nr is indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/drm_ioctl.c:805 drm_ioctl() warn: potential spectre issue 'dev->driver->ioctls' [r]
drivers/gpu/drm/drm_ioctl.c:810 drm_ioctl() warn: potential spectre issue 'drm_ioctls' [r] (local cap)
drivers/gpu/drm/drm_ioctl.c:892 drm_ioctl_flags() warn: potential spectre issue 'drm_ioctls' [r] (local cap)
Fix this by sanitizing nr before using it to index dev->driver->ioctls
and drm_ioctls.
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Cc: [email protected]
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20181220000015.GA18973@embeddedor
>> 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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
A last-minute fix for a test build.
Signed-off-by: Michael S. Tsirkin <[email protected]>
-----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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
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 <[email protected]>
Signed-off-by: Antoine Tenart <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
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 <[email protected]>
Reviewed-by: Vlad Buslov <[email protected]>
Acked-by: Or Gerlitz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
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 <[email protected]>
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 <[email protected]>
Reviewed-by: Daniel Jurgens <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
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 <[email protected]>
Reviewed-by: Eran Ben Elisha <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
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 <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Just two small fixes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJcGgnhAAoJEBF7vIC1phx8kfgP/iiXHJo94IK/rqXbYFGnw259
ehRaWmzXJAdU6G7RgaAqyNkEudOjIoPx9QDe0WRl/vRkAiQ2iejoovGFfa/wDkV4
N4uCKdKJ8U39ixonC7/b90798p+Fgc1MfNHtrsvgjj9d4kjzx6L0Qq9G+8t9EcU+
BJZNuK6L2+AY/o/yysVTCp5yI/Pqf0vtKrtglsGe7Eg1FES8MWR3A0OIeOar5Bcq
uGFIUhEy2tHDNFYSdrmKCF4DGkJ+RmBgAEq/Lp2RqChD00CfVE/pHNZfQHGXmPFA
MuWvUohuhhF7Ly3OrQKNdILqxQkqUov3pNeWSzTb4Awy/GY3F1j9K4ysF4/uQLFr
97kjySVUpK1qhDVVS2lGZp1gOAmjByVfw9j7/Jq+MPDsHmNRISTfbCjdkzyhHxcd
joPS9/StC1r/kFN9pyfDr+S+8KgG4jx5Jk6Jjwt+BOUi2pummP9UcrAfxQd+6QKZ
3s2qrgAbkaJfYXpTqEw0WkxncYsNC+WVL3tmL7IQdBo6C+rPtUPpiSgT4Mbwy9Tk
s7KGX9u33mDuw4vvz3LFZcgcXdM+hItzsHsE/l8PFOea5jqKIvyyuaK9zjGS25b1
VTP/2RckdopTHEy+iFz3tmRzHB2n36U3cEeOCow3/wDzEbJKy2qK7SeIUTuQloyG
ZZChydpdoc3I/5m6ecCc
=GVCX
-----END PGP SIGNATURE-----
Merge tag 'kvm-s390-next-4.21-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD
KVM: s390: Fixes for 4.21
Just two small fixes.
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: [email protected]
Cc: Jon Maloy <[email protected]>
Signed-off-by: Cong Wang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
- Large PUD support for HugeTLB
- Single-stepping fixes
- Improved tracing
- Various timer and vgic fixups
-----BEGIN PGP SIGNATURE-----
iQJJBAABCgAzFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAlwahf0VHG1hcmMuenlu
Z2llckBhcm0uY29tAAoJECPQ0LrRPXpDl3MQAKTJ2+vA1vCln2OiKJLZ0TzsSVFB
EXiJfQ6QghD+BHeXw/XU/4X8sD8NjzIP833RvmAgQ/Gm2BpEY/Fj4CmTKaoA5wfJ
UMEvLUFGWb19d0hbf7AllSXg3FvkpAMVof7zfKIyI7tHem6sWHmyXDiXzEfpX2un
bS3x8OBbdVhHcjCvgc1U6Jbii0KUR8Ac5PJBJny1PWkKHFe8NYf/cX+Ii//FMdCm
7zihQAFOpksVOI7y9wYwpmMeI52vDwesergqBBJXkklsAFAda56a2NuoG6oim3BJ
FH/cavGGfrwcdN6Dh5tkvubfxIL5sKF57ZW0Jpy7MPK7u2Zzr7ZvRBHdvYqE+kp3
+jieKr6t1MVnpYfOOZRZgnTqio3Cp++2GzZr283IH0WjDTnN7hhEWbU6/o8DHSge
H/nDyxSycbUZtrGVAOm6oPoy4hNElvW8S71+rLqXVc46aKs3YheNg5MqkLawRA0q
5U9Lw5Um/IvcjfM8DESpmYnugZV8FkzEcMZ3SQjQRYafXdjq2V2NjSMtl2+dyeDh
KthCujhK0F1KBgw7FocNOwh2M7q6mIjw93HrX30CcT6cu2q+0apty+tjXZapP+dc
l7Tad8iFGzAGvW0i3yNWADXhMGk721YrGmptWZh4M9B8CZr2pPzuB4nUPDMeyMYl
XlgIgVGv24MKDjnW
=SiUI
-----END PGP SIGNATURE-----
Merge tag 'kvmarm-for-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm updates for 4.21
- Large PUD support for HugeTLB
- Single-stepping fixes
- Improved tracing
- Various timer and vgic fixups
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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
This patch does the following:
- align parameter with parenthesis
- fix compile error
If CONFIG_SUSPEND is not set the dummy pm_ops
callbacks are named mcp16502_suspend and mcp16502_resume
instead of mcp16502_suspend_noirq and mcp16502_resume_noirq.
Excerpt from compile log (kbuild test robot):
In file included from include/linux/device.h:23:0,
from include/linux/gpio/driver.h:5,
from include/asm-generic/gpio.h:13,
from include/linux/gpio.h:62,
from drivers/regulator/mcp16502.c:11:
>> drivers/regulator/mcp16502.c:527:32: error: 'mcp16502_suspend_noirq'
undeclared here (not in a function); did you mean 'mcp16502_suspend'?
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mcp16502_suspend_noirq,
>> drivers/regulator/mcp16502.c:528:10: error: 'mcp16502_resume_noirq'
undeclared here (not in a function); did you mean 'mcp16502_suspend_noirq'?
mcp16502_resume_noirq)
vim +527 drivers/regulator/mcp16502.c
524
525 #ifdef CONFIG_PM
526 static const struct dev_pm_ops mcp16502_pm_ops = {
> 527 SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mcp16502_suspend_noirq,
> 528 mcp16502_resume_noirq)
529 };
530 #endif
531 static const struct i2c_device_id mcp16502_i2c_id[] = {
532 { "mcp16502", 0 },
533 { }
534 };
535 MODULE_DEVICE_TABLE(i2c, mcp16502_i2c_id);
536
Signed-off-by: Andrei Stefanescu <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Some interrupt controllers whose interrupts are acked on read will set
the status bits for masked interrupts without changing the state of
the IRQ line.
Some chips have an additional "feature" where if those set bits are
not cleared before unmasking their respective interrupts, the IRQ
line will change the state and we'll interpret this as an interrupt
although it actually fired when it was masked.
Add a new field to the irq chip struct that tells the regmap irq chip
code to always clear the status registers before actually changing the
irq mask values.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Add level active IRQ support to regmap-irq irqchip. Change breaks
existing regmap-irq type setting. Convert the existing drivers which
use regmap-irq with trigger type setting (gpio-max77620) to work
with this new approach. So we do not magically support level-active
IRQs on gpio-max77620 - but add support to the regmap-irq for chips
which support them =)
We do not support distinguishing situation where HW supports rising
and falling edge detection but not both. Separating this would require
inventing yet another flags for IRQ types.
Signed-off-by: Matti Vaittinen <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
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 <[email protected]>
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 <[email protected]>
Acked-by: Santosh Shilimkar <[email protected]>
Signed-off-by: shamir rabinovitch <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Fixes the following sparse warning:
drivers/regulator/act8945a-regulator.c:340:1: warning:
symbol 'act8945a_pm' was not declared. Should it be static?
Fixes: 7482d6ecc6 ("regulator: act8945a-regulator: Implement PM functionalities")
Signed-off-by: Wei Yongjun <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
The common code should not set IRQ type. Read HW defaults to the
cache at startup instead of forcing type to EDGE_BOTH. If
default setting is needed this should be done via normal
mechanisms or by chip specific code if normal mechanisms are not
suitable for some reason. Common regmap-irq code should not have
defaults hard-coded but keep the HW/boot defaults untouched.
Signed-off-by: Matti Vaittinen <[email protected]>
Tested-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
They were missing, and it turns out that we do need them now.
Acked-by: Christoffer Dall <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
32 and 64bit use different symbols to identify the traps.
32bit has a fine grained approach (prefetch abort, data abort and HVC),
while 64bit is pretty happy with just "trap".
This has been fine so far, except that we now need to decode some
of that in tracepoints that are common to both architectures.
Introduce ARM_EXCEPTION_IS_TRAP which abstracts the trap symbols
and make the tracepoint use it.
Acked-by: Christoffer Dall <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Although bit 31 of VTCR_EL2 is RES1, we inadvertently end up setting all
of the upper 32 bits to 1 as well because we define VTCR_EL2_RES1 as
signed, which is sign-extended when assigning to kvm->arch.vtcr.
Lucky for us, the architecture currently treats these upper bits as RES0
so, whilst we've been naughty, we haven't set fire to anything yet.
Cc: <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Christoffer Dall <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
There are two things we need to take care of when we create block
mappings in the stage 2 page tables:
(1) The alignment within a PMD between the host address range and the
guest IPA range must be the same, since otherwise we end up mapping
pages with the wrong offset.
(2) The head and tail of a memory slot may not cover a full block
size, and we have to take care to not map those with block
descriptors, since we could expose memory to the guest that the host
did not intend to expose.
So far, we have been taking care of (1), but not (2), and our commentary
describing (1) was somewhat confusing.
This commit attempts to factor out the checks of both into a common
function, and if we don't pass the check, we won't attempt any PMD
mappings for neither hugetlbfs nor THP.
Note that we used to only check the alignment for THP, not for
hugetlbfs, but as far as I can tell the check needs to be applied to
both scenarios.
Cc: Ralph Palutke <[email protected]>
Cc: Lukas Braun <[email protected]>
Reported-by: Lukas Braun <[email protected]>
Signed-off-by: Christoffer Dall <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
We currently only halt the guest when a vCPU messes with the active
state of an SPI. This is perfectly fine for GICv2, but isn't enough
for GICv3, where all vCPUs can access the state of any other vCPU.
Let's broaden the condition to include any GICv3 interrupt that
has an active state (i.e. all but LPIs).
Cc: [email protected]
Reviewed-by: Christoffer Dall <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
We're pretty blind when it comes to system register tracing,
and rely on the ESR value displayed by kvm_handle_sys, which
isn't much.
Instead, let's add an actual name to the sysreg entries, so that
we can finally print it as we're about to perform the access
itself.
The new tracepoint is conveniently called kvm_sys_access.
Signed-off-by: Marc Zyngier <[email protected]>
vcpu_read_sys_reg should not be modifying the VCPU structure.
Eventually, to handle EL2 sysregs for nested virtualization, we will
call vcpu_read_sys_reg from places that have a const vcpu pointer, which
will complain about the lack of the const modifier on the read path.
Signed-off-by: Christoffer Dall <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
kvm_timer_vcpu_terminate can only be called in two scenarios:
1. As part of cleanup during a failed VCPU create
2. As part of freeing the whole VM (struct kvm refcount == 0)
In the first case, we cannot have programmed any timers or mapped any
IRQs, and therefore we do not have to cancel anything or unmap anything.
In the second case, the VCPU will have gone through kvm_timer_vcpu_put,
which will have canceled the emulated physical timer's hrtimer, and we
do not need to that here as well. We also do not care if the irq is
recorded as mapped or not in the VGIC data structure, because the whole
VM is going away. That leaves us only with having to ensure that we
cancel the bg_timer if we were blocking the last time we called
kvm_timer_vcpu_put().
Signed-off-by: Christoffer Dall <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
The use of a work queue in the hrtimer expire function for the bg_timer
is a leftover from the time when we would inject interrupts when the
bg_timer expired.
Since we are no longer doing that, we can instead call
kvm_vcpu_wake_up() directly from the hrtimer function and remove all
workqueue functionality from the arch timer code.
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Christoffer Dall <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
The kvm_exit tracepoint strangely always reported exits as being IRQs.
This seems to be because either the __print_symbolic or the tracepoint
macros use a variable named idx.
Take this chance to update the fields in the tracepoint to reflect the
concepts in the arm64 architecture that we pass to the tracepoint and
move the exception type table to the same location and header files as
the exits code.
We also clear out the exception code to 0 for IRQ exits (which
translates to UNKNOWN in text) to make it slighyly less confusing to
parse the trace output.
Signed-off-by: Christoffer Dall <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
When checking if there are any pending IRQs for the VM, consider the
active state and priority of the IRQs as well.
Otherwise we could be continuously scheduling a guest hypervisor without
it seeing an IRQ.
Signed-off-by: Christoffer Dall <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
When using the nospec API, it should be taken into account that:
"...if the CPU speculates past the bounds check then
* array_index_nospec() will clamp the index within the range of [0,
* size)."
The above is part of the header for macro array_index_nospec() in
linux/nospec.h
Now, in this particular case, if intid evaluates to exactly VGIC_MAX_SPI
or to exaclty VGIC_MAX_PRIVATE, the array_index_nospec() macro ends up
returning VGIC_MAX_SPI - 1 or VGIC_MAX_PRIVATE - 1 respectively, instead
of VGIC_MAX_SPI or VGIC_MAX_PRIVATE, which, based on the original logic:
/* SGIs and PPIs */
if (intid <= VGIC_MAX_PRIVATE)
return &vcpu->arch.vgic_cpu.private_irqs[intid];
/* SPIs */
if (intid <= VGIC_MAX_SPI)
return &kvm->arch.vgic.spis[intid - VGIC_NR_PRIVATE_IRQS];
are valid values for intid.
Fix this by calling array_index_nospec() macro with VGIC_MAX_PRIVATE + 1
and VGIC_MAX_SPI + 1 as arguments for its parameter size.
Fixes: 41b87599c7 ("KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()")
Cc: [email protected]
Signed-off-by: Gustavo A. R. Silva <[email protected]>
[dropped the SPI part which was fixed separately]
Signed-off-by: Marc Zyngier <[email protected]>
For HDaudio and Skylake drivers, add module parameter "pci_binding"
When pci_binding == 0 (AUTO), the PCI class/subclass info is used to
select drivers based on the presence of the DSP.
pci_binding == 1 (LEGACY) forces the use of the HDAudio legacy driver,
even if the DSP is present.
pci_binding == 2 (ASOC) forces the use of the ASOC driver. The
information on the DSP presence is bypassed.
The value for the module parameter needs to be identical for both
drivers. This parameter is intended as a back-up solution if the
automatic detection fails or when the DSP usage fails. Such cases
should be reported on the alsa-devel mailing list for analysis.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Now that the SST/Skylake driver supports per platform selectors, we
can add logic to automatically select the right driver.
If the Skylake driver is selected for a specific platform, and the DSP
is detected at run-time based on the PCI class/subclass/prog-if
information, the legacy HDaudio driver aborts the probe. This will
result in a single driver probing and remove the need for modprobe
blacklists.
Follow-up patches will add a module parameter to bypass the logic if
this automatic detection fails, or if the Skylake driver is unable to
actually support the platform (firmware authentication, missing
topology file, hardware issue, etc).
The same mechanism will be used to conflicts generated by the same PCI
ID being registered by both legacy HDAuudio and SOF drivers for Intel
platforms. In other words SOF will not require changes to the HDaudio
legacy.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
The SOF implementation does not rely on the hdac_bus library, however
for HDMI and HDaudio codec support it does need to deal with
unsolicited events. Instead of re-inventing the wheel, export this
symbol to reuse this part of the library directly.
Signed-off-by: Keyon Jie <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
System call table generation script must be run to gener-
ate unistd_32.h and syscall_table.h files. This patch will
have changes which will invokes the script.
This patch will generate unistd_32.h and syscall_table.h
files by the syscall table generation script invoked by
sh/Makefile and the generated files against the removed
files must be identical.
The generated uapi header file will be included in uapi/-
asm/unistd.h and generated system call table header file
will be included by kernel/syscall_32.S file.
Signed-off-by: Firoz Khan <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
The system call tables are in different format in all
architecture and it will be difficult to manually add,
modify or delete the syscall table entries in the res-
pective files. To make it easy by keeping a script and
which will generate the uapi header and syscall table
file. This change will also help to unify the implemen-
tation across all architectures.
The system call table generation script is added in
kernel/syscalls directory which contain the scripts to
generate both uapi header file and system call table
files. The syscall.tbl will be input for the scripts.
syscall.tbl contains the list of available system calls
along with system call number and corresponding entry
point. Add a new system call in this architecture will
be possible by adding new entry in the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
syscallhdr.sh and syscalltbl.sh will generate uapi header
unistd_32.h and syscall_table.h files respectively. Both
.sh files will parse the content syscall.tbl to generate
the header and table files. unistd_32.h will be included
by uapi/asm/unistd.h and syscall_table.h is included by
kernel/syscall_32.S - the real system call table.
Please note, this support is only available for 32-bit
kernel, not 64-bit kernel. As I came across the 64-bit
kernel is not active for long time.
ARM, s390 and x86 architecuture does have similar support.
I leverage their implementation to come up with a generic
solution.
Signed-off-by: Firoz Khan <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
