Skip to content

L
linux
Switch branch/tag
  1. 03 Aug, 2018 11 commits
    • David S. Miller's avatar
      Merge branch 'l2tp-mtu' · 723a0043
      David S. Miller authored 
      Guillaume Nault says:

====================
l2tp: sanitise MTU handling on sessions

Most of the code handling sessions' MTU has no effect. The ->mtu field
in struct l2tp_session might be used at session creation time, but
neither PPP nor Ethernet pseudo-wires take updates into account.

L2TP sessions don't have a concept of MTU, which is the reason why
->mtu is mostly ignored. MTU should remain a network device thing.
Therefore this patch set does not try to propagate/update ->mtu to/from
the device. That would complicate the code unnecessarily. Instead this
field and the associated ioctl commands and netlink attributes are
removed.

Patch #1 defines l2tp_tunnel_dst_mtu() in order to simplify the
following patches. Then patches #2 and #3 remove MTU handling from PPP
and Ethernet pseudo-wires respectively.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      723a0043
    • Guillaume Nault's avatar
      l2tp: ignore L2TP_ATTR_MTU · e9697e2e
      Guillaume Nault authored 
      This attribute's handling is broken. It can only be used when creating
Ethernet pseudo-wires, in which case its value can be used as the
initial MTU for the l2tpeth device.
However, when handling update requests, L2TP_ATTR_MTU only modifies
session->mtu. This value is never propagated to the l2tpeth device.
Dump requests also return the value of session->mtu, which is not
synchronised anymore with the device MTU.

The same problem occurs if the device MTU is properly updated using the
generic IFLA_MTU attribute. In this case, session->mtu is not updated,
and L2TP_ATTR_MTU will report an invalid value again when dumping the
session.

It does not seem worthwhile to complexify l2tp_eth.c to synchronise
session->mtu with the device MTU. Even the ip-l2tp manpage advises to
use 'ip link' to initialise the MTU of l2tpeth devices (iproute2 does
not handle L2TP_ATTR_MTU at all anyway). So let's just ignore it
entirely.
Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e9697e2e
    • Guillaume Nault's avatar
      l2tp: simplify MTU handling in l2tp_ppp · 789141b2
      Guillaume Nault authored 
      The value of the session's .mtu field, as defined by
pppol2tp_connect() or pppol2tp_session_create(), is later overwritten
by pppol2tp_session_init() (unless getting the tunnel's socket PMTU
fails). This field is then only used when setting the PPP channel's MTU
in pppol2tp_connect().
Furthermore, the SIOC[GS]IFMTU ioctls only act on the session's .mtu
without propagating this value to the PPP channel, making them useless.

This patch initialises the PPP channel's MTU directly and ignores the
session's .mtu entirely. MTU is still computed by subtracting the
PPPOL2TP_HEADER_OVERHEAD constant. It is not optimal, but that doesn't
really matter: po->chan.mtu is only used when the channel is part of a
multilink PPP bundle. Running multilink PPP over packet switched
networks is certainly not going to be efficient, so not picking the
best MTU does not harm (in the worst case, packets will just be
fragmented by the underlay).

The SIOC[GS]IFMTU ioctls are removed entirely (as opposed to simply
ignored), because these ioctls commands are part of the requests that
should be handled generically by the socket layer. PX_PROTO_OL2TP was
the only socket type abusing these ioctls.
Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      789141b2
    • Guillaume Nault's avatar
      l2tp: define l2tp_tunnel_dst_mtu() · 1f5cd2a0
      Guillaume Nault authored 
      Consolidate retrieval of tunnel's socket mtu in order to simplify
l2tp_eth and l2tp_ppp a bit.
Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f5cd2a0
    • David S. Miller's avatar
      Merge branch 'hns3-next' · f3184645
      David S. Miller authored 
      Salil Mehta says:

====================
Some important fixes for HNS3 driver

This patch presents some important fixes related to MSIX allocation
in HNS3 driver.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f3184645
    • Jian Shen's avatar
      net: hns3: Refine the MSIX allocation for PF · 375dd5e4
      Jian Shen authored 
      The offset of msix number for roce is different between different
revision id. We should get it from firmware, instead of a fix value.
This patch refines the msix allocation, make it compatible.
Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      375dd5e4
    • Jian Shen's avatar
      net: hns3: Fix MSIX allocation issue for VF · 07acf909
      Jian Shen authored 
      The msix number for vf is different, depends on the max vf number.
Futherly if the vf supports roce, the offset of msix is not fixed.
It's incorrect to fix the msix number to 33. This patch fixes it by
querying the msix number from firmware, and adjusting it with roce
support.

Fixes: e2cb1dec ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support")
Signed-off-by: default avatarJian Shen <shenjian15@huawei.com>
Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07acf909
    • Kees Cook's avatar
      rxrpc: Reuse SKCIPHER_REQUEST_ON_STACK buffer · 54424d38
      Kees Cook authored 
      The use of SKCIPHER_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
