Eddie James [Thu, 19 Dec 2019 20:50:06 +0000 (14:50 -0600)]
hwmon: (pmbus/ibm-cffps) Add the VMON property for version 2
Version 2 of the PSU supports reading an auxiliary voltage. Use the
pmbus VMON property and associated virtual register to read it.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/1576788607-13567-3-git-send-email-eajames@linux.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Eddie James [Thu, 19 Dec 2019 20:50:05 +0000 (14:50 -0600)]
hwmon: (pmbus/ibm-cffps) Add new manufacturer debugfs entries
Add support for a number of manufacturer-specific registers in the
debugfs entries, as well as support to read and write the
PMBUS_ON_OFF_CONFIG register through debugfs.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/1576788607-13567-2-git-send-email-eajames@linux.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Fri, 6 Dec 2019 04:26:24 +0000 (20:26 -0800)]
hwmon: (pmbus) Driver for MAX20730, MAX20734, and MAX20743
Add support for Maxim MAX20730, MAX20734, MAX20743 Integrated,
Step-Down Switching Regulators with PMBus support.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Dr. David Alan Gilbert [Wed, 25 Dec 2019 02:32:25 +0000 (02:32 +0000)]
hwmon: (w83627ehf) Now only one intrusion channel
The 2nd intrusion channel was only used on the nct6776
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20191225023225.2785-4-linux@treblig.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Dr. David Alan Gilbert [Wed, 25 Dec 2019 02:32:24 +0000 (02:32 +0000)]
hwmon: (w83627ehf) Remove code not needed after nct677* removal
Now the nct677* are gone, we can clean up some flags that are
always the same now and simplify some code.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20191225023225.2785-3-linux@treblig.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Dr. David Alan Gilbert [Wed, 25 Dec 2019 02:32:23 +0000 (02:32 +0000)]
hwmon: (w83627ehf) remove nct6775 and nct6776 support
The nct6775 and nct6776 are supported by the separate nct6775.c driver,
so remove the code from the w83627ehf driver.
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20191225023225.2785-2-linux@treblig.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Fri, 13 Dec 2019 21:36:36 +0000 (13:36 -0800)]
hwmon: (pmbus) Add MAX20796 to devices supported by generic pmbus driver
MAX20796 is a dual-phase scalable integrated voltage regulator with
PMBus interface.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Chen Zhou [Fri, 13 Dec 2019 01:56:05 +0000 (09:56 +0800)]
hwmon: (w83627ehf) make sensor_dev_attr_##_name variables static
Fix sparse warning:
drivers/hwmon/w83627ehf.c:1202:1: warning:
symbol 'sensor_dev_attr_pwm1_target' was not declared. Should it be static?
and many more similar messages.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Link: https://lore.kernel.org/r/20191213015605.172472-1-chenzhou10@huawei.com
[groeck: Dropped all but one log message from description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Thu, 12 Dec 2019 17:14:34 +0000 (09:14 -0800)]
hwmon: (pmbus) Detect if chip is write protected
If a chip is write protected, we can not change any limits, and we can
not clear status flags. This may be the reason why clearing status flags
is reported to not work for some chips. Detect the condition in the pmbus
core. If the chip is write protected, set limit attributes as read-only,
and set the flag indicating that the status flag should be ignored.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Sat, 23 Nov 2019 19:11:26 +0000 (11:11 -0800)]
hwmon: Driver for MAX31730
MAX31730 is a 3-Channel Remote Temperature Sensor.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Tue, 17 Jul 2018 17:17:19 +0000 (10:17 -0700)]
hwmon: Add support for enable attributes to hwmon core
The hwmon ABI supports enable attributes since commit
fb41a710f84e
("hwmon: Document the sensor enable attribute"), but did not
add support for those attributes to the hwmon core. Do that now.
Since the enable attributes are logically the most important attributes,
they are added as first attribute to the attribute list. Move
hwmon_in_enable from last to first place for consistency.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Dr. David Alan Gilbert [Sun, 24 Nov 2019 20:20:30 +0000 (20:20 +0000)]
hwmon: (w83627ehf) convert to with_info interface
Convert the old hwmon_device_register code to
devm_hwmon_device_register_with_info.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20191124202030.45360-3-linux@treblig.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Jim Wright [Thu, 5 Dec 2019 23:24:11 +0000 (17:24 -0600)]
hwmon: (pmbus/ucd9000) Add support for UCD90320 Power Sequencer
Add support for the UCD90320 chip and its expanded set of GPIO pins.
Signed-off-by: Jim Wright <wrightj@linux.vnet.ibm.com>
Link: https://lore.kernel.org/r/20191205232411.21492-3-wrightj@linux.vnet.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Jim Wright [Thu, 5 Dec 2019 23:24:10 +0000 (17:24 -0600)]
dt-bindings: hwmon/pmbus: Add ti,ucd90320 power sequencer
Document the UCD90320 device tree binding.
Signed-off-by: Jim Wright <wrightj@linux.vnet.ibm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20191205232411.21492-2-wrightj@linux.vnet.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Dr. David Alan Gilbert [Sun, 24 Nov 2019 20:20:29 +0000 (20:20 +0000)]
hwmon: Add intrusion templates
Add templates for intrusion%d_alarm and intrusion%d_beep.
Note, these start at 0.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20191124202030.45360-2-linux@treblig.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cong Wang [Wed, 22 Jan 2020 23:42:02 +0000 (15:42 -0800)]
net_sched: fix datalen for ematch
syzbot reported an out-of-bound access in em_nbyte. As initially
analyzed by Eric, this is because em_nbyte sets its own em->datalen
in em_nbyte_change() other than the one specified by user, but this
value gets overwritten later by its caller tcf_em_validate().
We should leave em->datalen untouched to respect their choices.
I audit all the in-tree ematch users, all of those implement
->change() set em->datalen, so we can just avoid setting it twice
in this case.
Reported-and-tested-by: syzbot+5af9a90dad568aa9f611@syzkaller.appspotmail.com
Reported-by: syzbot+2f07903a5b05e7f36410@syzkaller.appspotmail.com
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Eric Dumazet <eric.dumazet@gmail.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>
David S. Miller [Thu, 23 Jan 2020 20:24:37 +0000 (21:24 +0100)]
Merge branch 'Fixes-for-SONIC-ethernet-driver'
Finn Thain says:
====================
Fixes for SONIC ethernet driver
Various SONIC driver problems have become apparent over the years,
including tx watchdog timeouts, lost packets and duplicated packets.
The problems are mostly caused by bugs in buffer handling, locking and
(re-)initialization code.
This patch series resolves these problems.
This series has been tested on National Semiconductor hardware (macsonic),
qemu-system-m68k (macsonic) and qemu-system-mips64el (jazzsonic).
The emulated dp8393x device used in QEMU also has bugs.
I have fixed the bugs that I know of in a series of patches at,
https://github.com/fthain/qemu/commits/sonic
Changed since v1:
- Minor revisions as described in commit logs.
- Deferred net-next patches.
Changed since v2:
- Minor revisions as described in commit logs.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Prevent tx watchdog timeout
Section 5.5.3.2 of the datasheet says,
If FIFO Underrun, Byte Count Mismatch, Excessive Collision, or
Excessive Deferral (if enabled) errors occur, transmission ceases.
In this situation, the chip asserts a TXER interrupt rather than TXDN.
But the handler for the TXDN is the only way that the transmit queue
gets restarted. Hence, an aborted transmission can result in a watchdog
timeout.
This problem can be reproduced on congested link, as that can result in
excessive transmitter collisions. Another way to reproduce this is with
a FIFO Underrun, which may be caused by DMA latency.
In event of a TXER interrupt, prevent a watchdog timeout by restarting
transmission.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Fix CAM initialization
Section 4.3.1 of the datasheet says,
This bit [TXP] must not be set if a Load CAM operation is in
progress (LCAM is set). The SONIC will lock up if both bits are
set simultaneously.
Testing has shown that the driver sometimes attempts to set LCAM
while TXP is set. Avoid this by waiting for command completion
before and after giving the LCAM command.
After issuing the Load CAM command, poll for !SONIC_CR_LCAM rather than
SONIC_INT_LCD, because the SONIC_CR_TXP bit can't be used until
!SONIC_CR_LCAM.
When in reset mode, take the opportunity to reset the CAM Enable
register.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Fix command register usage
There are several issues relating to command register usage during
chip initialization.
Firstly, the SONIC sometimes comes out of software reset with the
Start Timer bit set. This gets logged as,
macsonic macsonic eth0: sonic_init: status=24, i=101
Avoid this by giving the Stop Timer command earlier than later.
Secondly, the loop that waits for the Read RRA command to complete has
the break condition inverted. That's why the for loop iterates until
its termination condition. Call the helper for this instead.
Finally, give the Receiver Enable command after clearing interrupts,
not before, to avoid the possibility of losing an interrupt.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Quiesce SONIC before re-initializing descriptor memory
Make sure the SONIC's DMA engine is idle before altering the transmit
and receive descriptors. Add a helper for this as it will be needed
again.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Fix receive buffer replenishment
As soon as the driver is finished with a receive buffer it allocs a new
one and overwrites the corresponding RRA entry with a new buffer pointer.
Problem is, the buffer pointer is split across two word-sized registers.
It can't be updated in one atomic store. So this operation races with the
chip while it stores received packets and advances its RRP register.
This could result in memory corruption by a DMA write.
Avoid this problem by adding buffers only at the location given by the
RWP register, in accordance with the National Semiconductor datasheet.
Re-factor this code into separate functions to calculate a RRA pointer
and to update the RWP.
Fixes:
efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Improve receive descriptor status flag check
After sonic_tx_timeout() calls sonic_init(), it can happen that
sonic_rx() will subsequently encounter a receive descriptor with no
flags set. Remove the comment that says that this can't happen.
When giving a receive descriptor to the SONIC, clear the descriptor
status field. That way, any rx descriptor with flags set can only be
a newly received packet.
Don't process a descriptor without the LPKT bit set. The buffer is
still in use by the SONIC.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Avoid needless receive descriptor EOL flag updates
The while loop in sonic_rx() traverses the rx descriptor ring. It stops
when it reaches a descriptor that the SONIC has not used. Each iteration
advances the EOL flag so the SONIC can keep using more descriptors.
Therefore, the while loop has no definite termination condition.
The algorithm described in the National Semiconductor literature is quite
different. It consumes descriptors up to the one with its EOL flag set
(which will also have its "in use" flag set). All freed descriptors are
then returned to the ring at once, by adjusting the EOL flags (and link
pointers).
Adopt the algorithm from datasheet as it's simpler, terminates quickly
and avoids a lot of pointless descriptor EOL flag changes.
Fixes:
efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Fix receive buffer handling
The SONIC can sometimes advance its rx buffer pointer (RRP register)
without advancing its rx descriptor pointer (CRDA register). As a result
the index of the current rx descriptor may not equal that of the current
rx buffer. The driver mistakenly assumes that they are always equal.
This assumption leads to incorrect packet lengths and possible packet
duplication. Avoid this by calling a new function to locate the buffer
corresponding to a given descriptor.
Fixes:
efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Fix interface error stats collection
The tx_aborted_errors statistic should count packets flagged with EXD,
EXC, FU, or BCM bits because those bits denote an aborted transmission.
That corresponds to the bitmask 0x0446, not 0x0642. Use macros for these
constants to avoid mistakes. Better to leave out FIFO Underruns (FU) as
there's a separate counter for that purpose.
Don't lump all these errors in with the general tx_errors counter as
that's used for tx timeout events.
On the rx side, don't count RDE and RBAE interrupts as dropped packets.
These interrupts don't indicate a lost packet, just a lack of resources.
When a lack of resources results in a lost packet, this gets reported
in the rx_missed_errors counter (along with RFO events).
Don't double-count rx_frame_errors and rx_crc_errors.
Don't use the general rx_errors counter for events that already have
special counters.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Use MMIO accessors
The driver accesses descriptor memory which is simultaneously accessed by
the chip, so the compiler must not be allowed to re-order CPU accesses.
sonic_buf_get() used 'volatile' to prevent that. sonic_buf_put() should
have done so too but was overlooked.
Fixes:
efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Clear interrupt flags immediately
The chip can change a packet's descriptor status flags at any time.
However, an active interrupt flag gets cleared rather late. This
allows a race condition that could theoretically lose an interrupt.
Fix this by clearing asserted interrupt flags immediately.
Fixes:
efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Finn Thain [Wed, 22 Jan 2020 22:07:26 +0000 (09:07 +1100)]
net/sonic: Add mutual exclusion for accessing shared state
The netif_stop_queue() call in sonic_send_packet() races with the
netif_wake_queue() call in sonic_interrupt(). This causes issues
like "NETDEV WATCHDOG: eth0 (macsonic): transmit queue 0 timed out".
Fix this by disabling interrupts when accessing tx_skb[] and next_tx.
Update a comment to clarify the synchronization properties.
Fixes:
efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Madalin Bucur [Wed, 22 Jan 2020 14:15:14 +0000 (16:15 +0200)]
net: fsl/fman: rename IF_MODE_XGMII to IF_MODE_10G
As the only 10G PHY interface type defined at the moment the code
was developed was XGMII, although the PHY interface mode used was
not XGMII, XGMII was used in the code to denote 10G. This patch
renames the 10G interface mode to remove the ambiguity.
Signed-off-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Thu, 23 Jan 2020 20:17:13 +0000 (21:17 +0100)]
Merge branch 'net-fsl-fman-address-erratum-
A011043'
Madalin Bucur says:
====================
net: fsl/fman: address erratum
A011043
This addresses a HW erratum on some QorIQ DPAA devices.
MDIO reads to internal PCS registers may result in having
the MDIO_CFG[MDIO_RD_ER] bit set, even when there is no
error and read data (MDIO_DATA[MDIO_DATA]) is correct.
Software may get false read error when reading internal
PCS registers through MDIO. As a workaround, all internal
MDIO accesses should ignore the MDIO_CFG[MDIO_RD_ER] bit.
When the issue was present, one could see such errors
during boot:
mdio_bus
ffe4e5000: Error while reading PHY0 reg at 3.3
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Madalin Bucur [Wed, 22 Jan 2020 13:20:29 +0000 (15:20 +0200)]
net/fsl: treat fsl,erratum-
a011043
When fsl,erratum-
a011043 is set, adjust for erratum
A011043:
MDIO reads to internal PCS registers may result in having
the MDIO_CFG[MDIO_RD_ER] bit set, even when there is no
error and read data (MDIO_DATA[MDIO_DATA]) is correct.
Software may get false read error when reading internal
PCS registers through MDIO. As a workaround, all internal
MDIO accesses should ignore the MDIO_CFG[MDIO_RD_ER] bit.
Signed-off-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Madalin Bucur [Wed, 22 Jan 2020 13:20:28 +0000 (15:20 +0200)]
powerpc/fsl/dts: add fsl,erratum-
a011043
Add fsl,erratum-
a011043 to internal MDIO buses.
Software may get false read error when reading internal
PCS registers through MDIO. As a workaround, all internal
MDIO accesses should ignore the MDIO_CFG[MDIO_RD_ER] bit.
Signed-off-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Madalin Bucur [Wed, 22 Jan 2020 13:20:27 +0000 (15:20 +0200)]
dt-bindings: net: add fsl,erratum-
a011043
Add an entry for erratum
A011043: the MDIO_CFG[MDIO_RD_ER]
bit may be falsely set when reading internal PCS registers.
MDIO reads to internal PCS registers may result in having
the MDIO_CFG[MDIO_RD_ER] bit set, even when there is no
error and read data (MDIO_DATA[MDIO_DATA]) is correct.
Software may get false read error when reading internal
PCS registers through MDIO. As a workaround, all internal
MDIO accesses should ignore the MDIO_CFG[MDIO_RD_ER] bit.
Signed-off-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Manish Chopra [Wed, 22 Jan 2020 09:43:38 +0000 (01:43 -0800)]
qlcnic: Fix CPU soft lockup while collecting firmware dump
Driver while collecting firmware dump takes longer time to
collect/process some of the firmware dump entries/memories.
Bigger capture masks makes it worse as it results in larger
amount of data being collected and results in CPU soft lockup.
Place cond_resched() in some of the driver flows that are
expectedly time consuming to relinquish the CPU to avoid CPU
soft lockup panic.
Signed-off-by: Shahed Shaikh <shshaikh@marvell.com>
Tested-by: Yonggen Xu <Yonggen.Xu@dell.com>
Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Thu, 23 Jan 2020 19:37:19 +0000 (11:37 -0800)]
Merge tag 'xarray-5.5' of git://git.infradead.org/users/willy/linux-dax
Pull XArray fixes from Matthew Wilcox:
"Primarily bugfixes, mostly around handling index wrap-around
correctly.
A couple of doc fixes and adding missing APIs.
I had an oops live on stage at linux.conf.au this year, and it turned
out to be a bug in xas_find() which I can't prove isn't triggerable in
the current codebase. Then in looking for the bug, I spotted two more
bugs.
The bots have had a few days to chew on this with no problems
reported, and it passes the test-suite (which now has more tests to
make sure these problems don't come back)"
* tag 'xarray-5.5' of git://git.infradead.org/users/willy/linux-dax:
XArray: Add xa_for_each_range
XArray: Fix xas_find returning too many entries
XArray: Fix xa_find_after with multi-index entries
XArray: Fix infinite loop with entry at ULONG_MAX
XArray: Add wrappers for nested spinlocks
XArray: Improve documentation of search marks
XArray: Fix xas_pause at ULONG_MAX
Linus Torvalds [Thu, 23 Jan 2020 19:23:37 +0000 (11:23 -0800)]
Merge tag 'trace-v5.5-rc6-2' of git://git./linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
"Various tracing fixes:
- Fix a function comparison warning for a xen trace event macro
- Fix a double perf_event linking to a trace_uprobe_filter for
multiple events
- Fix suspicious RCU warnings in trace event code for using
list_for_each_entry_rcu() when the "_rcu" portion wasn't needed.
- Fix a bug in the histogram code when using the same variable
- Fix a NULL pointer dereference when tracefs lockdown enabled and
calling trace_set_default_clock()
- A fix to a bug found with the double perf_event linking patch"
* tag 'trace-v5.5-rc6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing/uprobe: Fix to make trace_uprobe_filter alignment safe
tracing: Do not set trace clock if tracefs lockdown is in effect
tracing: Fix histogram code when expression has same var as value
tracing: trigger: Replace unneeded RCU-list traversals
tracing/uprobe: Fix double perf_event linking on multiprobe uprobe
tracing: xen: Ordered comparison of function pointers
Linus Torvalds [Thu, 23 Jan 2020 19:21:35 +0000 (11:21 -0800)]
Merge tag 'ceph-for-5.5-rc8' of https://github.com/ceph/ceph-client
Pull ceph fix from Ilya Dryomov:
"A fix for a potential use-after-free from Jeff, marked for stable"
* tag 'ceph-for-5.5-rc8' of https://github.com/ceph/ceph-client:
ceph: hold extra reference to r_parent over life of request
Linus Torvalds [Thu, 23 Jan 2020 19:10:21 +0000 (11:10 -0800)]
Merge tag 'pm-5.5-rc8' of git://git./linux/kernel/git/rafael/linux-pm
Pull power management fix from Rafael Wysocki:
"Prevent the kernel from crashing during resume from hibernation if
free pages contain leftover data from the restore kernel and
init_on_free is set (Alexander Potapenko)"
* tag 'pm-5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
PM: hibernate: fix crashes with init_on_free=1
Linus Torvalds [Thu, 23 Jan 2020 19:08:15 +0000 (11:08 -0800)]
Merge tag 'pci-v5.5-fixes-2' of git://git./linux/kernel/git/helgaas/pci
Pull PCI fix from Bjorn Helgaas:
"Mark ATS as broken on AMD Navi14 GPU rev 0xc5 (Alex Deucher)"
* tag 'pci-v5.5-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: Mark AMD Navi14 GPU rev 0xc5 ATS as broken
Linus Torvalds [Wed, 22 Jan 2020 20:37:25 +0000 (12:37 -0800)]
readdir: make user_access_begin() use the real access range
In commit
9f79b78ef744 ("Convert filldir[64]() from __put_user() to
unsafe_put_user()") I changed filldir to not do individual __put_user()
accesses, but instead use unsafe_put_user() surrounded by the proper
user_access_begin/end() pair.
That make them enormously faster on modern x86, where the STAC/CLAC
games make individual user accesses fairly heavy-weight.
However, the user_access_begin() range was not really the exact right
one, since filldir() has the unfortunate problem that it needs to not
only fill out the new directory entry, it also needs to fix up the
previous one to contain the proper file offset.
It's unfortunate, but the "d_off" field in "struct dirent" is _not_ the
file offset of the directory entry itself - it's the offset of the next
one. So we end up backfilling the offset in the previous entry as we
walk along.
But since x86 didn't really care about the exact range, and used to be
the only architecture that did anything fancy in user_access_begin() to
begin with, the filldir[64]() changes did something lazy, and even
commented on it:
/*
* Note! This range-checks 'previous' (which may be NULL).
* The real range was checked in getdents
*/
if (!user_access_begin(dirent, sizeof(*dirent)))
goto efault;
and it all worked fine.
But now 32-bit ppc is starting to also implement user_access_begin(),
and the fact that we faked the range to only be the (possibly not even
valid) previous directory entry becomes a problem, because ppc32 will
actually be using the range that is passed in for more than just "check
that it's user space".
This is a complete rewrite of Christophe's original patch.
By saving off the record length of the previous entry instead of a
pointer to it in the filldir data structures, we can simplify the range
check and the writing of the previous entry d_off field. No need for
any conditionals in the user accesses themselves, although we retain the
conditional EINTR checking for the "was this the first directory entry"
signal handling latency logic.
Fixes:
9f79b78ef744 ("Convert filldir[64]() from __put_user() to unsafe_put_user()")
Link: https://lore.kernel.org/lkml/a02d3426f93f7eb04960a4d9140902d278cab0bb.1579697910.git.christophe.leroy@c-s.fr/
Link: https://lore.kernel.org/lkml/408c90c4068b00ea8f1c41cca45b84ec23d4946b.1579783936.git.christophe.leroy@c-s.fr/
Reported-and-tested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Thu, 23 Jan 2020 18:05:05 +0000 (10:05 -0800)]
readdir: be more conservative with directory entry names
Commit
8a23eb804ca4 ("Make filldir[64]() verify the directory entry
filename is valid") added some minimal validity checks on the directory
entries passed to filldir[64](). But they really were pretty minimal.
This fleshes out at least the name length check: we used to disallow
zero-length names, but really, negative lengths or oevr-long names
aren't ok either. Both could happen if there is some filesystem
corruption going on.
Now, most filesystems tend to use just an "unsigned char" or similar for
the length of a directory entry name, so even with a corrupt filesystem
you should never see anything odd like that. But since we then use the
name length to create the directory entry record length, let's make sure
it actually is half-way sensible.
Note how POSIX states that the size of a path component is limited by
NAME_MAX, but we actually use PATH_MAX for the check here. That's
because while NAME_MAX is generally the correct maximum name length
(it's 255, for the same old "name length is usually just a byte on
disk"), there's nothing in the VFS layer that really cares.
So the real limitation at a VFS layer is the total pathname length you
can pass as a filename: PATH_MAX.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Alex Deucher [Wed, 22 Jan 2020 16:17:24 +0000 (11:17 -0500)]
drm/amdgpu: remove the experimental flag for renoir
Should work properly with the latest sbios on 5.5 and newer
kernels.
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Raag Jadav [Sun, 19 Jan 2020 11:28:59 +0000 (16:58 +0530)]
ARM: dts: am43x-epos-evm: set data pin directions for spi0 and spi1
Set d0 and d1 pin directions for spi0 and spi1 as per their pinmux.
Signed-off-by: Raag Jadav <raagjadav@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Kristian Evensen [Thu, 23 Jan 2020 12:20:18 +0000 (13:20 +0100)]
fou: Fix IPv6 netlink policy
When submitting v2 of "fou: Support binding FoU socket" (
1713cb37bf67),
I accidentally sent the wrong version of the patch and one fix was
missing. In the initial version of the patch, as well as the version 2
that I submitted, I incorrectly used ".type" for the two V6-attributes.
The correct is to use ".len".
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes:
1713cb37bf67 ("fou: Support binding FoU socket")
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Thu, 23 Jan 2020 13:30:20 +0000 (14:30 +0100)]
Merge tag 'wireless-drivers-2020-01-23' of git://git./linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
wireless-drivers fixes for v5.5
Second set of fixes for v5.5. There are quite a few patches,
especially on iwlwifi, due to me being on a long break. Libertas also
has a security fix and mt76 a build fix.
iwlwifi
* don't send the PPAG command when PPAG is disabled, since it can cause problems
* a few fixes for a HW bug
* a fix for RS offload;
* a fix for 3168 devices where the NVM tables where the wrong tables were being read
* fix a couple of potential memory leaks in TXQ code
* disable L0S states in all hardware since our hardware doesn't
officially support them anymore (and older versions of the hardware
had instability in these states)
* remove lar_disable parameter since it has been causing issues for
some people who erroneously disable it
* force the debug monitor HW to stop also when debug is disabled,
since it sometimes stays on and prevents low system power states
* don't send IWL_MVM_RXQ_NSSN_SYNC notification due to DMA problems
libertas
* fix two buffer overflows
mt76
* build fix related to CONFIG_MT76_LEDS
* fix off by one in bitrates handling
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Wed, 22 Jan 2020 17:07:35 +0000 (09:07 -0800)]
tun: add mutex_unlock() call and napi.skb clearing in tun_get_user()
If both IFF_NAPI_FRAGS mode and XDP are enabled, and the XDP program
consumes the skb, we need to clear the napi.skb (or risk
a use-after-free) and release the mutex (or risk a deadlock)
WARNING: lock held when returning to user space!
5.5.0-rc6-syzkaller #0 Not tainted
------------------------------------------------
syz-executor.0/455 is leaving the kernel with locks still held!
1 lock held by syz-executor.0/455:
#0:
ffff888098f6e748 (&tfile->napi_mutex){+.+.}, at: tun_get_user+0x1604/0x3fc0 drivers/net/tun.c:1835
Fixes:
90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Petar Penkov <ppenkov@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 22 Jan 2020 18:09:52 +0000 (20:09 +0200)]
mlxsw: spectrum_acl: Fix use-after-free during reload
During reload (or module unload), the router block is de-initialized.
Among other things, this results in the removal of a default multicast
route from each active virtual router (VRF). These default routes are
configured during initialization to trap packets to the CPU. In
Spectrum-2, unlike Spectrum-1, multicast routes are implemented using
ACL rules.
Since the router block is de-initialized before the ACL block, it is
possible that the ACL rules corresponding to the default routes are
deleted while being accessed by the ACL delayed work that queries rules'
activity from the device. This can result in a rare use-after-free [1].
Fix this by protecting the rules list accessed by the delayed work with
a lock. We cannot use a spinlock as the activity read operation is
blocking.
[1]
[ 123.331662] ==================================================================
[ 123.339920] BUG: KASAN: use-after-free in mlxsw_sp_acl_rule_activity_update_work+0x330/0x3b0
[ 123.349381] Read of size 8 at addr
ffff8881f3bb4520 by task kworker/0:2/78
[ 123.357080]
[ 123.358773] CPU: 0 PID: 78 Comm: kworker/0:2 Not tainted
5.5.0-rc5-custom-33108-gf5df95d3ef41 #2209
[ 123.368898] Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018
[ 123.378456] Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work
[ 123.385970] Call Trace:
[ 123.388734] dump_stack+0xc6/0x11e
[ 123.392568] print_address_description.constprop.4+0x21/0x340
[ 123.403236] __kasan_report.cold.8+0x76/0xb1
[ 123.414884] kasan_report+0xe/0x20
[ 123.418716] mlxsw_sp_acl_rule_activity_update_work+0x330/0x3b0
[ 123.444034] process_one_work+0xb06/0x19a0
[ 123.453731] worker_thread+0x91/0xe90
[ 123.467348] kthread+0x348/0x410
[ 123.476847] ret_from_fork+0x24/0x30
[ 123.480863]
[ 123.482545] Allocated by task 73:
[ 123.486273] save_stack+0x19/0x80
[ 123.490000] __kasan_kmalloc.constprop.6+0xc1/0xd0
[ 123.495379] mlxsw_sp_acl_rule_create+0xa7/0x230
[ 123.500566] mlxsw_sp2_mr_tcam_route_create+0xf6/0x3e0
[ 123.506334] mlxsw_sp_mr_tcam_route_create+0x5b4/0x820
[ 123.512102] mlxsw_sp_mr_table_create+0x3b5/0x690
[ 123.517389] mlxsw_sp_vr_get+0x289/0x4d0
[ 123.521797] mlxsw_sp_fib_node_get+0xa2/0x990
[ 123.526692] mlxsw_sp_router_fib4_event_work+0x54c/0x2d60
[ 123.532752] process_one_work+0xb06/0x19a0
[ 123.537352] worker_thread+0x91/0xe90
[ 123.541471] kthread+0x348/0x410
[ 123.545103] ret_from_fork+0x24/0x30
[ 123.549113]
[ 123.550795] Freed by task 518:
[ 123.554231] save_stack+0x19/0x80
[ 123.557958] __kasan_slab_free+0x125/0x170
[ 123.562556] kfree+0xd7/0x3a0
[ 123.565895] mlxsw_sp_acl_rule_destroy+0x63/0xd0
[ 123.571081] mlxsw_sp2_mr_tcam_route_destroy+0xd5/0x130
[ 123.576946] mlxsw_sp_mr_tcam_route_destroy+0xba/0x260
[ 123.582714] mlxsw_sp_mr_table_destroy+0x1ab/0x290
[ 123.588091] mlxsw_sp_vr_put+0x1db/0x350
[ 123.592496] mlxsw_sp_fib_node_put+0x298/0x4c0
[ 123.597486] mlxsw_sp_vr_fib_flush+0x15b/0x360
[ 123.602476] mlxsw_sp_router_fib_flush+0xba/0x470
[ 123.607756] mlxsw_sp_vrs_fini+0xaa/0x120
[ 123.612260] mlxsw_sp_router_fini+0x137/0x384
[ 123.617152] mlxsw_sp_fini+0x30a/0x4a0
[ 123.621374] mlxsw_core_bus_device_unregister+0x159/0x600
[ 123.627435] mlxsw_devlink_core_bus_device_reload_down+0x7e/0xb0
[ 123.634176] devlink_reload+0xb4/0x380
[ 123.638391] devlink_nl_cmd_reload+0x610/0x700
[ 123.643382] genl_rcv_msg+0x6a8/0xdc0
[ 123.647497] netlink_rcv_skb+0x134/0x3a0
[ 123.651904] genl_rcv+0x29/0x40
[ 123.655436] netlink_unicast+0x4d4/0x700
[ 123.659843] netlink_sendmsg+0x7c0/0xc70
[ 123.664251] __sys_sendto+0x265/0x3c0
[ 123.668367] __x64_sys_sendto+0xe2/0x1b0
[ 123.672773] do_syscall_64+0xa0/0x530
[ 123.676892] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 123.682552]
[ 123.684238] The buggy address belongs to the object at
ffff8881f3bb4500
[ 123.684238] which belongs to the cache kmalloc-128 of size 128
[ 123.698261] The buggy address is located 32 bytes inside of
[ 123.698261] 128-byte region [
ffff8881f3bb4500,
ffff8881f3bb4580)
[ 123.711303] The buggy address belongs to the page:
[ 123.716682] page:
ffffea0007ceed00 refcount:1 mapcount:0 mapping:
ffff888236403500 index:0x0
[ 123.725958] raw:
0200000000000200 dead000000000100 dead000000000122 ffff888236403500
[ 123.734646] raw:
0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
[ 123.743315] page dumped because: kasan: bad access detected
[ 123.749562]
[ 123.751241] Memory state around the buggy address:
[ 123.756620]
ffff8881f3bb4400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 123.764716]
ffff8881f3bb4480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 123.772812] >
ffff8881f3bb4500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 123.780904] ^
[ 123.785697]
ffff8881f3bb4580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 123.793793]
ffff8881f3bb4600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 123.801883] ==================================================================
Fixes:
cf7221a4f5a5 ("mlxsw: spectrum_router: Add Multicast routing support for Spectrum-2")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Aneesh Kumar K.V [Wed, 8 Jan 2020 05:44:22 +0000 (11:14 +0530)]
powerpc/mm/hash: Fix sharing context ids between kernel & userspace
Commit
0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in
the same 0xc range") has a bug in the definition of MIN_USER_CONTEXT.
The result is that the context id used for the vmemmap and the lowest
context id handed out to userspace are the same. The context id is
essentially the process identifier as far as the first stage of the
MMU translation is concerned.
This can result in multiple SLB entries with the same VSID (Virtual
Segment ID), accessible to the kernel and some random userspace
process that happens to get the overlapping id, which is not expected
eg:
07
c00c000008000000 40066bdea7000500 1T ESID= c00c00 VSID=
66bdea7 LLP:100
12
0002000008000000 40066bdea7000d80 1T ESID= 200 VSID=
66bdea7 LLP:100
Even though the user process and the kernel use the same VSID, the
permissions in the hash page table prevent the user process from
reading or writing to any kernel mappings.
It can also lead to SLB entries with different base page size
encodings (LLP), eg:
05
c00c000008000000 00006bde0053b500 256M ESID=
c00c00000 VSID=
6bde0053b LLP:100
09
0000000008000000 00006bde0053bc80 256M ESID= 0 VSID=
6bde0053b LLP: 0
Such SLB entries can result in machine checks, eg. as seen on a G5:
Oops: Machine check, sig: 7 [#1]
BE PAGE SIZE=64K MU-Hash SMP NR_CPUS=4 NUMA Power Mac
NIP:
c00000000026f248 LR:
c000000000295e58 CTR:
0000000000000000
REGS: c0000000erfd3d70 TRAP: 0200 Tainted: G M (
5.5.0-rcl-gcc-8.2.0-00010-g228b667d8ea1)
MSR:
9000000000109032 <SF,HV,EE,ME,IR,DR,RI> CR:
24282048 XER:
00000000
DAR:
c00c000000612c80 DSISR:
00000400 IRQMASK: 0
...
NIP [
c00000000026f248] .kmem_cache_free+0x58/0x140
LR [
c088000008295e58] .putname 8x88/0xa
Call Trace:
.putname+0xB8/0xa
.filename_lookup.part.76+0xbe/0x160
.do_faccessat+0xe0/0x380
system_call+0x5c/ex68
This happens with 256MB segments and 64K pages, as the duplicate VSID
is hit with the first vmemmap segment and the first user segment, and
older 32-bit userspace maps things in the first user segment.
On other CPUs a machine check is not seen. Instead the userspace
process can get stuck continuously faulting, with the fault never
properly serviced, due to the kernel not understanding that there is
already a HPTE for the address but with inaccessible permissions.
On machines with 1T segments we've not seen the bug hit other than by
deliberately exercising it. That seems to be just a matter of luck
though, due to the typical layout of the user virtual address space
and the ranges of vmemmap that are typically populated.
To fix it we add 2 to MIN_USER_CONTEXT. This ensures the lowest
context given to userspace doesn't overlap with the VMEMMAP context,
or with the context for INVALID_REGION_ID.
Fixes:
0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in the same 0xc range")
Cc: stable@vger.kernel.org # v5.2+
Reported-by: Christian Marillat <marillat@debian.org>
Reported-by: Romain Dolbeau <romain@dolbeau.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
[mpe: Account for INVALID_REGION_ID, mostly rewrite change log]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200123102547.11623-1-mpe@ellerman.id.au
David S. Miller [Thu, 23 Jan 2020 10:20:57 +0000 (11:20 +0100)]
Merge branch 'r8152-serial-fixes'
Hayes Wang says:
====================
r8152: serial fixes
v3:
1. Fix the typos for patch #5 and #6.
2. Modify the commit message of patch #9.
v2:
For patch #2, move declaring the variable "ocp_data".
v1:
These patches are used to fix some issues for RTL8153.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Hayes Wang [Wed, 22 Jan 2020 08:02:13 +0000 (16:02 +0800)]
r8152: disable DelayPhyPwrChg
When enabling this, the device would wait an internal signal which
wouldn't be triggered. Then, the device couldn't enter P3 mode, so
the power consumption is increased.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hayes Wang [Wed, 22 Jan 2020 08:02:12 +0000 (16:02 +0800)]
r8152: avoid the MCU to clear the lanwake
Avoid the MCU to clear the lanwake after suspending. It may cause the
WOL fail. Disable LANWAKE_CLR_EN before suspending. Besides,enable it
and reset the lanwake status when resuming or initializing.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hayes Wang [Wed, 22 Jan 2020 08:02:11 +0000 (16:02 +0800)]
r8152: don't enable U1U2 with USB_SPEED_HIGH for RTL8153B
For certain platforms, it causes USB reset periodically.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hayes Wang [Wed, 22 Jan 2020 08:02:10 +0000 (16:02 +0800)]
r8152: disable test IO for RTL8153B
For RTL8153B with QFN32, disable test IO. Otherwise, it may cause
abnormal behavior for the device randomly.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hayes Wang [Wed, 22 Jan 2020 08:02:09 +0000 (16:02 +0800)]
r8152: Disable PLA MCU clock speed down
PLA MCU clock speed down could only be enabled when tx/rx are disabled.
Otherwise, the packet loss may occur.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hayes Wang [Wed, 22 Jan 2020 08:02:08 +0000 (16:02 +0800)]
r8152: disable U2P3 for RTL8153B
Enable U2P3 may miss zero packet for bulk-in.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hayes Wang [Wed, 22 Jan 2020 08:02:07 +0000 (16:02 +0800)]
r8152: get default setting of WOL before initializing
Initailization would reset runtime suspend by tp->saved_wolopts, so
the tp->saved_wolopts should be set before initializing.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hayes Wang [Wed, 22 Jan 2020 08:02:06 +0000 (16:02 +0800)]
r8152: reset flow control patch when linking on for RTL8153B
When linking ON, the patch of flow control has to be reset. This
makes sure the patch works normally.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hayes Wang [Wed, 22 Jan 2020 08:02:05 +0000 (16:02 +0800)]
r8152: fix runtime resume for linking change
Fix the runtime resume doesn't work normally for linking change.
1. Reset the settings and status of runtime suspend.
2. Sync the linking status.
3. Poll the linking change.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Wed, 22 Jan 2020 07:17:14 +0000 (23:17 -0800)]
gtp: make sure only SOCK_DGRAM UDP sockets are accepted
A malicious user could use RAW sockets and fool
GTP using them as standard SOCK_DGRAM UDP sockets.
BUG: KMSAN: uninit-value in udp_tunnel_encap_enable include/net/udp_tunnel.h:174 [inline]
BUG: KMSAN: uninit-value in setup_udp_tunnel_sock+0x45e/0x6f0 net/ipv4/udp_tunnel.c:85
CPU: 0 PID: 11262 Comm: syz-executor613 Not tainted 5.5.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x220 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
udp_tunnel_encap_enable include/net/udp_tunnel.h:174 [inline]
setup_udp_tunnel_sock+0x45e/0x6f0 net/ipv4/udp_tunnel.c:85
gtp_encap_enable_socket+0x37f/0x5a0 drivers/net/gtp.c:827
gtp_encap_enable drivers/net/gtp.c:844 [inline]
gtp_newlink+0xfb/0x1e50 drivers/net/gtp.c:666
__rtnl_newlink net/core/rtnetlink.c:3305 [inline]
rtnl_newlink+0x2973/0x3920 net/core/rtnetlink.c:3363
rtnetlink_rcv_msg+0x1153/0x1570 net/core/rtnetlink.c:5424
netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5442
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0xf9e/0x1100 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x1248/0x14d0 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:639 [inline]
sock_sendmsg net/socket.c:659 [inline]
____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330
___sys_sendmsg net/socket.c:2384 [inline]
__sys_sendmsg+0x451/0x5f0 net/socket.c:2417
__do_sys_sendmsg net/socket.c:2426 [inline]
__se_sys_sendmsg+0x97/0xb0 net/socket.c:2424
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424
do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x441359
Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007fff1cd0ac28 EFLAGS:
00000246 ORIG_RAX:
000000000000002e
RAX:
ffffffffffffffda RBX:
0000000000000000 RCX:
0000000000441359
RDX:
0000000000000000 RSI:
0000000020000100 RDI:
0000000000000003
RBP:
00000000006cb018 R08:
00000000004002c8 R09:
00000000004002c8
R10:
00000000004002c8 R11:
0000000000000246 R12:
00000000004020d0
R13:
0000000000402160 R14:
0000000000000000 R15:
0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags+0x3c/0x90 mm/kmsan/kmsan.c:144
kmsan_internal_alloc_meta_for_pages mm/kmsan/kmsan_shadow.c:307 [inline]
kmsan_alloc_page+0x12a/0x310 mm/kmsan/kmsan_shadow.c:336
__alloc_pages_nodemask+0x57f2/0x5f60 mm/page_alloc.c:4800
alloc_pages_current+0x67d/0x990 mm/mempolicy.c:2207
alloc_pages include/linux/gfp.h:534 [inline]
alloc_slab_page+0x111/0x12f0 mm/slub.c:1511
allocate_slab mm/slub.c:1656 [inline]
new_slab+0x2bc/0x1130 mm/slub.c:1722
new_slab_objects mm/slub.c:2473 [inline]
___slab_alloc+0x1533/0x1f30 mm/slub.c:2624
__slab_alloc mm/slub.c:2664 [inline]
slab_alloc_node mm/slub.c:2738 [inline]
slab_alloc mm/slub.c:2783 [inline]
kmem_cache_alloc+0xb23/0xd70 mm/slub.c:2788
sk_prot_alloc+0xf2/0x620 net/core/sock.c:1597
sk_alloc+0xf0/0xbe0 net/core/sock.c:1657
inet_create+0x7c7/0x1370 net/ipv4/af_inet.c:321
__sock_create+0x8eb/0xf00 net/socket.c:1420
sock_create net/socket.c:1471 [inline]
__sys_socket+0x1a1/0x600 net/socket.c:1513
__do_sys_socket net/socket.c:1522 [inline]
__se_sys_socket+0x8d/0xb0 net/socket.c:1520
__x64_sys_socket+0x4a/0x70 net/socket.c:1520
do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Pablo Neira <pablo@netfilter.org>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Wed, 22 Jan 2020 06:47:29 +0000 (22:47 -0800)]
net: rtnetlink: validate IFLA_MTU attribute in rtnl_create_link()
rtnl_create_link() needs to apply dev->min_mtu and dev->max_mtu
checks that we apply in do_setlink()
Otherwise malicious users can crash the kernel, for example after
an integer overflow :
BUG: KASAN: use-after-free in memset include/linux/string.h:365 [inline]
BUG: KASAN: use-after-free in __alloc_skb+0x37b/0x5e0 net/core/skbuff.c:238
Write of size 32 at addr
ffff88819f20b9c0 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.5.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x197/0x210 lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
__kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
kasan_report+0x12/0x20 mm/kasan/common.c:639
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192
memset+0x24/0x40 mm/kasan/common.c:108
memset include/linux/string.h:365 [inline]
__alloc_skb+0x37b/0x5e0 net/core/skbuff.c:238
alloc_skb include/linux/skbuff.h:1049 [inline]
alloc_skb_with_frags+0x93/0x590 net/core/skbuff.c:5664
sock_alloc_send_pskb+0x7ad/0x920 net/core/sock.c:2242
sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2259
mld_newpack+0x1d7/0x7f0 net/ipv6/mcast.c:1609
add_grhead.isra.0+0x299/0x370 net/ipv6/mcast.c:1713
add_grec+0x7db/0x10b0 net/ipv6/mcast.c:1844
mld_send_cr net/ipv6/mcast.c:1970 [inline]
mld_ifc_timer_expire+0x3d3/0x950 net/ipv6/mcast.c:2477
call_timer_fn+0x1ac/0x780 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0x6c3/0x1790 kernel/time/timer.c:1786
__do_softirq+0x262/0x98c kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x19b/0x1e0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x1a3/0x610 arch/x86/kernel/apic/apic.c:1137
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
</IRQ>
RIP: 0010:native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:61
Code: 98 6b ea f9 eb 8a cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d 44 1c 60 00 f4 c3 66 90 e9 07 00 00 00 0f 00 2d 34 1c 60 00 fb f4 <c3> cc 55 48 89 e5 41 57 41 56 41 55 41 54 53 e8 4e 5d 9a f9 e8 79
RSP: 0018:
ffffffff89807ce8 EFLAGS:
00000286 ORIG_RAX:
ffffffffffffff13
RAX:
1ffffffff13266ae RBX:
ffffffff8987a1c0 RCX:
0000000000000000
RDX:
dffffc0000000000 RSI:
0000000000000006 RDI:
ffffffff8987aa54
RBP:
ffffffff89807d18 R08:
ffffffff8987a1c0 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000000 R12:
dffffc0000000000
R13:
ffffffff8a799980 R14:
0000000000000000 R15:
0000000000000000
arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:690
default_idle_call+0x84/0xb0 kernel/sched/idle.c:94
cpuidle_idle_call kernel/sched/idle.c:154 [inline]
do_idle+0x3c8/0x6e0 kernel/sched/idle.c:269
cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:361
rest_init+0x23b/0x371 init/main.c:451
arch_call_rest_init+0xe/0x1b
start_kernel+0x904/0x943 init/main.c:784
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:490
x86_64_start_kernel+0x77/0x7b arch/x86/kernel/head64.c:471
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:242
The buggy address belongs to the page:
page:
ffffea00067c82c0 refcount:0 mapcount:0 mapping:
0000000000000000 index:0x0
raw:
057ffe0000000000 ffffea00067c82c8 ffffea00067c82c8 0000000000000000
raw:
0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88819f20b880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88819f20b900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
ffff88819f20b980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff88819f20ba00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88819f20ba80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Fixes:
61e84623ace3 ("net: centralize net_device min/max MTU checking")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Ellerman [Wed, 22 Jan 2020 04:07:28 +0000 (15:07 +1100)]
airo: Add missing CAP_NET_ADMIN check in AIROOLDIOCTL/SIOCDEVPRIVATE
The driver for Cisco Aironet 4500 and 4800 series cards (airo.c),
implements AIROOLDIOCTL/SIOCDEVPRIVATE in airo_ioctl().
The ioctl handler copies an aironet_ioctl struct from userspace, which
includes a command. Some of the commands are handled in readrids(),
where the user controlled command is converted into a driver-internal
value called "ridcode".
There are two command values, AIROGWEPKTMP and AIROGWEPKNV, which
correspond to ridcode values of RID_WEP_TEMP and RID_WEP_PERM
respectively. These commands both have checks that the user has
CAP_NET_ADMIN, with the comment that "Only super-user can read WEP
keys", otherwise they return -EPERM.
However there is another command value, AIRORRID, that lets the user
specify the ridcode value directly, with no other checks. This means
the user can bypass the CAP_NET_ADMIN check on AIROGWEPKTMP and
AIROGWEPKNV.
Fix it by moving the CAP_NET_ADMIN check out of the command handling
and instead do it later based on the ridcode. That way regardless of
whether the ridcode is set via AIROGWEPKTMP or AIROGWEPKNV, or passed
in using AIRORID, we always do the CAP_NET_ADMIN check.
Found by Ilja by code inspection, not tested as I don't have the
required hardware.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Ellerman [Wed, 22 Jan 2020 04:07:27 +0000 (15:07 +1100)]
airo: Fix possible info leak in AIROOLDIOCTL/SIOCDEVPRIVATE
The driver for Cisco Aironet 4500 and 4800 series cards (airo.c),
implements AIROOLDIOCTL/SIOCDEVPRIVATE in airo_ioctl().
The ioctl handler copies an aironet_ioctl struct from userspace, which
includes a command and a length. Some of the commands are handled in
readrids(), which kmalloc()'s a buffer of RIDSIZE (2048) bytes.
That buffer is then passed to PC4500_readrid(), which has two cases.
The else case does some setup and then reads up to RIDSIZE bytes from
the hardware into the kmalloc()'ed buffer.
Here len == RIDSIZE, pBuf is the kmalloc()'ed buffer:
// read the rid length field
bap_read(ai, pBuf, 2, BAP1);
// length for remaining part of rid
len = min(len, (int)le16_to_cpu(*(__le16*)pBuf)) - 2;
...
// read remainder of the rid
rc = bap_read(ai, ((__le16*)pBuf)+1, len, BAP1);
PC4500_readrid() then returns to readrids() which does:
len = comp->len;
if (copy_to_user(comp->data, iobuf, min(len, (int)RIDSIZE))) {
Where comp->len is the user controlled length field.
So if the "rid length field" returned by the hardware is < 2048, and
the user requests 2048 bytes in comp->len, we will leak the previous
contents of the kmalloc()'ed buffer to userspace.
Fix it by kzalloc()'ing the buffer.
Found by Ilja by code inspection, not tested as I don't have the
required hardware.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vincenzo Frascino [Fri, 10 Jan 2020 12:28:07 +0000 (12:28 +0000)]
tee: optee: Fix compilation issue with nommu
The optee driver uses specific page table types to verify if a memory
region is normal. These types are not defined in nommu systems. Trying
to compile the driver in these systems results in a build error:
linux/drivers/tee/optee/call.c: In function ‘is_normal_memory’:
linux/drivers/tee/optee/call.c:533:26: error: ‘L_PTE_MT_MASK’ undeclared
(first use in this function); did you mean ‘PREEMPT_MASK’?
return (pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC;
^~~~~~~~~~~~~
PREEMPT_MASK
linux/drivers/tee/optee/call.c:533:26: note: each undeclared identifier is
reported only once for each function it appears in
linux/drivers/tee/optee/call.c:533:44: error: ‘L_PTE_MT_WRITEALLOC’ undeclared
(first use in this function)
return (pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC;
^~~~~~~~~~~~~~~~~~~
Make the optee driver depend on MMU to fix the compilation issue.
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
[jw: update commit title]
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Andrew Lunn [Wed, 22 Jan 2020 19:23:15 +0000 (20:23 +0100)]
MAINTAINERS: Make Russell King designated reviewer of phylib
phylink and phylib are interconnected. It makes sense for phylib and
phy driver patches to be also reviewed by the phylink maintainer.
So add Russell King as a designed reviewer of phylib.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Dave Airlie [Wed, 22 Jan 2020 23:57:08 +0000 (09:57 +1000)]
Merge tag 'drm-misc-fixes-2020-01-22-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
-mst: Fix SST branch device handling (Wayne)
-panfrost: Fix mapping of globally visible BO's (Boris)
Cc: Wayne Lin <Wayne.Lin@amd.com>
CC: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200122213725.GA22099@art_vandelay
Linus Torvalds [Wed, 22 Jan 2020 20:56:19 +0000 (12:56 -0800)]
Merge tag 'leds-5.5-rc8' of git://git./linux/kernel/git/pavel/linux-leds
Pull LED fixes from Pavel Machek:
"Jacek's fix for an uninitialized gpio label is why I'm requesting this
pull; it fixes regression in debugging output in sysfs. Others are
just bugfixes that should be safe.
Everything has been in -next for while"
* tag 'leds-5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds:
leds: lm3532: add pointer to documentation and fix typo
leds: rb532: cleanup whitespace
ledtrig-pattern: fix email address quoting in MODULE_AUTHOR()
led: max77650: add of_match table
leds-as3645a: Drop fwnode reference on ignored node
leds: gpio: Fix uninitialized gpio label for fwnode based probe
Linus Torvalds [Wed, 22 Jan 2020 20:38:10 +0000 (12:38 -0800)]
Merge tag 'hwmon-for-v5.5-rc8' of git://git./linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
- In hwmon core, do not use the hwmon parent device for device managed
memory allocations, since parent device lifetime may not match hwmon
device lifetime.
- Fix discrepancy between read and write values in adt7475 driver.
- Fix alarms and voltage limits in nct7802 driver.
* tag 'hwmon-for-v5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (core) Do not use device managed functions for memory allocations
hwmon: (adt7475) Make volt2reg return same reg as reg2volt input
hwmon: (nct7802) Fix non-working alarm on voltages
hwmon: (nct7802) Fix voltage limits to wrong registers
William Dauchy [Tue, 21 Jan 2020 20:49:54 +0000 (21:49 +0100)]
net, ip6_tunnel: fix namespaces move
in the same manner as commit
d0f418516022 ("net, ip_tunnel: fix
namespaces move"), fix namespace moving as it was broken since commit
8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnel"), but for
ipv6 this time; there is no reason to keep it for ip6_tunnel.
Fixes:
8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnel")
Signed-off-by: William Dauchy <w.dauchy@criteo.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 21 Jan 2020 19:02:20 +0000 (11:02 -0800)]
net_sched: use validated TCA_KIND attribute in tc_new_tfilter()
sysbot found another issue in tc_new_tfilter().
We probably should use @name which contains the sanitized
version of TCA_KIND.
BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:608 [inline]
BUG: KMSAN: uninit-value in string+0x522/0x690 lib/vsprintf.c:689
CPU: 1 PID: 10753 Comm: syz-executor.1 Not tainted 5.5.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x220 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
string_nocheck lib/vsprintf.c:608 [inline]
string+0x522/0x690 lib/vsprintf.c:689
vsnprintf+0x207d/0x31b0 lib/vsprintf.c:2574
__request_module+0x2ad/0x11c0 kernel/kmod.c:143
tcf_proto_lookup_ops+0x241/0x720 net/sched/cls_api.c:139
tcf_proto_create net/sched/cls_api.c:262 [inline]
tc_new_tfilter+0x2a4e/0x5010 net/sched/cls_api.c:2058
rtnetlink_rcv_msg+0xcb7/0x1570 net/core/rtnetlink.c:5415
netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5442
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0xf9e/0x1100 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x1248/0x14d0 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:639 [inline]
sock_sendmsg net/socket.c:659 [inline]
____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330
___sys_sendmsg net/socket.c:2384 [inline]
__sys_sendmsg+0x451/0x5f0 net/socket.c:2417
__do_sys_sendmsg net/socket.c:2426 [inline]
__se_sys_sendmsg+0x97/0xb0 net/socket.c:2424
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424
do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45b349
Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007f88b3948c78 EFLAGS:
00000246 ORIG_RAX:
000000000000002e
RAX:
ffffffffffffffda RBX:
00007f88b39496d4 RCX:
000000000045b349
RDX:
0000000000000000 RSI:
00000000200001c0 RDI:
0000000000000003
RBP:
000000000075bfc8 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000246 R12:
00000000ffffffff
R13:
000000000000099f R14:
00000000004cb163 R15:
000000000075bfd4
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:144 [inline]
kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:127
kmsan_slab_alloc+0x8a/0xe0 mm/kmsan/kmsan_hooks.c:82
slab_alloc_node mm/slub.c:2774 [inline]
__kmalloc_node_track_caller+0xb40/0x1200 mm/slub.c:4382
__kmalloc_reserve net/core/skbuff.c:141 [inline]
__alloc_skb+0x2fd/0xac0 net/core/skbuff.c:209
alloc_skb include/linux/skbuff.h:1049 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1174 [inline]
netlink_sendmsg+0x7d3/0x14d0 net/netlink/af_netlink.c:1892
sock_sendmsg_nosec net/socket.c:639 [inline]
sock_sendmsg net/socket.c:659 [inline]
____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330
___sys_sendmsg net/socket.c:2384 [inline]
__sys_sendmsg+0x451/0x5f0 net/socket.c:2417
__do_sys_sendmsg net/socket.c:2426 [inline]
__se_sys_sendmsg+0x97/0xb0 net/socket.c:2424
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424
do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
6f96c3c6904c ("net_sched: fix backward compatibility for TCA_KIND")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
Paolo Abeni [Tue, 21 Jan 2020 15:50:49 +0000 (16:50 +0100)]
Revert "udp: do rmem bulk free even if the rx sk queue is empty"
This reverts commit
0d4a6608f68c7532dcbfec2ea1150c9761767d03.
Williem reported that after commit
0d4a6608f68c ("udp: do rmem bulk
free even if the rx sk queue is empty") the memory allocated by
an almost idle system with many UDP sockets can grow a lot.
For stable kernel keep the solution as simple as possible and revert
the offending commit.
Reported-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Diagnosed-by: Eric Dumazet <eric.dumazet@gmail.com>
Fixes:
0d4a6608f68c ("udp: do rmem bulk free even if the rx sk queue is empty")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pavel [Sun, 5 Jan 2020 22:36:58 +0000 (23:36 +0100)]
leds: lm3532: add pointer to documentation and fix typo
Add pointer to datasheet and fix typo in printk message.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Pavel Machek [Thu, 2 Jan 2020 21:29:35 +0000 (22:29 +0100)]
leds: rb532: cleanup whitespace
Trivial cleanup removing empty line at wrong place.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Pavel Machek [Sun, 10 Mar 2019 18:54:40 +0000 (19:54 +0100)]
ledtrig-pattern: fix email address quoting in MODULE_AUTHOR()
Apparently it is quite easy to forget ">" in quoting of email
address. This fixes it.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Bartosz Golaszewski [Tue, 10 Dec 2019 10:08:32 +0000 (11:08 +0100)]
led: max77650: add of_match table
We need the of_match table if we want to use the compatible string in
the pmic's child node and get the led driver loaded automatically.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Sakari Ailus [Wed, 4 Dec 2019 07:56:42 +0000 (09:56 +0200)]
leds-as3645a: Drop fwnode reference on ignored node
If a node is ignored, do not get a reference to it. Fix the bug by moving
fwnode_handle_get() where a reference to an fwnode is saved for clarity.
Reported-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Jacek Anaszewski [Thu, 5 Dec 2019 21:25:01 +0000 (22:25 +0100)]
leds: gpio: Fix uninitialized gpio label for fwnode based probe
When switching to using generic LED name composition mechanism via
devm_led_classdev_register_ext() API the part of code initializing
struct gpio_led's template name property was removed alongside.
It was however overlooked that the property was also passed to
devm_fwnode_get_gpiod_from_child() in place of "label" parameter,
which when set to NULL, results in gpio label being initialized to '?'.
It could be observed in debugfs and failed to properly identify
gpio association with LED consumer.
Fix this shortcoming by updating the GPIO label after the LED is
registered and its final name is known.
Fixes:
d7235f5feaa0 ("leds: gpio: Use generic support for composing LED names")
Cc: Russell King <linux@armlinux.org.uk>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
[fixed comment]
Signed-off-by: Pavel Machek <pavel@ucw.cz>
David S. Miller [Wed, 22 Jan 2020 19:38:39 +0000 (20:38 +0100)]
net: Add Jakub to MAINTAINERS for networking general.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Maxim Mikityanskiy [Tue, 21 Jan 2020 15:09:40 +0000 (15:09 +0000)]
net: Fix packet reordering caused by GRO and listified RX cooperation
Commit
323ebb61e32b ("net: use listified RX for handling GRO_NORMAL
skbs") introduces batching of GRO_NORMAL packets in napi_frags_finish,
and commit
6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in
napi_gro_receive()") adds the same to napi_skb_finish. However,
dev_gro_receive (that is called just before napi_{frags,skb}_finish) can
also pass skbs to the networking stack: e.g., when the GRO session is
flushed, napi_gro_complete is called, which passes pp directly to
netif_receive_skb_internal, skipping napi->rx_list. It means that the
packet stored in pp will be handled by the stack earlier than the
packets that arrived before, but are still waiting in napi->rx_list. It
leads to TCP reorderings that can be observed in the TCPOFOQueue counter
in netstat.
This commit fixes the reordering issue by making napi_gro_complete also
use napi->rx_list, so that all packets going through GRO will keep their
order. In order to keep napi_gro_flush working properly, gro_normal_list
calls are moved after the flush to clear napi->rx_list.
iwlwifi calls napi_gro_flush directly and does the same thing that is
done by gro_normal_list, so the same change is applied there:
napi_gro_flush is moved to be before the flush of napi->rx_list.
A few other drivers also use napi_gro_flush (brocade/bna/bnad.c,
cortina/gemini.c, hisilicon/hns3/hns3_enet.c). The first two also use
napi_complete_done afterwards, which performs the gro_normal_list flush,
so they are fine. The latter calls napi_gro_receive right after
napi_gro_flush, so it can end up with non-empty napi->rx_list anyway.
Fixes:
323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs")
Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
Cc: Alexander Lobakin <alobakin@dlink.ru>
Cc: Edward Cree <ecree@solarflare.com>
Acked-by: Alexander Lobakin <alobakin@dlink.ru>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Acked-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Richard Palethorpe [Tue, 21 Jan 2020 13:42:58 +0000 (14:42 +0100)]
can, slip: Protect tty->disc_data in write_wakeup and close with RCU
write_wakeup can happen in parallel with close/hangup where tty->disc_data
is set to NULL and the netdevice is freed thus also freeing
disc_data. write_wakeup accesses disc_data so we must prevent close from
freeing the netdev while write_wakeup has a non-NULL view of
tty->disc_data.
We also need to make sure that accesses to disc_data are atomic. Which can
all be done with RCU.
This problem was found by Syzkaller on SLCAN, but the same issue is
reproducible with the SLIP line discipline using an LTP test based on the
Syzkaller reproducer.
A fix which didn't use RCU was posted by Hillf Danton.
Fixes:
661f7fda21b1 ("slip: Fix deadlock in write_wakeup")
Fixes:
a8e83b17536a ("slcan: Port write_wakeup deadlock fix from slip")
Reported-by: syzbot+017e491ae13c0068598a@syzkaller.appspotmail.com
Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Tyler Hall <tylerwhall@gmail.com>
Cc: linux-can@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: syzkaller@googlegroups.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Sitnicki [Tue, 21 Jan 2020 12:31:47 +0000 (13:31 +0100)]
net, sk_msg: Don't check if sock is locked when tearing down psock
As John Fastabend reports [0], psock state tear-down can happen on receive
path *after* unlocking the socket, if the only other psock user, that is
sockmap or sockhash, releases its psock reference before tcp_bpf_recvmsg
does so:
tcp_bpf_recvmsg()
psock = sk_psock_get(sk) <- refcnt 2
lock_sock(sk);
...
sock_map_free() <- refcnt 1
release_sock(sk)
sk_psock_put() <- refcnt 0
Remove the lockdep check for socket lock in psock tear-down that got
introduced in
7e81a3530206 ("bpf: Sockmap, ensure sock lock held during
tear down").
[0] https://lore.kernel.org/netdev/5e25dc995d7d_74082aaee6e465b441@john-XPS-13-9370.notmuch/
Fixes:
7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down")
Reported-by: syzbot+d73682fcf7fee6982fe3@syzkaller.appspotmail.com
Suggested-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Murzin [Mon, 20 Jan 2020 14:07:46 +0000 (15:07 +0100)]
ARM: 8955/1: virt: Relax arch timer version check during early boot
Updates to the Generic Timer architecture allow ID_PFR1.GenTimer to
have values other than 0 or 1 while still preserving backward
compatibility. At the moment, Linux is quite strict in the way it
handles this field at early boot and will not configure arch timer if
it doesn't find the value 1.
Since here use ubfx for arch timer version extraction (hyb-stub build
with -march=armv7-a, so it is safe)
To help backports (even though the code was correct at the time of writing)
Fixes:
8ec58be9f3ff ("ARM: virt: arch_timers: enable access to physical timers")
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Emmanuel Grumbach [Tue, 3 Dec 2019 08:08:49 +0000 (10:08 +0200)]
iwlwifi: mvm: don't send the IWL_MVM_RXQ_NSSN_SYNC notif to Rx queues
The purpose of this was to keep all the queues updated with
the Rx sequence numbers because unlikely yet possible
situations where queues can't understand if a specific
packet needs to be dropped or not.
Unfortunately, it was reported that this caused issues in
our DMA engine. We don't fully understand how this is related,
but this is being currently debugged. For now, just don't send
this notification to the Rx queues. This de-facto reverts my
commit
3c514bf831ac12356b695ff054bef641b9e99593:
iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues
This issue was reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=204873
https://bugzilla.kernel.org/show_bug.cgi?id=205001
and others maybe.
Fixes:
3c514bf831ac ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues")
CC: <stable@vger.kernel.org> # 5.3+
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Linus Torvalds [Wed, 22 Jan 2020 16:30:09 +0000 (08:30 -0800)]
Merge tag 'io_uring-5.5-2020-01-22' of git://git.kernel.dk/linux-block
Pull io_uring fix from Jens Axboe:
"This was supposed to have gone in last week, but due to a brain fart
on my part, I forgot that we made this struct addition in the 5.5
cycle. So here it is for 5.5, to prevent having a 32 vs 64-bit
compatability issue with the files_update command"
* tag 'io_uring-5.5-2020-01-22' of git://git.kernel.dk/linux-block:
io_uring: fix compat for IORING_REGISTER_FILES_UPDATE
Mark Rutland [Wed, 22 Jan 2020 12:45:46 +0000 (12:45 +0000)]
arm64: acpi: fix DAIF manipulation with pNMI
Since commit:
d44f1b8dd7e66d80 ("arm64: KVM/mm: Move SEA handling behind a single 'claim' interface")
... the top-level APEI SEA handler has the shape:
1. current_flags = arch_local_save_flags()
2. local_daif_restore(DAIF_ERRCTX)
3. <GHES handler>
4. local_daif_restore(current_flags)
However, since commit:
4a503217ce37e1f4 ("arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking")
... when pseudo-NMIs (pNMIs) are in use, arch_local_save_flags() will save
the PMR value rather than the DAIF flags.
The combination of these two commits means that the APEI SEA handler will
erroneously attempt to restore the PMR value into DAIF. Fix this by
factoring local_daif_save_flags() out of local_daif_save(), so that we
can consistently save DAIF in step #1, regardless of whether pNMIs are in
use.
Both commits were introduced concurrently in v5.0.
Cc: <stable@vger.kernel.org>
Fixes:
4a503217ce37e1f4 ("arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking")
Fixes:
d44f1b8dd7e66d80 ("arm64: KVM/mm: Move SEA handling behind a single 'claim' interface")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Masami Hiramatsu [Wed, 22 Jan 2020 03:23:25 +0000 (12:23 +0900)]
tracing/uprobe: Fix to make trace_uprobe_filter alignment safe
Commit
99c9a923e97a ("tracing/uprobe: Fix double perf_event
linking on multiprobe uprobe") moved trace_uprobe_filter on
trace_probe_event. However, since it introduced a flexible
data structure with char array and type casting, the
alignment of trace_uprobe_filter can be broken.
This changes the type of the array to trace_uprobe_filter
data strucure to fix it.
Link: http://lore.kernel.org/r/20200120124022.GA14897@hirez.programming.kicks-ass.net
Link: http://lkml.kernel.org/r/157966340499.5107.10978352478952144902.stgit@devnote2
Fixes:
99c9a923e97a ("tracing/uprobe: Fix double perf_event linking on multiprobe uprobe")
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Will Deacon [Wed, 22 Jan 2020 11:38:53 +0000 (11:38 +0000)]
Merge branch 'for-next/rng' into for-next/core
* for-next/rng: (2 commits)
arm64: Use v8.5-RNG entropy for KASLR seed
...
Will Deacon [Wed, 22 Jan 2020 11:35:05 +0000 (11:35 +0000)]
Merge branch 'for-next/errata' into for-next/core
* for-next/errata: (3 commits)
arm64: Workaround for Cortex-A55 erratum
1530923
...
Will Deacon [Wed, 22 Jan 2020 11:34:21 +0000 (11:34 +0000)]
Merge branch 'for-next/asm-annotations' into for-next/core
* for-next/asm-annotations: (6 commits)
arm64: kernel: Correct annotation of end of el0_sync
...
Will Deacon [Wed, 22 Jan 2020 11:32:31 +0000 (11:32 +0000)]
Merge branches 'for-next/acpi', 'for-next/cpufeatures', 'for-next/csum', 'for-next/e0pd', 'for-next/entry', 'for-next/kbuild', 'for-next/kexec/cleanup', 'for-next/kexec/file-kdump', 'for-next/misc', 'for-next/nofpsimd', 'for-next/perf' and 'for-next/scs' into for-next/core
* for-next/acpi:
ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map()
* for-next/cpufeatures: (2 commits)
arm64: Introduce ID_ISAR6 CPU register
...
* for-next/csum: (2 commits)
arm64: csum: Fix pathological zero-length calls
...
* for-next/e0pd: (7 commits)
arm64: kconfig: Fix alignment of E0PD help text
...
* for-next/entry: (5 commits)
arm64: entry: cleanup sp_el0 manipulation
...
* for-next/kbuild: (4 commits)
arm64: kbuild: remove compressed images on 'make ARCH=arm64 (dist)clean'
...
* for-next/kexec/cleanup: (11 commits)
Revert "arm64: kexec: make dtb_mem always enabled"
...
* for-next/kexec/file-kdump: (2 commits)
arm64: kexec_file: add crash dump support
...
* for-next/misc: (12 commits)
arm64: entry: Avoid empty alternatives entries
...
* for-next/nofpsimd: (7 commits)
arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly
...
* for-next/perf: (2 commits)
perf/imx_ddr: Fix cpu hotplug state cleanup
...
* for-next/scs: (6 commits)
arm64: kernel: avoid x18 in __cpu_soft_restart
...
Will Deacon [Wed, 22 Jan 2020 11:23:54 +0000 (11:23 +0000)]
arm64: kconfig: Fix alignment of E0PD help text
Remove the additional space.
Signed-off-by: Will Deacon <will@kernel.org>
Mark Brown [Tue, 21 Jan 2020 12:58:53 +0000 (12:58 +0000)]
arm64: Use v8.5-RNG entropy for KASLR seed
When seeding KALSR on a system where we have architecture level random
number generation make use of that entropy, mixing it in with the seed
passed by the bootloader. Since this is run very early in init before
feature detection is complete we open code rather than use archrandom.h.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Richard Henderson [Tue, 21 Jan 2020 12:58:52 +0000 (12:58 +0000)]
arm64: Implement archrandom.h for ARMv8.5-RNG
Expose the ID_AA64ISAR0.RNDR field to userspace, as the RNG system
registers are always available at EL0.
Implement arch_get_random_seed_long using RNDR. Given that the
TRNG is likely to be a shared resource between cores, and VMs,
do not explicitly force re-seeding with RNDRRS. In order to avoid
code complexity and potential issues with hetrogenous systems only
provide values after cpufeature has finalized the system capabilities.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
[Modified to only function after cpufeature has finalized the system
capabilities and move all the code into the header -- broonie]
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
[will: Advertise HWCAP via /proc/cpuinfo]
Signed-off-by: Will Deacon <will@kernel.org>
Frederic Barrat [Mon, 13 Jan 2020 13:01:18 +0000 (14:01 +0100)]
powerpc/xive: Discard ESB load value when interrupt is invalid
A load on an ESB page returning all 1's means that the underlying
device has invalidated the access to the PQ state of the interrupt
through mmio. It may happen, for example when querying a PHB interrupt
while the PHB is in an error state.
In that case, we should consider the interrupt to be invalid when
checking its state in the irq_get_irqchip_state() handler.
Fixes:
da15c03b047d ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race")
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
[clg: wrote a commit log, introduced XIVE_ESB_INVALID ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200113130118.27969-1-clg@kaod.org
Bharata B Rao [Thu, 9 Jan 2020 09:20:47 +0000 (14:50 +0530)]
powerpc: Ultravisor: Fix the dependencies for CONFIG_PPC_UV
Let PPC_UV depend only on DEVICE_PRIVATE which in turn
will satisfy all the other required dependencies
Fixes:
013a53f2d25a ("powerpc: Ultravisor: Add PPC_UV config option")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200109092047.24043-1-bharata@linux.ibm.com
Jerry Snitselaar [Wed, 30 Oct 2019 22:58:43 +0000 (15:58 -0700)]
tpm: Add tpm_version_major sysfs file
Easily determining what TCG version a tpm device implements
has been a pain point for userspace for a long time, so
add a sysfs file to report the TCG major version of a tpm device.
Also add an entry to Documentation/ABI/stable/sysfs-class-tpm
describing the new file.
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: Peter Huewe <peterhuewe@gmx.de>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: linux-integrity@vger.kernel.org
Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Jerry Snitselaar [Fri, 25 Oct 2019 19:36:28 +0000 (12:36 -0700)]
tpm: Update mailing list contact information in sysfs-class-tpm
All of the entries in Documentation/ABI/stable/sysfs-class-tpm
point to the old tpmdd-devel mailing list. This patch
updates the entries to point to linux-intergrity.
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Peter Huewe <peterhuewe@gmx.de>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: linux-integrity@vger.kernel.org
Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Jeff Layton [Wed, 3 Apr 2019 17:16:01 +0000 (13:16 -0400)]
ceph: hold extra reference to r_parent over life of request
Currently, we just assume that it will stick around by virtue of the
submitter's reference, but later patches will allow the syscall to
return early and we can't rely on that reference at that point.
While I'm not aware of any reports of it, Xiubo pointed out that this
may fix a use-after-free. If the wait for a reply times out or is
canceled via signal, and then the reply comes in after the syscall
returns, the client can end up trying to access r_parent without a
reference.
Take an extra reference to the inode when setting r_parent and release
it when releasing the request.
Cc: stable@vger.kernel.org
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Boris Brezillon [Thu, 16 Jan 2020 02:15:54 +0000 (20:15 -0600)]
drm/panfrost: Add the panfrost_gem_mapping concept
With the introduction of per-FD address space, the same BO can be mapped
in different address space if the BO is globally visible (GEM_FLINK)
and opened in different context or if the dmabuf is self-imported. The
current implementation does not take case into account, and attaches the
mapping directly to the panfrost_gem_object.
Let's create a panfrost_gem_mapping struct and allow multiple mappings
per BO.
The mappings are refcounted which helps solve another problem where
mappings were torn down (GEM handle closed by userspace) while GPU
jobs accessing those BOs were still in-flight. Jobs now keep a
reference on the mappings they use.
v2 (robh):
- Minor review comment clean-ups from Steven
- Use list_is_singular helper
- Just WARN if we add a mapping when madvise state is not WILLNEED.
With that, drop the use of object_name_lock.
v3 (robh):
- Revert returning list iterator in panfrost_gem_mapping_get()
Fixes:
a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation")
Fixes:
7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc: <stable@vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200116021554.15090-1-robh@kernel.org
Dirk Behme [Tue, 21 Jan 2020 15:54:39 +0000 (16:54 +0100)]
arm64: kbuild: remove compressed images on 'make ARCH=arm64 (dist)clean'
Since v4.3-rc1 commit
0723c05fb75e44 ("arm64: enable more compressed
Image formats"), it is possible to build Image.{bz2,lz4,lzma,lzo}
AArch64 images. However, the commit missed adding support for removing
those images on 'make ARCH=arm64 (dist)clean'.
Fix this by adding them to the target list.
Make sure to match the order of the recipes in the makefile.
Cc: stable@vger.kernel.org # v4.3+
Fixes:
0723c05fb75e44 ("arm64: enable more compressed Image formats")
Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Will Deacon <will@kernel.org>