perf db-export:
Adrian Hunter:
- Improvements in how COMM details are exported to databases for
post processing and use in the sql-viewer.py UI.
- Export switch events to the database.
BPF:
Arnaldo Carvalho de Melo:
- Bump rlimit(MEMLOCK) for 'perf test bpf' and 'perf trace', just like
selftests/bpf/bpf_rlimit.h do, which makes errors due to exhaustion of
this limit, which are kinda cryptic (EPERM sometimes) less frequent.
perf version:
Ravi Bangoria:
- Fix segfault due to missing OPT_END(), noticed on PowerPC.
perf vendor events:
Thomas Richter:
- Add JSON files for IBM s/390 machine type 8561.
perf cs-etm (ARM):
YueHaibing:
- Fix two cases of error returns not bing done properly: Invalid ERR_PTR() use
and loss of propagation error codes.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQR2GiIUctdOfX2qHhGyPKLppCJ+JwUCXSzqiQAKCRCyPKLppCJ+
J6E6AQDUJOqIQ9/AU4VnaLejy01N61TswV++EYaHsGlNoau6SQD+L68GifDgGIh1
hbGAg/BannQONcMHk+0qFXD/AonntQA=
=zyDe
-----END PGP SIGNATURE-----
Merge tag 'perf-core-for-mingo-5.3-20190715' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:
perf db-export:
Adrian Hunter:
- Improvements in how COMM details are exported to databases for
post processing and use in the sql-viewer.py UI.
- Export switch events to the database.
BPF:
Arnaldo Carvalho de Melo:
- Bump rlimit(MEMLOCK) for 'perf test bpf' and 'perf trace', just like
selftests/bpf/bpf_rlimit.h do, which makes errors due to exhaustion of
this limit, which are kinda cryptic (EPERM sometimes) less frequent.
perf version:
Ravi Bangoria:
- Fix segfault due to missing OPT_END(), noticed on PowerPC.
perf vendor events:
Thomas Richter:
- Add JSON files for IBM s/390 machine type 8561.
perf cs-etm (ARM):
YueHaibing:
- Fix two cases of error returns not bing done properly: Invalid ERR_PTR() use
and loss of propagation error codes.
Paul reported that l2tp sessions were broken after the commit referenced
in the Fixes tag. Prior to this commit rt6_check returned NULL if the
rt6_info 'from' was NULL - ie., the dst_entry was disconnected from a FIB
entry. Restore that behavior.
Fixes: 93531c6743 ("net/ipv6: separate handling of FIB entries from dst based routes")
Reported-by: Paul Donohue <linux-kernel@PaulSD.com>
Tested-by: Paul Donohue <linux-kernel@PaulSD.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The tipc_msg_validate() function leaves a boolean flag 'validated' in
the validated buffer's control block, to avoid performing this action
more than once. However, at reception of new packets, the position of
this field may already have been set by lower layer protocols, so
that the packet is erroneously perceived as already validated by TIPC.
We fix this by initializing the said field to 'false' before performing
the initial validation.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cong Wang says:
====================
ipv4: relax source validation check for loopback packets
This patchset fixes a corner case when loopback packets get dropped
by rp_filter when we route them from veth to lo. Patch 1 is the fix
and patch 2 provides a simplified test case for this scenario.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a test case to simulate the loopback packet case fixed
in the previous patch.
This test gets passed after the fix:
IPv4 rp_filter tests
TEST: rp_filter passes local packets [ OK ]
TEST: rp_filter passes loopback packets [ OK ]
Cc: David Ahern <dsahern@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In a rare case where we redirect local packets from veth to lo,
these packets fail to pass the source validation when rp_filter
is turned on, as the tracing shows:
<...>-311708 [040] ..s1 7951180.957825: fib_table_lookup: table 254 oif 0 iif 1 src 10.53.180.130 dst 10.53.180.130 tos 0 scope 0 flags 0
<...>-311708 [040] ..s1 7951180.957826: fib_table_lookup_nh: nexthop dev eth0 oif 4 src 10.53.180.130
So, the fib table lookup returns eth0 as the nexthop even though
the packets are local and should be routed to loopback nonetheless,
but they can't pass the dev match check in fib_info_nh_uses_dev()
without this patch.
It should be safe to relax this check for this special case, as
normally packets coming out of loopback device still have skb_dst
so they won't even hit this slow path.
Cc: Julian Anastasov <ja@ssi.bg>
Cc: David Ahern <dsahern@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel says:
====================
mlxsw: Two fixes
This patchset contains two fixes for mlxsw.
Patch #1 from Petr fixes an issue in which DSCP rewrite can occur even
if the egress port was switched to Trust L2 mode where priority mapping
is based on PCP.
Patch #2 fixes a problem where packets can be learned on a non-existing
FID if a tc filter with a redirect action is configured on a bridged
port. The problem and fix are explained in detail in the commit message.
Please consider both patches for 5.2.y
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The switch periodically sends notifications about learned FDB entries.
Among other things, the notification includes the FID (Filtering
Identifier) and the port on which the MAC was learned.
In case the driver does not have the FID defined on the relevant port,
the following error will be periodically generated:
mlxsw_spectrum2 0000:06:00.0 swp32: Failed to find a matching {Port, VID} following FDB notification
This is not supposed to happen under normal conditions, but can happen
if an ingress tc filter with a redirect action is installed on a bridged
port. The redirect action will cause the packet's FID to be changed to
the dummy FID and a learning notification will be emitted with this FID
- which is not defined on the bridged port.
Fix this by having the driver ignore learning notifications generated
with the dummy FID and delete them from the device.
Another option is to chain an ignore action after the redirect action
which will cause the device to disable learning, but this means that we
need to consume another action whenever a redirect action is used. In
addition, the scenario described above is merely a corner case.
Fixes: cedbb8b259 ("mlxsw: spectrum_flower: Set dummy FID before forward action")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reported-by: Alex Kushnarov <alexanderk@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Tested-by: Alex Kushnarov <alexanderk@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Spectrum systems use DSCP rewrite map to update DSCP field in egressing
packets to correspond to priority that the packet has. Whether rewriting
will take place is determined at the point when the packet ingresses the
switch: if the port is in Trust L3 mode, packet priority is determined from
the DSCP map at the port, and DSCP rewrite will happen. If the port is in
Trust L2 mode, 802.1p is used for packet prioritization, and no DSCP
rewrite will happen.
The driver determines the port trust mode based on whether any DSCP
prioritization rules are in effect at given port. If there are any, trust
level is L3, otherwise it's L2. When the last DSCP rule is removed, the
port is switched to trust L2. Under that scenario, if DSCP of a packet
should be rewritten, it should be rewritten to 0.
However, when switching to Trust L2, the driver neglects to also update the
DSCP rewrite map. The last DSCP rule thus remains in effect, and packets
egressing through this port, if they have the right priority, will have
their DSCP set according to this rule.
Fix by first configuring the rewrite map, and only then switching to trust
L2 and bailing out.
Fixes: b2b1dab688 ("mlxsw: spectrum: Support ieee_setapp, ieee_delapp")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Reported-by: Alex Veber <alexve@mellanox.com>
Tested-by: Alex Veber <alexve@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ag71xx uses devm_ioremap_nocache. This fixes usage of an implicit function
Fixes: d51b6ce441 ("net: ethernet: add ag71xx driver")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes a global out-of-bounds read access in the copy_buffer
function of the floppy driver.
The FDDEFPRM ioctl allows one to set the geometry of a disk. The sect
and head fields (unsigned int) of the floppy_drive structure are used to
compute the max_sector (int) in the make_raw_rw_request function. It is
possible to overflow the max_sector. Next, max_sector is passed to the
copy_buffer function and used in one of the memcpy calls.
An unprivileged user could trigger the bug if the device is accessible,
but requires a floppy disk to be inserted.
The patch adds the check for the .sect * .head multiplication for not
overflowing in the set_geometry function.
The bug was found by syzkaller.
Signed-off-by: Denis Efremov <efremov@ispras.ru>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This fixes the invalid pointer dereference in the drive_name function of
the floppy driver.
The native_format field of the struct floppy_drive_params is used as
floppy_type array index in the drive_name function. Thus, the field
should be checked the same way as the autodetect field.
To trigger the bug, one could use a value out of range and set the drive
parameters with the FDSETDRVPRM ioctl. Next, FDGETDRVTYP ioctl should
be used to call the drive_name. A floppy disk is not required to be
inserted.
CAP_SYS_ADMIN is required to call FDSETDRVPRM.
The patch adds the check for a value of the native_format field to be in
the '0 <= x < ARRAY_SIZE(floppy_type)' range of the floppy_type array
indices.
The bug was found by syzkaller.
Signed-off-by: Denis Efremov <efremov@ispras.ru>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This fixes a global out-of-bounds read access in the next_valid_format
function of the floppy driver.
The values from autodetect field of the struct floppy_drive_params are
used as indices for the floppy_type array in the next_valid_format
function 'floppy_type[DP->autodetect[probed_format]].sect'.
To trigger the bug, one could use a value out of range and set the drive
parameters with the FDSETDRVPRM ioctl. A floppy disk is not required to
be inserted.
CAP_SYS_ADMIN is required to call FDSETDRVPRM.
The patch adds the check for values of the autodetect field to be in the
'0 <= x < ARRAY_SIZE(floppy_type)' range of the floppy_type array indices.
The bug was found by syzkaller.
Signed-off-by: Denis Efremov <efremov@ispras.ru>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This fixes a divide by zero error in the setup_format_params function of
the floppy driver.
Two consecutive ioctls can trigger the bug: The first one should set the
drive geometry with such .sect and .rate values for the F_SECT_PER_TRACK
to become zero. Next, the floppy format operation should be called.
A floppy disk is not required to be inserted. An unprivileged user
could trigger the bug if the device is accessible.
The patch checks F_SECT_PER_TRACK for a non-zero value in the
set_geometry function. The proper check should involve a reasonable
upper limit for the .sect and .rate fields, but it could change the
UAPI.
The patch also checks F_SECT_PER_TRACK in the setup_format_params, and
cancels the formatting operation in case of zero.
The bug was found by syzkaller.
Signed-off-by: Denis Efremov <efremov@ispras.ru>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Despite the current efforts to read CR2 before tracing happens there still
exist a number of possible holes:
idtentry page_fault do_page_fault has_error_code=1
call error_entry
TRACE_IRQS_OFF
call trace_hardirqs_off*
#PF // modifies CR2
CALL_enter_from_user_mode
__context_tracking_exit()
trace_user_exit(0)
#PF // modifies CR2
call do_page_fault
address = read_cr2(); /* whoopsie */
And similar for i386.
Fix it by pulling the CR2 read into the entry code, before any of that
stuff gets a chance to run and ruin things.
Reported-by: He Zhe <zhe.he@windriver.com>
Reported-by: Eiichi Tsukata <devel@etsukata.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Cc: bp@alien8.de
Cc: rostedt@goodmis.org
Cc: torvalds@linux-foundation.org
Cc: hpa@zytor.com
Cc: dave.hansen@linux.intel.com
Cc: jgross@suse.com
Cc: joel@joelfernandes.org
Link: https://lkml.kernel.org/r/20190711114336.116812491@infradead.org
Debugged-by: Steven Rostedt <rostedt@goodmis.org>
On parisc the privilege level of a process is stored in the lowest two bits of
the instruction pointers (IAOQ0 and IAOQ1). On Linux we use privilege level 0
for the kernel and privilege level 3 for user-space. So userspace should not be
allowed to modify IAOQ0 or IAOQ1 of a ptraced process to change it's privilege
level to e.g. 0 to try to gain kernel privileges.
This patch prevents such modifications in the regset support functions by
always setting the two lowest bits to one (which relates to privilege level 3
for user-space) if IAOQ0 or IAOQ1 are modified via ptrace regset calls.
Link: https://bugs.gentoo.org/481768
Cc: <stable@vger.kernel.org> # v4.7+
Tested-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
Signed-off-by: Helge Deller <deller@gmx.de>
On parisc the privilege level of a process is stored in the lowest two bits of
the instruction pointers (IAOQ0 and IAOQ1). On Linux we use privilege level 0
for the kernel and privilege level 3 for user-space. So userspace should not be
allowed to modify IAOQ0 or IAOQ1 of a ptraced process to change it's privilege
level to e.g. 0 to try to gain kernel privileges.
This patch prevents such modifications by always setting the two lowest bits to
one (which relates to privilege level 3 for user-space) if IAOQ0 or IAOQ1 are
modified via ptrace calls in the native and compat ptrace paths.
Link: https://bugs.gentoo.org/481768
Reported-by: Jeroen Roovers <jer@gentoo.org>
Cc: <stable@vger.kernel.org>
Tested-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
Signed-off-by: Helge Deller <deller@gmx.de>
For qdisc's that support TC filters and set TCQ_F_CAN_BYPASS,
notably fq_codel, it makes no sense to let packets bypass the TC
filters we setup in any scenario, otherwise our packets steering
policy could not be enforced.
This can be reproduced easily with the following script:
ip li add dev dummy0 type dummy
ifconfig dummy0 up
tc qd add dev dummy0 root fq_codel
tc filter add dev dummy0 parent 8001: protocol arp basic action mirred egress redirect dev lo
tc filter add dev dummy0 parent 8001: protocol ip basic action mirred egress redirect dev lo
ping -I dummy0 192.168.112.1
Without this patch, packets are sent directly to dummy0 without
hitting any of the filters. With this patch, packets are redirected
to loopback as expected.
This fix is not perfect, it only unsets the flag but does not set it back
because we have to save the information somewhere in the qdisc if we
really want that. Note, both fq_codel and sfq clear this flag in their
->bind_tcf() but this is clearly not sufficient when we don't use any
class ID.
Fixes: 23624935e0 ("net_sched: TCQ_F_CAN_BYPASS generalization")
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Provide better naming for ABI, i.e. tell that we have fan boost mode.
The following is an automated git shortlog grouped by driver:
asus:
- Rename "fan mode" to "fan boost mode"
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEqaflIX74DDDzMJJtb7wzTHR8rCgFAl0vSKcACgkQb7wzTHR8
rCg4zhAAloPsy7IHNxJOwISxwhgu3v7unpKOta8V16yUfuakHNwjKQOpj4N8YYE5
ezHsfzhf1jTjH00Bt9VuEpaXGJzWfPkXkH/713grpemSpPfI/hAdSN8lvNaA89EE
3CEE13D+IAFu4LZE71zQmNZy77HGvPGUhSimb7rYy0ggaQVudSVysjHA7OC0sYpD
znon8irvZurcKZxTWpWq8r5wDYTEZMAW20mOl7jpr3iD7f1rkrdZCi5q8+05h12q
7HSjZrLjHQZw/P9PAMHnOeTLzf+Oc4KU83eUpaCIMUKK1vdZzSZDtjjhUUPm2Dm+
klraonqVgorvRanY1cAjVq5RCDkG7kvaI9lbiWHdoRgkShQgOZsjtTsAHzGnEbzT
c5RaSjJ9NUf9GDtoK3MGirirRVwO7SJagmSCc1Myph2cZJDR7KDSPURLxoX8n/U9
fOJkH23vAd+HTuWTTt22pURAdZSq0Eq6yNhdEIaIhHHaS2FUipblKNZrcuUuGFmV
oglpoYrXX3wrXKW5FxAUT/+ZFAlKk8TLSwlecZgLTzrUtIAWsw4X/uY0MgAM/Hkt
qhtHRNLPe0qbL1GMFZUG8Uv2ONXl+gyiuSH2kibvWoZwbjQNnjAUEGZphHGX9zor
bUmtHxCdIGGrxN74DgOPpzFY7Ep41sHeOUraioLhMT4yZEtE1/U=
=ZhHh
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v5.3-2' of git://git.infradead.org/linux-platform-drivers-x86
Pull another x86 platform driver update from Andy Shevchenko:
"Provide better naming for ABI, i.e. tell that we have fan boost mode.
It won't break any ABI, but has to be done now to avoid confusion in
the future"
* tag 'platform-drivers-x86-v5.3-2' of git://git.infradead.org/linux-platform-drivers-x86:
platform/x86: asus: Rename "fan mode" to "fan boost mode"
- Revert a SPIO GPIO fix that didn't fix anything instead created new
problems.
- Remove the EM GPIO irqdomain in a safe manner.
- Fix a memory leak in the gpio quirks.
- Make the DaVinci error path silent on probe deferral.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl0vPEkACgkQQRCzN7AZ
XXOL0g/8DxfjkoyS0+GQDJAx1wANj9xZP5OzDEEpzV8YHZmAK4q8ucyt5jJarO7q
v75T5dpcqudG3oRRwLUzA8qZJBGl/M9T82T3bRu9d3KYZhkOoXp2LkyD3m8prvr6
9bd4mjPzr78ro5EJhHFEFkjhNlpGxcFvmP3wMR1BOGCMlnv975J7RH24hOdu+CWO
/a3CaKpPdWlPDjgclWYql3MNBvSE6M87azOQWSPJhabSmUqFUGzyo4Fk5NLxwHl1
oixBgLXRBJ/rOtuzLW+LFi9iW9N0QvHQgQuEQm7p21+E4T0Bqdv0xADl2ThKFJUj
Vu6gAfYxJt3hvfEW3/Vcd3MsclLCvgYveAX1hHR/OxuZv69fOpM7LkWB6g5MYanG
238SYb13dvzDRYjh6lKiOxGMZSRBA5Bw9jf/03l1b7S3olmsoD4Zuc3mstcGdBrl
qt4eRKCekkP7txbn2i50PLd2hGV0HjO2sNeNXdW8o+qEjDRcxLXiXv+MBDZTeEhJ
RSMOegzyyHVPDKS+0sQAHXHKYqiw9117Fe8swbgHjkTxdtsER8spot7PdKF0Lblu
WU2SXdbltqcufo883LG0Kzgx3xwvt/ncYoUB4gHLfx+sFxPY1wbeOHjOreWJ4QOs
ycd21YiCdZLk9ExrOPQ4NSniXX9bzH2FlovT/bHYMpl75pKa7Ig=
=/5s0
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
- Revert a SPIO GPIO fix that didn't fix anything but instead created
new problems.
- Remove the EM GPIO irqdomain in a safe manner.
- Fix a memory leak in the gpio quirks.
- Make the DaVinci error path silent on probe deferral.
* tag 'gpio-v5.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
Revert "gpio/spi: Fix spi-gpio regression on active high CS"
gpio: em: remove the gpiochip before removing the irq domain
gpiolib: of: fix a memory leak in of_gpio_flags_quirks()
gpio: davinci: silence error prints in case of EPROBE_DEFER
Gerd Rausch says:
====================
net/rds: RDMA fixes
A number of net/rds fixes necessary to make "rds_rdma.ko"
pass some basic Oracle internal tests.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Otherwise, if an IB connection is torn down before "rds_ib_setup_qp"
is called, the value of "ic->i_fastreg_wrs" is still at zero
(as it wasn't initialized by "rds_ib_setup_qp").
Consequently "rds_ib_conn_path_shutdown" will spin forever,
waiting for it to go back to "RDS_IB_DEFAULT_FR_WR",
which of course will never happen as there are no
outstanding work requests.
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since "rds_ib_free_frmr" and "rds_ib_free_frmr_list" simply put
the FRMR memory segments on the "drop_list" or "free_list",
and it is the job of "rds_ib_flush_mr_pool" to reap those entries
by ultimately issuing a "IB_WR_LOCAL_INV" work-request,
we need to trigger and then wait for all those memory segments
attached to a particular connection to be fully released before
we can move on to release the QP, CQ, etc.
So we make "rds_ib_conn_path_shutdown" wait for one more
atomic_t called "i_fastreg_inuse_count" that keeps track of how
many FRWR memory segments are out there marked "FRMR_IS_INUSE"
(and also wake_up rds_ib_ring_empty_wait, as they go away).
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix a bug where fr_state first goes to FRMR_IS_STALE, because of a failure
of operation IB_WR_LOCAL_INV, but then gets set back to "FRMR_IS_FREE"
uncoditionally, even though the operation failed.
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make function "rds_ib_try_reuse_ibmr" return NULL in case
memory region could not be allocated, since callers
simply check if the return value is not NULL.
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In order to:
1) avoid a silly bouncing between "clean_list" and "drop_list"
triggered by function "rds_ib_reg_frmr" as it is releases frmr
regions whose state is not "FRMR_IS_FREE" right away.
2) prevent an invalid access error in a race from a pending
"IB_WR_LOCAL_INV" operation with a teardown ("dma_unmap_sg", "put_page")
and de-registration ("ib_dereg_mr") of the corresponding
memory region.
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Waiting for activity on the "clean_list" to quiesce is no substitute
for proper locking.
We can have multiple threads competing for "llist_del_first"
via "rds_ib_reuse_mr", and a single thread competing
for "llist_del_all" and "llist_del_first" via "rds_ib_flush_mr_pool".
Since "llist_del_first" depends on "list->first->next" not to change
in the midst of the operation, simply waiting for all current calls
to "rds_ib_reuse_mr" to quiesce across all CPUs is woefully inadequate:
By the time "wait_clean_list_grace" is done iterating over all CPUs to see
that there is no concurrent caller to "rds_ib_reuse_mr", a new caller may
have just shown up on the first CPU.
Furthermore, <linux/llist.h> explicitly calls out the need for locking:
* Cases where locking is needed:
* If we have multiple consumers with llist_del_first used in one consumer,
* and llist_del_first or llist_del_all used in other consumers,
* then a lock is needed.
Also, while at it, drop the unused "pool" parameter
from "list_to_llist_nodes".
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the context of FRMR (ib_frmr.c):
Memory regions make it onto the "clean_list" via "rds_ib_flush_mr_pool",
after the memory region has been posted for invalidation via
"rds_ib_post_inv".
At that point in time, "fr_state" may still be in state "FRMR_IS_INUSE",
since the only place where "fr_state" transitions to "FRMR_IS_FREE"
is in "rds_ib_mr_cqe_handler", which is triggered by a tasklet.
So in case we notice that "fr_state != FRMR_IS_FREE" (see below),
we wait for "fr_inv_done" to trigger with a maximum of 10msec.
Then we check again, and only put the memory region onto the drop_list
(via "rds_ib_free_frmr") in case the situation remains unchanged.
This avoids the problem of memory-regions bouncing between "clean_list"
and "drop_list" before they even have a chance to be properly invalidated.
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If NF_NAT is m and NET_ACT_CT is y, build fails:
net/sched/act_ct.o: In function `tcf_ct_act':
act_ct.c:(.text+0x21ac): undefined reference to `nf_ct_nat_ext_add'
act_ct.c:(.text+0x229a): undefined reference to `nf_nat_icmp_reply_translation'
act_ct.c:(.text+0x233a): undefined reference to `nf_nat_setup_info'
act_ct.c:(.text+0x234a): undefined reference to `nf_nat_alloc_null_binding'
act_ct.c:(.text+0x237c): undefined reference to `nf_nat_packet'
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: b57dc7c13e ("net/sched: Introduce action ct")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch removes NULL checks before calling kfree.
fixes below issues reported by coccicheck
net/sctp/sm_make_chunk.c:2586:3-8: WARNING: NULL check before some
freeing functions is not needed.
net/sctp/sm_make_chunk.c:2652:3-8: WARNING: NULL check before some
freeing functions is not needed.
net/sctp/sm_make_chunk.c:2667:3-8: WARNING: NULL check before some
freeing functions is not needed.
net/sctp/sm_make_chunk.c:2684:3-8: WARNING: NULL check before some
freeing functions is not needed.
Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
cfhsi_exit_module() calls unregister_netdev() under rtnl_lock().
but unregister_netdev() internally calls rtnl_lock().
So deadlock would occur.
Fixes: c412540063 ("caif-hsi: Add rtnl support")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This contains support for hardware spinlock TI K3 AM65x and J721E family
of SoCs, support for using hwspinlocks from atomic context and better
error reporting when dealing with hardware disabled in DeviceTree.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAl0uHkobHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3Fm0MP/ibvaJ82nOKumQGrOjom
CAI2U/nf1AWbm3Rhy+u3zVelKpd9iLKjsUj2fF42HBARZWXGfxEJUL7fH50Whp+n
lGDgD5r1vE+wp4aqHycRZJEKWUnKTLA/2ddK9QUfljtvdItZJ1MBoKu/V3nhELZd
wfK7vLVbeSIcK2ChVYFZtNhFRmRRN24K4RzcANzzxNrP7+xzqZuJEwmpKKibeMCN
M/LI0XcE95s4+O3e5mcTOOtEyGqbsNrwOwQquYVOFBNbzKHN2HN/9dPAXHA4/K0y
N8zseMeV52dTtaaK8tNLcY7XNJp8r326TN8N/ufmU8oO+KCj3cx1juBSeS4pze1m
U4+vFS9B8aRdeB6a6+W4ZdJpJVSJvTKDJMSB2vbvXJAQfklrGlaHQRmv+OBoPVMj
vUwWB10hJZMrONfGxN8KwG7wzFx7yIol2u2KmJcSfFVAJVVA/YBaulZDl6jkzyeB
GDrgrGnd7iYGa2LhPVHZ/xwyCb0WsRQMXx2gkNegxwlF+nnfTrNMKUJ9eTps4WUn
o80/khuegIzyieym9SB+f7BCRO1xC26FhcGuHrKJXK2Rfcf6LJv+b1B0Q+hwL8UQ
2DsImsH9VnWV7lIaXvbQh8Fsr361xuxJ2Lm3dszbtfEUuhLSyMuJvhyPO+FPSggZ
C51xGa/x71EqBWvKh2YheJSo
=Dz9r
-----END PGP SIGNATURE-----
Merge tag 'hwlock-v5.3' of git://github.com/andersson/remoteproc
Pull hwspinlock updates from Bjorn Andersson:
"This contains support for hardware spinlock TI K3 AM65x and J721E
family of SoCs, support for using hwspinlocks from atomic context and
better error reporting when dealing with hardware disabled in
DeviceTree"
* tag 'hwlock-v5.3' of git://github.com/andersson/remoteproc:
hwspinlock: add the 'in_atomic' API
hwspinlock: document the hwspinlock 'raw' API
hwspinlock: stm32: implement the relax() ops
hwspinlock: ignore disabled device
hwspinlock/omap: Add a trace during probe
hwspinlock/omap: Add support for TI K3 SoCs
dt-bindings: hwlock: Update OMAP binding for TI K3 SoCs
This adds support for the STM32 remoteproc, additional i.MX platforms
with Cortex M4 remoteprocs and Qualcomm's QCS404 Compute DSP. Initial
support for vendor specific resource table entries and support for
unprocessed Qualcomm firmware files.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAl0uGwsbHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FVhcQALBcuPOo2nBQEiOvgS79
0kVBSdUxw6+mI4EFLfQPeSTtGGrSK5/oZBmYhdv+HEDu6CLG1DS+6PZyCjhqdDsU
xjeTIkfe4RDAwnqlGxqK7OyeslAUe91kr0FDaS0XyajhQ+urI8N9Ou/JQDEZKArl
lpuxGmjWASeIbO3TC/p4OhyOU6yqqlyxlv9x/kJnF+PhDfdK1tezvgmLvCDtnD9y
gtYMzSz9txQCXMJmUaDFeUrMph6/Eo2Zn9rYyen5fDzqAXBys7nfH2fbDcbNK1fy
qgjWDjUxENeoZEuohIFn2Dg3egr6rF9TQQvM4uoAoKlS6+yEvTiE8g122BJxVGd3
BOmWK44hTpV1qAGfTivGOH3g/Q9pxI22a17t1BTxcHIYcmMBxERHAVRQ/wbwXRDp
qEv4HUuvciMSjonf8pW3GuuOny9jeTird5q8e3gTNA/s6aESm/YoynwWF3LmNZBo
XePc5sP4oz9HGJKS/SUu0/H6d1/YqOXOwVBmlTl4L0ErWOpaeGMinJQvSRHb0rL2
BgL8bADxFJGM0ITeIA5CpzZzbbbZSmPqxOBhcU+a/PnRL8zVWJOpSCMLe04vrQNT
9lVXAxmcRZjq80fbfyjqomyaT5N5Yvvv6dIz2AtCnAOEynHLnJq/dd5eX840l3RC
1wXvNF4l0rzYm0yYHr0+oQXQ
=iqXq
-----END PGP SIGNATURE-----
Merge tag 'rproc-v5.3' of git://github.com/andersson/remoteproc
Pull remoteproc updates from Bjorn Andersson:
"This adds support for the STM32 remoteproc, additional i.MX platforms
with Cortex M4 remoteprocs and Qualcomm's QCS404 Compute DSP.
Also initial support for vendor specific resource table entries and
support for unprocessed Qualcomm firmware files"
* tag 'rproc-v5.3' of git://github.com/andersson/remoteproc:
remoteproc: stm32: fix building without ARM SMCC
remoteproc: qcom: q6v5-mss: Fix build error without QCOM_MDT_LOADER
remoteproc: copy parent dma_pfn_offset for vdev
remoteproc: qcom: q6v5-mss: Support loading non-split images
soc: qcom: mdt_loader: Support loading non-split images
remoteproc: stm32: add an ST stm32_rproc driver
dt-bindings: remoteproc: add bindings for stm32 remote processor driver
dt-bindings: stm32: add bindings for ML-AHB interconnect
remoteproc: Use struct_size() helper
remoteproc: add vendor resources handling
remoteproc: imx: Fix typo in "failed"
remoteproc: imx: Broaden the Kconfig selection logic
remoteproc,rpmsg: add missing MAINTAINERS file entries
remoteproc: qcom: qdsp6-adsp: Add support for QCS404 CDSP
dt-bindings: remoteproc: Rename and amend Hexagon v56 binding
If we shut down a process without having destroyed its GWS-using
queues, it is possible that GWS BO will still be in the process
BO list during the gpuvm destruction. This list should be empty
at that time, so we should remove the GWS allocation at the
process uninit point if it is still around.
Signed-off-by: Joseph Greathouse <Joseph.Greathouse@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The register debugfs interface was using the wrong bitmask for vmid
selection for GFX_CNTL.
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Optimization for the socket power calculation is introduced.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Do not halt driver loading on if_version mismatch. As our
driver and FWs are backward compatible.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The interface was used in a confusing way. In profile mode scenario,
the 2nd parameter of the interface was used in a different way from
other scenarios.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
As the lock was already held on the entrance to smu_handle_task.
- V2: lock in small granularity
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
No access before allocation.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fix memory allocation failure check.
- V2: fix one more similar error
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Under memory pressure, buffer moves between RAM to VRAM can
fail when there is no GTT space available. In those cases
amdgpu_bo_move falls back to ttm_bo_move_memcpy, which seems to
succeed, although it doesn't really support non-contiguous or
invisible VRAM. This manifests as VM faults with corrupted page
table entries in KFD eviction stress tests.
Print some helpful messages when lack of GTT space is causing buffer
moves to fail. Check that source and destination memory regions are
supported by ttm_bo_move_memcpy before taking that fallback.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Michael Forney
Thomas Gleixner
David Ahern
Jon Maloy
David S. Miller
Cong Wang
Ido Schimmel
Petr Machata
Rosen Penev
Denis Efremov
Peter Zijlstra
Helge Deller
Linus Torvalds
Gerd Rausch
YueHaibing
Hariprasad Kelam
Taehee Yoo
Joseph Greathouse
Tom St Denis
Evan Quan
Felix Kuehling