(when less than 2048) once the VLA is no longer hidden from the check:

net/rxrpc/rxkad.c:398:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]
net/rxrpc/rxkad.c:242:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]

This passes the initial SKCIPHER_REQUEST_ON_STACK allocation to the leaf
functions for reuse. Two requests allocated on the stack is not needed
when only one is used at a time.
Signed-off-by: default avatarKees Cook <keescook@chromium.org>
Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54424d38
    • Jiri Pirko's avatar
      net: sched: fix flush on non-existing chain · 5ca8a25c
      Jiri Pirko authored 
      User was able to perform filter flush on chain 0 even if it didn't have
any filters in it. With the patch that avoided implicit chain 0
creation, this changed. So in case user wants filter flush on chain
which does not exist, just return success. There's no reason for non-0
chains to behave differently than chain 0, so do the same for them.
Reported-by: default avatarIdo Schimmel <idosch@mellanox.com>
Fixes: f71e0ca4 ("net: sched: Avoid implicit chain 0 creation")
Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5ca8a25c
    • YueHaibing's avatar
      bnxt_en: combine 'else if' and 'else' into single branch · 6fd544c8
      YueHaibing authored 
      The else-if branch and else branch set mac_ok to true similarly,
so combine the two into single else branch.

Also add comments to explain the two conditions, which
from Michael Chan and Vasundhara Volam.
Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
Acked-by: default avatarMichael Chan <michael.chan@broadcom.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6fd544c8
    • Jakub Kicinski's avatar
      tools: bpf: fix BTF code added twice to different trees · 6534770d
      Jakub Kicinski authored 
      commit 38d5d3b3 ("bpf: Introduce BPF_ANNOTATE_KV_PAIR")

added to the bpf and net trees what

commit 92b57121 ("bpf: btf: export btf types and name by offset from lib")

has already added to bpf-next/net-next, but in slightly different
location.  Remove the duplicates (to fix build of libbpf).
Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6534770d
  3. 02 Aug, 2018 21 commits
  5. 01 Aug, 2018 8 commits
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm · 6b470376
      Linus Torvalds authored 
      Pull ARM fix from Russell King:
 "Just a single fix this time around for recent binutils causing build
  problems when generating Thumb-2 code"

* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+
      6b470376
    • Vincent Bernat's avatar
      net: don't declare IPv6 non-local bind helper if CONFIG_IPV6 undefined · db57dc7c
      Vincent Bernat authored 
      Fixes: 83ba4645 ("net: add helpers checking if socket can be bound to nonlocal address")
