>> net/rds/send.c:1109:42: warning: Using plain integer as NULL pointer
Fixes: ea010070d0 ("net/rds: fix warn in rds_message_alloc_sgs")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A last-minute fix for a test build.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJcGtMtAAoJECgfDbjSjVRpps4H/27UFb1IcPR2AVITTk8BTZA0
eBPxr7d3JoaVLUXkxi4tju3kJ8dI1bqrfJQkmAfa26esw6q5CDau1G7m34UdUqY3
kJMJ0Ce+HOdsSVC7a4PlT9UjgaCkIIi2X+uahAigshvJwumBYISnj2dt37SoDlTg
lIBwWfwNdSkmoEc4bJ9s26xyAnBXRSgz0CQlvhzZthHtorfzkaoL3P1/o7BznHqR
rMIzge7S3E/hN4sRK15DJ5y/QNVKKSiuy2uFxQuLft3sQdEndM+GUnEMrvqlRvUu
iSCdquAXkk08Ok7pINkMGcQ3TE5JPl+Q8BPGzK/a8Aiqsty13jcUjReMySvezrI=
=ik55
-----END PGP SIGNATURE-----
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio fix from Michael Tsirkin:
"A last-minute fix for a test build"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
virtio: fix test build after uio.h change
Bugfixes:
- Fix TCP socket disconnection races by ensuring we always call
xprt_disconnect_done() after releasing the socket.
- Fix a race when clearing both XPRT_CONNECTING and XPRT_LOCKED
- Remove xprt_connect_status() so it does not mask errors that should
be handled by call_connect_status()
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcGnQMAAoJEA4mA3inWBJc3OIP/iRGQeEKuJrGxarssdzIXrqZ
ID6t6XuYxuh6nknS3PAvn1TpAPGFRcTya5MIjvMEMCknH4tQVmD7S2v2vOlx395E
5Cg5Q6FX1dj3i2/flzS1YcByQonUrkJuuMZ36bRJ5uCGjXdryhgC1YNcsq3HXAiA
G/O4W+BpvxLC9z3KGwWz2+v5K4gnIh9sypSye8qsQdrgDlFDo88jWH57gtxQTVjv
13vke64pv/bm97EfZ8gfZprcwLegQ3JJsmcoOfwnh2jRd2i5j4S/xmCLaTjOn9Fg
8fgev7klAzO/39gNV+syGKXVwgOh6mKk5PifDYv986ghvzamPmVT+chIpjgXKSJp
KOpGXY/547KFHWwMQVsmNI+5RPC7FTwDkTwXuOVcmtVyNiJgpveX45pQS8kwRYxq
kZXk/t1T1lXbsBPd0S+1KDjUUPd9DjSm3T3CZKvvfJBbH+ITV2gol2eqneizgxDo
JLBdNFRVTPnud7IEdXiXgjMzl8aFAZsPkXfUmqWPEMtiTn5izSUbXxa04KYgHQpI
GAAMVAZttl6cYoRkPIVIbQLbpY4LsBxA9iTTR39SGINLYiFQBFUNkP02OR+HaD4l
bzY8n5Li1/WekxHagq6RFt+ajBgXSPeCXS3WqigEMc0Xw58u/3Td+0DuRIABmhhr
IJDorHWizxgh2VseZkUB
=+M4X
-----END PGP SIGNATURE-----
Merge tag 'nfs-for-4.20-6' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
Pull NFS client bugfixes from Trond Myklebust:
- Fix TCP socket disconnection races by ensuring we always call
xprt_disconnect_done() after releasing the socket.
- Fix a race when clearing both XPRT_CONNECTING and XPRT_LOCKED
- Remove xprt_connect_status() so it does not mask errors that should
be handled by call_connect_status()
* tag 'nfs-for-4.20-6' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
SUNRPC: Remove xprt_connect_status()
SUNRPC: Fix a race with XPRT_CONNECTING
SUNRPC: Fix disconnection races
* A less nasty use-after-free that can only zero some words at
the beginning of the page, and hence is not really exploitable
* A NULL pointer dereference
* A dummy implementation of an AMD chicken bit MSR that Windows uses
for some unknown reason
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJcGWZUAAoJEL/70l94x66DhecIAKhyarwvQ1HyKUCmeeVAuQHi
8RW8iisiCAQdhtrzjrOjt025gYskeuKItw0V/ipg0orgTTgti4TRoJpfDpZV+550
2EHT2UyUNCjSUwwtUNJ60ky+GRyFCgY8kdqiMTqFmFnpbK/TWY7jx7jtPToRQron
tL1H0RCeYJlPThK/UM7i3UIvS5oVIZ8YOJ18PVcKCoiynrbPk7wgw3it5OdiO2bS
VnI5JMfNy4YIXPc6QqdcKmsLqtinHxVObg+0PnLFtaI6xUqzTzEa12toZxsc9Sf3
rHyYhpNO8kaTw2inLpvbgLX3TZbw5DckHEoOn+s4e5Q193HGTjsTfG9P9oph2hA=
=VQE8
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
- One nasty use-after-free bugfix, from this merge window however
- A less nasty use-after-free that can only zero some words at the
beginning of the page, and hence is not really exploitable
- A NULL pointer dereference
- A dummy implementation of an AMD chicken bit MSR that Windows uses
for some unknown reason
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
kvm: x86: Add AMD's EX_CFG to the list of ignored MSRs
KVM: X86: Fix NULL deref in vcpu_scan_ioapic
KVM: Fix UAF in nested posted interrupt processing
KVM: fix unregistering coalesced mmio zone from wrong bus
Fix a regression in dma-direct that didn't take account the magic AMD
memory encryption mask in the DMA address.
-----BEGIN PGP SIGNATURE-----
iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAlwaVAULHGhjaEBsc3Qu
ZGUACgkQD55TZVIEUYOY4A/9FYHCK486kbEA1df8DxLT6Hz0U6NU9fxgOBMb347K
uQdmdRB8oR3+aaWnohdr6/qT2oAEn3HM9db4L+eu4D28Fxjfv9Pn0QwjFnAUKGKS
90ZvmE8FxHOZydR0l3glHgSxuK+aKGs4Qv6Im5vDWkzwVfMqN0WDbBUfbNbG4nsh
spkdRnx32orstPpUkqbr/26iUAFk9TI3tvg7QDgL88cFArwCBW5ZTmznCnbFeGoz
TxptRFzDYslWZJYAgKWJ9VQ1sCRyZeMD6maoHsFZNL+XQiZ9/WzLN8GZm8/Tn7sP
Rcc8D0qkNqcZbUFku2n1r2Z9iHjB3+fI87zdaarSytB5mhHNkpES5boC2ExTjXTu
QsQt33zbrJXO+8F/571u3k5n8QkkazmYewtviGnNpGq2AofinSOU4BsKxQePI00l
gN3FjVpFyvgxzRdxp4kpa3UfRFOp61zWqVYZYzGrH8Au99t4ineD+iY1ztd0Z2mH
23zjAfnCjGF8VOBNi9vxQFeNLlZoWCCuShENePJ76Bm6lBNjPT1O2Tilc+pbBs2A
RJPoUgMCSfZ+RHyS3ohKM/LLJaX1wEQHYTXa6FyskvOWa9vD4bXJ4kNwc5LY7SyK
i+KAnEierBxvtRMzo5uu9DJXaJZx1Cw711/2IAPkmXUMDld5rwsrdEbgqDD2mlD8
6l0=
=EybB
-----END PGP SIGNATURE-----
Merge tag 'dma-mapping-4.20-4' of git://git.infradead.org/users/hch/dma-mapping
Pull dma-mapping fix from Christoph Hellwig:
"Fix a regression in dma-direct that didn't take account the magic AMD
memory encryption mask in the DMA address"
* tag 'dma-mapping-4.20-4' of git://git.infradead.org/users/hch/dma-mapping:
dma-direct: do not include SME mask in the DMA supported check
When dumping proxy entries the dump request has NTF_PROXY set in
ndm_flags. strict mode checking needs to be updated to allow this
flag.
Fixes: 51183d233b ("net/neighbor: Update neigh_dump_info for strict data checking")
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The mvpp2_phylink_validate() sets all modes that are supported by a
given PPv2 port. An mistake made the 10000baseT_Full mode being
advertised in some cases when a port wasn't configured to perform at
10G. This patch fixes this.
Fixes: d97c9f4ab0 ("net: mvpp2: 1000baseX support")
Reported-by: Russell King <linux@armlinux.org.uk>
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When replacing a rule we add the new rule to the rhashtable
but only remove the old if not in skip_sw.
This commit fix this and remove the old rule anyway.
Fixes: 35cc3cefc4 ("net/sched: cls_flower: Reject duplicated rules also under skip_sw")
Signed-off-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ip l add dev tun type gretap external
ip r a 10.0.0.1 encap ip dst 192.168.152.171 id 1000 dev gretap
For gretap Key example when the command set the id but don't set the
TUNNEL_KEY flags. There is no key field in the send packet
In the lwtunnel situation, some TUNNEL_FLAGS should can be set by
userspace
Signed-off-by: wenxu <wenxu@ucloud.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
The MAC Reset was noticed to erase important EEPROM settings.
It is also unnecessary since a chip wide reset was done earlier
in initialization, and that reset preserves EEPROM settings.
There for this patch removes the unnecessary MAC specific reset.
Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some fixes for the mlx5 driver
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJcGrikAAoJEEg/ir3gV/o+tSEH/A6192OXs+B6phGdMr6GyhbK
nzw6bkJfjHLMDj00F+9qLYYQbqfG1QjDYZnthPCezD9Kv0thFuP8cvSSY1S6SsJq
uMwlHwYQ4ljZvl49pkwiiKMufWGcuVYf+NiEmvrYVWXugej1wENe1xiTS9V3OCAA
j9gQA7gYeEwveOLWLakwzbfvLJ+fyUkLDjB1EJPOzh2fnfkGl8Z8LovAmoXOywdn
PdMh9xAlqovJyY9kS4vaj/1WDCO9+rUfGHXDLjjzG5ygsfipyb8xSdzsY9WgriMu
NKgg1VpEjc9egalT9qqznUE7ilfBUvW++Yc0wsrH+Cme3Rj322L3Es+j5fduKGo=
=YiD1
-----END PGP SIGNATURE-----
Merge tag 'mlx5-fixes-2018-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5-fixes-2018-12-19
Some fixes for the mlx5 driver
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Expression terminated with "," instead of ";", resulted in
set_fte getting bad value for modify_enable_mask field.
Fixes: bd5251dbf1 ("net/mlx5_core: Introduce flow steering destination of type counter")
Signed-off-by: Yuval Avnery <yuvalav@mellanox.com>
Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
When the completion queue of the RQ is empty, do not immediately return.
If left-over decompressed CQEs (from the previous cycle) were processed,
need to go to the finalization part of the poll function.
Bug exists only when CQE compression is turned ON.
This solves the following issue:
mlx5_core 0000:82:00.1: mlx5_eq_int:544:(pid 0): CQ error on CQN 0xc08, syndrome 0x1
mlx5_core 0000:82:00.1 p4p2: mlx5e_cq_error_event: cqn=0x000c08 event=0x04
Fixes: 4b7dfc9925 ("net/mlx5e: Early-return on empty completion queues")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Recent optimizations in MMU code broke nested SVM with NPT in L1
completely: when we do nested_svm_{,un}init_mmu_context() we want
to switch from TDP MMU to shadow MMU, both init_kvm_tdp_mmu() and
kvm_init_shadow_mmu() check if re-configuration is needed by looking
at cache source data. The data, however, doesn't change - it's only
the type of the MMU which changes. We end up not re-initializing
guest MMU as shadow and everything goes off the rails.
The issue could have been fixed by putting MMU type into extended MMU
role but this is not really needed. We can just split root and guest MMUs
the exact same way we did for nVMX, their types never change in the
lifetime of a vCPU.
There is still room for improvement: currently, we reset all MMU roots
when switching from L1 to L2 and back and this is not needed.
Fixes: 7dcd575520 ("x86/kvm/mmu: check if tdp/shadow MMU reconfiguration is needed")
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
syzbot reported the use of uninitialized udp6_addr::sin6_scope_id.
We can just set ::sin6_scope_id to zero, as tunnels are unlikely
to use an IPv6 address that needs a scope id and there is no
interface to bind in this context.
For net-next, it looks different as we have cfg->bind_ifindex there
so we can probably call ipv6_iface_scope_id().
Same for ::sin6_flowinfo, tunnels don't use it.
Fixes: 8024e02879 ("udp: Add udp_sock_create for UDP tunnels to open listener socket")
Reported-by: syzbot+c56449ed3652e6720f30@syzkaller.appspotmail.com
Cc: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current code has 2 problems. It assumes that the RX ring for
the loopback packet is combined with the TX ring. This is not
true if the ethtool channels are set to non-combined mode. The
second problem is that it won't work on 57500 chips without
adjusting the logic to get the proper completion ring (cpr) pointer.
Fix both issues by locating the proper cpr pointer through the RX
ring.
Fixes: e44758b78a ("bnxt_en: Use bnxt_cp_ring_info struct pointer as parameter for RX path.")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Shamir Rabinovitch says:
====================
WARNING in rds_message_alloc_sgs
This patch set fix google syzbot rds bug found in linux-next.
The first patch solve the syzbot issue.
The second patch fix issue mentioned by Leon Romanovsky that
drivers should not call WARN_ON as result from user input.
syzbot bug report can be foud here: https://lkml.org/lkml/2018/10/31/28
v1->v2:
- patch 1: make rds_iov_vector fields name more descriptive (Hakon)
- patch 1: fix potential mem leak in rds_rm_size if krealloc fail
(Hakon)
v2->v3:
- patch 2: harden rds_sendmsg for invalid number of sgs (Gerd)
v3->v4
- Santosh a.b. on both patches + repost to net-dev
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
per comment from Leon in rdma mailing list
https://lkml.org/lkml/2018/10/31/312 :
Please don't forget to remove user triggered WARN_ON.
https://lwn.net/Articles/769365/
"Greg Kroah-Hartman raised the problem of core kernel API code that will
use WARN_ON_ONCE() to complain about bad usage; that will not generate
the desired result if WARN_ON_ONCE() is configured to crash the machine.
He was told that the code should just call pr_warn() instead, and that
the called function should return an error in such situations. It was
generally agreed that any WARN_ON() or WARN_ON_ONCE() calls that can be
triggered from user space need to be fixed."
in addition harden rds_sendmsg to detect and overcome issues with
invalid sg count and fail the sendmsg.
Suggested-by: Leon Romanovsky <leon@kernel.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: shamir rabinovitch <shamir.rabinovitch@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Last set of fixes for 4.20. All (except the mt76 fix) of these are
important fixes to user reported problems and pretty small in size.
rtlwifi
* fix skb leak
mwifiex
* revert a commit from v4.19 due to problems with locking
mt76
* fix a potential NULL derenfence
* add entry to MAINTAINERS
iwlwifi
* fix a firmware crash which was a regression introduced in v4.20-rc4
ath10k
* fix a firmware crash with wcn3990 firmware
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJcGlNvAAoJEG4XJFUm622boJ0H/AjDASkdxSG4n+s1wCmsUizE
jK9YwS2dOc1oVSzGPm35GccFgkc4x1IpS1qoTo1rykVD7Cn6G7mj6eqy8vTiJ24S
6HPhdkS5YynWvYfbQmuhhhaQ6ew8/dJzqhPJAH1/kPfDsy08qUaVl5tGw4CwP4Pp
Ufvrn8VNmRbrAg9Jq28+xmANNURtKNtHmXI5WWuSvA4LzkdEz2aebG8ynOwTrVW6
f6NHTDeJ5tWrswr0EWGjBbGRfb8TlacOxqzytrFYFuYHH3WiqCQZdsvRBazvryqJ
szrYMlI+bSN4m3ZEAtEWlZYTU1YNPwbRDXc+GYkbDr19YKevHxi+46SvXa36cJM=
=ECaW
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-for-davem-2018-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
wireless-drivers fixes for 4.20
Last set of fixes for 4.20. All (except the mt76 fix) of these are
important fixes to user reported problems and pretty small in size.
rtlwifi
* fix skb leak
mwifiex
* revert a commit from v4.19 due to problems with locking
mt76
* fix a potential NULL derenfence
* add entry to MAINTAINERS
iwlwifi
* fix a firmware crash which was a regression introduced in v4.20-rc4
ath10k
* fix a firmware crash with wcn3990 firmware
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
* fix a memory leak in an error path
* fix TXQs in interface teardown
* free fraglist if we used it internally
before returning SKB
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEH1e1rEeCd0AIMq6MB8qZga/fl8QFAlwaBJAACgkQB8qZga/f
l8QvBg/9ESMGPa4F+AdXfvwlDWHkb3fBuv8E1HAkiDiV3G0eyziOwqIo4mSD49fT
tSM+3AFBe9D97O0Y669qnKrcqSWVpGY31hI2MmxskcwwJ+BVgf9M33GjvHa548Bt
c3DEKVLDIfOfQG9+LySeNNz8kRipqIe11WDjpoHZ1i2LtV/uEGOC+cSAxTRwqxpG
HyjF2GBz24PVz69eGNODQNIWgIkkGCil8b8BCED94jUio015t7H+b3hzWDDC83m1
pJwK/Uq4UkJzpjQykSf9805blB0h7PdXo8CSrNNw9+PnEVcvu+81IqD0q5VfZL1a
CePmM43ud59kx1DtPQ0LB4XSIJX7PPiMskK9ZoPUduDvOsaJU32gFmK/Rvm45Xdt
8mQrZM8EsBLCFq8M/Gk89QadXByItUD8B6jZcJgMEddUOa5QPnCaodTQqqO2I8ky
T76FXRegTOMFeGhr/NrWAw3xxCY8TZqwB4P9F4juoKCa9Wz0b1dbIrD7nx1SajoA
jhb795CTczMKCzFywNIh97fKa2yp0YQO0/EQDOFrbYxEyQozSr+cudU4EBN6B08i
A4rVRAAPTlwfFz5TSr7gvT/JHlsku+kfjFAY1tmSWxLgWxFJb3cc0Uj1ak05bmv4
fdANk9g81U4W/bUBKqmeIIrYW0icXHtGZBLX0Khpcx3KQSH11vw=
=X7vr
-----END PGP SIGNATURE-----
Merge tag 'mac80211-for-davem-2018-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
Just three fixes:
* fix a memory leak in an error path
* fix TXQs in interface teardown
* free fraglist if we used it internally
before returning SKB
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When running the kernel in Fast RAM on Atari:
Ignoring memory chunk at 0x0:0xe00000 before the first chunk
...
Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
Oops: 00000000
Modules linked in:
PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
SR: 2714 SP: (ptrval) a2: 005e3314
d0: 00000000 d1: 0000000a d2: 00000e00 d3: 00000000
d4: 005e1fc0 d5: 0000001a a0: 01000000 a1: 00000000
Process swapper (pid: 0, task=(ptrval))
Frame format=7 eff addr=00000736 ssw=0505 faddr=00000736
wb 1 stat/addr/data: 0000 00000000 00000000
wb 2 stat/addr/data: 0000 00000000 00000000
wb 3 stat/addr/data: 0000 00000736 00000000
push data: 00000000 00000000 00000000 00000000
Stack from 005e1f84:
00000000 0000000a 027d3260 006b5006 00000000 00000000 00000000 00000000
0004f062 0003a220 0069e272 005e1ff8 0000054c 00000000 00e00000 00000000
00000001 00693cd8 027d3260 0004f062 0003a220 00691be6 00000000 00000000
00000000 00000000 00000000 00000000 006b5006 00000000 00690872
Call Trace: [<0004f062>] printk+0x0/0x18
[<0003a220>] parse_args+0x0/0x2d4
[<0069e272>] memblock_virt_alloc_try_nid+0x0/0xa4
[<00693cd8>] mem_init+0xa/0x5c
[<0004f062>] printk+0x0/0x18
[<0003a220>] parse_args+0x0/0x2d4
[<00691be6>] start_kernel+0x1ca/0x462
[<00690872>] _sinittext+0x872/0x11f8
Code: 7a1a eaae 2270 6db0 0061 ef14 2f01 2f03 <96a9> 0736 2203 e589 d681 e78b d6a9 0732 2f03 2f40 0034 4eb9 0069 b8d0 260e 4fef
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill the idle task!
As the kernel must run in the memory chunk with the lowest address,
ST-RAM is ignored, and removed from the m68k_memory[] array.
However, it is not removed from memblock, causing a crash later.
More investigation shows that there are 3 places where memory chunks are
ignored, all after the calls to memblock_add() in m68k_parse_bootinfo(),
and thus causing crashes:
1. On classic m68k CPUs with a MMU, paging_init() ignores all memory
chunks below the first chunk, cfr. above,
2. On Amigas equipped with a Zorro III bus, config_amiga() ignores all
Zorro II memory,
3. If CONFIG_SINGLE_MEMORY_CHUNK=y, m68k_parse_bootinfo() ignores all
but the first memory chunk.
Fix this by moving the calls to memblock_add() from
m68k_parse_bootinfo() to paging_init(), after all ignored memory chunks
have been removed from m68k_memory[].
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Fixes: 1008a11590 ("m68k: switch to MEMBLOCK + NO_BOOTMEM")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
For the same reason as commit 25896d073d ("x86/build: Fix compiler
support check for CONFIG_RETPOLINE"), you cannot put this $(error ...)
into the parse stage of the top Makefile.
Perhaps I'd propose a more sophisticated solution later, but this is
the best I can do for now.
Link: https://lkml.org/lkml/2017/12/25/211
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Reported-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reported-by: Qian Cai <cai@lca.pw>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Qian Cai <cai@lca.pw>
Some servers require that the setinfo matches the exact size,
and in this case compounding changes introduced by
commit c2e0fe3f5a ("cifs: make rmdir() use compounding")
caused us to send 8 bytes (padded length) instead of 1 byte
(the size of the structure). See MS-FSCC section 2.4.11.
Fixing this when we send a SET_INFO command for delete file
disposition, then ends up as an iov of a single byte but this
causes problems with SMB3 and encryption.
To avoid this, instead of creating a one byte iov for the disposition value
and then appending an additional iov with a 7 byte padding we now handle
this as a single 8 byte iov containing both the disposition byte as well as
the padding in one single buffer.
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Acked-by: Paulo Alcantara <palcantara@suse.de>
HL2.0 firmware does not support setting quiet mode. If the host driver sends
the quiet mode setting command to the HL2.0 firmware, it crashes with the below
signature.
fatal error received: err_qdi.c:456:EX:wlan_process:1:WLAN RT:207a:PC=b001b4f0
The quiet mode command support is exposed by the firmware via thermal throttle
wmi service. Enable ath10k thermal support if thermal throttle wmi service bit
is set. 10.x firmware versions support this feature by default, but
unfortunately do not advertise the support via service flags, hence have to
manually set the service flag in ath10k_core_compat_services().
Tested on QCA988X with 10.2.4.70.9-2. Also tested on WCN3990.
Co-developed-by: Govind Singh <govinds@codeaurora.org>
Co-developed-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Govind Singh <govinds@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This reverts commit 5bdcd510c2.
The macro based workarounds for GCC's inlining bugs caused regressions: distcc
and other distro build setups broke, and the fixes are not easy nor will they
solve regressions on already existing installations.
So we are reverting this patch and the 8 followup patches.
What makes this revert easier is that GCC9 will likely include the new 'asm inline'
syntax that makes inlining of assembly blocks a lot more robust.
This is a superior method to any macro based hackeries - and might even be
backported to GCC8, which would make all modern distros get the inlining
fixes as well.
Many thanks to Masahiro Yamada and others for helping sort out these problems.
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Borislav Petkov <bp@alien8.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Richard Biener <rguenther@suse.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Nadav Amit <namit@vmware.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
mac80211 uses the frag list to build AMSDU. When freeing
the skb, it may not be really freed, since someone is still
holding a reference to it.
In that case, when TCP skb is being retransmitted, the
pointer to the frag list is being reused, while the data
in there is no longer valid.
Since we will never get frag list from the network stack,
as mac80211 doesn't advertise the capability, we can safely
free and nullify it before releasing the SKB.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If validate_pae_over_nl80211() were to fail in nl80211_crypto_settings(),
we might leak the 'connkeys' allocation. Fix this.
Fixes: 64bf3d4bc2 ("nl80211: Add CONTROL_PORT_OVER_NL80211 attribute")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Alexei Starovoitov says:
====================
pull-request: bpf 2018-12-18
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) promote bpf_perf_event.h to mandatory UAPI header, from Masahiro.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
clcsock can be released while kernel_accept() references it in TCP
listen worker. Also, clcsock needs to wake up before released if TCP
fallback is used and the clcsock is blocked by accept. Add a lock to
safely release clcsock and call kernel_sock_shutdown() to wake up
clcsock from accept in smc_release().
Reported-by: syzbot+0bf2e01269f1274b4b03@syzkaller.appspotmail.com
Reported-by: syzbot+e3132895630f957306bc@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently variable data0 is not being initialized so a garbage value is
being passed to vxge_hw_vpath_fw_api and this value is being written to
the rts_access_steer_data0 register. There are other occurrances where
data0 is being initialized to zero (e.g. in function
vxge_hw_upgrade_read_version) so I think it makes sense to ensure data0
is initialized likewise to 0.
Detected by CoverityScan, CID#140696 ("Uninitialized scalar variable")
Fixes: 8424e00dfd ("vxge: serialize access to steering control register")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
At least old Xen net backends seem to send frags with no real data
sometimes. In case such a fragment happens to occur with the frag limit
already reached the frontend will BUG currently even if this situation
is easily recoverable.
Modify the BUG_ON() condition accordingly.
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Even though the link is down before entering hibernation,
there is an issue that the network interface always links up after resuming
from hibernation.
If the link is still down before enabling the network interface,
and after resuming from hibernation, the phydev->state is forcibly set
to PHY_UP in mdio_bus_phy_restore(), and the link becomes up.
In suspend sequence, only if the PHY is attached, mdio_bus_phy_suspend()
calls phy_stop_machine(), and mdio_bus_phy_resume() calls
phy_start_machine().
In resume sequence, it's enough to do the same as mdio_bus_phy_resume()
because the state has been preserved.
This patch fixes the issue by calling phy_start_machine() in
mdio_bus_phy_restore() in the same way as mdio_bus_phy_resume().
Fixes: bc87922ff5 ("phy: Move PHY PM operations into phy_device")
Suggested-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Current state for the lan78xx driver does not allow for changing the
MAC address of the interface, without either removing the module (if
you compiled it that way) or rebooting the machine. If you attempt to
change the MAC address, ifconfig will show the new address, however,
the system/interface will not respond to any traffic using that
configuration. A few short-term options to work around this are to
unload the module and reload it with the new MAC address, change the
interface to "promisc", or reboot with the correct configuration to
change the MAC.
This patch enables the ability to change the MAC address via fairly normal means...
ifdown <interface>
modify entry in /etc/network/interfaces OR a similar method
ifup <interface>
Then test via any network communication, such as ICMP requests to gateway.
My only test platform for this patch has been a raspberry pi model 3b+.
Signed-off-by: Jason Martinsen <jasonmartinsen@msn.com>
-----
Signed-off-by: David S. Miller <davem@davemloft.net>
The LAN7431 uses an external phy, and it can be found anywhere in
the phy address space. This patch uses phy address 1 for LAN7430
only. And searches all addresses otherwise.
Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Petr Machata says:
====================
vxlan: Various fixes
This patch set contains three fixes for the vxlan driver.
Patch #1 fixes handling of offload mark on replaced VXLAN FDB entries. A
way to trigger this is to replace the FDB entry with one that can not be
offloaded. A future patch set should make it possible to veto such FDB
changes. However the FDB might still fail to be offloaded due to another
issue, and the offload mark should reflect that.
Patch #2 fixes problems in __vxlan_dev_create() when a call to
rtnl_configure_link() fails. These failures would be tricky to hit on a
real system, the most likely vector is through an error in vxlan_open().
However, with the abovementioned vetoing patchset, vetoing the created
entry would trigger the same problems (and be easier to reproduce).
Patch #3 fixes a problem in vxlan_changelink(). In situations where the
default remote configured in the FDB table (if any) does not exactly
match the remote address configured at the VXLAN device, changing the
remote address breaks the default FDB entry. Patch #4 is then a self
test for this issue.
v3:
- Patch #2:
- Reuse the same errout block for both cleanup paths. Use a bool to
decide whether the unregister_netdevice() call should be made.
v2:
- Drop former patch #3
- Patch #2:
- Delete the default entry before calling unregister_netdevice(). That
takes care of former patch #3, hence tweak the commit message to
mention that problem as well.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a test to exercise the fix from the previous patch.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Default remotes are stored as FDB entries with an Ethernet address of
00:00:00:00:00:00. When a request is made to change a remote address of
a VXLAN device, vxlan_changelink() first deletes the existing default
remote, and then creates a new FDB entry.
This works well as long as the list of default remotes matches exactly
the configuration of a VXLAN remote address. Thus when the VXLAN device
has a remote of X, there should be exactly one default remote FDB entry
X. If the VXLAN device has no remote address, there should be no such
entry.
Besides using "ip link set", it is possible to manipulate the list of
default remotes by using the "bridge fdb". It is therefore easy to break
the above condition. Under such circumstances, the __vxlan_fdb_delete()
call doesn't delete the FDB entry itself, but just one remote. The
following vxlan_fdb_create() then creates a new FDB entry, leading to a
situation where two entries exist for the address 00:00:00:00:00:00,
each with a different subset of default remotes.
An even more obvious breakage rooted in the same cause can be observed
when a remote address is configured for a VXLAN device that did not have
one before. In that case vxlan_changelink() doesn't remove any remote,
and just creates a new FDB entry for the new address:
$ ip link add name vx up type vxlan id 2000 dstport 4789
$ bridge fdb ap dev vx 00:00:00:00:00:00 dst 192.0.2.20 self permanent
$ bridge fdb ap dev vx 00:00:00:00:00:00 dst 192.0.2.30 self permanent
$ ip link set dev vx type vxlan remote 192.0.2.30
$ bridge fdb sh dev vx | grep 00:00:00:00:00:00
00:00:00:00:00:00 dst 192.0.2.30 self permanent <- new entry, 1 rdst
00:00:00:00:00:00 dst 192.0.2.20 self permanent <- orig. entry, 2 rdsts
00:00:00:00:00:00 dst 192.0.2.30 self permanent
To fix this, instead of calling vxlan_fdb_create() directly, defer to
vxlan_fdb_update(). That has logic to handle the duplicates properly.
Additionally, it also handles notifications, so drop that call from
changelink as well.
Fixes: 0241b83673 ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
