l2tp_session_create() relies on its caller for checking for duplicate
sessions. This is racy since a session can be concurrently inserted
after the caller's verification.
Fix this by letting l2tp_session_create() verify sessions uniqueness
upon insertion. Callers need to be adapted to check for
l2tp_session_create()'s return code instead of calling
l2tp_session_find().
pppol2tp_connect() is a bit special because it has to work on existing
sessions (if they're not connected) or to create a new session if none
is found. When acting on a preexisting session, a reference must be
held or it could go away on us. So we have to use l2tp_session_get()
instead of l2tp_session_find() and drop the reference before exiting.
Fixes: d9e31d17ce ("l2tp: Add L2TP ethernet pseudowire support")
Fixes: fd558d186d ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Holding a reference on session is required before calling
pppol2tp_session_ioctl(). The session could get freed while processing the
ioctl otherwise. Since pppol2tp_session_ioctl() uses the session's socket,
we also need to take a reference on it in l2tp_session_get().
Fixes: fd558d186d ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Taking a reference on sessions in l2tp_recv_common() is racy; this
has to be done by the callers.
To this end, a new function is required (l2tp_session_get()) to
atomically lookup a session and take a reference on it. Callers then
have to manually drop this reference.
Fixes: fd558d186d ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since sctp reconf was added in sctp, the real cnt of in/out stream
have not been c.sinit_max_instreams and c.sinit_num_ostreams any
more.
This patch is to replace them with stream->in/outcnt.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the udp_sock struct, the 'forward_deficit' and 'pcflag' fields
share the same cacheline. While the first is dirtied by
udp_recvmsg, the latter is read, possibly several times, by the
bottom half processing to discriminate between udp and udplite
sockets.
With this patch, sk->sk_protocol is used to check is the socket is
really an udplite one, avoiding some cache misses per
packet and improving the performance under udp_flood with
small packet up to 10%.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull parisc fixes from Helge Deller:
"Al Viro reported that - in case of read faults - our copy_from_user()
implementation may claim to have copied more bytes than it actually
did. In order to fix this bug and because of the way how gcc optimizes
register usage for inline assembly in C code, we had to replace our
pa_memcpy() function with a pure assembler implementation.
While fixing the memcpy bug we noticed some other issues with our
get_user() and put_user() functions, e.g. nested faults may return
wrong data. This is now fixed by a common fixup handler for
get_user/put_user in the exception handler which additionally makes
generated code smaller and faster.
The third patch is a trivial one-line fix for a patch which went in
during 4.11-rc and which avoids stalled CPU warnings after power
shutdown (for parisc machines which can't plug power off themselves).
Due to the rewrite of pa_memcpy() into assembly this patch got bigger
than what I wanted to have sent at this stage.
Those patches have been running in production during the last few days
on our debian build servers without any further issues"
* 'parisc-4.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Avoid stalled CPU warnings after system shutdown
parisc: Clean up fixup routines for get_user()/put_user()
parisc: Fix access fault handling in pa_memcpy()
After commit 96567d5dac ("net: dsa: dsa2: Add basic support of devlink")
I see the following link error with CONFIG_NET_DSA=y and CONFIG_NET_DEVLINK=m:
net/built-in.o: In function 'dsa_register_switch':
(.text+0xe226b): undefined reference to `devlink_alloc'
net/built-in.o: In function 'dsa_register_switch':
(.text+0xe2284): undefined reference to `devlink_register'
net/built-in.o: In function 'dsa_register_switch':
(.text+0xe243e): undefined reference to `devlink_port_register'
net/built-in.o: In function 'dsa_register_switch':
(.text+0xe24e1): undefined reference to `devlink_port_register'
net/built-in.o: In function 'dsa_register_switch':
(.text+0xe24fa): undefined reference to `devlink_port_type_eth_set'
net/built-in.o: In function 'dsa_dst_unapply.part.8':
dsa2.c:(.text.unlikely+0x345): undefined reference to 'devlink_port_unregister'
dsa2.c:(.text.unlikely+0x36c): undefined reference to 'devlink_port_unregister'
dsa2.c:(.text.unlikely+0x38e): undefined reference to 'devlink_port_unregister'
dsa2.c:(.text.unlikely+0x3f2): undefined reference to 'devlink_unregister'
dsa2.c:(.text.unlikely+0x3fb): undefined reference to 'devlink_free'
Fix this by adding a dependency on MAY_USE_DEVLINK so that CONFIG_NET_DSA
get switched to be build as module when CONFIG_NET_DEVLINK=m.
Fixes: 96567d5dac ("net: dsa: dsa2: Add basic support of devlink")
Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Thirteen small fixes: The hopefully final effort to get the lpfc nvme
kconfig problems sorted, there's one important sg fix (user can induce
read after end of buffer) and one minor enhancement (adding an extra
PCI ID to qedi). The rest are a set of minor fixes, which mostly occur
as user visible in error legs or on specific devices.
Signed-off-by: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJY39E7AAoJEAVr7HOZEZN4WskQALCWMroFglXHofUbwMrKH4gv
on+6k1k+z0iiUiidpfdPb0gL1D4fSBcDl60fQbSUFFlGiM1/MTpyv10QhqlER1al
74ZLJ6cavw52WBLJccQBCGeYBIDdvAGPLfcoIHPfa4+6I2yXe1dsAY6T3qDUHsGW
amEG62qjbpUkrPhyQq+ehTxU4itam2JH17eTis4xVCG0vXuvlp4igecbErzwOZu7
zhpTvJZezsfiCXmPGyqbyRU1IRU5WglznwiZ7duNtTIFD8vQ9dugs/QH88VL31rh
25uWiJMn9waC2o4wHuRzHb5VOFQxkhanAc0y+f3I4pxTdX4d5yN7TeNtxUxZM1z7
CEB4QFVns8YF68WZaodCVqn06uX4REwdIs6n7KTsQT9JGQbnmEFoGLNe1/wCgdGZ
16gH+0visFCnZQpCDbuFsUcddFglAT1EtvNLbPxKk3sKxAwqZJ+e5Lon7CX9s89f
rPlvRb68Nw/ctxgXffM2ecRddpvHTeRgy1XBv/STMhGOzJV5k6S3nXPZfyq5kWdH
Fv9MUu3qu2rVplPKydrOlXkz40a2cl/jS0M8UXueoJwE/JkvoiwquzThLO1BB3W/
5Dc1NVii67qPlEJ8mAsNYiPnZww7t8IRlHlD+H7/pSo0RE2C4jhNmoZMyEjwlmex
Fq13DkTbBhIZ0mNCwQ2J
=umUo
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Thirteen small fixes: The hopefully final effort to get the lpfc nvme
kconfig problems sorted, there's one important sg fix (user can induce
read after end of buffer) and one minor enhancement (adding an extra
PCI ID to qedi). The rest are a set of minor fixes, which mostly occur
as user visible in error legs or on specific devices"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: ufs: remove the duplicated checking for supporting clkscaling
scsi: lpfc: fix building without debugfs support
scsi: lpfc: Fix PT2PT PRLI reject
scsi: hpsa: fix volume offline state
scsi: libsas: fix ata xfer length
scsi: scsi_dh_alua: Warn if the first argument of alua_rtpg_queue() is NULL
scsi: scsi_dh_alua: Ensure that alua_activate() calls the completion function
scsi: scsi_dh_alua: Check scsi_device_get() return value
scsi: sg: check length passed to SG_NEXT_CMD_LEN
scsi: ufshcd-platform: remove the useless cast in ERR_PTR/IS_ERR
scsi: qedi: Add PCI device-ID for QL41xxx adapters.
scsi: aacraid: Fix potential null access
scsi: qla2xxx: Fix crash in qla2xxx_eh_abort on bad ptr
Russell King says:
====================
phylib EEE updates
This series of patches depends on the previous set of changes, and is
therefore net-next material.
While testing the EEE code, I discovered a number of issues:
1. It is possible to enable advertisment of EEE modes which are not
supported by the hardware. We omit to check the supported modes
and mask off those modes that are not supported before writing the
EEE advertisment register.
2. We need to restart autonegotiation after a change of the EEE
advertisment, otherwise the link partner does not see the updated
EEE modes.
3. SGMII connected PHYs are also capable of supporting EEE.
Through discussion with Florian, it has been decided to remove the check
for the PHY interface mode in patch (3).
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
EEE is able to work in any PHY interface mode, there is nothing which
fundamentally restricts it to only a few modes. For example, EEE works
in SGMII mode with the Marvell 88E1512.
Rather than just adding SGMII mode to the list, Florian suggests
removing the list of interface modes entirely:
It actually sounds like we should just kill the check entirely,
it does not appear that any of the interface mode would not
fundamentally be able to support EEE, because the "lowest" mode
we support is MII, and even there it's quite possible to support
EEE.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the EEE advertisment is changed, we should restart autonegotiation
to update the link partner with the new EEE settings. Add this trigger
but only if the advertisment has changed.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
We currently allow userspace to set any EEE advertisments it desires,
whether or not the PHY supports them. For example:
# ethtool --set-eee eth1 advertise 0xffffffff
# ethtool --show-eee eth1
EEE Settings for eth1:
EEE status: disabled
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
1000baseKX/Full
10000baseT/Full
10000baseKX4/Full
10000baseKR/Full
Clearly, this is not sane, we should only allow link modes that are
supported to be advertised (as we do elsewhere.) Ensure that we mask
the MDIO_AN_EEE_ADV value with the capabilities retrieved from the
MDIO_PCS_EEE_ABLE register.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge misc fixes from Andrew Morton:
"11 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
kasan: do not sanitize kexec purgatory
drivers/rapidio/devices/tsi721.c: make module parameter variable name unique
mm/hugetlb.c: don't call region_abort if region_chg fails
kasan: report only the first error by default
hugetlbfs: initialize shared policy as part of inode allocation
mm: fix section name for .data..ro_after_init
mm, hugetlb: use pte_present() instead of pmd_present() in follow_huge_pmd()
mm: workingset: fix premature shadow node shrinking with cgroups
mm: rmap: fix huge file mmap accounting in the memcg stats
mm: move mm_percpu_wq initialization earlier
mm: migrate: fix remove_migration_pte() for ksm pages
Alexei Starovoitov says:
====================
bpf: program testing framework
Development and testing of networking bpf programs is quite cumbersome.
Especially tricky are XDP programs that attach to real netdevices and
program development feels like working on the car engine while
the car is in motion.
Another problem is ongoing changes to upstream llvm core
that can introduce an optimization that verifier will not
recognize. llvm bpf backend tests have no ability to run the programs.
To improve this situation introduce BPF_PROG_TEST_RUN command
to test and performance benchmark bpf programs.
It achieves several goals:
- development of xdp and skb based bpf programs can be done
in a canned environment with unit tests
- program performance optimizations can be benchmarked outside of
networking core (without driver and skb costs)
- continuous testing of upstream changes is finally practical
Patches 4,5,6 add C based test cases of various complexity
to cover some sched_cls and xdp features. More tests will
be added in the future. The tests were run on centos7 only.
For now the framework supports only skb and xdp programs. In the future
it can be extended to socket_filter and tracing program types.
More details are in individual patches.
v1->v2:
- rename bpf_program_test_run->bpf_prog_test_run
- add missing #include <linux/bpf.h> since libbpf.h shouldn't depend
on prior includes
- reordered patches 3 and 4 to keep bisect clean
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
this l4lb demo is a comprehensive test case for LLVM codegen and
kernel verifier. It's using fully inlined jhash(), complex packet
parsing and multiple map lookups of different types to stress
llvm and verifier.
The map sizes, map population and test vectors are artificial to
exercise different paths through the bpf program.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
add C test for xdp_adjust_head(), packet rewrite and map lookups
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
add simple C test case for llvm and verifier range check fix from
commit b1977682a3 ("bpf: improve verifier packet range checks")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
expose bpf_program__set_type() to set program type
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
add support for BPF_PROG_TEST_RUN command to libbpf.a
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Wang Nan <wangnan0@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
development and testing of networking bpf programs is quite cumbersome.
Despite availability of user space bpf interpreters the kernel is
the ultimate authority and execution environment.
Current test frameworks for TC include creation of netns, veth,
qdiscs and use of various packet generators just to test functionality
of a bpf program. XDP testing is even more complicated, since
qemu needs to be started with gro/gso disabled and precise queue
configuration, transferring of xdp program from host into guest,
attaching to virtio/eth0 and generating traffic from the host
while capturing the results from the guest.
Moreover analyzing performance bottlenecks in XDP program is
impossible in virtio environment, since cost of running the program
is tiny comparing to the overhead of virtio packet processing,
so performance testing can only be done on physical nic
with another server generating traffic.
Furthermore ongoing changes to user space control plane of production
applications cannot be run on the test servers leaving bpf programs
stubbed out for testing.
Last but not least, the upstream llvm changes are validated by the bpf
backend testsuite which has no ability to test the code generated.
To improve this situation introduce BPF_PROG_TEST_RUN command
to test and performance benchmark bpf programs.
Joint work with Daniel Borkmann.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds support for a DSA mock-up driver which essentially does
the following:
- registers/unregisters 4 fixed PHYs to the slave network devices
- uses eth0 (configurable) as the master netdev
- registers the switch as a fixed MDIO device against the fixed MDIO bus
at address 31
- includes dynamic debug prints for dsa_switch_ops functions that can be
enabled to get call traces
This is a good way to test modular builds as well as exercise the DSA
APIs without requiring access to real hardware. This does not test the
data-path, although this could be added later on.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Daniel Borkmann says:
====================
BPF fixes on map_value_adj reg types
This set adds two fixes for map_value_adj register type in the
verifier and user space tests along with them for the BPF self
test suite. For details, please see individual patches.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a couple of test cases, for example, probing for xadd on a spilled
pointer to packet and map_value_adj register, various other map_value_adj
tests including the unaligned load/store, and trying out pointer arithmetic
on map_value_adj register itself. For the unaligned load/store, we need
to figure out whether the architecture has efficient unaligned access and
need to mark affected tests accordingly.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, the verifier doesn't reject unaligned access for map_value_adj
register types. Commit 484611357c ("bpf: allow access into map value
arrays") added logic to check_ptr_alignment() extending it from PTR_TO_PACKET
to also PTR_TO_MAP_VALUE_ADJ, but for PTR_TO_MAP_VALUE_ADJ no enforcement
is in place, because reg->id for PTR_TO_MAP_VALUE_ADJ reg types is never
non-zero, meaning, we can cause BPF_H/_W/_DW-based unaligned access for
architectures not supporting efficient unaligned access, and thus worst
case could raise exceptions on some archs that are unable to correct the
unaligned access or perform a different memory access to the actual
requested one and such.
i) Unaligned load with !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
on r0 (map_value_adj):
0: (bf) r2 = r10
1: (07) r2 += -8
2: (7a) *(u64 *)(r2 +0) = 0
3: (18) r1 = 0x42533a00
5: (85) call bpf_map_lookup_elem#1
6: (15) if r0 == 0x0 goto pc+11
R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp
7: (61) r1 = *(u32 *)(r0 +0)
8: (35) if r1 >= 0xb goto pc+9
R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R1=inv,min_value=0,max_value=10 R10=fp
9: (07) r0 += 3
10: (79) r7 = *(u64 *)(r0 +0)
R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R1=inv,min_value=0,max_value=10 R10=fp
11: (79) r7 = *(u64 *)(r0 +2)
R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R1=inv,min_value=0,max_value=10 R7=inv R10=fp
[...]
ii) Unaligned store with !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
on r0 (map_value_adj):
0: (bf) r2 = r10
1: (07) r2 += -8
2: (7a) *(u64 *)(r2 +0) = 0
3: (18) r1 = 0x4df16a00
5: (85) call bpf_map_lookup_elem#1
6: (15) if r0 == 0x0 goto pc+19
R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp
7: (07) r0 += 3
8: (7a) *(u64 *)(r0 +0) = 42
R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R10=fp
9: (7a) *(u64 *)(r0 +2) = 43
R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R10=fp
10: (7a) *(u64 *)(r0 -2) = 44
R0=map_value_adj(ks=8,vs=48,id=0),min_value=3,max_value=3 R10=fp
[...]
For the PTR_TO_PACKET type, reg->id is initially zero when skb->data
was fetched, it later receives a reg->id from env->id_gen generator
once another register with UNKNOWN_VALUE type was added to it via
check_packet_ptr_add(). The purpose of this reg->id is twofold: i) it
is used in find_good_pkt_pointers() for setting the allowed access
range for regs with PTR_TO_PACKET of same id once verifier matched
on data/data_end tests, and ii) for check_ptr_alignment() to determine
that when not having efficient unaligned access and register with
UNKNOWN_VALUE was added to PTR_TO_PACKET, that we're only allowed
to access the content bytewise due to unknown unalignment. reg->id
was never intended for PTR_TO_MAP_VALUE{,_ADJ} types and thus is
always zero, the only marking is in PTR_TO_MAP_VALUE_OR_NULL that
was added after 484611357c via 57a09bf0a4 ("bpf: Detect identical
PTR_TO_MAP_VALUE_OR_NULL registers"). Above tests will fail for
non-root environment due to prohibited pointer arithmetic.
The fix splits register-type specific checks into their own helper
instead of keeping them combined, so we don't run into a similar
issue in future once we extend check_ptr_alignment() further and
forget to add reg->type checks for some of the checks.
Fixes: 484611357c ("bpf: allow access into map value arrays")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
While looking into map_value_adj, I noticed that alu operations
directly on the map_value() resp. map_value_adj() register (any
alu operation on a map_value() register will turn it into a
map_value_adj() typed register) are not sufficiently protected
against some of the operations. Two non-exhaustive examples are
provided that the verifier needs to reject:
i) BPF_AND on r0 (map_value_adj):
0: (bf) r2 = r10
1: (07) r2 += -8
2: (7a) *(u64 *)(r2 +0) = 0
3: (18) r1 = 0xbf842a00
5: (85) call bpf_map_lookup_elem#1
6: (15) if r0 == 0x0 goto pc+2
R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp
7: (57) r0 &= 8
8: (7a) *(u64 *)(r0 +0) = 22
R0=map_value_adj(ks=8,vs=48,id=0),min_value=0,max_value=8 R10=fp
9: (95) exit
from 6 to 9: R0=inv,min_value=0,max_value=0 R10=fp
9: (95) exit
processed 10 insns
ii) BPF_ADD in 32 bit mode on r0 (map_value_adj):
0: (bf) r2 = r10
1: (07) r2 += -8
2: (7a) *(u64 *)(r2 +0) = 0
3: (18) r1 = 0xc24eee00
5: (85) call bpf_map_lookup_elem#1
6: (15) if r0 == 0x0 goto pc+2
R0=map_value(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp
7: (04) (u32) r0 += (u32) 0
8: (7a) *(u64 *)(r0 +0) = 22
R0=map_value_adj(ks=8,vs=48,id=0),min_value=0,max_value=0 R10=fp
9: (95) exit
from 6 to 9: R0=inv,min_value=0,max_value=0 R10=fp
9: (95) exit
processed 10 insns
Issue is, while min_value / max_value boundaries for the access
are adjusted appropriately, we change the pointer value in a way
that cannot be sufficiently tracked anymore from its origin.
Operations like BPF_{AND,OR,DIV,MUL,etc} on a destination register
that is PTR_TO_MAP_VALUE{,_ADJ} was probably unintended, in fact,
all the test cases coming with 484611357c ("bpf: allow access
into map value arrays") perform BPF_ADD only on the destination
register that is PTR_TO_MAP_VALUE_ADJ.
Only for UNKNOWN_VALUE register types such operations make sense,
f.e. with unknown memory content fetched initially from a constant
offset from the map value memory into a register. That register is
then later tested against lower / upper bounds, so that the verifier
can then do the tracking of min_value / max_value, and properly
check once that UNKNOWN_VALUE register is added to the destination
register with type PTR_TO_MAP_VALUE{,_ADJ}. This is also what the
original use-case is solving. Note, tracking on what is being
added is done through adjust_reg_min_max_vals() and later access
to the map value enforced with these boundaries and the given offset
from the insn through check_map_access_adj().
Tests will fail for non-root environment due to prohibited pointer
arithmetic, in particular in check_alu_op(), we bail out on the
is_pointer_value() check on the dst_reg (which is false in root
case as we allow for pointer arithmetic via env->allow_ptr_leaks).
Similarly to PTR_TO_PACKET, one way to fix it is to restrict the
allowed operations on PTR_TO_MAP_VALUE{,_ADJ} registers to 64 bit
mode BPF_ADD. The test_verifier suite runs fine after the patch
and it also rejects mentioned test cases.
Fixes: 484611357c ("bpf: allow access into map value arrays")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vivien Didelot says:
====================
net: dsa: mv88e6xxx: program cross-chip bridging
The purpose of this patch series is to bring hardware cross-chip
bridging configuration to the DSA layer and the mv88e6xxx DSA driver.
Most recent Marvell switch chips have a Cross-chip Port Based VLAN Table
(PVT) used to restrict to which internal destination port an arbitrary
external source port is allowed to egress frames to.
The current behavior of the mv88e6xxx driver is to program this table
table with all ones, allowing any external ports to egress frames on any
internal ports. This means that carefully crafted Ethernet frames can
potentially bypass the user bridging configuration.
Patches 1 to 7 prepare the setup of this table and factorize the common
bits of both in-chip and cross-chip Marvell bridging code.
Patch 8 adds new optional cross-chip bridging operations to DSA switch.
Patch 9 switches the current behavior to program the table according to
the user bridging configuration when (cross-chip) ports get (un)bridged.
On a ZII Rev B board, bridging together the 3 user ports of both 88E6352
will result in the following PVTs on respectively switch 0 and switch 1:
External Internal Ports
Dev Port 0 1 2 3 4 5 6
1 0 * * * - - * *
1 1 * * * - - * *
1 2 * * * - - * *
1 3 - - - - - * *
1 4 - - - - - * *
1 5 * * * * * * *
1 6 * * * * * * *
0 0 * * * - - * *
0 1 * * * - - * *
0 2 * * * - - * *
0 3 - - - - - * *
0 4 - - - - - * *
0 5 * * * * * * *
0 6 * * * * * * *
Changes since v2:
- Define MV88E6XXX_MAX_PVT_SWITCHES and MV88E6XXX_MAX_PVT_PORTS
- use mv88e6xxx_g2_misc_4_bit_port instead of the 5-bit variant
- add Andrew's tags and reword commit 6/9
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Implement the DSA cross-chip bridging operations by remapping the local
ports an external source port can egress frames to, when this cross-chip
port joins or leaves a bridge.
The PVT is no longer configured with all ones allowing any external
frame to egress any local port. Only DSA and CPU ports, as well as
bridge group members, can egress frames on local ports.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Introduce crosschip_bridge_{join,leave} operations in the dsa_switch_ops
structure, which can be used by switches supporting interconnection.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a local port of a switch chip becomes a member of a bridge group,
we need to reprogram the Cross-chip Port Based VLAN Table (PVT) to allow
existing cross-chip bridge members to egress frames on the new ports.
There is no functional changes yet, since the PVT is still programmed
with all ones, allowing any external port to egress frames locally.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Factorize the code in the DSA port_bridge_{join,leave} routines used to
program the port VLAN map of all local ports of a given bridge group.
At the same time shorten the _mv88e6xxx_port_based_vlan_map to get rid
of the old underscore prefix naming convention.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
All ports -- internal and external, for chips featuring a PVT -- have a
mask restricting to which internal ports a frame is allowed to egress.
Now that DSA exposes the number of ports and their bridge devices, it is
possible to extract the code generating the VLAN map and make it generic
so that it can be shared later with the cross-chip bridging code.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current code allocates DSA_MAX_PORTS ports for a Marvell dsa_switch
structure. Provide the exact number of ports so the corresponding
ds->num_ports is accurate.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The Cross-chip Port Based VLAN Table (PVT) is currently initialized with
all ones, allowing any external ports to egress frames on local ports.
This commit implements the PVT access functions and programs the PVT
with all ones for the local switch ports only, instead of using the Init
operation. The current behavior is unchanged for the moment.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The Cross-chip Port Based VLAN Table (PVT) supports two indexing modes,
one using 5-bit for device and 4-bit for port, the other using 4-bit for
device and 5-bit for port, configured via the Global 2 Misc register.
Only 4 bits for the source port are needed when interconnecting 88E6xxx
switch devices since they all support less than 16 physical ports. The
full 5 bits are needed when interconnecting a device with 98DXxxx switch
devices since they support more than 16 physical ports.
Add a mv88e6xxx_pvt_setup helper to set the 4-bit port PVT mode, which
will be extended later to also initialize the PVT content.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Not all Marvell switch chips feature a Cross-chip Port VLAN Table (PVT).
Chips with a PVT use the same implementation, so a new mv88e6xxx_ops
member won't be necessary yet. Add a "pvt" boolean member to the
mv88e6xxx_info structure and kill the obsolete MV88E6XXX_FLAGS_PVT flag.
Add a mv88e6xxx_has_pvt helper to wrap future checks of that condition.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Without this the generic cdc_ether grabs the device,
and does not really work.
Signed-off-by: René Rebe <rene@exactcode.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
ovs_flow_key_update() is called when the flow key is invalid, and it is
used to update and revalidate the flow key. Commit 329f45bc4f
("openvswitch: add mac_proto field to the flow key") introduces mac_proto
field to flow key and use it to determine whether the flow key is valid.
However, the commit does not update the code path in ovs_flow_key_update()
to revalidate the flow key which may cause BUG_ON() on execute_recirc().
This patch addresses the aforementioned issue.
Fixes: 329f45bc4f ("openvswitch: add mac_proto field to the flow key")
Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
Acked-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This driver uses interfaces from linux/of.h and linux/property.h but
relies on implict inclusion of those headers which means that changes in
other headers could break the build, as happened in -next for arm today.
Add a explicit includes.
Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current code only supports DT to check SFP present.
This patch adds ACPI support as well.
Signed-off-by: Daode Huang <huangdaode@hisilicon.com>
Reviewed-by: Yisen Zhuang <yisen.zhuang@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The AVOIDBLOCK flag determines the Tx confirmation queues processing
to be redirected to any available CPU when the current one is slow
in processing them. This may result in a higher Tx confirmation
interrupt count but may reduce pressure on a certain CPU that with
the previous setting would process all Tx confirmation frames.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Here are some small USB fixes for 4.11-rc5.
The usual xhci fixes are here, as well as a fix for
yet-another-bug-found-by-KASAN, those developers are doing great stuff
here. And there's a phy build warning fix that showed up in 4.11-rc1.
All of these have been in linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWN/NGw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymNQQCeNiONvY70Y99hWFDX+PL896fV1rYAoNchYIZY
V4NYSVr43W4uk7jrUQD5
=NUT1
-----END PGP SIGNATURE-----
Merge tag 'usb-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB fixes for 4.11-rc5.
The usual xhci fixes are here, as well as a fix for yet-another-bug-
found-by-KASAN, those developers are doing great stuff here.
And there's a phy build warning fix that showed up in 4.11-rc1.
All of these have been in linux-next with no reported issues"
* tag 'usb-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: phy: isp1301: Fix build warning when CONFIG_OF is disabled
xhci: Manually give back cancelled URB if we can't queue it for cancel
xhci: Set URB actual length for stopped control transfers
xhci: plat: Register shutdown for xhci_plat
USB: fix linked-list corruption in rh_call_control()
Here are some small fixes for some serial drivers and Kconfig help text
for 4.11-rc5. Nothing major here at all, a few things resolving
reported bugs in some random serial drivers.
I don't think these made the last linux-next due to me getting to them
yesterday, but I am not sure, they might have snuck in. The patches
only affect drivers that the maintainers of sent me these patches for,
so we should be safe here :)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWN/ODw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yl5cwCfaBlkq7fOavwOENjXEGCsilXUNP0Anic5NQ5D
F26b+NwYZUO2MAQjZ2MP
=pS56
-----END PGP SIGNATURE-----
Merge tag 'tty-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are some small fixes for some serial drivers and Kconfig help
text for 4.11-rc5. Nothing major here at all, a few things resolving
reported bugs in some random serial drivers.
I don't think these made the last linux-next due to me getting to them
yesterday, but I am not sure, they might have snuck in. The patches
only affect drivers that the maintainers of sent me these patches for,
so we should be safe here :)"
* tag 'tty-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: pl011: fix earlycon work-around for QDF2400 erratum 44
serial: 8250_EXAR: fix duplicate Kconfig text and add missing help text
tty/serial: atmel: fix TX path in atmel_console_write()
tty/serial: atmel: fix race condition (TX+DMA)
serial: mxs-auart: Fix baudrate calculation
vxlan dev currently ignores lowerdev's gso_max_size, which adversely
affects TSO performance of liquidio if it's the lowerdev. Egress TCP
packets' skb->len often exceed liquidio's advertised gso_max_size. This
may happen on other NIC drivers.
Fix it by assigning lowerdev's gso_max_size to that of vxlan dev. Might as
well do likewise for gso_max_segs.
Single flow TSO throughput of liquidio as lowerdev (using iperf3):
Before the patch: 139 Mbps
After the patch : 8.68 Gbps
Percent increase: 6,144 %
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- Drop the unconditional setting of the '-Os' gcc flag from the ACPI
Makefile to make the function graph tracer work correctly with the
ACPI subsystem (Josh Poimboeuf).
- Add missing synchronize_rcu() to ghes_remove() which removes an
element from an RCU-protected list, but fails to synchronize it
properly afterward (James Morse).
- Fix two problems related to IOAPIC hotplug, a local variable
initialization in setup_res() and the creation of platform
device objects for IO(x)APICs which are (a) unused and (b) leaked
on hot-removal (Joerg Roedel).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJY3sfNAAoJEILEb/54YlRxcZUQAJal6FG3HqlPdIRzNMMsZf+H
kygxIf8BJfP4qh5FabeGacsizpJqZpUrOmCZZkPMYGDN7qe5QXpP1ZHYLxAm+jlB
1XL1yoqJwkEPhM8IaeoXprjvyTaFI2QPVDbHhFmhO3pc3CAhKsg85tK02TIER7G5
vWK7/qfIcWKjdqISUyHaL7P+5KHLWtOFXi78WAEA9RnDV23GUoLGp2CBkPSM0VvP
gsz+PYF0q4AAsjpSUsTx4MPecxL1Nvhl60MqCQ6gfybde9znnqtY6Pazen3OEoct
ntX9tYu6Awq35FQtYFzxQWBSgdxiK7lWB/+4TvGQBQ5TiaCa0DOAKbGBDwZGIfVJ
gHaFyq+AF5cD7VQL7+9M7A+urGnCoUEt0VeaVJtinOq0AHx4w1pBtV7rzpt9OWwD
0/JkMJ5h1zbGC9tBiu4YmoQN8abuPoUxz/zlErKlhB7ur3kWRd4EXRXr6I22b43Q
DPUPUGSY/vTbB6/MILNOLxQFCHDB83AOTQu01aKIZZdQ4dlgmjC4dymYgO7J2HGi
V7E6t8iW8jyZ7kGBgAvWDuLh9T/RqAx/HaEtRDrmKyPS0Y5ND/nDDSmNHSjJQ4+3
S88pgMQjIDWd+Dsu2xHWQC1r5d3qmD2ScwlQlPqtKDOlAUO/v3hJebk8w1PUYa59
uLmsZHL7RVcEEe9D4Dp0
=dCcJ
-----END PGP SIGNATURE-----
Merge tag 'acpi-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"These fix two issues related to IOAPIC hotplug, an overzealous build
optimization that prevents the function graph tracer from working with
the ACPI subsystem correctly and an RCU synchronization issue in the
ACPI APEI code.
Specifics:
- drop the unconditional setting of the '-Os' gcc flag from the ACPI
Makefile to make the function graph tracer work correctly with the
ACPI subsystem (Josh Poimboeuf).
- add missing synchronize_rcu() to ghes_remove() which removes an
element from an RCU-protected list, but fails to synchronize it
properly afterward (James Morse).
- fix two problems related to IOAPIC hotplug, a local variable
initialization in setup_res() and the creation of platform device
objects for IO(x)APICs which are (a) unused and (b) leaked on
hot-removal (Joerg Roedel)"
* tag 'acpi-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: Fix incompatibility with mcount-based function graph tracing
ACPI / APEI: Add missing synchronize_rcu() on NOTIFY_SCI removal
ACPI: Do not create a platform_device for IOAPIC/IOxAPIC
ACPI: ioapic: Clear on-stack resource before using it
- Symbolic links from CPU directories to the corresponding cpufreq
policy directories in sysfs are not created during initialization
in some cases which confuses user space, so prevent that from
happening (Rafael Wysocki).
- The powernv cpuidle driver fails to pass a correct cpumaks to
the cpuidle core in some cases which causes subsequent failures
to occur, so fix it (Vaidyanathan Srinivasan).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJY3sdlAAoJEILEb/54YlRxMG0P/1YRBbFeC8V6z5LLZUzaYt+h
lK+G6scJ5rFSl3kphNNbDBIWiK8R/rOT7hizqIbMpBvtmaFB/EJbEuNgsxprQ99+
Ru3pvX/GjnpFljb5QlmdKFxtr4MUPYz3WkxGkkIf0W+lyacOSMcOqpBASJIHsqok
rG9AMQTJJ7yooh6Sn9/b5VEkLUu5uLcw1P+XKjXnsz5QU7F1f8HEfPa1sFbreFCt
1XZx09szLTCdYnpESEiX/CJQlwdbB6dT4Mc260xzmrLI0pMFLnQBsbg7i62HeY1N
TaSTAY463IZ1+IW7e1gyyFz5PnMeuqvMVvl0XFKyftwtu0ybdieCNYfDeQn79+XY
LLd0p15HbpLxoqpkr+xWNQoCunkhMl146o+VgxD+jZ+yUMk/NyU6/TaSJzsxm0Jx
52Rk7lWPXLPZ8NyF4NatTWWhPRFd0fxmhb1CLRai5/7iA3M4EVVbVleKKapIHqxg
cDhfxmjeMSKAxfQ1JTmow0CR1JMk0wAC2hLxo4S2kYOrGTQ3Al8wxe0cGnWMgQ36
USAi6wNSGN98FeLzWqWJ90vrUQtdXuDp5N3+2VDqh2hT8sZOMdhVY3GGqzjGqdEe
a1bYGTPt2VGRGR0wycEg5cG/d+d9tAeaZldkg8AGULD8MMOC2RBd+p1aWiKpuoHq
sWhsxv/2EBi4i8yTaDs9
=MRmB
-----END PGP SIGNATURE-----
Merge tag 'pm-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These fix a cpufreq core issue with the initialization of the cpufreq
sysfs interface and a cpuidle powernv driver initialization issue.
Specifics:
- symbolic links from CPU directories to the corresponding cpufreq
policy directories in sysfs are not created during initialization
in some cases which confuses user space, so prevent that from
happening (Rafael Wysocki).
- the powernv cpuidle driver fails to pass a correct cpumaks to the
cpuidle core in some cases which causes subsequent failures to
occur, so fix it (Vaidyanathan Srinivasan)"
* tag 'pm-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpuidle: powernv: Pass correct drv->cpumask for registration
cpufreq: Fix creation of symbolic links to policy directories
Pull i2c fixes from Wolfram Sang:
"Two bugfixes from I2C, specifically the I2C mux section. Thanks to
peda for collecting them"
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: mux: pca954x: Add missing pca9546 definition to chip_desc
Revert "i2c: mux: pca954x: Add ACPI support for pca954x"
- reading clk from driver vs. device tree [Vlad]
- Fix support for UIO in VDK platform [Alexey]
- SLC busy bit reading workaround
- build warning with kprobes header reorg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJY3r+cAAoJEGnX8d3iisJesXoQAMhFRHo4UBSADAPRzuzUeI0S
6DzYsJo1P9FIaJjdMBBkLQ1SXN2mLY8rr/NgXVljyNb/7iMe8lkwzqtg3wVXaz/U
VihnpzMMgJqoHy3DXv0F4dxAtPsLhkCbjhq971CdVbuOZT16qxXbBzCRLyrTjSpc
4gpnzSf75nJQMzdcYMWv27J93F1LJKo0FpBP6laVn2h3fQOufhpCYGZn+1bUez1r
3tfpekkrRO1ilT6ldMLvXtBrVyIKd/o3eWPQ0AKNjOY0bXhZ/6NyUo2T6zrqkihx
FHzynLLAg9FBZB/3d2uyJRGKaeJ+vDXK+yNjvT7ive+Wt1Mc+HcHdozzZv/lLnqS
odo1ZkTSM3Pr6bEL3Ez0HwggWD6C4ZNhNPz/+0VHp/vRVCYwtyrZiRGVr6B7iCic
U8wxb5TrYET2tbYyRPd094HxMCVJqGfkUm1lm2NLaO7xJEnUI+Waxd4TDg2YvWqe
uz97odL163vO8niwmP0CA1sh1DqPcxfpUlKCj+wz1m+TqbJbhlSlljyNWlzaTb4r
3werK0RwnpDfuRtDOZoJIJfUlBCHedF1G3jfiqKRXtT/74WOEnsoOrJJ0W+JJO4O
gQY5dwHIeirt0hekYkqoiZf47vJp/hVfHFqU3Kc0R+ij7R9+6UzQ9TNmCcwN9LoM
3Nsf7AouaAf9+hG7KGvI
=MIWw
-----END PGP SIGNATURE-----
Merge tag 'arc-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
Pull ARC fixes from Vineet Gupta:
"Accumulated fixes for ARC which I've been been sitting on for a while:
- reading clk from driver vs device tree [Vlad]
- fix support for UIO in VDK platform [Alexey]
- SLC busy bit reading workaround
- build warning with kprobes header reorg"
* tag 'arc-4.11-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARC: fix build warnings with !CONFIG_KPROBES
ARCv2: SLC: Make sure busy bit is set properly on SLC flushing
ARC: vdk: Fix support of UIO
ARCv2: make unimplemented vectors as no-ops rather than halt core
ARC: get rate from clk driver instead of reading device tree
ARC: [dts] add cpu nodes to ARCHS SMP device tree
ARC: [dts] add input clocks for cpu nodes
backchannel; fix. Also some minor refinements to the nfsd
version-setting interface that we'd like to get fixed before release.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJY3weFAAoJECebzXlCjuG+fQYQAKh7QVB/vDZwvjWZ7OGSBhoe
LJfS1mzzf52MfQk6qNEM9to86qu+ywmH4XD2rvgMdif6Kc0qF1xBzzVEnp527lVW
nt1nLq/oIXeRl7a+5p+FxTnqHn0OBH+iCnxcVZI8tvHgptpR+6TwEzR36k4n4esN
kvNrrv9dFIoBGx0nSBScHTC3zNArU+C9oZTTHAuPJICNBHsOMqYF7sSAXPg9NFR+
HnowZfGWWXpSnWZ9DaM14Zb/dX0B9Pexv1MsgfiKYS9Beh7g4JN48+CHtWyVliwd
M/LVBpT2ZwFM/NzvJ2exVIqm/hwj4El2Sjy67XHwQzDvGjnUn/fz55SfXfzZSMyD
PMj+IeHKuT3jipNui1AXAlzYEz8gPvuKQ0vQ0vVuNX4Ln28KydGwvVTkUNltDnfq
E7L7RI6mj03OY1j1p6zeK6UJeueZq1gmjfq1NVTPO+TgQFPhh8A50NsDEVcaiwNN
W8uX7Qa39y79BT+4OFuYL05AbuqxKR+nAmCbVSLy9Kq4sc/6/YErBZtXXAghzPPl
4Es4tzlAd8skkxWlcVeCeUqPfcDCqHL6xKqa62m5wUuYXmqPtIMyAyVutF4lWpH/
dAV5Lcjz7HeQnpCgFZXXtIQW5OIIfFa08s0f7fuFm+uxz+nM/x8gg99tuwWP6OsT
Za7EtdB84M1ZGgjO3JhY
=oi0+
-----END PGP SIGNATURE-----
Merge tag 'nfsd-4.11-1' of git://linux-nfs.org/~bfields/linux
Pull nfsd fixes from Bruce Fields:
"The restriction of NFSv4 to TCP went overboard and also broke the
backchannel; fix.
Also some minor refinements to the nfsd version-setting interface that
we'd like to get fixed before release"
* tag 'nfsd-4.11-1' of git://linux-nfs.org/~bfields/linux:
svcrdma: set XPT_CONG_CTRL flag for bc xprt
NFSD: fix nfsd_reset_versions for NFSv4.
NFSD: fix nfsd_minorversion(.., NFSD_AVAIL)
NFSD: further refinement of content of /proc/fs/nfsd/versions
nfsd: map the ENOKEY to nfserr_perm for avoiding warning
SUNRPC/backchanel: set XPT_CONG_CTRL flag for bc xprt