Signed-off-by: default avatarVincent Bernat <vincent@bernat.im>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db57dc7c
    • Linus Torvalds's avatar
      mm: do not initialize TLB stack vma's with vma_init() · 8b11ec1b
      Linus Torvalds authored 
      Commit 2c4541e2 ("mm: use vma_init() to initialize VMAs on stack and
data segments") tried to initialize various left-over ad-hoc vma's
"properly", but actually made things worse for the temporary vma's used
for TLB flushing.

vma_init() doesn't actually initialize all of the vma, just a few
fields, so doing something like

   -       struct vm_area_struct vma = { .vm_mm = tlb->mm, };
   +       struct vm_area_struct vma;
   +
   +       vma_init(&vma, tlb->mm);

was actually very bad: instead of having a nicely initialized vma with
every field but "vm_mm" zeroed, you'd have an entirely uninitialized vma
with only a couple of fields initialized.  And they weren't even fields
that the code in question mostly cared about.

The flush_tlb_range() function takes a "struct vma" rather than a
"struct mm_struct", because a few architectures actually care about what
kind of range it is - being able to only do an ITLB flush if it's a
range that doesn't have data accesses enabled, for example.  And all the
normal users already have the vma for doing the range invalidation.

But a few people want to call flush_tlb_range() with a range they just
made up, so they also end up using a made-up vma.  x86 just has a
special "flush_tlb_mm_range()" function for this, but other
architectures (arm and ia64) do the "use fake vma" thing instead, and
thus got caught up in the vma_init() changes.

At the same time, the TLB flushing code really doesn't care about most
other fields in the vma, so vma_init() is just unnecessary and
pointless.

This fixes things by having an explicit "this is just an initializer for
the TLB flush" initializer macro, which is used by the arm/arm64/ia64
people who mis-use this interface with just a dummy vma.

Fixes: 2c4541e2 ("mm: use vma_init() to initialize VMAs on stack and data segments")
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8b11ec1b
    • Hugh Dickins's avatar
      mm: delete historical BUG from zap_pmd_range() · 53406ed1
      Hugh Dickins authored 
      Delete the old VM_BUG_ON_VMA() from zap_pmd_range(), which asserted
that mmap_sem must be held when splitting an "anonymous" vma there.
Whether that's still strictly true nowadays is not entirely clear,
but the danger of sometimes crashing on the BUG is now fairly clear.

Even with the new stricter rules for anonymous vma marking, the
condition it checks for can possible trigger. Commit 44960f2a
("staging: ashmem: Fix SIGBUS crash when traversing mmaped ashmem
pages") is good, and originally I thought it was safe from that
VM_BUG_ON_VMA(), because the /dev/ashmem fd exposed to the user is
disconnected from the vm_file in the vma, and madvise(,,MADV_REMOVE)
insists on VM_SHARED.

But after I read John's earlier mail, drawing attention to the
vfs_fallocate() in there: I may be wrong, and I don't know if Android
has THP in the config anyway, but it looks to me like an
unmap_mapping_range() from ashmem's vfs_fallocate() could hit precisely
the VM_BUG_ON_VMA(), once it's vma_is_anonymous().
Signed-off-by: default avatarHugh Dickins <hughd@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      53406ed1
    • David S. Miller's avatar
      Merge tag 'rxrpc-next-20180801' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs · b69ab96a
      David S. Miller authored 
      David Howells says:

====================
rxrpc: Development

Here are some patches that add some more tracepoints to AF_RXRPC and fix
some issues therein.  The most significant points are:

 (1) Display the call timeout information in /proc/net/rxrpc/calls.

 (2) Save the call's debug_id in the rxrpc_channel struct so that it can be
     used in traces after the rxrpc_call struct has been destroyed.

 (3) Increase the size of the kAFS Rx window from 32 to 63 to be about the
     same as the Auristor server.

 (4) Propose the terminal ACK for a client call after it has received all
     its data to be transmitted after a short interval so that it will get
     transmitted if not first superseded by a new call on the same channel.

 (5) Flush ACKs during the data reception if we detect that we've run out
     of data.[*]

 (6) Trace successful packet transmission and softirq to process context
     socket notification.

[*] Note that on a uncontended gigabit network, rxrpc runs in to trouble
    with ACK packets getting batched together (up to ~32 at a time)
    somewhere between the IP transmit queue on the client and the ethernet
    receive queue on the server.

    I can see the kernel afs filesystem client and Auristor userspace
    server stalling occasionally on a 512MB single read.  Sticking
    tracepoints in the network driver at either end seems to show that,
    although the ACK transmissions made by the client are reasonably spaced
    timewise, the received ACKs come in batches from the network card on
    the server.

    I'm not sure what, if anything, can be done about this.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b69ab96a
    • YueHaibing's avatar
      rxrpc: Fix user call ID check in rxrpc_service_prealloc_one · c01f6c9b
      YueHaibing authored 
      There just check the user call ID isn't already in use, hence should
compare user_call_ID with xcall->user_call_ID, which is current
node's user_call_ID.

Fixes: 540b1c48 ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg")
Suggested-by: default avatarDavid Howells <dhowells@redhat.com>
Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c01f6c9b
    • Linus Torvalds's avatar
      Merge tag 'mmc-v4.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc · 9a97ebf7
      Linus Torvalds authored 
      Pull MMC fix from Ulf Hansson:
 "MMC host: mxcmmc: Fix build error for powerpc"

* tag 'mmc-v4.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  mmc: mxcmmc: Fix missing parentheses and brace
      9a97ebf7
    • Linus Torvalds's avatar
      Merge tag 'pm-urgent-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · f390b7bf
      Linus Torvalds authored 
      Pull power management fixes from Rafael Wysocki:
 "These fix the scope of a recent intel_pstate driver optimization used
  incorrectly on some systems due to processor identification ambiguity
  and fix a few issues in the turbostat utility, including three recent
  regressions.

  Specifics:

   - Use ACPI FADT preferred PM Profile to distinguish Skylake desktop
     processors from some server ones with the same model number in
     order to limit the scope of the recent IO-wait boost optimization
     to servers, as intended (Srinivas Pandruvada).

   - Fix several issues in the turbostat utility:
      * Fix the -S option on 1-CPU systems (Len Brown).
      * Fix computations using incorrect processor core counts (Artem
        Bityutskiy).
      * Fix the x2apic debug message (Len Brown).
      * Fix logical node enumeration to allow for non-sequential
        physical nodes (Prarit Bhargava).
      * Fix reported family on modern AMD processors (Calvin Walton).
      * Clarify the RAPL column information in the man page (Len Brown)"

* tag 'pm-urgent-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  cpufreq: intel_pstate: Limit the scope of HWP dynamic boost platforms
  tools/power turbostat: version 18.07.27
  tools/power turbostat: Read extended processor family from CPUID
  tools/power turbostat: Fix logical node enumeration to allow for non-sequential physical nodes
  tools/power turbostat: fix x2apic debug message output file
  tools/power turbostat: fix bogus summary values
  tools/power turbostat: fix -S on UP systems
  tools/power turbostat: Update turbostat(8) RAPL throttling column description
      f390b7bf
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7