2019-10-02 19:08:56

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 00/87] 3.16.75-rc1 review

This is the start of the stable review cycle for the 3.16.75 release.
There are 87 patches in this series, which will be posted as responses
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri Oct 04 19:06:50 UTC 2019.
Anything received after that time might be too late.

All the patches have also been committed to the linux-3.16.y-rc branch of
https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-rc.git .
A shortlog and diffstat can be found below.

Ben.

-------------

Alan Stern (1):
USB: Fix slab-out-of-bounds write in usb_get_bos_descriptor
[a03ff54460817c76105f81f3aa8ef655759ccc9a]

Alejandro Jimenez (1):
x86/speculation: Allow guests to use SSBD even if host does not
[c1f7fec1eb6a2c86d01bc22afce772c743451d88]

Alexandra Winter (1):
s390/qeth: fix VLAN attribute in bridge_hostnotify udev event
[335726195e460cb6b3f795b695bfd31f0ea70ef0]

Andrea Arcangeli (1):
coredump: fix race condition between collapse_huge_page() and core dumping
[59ea6d06cfa9247b586a695c21f94afa7183af74]

Andrea Parri (1):
sbitmap: fix improper use of smp_mb__before_atomic()
[a0934fd2b1208458e55fc4b48f55889809fce666]

Andrey Smirnov (1):
Input: uinput - add compat ioctl number translation for UI_*_FF_UPLOAD
[7c7da40da1640ce6814dab1e8031b44e19e5a3f6]

Carsten Schmid (1):
usb: xhci: avoid null pointer deref when bos field is NULL
[7aa1bb2ffd84d6b9b5f546b079bb15cd0ab6e76e]

Catalina Mocanu (1):
staging: iio: cdc: Don't put an else right after a return
[288903f6b91e759b0a813219acd376426cbb8f14]

Chris Packham (1):
USB: serial: pl2303: add Allied Telesis VT-Kit3
[c5f81656a18b271976a86724dadd8344e54de74e]

Colin Ian King (3):
ALSA: seq: fix incorrect order of dest_client/dest_ports arguments
[c3ea60c231446663afd6ea1054da6b7f830855ca]
scsi: bnx2fc: fix incorrect cast to u64 on shift operation
[d0c0d902339249c75da85fd9257a86cbb98dfaa5]
x86/apic: Fix integer overflow on 10 bit left shift of cpu_khz
[ea136a112d89bade596314a1ae49f748902f4727]

Coly Li (1):
bcache: fix stack corruption by PRECEDING_KEY()
[31b90956b124240aa8c63250243ae1a53585c5e2]

Dan Carpenter (1):
genwqe: Prevent an integer overflow in the ioctl
[110080cea0d0e4dfdb0b536e7f8a5633ead6a781]

Dave Martin (1):
KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST
[df205b5c63281e4f32caac22adda18fd68795e80]

Dmitry Korotin (1):
MIPS: Add missing EHB in mtc0 -> mfc0 sequence.
[0b24cae4d535045f4c9e177aa228d4e97bad212c]

Eiichi Tsukata (1):
tracing/snapshot: Resize spare buffer if size changed
[46cc0b44428d0f0e81f11ea98217fc0edfbeab07]

Eric Biggers (2):
cfg80211: fix memory leak of wiphy device name
[4f488fbca2a86cc7714a128952eead92cac279ab]
crypto: user - prevent operating on larval algorithms
[21d4120ec6f5b5992b01b96ac484701163917b63]

Eric Dumazet (6):
ipv4/igmp: fix another memory leak in igmpv3_del_delrec()
[3580d04aa674383c42de7b635d28e52a1e5bc72c]
ipv4/igmp: fix build error if !CONFIG_IP_MULTICAST
[903869bd10e6719b9df6718e785be7ec725df59f]
ipv6: flowlabel: fl6_sock_lookup() must use atomic_inc_not_zero
[65a3c497c0e965a552008db8bc2653f62bc925a1]
llc: fix skb leak in llc_build_and_send_ui_pkt()
[8fb44d60d4142cd2a440620cd291d346e23c131e]
neigh: fix use-after-free read in pneigh_get_next
[f3e92cb8e2eb8c27d109e6fd73d3a69a8c09e288]
net-gro: fix use-after-free read in napi_gro_frags()
[a4270d6795b0580287453ea55974d948393e66ef]

Eric W. Biederman (1):
signal/ptrace: Don't leak unitialized kernel memory with PTRACE_PEEK_SIGINFO
[f6e2aa91a46d2bc79fce9b93a988dbe7655c90c0]

Filipe Manana (2):
Btrfs: fix race between ranged fsync and writeback of adjacent ranges
[0c713cbab6200b0ab6473b50435e450a6e1de85d]
Btrfs: fix race between readahead and device replace/removal
[ce7791ffee1e1ee9f97193b817c7dd1fa6746aad]

Geert Uytterhoeven (1):
cpu/speculation: Warn on unsupported mitigations= parameter
[1bf72720281770162c87990697eae1ba2f1d917a]

George G. Davis (1):
serial: sh-sci: disable DMA for uart_console
[099506cbbc79c0bd52b19cb6b930f256dabc3950]

Hans de Goede (1):
libata: Extend quirks for the ST1000LM024 drives with NOLPM quirk
[31f6264e225fb92cf6f4b63031424f20797c297d]

Harald Freudenberger (1):
s390/crypto: fix possible sleep during spinlock aquired
[1c2c7029c008922d4d48902cc386250502e73d51]

Herbert Xu (1):
lib/mpi: Fix karactx leak in mpi_powm
[c8ea9fce2baf7b643384f36f29e4194fa40d33a6]

Ivan Vecera (1):
be2net: Fix number of Rx queues used for flow hashing
[718f4a2537089ea41903bf357071306163bc7c04]

Jakub Kicinski (1):
net: netem: fix backlog accounting for corrupted GSO frames
[177b8007463c4f36c9a2c7ce7aa9875a4cad9bd5]

Jan Kara (1):
scsi: vmw_pscsi: Fix use-after-free in pvscsi_queue_lck()
[240b4cc8fd5db138b675297d4226ec46594d9b3b]

Jan Stancek (1):
powerpc/perf: add missing put_cpu_var in power_pmu_event_init
[68de8867ea5d99127e836c23f6bccf4d44859623]

Jann Horn (2):
apparmor: enforce nullbyte at end of tag string
[8404d7a674c49278607d19726e0acc0cae299357]
ptrace: restore smp_rmb() in __ptrace_may_access()
[f6581f5b55141a95657ef5742cf6a6bfa20a109f]

Jisheng Zhang (1):
net: stmmac: fix reset gpio free missing
[49ce881c0d4c4a7a35358d9dccd5f26d0e56fc61]

Joakim Zhang (1):
can: flexcan: fix timeout when set small bitrate
[247e5356a709eb49a0d95ff2a7f07dac05c8252c]

Joe Burmeister (1):
tty: max310x: Fix external crystal register setup
[5d24f455c182d5116dd5db8e1dc501115ecc9c2c]

John David Anglin (1):
parisc: Use implicit space register selection for loading the coherence index of I/O pdirs
[63923d2c3800919774f5c651d503d1dd2adaddd5]

Julian Wiedmann (2):
net/af_iucv: always register net_device notifier
[06996c1d4088a0d5f3e7789d7f96b4653cc947cc]
net/af_iucv: remove GFP_DMA restriction for HiperTransport
[fdbf6326912d578a31ac4ca0933c919eadf1d54c]

Kai-Heng Feng (1):
USB: usb-storage: Add new ID to ums-realtek
[1a6dd3fea131276a4fc44ae77b0f471b0b473577]

Kees Cook (1):
net: tulip: de4x5: Drop redundant MODULE_DEVICE_TABLE()
[3e66b7cc50ef921121babc91487e1fb98af1ba6e]

Marco Zatta (1):
USB: Fix chipmunk-like voice when using Logitech C270 for recording audio.
[bd21f0222adab64974b7d1b4b8c7ce6b23e9ea4d]

Maximilian Luz (1):
USB: Add LPM quirk for Surface Dock GigE adapter
[ea261113385ac0a71c2838185f39e8452d54b152]

Melissa Wen (1):
staging:iio:ad7150: fix threshold mode config bit
[df4d737ee4d7205aaa6275158aeebff87fd14488]

Naohiro Aota (1):
btrfs: start readahead also in seed devices
[c4e0540d0ad49c8ceab06cceed1de27c4fe29f6e]

Oliver Neukum (1):
USB: rio500: fix memory leak in close after disconnect
[e0feb73428b69322dd5caae90b0207de369b5575]

Paolo Abeni (1):
pktgen: do not sleep with the thread lock held.
[720f1de4021f09898b8c8443f3b3e995991b6e3a]

Patrik Jakobsson (1):
drm/gma500/cdv: Check vbt config bits when detecting lvds panels
[7c420636860a719049fae9403e2c87804f53bdde]

Peter Zijlstra (2):
perf/core: Fix perf_sample_regs_user() mm check
[085ebfe937d7a7a5df1729f35a12d6d655fea68c]
perf/ring_buffer: Add ordering to rb->nest increment
[3f9fbe9bd86c534eba2faf5d840fd44c6049f50e]

Petr Oros (1):
be2net: fix link failure after ethtool offline test
[2e5db6eb3c23e5dc8171eb8f6af7a97ef9fcf3a9]

Randy Dunlap (1):
gpio: fix gpio-adp5588 build errors
[e9646f0f5bb62b7d43f0968f39d536cfe7123b53]

Ravi Bangoria (2):
perf/ioctl: Add check for the sample_period value
[913a90bc5a3a06b1f04c337320e9aeee2328dd77]
powerpc/perf: Fix MMCRA corruption by bhrb_filter
[3202e35ec1c8fc19cea24253ff83edf702a60a02]

Robert Hancock (1):
hwmon: (pmbus/core) Treat parameters as paged if on multiple pages
[4a60570dce658e3f8885bbcf852430b99f65aca5]

Roberto Bergantinos Corpas (1):
CIFS: cifs_read_allocate_pages: don't iterate through whole page array on ENOMEM
[31fad7d41e73731f05b8053d17078638cf850fa6]

Roman Bolshakov (1):
scsi: target/iblock: Fix overrun in WRITE SAME emulation
[5676234f20fef02f6ca9bd66c63a8860fce62645]

Ronnie Sahlberg (1):
cifs: add spinlock for the openFileList to cifsInodeInfo
[487317c99477d00f22370625d53be3239febabbe]

Russell King (1):
i2c: acorn: fix i2c warning
[ca21f851cc9643af049226d57fabc3c883ea648e]

S.j. Wang (1):
ASoC: cs42xx8: Add regcache mask dirty
[ad6eecbfc01c987e0253371f274c3872042e4350]

Sahitya Tummala (1):
configfs: Fix use-after-free when accessing sd->s_dentry
[f6122ed2a4f9c9c1c073ddf6308d1b2ac10e0781]

Shuah Khan (2):
usbip: usbip_host: fix BUG: sleeping function called from invalid context
[0c9e8b3cad654bfc499c10b652fbf8f0b890af8f]
usbip: usbip_host: fix stub_dev lock context imbalance regression
[3ea3091f1bd8586125848c62be295910e9802af0]

Stanley Chu (1):
scsi: ufs: Avoid runtime suspend possibly being blocked forever
[24e2e7a19f7e4b83d0d5189040d997bce3596473]

Steffen Maier (2):
scsi: zfcp: fix missing zfcp_port reference put on -EBUSY from port_remove
[d27e5e07f9c49bf2a6a4ef254ce531c1b4fb5a38]
scsi: zfcp: fix to prevent port_remove with pure auto scan LUNs (only sdevs)
[ef4021fe5fd77ced0323cede27979d80a56211ca]

Steve French (1):
SMB3: retry on STATUS_INSUFFICIENT_RESOURCES instead of failing write
[8d526d62db907e786fd88948c75d1833d82bd80e]

WANG Cong (2):
igmp: acquire pmc lock for ip_mc_clear_src()
[c38b7d327aafd1e3ad7ff53eefac990673b65667]
igmp: add a missing spin_lock_init()
[b4846fc3c8559649277e3e4e6b5cec5348a8d208]

Wengang Wang (1):
fs/ocfs2: fix race in ocfs2_dentry_attach_lock()
[be99ca2716972a712cde46092c54dee5e6192bf8]

Willem de Bruijn (1):
can: purge socket error queue on sock destruct
[fd704bd5ee749d560e86c4f1fd2ef486d8abf7cf]

Xin Long (1):
sctp: change to hold sk after auth shkey is created successfully
[25bff6d5478b2a02368097015b7d8eb727c87e16]

Yabin Cui (1):
perf/ring_buffer: Fix exposing a temporarily decreased data_head
[1b038c6e05ff70a1e66e3e571c2e6106bdb75f53]

Yingjoe Chen (1):
i2c: dev: fix potential memory leak in i2cdev_ioctl_rdwr
[a0692f0eef91354b62c2b4c94954536536be5425]

YueHaibing (4):
bonding: Add vlan tx offload to hw_enc_features
[d595b03de2cb0bdf9bcdf35ff27840cc3a37158f]
bonding: Always enable vlan tx offload
[30d8177e8ac776d89d387fad547af6a0f599210e]
can: af_can: Fix error path of can_init()
[c5a3aed1cd3152429348ee1fe5cdcca65fe901ce]
spi: bitbang: Fix NULL pointer dereference in spi_unregister_master
[5caaf29af5ca82d5da8bc1d0ad07d9e664ccf1d8]

Yunjian Wang (1):
net/mlx4_core: Change the error print to info print
[00f9fec48157f3734e52130a119846e67a12314b]

Zhenliang Wei (1):
kernel/signal.c: trace_signal_deliver when signal_group_exit
[98af37d624ed8c83f1953b1b6b2f6866011fc064]

Zhu Yanjun (1):
net: rds: fix memory leak in rds_ib_flush_mr_pool
[85cb928787eab6a2f4ca9d2a798b6f3bed53ced1]

Makefile | 4 +-
arch/arm64/kvm/guest.c | 49 ++++++++++++---
arch/mips/mm/tlbex.c | 29 ++++++---
arch/powerpc/perf/core-book3s.c | 8 ++-
arch/powerpc/perf/power8-pmu.c | 3 +
arch/s390/crypto/aes_s390.c | 10 +--
arch/s390/crypto/des_s390.c | 9 +--
arch/x86/kernel/apic/apic.c | 3 +-
arch/x86/kernel/cpu/bugs.c | 11 +++-
block/blk-mq-tag.c | 2 +-
crypto/crypto_user.c | 3 +
drivers/ata/libata-core.c | 9 ++-
drivers/gpio/Kconfig | 1 +
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +
drivers/gpu/drm/gma500/intel_bios.c | 3 +
drivers/gpu/drm/gma500/psb_drv.h | 1 +
drivers/hwmon/pmbus/pmbus_core.c | 34 ++++++++--
drivers/i2c/busses/i2c-acorn.c | 1 +
drivers/i2c/i2c-dev.c | 1 +
drivers/input/misc/uinput.c | 22 ++++++-
drivers/md/bcache/bset.c | 16 ++++-
drivers/md/bcache/bset.h | 34 +++++-----
drivers/misc/genwqe/card_dev.c | 2 +
drivers/misc/genwqe/card_utils.c | 4 ++
drivers/net/bonding/bond_main.c | 6 +-
drivers/net/can/flexcan.c | 2 +-
drivers/net/ethernet/dec/tulip/de4x5.c | 1 -
drivers/net/ethernet/emulex/benet/be_ethtool.c | 30 ++++++---
drivers/net/ethernet/mellanox/mlx4/mcg.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 3 +-
drivers/parisc/ccio-dma.c | 4 +-
drivers/parisc/sba_iommu.c | 3 +-
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/scsi/zfcp_ext.h | 1 +
drivers/s390/scsi/zfcp_scsi.c | 9 +++
drivers/s390/scsi/zfcp_sysfs.c | 55 +++++++++++++++--
drivers/s390/scsi/zfcp_unit.c | 8 ++-
drivers/scsi/bnx2fc/bnx2fc_hwi.c | 2 +-
drivers/scsi/ufs/ufshcd-pltfrm.c | 11 ++--
drivers/scsi/vmw_pvscsi.c | 6 +-
drivers/spi/spi-bitbang.c | 2 +-
drivers/staging/iio/cdc/ad7150.c | 23 ++++---
drivers/staging/usbip/stub_dev.c | 75 ++++++++++++++++-------
drivers/target/target_core_iblock.c | 2 +-
drivers/tty/serial/max310x.c | 2 +-
drivers/tty/serial/sh-sci.c | 7 +++
drivers/usb/core/config.c | 4 +-
drivers/usb/core/quirks.c | 6 ++
drivers/usb/host/xhci.c | 2 +-
drivers/usb/misc/rio500.c | 17 ++++-
drivers/usb/serial/pl2303.c | 1 +
drivers/usb/serial/pl2303.h | 3 +
drivers/usb/storage/unusual_realtek.h | 5 ++
fs/btrfs/file.c | 12 ++++
fs/btrfs/reada.c | 7 +++
fs/cifs/cifsfs.c | 1 +
fs/cifs/cifsglob.h | 5 ++
fs/cifs/file.c | 12 +++-
fs/cifs/smb2maperror.c | 2 +-
fs/configfs/dir.c | 14 ++---
fs/ocfs2/dcache.c | 12 ++++
include/linux/sched.h | 4 ++
kernel/cpu.c | 3 +
kernel/cred.c | 9 +++
kernel/events/core.c | 5 +-
kernel/events/ring_buffer.c | 33 ++++++++--
kernel/ptrace.c | 20 +++++-
kernel/signal.c | 2 +
kernel/trace/trace.c | 10 +--
lib/mpi/mpi-pow.c | 6 +-
mm/huge_memory.c | 2 +
net/can/af_can.c | 24 +++++++-
net/core/dev.c | 2 +-
net/core/neighbour.c | 7 +++
net/core/pktgen.c | 11 ++++
net/ipv4/igmp.c | 53 +++++++++++-----
net/ipv6/ip6_flowlabel.c | 7 ++-
net/iucv/af_iucv.c | 33 +++++++---
net/llc/llc_output.c | 2 +
net/rds/ib_rdma.c | 10 +--
net/sched/sch_netem.c | 13 ++--
net/sctp/endpointola.c | 8 +--
net/wireless/core.c | 2 +-
security/apparmor/policy_unpack.c | 2 +-
sound/core/seq/oss/seq_oss_ioctl.c | 2 +-
sound/core/seq/oss/seq_oss_rw.c | 2 +-
sound/soc/codecs/cs42xx8.c | 1 +
87 files changed, 683 insertions(+), 211 deletions(-)

--
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


2019-10-02 19:08:58

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 17/87] net: stmmac: fix reset gpio free missing

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Jisheng Zhang <[email protected]>

commit 49ce881c0d4c4a7a35358d9dccd5f26d0e56fc61 upstream.

Commit 984203ceff27 ("net: stmmac: mdio: remove reset gpio free")
removed the reset gpio free, when the driver is unbinded or rmmod,
we miss the gpio free.

This patch uses managed API to request the reset gpio, so that the
gpio could be freed properly.

Fixes: 984203ceff27 ("net: stmmac: mdio: remove reset gpio free")
Signed-off-by: Jisheng Zhang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -159,7 +159,8 @@ int stmmac_mdio_reset(struct mii_bus *bu
reset_gpio = data->reset_gpio;
active_low = data->active_low;

- if (!gpio_request(reset_gpio, "mdio-reset")) {
+ if (!devm_gpio_request(priv->device, reset_gpio,
+ "mdio-reset")) {
gpio_direction_output(reset_gpio, active_low ? 1 : 0);
udelay(data->delays[0]);
gpio_set_value(reset_gpio, active_low ? 0 : 1);

2019-10-02 19:08:59

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 18/87] igmp: acquire pmc lock for ip_mc_clear_src()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: WANG Cong <[email protected]>

commit c38b7d327aafd1e3ad7ff53eefac990673b65667 upstream.

Andrey reported a use-after-free in add_grec():

for (psf = *psf_list; psf; psf = psf_next) {
...
psf_next = psf->sf_next;

where the struct ip_sf_list's were already freed by:

kfree+0xe8/0x2b0 mm/slub.c:3882
ip_mc_clear_src+0x69/0x1c0 net/ipv4/igmp.c:2078
ip_mc_dec_group+0x19a/0x470 net/ipv4/igmp.c:1618
ip_mc_drop_socket+0x145/0x230 net/ipv4/igmp.c:2609
inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411
sock_release+0x8d/0x1e0 net/socket.c:597
sock_close+0x16/0x20 net/socket.c:1072

This happens because we don't hold pmc->lock in ip_mc_clear_src()
and a parallel mr_ifc_timer timer could jump in and access them.

The RCU lock is there but it is merely for pmc itself, this
spinlock could actually ensure we don't access them in parallel.

Thanks to Eric and Long for discussion on this bug.

Reported-by: Andrey Konovalov <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: Xin Long <[email protected]>
Signed-off-by: Cong Wang <[email protected]>
Reviewed-by: Xin Long <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/ipv4/igmp.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)

--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1880,21 +1880,26 @@ static int ip_mc_add_src(struct in_devic

static void ip_mc_clear_src(struct ip_mc_list *pmc)
{
- struct ip_sf_list *psf, *nextpsf;
+ struct ip_sf_list *psf, *nextpsf, *tomb, *sources;

- for (psf = pmc->tomb; psf; psf = nextpsf) {
+ spin_lock_bh(&pmc->lock);
+ tomb = pmc->tomb;
+ pmc->tomb = NULL;
+ sources = pmc->sources;
+ pmc->sources = NULL;
+ pmc->sfmode = MCAST_EXCLUDE;
+ pmc->sfcount[MCAST_INCLUDE] = 0;
+ pmc->sfcount[MCAST_EXCLUDE] = 1;
+ spin_unlock_bh(&pmc->lock);
+
+ for (psf = tomb; psf; psf = nextpsf) {
nextpsf = psf->sf_next;
kfree(psf);
}
- pmc->tomb = NULL;
- for (psf = pmc->sources; psf; psf = nextpsf) {
+ for (psf = sources; psf; psf = nextpsf) {
nextpsf = psf->sf_next;
kfree(psf);
}
- pmc->sources = NULL;
- pmc->sfmode = MCAST_EXCLUDE;
- pmc->sfcount[MCAST_INCLUDE] = 0;
- pmc->sfcount[MCAST_EXCLUDE] = 1;
}



2019-10-02 19:09:04

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 28/87] net: tulip: de4x5: Drop redundant MODULE_DEVICE_TABLE()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Kees Cook <[email protected]>

commit 3e66b7cc50ef921121babc91487e1fb98af1ba6e upstream.

Building with Clang reports the redundant use of MODULE_DEVICE_TABLE():

drivers/net/ethernet/dec/tulip/de4x5.c:2110:1: error: redefinition of '__mod_eisa__de4x5_eisa_ids_device_table'
MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
^
./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
extern typeof(name) __mod_##type##__##name##_device_table \
^
<scratch space>:90:1: note: expanded from here
__mod_eisa__de4x5_eisa_ids_device_table
^
drivers/net/ethernet/dec/tulip/de4x5.c:2100:1: note: previous definition is here
MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
^
./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE'
extern typeof(name) __mod_##type##__##name##_device_table \
^
<scratch space>:85:1: note: expanded from here
__mod_eisa__de4x5_eisa_ids_device_table
^

This drops the one further from the table definition to match the common
use of MODULE_DEVICE_TABLE().

Fixes: 07563c711fbc ("EISA bus MODALIAS attributes support")
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/net/ethernet/dec/tulip/de4x5.c | 1 -
1 file changed, 1 deletion(-)

--- a/drivers/net/ethernet/dec/tulip/de4x5.c
+++ b/drivers/net/ethernet/dec/tulip/de4x5.c
@@ -2107,7 +2107,6 @@ static struct eisa_driver de4x5_eisa_dri
.remove = de4x5_eisa_remove,
}
};
-MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids);
#endif

#ifdef CONFIG_PCI

2019-10-02 19:09:10

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 32/87] configfs: Fix use-after-free when accessing sd->s_dentry

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Sahitya Tummala <[email protected]>

commit f6122ed2a4f9c9c1c073ddf6308d1b2ac10e0781 upstream.

In the vfs_statx() context, during path lookup, the dentry gets
added to sd->s_dentry via configfs_attach_attr(). In the end,
vfs_statx() kills the dentry by calling path_put(), which invokes
configfs_d_iput(). Ideally, this dentry must be removed from
sd->s_dentry but it doesn't if the sd->s_count >= 3. As a result,
sd->s_dentry is holding reference to a stale dentry pointer whose
memory is already freed up. This results in use-after-free issue,
when this stale sd->s_dentry is accessed later in
configfs_readdir() path.

This issue can be easily reproduced, by running the LTP test case -
sh fs_racer_file_list.sh /config
(https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/racer/fs_racer_file_list.sh)

Fixes: 76ae281f6307 ('configfs: fix race between dentry put and lookup')
Signed-off-by: Sahitya Tummala <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
fs/configfs/dir.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)

--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -58,15 +58,13 @@ static void configfs_d_iput(struct dentr
if (sd) {
/* Coordinate with configfs_readdir */
spin_lock(&configfs_dirent_lock);
- /* Coordinate with configfs_attach_attr where will increase
- * sd->s_count and update sd->s_dentry to new allocated one.
- * Only set sd->dentry to null when this dentry is the only
- * sd owner.
- * If not do so, configfs_d_iput may run just after
- * configfs_attach_attr and set sd->s_dentry to null
- * even it's still in use.
+ /*
+ * Set sd->s_dentry to null only when this dentry is the one
+ * that is going to be killed. Otherwise configfs_d_iput may
+ * run just after configfs_attach_attr and set sd->s_dentry to
+ * NULL even it's still in use.
*/
- if (atomic_read(&sd->s_count) <= 2)
+ if (sd->s_dentry == dentry)
sd->s_dentry = NULL;

spin_unlock(&configfs_dirent_lock);

2019-10-02 19:09:19

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 46/87] parisc: Use implicit space register selection for loading the coherence index of I/O pdirs

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: John David Anglin <[email protected]>

commit 63923d2c3800919774f5c651d503d1dd2adaddd5 upstream.

We only support I/O to kernel space. Using %sr1 to load the coherence
index may be racy unless interrupts are disabled. This patch changes the
code used to load the coherence index to use implicit space register
selection. This saves one instruction and eliminates the race.

Tested on rp3440, c8000 and c3750.

Signed-off-by: John David Anglin <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/parisc/ccio-dma.c | 4 +---
drivers/parisc/sba_iommu.c | 3 +--
2 files changed, 2 insertions(+), 5 deletions(-)

--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -563,8 +563,6 @@ ccio_io_pdir_entry(u64 *pdir_ptr, space_
/* We currently only support kernel addresses */
BUG_ON(sid != KERNEL_SPACE);

- mtsp(sid,1);
-
/*
** WORD 1 - low order word
** "hints" parm includes the VALID bit!
@@ -595,7 +593,7 @@ ccio_io_pdir_entry(u64 *pdir_ptr, space_
** Grab virtual index [0:11]
** Deposit virt_idx bits into I/O PDIR word
*/
- asm volatile ("lci %%r0(%%sr1, %1), %0" : "=r" (ci) : "r" (vba));
+ asm volatile ("lci %%r0(%1), %0" : "=r" (ci) : "r" (vba));
asm volatile ("extru %1,19,12,%0" : "+r" (ci) : "r" (ci));
asm volatile ("depw %1,15,12,%0" : "+r" (pa) : "r" (ci));

--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -573,8 +573,7 @@ sba_io_pdir_entry(u64 *pdir_ptr, space_t
pa = virt_to_phys(vba);
pa &= IOVP_MASK;

- mtsp(sid,1);
- asm("lci 0(%%sr1, %1), %0" : "=r" (ci) : "r" (vba));
+ asm("lci 0(%1), %0" : "=r" (ci) : "r" (vba));
pa |= (ci >> PAGE_SHIFT) & 0xff; /* move CI (8 bits) into lowest byte */

pa |= SBA_PDIR_VALID_BIT; /* set "valid" bit */

2019-10-02 19:09:26

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 87/87] crypto: user - prevent operating on larval algorithms

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Eric Biggers <[email protected]>

commit 21d4120ec6f5b5992b01b96ac484701163917b63 upstream.

Michal Suchanek reported [1] that running the pcrypt_aead01 test from
LTP [2] in a loop and holding Ctrl-C causes a NULL dereference of
alg->cra_users.next in crypto_remove_spawns(), via crypto_del_alg().
The test repeatedly uses CRYPTO_MSG_NEWALG and CRYPTO_MSG_DELALG.

The crash occurs when the instance that CRYPTO_MSG_DELALG is trying to
unregister isn't a real registered algorithm, but rather is a "test
larval", which is a special "algorithm" added to the algorithms list
while the real algorithm is still being tested. Larvals don't have
initialized cra_users, so that causes the crash. Normally pcrypt_aead01
doesn't trigger this because CRYPTO_MSG_NEWALG waits for the algorithm
to be tested; however, CRYPTO_MSG_NEWALG returns early when interrupted.

Everything else in the "crypto user configuration" API has this same bug
too, i.e. it inappropriately allows operating on larval algorithms
(though it doesn't look like the other cases can cause a crash).

Fix this by making crypto_alg_match() exclude larval algorithms.

[1] https://lkml.kernel.org/r/[email protected]
[2] https://github.com/linux-test-project/ltp/blob/20190517/testcases/kernel/crypto/pcrypt_aead01.c

Reported-by: Michal Suchanek <[email protected]>
Fixes: a38f7907b926 ("crypto: Add userspace configuration API")
Cc: Steffen Klassert <[email protected]>
Signed-off-by: Eric Biggers <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <[email protected]>
---
crypto/crypto_user.c | 3 +++
1 file changed, 3 insertions(+)

--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user.c
@@ -53,6 +53,9 @@ static struct crypto_alg *crypto_alg_mat
list_for_each_entry(q, &crypto_alg_list, cra_list) {
int match = 0;

+ if (crypto_is_larval(q))
+ continue;
+
if ((q->cra_flags ^ p->cru_type) & p->cru_mask)
continue;


2019-10-02 19:09:36

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 78/87] x86/speculation: Allow guests to use SSBD even if host does not

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Alejandro Jimenez <[email protected]>

commit c1f7fec1eb6a2c86d01bc22afce772c743451d88 upstream.

The bits set in x86_spec_ctrl_mask are used to calculate the guest's value
of SPEC_CTRL that is written to the MSR before VMENTRY, and control which
mitigations the guest can enable. In the case of SSBD, unless the host has
enabled SSBD always on mode (by passing "spec_store_bypass_disable=on" in
the kernel parameters), the SSBD bit is not set in the mask and the guest
can not properly enable the SSBD always on mitigation mode.

This has been confirmed by running the SSBD PoC on a guest using the SSBD
always on mitigation mode (booted with kernel parameter
"spec_store_bypass_disable=on"), and verifying that the guest is vulnerable
unless the host is also using SSBD always on mode. In addition, the guest
OS incorrectly reports the SSB vulnerability as mitigated.

Always set the SSBD bit in x86_spec_ctrl_mask when the host CPU supports
it, allowing the guest to use SSBD whether or not the host has chosen to
enable the mitigation in any of its modes.

Fixes: be6fcb5478e9 ("x86/bugs: Rework spec_ctrl base and mask logic")
Signed-off-by: Alejandro Jimenez <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Liam Merwick <[email protected]>
Reviewed-by: Mark Kanda <[email protected]>
Reviewed-by: Paolo Bonzini <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ben Hutchings <[email protected]>
---
arch/x86/kernel/cpu/bugs.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -960,6 +960,16 @@ static enum ssb_mitigation __init __ssb_
}

/*
+ * If SSBD is controlled by the SPEC_CTRL MSR, then set the proper
+ * bit in the mask to allow guests to use the mitigation even in the
+ * case where the host does not enable it.
+ */
+ if (static_cpu_has(X86_FEATURE_SPEC_CTRL_SSBD) ||
+ static_cpu_has(X86_FEATURE_AMD_SSBD)) {
+ x86_spec_ctrl_mask |= SPEC_CTRL_SSBD;
+ }
+
+ /*
* We have three CPU feature flags that are in play here:
* - X86_BUG_SPEC_STORE_BYPASS - CPU is susceptible.
* - X86_FEATURE_SSBD - CPU is able to turn off speculative store bypass
@@ -976,7 +986,6 @@ static enum ssb_mitigation __init __ssb_
x86_amd_ssb_disable();
} else {
x86_spec_ctrl_base |= SPEC_CTRL_SSBD;
- x86_spec_ctrl_mask |= SPEC_CTRL_SSBD;
wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
}
}

2019-10-02 19:09:47

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 26/87] gpio: fix gpio-adp5588 build errors

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Randy Dunlap <[email protected]>

commit e9646f0f5bb62b7d43f0968f39d536cfe7123b53 upstream.

The gpio-adp5588 driver uses interfaces that are provided by
GPIOLIB_IRQCHIP, so select that symbol in its Kconfig entry.

Fixes these build errors:

../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_handler’:
../drivers/gpio/gpio-adp5588.c:266:26: error: ‘struct gpio_chip’ has no member named ‘irq’
dev->gpio_chip.irq.domain, gpio));
^
../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_setup’:
../drivers/gpio/gpio-adp5588.c:298:2: error: implicit declaration of function ‘gpiochip_irqchip_add_nested’ [-Werror=implicit-function-declaration]
ret = gpiochip_irqchip_add_nested(&dev->gpio_chip,
^
../drivers/gpio/gpio-adp5588.c:307:2: error: implicit declaration of function ‘gpiochip_set_nested_irqchip’ [-Werror=implicit-function-declaration]
gpiochip_set_nested_irqchip(&dev->gpio_chip,
^

Fixes: 459773ae8dbb ("gpio: adp5588-gpio: support interrupt controller")
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Randy Dunlap <[email protected]>
Cc: [email protected]
Reviewed-by: Bartosz Golaszewski <[email protected]>
Acked-by: Michael Hennerich <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/gpio/Kconfig | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -654,6 +654,7 @@ config GPIO_ADP5588
config GPIO_ADP5588_IRQ
bool "Interrupt controller support for ADP5588"
depends on GPIO_ADP5588=y
+ select GPIOLIB_IRQCHIP
help
Say yes here to enable the adp5588 to be used as an interrupt
controller. It requires the driver to be built in the kernel.

2019-10-02 19:09:55

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 85/87] scsi: target/iblock: Fix overrun in WRITE SAME emulation

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Roman Bolshakov <[email protected]>

commit 5676234f20fef02f6ca9bd66c63a8860fce62645 upstream.

WRITE SAME corrupts data on the block device behind iblock if the command
is emulated. The emulation code issues (M - 1) * N times more bios than
requested, where M is the number of 512 blocks per real block size and N is
the NUMBER OF LOGICAL BLOCKS specified in WRITE SAME command. So, for a
device with 4k blocks, 7 * N more LBAs gets written after the requested
range.

The issue happens because the number of 512 byte sectors to be written is
decreased one by one while the real bios are typically from 1 to 8 512 byte
sectors per bio.

Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6")
Signed-off-by: Roman Bolshakov <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
[bwh: Backported to 3.16: use IBLOCK_LBA_SHIFT instead of SECTOR_SHIFT]
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/target/target_core_iblock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -490,7 +490,7 @@ iblock_execute_write_same(struct se_cmd

/* Always in 512 byte units for Linux/Block */
block_lba += sg->length >> IBLOCK_LBA_SHIFT;
- sectors -= 1;
+ sectors -= sg->length >> IBLOCK_LBA_SHIFT;
}

iblock_submit_bios(&list, WRITE);

2019-10-02 19:09:56

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 86/87] lib/mpi: Fix karactx leak in mpi_powm

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Herbert Xu <[email protected]>

commit c8ea9fce2baf7b643384f36f29e4194fa40d33a6 upstream.

Sometimes mpi_powm will leak karactx because a memory allocation
failure causes a bail-out that skips the freeing of karactx. This
patch moves the freeing of karactx to the end of the function like
everything else so that it can't be skipped.

Reported-by: [email protected]
Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files...")
Signed-off-by: Herbert Xu <[email protected]>
Reviewed-by: Eric Biggers <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
lib/mpi/mpi-pow.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

--- a/lib/mpi/mpi-pow.c
+++ b/lib/mpi/mpi-pow.c
@@ -36,6 +36,7 @@
int mpi_powm(MPI res, MPI base, MPI exp, MPI mod)
{
mpi_ptr_t mp_marker = NULL, bp_marker = NULL, ep_marker = NULL;
+ struct karatsuba_ctx karactx = {};
mpi_ptr_t xp_marker = NULL;
mpi_ptr_t tspace = NULL;
mpi_ptr_t rp, ep, mp, bp;
@@ -163,13 +164,11 @@ int mpi_powm(MPI res, MPI base, MPI exp,
int c;
mpi_limb_t e;
mpi_limb_t carry_limb;
- struct karatsuba_ctx karactx;

xp = xp_marker = mpi_alloc_limb_space(2 * (msize + 1));
if (!xp)
goto enomem;

- memset(&karactx, 0, sizeof karactx);
negative_result = (ep[0] & 1) && base->sign;

i = esize - 1;
@@ -293,8 +292,6 @@ int mpi_powm(MPI res, MPI base, MPI exp,
if (mod_shift_cnt)
mpihelp_rshift(rp, rp, rsize, mod_shift_cnt);
MPN_NORMALIZE(rp, rsize);
-
- mpihelp_release_karatsuba_ctx(&karactx);
}

if (negative_result && rsize) {
@@ -311,6 +308,7 @@ int mpi_powm(MPI res, MPI base, MPI exp,
leave:
rc = 0;
enomem:
+ mpihelp_release_karatsuba_ctx(&karactx);
if (assign_rp)
mpi_assign_limb_space(res, rp, size);
if (mp_marker)

2019-10-02 19:10:07

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 50/87] can: af_can: Fix error path of can_init()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: YueHaibing <[email protected]>

commit c5a3aed1cd3152429348ee1fe5cdcca65fe901ce upstream.

This patch add error path for can_init() to avoid possible crash if some
error occurs.

Fixes: 0d66548a10cb ("[CAN]: Add PF_CAN core module")
Signed-off-by: YueHaibing <[email protected]>
Acked-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
[bwh: Backported to 3.16:
- af_can doesn't register any pernet_operations
- It does start a global timer and add procfs entries that need to be
cleaned up on the error path]
Signed-off-by: Ben Hutchings <[email protected]>
---
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -899,6 +899,8 @@ static struct notifier_block can_netdev_

static __init int can_init(void)
{
+ int err;
+
/* check for correct padding to be able to use the structs similarly */
BUILD_BUG_ON(offsetof(struct can_frame, can_dlc) !=
offsetof(struct canfd_frame, len) ||
@@ -924,12 +926,29 @@ static __init int can_init(void)
can_init_proc();

/* protocol register */
- sock_register(&can_family_ops);
- register_netdevice_notifier(&can_netdev_notifier);
+ err = sock_register(&can_family_ops);
+ if (err)
+ goto out_sock;
+ err = register_netdevice_notifier(&can_netdev_notifier);
+ if (err)
+ goto out_notifier;
+
dev_add_pack(&can_packet);
dev_add_pack(&canfd_packet);

return 0;
+
+out_notifier:
+ sock_unregister(PF_CAN);
+out_sock:
+ kmem_cache_destroy(rcv_cache);
+
+ if (stats_timer)
+ del_timer_sync(&can_stattimer);
+
+ can_remove_proc();
+
+ return err;
}

static __exit void can_exit(void)

2019-10-02 19:10:10

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 44/87] s390/qeth: fix VLAN attribute in bridge_hostnotify udev event

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Alexandra Winter <[email protected]>

commit 335726195e460cb6b3f795b695bfd31f0ea70ef0 upstream.

Enabling sysfs attribute bridge_hostnotify triggers a series of udev events
for the MAC addresses of all currently connected peers. In case no VLAN is
set for a peer, the device reports the corresponding MAC addresses with
VLAN ID 4096. This currently results in attribute VLAN=4096 for all
non-VLAN interfaces in the initial series of events after host-notify is
enabled.

Instead, no VLAN attribute should be reported in the udev event for
non-VLAN interfaces.

Only the initial events face this issue. For dynamic changes that are
reported later, the device uses a validity flag.

This also changes the code so that it now sets the VLAN attribute for
MAC addresses with VID 0. On Linux, no qeth interface will ever be
registered with VID 0: Linux kernel registers VID 0 on all network
interfaces initially, but qeth will drop .ndo_vlan_rx_add_vid for VID 0.
Peers with other OSs could register MACs with VID 0.

Fixes: 9f48b9db9a22 ("qeth: bridgeport support - address notifications")
Signed-off-by: Alexandra Winter <[email protected]>
Signed-off-by: Julian Wiedmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/s390/net/qeth_l2_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -1956,7 +1956,7 @@ static void qeth_bridgeport_an_set_cb(vo

l2entry = (struct qdio_brinfo_entry_l2 *)entry;
code = IPA_ADDR_CHANGE_CODE_MACADDR;
- if (l2entry->addr_lnid.lnid)
+ if (l2entry->addr_lnid.lnid < VLAN_N_VID)
code |= IPA_ADDR_CHANGE_CODE_VLANID;
qeth_bridge_emit_host_event(card, anev_reg_unreg, code,
(struct net_if_token *)&l2entry->nit,

2019-10-02 19:10:20

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 25/87] perf/ring_buffer: Add ordering to rb->nest increment

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Peter Zijlstra <[email protected]>

commit 3f9fbe9bd86c534eba2faf5d840fd44c6049f50e upstream.

Similar to how decrementing rb->next too early can cause data_head to
(temporarily) be observed to go backward, so too can this happen when
we increment too late.

This barrier() ensures the rb->head load happens after the increment,
both the one in the 'goto again' path, as the one from
perf_output_get_handle() -- albeit very unlikely to matter for the
latter.

Suggested-by: Yabin Cui <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Fixes: ef60777c9abd ("perf: Optimize the perf_output() path by removing IRQ-disables")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
kernel/events/ring_buffer.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -47,6 +47,15 @@ static void perf_output_put_handle(struc
unsigned long head;

again:
+ /*
+ * In order to avoid publishing a head value that goes backwards,
+ * we must ensure the load of @rb->head happens after we've
+ * incremented @rb->nest.
+ *
+ * Otherwise we can observe a @rb->head value before one published
+ * by an IRQ/NMI happening between the load and the increment.
+ */
+ barrier();
head = local_read(&rb->head);

/*

2019-10-02 19:10:26

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 24/87] perf/ring_buffer: Fix exposing a temporarily decreased data_head

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Yabin Cui <[email protected]>

commit 1b038c6e05ff70a1e66e3e571c2e6106bdb75f53 upstream.

In perf_output_put_handle(), an IRQ/NMI can happen in below location and
write records to the same ring buffer:

...
local_dec_and_test(&rb->nest)
... <-- an IRQ/NMI can happen here
rb->user_page->data_head = head;
...

In this case, a value A is written to data_head in the IRQ, then a value
B is written to data_head after the IRQ. And A > B. As a result,
data_head is temporarily decreased from A to B. And a reader may see
data_head < data_tail if it read the buffer frequently enough, which
creates unexpected behaviors.

This can be fixed by moving dec(&rb->nest) to after updating data_head,
which prevents the IRQ/NMI above from updating data_head.

[ Split up by peterz. ]

Signed-off-by: Yabin Cui <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Cc: [email protected]
Fixes: ef60777c9abd ("perf: Optimize the perf_output() path by removing IRQ-disables")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
kernel/events/ring_buffer.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)

--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -50,11 +50,18 @@ again:
head = local_read(&rb->head);

/*
- * IRQ/NMI can happen here, which means we can miss a head update.
+ * IRQ/NMI can happen here and advance @rb->head, causing our
+ * load above to be stale.
*/

- if (!local_dec_and_test(&rb->nest))
+ /*
+ * If this isn't the outermost nesting, we don't have to update
+ * @rb->user_page->data_head.
+ */
+ if (local_read(&rb->nest) > 1) {
+ local_dec(&rb->nest);
goto out;
+ }

/*
* Since the mmap() consumer (userspace) can run on a different CPU:
@@ -86,9 +93,18 @@ again:
rb->user_page->data_head = head;

/*
- * Now check if we missed an update -- rely on previous implied
- * compiler barriers to force a re-read.
+ * We must publish the head before decrementing the nest count,
+ * otherwise an IRQ/NMI can publish a more recent head value and our
+ * write will (temporarily) publish a stale value.
+ */
+ barrier();
+ local_set(&rb->nest, 0);
+
+ /*
+ * Ensure we decrement @rb->nest before we validate the @rb->head.
+ * Otherwise we cannot be sure we caught the 'last' nested update.
*/
+ barrier();
if (unlikely(head != local_read(&rb->head))) {
local_inc(&rb->nest);
goto again;

2019-10-02 19:10:29

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 79/87] cpu/speculation: Warn on unsupported mitigations= parameter

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Geert Uytterhoeven <[email protected]>

commit 1bf72720281770162c87990697eae1ba2f1d917a upstream.

Currently, if the user specifies an unsupported mitigation strategy on the
kernel command line, it will be ignored silently. The code will fall back
to the default strategy, possibly leaving the system more vulnerable than
expected.

This may happen due to e.g. a simple typo, or, for a stable kernel release,
because not all mitigation strategies have been backported.

Inform the user by printing a message.

Fixes: 98af8452945c5565 ("cpu/speculation: Add 'mitigations=' cmdline option")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Josh Poimboeuf <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ben Hutchings <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
kernel/cpu.c | 3 +++
1 file changed, 3 insertions(+)

--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -804,6 +804,9 @@ static int __init mitigations_parse_cmdl
cpu_mitigations = CPU_MITIGATIONS_OFF;
else if (!strcmp(arg, "auto"))
cpu_mitigations = CPU_MITIGATIONS_AUTO;
+ else
+ pr_crit("Unsupported mitigations=%s, system may still be vulnerable\n",
+ arg);

return 0;
}

2019-10-02 19:10:37

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 66/87] perf/core: Fix perf_sample_regs_user() mm check

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Peter Zijlstra <[email protected]>

commit 085ebfe937d7a7a5df1729f35a12d6d655fea68c upstream.

perf_sample_regs_user() uses 'current->mm' to test for the presence of
userspace, but this is insufficient, consider use_mm().

A better test is: '!(current->flags & PF_KTHREAD)', exec() clears
PF_KTHREAD after it sets the new ->mm but before it drops to userspace
for the first time.

Possibly obsoletes: bf05fc25f268 ("powerpc/perf: Fix oops when kthread execs user process")

Reported-by: Ravi Bangoria <[email protected]>
Reported-by: Young Xiao <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Acked-by: Will Deacon <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Naveen N. Rao <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Fixes: 4018994f3d87 ("perf: Add ability to attach user level registers dump to sample")
Signed-off-by: Ingo Molnar <[email protected]>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
kernel/events/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4581,7 +4581,7 @@ static void perf_sample_regs_user(struct
struct pt_regs *regs)
{
if (!user_mode(regs)) {
- if (current->mm)
+ if (!(current->flags & PF_KTHREAD))
regs = task_pt_regs(current);
else
regs = NULL;

2019-10-02 19:10:38

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 29/87] staging: iio: cdc: Don't put an else right after a return

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Catalina Mocanu <[email protected]>

commit 288903f6b91e759b0a813219acd376426cbb8f14 upstream.

This fixes the following checkpatch.pl warning:
WARNING: else is not generally useful after a break or return.

While at it, remove new line for symmetry with the rest of the code.

Signed-off-by: Catalina Mocanu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/staging/iio/cdc/ad7150.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)

--- a/drivers/staging/iio/cdc/ad7150.c
+++ b/drivers/staging/iio/cdc/ad7150.c
@@ -143,19 +143,15 @@ static int ad7150_read_event_config(stru
case IIO_EV_TYPE_MAG_ADAPTIVE:
if (dir == IIO_EV_DIR_RISING)
return adaptive && (threshtype == 0x1);
- else
- return adaptive && (threshtype == 0x0);
+ return adaptive && (threshtype == 0x0);
case IIO_EV_TYPE_THRESH_ADAPTIVE:
if (dir == IIO_EV_DIR_RISING)
return adaptive && (threshtype == 0x3);
- else
- return adaptive && (threshtype == 0x2);
-
+ return adaptive && (threshtype == 0x2);
case IIO_EV_TYPE_THRESH:
if (dir == IIO_EV_DIR_RISING)
return !adaptive && (threshtype == 0x1);
- else
- return !adaptive && (threshtype == 0x0);
+ return !adaptive && (threshtype == 0x0);
default:
break;
}

2019-10-02 19:10:49

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 72/87] net/af_iucv: always register net_device notifier

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Julian Wiedmann <[email protected]>

commit 06996c1d4088a0d5f3e7789d7f96b4653cc947cc upstream.

Even when running as VM guest (ie pr_iucv != NULL), af_iucv can still
open HiperTransport-based connections. For robust operation these
connections require the af_iucv_netdev_notifier, so register it
unconditionally.

Also handle any error that register_netdevice_notifier() returns.

Fixes: 9fbd87d41392 ("af_iucv: handle netdev events")
Signed-off-by: Julian Wiedmann <[email protected]>
Reviewed-by: Ursula Braun <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/iucv/af_iucv.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)

--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -2399,6 +2399,13 @@ out:
return err;
}

+static void afiucv_iucv_exit(void)
+{
+ device_unregister(af_iucv_dev);
+ driver_unregister(&af_iucv_driver);
+ pr_iucv->iucv_unregister(&af_iucv_handler, 0);
+}
+
static int __init afiucv_init(void)
{
int err;
@@ -2432,11 +2439,18 @@ static int __init afiucv_init(void)
err = afiucv_iucv_init();
if (err)
goto out_sock;
- } else
- register_netdevice_notifier(&afiucv_netdev_notifier);
+ }
+
+ err = register_netdevice_notifier(&afiucv_netdev_notifier);
+ if (err)
+ goto out_notifier;
+
dev_add_pack(&iucv_packet_type);
return 0;

+out_notifier:
+ if (pr_iucv)
+ afiucv_iucv_exit();
out_sock:
sock_unregister(PF_IUCV);
out_proto:
@@ -2450,12 +2464,11 @@ out:
static void __exit afiucv_exit(void)
{
if (pr_iucv) {
- device_unregister(af_iucv_dev);
- driver_unregister(&af_iucv_driver);
- pr_iucv->iucv_unregister(&af_iucv_handler, 0);
+ afiucv_iucv_exit();
symbol_put(iucv_if);
- } else
- unregister_netdevice_notifier(&afiucv_netdev_notifier);
+ }
+
+ unregister_netdevice_notifier(&afiucv_netdev_notifier);
dev_remove_pack(&iucv_packet_type);
sock_unregister(PF_IUCV);
proto_unregister(&iucv_proto);

2019-10-02 19:11:02

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 65/87] neigh: fix use-after-free read in pneigh_get_next

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <[email protected]>

commit f3e92cb8e2eb8c27d109e6fd73d3a69a8c09e288 upstream.

Nine years ago, I added RCU handling to neighbours, not pneighbours.
(pneigh are not commonly used)

Unfortunately I missed that /proc dump operations would use a
common entry and exit point : neigh_seq_start() and neigh_seq_stop()

We need to read_lock(tbl->lock) or risk use-after-free while
iterating the pneigh structures.

We might later convert pneigh to RCU and revert this patch.

sysbot reported :

BUG: KASAN: use-after-free in pneigh_get_next.isra.0+0x24b/0x280 net/core/neighbour.c:3158
Read of size 8 at addr ffff888097f2a700 by task syz-executor.0/9825

CPU: 1 PID: 9825 Comm: syz-executor.0 Not tainted 5.2.0-rc4+ #32
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+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
__kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
kasan_report+0x12/0x20 mm/kasan/common.c:614
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
pneigh_get_next.isra.0+0x24b/0x280 net/core/neighbour.c:3158
neigh_seq_next+0xdb/0x210 net/core/neighbour.c:3240
seq_read+0x9cf/0x1110 fs/seq_file.c:258
proc_reg_read+0x1fc/0x2c0 fs/proc/inode.c:221
do_loop_readv_writev fs/read_write.c:714 [inline]
do_loop_readv_writev fs/read_write.c:701 [inline]
do_iter_read+0x4a4/0x660 fs/read_write.c:935
vfs_readv+0xf0/0x160 fs/read_write.c:997
kernel_readv fs/splice.c:359 [inline]
default_file_splice_read+0x475/0x890 fs/splice.c:414
do_splice_to+0x127/0x180 fs/splice.c:877
splice_direct_to_actor+0x2d2/0x970 fs/splice.c:954
do_splice_direct+0x1da/0x2a0 fs/splice.c:1063
do_sendfile+0x597/0xd00 fs/read_write.c:1464
__do_sys_sendfile64 fs/read_write.c:1525 [inline]
__se_sys_sendfile64 fs/read_write.c:1511 [inline]
__x64_sys_sendfile64+0x1dd/0x220 fs/read_write.c:1511
do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4592c9
Code: fd b7 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 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f4aab51dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00000000004592c9
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000005
RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000080000000 R11: 0000000000000246 R12: 00007f4aab51e6d4
R13: 00000000004c689d R14: 00000000004db828 R15: 00000000ffffffff

Allocated by task 9827:
save_stack+0x23/0x90 mm/kasan/common.c:71
set_track mm/kasan/common.c:79 [inline]
__kasan_kmalloc mm/kasan/common.c:489 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
__do_kmalloc mm/slab.c:3660 [inline]
__kmalloc+0x15c/0x740 mm/slab.c:3669
kmalloc include/linux/slab.h:552 [inline]
pneigh_lookup+0x19c/0x4a0 net/core/neighbour.c:731
arp_req_set_public net/ipv4/arp.c:1010 [inline]
arp_req_set+0x613/0x720 net/ipv4/arp.c:1026
arp_ioctl+0x652/0x7f0 net/ipv4/arp.c:1226
inet_ioctl+0x2a0/0x340 net/ipv4/af_inet.c:926
sock_do_ioctl+0xd8/0x2f0 net/socket.c:1043
sock_ioctl+0x3ed/0x780 net/socket.c:1194
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696
ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 9824:
save_stack+0x23/0x90 mm/kasan/common.c:71
set_track mm/kasan/common.c:79 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:451
kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
__cache_free mm/slab.c:3432 [inline]
kfree+0xcf/0x220 mm/slab.c:3755
pneigh_ifdown_and_unlock net/core/neighbour.c:812 [inline]
__neigh_ifdown+0x236/0x2f0 net/core/neighbour.c:356
neigh_ifdown+0x20/0x30 net/core/neighbour.c:372
arp_ifdown+0x1d/0x21 net/ipv4/arp.c:1274
inetdev_destroy net/ipv4/devinet.c:319 [inline]
inetdev_event+0xa14/0x11f0 net/ipv4/devinet.c:1544
notifier_call_chain+0xc2/0x230 kernel/notifier.c:95
__raw_notifier_call_chain kernel/notifier.c:396 [inline]
raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:403
call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1749
call_netdevice_notifiers_extack net/core/dev.c:1761 [inline]
call_netdevice_notifiers net/core/dev.c:1775 [inline]
rollback_registered_many+0x9b9/0xfc0 net/core/dev.c:8178
rollback_registered+0x109/0x1d0 net/core/dev.c:8220
unregister_netdevice_queue net/core/dev.c:9267 [inline]
unregister_netdevice_queue+0x1ee/0x2c0 net/core/dev.c:9260
unregister_netdevice include/linux/netdevice.h:2631 [inline]
__tun_detach+0xd8a/0x1040 drivers/net/tun.c:724
tun_detach drivers/net/tun.c:741 [inline]
tun_chr_close+0xe0/0x180 drivers/net/tun.c:3451
__fput+0x2ff/0x890 fs/file_table.c:280
____fput+0x16/0x20 fs/file_table.c:313
task_work_run+0x145/0x1c0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:185 [inline]
exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:168
prepare_exit_to_usermode arch/x86/entry/common.c:199 [inline]
syscall_return_slowpath arch/x86/entry/common.c:279 [inline]
do_syscall_64+0x58e/0x680 arch/x86/entry/common.c:304
entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at ffff888097f2a700
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 0 bytes inside of
64-byte region [ffff888097f2a700, ffff888097f2a740)
The buggy address belongs to the page:
page:ffffea00025fca80 refcount:1 mapcount:0 mapping:ffff8880aa400340 index:0x0
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea000250d548 ffffea00025726c8 ffff8880aa400340
raw: 0000000000000000 ffff888097f2a000 0000000100000020 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff888097f2a600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
ffff888097f2a680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>ffff888097f2a700: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff888097f2a780: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff888097f2a800: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc

Fixes: 767e97e1e0db ("neigh: RCU conversion of struct neighbour")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: syzbot <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/core/neighbour.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -2649,6 +2649,7 @@ static void *neigh_get_idx_any(struct se
}

void *neigh_seq_start(struct seq_file *seq, loff_t *pos, struct neigh_table *tbl, unsigned int neigh_seq_flags)
+ __acquires(tbl->lock)
__acquires(rcu_bh)
{
struct neigh_seq_state *state = seq->private;
@@ -2659,6 +2660,7 @@ void *neigh_seq_start(struct seq_file *s

rcu_read_lock_bh();
state->nht = rcu_dereference_bh(tbl->nht);
+ read_lock(&tbl->lock);

return *pos ? neigh_get_idx_any(seq, pos) : SEQ_START_TOKEN;
}
@@ -2692,8 +2694,13 @@ out:
EXPORT_SYMBOL(neigh_seq_next);

void neigh_seq_stop(struct seq_file *seq, void *v)
+ __releases(tbl->lock)
__releases(rcu_bh)
{
+ struct neigh_seq_state *state = seq->private;
+ struct neigh_table *tbl = state->tbl;
+
+ read_unlock(&tbl->lock);
rcu_read_unlock_bh();
}
EXPORT_SYMBOL(neigh_seq_stop);

2019-10-02 19:11:08

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 04/87] ASoC: cs42xx8: Add regcache mask dirty

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: "S.j. Wang" <[email protected]>

commit ad6eecbfc01c987e0253371f274c3872042e4350 upstream.

Add regcache_mark_dirty before regcache_sync for power
of codec may be lost at suspend, then all the register
need to be reconfigured.

Fixes: 0c516b4ff85c ("ASoC: cs42xx8: Add codec driver
support for CS42448/CS42888")
Signed-off-by: Shengjiu Wang <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
sound/soc/codecs/cs42xx8.c | 1 +
1 file changed, 1 insertion(+)

--- a/sound/soc/codecs/cs42xx8.c
+++ b/sound/soc/codecs/cs42xx8.c
@@ -557,6 +557,7 @@ static int cs42xx8_runtime_resume(struct
msleep(5);

regcache_cache_only(cs42xx8->regmap, false);
+ regcache_mark_dirty(cs42xx8->regmap);

ret = regcache_sync(cs42xx8->regmap);
if (ret) {

2019-10-02 19:11:11

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 69/87] net: netem: fix backlog accounting for corrupted GSO frames

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Jakub Kicinski <[email protected]>

commit 177b8007463c4f36c9a2c7ce7aa9875a4cad9bd5 upstream.

When GSO frame has to be corrupted netem uses skb_gso_segment()
to produce the list of frames, and re-enqueues the segments one
by one. The backlog length has to be adjusted to account for
new frames.

The current calculation is incorrect, leading to wrong backlog
lengths in the parent qdisc (both bytes and packets), and
incorrect packet backlog count in netem itself.

Parent backlog goes negative, netem's packet backlog counts
all non-first segments twice (thus remaining non-zero even
after qdisc is emptied).

Move the variables used to count the adjustment into local
scope to make 100% sure they aren't used at any stage in
backports.

Fixes: 6071bd1aa13e ("netem: Segment GSO packets on enqueue")
Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: Dirk van der Merwe <[email protected]>
Acked-by: Cong Wang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/sched/sch_netem.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)

--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -440,8 +440,7 @@ static int netem_enqueue(struct sk_buff
struct netem_skb_cb *cb;
struct sk_buff *skb2;
struct sk_buff *segs = NULL;
- unsigned int len = 0, last_len, prev_len = qdisc_pkt_len(skb);
- int nb = 0;
+ unsigned int prev_len = qdisc_pkt_len(skb);
int count = 1;
int rc = NET_XMIT_SUCCESS;
int rc_drop = NET_XMIT_DROP;
@@ -495,6 +494,7 @@ static int netem_enqueue(struct sk_buff
segs = netem_segment(skb, sch);
if (!segs)
return rc_drop;
+ qdisc_skb_cb(segs)->pkt_len = segs->len;
} else {
segs = skb;
}
@@ -575,6 +575,11 @@ static int netem_enqueue(struct sk_buff

finish_segs:
if (segs) {
+ unsigned int len, last_len;
+ int nb = 0;
+
+ len = skb->len;
+
while (segs) {
skb2 = segs->next;
segs->next = NULL;
@@ -590,9 +595,7 @@ finish_segs:
}
segs = skb2;
}
- sch->q.qlen += nb;
- if (nb > 1)
- qdisc_tree_reduce_backlog(sch, 1 - nb, prev_len - len);
+ qdisc_tree_reduce_backlog(sch, -nb, prev_len - len);
}
return NET_XMIT_SUCCESS;
}

2019-10-02 19:11:14

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 61/87] cfg80211: fix memory leak of wiphy device name

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Eric Biggers <[email protected]>

commit 4f488fbca2a86cc7714a128952eead92cac279ab upstream.

In wiphy_new_nm(), if an error occurs after dev_set_name() and
device_initialize() have already been called, it's necessary to call
put_device() (via wiphy_free()) to avoid a memory leak.

Reported-by: [email protected]
Fixes: 1f87f7d3a3b4 ("cfg80211: add rfkill support")
Signed-off-by: Eric Biggers <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/wireless/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -386,7 +386,7 @@ struct wiphy *wiphy_new(const struct cfg
&rdev->rfkill_ops, rdev);

if (!rdev->rfkill) {
- kfree(rdev);
+ wiphy_free(&rdev->wiphy);
return NULL;
}


2019-10-02 19:11:16

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 59/87] fs/ocfs2: fix race in ocfs2_dentry_attach_lock()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Wengang Wang <[email protected]>

commit be99ca2716972a712cde46092c54dee5e6192bf8 upstream.

ocfs2_dentry_attach_lock() can be executed in parallel threads against the
same dentry. Make that race safe. The race is like this:

thread A thread B

(A1) enter ocfs2_dentry_attach_lock,
seeing dentry->d_fsdata is NULL,
and no alias found by
ocfs2_find_local_alias, so kmalloc
a new ocfs2_dentry_lock structure
to local variable "dl", dl1

.....

(B1) enter ocfs2_dentry_attach_lock,
seeing dentry->d_fsdata is NULL,
and no alias found by
ocfs2_find_local_alias so kmalloc
a new ocfs2_dentry_lock structure
to local variable "dl", dl2.

......

(A2) set dentry->d_fsdata with dl1,
call ocfs2_dentry_lock() and increase
dl1->dl_lockres.l_ro_holders to 1 on
success.
......

(B2) set dentry->d_fsdata with dl2
call ocfs2_dentry_lock() and increase
dl2->dl_lockres.l_ro_holders to 1 on
success.

......

(A3) call ocfs2_dentry_unlock()
and decrease
dl2->dl_lockres.l_ro_holders to 0
on success.
....

(B3) call ocfs2_dentry_unlock(),
decreasing
dl2->dl_lockres.l_ro_holders, but
see it's zero now, panic

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Wengang Wang <[email protected]>
Reported-by: Daniel Sobe <[email protected]>
Tested-by: Daniel Sobe <[email protected]>
Reviewed-by: Changwei Ge <[email protected]>
Reviewed-by: Joseph Qi <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: Junxiao Bi <[email protected]>
Cc: Gang He <[email protected]>
Cc: Jun Piao <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
fs/ocfs2/dcache.c | 12 ++++++++++++
1 file changed, 12 insertions(+)

--- a/fs/ocfs2/dcache.c
+++ b/fs/ocfs2/dcache.c
@@ -310,6 +310,18 @@ int ocfs2_dentry_attach_lock(struct dent

out_attach:
spin_lock(&dentry_attach_lock);
+ if (unlikely(dentry->d_fsdata && !alias)) {
+ /* d_fsdata is set by a racing thread which is doing
+ * the same thing as this thread is doing. Leave the racing
+ * thread going ahead and we return here.
+ */
+ spin_unlock(&dentry_attach_lock);
+ iput(dl->dl_inode);
+ ocfs2_lock_res_free(&dl->dl_lockres);
+ kfree(dl);
+ return 0;
+ }
+
dentry->d_fsdata = dl;
dl->dl_count++;
spin_unlock(&dentry_attach_lock);

2019-10-02 19:11:17

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 54/87] i2c: acorn: fix i2c warning

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Russell King <[email protected]>

commit ca21f851cc9643af049226d57fabc3c883ea648e upstream.

The Acorn i2c driver (for RiscPC) triggers the "i2c adapter has no name"
warning in the I2C core driver, resulting in the RTC being inaccessible.
Fix this.

Fixes: 2236baa75f70 ("i2c: Sanity checks on adapter registration")
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/i2c/busses/i2c-acorn.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/i2c/busses/i2c-acorn.c
+++ b/drivers/i2c/busses/i2c-acorn.c
@@ -83,6 +83,7 @@ static struct i2c_algo_bit_data ioc_data

static struct i2c_adapter ioc_ops = {
.nr = 0,
+ .name = "ioc",
.algo_data = &ioc_data,
};


2019-10-02 19:11:19

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 57/87] libata: Extend quirks for the ST1000LM024 drives with NOLPM quirk

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Hans de Goede <[email protected]>

commit 31f6264e225fb92cf6f4b63031424f20797c297d upstream.

We've received a bugreport that using LPM with ST1000LM024 drives leads
to system lockups. So it seems that these models are buggy in more then
1 way. Add NOLPM quirk to the existing quirks entry for BROKEN_FPDMA_AA.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1571330
Reviewed-by: Martin K. Petersen <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/ata/libata-core.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4176,9 +4176,12 @@ static const struct ata_blacklist_entry
{ "ST3320[68]13AS", "SD1[5-9]", ATA_HORKAGE_NONCQ |
ATA_HORKAGE_FIRMWARE_WARN },

- /* drives which fail FPDMA_AA activation (some may freeze afterwards) */
- { "ST1000LM024 HN-M101MBB", "2AR10001", ATA_HORKAGE_BROKEN_FPDMA_AA },
- { "ST1000LM024 HN-M101MBB", "2BA30001", ATA_HORKAGE_BROKEN_FPDMA_AA },
+ /* drives which fail FPDMA_AA activation (some may freeze afterwards)
+ the ST disks also have LPM issues */
+ { "ST1000LM024 HN-M101MBB", "2AR10001", ATA_HORKAGE_BROKEN_FPDMA_AA |
+ ATA_HORKAGE_NOLPM, },
+ { "ST1000LM024 HN-M101MBB", "2BA30001", ATA_HORKAGE_BROKEN_FPDMA_AA |
+ ATA_HORKAGE_NOLPM, },
{ "VB0250EAVER", "HPG7", ATA_HORKAGE_BROKEN_FPDMA_AA },

/* Blacklist entries taken from Silicon Image 3124/3132

2019-10-02 19:11:35

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 67/87] SMB3: retry on STATUS_INSUFFICIENT_RESOURCES instead of failing write

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Steve French <[email protected]>

commit 8d526d62db907e786fd88948c75d1833d82bd80e upstream.

Some servers such as Windows 10 will return STATUS_INSUFFICIENT_RESOURCES
as the number of simultaneous SMB3 requests grows (even though the client
has sufficient credits). Return EAGAIN on STATUS_INSUFFICIENT_RESOURCES
so that we can retry writes which fail with this status code.

This (for example) fixes large file copies to Windows 10 on fast networks.

Signed-off-by: Steve French <[email protected]>
Reviewed-by: Ronnie Sahlberg <[email protected]>
Reviewed-by: Pavel Shilovsky <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
fs/cifs/smb2maperror.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/cifs/smb2maperror.c
+++ b/fs/cifs/smb2maperror.c
@@ -455,7 +455,7 @@ static const struct status_to_posix_erro
{STATUS_FILE_INVALID, -EIO, "STATUS_FILE_INVALID"},
{STATUS_ALLOTTED_SPACE_EXCEEDED, -EIO,
"STATUS_ALLOTTED_SPACE_EXCEEDED"},
- {STATUS_INSUFFICIENT_RESOURCES, -EREMOTEIO,
+ {STATUS_INSUFFICIENT_RESOURCES, -EAGAIN,
"STATUS_INSUFFICIENT_RESOURCES"},
{STATUS_DFS_EXIT_PATH_FOUND, -EIO, "STATUS_DFS_EXIT_PATH_FOUND"},
{STATUS_DEVICE_DATA_ERROR, -EIO, "STATUS_DEVICE_DATA_ERROR"},

2019-10-02 19:11:44

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 71/87] net/af_iucv: remove GFP_DMA restriction for HiperTransport

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Julian Wiedmann <[email protected]>

commit fdbf6326912d578a31ac4ca0933c919eadf1d54c upstream.

af_iucv sockets over z/VM IUCV require that their skbs are allocated
in DMA memory. This restriction doesn't apply to connections over
HiperSockets. So only set this limit for z/VM IUCV sockets, thereby
increasing the likelihood that the large (and linear!) allocations for
HiperTransport messages succeed.

Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport")
Signed-off-by: Julian Wiedmann <[email protected]>
Reviewed-by: Ursula Braun <[email protected]>
Reviewed-by: Hendrik Brueckner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/iucv/af_iucv.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -568,7 +568,6 @@ static struct sock *iucv_sock_alloc(stru

sk->sk_destruct = iucv_sock_destruct;
sk->sk_sndtimeo = IUCV_CONN_TIMEOUT;
- sk->sk_allocation = GFP_DMA;

sock_reset_flag(sk, SOCK_ZAPPED);

@@ -762,6 +761,7 @@ vm_bind:
memcpy(iucv->src_user_id, iucv_userid, 8);
sk->sk_state = IUCV_BOUND;
iucv->transport = AF_IUCV_TRANS_IUCV;
+ sk->sk_allocation |= GFP_DMA;
if (!iucv->msglimit)
iucv->msglimit = IUCV_QUEUELEN_DEFAULT;
goto done_unlock;
@@ -786,6 +786,8 @@ static int iucv_sock_autobind(struct soc
return -EPROTO;

memcpy(iucv->src_user_id, iucv_userid, 8);
+ iucv->transport = AF_IUCV_TRANS_IUCV;
+ sk->sk_allocation |= GFP_DMA;

write_lock_bh(&iucv_sk_list.lock);
__iucv_auto_name(iucv);
@@ -1737,6 +1739,8 @@ static int iucv_callback_connreq(struct

niucv = iucv_sk(nsk);
iucv_sock_init(nsk, sk);
+ niucv->transport = AF_IUCV_TRANS_IUCV;
+ nsk->sk_allocation |= GFP_DMA;

/* Set the new iucv_sock */
memcpy(niucv->dst_name, ipuser + 8, 8);

2019-10-02 19:11:49

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 68/87] apparmor: enforce nullbyte at end of tag string

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Jann Horn <[email protected]>

commit 8404d7a674c49278607d19726e0acc0cae299357 upstream.

A packed AppArmor policy contains null-terminated tag strings that are read
by unpack_nameX(). However, unpack_nameX() uses string functions on them
without ensuring that they are actually null-terminated, potentially
leading to out-of-bounds accesses.

Make sure that the tag string is null-terminated before passing it to
strcmp().

Fixes: 736ec752d95e ("AppArmor: policy routines for loading and unpacking policy")
Signed-off-by: Jann Horn <[email protected]>
Signed-off-by: John Johansen <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
security/apparmor/policy_unpack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/security/apparmor/policy_unpack.c
+++ b/security/apparmor/policy_unpack.c
@@ -177,7 +177,7 @@ static bool unpack_nameX(struct aa_ext *
char *tag = NULL;
size_t size = unpack_u16_chunk(e, &tag);
/* if a name is specified it must match. otherwise skip tag */
- if (name && (!size || strcmp(name, tag)))
+ if (name && (!size || tag[size-1] != '\0' || strcmp(name, tag)))
goto fail;
} else if (name) {
/* if a name is specified and there is no name tag fail */

2019-10-02 19:11:53

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 22/87] sbitmap: fix improper use of smp_mb__before_atomic()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Andrea Parri <[email protected]>

commit a0934fd2b1208458e55fc4b48f55889809fce666 upstream.

This barrier only applies to the read-modify-write operations; in
particular, it does not apply to the atomic_set() primitive.

Replace the barrier with an smp_mb().

Fixes: 6c0ca7ae292ad ("sbitmap: fix wakeup hang after sbq resize")
Reported-by: "Paul E. McKenney" <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Signed-off-by: Andrea Parri <[email protected]>
Reviewed-by: Ming Lei <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Omar Sandoval <[email protected]>
Cc: Ming Lei <[email protected]>
Cc: [email protected]
Cc: "Paul E. McKenney" <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <[email protected]>
---
block/blk-mq-tag.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -499,7 +499,7 @@ static void bt_update_count(struct blk_m
* Pairs with the memory barrier in bt_clear_tag() to ensure
* that the batch size is updated before the wait counts.
*/
- smp_mb__before_atomic();
+ smp_mb();
for (i = 0; i < BT_WAIT_QUEUES; i++)
atomic_set(&bt->bs[i].wait_cnt, 1);
}

2019-10-02 19:11:56

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 76/87] perf/ioctl: Add check for the sample_period value

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Ravi Bangoria <[email protected]>

commit 913a90bc5a3a06b1f04c337320e9aeee2328dd77 upstream.

perf_event_open() limits the sample_period to 63 bits. See:

0819b2e30ccb ("perf: Limit perf_event_attr::sample_period to 63 bits")

Make ioctl() consistent with it.

Also on PowerPC, negative sample_period could cause a recursive
PMIs leading to a hang (reported when running perf-fuzzer).

Signed-off-by: Ravi Bangoria <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Fixes: 0819b2e30ccb ("perf: Limit perf_event_attr::sample_period to 63 bits")
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
kernel/events/core.c | 3 +++
1 file changed, 3 insertions(+)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3823,6 +3823,9 @@ static int perf_event_period(struct perf
if (perf_event_check_period(event, value))
return -EINVAL;

+ if (!event->attr.freq && (value & (1ULL << 63)))
+ return -EINVAL;
+
task = ctx->task;
pe.value = value;


2019-10-02 19:11:57

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 62/87] Btrfs: fix race between readahead and device replace/removal

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Filipe Manana <[email protected]>

commit ce7791ffee1e1ee9f97193b817c7dd1fa6746aad upstream.

The list of devices is protected by the device_list_mutex and the device
replace code, in its finishing phase correctly takes that mutex before
removing the source device from that list. However the readahead code was
iterating that list without acquiring the respective mutex leading to
crashes later on due to invalid memory accesses:

[125671.831036] general protection fault: 0000 [#1] PREEMPT SMP
[125671.832129] Modules linked in: btrfs dm_flakey dm_mod crc32c_generic xor raid6_pq acpi_cpufreq tpm_tis tpm ppdev evdev parport_pc psmouse sg parport
processor ser
[125671.834973] CPU: 10 PID: 19603 Comm: kworker/u32:19 Tainted: G W 4.6.0-rc7-btrfs-next-29+ #1
[125671.834973] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
[125671.834973] Workqueue: btrfs-readahead btrfs_readahead_helper [btrfs]
[125671.834973] task: ffff8801ac520540 ti: ffff8801ac918000 task.ti: ffff8801ac918000
[125671.834973] RIP: 0010:[<ffffffff81270479>] [<ffffffff81270479>] __radix_tree_lookup+0x6a/0x105
[125671.834973] RSP: 0018:ffff8801ac91bc28 EFLAGS: 00010206
[125671.834973] RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b6a RCX: 0000000000000000
[125671.834973] RDX: 0000000000000000 RSI: 00000000000c1bff RDI: ffff88002ebd62a8
[125671.834973] RBP: ffff8801ac91bc70 R08: 0000000000000001 R09: 0000000000000000
[125671.834973] R10: ffff8801ac91bc70 R11: 0000000000000000 R12: ffff88002ebd62a8
[125671.834973] R13: 0000000000000000 R14: 0000000000000000 R15: 00000000000c1bff
[125671.834973] FS: 0000000000000000(0000) GS:ffff88023fd40000(0000) knlGS:0000000000000000
[125671.834973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[125671.834973] CR2: 000000000073cae4 CR3: 00000000b7723000 CR4: 00000000000006e0
[125671.834973] Stack:
[125671.834973] 0000000000000000 ffff8801422d5600 ffff8802286bbc00 0000000000000000
[125671.834973] 0000000000000001 ffff8802286bbc00 00000000000c1bff 0000000000000000
[125671.834973] ffff88002e639eb8 ffff8801ac91bc80 ffffffff81270541 ffff8801ac91bcb0
[125671.834973] Call Trace:
[125671.834973] [<ffffffff81270541>] radix_tree_lookup+0xd/0xf
[125671.834973] [<ffffffffa04ae6a6>] reada_peer_zones_set_lock+0x3e/0x60 [btrfs]
[125671.834973] [<ffffffffa04ae8b9>] reada_pick_zone+0x29/0x103 [btrfs]
[125671.834973] [<ffffffffa04af42f>] reada_start_machine_worker+0x129/0x2d3 [btrfs]
[125671.834973] [<ffffffffa04880be>] btrfs_scrubparity_helper+0x185/0x3aa [btrfs]
[125671.834973] [<ffffffffa0488341>] btrfs_readahead_helper+0xe/0x10 [btrfs]
[125671.834973] [<ffffffff81069691>] process_one_work+0x271/0x4e9
[125671.834973] [<ffffffff81069dda>] worker_thread+0x1eb/0x2c9
[125671.834973] [<ffffffff81069bef>] ? rescuer_thread+0x2b3/0x2b3
[125671.834973] [<ffffffff8106f403>] kthread+0xd4/0xdc
[125671.834973] [<ffffffff8149e242>] ret_from_fork+0x22/0x40
[125671.834973] [<ffffffff8106f32f>] ? kthread_stop+0x286/0x286

So fix this by taking the device_list_mutex in the readahead code. We
can't use here the lighter approach of using a rcu_read_lock() and
rcu_read_unlock() pair together with a list_for_each_entry_rcu() call
because we end up doing calls to sleeping functions (kzalloc()) in the
respective code path.

Signed-off-by: Filipe Manana <[email protected]>
Reviewed-by: Josef Bacik <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
fs/btrfs/reada.c | 2 ++
1 file changed, 2 insertions(+)

--- a/fs/btrfs/reada.c
+++ b/fs/btrfs/reada.c
@@ -766,12 +766,14 @@ static void __reada_start_machine(struct

do {
enqueued = 0;
+ mutex_lock(&fs_devices->device_list_mutex);
list_for_each_entry(device, &fs_devices->devices, dev_list) {
if (atomic_read(&device->reada_in_flight) <
MAX_IN_FLIGHT)
enqueued += reada_start_machine_dev(fs_info,
device);
}
+ mutex_unlock(&fs_devices->device_list_mutex);
total += enqueued;
} while (enqueued && total < 10000);


2019-10-02 19:12:04

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 74/87] x86/apic: Fix integer overflow on 10 bit left shift of cpu_khz

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Colin Ian King <[email protected]>

commit ea136a112d89bade596314a1ae49f748902f4727 upstream.

The left shift of unsigned int cpu_khz will overflow for large values of
cpu_khz, so cast it to a long long before shifting it to avoid overvlow.
For example, this can happen when cpu_khz is 4194305, i.e. ~4.2 GHz.

Addresses-Coverity: ("Unintentional integer overflow")
Fixes: 8c3ba8d04924 ("x86, apic: ack all pending irqs when crashed/on kexec")
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: "H . Peter Anvin" <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
arch/x86/kernel/apic/apic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1403,7 +1403,8 @@ void setup_local_APIC(void)
if (queued) {
if (cpu_has_tsc && cpu_khz) {
rdtscll(ntsc);
- max_loops = (cpu_khz << 10) - (ntsc - tsc);
+ max_loops = (long long)cpu_khz << 10;
+ max_loops -= ntsc - tsc;
} else
max_loops--;
}

2019-10-02 19:12:21

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 84/87] tracing/snapshot: Resize spare buffer if size changed

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Eiichi Tsukata <[email protected]>

commit 46cc0b44428d0f0e81f11ea98217fc0edfbeab07 upstream.

Current snapshot implementation swaps two ring_buffers even though their
sizes are different from each other, that can cause an inconsistency
between the contents of buffer_size_kb file and the current buffer size.

For example:

# cat buffer_size_kb
7 (expanded: 1408)
# echo 1 > events/enable
# grep bytes per_cpu/cpu0/stats
bytes: 1441020
# echo 1 > snapshot // current:1408, spare:1408
# echo 123 > buffer_size_kb // current:123, spare:1408
# echo 1 > snapshot // current:1408, spare:123
# grep bytes per_cpu/cpu0/stats
bytes: 1443700
# cat buffer_size_kb
123 // != current:1408

And also, a similar per-cpu case hits the following WARNING:

Reproducer:

# echo 1 > per_cpu/cpu0/snapshot
# echo 123 > buffer_size_kb
# echo 1 > per_cpu/cpu0/snapshot

WARNING:

WARNING: CPU: 0 PID: 1946 at kernel/trace/trace.c:1607 update_max_tr_single.part.0+0x2b8/0x380
Modules linked in:
CPU: 0 PID: 1946 Comm: bash Not tainted 5.2.0-rc6 #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014
RIP: 0010:update_max_tr_single.part.0+0x2b8/0x380
Code: ff e8 dc da f9 ff 0f 0b e9 88 fe ff ff e8 d0 da f9 ff 44 89 ee bf f5 ff ff ff e8 33 dc f9 ff 41 83 fd f5 74 96 e8 b8 da f9 ff <0f> 0b eb 8d e8 af da f9 ff 0f 0b e9 bf fd ff ff e8 a3 da f9 ff 48
RSP: 0018:ffff888063e4fca0 EFLAGS: 00010093
RAX: ffff888066214380 RBX: ffffffff99850fe0 RCX: ffffffff964298a8
RDX: 0000000000000000 RSI: 00000000fffffff5 RDI: 0000000000000005
RBP: 1ffff1100c7c9f96 R08: ffff888066214380 R09: ffffed100c7c9f9b
R10: ffffed100c7c9f9a R11: 0000000000000003 R12: 0000000000000000
R13: 00000000ffffffea R14: ffff888066214380 R15: ffffffff99851060
FS: 00007f9f8173c700(0000) GS:ffff88806d000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000714dc0 CR3: 0000000066fa6000 CR4: 00000000000006f0
Call Trace:
? trace_array_printk_buf+0x140/0x140
? __mutex_lock_slowpath+0x10/0x10
tracing_snapshot_write+0x4c8/0x7f0
? trace_printk_init_buffers+0x60/0x60
? selinux_file_permission+0x3b/0x540
? tracer_preempt_off+0x38/0x506
? trace_printk_init_buffers+0x60/0x60
__vfs_write+0x81/0x100
vfs_write+0x1e1/0x560
ksys_write+0x126/0x250
? __ia32_sys_read+0xb0/0xb0
? do_syscall_64+0x1f/0x390
do_syscall_64+0xc1/0x390
entry_SYSCALL_64_after_hwframe+0x49/0xbe

This patch adds resize_buffer_duplicate_size() to check if there is a
difference between current/spare buffer sizes and resize a spare buffer
if necessary.

Link: http://lkml.kernel.org/r/[email protected]

Fixes: ad909e21bbe69 ("tracing: Add internal tracing_snapshot() functions")
Signed-off-by: Eiichi Tsukata <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
kernel/trace/trace.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5102,11 +5102,13 @@ tracing_snapshot_write(struct file *filp
break;
}
#endif
- if (!tr->allocated_snapshot) {
+ if (tr->allocated_snapshot)
+ ret = resize_buffer_duplicate_size(&tr->max_buffer,
+ &tr->trace_buffer, iter->cpu_file);
+ else
ret = alloc_snapshot(tr);
- if (ret < 0)
- break;
- }
+ if (ret < 0)
+ break;
local_irq_disable();
/* Now, we're going to swap */
if (iter->cpu_file == RING_BUFFER_ALL_CPUS)

2019-10-02 19:12:30

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 80/87] bonding: Always enable vlan tx offload

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: YueHaibing <[email protected]>

commit 30d8177e8ac776d89d387fad547af6a0f599210e upstream.

We build vlan on top of bonding interface, which vlan offload
is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
BOND_XMIT_POLICY_ENCAP34.

Because vlan tx offload is off, vlan tci is cleared and skb push
the vlan header in validate_xmit_vlan() while sending from vlan
devices. Then in bond_xmit_hash, __skb_flow_dissect() fails to
get information from protocol headers encapsulated within vlan,
because 'nhoff' is points to IP header, so bond hashing is based
on layer 2 info, which fails to distribute packets across slaves.

This patch always enable bonding's vlan tx offload, pass the vlan
packets to the slave devices with vlan tci, let them to handle
vlan implementation.

Fixes: 278339a42a1b ("bonding: propogate vlan_features to bonding master")
Suggested-by: Jiri Pirko <[email protected]>
Signed-off-by: YueHaibing <[email protected]>
Acked-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/net/bonding/bond_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4038,13 +4038,13 @@ void bond_setup(struct net_device *bond_
bond_dev->features |= NETIF_F_NETNS_LOCAL;

bond_dev->hw_features = BOND_VLAN_FEATURES |
- NETIF_F_HW_VLAN_CTAG_TX |
NETIF_F_HW_VLAN_CTAG_RX |
NETIF_F_HW_VLAN_CTAG_FILTER;

bond_dev->hw_features &= ~(NETIF_F_ALL_CSUM & ~NETIF_F_HW_CSUM);
bond_dev->hw_features |= NETIF_F_GSO_UDP_TUNNEL;
bond_dev->features |= bond_dev->hw_features;
+ bond_dev->features |= NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_STAG_TX;
}

/*

2019-10-02 19:12:39

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 81/87] bonding: Add vlan tx offload to hw_enc_features

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: YueHaibing <[email protected]>

commit d595b03de2cb0bdf9bcdf35ff27840cc3a37158f upstream.

As commit 30d8177e8ac7 ("bonding: Always enable vlan tx offload")
said, we should always enable bonding's vlan tx offload, pass the
vlan packets to the slave devices with vlan tci, let them to handle
vlan implementation.

Now if encapsulation protocols like VXLAN is used, skb->encapsulation
may be set, then the packet is passed to vlan device which based on
bonding device. However in netif_skb_features(), the check of
hw_enc_features:

if (skb->encapsulation)
features &= dev->hw_enc_features;

clears NETIF_F_HW_VLAN_CTAG_TX/NETIF_F_HW_VLAN_STAG_TX. This results
in same issue in commit 30d8177e8ac7 like this:

vlan_dev_hard_start_xmit
-->dev_queue_xmit
-->validate_xmit_skb
-->netif_skb_features //NETIF_F_HW_VLAN_CTAG_TX is cleared
-->validate_xmit_vlan
-->__vlan_hwaccel_push_inside //skb->tci is cleared
...
--> bond_start_xmit
--> bond_xmit_hash //BOND_XMIT_POLICY_ENCAP34
--> __skb_flow_dissect // nhoff point to IP header
--> case htons(ETH_P_8021Q)
// skb_vlan_tag_present is false, so
vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
//vlan point to ip header wrongly

Fixes: b2a103e6d0af ("bonding: convert to ndo_fix_features")
Signed-off-by: YueHaibing <[email protected]>
Acked-by: Jay Vosburgh <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1083,7 +1083,9 @@ static void bond_compute_features(struct

done:
bond_dev->vlan_features = vlan_features;
- bond_dev->hw_enc_features = enc_features;
+ bond_dev->hw_enc_features = enc_features |
+ NETIF_F_HW_VLAN_CTAG_TX |
+ NETIF_F_HW_VLAN_STAG_TX;
bond_dev->hard_header_len = max_hard_header_len;
bond_dev->gso_max_segs = gso_max_segs;
netif_set_gso_max_size(bond_dev, gso_max_size);

2019-10-02 19:12:45

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 83/87] ALSA: seq: fix incorrect order of dest_client/dest_ports arguments

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Colin Ian King <[email protected]>

commit c3ea60c231446663afd6ea1054da6b7f830855ca upstream.

There are two occurrances of a call to snd_seq_oss_fill_addr where
the dest_client and dest_port arguments are in the wrong order. Fix
this by swapping them around.

Addresses-Coverity: ("Arguments in wrong order")
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
sound/core/seq/oss/seq_oss_ioctl.c | 2 +-
sound/core/seq/oss/seq_oss_rw.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

--- a/sound/core/seq/oss/seq_oss_ioctl.c
+++ b/sound/core/seq/oss/seq_oss_ioctl.c
@@ -62,7 +62,7 @@ static int snd_seq_oss_oob_user(struct s
if (copy_from_user(ev, arg, 8))
return -EFAULT;
memset(&tmpev, 0, sizeof(tmpev));
- snd_seq_oss_fill_addr(dp, &tmpev, dp->addr.port, dp->addr.client);
+ snd_seq_oss_fill_addr(dp, &tmpev, dp->addr.client, dp->addr.port);
tmpev.time.tick = 0;
if (! snd_seq_oss_process_event(dp, (union evrec *)ev, &tmpev)) {
snd_seq_oss_dispatch(dp, &tmpev, 0, 0);
--- a/sound/core/seq/oss/seq_oss_rw.c
+++ b/sound/core/seq/oss/seq_oss_rw.c
@@ -174,7 +174,7 @@ insert_queue(struct seq_oss_devinfo *dp,
memset(&event, 0, sizeof(event));
/* set dummy -- to be sure */
event.type = SNDRV_SEQ_EVENT_NOTEOFF;
- snd_seq_oss_fill_addr(dp, &event, dp->addr.port, dp->addr.client);
+ snd_seq_oss_fill_addr(dp, &event, dp->addr.client, dp->addr.port);

if (snd_seq_oss_process_event(dp, rec, &event))
return 0; /* invalid event - no need to insert queue */

2019-10-02 19:12:46

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 56/87] bcache: fix stack corruption by PRECEDING_KEY()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Coly Li <[email protected]>

commit 31b90956b124240aa8c63250243ae1a53585c5e2 upstream.

Recently people report bcache code compiled with gcc9 is broken, one of
the buggy behavior I observe is that two adjacent 4KB I/Os should merge
into one but they don't. Finally it turns out to be a stack corruption
caused by macro PRECEDING_KEY().

See how PRECEDING_KEY() is defined in bset.h,
437 #define PRECEDING_KEY(_k) \
438 ({ \
439 struct bkey *_ret = NULL; \
440 \
441 if (KEY_INODE(_k) || KEY_OFFSET(_k)) { \
442 _ret = &KEY(KEY_INODE(_k), KEY_OFFSET(_k), 0); \
443 \
444 if (!_ret->low) \
445 _ret->high--; \
446 _ret->low--; \
447 } \
448 \
449 _ret; \
450 })

At line 442, _ret points to address of a on-stack variable combined by
KEY(), the life range of this on-stack variable is in line 442-446,
once _ret is returned to bch_btree_insert_key(), the returned address
points to an invalid stack address and this address is overwritten in
the following called bch_btree_iter_init(). Then argument 'search' of
bch_btree_iter_init() points to some address inside stackframe of
bch_btree_iter_init(), exact address depends on how the compiler
allocates stack space. Now the stack is corrupted.

Fixes: 0eacac22034c ("bcache: PRECEDING_KEY()")
Signed-off-by: Coly Li <[email protected]>
Reviewed-by: Rolf Fokkens <[email protected]>
Reviewed-by: Pierre JUHEN <[email protected]>
Tested-by: Shenghui Wang <[email protected]>
Tested-by: Pierre JUHEN <[email protected]>
Cc: Kent Overstreet <[email protected]>
Cc: Nix <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/md/bcache/bset.c | 16 +++++++++++++---
drivers/md/bcache/bset.h | 34 ++++++++++++++++++++--------------
2 files changed, 33 insertions(+), 17 deletions(-)

--- a/drivers/md/bcache/bset.c
+++ b/drivers/md/bcache/bset.c
@@ -823,12 +823,22 @@ unsigned bch_btree_insert_key(struct btr
struct bset *i = bset_tree_last(b)->data;
struct bkey *m, *prev = NULL;
struct btree_iter iter;
+ struct bkey preceding_key_on_stack = ZERO_KEY;
+ struct bkey *preceding_key_p = &preceding_key_on_stack;

BUG_ON(b->ops->is_extents && !KEY_SIZE(k));

- m = bch_btree_iter_init(b, &iter, b->ops->is_extents
- ? PRECEDING_KEY(&START_KEY(k))
- : PRECEDING_KEY(k));
+ /*
+ * If k has preceding key, preceding_key_p will be set to address
+ * of k's preceding key; otherwise preceding_key_p will be set
+ * to NULL inside preceding_key().
+ */
+ if (b->ops->is_extents)
+ preceding_key(&START_KEY(k), &preceding_key_p);
+ else
+ preceding_key(k, &preceding_key_p);
+
+ m = bch_btree_iter_init(b, &iter, preceding_key_p);

if (b->ops->insert_fixup(b, k, &iter, replace_key))
return status;
--- a/drivers/md/bcache/bset.h
+++ b/drivers/md/bcache/bset.h
@@ -417,20 +417,26 @@ static inline bool bch_cut_back(const st
return __bch_cut_back(where, k);
}

-#define PRECEDING_KEY(_k) \
-({ \
- struct bkey *_ret = NULL; \
- \
- if (KEY_INODE(_k) || KEY_OFFSET(_k)) { \
- _ret = &KEY(KEY_INODE(_k), KEY_OFFSET(_k), 0); \
- \
- if (!_ret->low) \
- _ret->high--; \
- _ret->low--; \
- } \
- \
- _ret; \
-})
+/*
+ * Pointer '*preceding_key_p' points to a memory object to store preceding
+ * key of k. If the preceding key does not exist, set '*preceding_key_p' to
+ * NULL. So the caller of preceding_key() needs to take care of memory
+ * which '*preceding_key_p' pointed to before calling preceding_key().
+ * Currently the only caller of preceding_key() is bch_btree_insert_key(),
+ * and it points to an on-stack variable, so the memory release is handled
+ * by stackframe itself.
+ */
+static inline void preceding_key(struct bkey *k, struct bkey **preceding_key_p)
+{
+ if (KEY_INODE(k) || KEY_OFFSET(k)) {
+ (**preceding_key_p) = KEY(KEY_INODE(k), KEY_OFFSET(k), 0);
+ if (!(*preceding_key_p)->low)
+ (*preceding_key_p)->high--;
+ (*preceding_key_p)->low--;
+ } else {
+ (*preceding_key_p) = NULL;
+ }
+}

static inline bool bch_ptr_invalid(struct btree_keys *b, const struct bkey *k)
{

2019-10-02 19:12:57

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 09/87] USB: rio500: fix memory leak in close after disconnect

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Oliver Neukum <[email protected]>

commit e0feb73428b69322dd5caae90b0207de369b5575 upstream.

If a disconnected device is closed, rio_close() must free
the buffers.

Signed-off-by: Oliver Neukum <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/usb/misc/rio500.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)

--- a/drivers/usb/misc/rio500.c
+++ b/drivers/usb/misc/rio500.c
@@ -103,9 +103,22 @@ static int close_rio(struct inode *inode
{
struct rio_usb_data *rio = &rio_instance;

- rio->isopen = 0;
+ /* against disconnect() */
+ mutex_lock(&rio500_mutex);
+ mutex_lock(&(rio->lock));

- dev_info(&rio->rio_dev->dev, "Rio closed.\n");
+ rio->isopen = 0;
+ if (!rio->present) {
+ /* cleanup has been delayed */
+ kfree(rio->ibuf);
+ kfree(rio->obuf);
+ rio->ibuf = NULL;
+ rio->obuf = NULL;
+ } else {
+ dev_info(&rio->rio_dev->dev, "Rio closed.\n");
+ }
+ mutex_unlock(&(rio->lock));
+ mutex_unlock(&rio500_mutex);
return 0;
}


2019-10-02 19:13:03

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 08/87] usbip: usbip_host: fix BUG: sleeping function called from invalid context

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Shuah Khan <[email protected]>

commit 0c9e8b3cad654bfc499c10b652fbf8f0b890af8f upstream.

stub_probe() and stub_disconnect() call functions which could call
sleeping function in invalid context whil holding busid_lock.

Fix the problem by refining the lock holds to short critical sections
to change the busid_priv fields. This fix restructures the code to
limit the lock holds in stub_probe() and stub_disconnect().

stub_probe():

[15217.927028] BUG: sleeping function called from invalid context at mm/slab.h:418
[15217.927038] in_atomic(): 1, irqs_disabled(): 0, pid: 29087, name: usbip
[15217.927044] 5 locks held by usbip/29087:
[15217.927047] #0: 0000000091647f28 (sb_writers#6){....}, at: vfs_write+0x191/0x1c0
[15217.927062] #1: 000000008f9ba75b (&of->mutex){....}, at: kernfs_fop_write+0xf7/0x1b0
[15217.927072] #2: 00000000872e5b4b (&dev->mutex){....}, at: __device_driver_lock+0x3b/0x50
[15217.927082] #3: 00000000e74ececc (&dev->mutex){....}, at: __device_driver_lock+0x46/0x50
[15217.927090] #4: 00000000b20abbe0 (&(&busid_table[i].busid_lock)->rlock){....}, at: get_busid_priv+0x48/0x60 [usbip_host]
[15217.927103] CPU: 3 PID: 29087 Comm: usbip Tainted: G W 5.1.0-rc6+ #40
[15217.927106] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18 09/24/2013
[15217.927109] Call Trace:
[15217.927118] dump_stack+0x63/0x85
[15217.927127] ___might_sleep+0xff/0x120
[15217.927133] __might_sleep+0x4a/0x80
[15217.927143] kmem_cache_alloc_trace+0x1aa/0x210
[15217.927156] stub_probe+0xe8/0x440 [usbip_host]
[15217.927171] usb_probe_device+0x34/0x70

stub_disconnect():

[15279.182478] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
[15279.182487] in_atomic(): 1, irqs_disabled(): 0, pid: 29114, name: usbip
[15279.182492] 5 locks held by usbip/29114:
[15279.182494] #0: 0000000091647f28 (sb_writers#6){....}, at: vfs_write+0x191/0x1c0
[15279.182506] #1: 00000000702cf0f3 (&of->mutex){....}, at: kernfs_fop_write+0xf7/0x1b0
[15279.182514] #2: 00000000872e5b4b (&dev->mutex){....}, at: __device_driver_lock+0x3b/0x50
[15279.182522] #3: 00000000e74ececc (&dev->mutex){....}, at: __device_driver_lock+0x46/0x50
[15279.182529] #4: 00000000b20abbe0 (&(&busid_table[i].busid_lock)->rlock){....}, at: get_busid_priv+0x48/0x60 [usbip_host]
[15279.182541] CPU: 0 PID: 29114 Comm: usbip Tainted: G W 5.1.0-rc6+ #40
[15279.182543] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18 09/24/2013
[15279.182546] Call Trace:
[15279.182554] dump_stack+0x63/0x85
[15279.182561] ___might_sleep+0xff/0x120
[15279.182566] __might_sleep+0x4a/0x80
[15279.182574] __mutex_lock+0x55/0x950
[15279.182582] ? get_busid_priv+0x48/0x60 [usbip_host]
[15279.182587] ? reacquire_held_locks+0xec/0x1a0
[15279.182591] ? get_busid_priv+0x48/0x60 [usbip_host]
[15279.182597] ? find_held_lock+0x94/0xa0
[15279.182609] mutex_lock_nested+0x1b/0x20
[15279.182614] ? mutex_lock_nested+0x1b/0x20
[15279.182618] kernfs_remove_by_name_ns+0x2a/0x90
[15279.182625] sysfs_remove_file_ns+0x15/0x20
[15279.182629] device_remove_file+0x19/0x20
[15279.182634] stub_disconnect+0x6d/0x180 [usbip_host]
[15279.182643] usb_unbind_device+0x27/0x60

Signed-off-by: Shuah Khan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/staging/usbip/stub_dev.c | 65 ++++++++++++++++++++++++------------
1 file changed, 43 insertions(+), 22 deletions(-)

--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -342,9 +342,17 @@ static int stub_probe(struct usb_device
const char *udev_busid = dev_name(&udev->dev);
struct bus_id_priv *busid_priv;
int rc = 0;
+ char save_status;

dev_dbg(&udev->dev, "Enter probe\n");

+ /* Not sure if this is our device. Allocate here to avoid
+ * calling alloc while holding busid_table lock.
+ */
+ sdev = stub_device_alloc(udev);
+ if (!sdev)
+ return -ENOMEM;
+
/* check we should claim or not by busid_table */
busid_priv = get_busid_priv(udev_busid);
if (!busid_priv || (busid_priv->status == STUB_BUSID_REMOV) ||
@@ -359,14 +367,14 @@ static int stub_probe(struct usb_device
* See driver_probe_device() in driver/base/dd.c
*/
rc = -ENODEV;
- goto call_put_busid_priv;
+ goto sdev_free;
}

if (udev->descriptor.bDeviceClass == USB_CLASS_HUB) {
dev_dbg(&udev->dev, "%s is a usb hub device... skip!\n",
udev_busid);
rc = -ENODEV;
- goto call_put_busid_priv;
+ goto sdev_free;
}

if (!strcmp(udev->bus->bus_name, "vhci_hcd")) {
@@ -375,15 +383,9 @@ static int stub_probe(struct usb_device
udev_busid);

rc = -ENODEV;
- goto call_put_busid_priv;
+ goto sdev_free;
}

- /* ok, this is my device */
- sdev = stub_device_alloc(udev);
- if (!sdev) {
- rc = -ENOMEM;
- goto call_put_busid_priv;
- }

dev_info(&udev->dev,
"usbip-host: register new device (bus %u dev %u)\n",
@@ -393,9 +395,13 @@ static int stub_probe(struct usb_device

/* set private data to usb_device */
dev_set_drvdata(&udev->dev, sdev);
+
busid_priv->sdev = sdev;
busid_priv->udev = udev;

+ save_status = busid_priv->status;
+ busid_priv->status = STUB_BUSID_ALLOC;
+
/*
* Claim this hub port.
* It doesn't matter what value we pass as owner
@@ -408,15 +414,16 @@ static int stub_probe(struct usb_device
goto err_port;
}

+ /* release the busid_lock */
+ put_busid_priv(busid_priv);
+
rc = stub_add_files(&udev->dev);
if (rc) {
dev_err(&udev->dev, "stub_add_files for %s\n", udev_busid);
goto err_files;
}
- busid_priv->status = STUB_BUSID_ALLOC;

- rc = 0;
- goto call_put_busid_priv;
+ return 0;

err_files:
usb_hub_release_port(udev->parent, udev->portnum,
@@ -426,23 +433,24 @@ err_port:
usb_put_dev(udev);
kthread_stop_put(sdev->ud.eh);

+ /* we already have busid_priv, just lock busid_lock */
+ spin_lock(&busid_priv->busid_lock);
busid_priv->sdev = NULL;
+ busid_priv->status = save_status;
+sdev_free:
stub_device_free(sdev);
-
-call_put_busid_priv:
+ /* release the busid_lock */
put_busid_priv(busid_priv);
+
return rc;
}

static void shutdown_busid(struct bus_id_priv *busid_priv)
{
- if (busid_priv->sdev && !busid_priv->shutdown_busid) {
- busid_priv->shutdown_busid = 1;
- usbip_event_add(&busid_priv->sdev->ud, SDEV_EVENT_REMOVED);
+ usbip_event_add(&busid_priv->sdev->ud, SDEV_EVENT_REMOVED);

- /* wait for the stop of the event handler */
- usbip_stop_eh(&busid_priv->sdev->ud);
- }
+ /* wait for the stop of the event handler */
+ usbip_stop_eh(&busid_priv->sdev->ud);
}

/*
@@ -474,6 +482,9 @@ static void stub_disconnect(struct usb_d

dev_set_drvdata(&udev->dev, NULL);

+ /* release busid_lock before call to remove device files */
+ put_busid_priv(busid_priv);
+
/*
* NOTE: rx/tx threads are invoked for each usb_device.
*/
@@ -484,18 +495,27 @@ static void stub_disconnect(struct usb_d
(struct usb_dev_state *) udev);
if (rc) {
dev_dbg(&udev->dev, "unable to release port\n");
- goto call_put_busid_priv;
+ return;
}

/* If usb reset is called from event handler */
if (busid_priv->sdev->ud.eh == current)
- goto call_put_busid_priv;
+ return;
+
+ /* we already have busid_priv, just lock busid_lock */
+ spin_lock(&busid_priv->busid_lock);
+ if (!busid_priv->shutdown_busid)
+ busid_priv->shutdown_busid = 1;
+ /* release busid_lock */
+ put_busid_priv(busid_priv);

/* shutdown the current connection */
shutdown_busid(busid_priv);

usb_put_dev(sdev->udev);

+ /* we already have busid_priv, just lock busid_lock */
+ spin_lock(&busid_priv->busid_lock);
/* free sdev */
busid_priv->sdev = NULL;
stub_device_free(sdev);
@@ -504,6 +524,7 @@ static void stub_disconnect(struct usb_d
busid_priv->status = STUB_BUSID_ADDED;

call_put_busid_priv:
+ /* release busid_lock */
put_busid_priv(busid_priv);
}


2019-10-02 19:13:05

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 60/87] coredump: fix race condition between collapse_huge_page() and core dumping

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Andrea Arcangeli <[email protected]>

commit 59ea6d06cfa9247b586a695c21f94afa7183af74 upstream.

When fixing the race conditions between the coredump and the mmap_sem
holders outside the context of the process, we focused on
mmget_not_zero()/get_task_mm() callers in 04f5866e41fb70 ("coredump: fix
race condition between mmget_not_zero()/get_task_mm() and core
dumping"), but those aren't the only cases where the mmap_sem can be
taken outside of the context of the process as Michal Hocko noticed
while backporting that commit to older -stable kernels.

If mmgrab() is called in the context of the process, but then the
mm_count reference is transferred outside the context of the process,
that can also be a problem if the mmap_sem has to be taken for writing
through that mm_count reference.

khugepaged registration calls mmgrab() in the context of the process,
but the mmap_sem for writing is taken later in the context of the
khugepaged kernel thread.

collapse_huge_page() after taking the mmap_sem for writing doesn't
modify any vma, so it's not obvious that it could cause a problem to the
coredump, but it happens to modify the pmd in a way that breaks an
invariant that pmd_trans_huge_lock() relies upon. collapse_huge_page()
needs the mmap_sem for writing just to block concurrent page faults that
call pmd_trans_huge_lock().

Specifically the invariant that "!pmd_trans_huge()" cannot become a
"pmd_trans_huge()" doesn't hold while collapse_huge_page() runs.

The coredump will call __get_user_pages() without mmap_sem for reading,
which eventually can invoke a lockless page fault which will need a
functional pmd_trans_huge_lock().

So collapse_huge_page() needs to use mmget_still_valid() to check it's
not running concurrently with the coredump... as long as the coredump
can invoke page faults without holding the mmap_sem for reading.

This has "Fixes: khugepaged" to facilitate backporting, but in my view
it's more a bug in the coredump code that will eventually have to be
rewritten to stop invoking page faults without the mmap_sem for reading.
So the long term plan is still to drop all mmget_still_valid().

Link: http://lkml.kernel.org/r/[email protected]
Fixes: ba76149f47d8 ("thp: khugepaged")
Signed-off-by: Andrea Arcangeli <[email protected]>
Reported-by: Michal Hocko <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Jann Horn <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Mike Rapoport <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Peter Xu <[email protected]>
Cc: Jason Gunthorpe <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
[bwh: Backported to 3.16:
- Don't set result variable; collapse_huge_range() returns void
- Adjust filenames]
Signed-off-by: Ben Hutchings <[email protected]>
---
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2439,6 +2439,10 @@ static inline void mmdrop(struct mm_stru
* followed by taking the mmap_sem for writing before modifying the
* vmas or anything the coredump pretends not to change from under it.
*
+ * It also has to be called when mmgrab() is used in the context of
+ * the process, but then the mm_count refcount is transferred outside
+ * the context of the process to run down_write() on that pinned mm.
+ *
* NOTE: find_extend_vma() called from GUP context is the only place
* that can modify the "mm" (notably the vm_start/end) under mmap_sem
* for reading and outside the context of the process, so it is also
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2428,6 +2428,8 @@ static void collapse_huge_page(struct mm
* handled by the anon_vma lock + PG_lock.
*/
down_write(&mm->mmap_sem);
+ if (!mmget_still_valid(mm))
+ goto out;
if (unlikely(khugepaged_test_exit(mm)))
goto out;


2019-10-02 19:13:10

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 43/87] USB: Fix chipmunk-like voice when using Logitech C270 for recording audio.

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Marco Zatta <[email protected]>

commit bd21f0222adab64974b7d1b4b8c7ce6b23e9ea4d upstream.

This patch fixes the chipmunk-like voice that manifets randomly when
using the integrated mic of the Logitech Webcam HD C270.

The issue was solved initially for this device by commit 2394d67e446b
("USB: add RESET_RESUME for webcams shown to be quirky") but it was then
reintroduced by e387ef5c47dd ("usb: Add USB_QUIRK_RESET_RESUME for all
Logitech UVC webcams"). This patch is to have the fix back.

Signed-off-by: Marco Zatta <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -70,6 +70,9 @@ static const struct usb_device_id usb_qu
/* Cherry Stream G230 2.0 (G85-231) and 3.0 (G85-232) */
{ USB_DEVICE(0x046a, 0x0023), .driver_info = USB_QUIRK_RESET_RESUME },

+ /* Logitech HD Webcam C270 */
+ { USB_DEVICE(0x046d, 0x0825), .driver_info = USB_QUIRK_RESET_RESUME },
+
/* Logitech HD Pro Webcams C920, C920-C, C925e and C930e */
{ USB_DEVICE(0x046d, 0x082d), .driver_info = USB_QUIRK_DELAY_INIT },
{ USB_DEVICE(0x046d, 0x0841), .driver_info = USB_QUIRK_DELAY_INIT },

2019-10-02 19:13:14

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 64/87] be2net: Fix number of Rx queues used for flow hashing

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Ivan Vecera <[email protected]>

commit 718f4a2537089ea41903bf357071306163bc7c04 upstream.

Number of Rx queues used for flow hashing returned by the driver is
incorrect and this bug prevents user to use the last Rx queue in
indirection table.

Let's say we have a NIC with 6 combined queues:

[root@sm-03 ~]# ethtool -l enp4s0f0
Channel parameters for enp4s0f0:
Pre-set maximums:
RX: 5
TX: 5
Other: 0
Combined: 6
Current hardware settings:
RX: 0
TX: 0
Other: 0
Combined: 6

Default indirection table maps all (6) queues equally but the driver
reports only 5 rings available.

[root@sm-03 ~]# ethtool -x enp4s0f0
RX flow hash indirection table for enp4s0f0 with 5 RX ring(s):
0: 0 1 2 3 4 5 0 1
8: 2 3 4 5 0 1 2 3
16: 4 5 0 1 2 3 4 5
24: 0 1 2 3 4 5 0 1
...

Now change indirection table somehow:

[root@sm-03 ~]# ethtool -X enp4s0f0 weight 1 1
[root@sm-03 ~]# ethtool -x enp4s0f0
RX flow hash indirection table for enp4s0f0 with 6 RX ring(s):
0: 0 0 0 0 0 0 0 0
...
64: 1 1 1 1 1 1 1 1
...

Now it is not possible to change mapping back to equal (default) state:

[root@sm-03 ~]# ethtool -X enp4s0f0 equal 6
Cannot set RX flow hash configuration: Invalid argument

Fixes: 594ad54a2c3b ("be2net: Add support for setting and getting rx flow hash options")
Reported-by: Tianhao <[email protected]>
Signed-off-by: Ivan Vecera <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/net/ethernet/emulex/benet/be_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -962,7 +962,7 @@ static int be_get_rxnfc(struct net_devic
cmd->data = be_get_rss_hash_opts(adapter, cmd->flow_type);
break;
case ETHTOOL_GRXRINGS:
- cmd->data = adapter->num_rx_qs - 1;
+ cmd->data = adapter->num_rx_qs;
break;
default:
return -EINVAL;

2019-10-02 19:13:15

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 45/87] hwmon: (pmbus/core) Treat parameters as paged if on multiple pages

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Robert Hancock <[email protected]>

commit 4a60570dce658e3f8885bbcf852430b99f65aca5 upstream.

Some chips have attributes which exist on more than one page but the
attribute is not presently marked as paged. This causes the attributes
to be generated with the same label, which makes it impossible for
userspace to tell them apart.

Marking all such attributes as paged would result in the page suffix
being added regardless of whether they were present on more than one
page or not, which might break existing setups. Therefore, we add a
second check which treats the attribute as paged, even if not marked as
such, if it is present on multiple pages.

Fixes: b4ce237b7f7d ("hwmon: (pmbus) Introduce infrastructure to detect sensors and limit registers")
Signed-off-by: Robert Hancock <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/hwmon/pmbus/pmbus_core.c | 34 ++++++++++++++++++++++++++++----
1 file changed, 30 insertions(+), 4 deletions(-)

--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -987,14 +987,15 @@ static int pmbus_add_sensor_attrs_one(st
const struct pmbus_driver_info *info,
const char *name,
int index, int page,
- const struct pmbus_sensor_attr *attr)
+ const struct pmbus_sensor_attr *attr,
+ bool paged)
{
struct pmbus_sensor *base;
int ret;

if (attr->label) {
ret = pmbus_add_label(data, name, index, attr->label,
- attr->paged ? page + 1 : 0);
+ paged ? page + 1 : 0);
if (ret)
return ret;
}
@@ -1026,6 +1027,30 @@ static int pmbus_add_sensor_attrs_one(st
return 0;
}

+static bool pmbus_sensor_is_paged(const struct pmbus_driver_info *info,
+ const struct pmbus_sensor_attr *attr)
+{
+ int p;
+
+ if (attr->paged)
+ return true;
+
+ /*
+ * Some attributes may be present on more than one page despite
+ * not being marked with the paged attribute. If that is the case,
+ * then treat the sensor as being paged and add the page suffix to the
+ * attribute name.
+ * We don't just add the paged attribute to all such attributes, in
+ * order to maintain the un-suffixed labels in the case where the
+ * attribute is only on page 0.
+ */
+ for (p = 1; p < info->pages; p++) {
+ if (info->func[p] & attr->func)
+ return true;
+ }
+ return false;
+}
+
static int pmbus_add_sensor_attrs(struct i2c_client *client,
struct pmbus_data *data,
const char *name,
@@ -1039,14 +1064,15 @@ static int pmbus_add_sensor_attrs(struct
index = 1;
for (i = 0; i < nattrs; i++) {
int page, pages;
+ bool paged = pmbus_sensor_is_paged(info, attrs);

- pages = attrs->paged ? info->pages : 1;
+ pages = paged ? info->pages : 1;
for (page = 0; page < pages; page++) {
if (!(info->func[page] & attrs->func))
continue;
ret = pmbus_add_sensor_attrs_one(client, data, info,
name, index, page,
- attrs);
+ attrs, paged);
if (ret)
return ret;
index++;

2019-10-02 19:13:22

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 51/87] can: purge socket error queue on sock destruct

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Willem de Bruijn <[email protected]>

commit fd704bd5ee749d560e86c4f1fd2ef486d8abf7cf upstream.

CAN supports software tx timestamps as of the below commit. Purge
any queued timestamp packets on socket destroy.

Fixes: 51f31cabe3ce ("ip: support for TX timestamps on UDP and RAW sockets")
Reported-by: [email protected]
Signed-off-by: Willem de Bruijn <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/can/af_can.c | 1 +
1 file changed, 1 insertion(+)

--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -114,6 +114,7 @@ EXPORT_SYMBOL(can_ioctl);
static void can_sock_destruct(struct sock *sk)
{
skb_queue_purge(&sk->sk_receive_queue);
+ skb_queue_purge(&sk->sk_error_queue);
}

static const struct can_proto *can_get_proto(int protocol)

2019-10-02 19:13:27

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 47/87] net: rds: fix memory leak in rds_ib_flush_mr_pool

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Zhu Yanjun <[email protected]>

commit 85cb928787eab6a2f4ca9d2a798b6f3bed53ced1 upstream.

When the following tests last for several hours, the problem will occur.

Server:
rds-stress -r 1.1.1.16 -D 1M
Client:
rds-stress -r 1.1.1.14 -s 1.1.1.16 -D 1M -T 30

The following will occur.

"
Starting up....
tsks tx/s rx/s tx+rx K/s mbi K/s mbo K/s tx us/c rtt us cpu
%
1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
"
>From vmcore, we can find that clean_list is NULL.

>From the source code, rds_mr_flushd calls rds_ib_mr_pool_flush_worker.
Then rds_ib_mr_pool_flush_worker calls
"
rds_ib_flush_mr_pool(pool, 0, NULL);
"
Then in function
"
int rds_ib_flush_mr_pool(struct rds_ib_mr_pool *pool,
int free_all, struct rds_ib_mr **ibmr_ret)
"
ibmr_ret is NULL.

In the source code,
"
...
list_to_llist_nodes(pool, &unmap_list, &clean_nodes, &clean_tail);
if (ibmr_ret)
*ibmr_ret = llist_entry(clean_nodes, struct rds_ib_mr, llnode);

/* more than one entry in llist nodes */
if (clean_nodes->next)
llist_add_batch(clean_nodes->next, clean_tail, &pool->clean_list);
...
"
When ibmr_ret is NULL, llist_entry is not executed. clean_nodes->next
instead of clean_nodes is added in clean_list.
So clean_nodes is discarded. It can not be used again.
The workqueue is executed periodically. So more and more clean_nodes are
discarded. Finally the clean_list is NULL.
Then this problem will occur.

Fixes: 1bc144b62524 ("net, rds, Replace xlist in net/rds/xlist.h with llist")
Signed-off-by: Zhu Yanjun <[email protected]>
Acked-by: Santosh Shilimkar <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/rds/ib_rdma.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)

--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -663,12 +663,14 @@ static int rds_ib_flush_mr_pool(struct r
wait_clean_list_grace();

list_to_llist_nodes(pool, &unmap_list, &clean_nodes, &clean_tail);
- if (ibmr_ret)
+ if (ibmr_ret) {
*ibmr_ret = llist_entry(clean_nodes, struct rds_ib_mr, llnode);
-
+ clean_nodes = clean_nodes->next;
+ }
/* more than one entry in llist nodes */
- if (clean_nodes->next)
- llist_add_batch(clean_nodes->next, clean_tail, &pool->clean_list);
+ if (clean_nodes)
+ llist_add_batch(clean_nodes, clean_tail,
+ &pool->clean_list);

}


2019-10-02 19:13:43

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 58/87] cifs: add spinlock for the openFileList to cifsInodeInfo

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Ronnie Sahlberg <[email protected]>

commit 487317c99477d00f22370625d53be3239febabbe upstream.

We can not depend on the tcon->open_file_lock here since in multiuser mode
we may have the same file/inode open via multiple different tcons.

The current code is race prone and will crash if one user deletes a file
at the same time a different user opens/create the file.

To avoid this we need to have a spinlock attached to the inode and not the tcon.

RHBZ: 1580165

Signed-off-by: Ronnie Sahlberg <[email protected]>
Signed-off-by: Steve French <[email protected]>
Reviewed-by: Pavel Shilovsky <[email protected]>
[bwh: Backported to 3.16: adjust context, indentation]
Signed-off-by: Ben Hutchings <[email protected]>
---
fs/cifs/cifsfs.c | 1 +
fs/cifs/cifsglob.h | 5 +++++
fs/cifs/file.c | 8 ++++++--
3 files changed, 12 insertions(+), 2 deletions(-)

--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -260,6 +260,7 @@ cifs_alloc_inode(struct super_block *sb)
cifs_inode->uniqueid = 0;
cifs_inode->createtime = 0;
cifs_inode->epoch = 0;
+ spin_lock_init(&cifs_inode->open_file_lock);
#ifdef CONFIG_CIFS_SMB2
generate_random_uuid(cifs_inode->lease_key);
#endif
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -1116,6 +1116,7 @@ struct cifsInodeInfo {
struct rw_semaphore lock_sem; /* protect the fields above */
/* BB add in lists for dirty pages i.e. write caching info for oplock */
struct list_head openFileList;
+ spinlock_t open_file_lock; /* protects openFileList */
__u32 cifsAttrs; /* e.g. DOS archive bit, sparse, compressed, system */
unsigned int oplock; /* oplock/lease level we have */
unsigned int epoch; /* used to track lease state changes */
@@ -1485,10 +1486,14 @@ require use of the stronger protocol */
* tcp_ses_lock protects:
* list operations on tcp and SMB session lists
* tcon->open_file_lock protects the list of open files hanging off the tcon
+ * inode->open_file_lock protects the openFileList hanging off the inode
* cfile->file_info_lock protects counters and fields in cifs file struct
* f_owner.lock protects certain per file struct operations
* mapping->page_lock protects certain per page operations
*
+ * Note that the cifs_tcon.open_file_lock should be taken before
+ * not after the cifsInodeInfo.open_file_lock
+ *
* Semaphores
* ----------
* sesSem operations on smb session
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -337,10 +337,12 @@ cifs_new_fileinfo(struct cifs_fid *fid,
list_add(&cfile->tlist, &tcon->openFileList);

/* if readable file instance put first in list*/
+ spin_lock(&cinode->open_file_lock);
if (file->f_mode & FMODE_READ)
list_add(&cfile->flist, &cinode->openFileList);
else
list_add_tail(&cfile->flist, &cinode->openFileList);
+ spin_unlock(&cinode->open_file_lock);
spin_unlock(&tcon->open_file_lock);

if (fid->purge_cache)
@@ -412,7 +414,9 @@ void _cifsFileInfo_put(struct cifsFileIn
cifs_add_pending_open_locked(&fid, cifs_file->tlink, &open);

/* remove it from the lists */
+ spin_lock(&cifsi->open_file_lock);
list_del(&cifs_file->flist);
+ spin_unlock(&cifsi->open_file_lock);
list_del(&cifs_file->tlist);

if (list_empty(&cifsi->openFileList)) {
@@ -1850,10 +1854,10 @@ refind_writable:
if (!rc)
return inv_file;
else {
- spin_lock(&tcon->open_file_lock);
+ spin_lock(&cifs_inode->open_file_lock);
list_move_tail(&inv_file->flist,
&cifs_inode->openFileList);
- spin_unlock(&tcon->open_file_lock);
+ spin_unlock(&cifs_inode->open_file_lock);
cifsFileInfo_put(inv_file);
++refind;
inv_file = NULL;

2019-10-02 19:13:46

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 70/87] scsi: ufs: Avoid runtime suspend possibly being blocked forever

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Stanley Chu <[email protected]>

commit 24e2e7a19f7e4b83d0d5189040d997bce3596473 upstream.

UFS runtime suspend can be triggered after pm_runtime_enable() is invoked
in ufshcd_pltfrm_init(). However if the first runtime suspend is triggered
before binding ufs_hba structure to ufs device structure via
platform_set_drvdata(), then UFS runtime suspend will be no longer
triggered in the future because its dev->power.runtime_error was set in the
first triggering and does not have any chance to be cleared.

To be more clear, dev->power.runtime_error is set if hba is NULL in
ufshcd_runtime_suspend() which returns -EINVAL to rpm_callback() where
dev->power.runtime_error is set as -EINVAL. In this case, any future
rpm_suspend() for UFS device fails because rpm_check_suspend_allowed()
fails due to non-zero
dev->power.runtime_error.

To resolve this issue, make sure the first UFS runtime suspend get valid
"hba" in ufshcd_runtime_suspend(): Enable UFS runtime PM only after hba is
successfully bound to UFS device structure.

Fixes: 62694735ca95 ([SCSI] ufs: Add runtime PM support for UFS host controller driver)
Signed-off-by: Stanley Chu <[email protected]>
Reviewed-by: Avri Altman <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
[bwh: Backported to 3.16:
- ufshcd_pltrfm_probe() doesn't allocate or free the host structure
- Adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/scsi/ufs/ufshcd-pltfrm.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)

--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -150,22 +150,19 @@ static int ufshcd_pltfrm_probe(struct pl
goto out;
}

- pm_runtime_set_active(&pdev->dev);
- pm_runtime_enable(&pdev->dev);
-
err = ufshcd_init(dev, &hba, mmio_base, irq);
if (err) {
dev_err(dev, "Intialization failed\n");
- goto out_disable_rpm;
+ goto out;
}

platform_set_drvdata(pdev, hba);

+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+
return 0;

-out_disable_rpm:
- pm_runtime_disable(&pdev->dev);
- pm_runtime_set_suspended(&pdev->dev);
out:
return err;
}

2019-10-02 19:13:51

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 63/87] btrfs: start readahead also in seed devices

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Naohiro Aota <[email protected]>

commit c4e0540d0ad49c8ceab06cceed1de27c4fe29f6e upstream.

Currently, btrfs does not consult seed devices to start readahead. As a
result, if readahead zone is added to the seed devices, btrfs_reada_wait()
indefinitely wait for the reada_ctl to finish.

You can reproduce the hung by modifying btrfs/163 to have larger initial
file size (e.g. xfs_io pwrite 4M instead of current 256K).

Fixes: 7414a03fbf9e ("btrfs: initial readahead code and prototypes")
Reviewed-by: Filipe Manana <[email protected]>
Signed-off-by: Naohiro Aota <[email protected]>
Signed-off-by: David Sterba <[email protected]>
---
fs/btrfs/reada.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/fs/btrfs/reada.c
+++ b/fs/btrfs/reada.c
@@ -764,6 +764,7 @@ static void __reada_start_machine(struct
u64 total = 0;
int i;

+again:
do {
enqueued = 0;
mutex_lock(&fs_devices->device_list_mutex);
@@ -776,6 +777,10 @@ static void __reada_start_machine(struct
mutex_unlock(&fs_devices->device_list_mutex);
total += enqueued;
} while (enqueued && total < 10000);
+ if (fs_devices->seed) {
+ fs_devices = fs_devices->seed;
+ goto again;
+ }

if (enqueued == 0)
return;

2019-10-02 19:13:54

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 02/87] spi: bitbang: Fix NULL pointer dereference in spi_unregister_master

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: YueHaibing <[email protected]>

commit 5caaf29af5ca82d5da8bc1d0ad07d9e664ccf1d8 upstream.

If spi_register_master fails in spi_bitbang_start
because device_add failure, We should return the
error code other than 0, otherwise calling
spi_bitbang_stop may trigger NULL pointer dereference
like this:

BUG: KASAN: null-ptr-deref in __list_del_entry_valid+0x45/0xd0
Read of size 8 at addr 0000000000000000 by task syz-executor.0/3661

CPU: 0 PID: 3661 Comm: syz-executor.0 Not tainted 5.1.0+ #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
dump_stack+0xa9/0x10e
? __list_del_entry_valid+0x45/0xd0
? __list_del_entry_valid+0x45/0xd0
__kasan_report+0x171/0x18d
? __list_del_entry_valid+0x45/0xd0
kasan_report+0xe/0x20
__list_del_entry_valid+0x45/0xd0
spi_unregister_controller+0x99/0x1b0
spi_lm70llp_attach+0x3ae/0x4b0 [spi_lm70llp]
? 0xffffffffc1128000
? klist_next+0x131/0x1e0
? driver_detach+0x40/0x40 [parport]
port_check+0x3b/0x50 [parport]
bus_for_each_dev+0x115/0x180
? subsys_dev_iter_exit+0x20/0x20
__parport_register_driver+0x1f0/0x210 [parport]
? 0xffffffffc1150000
do_one_initcall+0xb9/0x3b5
? perf_trace_initcall_level+0x270/0x270
? kasan_unpoison_shadow+0x30/0x40
? kasan_unpoison_shadow+0x30/0x40
do_init_module+0xe0/0x330
load_module+0x38eb/0x4270
? module_frob_arch_sections+0x20/0x20
? kernel_read_file+0x188/0x3f0
? find_held_lock+0x6d/0xd0
? fput_many+0x1a/0xe0
? __do_sys_finit_module+0x162/0x190
__do_sys_finit_module+0x162/0x190
? __ia32_sys_init_module+0x40/0x40
? __mutex_unlock_slowpath+0xb4/0x3f0
? wait_for_completion+0x240/0x240
? vfs_write+0x160/0x2a0
? lockdep_hardirqs_off+0xb5/0x100
? mark_held_locks+0x1a/0x90
? do_syscall_64+0x14/0x2a0
do_syscall_64+0x72/0x2a0
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Reported-by: Hulk Robot <[email protected]>
Fixes: 702a4879ec33 ("spi: bitbang: Let spi_bitbang_start() take a reference to master")
Signed-off-by: YueHaibing <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Axel Lin <[email protected]>
Reviewed-by: Mukesh Ojha <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/spi/spi-bitbang.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/spi/spi-bitbang.c
+++ b/drivers/spi/spi-bitbang.c
@@ -462,7 +462,7 @@ int spi_bitbang_start(struct spi_bitbang
if (ret)
spi_master_put(master);

- return 0;
+ return ret;
}
EXPORT_SYMBOL_GPL(spi_bitbang_start);


2019-10-02 19:13:57

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 11/87] USB: serial: pl2303: add Allied Telesis VT-Kit3

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Chris Packham <[email protected]>

commit c5f81656a18b271976a86724dadd8344e54de74e upstream.

This is adds the vendor and device id for the AT-VT-Kit3 which is a
pl2303-based device.

Signed-off-by: Chris Packham <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/usb/serial/pl2303.c | 1 +
drivers/usb/serial/pl2303.h | 3 +++
2 files changed, 4 insertions(+)

--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -100,6 +100,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(SANWA_VENDOR_ID, SANWA_PRODUCT_ID) },
{ USB_DEVICE(ADLINK_VENDOR_ID, ADLINK_ND6530_PRODUCT_ID) },
{ USB_DEVICE(SMART_VENDOR_ID, SMART_PRODUCT_ID) },
+ { USB_DEVICE(AT_VENDOR_ID, AT_VTKIT3_PRODUCT_ID) },
{ } /* Terminating entry */
};

--- a/drivers/usb/serial/pl2303.h
+++ b/drivers/usb/serial/pl2303.h
@@ -158,3 +158,6 @@
#define SMART_VENDOR_ID 0x0b8c
#define SMART_PRODUCT_ID 0x2303

+/* Allied Telesis VT-Kit3 */
+#define AT_VENDOR_ID 0x0caa
+#define AT_VTKIT3_PRODUCT_ID 0x3001

2019-10-02 19:14:03

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 77/87] MIPS: Add missing EHB in mtc0 -> mfc0 sequence.

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Dmitry Korotin <[email protected]>

commit 0b24cae4d535045f4c9e177aa228d4e97bad212c upstream.

Add a missing EHB (Execution Hazard Barrier) in mtc0 -> mfc0 sequence.
Without this execution hazard barrier it's possible for the value read
back from the KScratch register to be the value from before the mtc0.

Reproducible on P5600 & P6600.

The hazard is documented in the MIPS Architecture Reference Manual Vol.
III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev
6.03 table 8.1 which includes:

Producer | Consumer | Hazard
----------|----------|----------------------------
mtc0 | mfc0 | any coprocessor 0 register

Signed-off-by: Dmitry Korotin <[email protected]>
[[email protected]:
- Commit message tweaks.
- Add Fixes tags.
- Mark for stable back to v3.15 where P5600 support was introduced.]
Signed-off-by: Paul Burton <[email protected]>
Fixes: 3d8bfdd03072 ("MIPS: Use C0_KScratch (if present) to hold PGD pointer.")
Fixes: 829dcc0a956a ("MIPS: Add MIPS P5600 probe support")
Cc: [email protected]
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
arch/mips/mm/tlbex.c | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)

--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -374,6 +374,7 @@ static struct work_registers build_get_w
static void build_restore_work_registers(u32 **p)
{
if (scratch_reg >= 0) {
+ uasm_i_ehb(p);
UASM_i_MFC0(p, 1, c0_kscratch(), scratch_reg);
return;
}
@@ -665,10 +666,12 @@ static void build_restore_pagemask(u32 *
uasm_i_mtc0(p, 0, C0_PAGEMASK);
uasm_il_b(p, r, lid);
}
- if (scratch_reg >= 0)
+ if (scratch_reg >= 0) {
+ uasm_i_ehb(p);
UASM_i_MFC0(p, 1, c0_kscratch(), scratch_reg);
- else
+ } else {
UASM_i_LW(p, 1, scratchpad_offset(0), 0);
+ }
} else {
/* Reset default page size */
if (PM_DEFAULT_MASK >> 16) {
@@ -906,10 +909,12 @@ build_get_pgd_vmalloc64(u32 **p, struct
uasm_i_jr(p, ptr);

if (mode == refill_scratch) {
- if (scratch_reg >= 0)
+ if (scratch_reg >= 0) {
+ uasm_i_ehb(p);
UASM_i_MFC0(p, 1, c0_kscratch(), scratch_reg);
- else
+ } else {
UASM_i_LW(p, 1, scratchpad_offset(0), 0);
+ }
} else {
uasm_i_nop(p);
}
@@ -1215,6 +1220,7 @@ build_fast_tlb_refill_handler (u32 **p,
UASM_i_MTC0(p, odd, C0_ENTRYLO1); /* load it */

if (c0_scratch_reg >= 0) {
+ uasm_i_ehb(p);
UASM_i_MFC0(p, scratch, c0_kscratch(), c0_scratch_reg);
build_tlb_write_entry(p, l, r, tlb_random);
uasm_l_leave(l, *p);
@@ -1466,12 +1472,14 @@ static void build_setup_pgd(void)
uasm_i_dinsm(&p, a0, 0, 29, 64 - 29);
uasm_l_tlbl_goaround1(&l, p);
UASM_i_SLL(&p, a0, a0, 11);
- uasm_i_jr(&p, 31);
UASM_i_MTC0(&p, a0, C0_CONTEXT);
+ uasm_i_jr(&p, 31);
+ uasm_i_ehb(&p);
} else {
/* PGD in c0_KScratch */
- uasm_i_jr(&p, 31);
UASM_i_MTC0(&p, a0, c0_kscratch(), pgd_reg);
+ uasm_i_jr(&p, 31);
+ uasm_i_ehb(&p);
}
#else
#ifdef CONFIG_SMP
@@ -1485,13 +1493,16 @@ static void build_setup_pgd(void)
UASM_i_LA_mostly(&p, a2, pgdc);
UASM_i_SW(&p, a0, uasm_rel_lo(pgdc), a2);
#endif /* SMP */
- uasm_i_jr(&p, 31);

/* if pgd_reg is allocated, save PGD also to scratch register */
- if (pgd_reg != -1)
+ if (pgd_reg != -1) {
UASM_i_MTC0(&p, a0, c0_kscratch(), pgd_reg);
- else
+ uasm_i_jr(&p, 31);
+ uasm_i_ehb(&p);
+ } else {
+ uasm_i_jr(&p, 31);
uasm_i_nop(&p);
+ }
#endif
if (p >= tlbmiss_handler_setup_pgd_end)
panic("tlbmiss_handler_setup_pgd space exceeded");

2019-10-02 19:14:09

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 41/87] kernel/signal.c: trace_signal_deliver when signal_group_exit

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Zhenliang Wei <[email protected]>

commit 98af37d624ed8c83f1953b1b6b2f6866011fc064 upstream.

In the fixes commit, removing SIGKILL from each thread signal mask and
executing "goto fatal" directly will skip the call to
"trace_signal_deliver". At this point, the delivery tracking of the
SIGKILL signal will be inaccurate.

Therefore, we need to add trace_signal_deliver before "goto fatal" after
executing sigdelset.

Note: SEND_SIG_NOINFO matches the fact that SIGKILL doesn't have any info.

Link: http://lkml.kernel.org/r/[email protected]
Fixes: cf43a757fd4944 ("signal: Restore the stop PTRACE_EVENT_EXIT")
Signed-off-by: Zhenliang Wei <[email protected]>
Reviewed-by: Christian Brauner <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Cc: Eric W. Biederman <[email protected]>
Cc: Ivan Delalande <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Deepa Dinamani <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
kernel/signal.c | 2 ++
1 file changed, 2 insertions(+)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2277,6 +2277,8 @@ relock:
if (signal_group_exit(signal)) {
ksig->info.si_signo = signr = SIGKILL;
sigdelset(&current->pending.signal, SIGKILL);
+ trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO,
+ &sighand->action[SIGKILL - 1]);
recalc_sigpending();
goto fatal;
}

2019-10-02 19:14:11

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 31/87] i2c: dev: fix potential memory leak in i2cdev_ioctl_rdwr

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Yingjoe Chen <[email protected]>

commit a0692f0eef91354b62c2b4c94954536536be5425 upstream.

If I2C_M_RECV_LEN check failed, msgs[i].buf allocated by memdup_user
will not be freed. Pump index up so it will be freed.

Fixes: 838bfa6049fb ("i2c-dev: Add support for I2C_M_RECV_LEN")
Signed-off-by: Yingjoe Chen <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/i2c/i2c-dev.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -300,6 +300,7 @@ static noinline int i2cdev_ioctl_rdrw(st
rdwr_pa[i].buf[0] < 1 ||
rdwr_pa[i].len < rdwr_pa[i].buf[0] +
I2C_SMBUS_BLOCK_MAX) {
+ i++;
res = -EINVAL;
break;
}

2019-10-02 19:14:12

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 12/87] serial: sh-sci: disable DMA for uart_console

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: "George G. Davis" <[email protected]>

commit 099506cbbc79c0bd52b19cb6b930f256dabc3950 upstream.

As noted in commit 84b40e3b57ee ("serial: 8250: omap: Disable DMA for
console UART"), UART console lines use low-level PIO only access functions
which will conflict with use of the line when DMA is enabled, e.g. when
the console line is also used for systemd messages. So disable DMA
support for UART console lines.

Reported-by: Michael Rodin <[email protected]>
Link: https://patchwork.kernel.org/patch/10929511/
Tested-by: Eugeniu Rosca <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Reviewed-by: Wolfram Sang <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: George G. Davis <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/tty/serial/sh-sci.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1600,6 +1600,13 @@ static void sci_request_dma(struct uart_

dev_dbg(port->dev, "%s: port %d\n", __func__, port->line);

+ /*
+ * DMA on console may interfere with Kernel log messages which use
+ * plain putchar(). So, simply don't use it with a console.
+ */
+ if (uart_console(port))
+ return;
+
if (s->cfg->dma_slave_tx <= 0 || s->cfg->dma_slave_rx <= 0)
return;


2019-10-02 19:14:18

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 37/87] scsi: zfcp: fix missing zfcp_port reference put on -EBUSY from port_remove

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Steffen Maier <[email protected]>

commit d27e5e07f9c49bf2a6a4ef254ce531c1b4fb5a38 upstream.

With this early return due to zfcp_unit child(ren), we don't use the
zfcp_port reference from the earlier zfcp_get_port_by_wwpn() anymore and
need to put it.

Signed-off-by: Steffen Maier <[email protected]>
Fixes: d99b601b6338 ("[SCSI] zfcp: restore refcount check on port_remove")
Reviewed-by: Jens Remus <[email protected]>
Reviewed-by: Benjamin Block <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/s390/scsi/zfcp_sysfs.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/s390/scsi/zfcp_sysfs.c
+++ b/drivers/s390/scsi/zfcp_sysfs.c
@@ -261,6 +261,7 @@ static ssize_t zfcp_sysfs_port_remove_st
if (atomic_read(&port->units) > 0) {
retval = -EBUSY;
mutex_unlock(&zfcp_sysfs_port_units_mutex);
+ put_device(&port->dev); /* undo zfcp_get_port_by_wwpn() */
goto out;
}
/* port is about to be removed, so no more unit_add */

2019-10-02 19:14:22

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 36/87] usbip: usbip_host: fix stub_dev lock context imbalance regression

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Shuah Khan <[email protected]>

commit 3ea3091f1bd8586125848c62be295910e9802af0 upstream.

Fix the following sparse context imbalance regression introduced in
a patch that fixed sleeping function called from invalid context bug.

kbuild test robot reported on:

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-linus

Regressions in current branch:

drivers/usb/usbip/stub_dev.c:399:9: sparse: sparse: context imbalance in 'stub_probe' - different lock contexts for basic block
drivers/usb/usbip/stub_dev.c:418:13: sparse: sparse: context imbalance in 'stub_disconnect' - different lock contexts for basic block
drivers/usb/usbip/stub_dev.c:464:1-10: second lock on line 476

Error ids grouped by kconfigs:

recent_errors
├── i386-allmodconfig
│ └── drivers-usb-usbip-stub_dev.c:second-lock-on-line
├── x86_64-allmodconfig
│ ├── drivers-usb-usbip-stub_dev.c:sparse:sparse:context-imbalance-in-stub_disconnect-different-lock-contexts-for-basic-block
│ └── drivers-usb-usbip-stub_dev.c:sparse:sparse:context-imbalance-in-stub_probe-different-lock-contexts-for-basic-block
└── x86_64-allyesconfig
└── drivers-usb-usbip-stub_dev.c:second-lock-on-line

This is a real problem in an error leg where spin_lock() is called on an
already held lock.

Fix the imbalance in stub_probe() and stub_disconnect().

Signed-off-by: Shuah Khan <[email protected]>
Fixes: 0c9e8b3cad65 ("usbip: usbip_host: fix BUG: sleeping function called from invalid context")
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/staging/usbip/stub_dev.c | 36 +++++++++++++++++++++++-------------
1 file changed, 23 insertions(+), 13 deletions(-)

--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -367,14 +367,17 @@ static int stub_probe(struct usb_device
* See driver_probe_device() in driver/base/dd.c
*/
rc = -ENODEV;
- goto sdev_free;
+ if (!busid_priv)
+ goto sdev_free;
+
+ goto call_put_busid_priv;
}

if (udev->descriptor.bDeviceClass == USB_CLASS_HUB) {
dev_dbg(&udev->dev, "%s is a usb hub device... skip!\n",
udev_busid);
rc = -ENODEV;
- goto sdev_free;
+ goto call_put_busid_priv;
}

if (!strcmp(udev->bus->bus_name, "vhci_hcd")) {
@@ -383,7 +386,7 @@ static int stub_probe(struct usb_device
udev_busid);

rc = -ENODEV;
- goto sdev_free;
+ goto call_put_busid_priv;
}


@@ -402,6 +405,9 @@ static int stub_probe(struct usb_device
save_status = busid_priv->status;
busid_priv->status = STUB_BUSID_ALLOC;

+ /* release the busid_lock */
+ put_busid_priv(busid_priv);
+
/*
* Claim this hub port.
* It doesn't matter what value we pass as owner
@@ -414,9 +420,6 @@ static int stub_probe(struct usb_device
goto err_port;
}

- /* release the busid_lock */
- put_busid_priv(busid_priv);
-
rc = stub_add_files(&udev->dev);
if (rc) {
dev_err(&udev->dev, "stub_add_files for %s\n", udev_busid);
@@ -437,11 +440,17 @@ err_port:
spin_lock(&busid_priv->busid_lock);
busid_priv->sdev = NULL;
busid_priv->status = save_status;
-sdev_free:
- stub_device_free(sdev);
+ spin_unlock(&busid_priv->busid_lock);
+ /* lock is released - go to free */
+ goto sdev_free;
+
+call_put_busid_priv:
/* release the busid_lock */
put_busid_priv(busid_priv);

+sdev_free:
+ stub_device_free(sdev);
+
return rc;
}

@@ -477,7 +486,9 @@ static void stub_disconnect(struct usb_d
/* get stub_device */
if (!sdev) {
dev_err(&udev->dev, "could not get device");
- goto call_put_busid_priv;
+ /* release busid_lock */
+ put_busid_priv(busid_priv);
+ return;
}

dev_set_drvdata(&udev->dev, NULL);
@@ -507,7 +518,7 @@ static void stub_disconnect(struct usb_d
if (!busid_priv->shutdown_busid)
busid_priv->shutdown_busid = 1;
/* release busid_lock */
- put_busid_priv(busid_priv);
+ spin_unlock(&busid_priv->busid_lock);

/* shutdown the current connection */
shutdown_busid(busid_priv);
@@ -522,10 +533,9 @@ static void stub_disconnect(struct usb_d

if (busid_priv->status == STUB_BUSID_ALLOC)
busid_priv->status = STUB_BUSID_ADDED;
-
-call_put_busid_priv:
/* release busid_lock */
- put_busid_priv(busid_priv);
+ spin_unlock(&busid_priv->busid_lock);
+ return;
}

#ifdef CONFIG_PM

2019-10-02 19:14:36

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 75/87] be2net: fix link failure after ethtool offline test

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Petr Oros <[email protected]>

commit 2e5db6eb3c23e5dc8171eb8f6af7a97ef9fcf3a9 upstream.

Certain cards in conjunction with certain switches need a little more
time for link setup that results in ethtool link test failure after
offline test. Patch adds a loop that waits for a link setup finish.

Changes in v2:
- added fixes header

Fixes: 4276e47e2d1c ("be2net: Add link test to list of ethtool self tests.")
Signed-off-by: Petr Oros <[email protected]>
Reviewed-by: Ivan Vecera <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
.../net/ethernet/emulex/benet/be_ethtool.c | 28 +++++++++++++++----
1 file changed, 22 insertions(+), 6 deletions(-)

--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -779,7 +779,7 @@ static void be_self_test(struct net_devi
u64 *data)
{
struct be_adapter *adapter = netdev_priv(netdev);
- int status;
+ int status, cnt;
u8 link_status = 0;

if (adapter->function_caps & BE_FUNCTION_CAPS_SUPER_NIC) {
@@ -790,6 +790,9 @@ static void be_self_test(struct net_devi

memset(data, 0, sizeof(u64) * ETHTOOL_TESTS_NUM);

+ /* check link status before offline tests */
+ link_status = netif_carrier_ok(netdev);
+
if (test->flags & ETH_TEST_FL_OFFLINE) {
if (be_loopback_test(adapter, BE_MAC_LOOPBACK, &data[0]) != 0)
test->flags |= ETH_TEST_FL_FAILED;
@@ -810,13 +813,26 @@ static void be_self_test(struct net_devi
test->flags |= ETH_TEST_FL_FAILED;
}

- status = be_cmd_link_status_query(adapter, NULL, &link_status, 0);
- if (status) {
- test->flags |= ETH_TEST_FL_FAILED;
- data[4] = -1;
- } else if (!link_status) {
+ /* link status was down prior to test */
+ if (!link_status) {
test->flags |= ETH_TEST_FL_FAILED;
data[4] = 1;
+ return;
+ }
+
+ for (cnt = 10; cnt; cnt--) {
+ status = be_cmd_link_status_query(adapter, NULL, &link_status,
+ 0);
+ if (status) {
+ test->flags |= ETH_TEST_FL_FAILED;
+ data[4] = -1;
+ break;
+ }
+
+ if (link_status)
+ break;
+
+ msleep_interruptible(500);
}
}


2019-10-02 19:14:36

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 38/87] scsi: zfcp: fix to prevent port_remove with pure auto scan LUNs (only sdevs)

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Steffen Maier <[email protected]>

commit ef4021fe5fd77ced0323cede27979d80a56211ca upstream.

When the user tries to remove a zfcp port via sysfs, we only rejected it if
there are zfcp unit children under the port. With purely automatically
scanned LUNs there are no zfcp units but only SCSI devices. In such cases,
the port_remove erroneously continued. We close the port and this
implicitly closes all LUNs under the port. The SCSI devices survive with
their private zfcp_scsi_dev still holding a reference to the "removed"
zfcp_port (still allocated but invisible in sysfs) [zfcp_get_port_by_wwpn
in zfcp_scsi_slave_alloc]. This is not a problem as long as the fc_rport
stays blocked. Once (auto) port scan brings back the removed port, we
unblock its fc_rport again by design. However, there is no mechanism that
would recover (open) the LUNs under the port (no "ersfs_3" without
zfcp_unit [zfcp_erp_strategy_followup_success]). Any pending or new I/O to
such LUN leads to repeated:

Done: NEEDS_RETRY Result: hostbyte=DID_IMM_RETRY driverbyte=DRIVER_OK

See also v4.10 commit 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race
with LUN recovery"). Even a manual LUN recovery
(echo 0 > /sys/bus/scsi/devices/H:C:T:L/zfcp_failed)
does not help, as the LUN links to the old "removed" port which remains
to lack ZFCP_STATUS_COMMON_RUNNING [zfcp_erp_required_act].
The only workaround is to first ensure that the fc_rport is blocked
(e.g. port_remove again in case it was re-discovered by (auto) port scan),
then delete the SCSI devices, and finally re-discover by (auto) port scan.
The port scan includes an fc_rport unblock, which in turn triggers
a new scan on the scsi target to freshly get new pure auto scan LUNs.

Fix this by rejecting port_remove also if there are SCSI devices
(even without any zfcp_unit) under this port. Re-use mechanics from v3.7
commit d99b601b6338 ("[SCSI] zfcp: restore refcount check on port_remove").
However, we have to give up zfcp_sysfs_port_units_mutex earlier in unit_add
to prevent a deadlock with scsi_host scan taking shost->scan_mutex first
and then zfcp_sysfs_port_units_mutex now in our zfcp_scsi_slave_alloc().

Signed-off-by: Steffen Maier <[email protected]>
Fixes: b62a8d9b45b9 ("[SCSI] zfcp: Use SCSI device data zfcp scsi dev instead of zfcp unit")
Fixes: f8210e34887e ("[SCSI] zfcp: Allow midlayer to scan for LUNs when running in NPIV mode")
Reviewed-by: Benjamin Block <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/s390/scsi/zfcp_ext.h | 1 +
drivers/s390/scsi/zfcp_scsi.c | 9 ++++++
drivers/s390/scsi/zfcp_sysfs.c | 54 ++++++++++++++++++++++++++++++----
drivers/s390/scsi/zfcp_unit.c | 8 ++++-
4 files changed, 65 insertions(+), 7 deletions(-)

--- a/drivers/s390/scsi/zfcp_ext.h
+++ b/drivers/s390/scsi/zfcp_ext.h
@@ -160,6 +160,7 @@ extern const struct attribute_group *zfc
extern struct mutex zfcp_sysfs_port_units_mutex;
extern struct device_attribute *zfcp_sysfs_sdev_attrs[];
extern struct device_attribute *zfcp_sysfs_shost_attrs[];
+bool zfcp_sysfs_port_is_removing(const struct zfcp_port *const port);

/* zfcp_unit.c */
extern int zfcp_unit_add(struct zfcp_port *, u64);
--- a/drivers/s390/scsi/zfcp_scsi.c
+++ b/drivers/s390/scsi/zfcp_scsi.c
@@ -145,6 +145,15 @@ static int zfcp_scsi_slave_alloc(struct

zfcp_sdev->erp_action.port = port;

+ mutex_lock(&zfcp_sysfs_port_units_mutex);
+ if (zfcp_sysfs_port_is_removing(port)) {
+ /* port is already gone */
+ mutex_unlock(&zfcp_sysfs_port_units_mutex);
+ put_device(&port->dev); /* undo zfcp_get_port_by_wwpn() */
+ return -ENXIO;
+ }
+ mutex_unlock(&zfcp_sysfs_port_units_mutex);
+
unit = zfcp_unit_find(port, zfcp_scsi_dev_lun(sdev));
if (unit)
put_device(&unit->dev);
--- a/drivers/s390/scsi/zfcp_sysfs.c
+++ b/drivers/s390/scsi/zfcp_sysfs.c
@@ -235,6 +235,53 @@ static ZFCP_DEV_ATTR(adapter, port_resca

DEFINE_MUTEX(zfcp_sysfs_port_units_mutex);

+static void zfcp_sysfs_port_set_removing(struct zfcp_port *const port)
+{
+ lockdep_assert_held(&zfcp_sysfs_port_units_mutex);
+ atomic_set(&port->units, -1);
+}
+
+bool zfcp_sysfs_port_is_removing(const struct zfcp_port *const port)
+{
+ lockdep_assert_held(&zfcp_sysfs_port_units_mutex);
+ return atomic_read(&port->units) == -1;
+}
+
+static bool zfcp_sysfs_port_in_use(struct zfcp_port *const port)
+{
+ struct zfcp_adapter *const adapter = port->adapter;
+ unsigned long flags;
+ struct scsi_device *sdev;
+ bool in_use = true;
+
+ mutex_lock(&zfcp_sysfs_port_units_mutex);
+ if (atomic_read(&port->units) > 0)
+ goto unlock_port_units_mutex; /* zfcp_unit(s) under port */
+
+ spin_lock_irqsave(adapter->scsi_host->host_lock, flags);
+ __shost_for_each_device(sdev, adapter->scsi_host) {
+ const struct zfcp_scsi_dev *zsdev = sdev_to_zfcp(sdev);
+
+ if (sdev->sdev_state == SDEV_DEL ||
+ sdev->sdev_state == SDEV_CANCEL)
+ continue;
+ if (zsdev->port != port)
+ continue;
+ /* alive scsi_device under port of interest */
+ goto unlock_host_lock;
+ }
+
+ /* port is about to be removed, so no more unit_add or slave_alloc */
+ zfcp_sysfs_port_set_removing(port);
+ in_use = false;
+
+unlock_host_lock:
+ spin_unlock_irqrestore(adapter->scsi_host->host_lock, flags);
+unlock_port_units_mutex:
+ mutex_unlock(&zfcp_sysfs_port_units_mutex);
+ return in_use;
+}
+
static ssize_t zfcp_sysfs_port_remove_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -257,16 +304,11 @@ static ssize_t zfcp_sysfs_port_remove_st
else
retval = 0;

- mutex_lock(&zfcp_sysfs_port_units_mutex);
- if (atomic_read(&port->units) > 0) {
+ if (zfcp_sysfs_port_in_use(port)) {
retval = -EBUSY;
- mutex_unlock(&zfcp_sysfs_port_units_mutex);
put_device(&port->dev); /* undo zfcp_get_port_by_wwpn() */
goto out;
}
- /* port is about to be removed, so no more unit_add */
- atomic_set(&port->units, -1);
- mutex_unlock(&zfcp_sysfs_port_units_mutex);

write_lock_irq(&adapter->port_list_lock);
list_del(&port->list);
--- a/drivers/s390/scsi/zfcp_unit.c
+++ b/drivers/s390/scsi/zfcp_unit.c
@@ -122,7 +122,7 @@ int zfcp_unit_add(struct zfcp_port *port
int retval = 0;

mutex_lock(&zfcp_sysfs_port_units_mutex);
- if (atomic_read(&port->units) == -1) {
+ if (zfcp_sysfs_port_is_removing(port)) {
/* port is already gone */
retval = -ENODEV;
goto out;
@@ -166,8 +166,14 @@ int zfcp_unit_add(struct zfcp_port *port
write_lock_irq(&port->unit_list_lock);
list_add_tail(&unit->list, &port->unit_list);
write_unlock_irq(&port->unit_list_lock);
+ /*
+ * lock order: shost->scan_mutex before zfcp_sysfs_port_units_mutex
+ * due to zfcp_unit_scsi_scan() => zfcp_scsi_slave_alloc()
+ */
+ mutex_unlock(&zfcp_sysfs_port_units_mutex);

zfcp_unit_scsi_scan(unit);
+ return retval;

out:
mutex_unlock(&zfcp_sysfs_port_units_mutex);

2019-10-02 19:14:37

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 40/87] net-gro: fix use-after-free read in napi_gro_frags()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <[email protected]>

commit a4270d6795b0580287453ea55974d948393e66ef upstream.

If a network driver provides to napi_gro_frags() an
skb with a page fragment of exactly 14 bytes, the call
to gro_pull_from_frag0() will 'consume' the fragment
by calling skb_frag_unref(skb, 0), and the page might
be freed and reused.

Reading eth->h_proto at the end of napi_frags_skb() might
read mangled data, or crash under specific debugging features.

BUG: KASAN: use-after-free in napi_frags_skb net/core/dev.c:5833 [inline]
BUG: KASAN: use-after-free in napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
Read of size 2 at addr ffff88809366840c by task syz-executor599/8957

CPU: 1 PID: 8957 Comm: syz-executor599 Not tainted 5.2.0-rc1+ #32
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+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
__kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
kasan_report+0x12/0x20 mm/kasan/common.c:614
__asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:142
napi_frags_skb net/core/dev.c:5833 [inline]
napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
tun_get_user+0x2f3c/0x3ff0 drivers/net/tun.c:1991
tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2037
call_write_iter include/linux/fs.h:1872 [inline]
do_iter_readv_writev+0x5f8/0x8f0 fs/read_write.c:693
do_iter_write fs/read_write.c:970 [inline]
do_iter_write+0x184/0x610 fs/read_write.c:951
vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015
do_writev+0x15b/0x330 fs/read_write.c:1058

Fixes: a50e233c50db ("net-gro: restore frag0 optimization")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: syzbot <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4239,7 +4239,6 @@ static struct sk_buff *napi_frags_skb(st
skb_reset_mac_header(skb);
skb_gro_reset_offset(skb);

- eth = skb_gro_header_fast(skb, 0);
if (unlikely(skb_gro_header_hard(skb, hlen))) {
eth = skb_gro_header_slow(skb, hlen, 0);
if (unlikely(!eth)) {
@@ -4247,6 +4246,7 @@ static struct sk_buff *napi_frags_skb(st
return NULL;
}
} else {
+ eth = (const struct ethhdr *)skb->data;
gro_pull_from_frag0(skb, hlen);
NAPI_GRO_CB(skb)->frag0 += hlen;
NAPI_GRO_CB(skb)->frag0_len -= hlen;

2019-10-02 19:14:39

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 73/87] scsi: vmw_pscsi: Fix use-after-free in pvscsi_queue_lck()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Jan Kara <[email protected]>

commit 240b4cc8fd5db138b675297d4226ec46594d9b3b upstream.

Once we unlock adapter->hw_lock in pvscsi_queue_lck() nothing prevents just
queued scsi_cmnd from completing and freeing the request. Thus cmd->cmnd[0]
dereference can dereference already freed request leading to kernel crashes
or other issues (which one of our customers observed). Store cmd->cmnd[0]
in a local variable before unlocking adapter->hw_lock to fix the issue.

Signed-off-by: Jan Kara <[email protected]>
Reviewed-by: Ewan D. Milne <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/scsi/vmw_pvscsi.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -754,6 +754,7 @@ static int pvscsi_queue_lck(struct scsi_
struct pvscsi_adapter *adapter = shost_priv(host);
struct pvscsi_ctx *ctx;
unsigned long flags;
+ unsigned char op;

spin_lock_irqsave(&adapter->hw_lock, flags);

@@ -766,13 +767,14 @@ static int pvscsi_queue_lck(struct scsi_
}

cmd->scsi_done = done;
+ op = cmd->cmnd[0];

dev_dbg(&cmd->device->sdev_gendev,
- "queued cmd %p, ctx %p, op=%x\n", cmd, ctx, cmd->cmnd[0]);
+ "queued cmd %p, ctx %p, op=%x\n", cmd, ctx, op);

spin_unlock_irqrestore(&adapter->hw_lock, flags);

- pvscsi_kick_io(adapter, cmd->cmnd[0]);
+ pvscsi_kick_io(adapter, op);

return 0;
}

2019-10-02 19:14:41

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 82/87] sctp: change to hold sk after auth shkey is created successfully

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Xin Long <[email protected]>

commit 25bff6d5478b2a02368097015b7d8eb727c87e16 upstream.

Now in sctp_endpoint_init(), it holds the sk then creates auth
shkey. But when the creation fails, it doesn't release the sk,
which causes a sk defcnf leak,

Here to fix it by only holding the sk when auth shkey is created
successfully.

Fixes: a29a5bd4f5c3 ("[SCTP]: Implement SCTP-AUTH initializations.")
Reported-by: [email protected]
Reported-by: [email protected]
Signed-off-by: Xin Long <[email protected]>
Acked-by: Neil Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
net/sctp/endpointola.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/net/sctp/endpointola.c
+++ b/net/sctp/endpointola.c
@@ -126,10 +126,6 @@ static struct sctp_endpoint *sctp_endpoi
/* Initialize the bind addr area */
sctp_bind_addr_init(&ep->base.bind_addr, 0);

- /* Remember who we are attached to. */
- ep->base.sk = sk;
- sock_hold(ep->base.sk);
-
/* Create the lists of associations. */
INIT_LIST_HEAD(&ep->asocs);

@@ -165,6 +161,10 @@ static struct sctp_endpoint *sctp_endpoi
ep->auth_hmacs_list = auth_hmacs;
ep->auth_chunk_list = auth_chunks;

+ /* Remember who we are attached to. */
+ ep->base.sk = sk;
+ sock_hold(ep->base.sk);
+
return ep;

nomem_hmacs:

2019-10-02 19:14:50

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 06/87] USB: Fix slab-out-of-bounds write in usb_get_bos_descriptor

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Alan Stern <[email protected]>

commit a03ff54460817c76105f81f3aa8ef655759ccc9a upstream.

The syzkaller USB fuzzer found a slab-out-of-bounds write bug in the
USB core, caused by a failure to check the actual size of a BOS
descriptor. This patch adds a check to make sure the descriptor is at
least as large as it is supposed to be, so that the code doesn't
inadvertently access memory beyond the end of the allocated region
when assigning to dev->bos->desc->bNumDeviceCaps later on.

Signed-off-by: Alan Stern <[email protected]>
Reported-and-tested-by: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/usb/core/config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -897,8 +897,8 @@ int usb_get_bos_descriptor(struct usb_de

/* Get BOS descriptor */
ret = usb_get_descriptor(dev, USB_DT_BOS, 0, bos, USB_DT_BOS_SIZE);
- if (ret < USB_DT_BOS_SIZE) {
- dev_err(ddev, "unable to get BOS descriptor\n");
+ if (ret < USB_DT_BOS_SIZE || bos->bLength < USB_DT_BOS_SIZE) {
+ dev_err(ddev, "unable to get BOS descriptor or descriptor too short\n");
if (ret >= 0)
ret = -ENOMSG;
kfree(bos);

2019-10-02 19:14:55

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 52/87] ipv6: flowlabel: fl6_sock_lookup() must use atomic_inc_not_zero

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <[email protected]>

commit 65a3c497c0e965a552008db8bc2653f62bc925a1 upstream.

Before taking a refcount, make sure the object is not already
scheduled for deletion.

Same fix is needed in ipv6_flowlabel_opt()

Fixes: 18367681a10b ("ipv6 flowlabel: Convert np->ipv6_fl_list to RCU.")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Willem de Bruijn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/ipv6/ip6_flowlabel.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -255,9 +255,9 @@ struct ip6_flowlabel * fl6_sock_lookup(s
rcu_read_lock_bh();
for_each_sk_fl_rcu(np, sfl) {
struct ip6_flowlabel *fl = sfl->fl;
- if (fl->label == label) {
+
+ if (fl->label == label && atomic_inc_not_zero(&fl->users)) {
fl->lastuse = jiffies;
- atomic_inc(&fl->users);
rcu_read_unlock_bh();
return fl;
}
@@ -619,7 +619,8 @@ int ipv6_flowlabel_opt(struct sock *sk,
goto done;
}
fl1 = sfl->fl;
- atomic_inc(&fl1->users);
+ if (!atomic_inc_not_zero(&fl1->users))
+ fl1 = NULL;
break;
}
}

2019-10-02 19:14:57

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 27/87] genwqe: Prevent an integer overflow in the ioctl

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

commit 110080cea0d0e4dfdb0b536e7f8a5633ead6a781 upstream.

There are a couple potential integer overflows here.

round_up(m->size + (m->addr & ~PAGE_MASK), PAGE_SIZE);

The first thing is that the "m->size + (...)" addition could overflow,
and the second is that round_up() overflows to zero if the result is
within PAGE_SIZE of the type max.

In this code, the "m->size" variable is an u64 but we're saving the
result in "map_size" which is an unsigned long and genwqe_user_vmap()
takes an unsigned long as well. So I have used ULONG_MAX as the upper
bound. From a practical perspective unsigned long is fine/better than
trying to change all the types to u64.

Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/misc/genwqe/card_dev.c | 2 ++
drivers/misc/genwqe/card_utils.c | 4 ++++
2 files changed, 6 insertions(+)

--- a/drivers/misc/genwqe/card_dev.c
+++ b/drivers/misc/genwqe/card_dev.c
@@ -779,6 +779,8 @@ static int genwqe_pin_mem(struct genwqe_

if ((m->addr == 0x0) || (m->size == 0))
return -EINVAL;
+ if (m->size > ULONG_MAX - PAGE_SIZE - (m->addr & ~PAGE_MASK))
+ return -EINVAL;

map_addr = (m->addr & PAGE_MASK);
map_size = round_up(m->size + (m->addr & ~PAGE_MASK), PAGE_SIZE);
--- a/drivers/misc/genwqe/card_utils.c
+++ b/drivers/misc/genwqe/card_utils.c
@@ -571,6 +571,10 @@ int genwqe_user_vmap(struct genwqe_dev *
/* determine space needed for page_list. */
data = (unsigned long)uaddr;
offs = offset_in_page(data);
+ if (size > ULONG_MAX - PAGE_SIZE - offs) {
+ m->size = 0; /* mark unused and not added */
+ return -EINVAL;
+ }
m->nr_pages = DIV_ROUND_UP(offs + size, PAGE_SIZE);

m->page_list = kcalloc(m->nr_pages,

2019-10-02 19:15:06

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 33/87] llc: fix skb leak in llc_build_and_send_ui_pkt()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <[email protected]>

commit 8fb44d60d4142cd2a440620cd291d346e23c131e upstream.

If llc_mac_hdr_init() returns an error, we must drop the skb
since no llc_build_and_send_ui_pkt() caller will take care of this.

BUG: memory leak
unreferenced object 0xffff8881202b6800 (size 2048):
comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.590s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<00000000e25b5abe>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
[<00000000e25b5abe>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<00000000e25b5abe>] slab_alloc mm/slab.c:3326 [inline]
[<00000000e25b5abe>] __do_kmalloc mm/slab.c:3658 [inline]
[<00000000e25b5abe>] __kmalloc+0x161/0x2c0 mm/slab.c:3669
[<00000000a1ae188a>] kmalloc include/linux/slab.h:552 [inline]
[<00000000a1ae188a>] sk_prot_alloc+0xd6/0x170 net/core/sock.c:1608
[<00000000ded25bbe>] sk_alloc+0x35/0x2f0 net/core/sock.c:1662
[<000000002ecae075>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950
[<00000000551f7c47>] llc_ui_create+0x7b/0x140 net/llc/af_llc.c:173
[<0000000029027f0e>] __sock_create+0x164/0x250 net/socket.c:1430
[<000000008bdec225>] sock_create net/socket.c:1481 [inline]
[<000000008bdec225>] __sys_socket+0x69/0x110 net/socket.c:1523
[<00000000b6439228>] __do_sys_socket net/socket.c:1532 [inline]
[<00000000b6439228>] __se_sys_socket net/socket.c:1530 [inline]
[<00000000b6439228>] __x64_sys_socket+0x1e/0x30 net/socket.c:1530
[<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
[<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

BUG: memory leak
unreferenced object 0xffff88811d750d00 (size 224):
comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.600s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 f0 0c 24 81 88 ff ff 00 68 2b 20 81 88 ff ff ...$.....h+ ....
backtrace:
[<0000000053026172>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
[<0000000053026172>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<0000000053026172>] slab_alloc_node mm/slab.c:3269 [inline]
[<0000000053026172>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
[<00000000fa8f3c30>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:198
[<00000000d96fdafb>] alloc_skb include/linux/skbuff.h:1058 [inline]
[<00000000d96fdafb>] alloc_skb_with_frags+0x5f/0x250 net/core/skbuff.c:5327
[<000000000a34a2e7>] sock_alloc_send_pskb+0x269/0x2a0 net/core/sock.c:2225
[<00000000ee39999b>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2242
[<00000000e034d810>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
[<00000000c0bc8445>] sock_sendmsg_nosec net/socket.c:652 [inline]
[<00000000c0bc8445>] sock_sendmsg+0x54/0x70 net/socket.c:671
[<000000003b687167>] __sys_sendto+0x148/0x1f0 net/socket.c:1964
[<00000000922d78d9>] __do_sys_sendto net/socket.c:1976 [inline]
[<00000000922d78d9>] __se_sys_sendto net/socket.c:1972 [inline]
[<00000000922d78d9>] __x64_sys_sendto+0x2a/0x30 net/socket.c:1972
[<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
[<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: syzbot <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/llc/llc_output.c | 2 ++
1 file changed, 2 insertions(+)

--- a/net/llc/llc_output.c
+++ b/net/llc/llc_output.c
@@ -72,6 +72,8 @@ int llc_build_and_send_ui_pkt(struct llc
rc = llc_mac_hdr_init(skb, skb->dev->dev_addr, dmac);
if (likely(!rc))
rc = dev_queue_xmit(skb);
+ else
+ kfree_skb(skb);
return rc;
}


2019-10-02 19:15:13

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 34/87] CIFS: cifs_read_allocate_pages: don't iterate through whole page array on ENOMEM

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Roberto Bergantinos Corpas <[email protected]>

commit 31fad7d41e73731f05b8053d17078638cf850fa6 upstream.

In cifs_read_allocate_pages, in case of ENOMEM, we go through
whole rdata->pages array but we have failed the allocation before
nr_pages, therefore we may end up calling put_page with NULL
pointer, causing oops

Signed-off-by: Roberto Bergantinos Corpas <[email protected]>
Acked-by: Pavel Shilovsky <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
fs/cifs/file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -2744,7 +2744,9 @@ cifs_read_allocate_pages(struct cifs_rea
}

if (rc) {
- for (i = 0; i < nr_pages; i++) {
+ unsigned int nr_page_failed = i;
+
+ for (i = 0; i < nr_page_failed; i++) {
put_page(rdata->pages[i]);
rdata->pages[i] = NULL;
}

2019-10-02 19:15:13

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 42/87] USB: usb-storage: Add new ID to ums-realtek

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Kai-Heng Feng <[email protected]>

commit 1a6dd3fea131276a4fc44ae77b0f471b0b473577 upstream.

There is one more Realtek card reader requires ums-realtek to work
correctly.

Add the device ID to support it.

Signed-off-by: Kai-Heng Feng <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/usb/storage/unusual_realtek.h | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/usb/storage/unusual_realtek.h
+++ b/drivers/usb/storage/unusual_realtek.h
@@ -28,6 +28,11 @@ UNUSUAL_DEV(0x0bda, 0x0138, 0x0000, 0x99
"USB Card Reader",
USB_SC_DEVICE, USB_PR_DEVICE, init_realtek_cr, 0),

+UNUSUAL_DEV(0x0bda, 0x0153, 0x0000, 0x9999,
+ "Realtek",
+ "USB Card Reader",
+ USB_SC_DEVICE, USB_PR_DEVICE, init_realtek_cr, 0),
+
UNUSUAL_DEV(0x0bda, 0x0158, 0x0000, 0x9999,
"Realtek",
"USB Card Reader",

2019-10-02 19:15:18

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 23/87] Input: uinput - add compat ioctl number translation for UI_*_FF_UPLOAD

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Andrey Smirnov <[email protected]>

commit 7c7da40da1640ce6814dab1e8031b44e19e5a3f6 upstream.

In the case of compat syscall ioctl numbers for UI_BEGIN_FF_UPLOAD and
UI_END_FF_UPLOAD need to be adjusted before being passed on
uinput_ioctl_handler() since code built with -m32 will be passing
slightly different values. Extend the code already covering
UI_SET_PHYS to cover UI_BEGIN_FF_UPLOAD and UI_END_FF_UPLOAD as well.

Reported-by: Pierre-Loup A. Griffais <[email protected]>
Signed-off-by: Andrey Smirnov <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/input/misc/uinput.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)

--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -908,13 +908,31 @@ static long uinput_ioctl(struct file *fi

#ifdef CONFIG_COMPAT

-#define UI_SET_PHYS_COMPAT _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
+/*
+ * These IOCTLs change their size and thus their numbers between
+ * 32 and 64 bits.
+ */
+#define UI_SET_PHYS_COMPAT \
+ _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t)
+#define UI_BEGIN_FF_UPLOAD_COMPAT \
+ _IOWR(UINPUT_IOCTL_BASE, 200, struct uinput_ff_upload_compat)
+#define UI_END_FF_UPLOAD_COMPAT \
+ _IOW(UINPUT_IOCTL_BASE, 201, struct uinput_ff_upload_compat)

static long uinput_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
- if (cmd == UI_SET_PHYS_COMPAT)
+ switch (cmd) {
+ case UI_SET_PHYS_COMPAT:
cmd = UI_SET_PHYS;
+ break;
+ case UI_BEGIN_FF_UPLOAD_COMPAT:
+ cmd = UI_BEGIN_FF_UPLOAD;
+ break;
+ case UI_END_FF_UPLOAD_COMPAT:
+ cmd = UI_END_FF_UPLOAD;
+ break;
+ }

return uinput_ioctl_handler(file, cmd, arg, compat_ptr(arg));
}

2019-10-02 19:15:27

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 55/87] KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Dave Martin <[email protected]>

commit df205b5c63281e4f32caac22adda18fd68795e80 upstream.

Since commit d26c25a9d19b ("arm64: KVM: Tighten guest core register
access from userspace"), KVM_{GET,SET}_ONE_REG rejects register IDs
that do not correspond to a single underlying architectural register.

KVM_GET_REG_LIST was not changed to match however: instead, it
simply yields a list of 32-bit register IDs that together cover the
whole kvm_regs struct. This means that if userspace tries to use
the resulting list of IDs directly to drive calls to KVM_*_ONE_REG,
some of those calls will now fail.

This was not the intention. Instead, iterating KVM_*_ONE_REG over
the list of IDs returned by KVM_GET_REG_LIST should be guaranteed
to work.

This patch fixes the problem by splitting validate_core_offset()
into a backend core_reg_size_from_offset() which does all of the
work except for checking that the size field in the register ID
matches, and kvm_arm_copy_reg_indices() and num_core_regs() are
converted to use this to enumerate the valid offsets.

kvm_arm_copy_reg_indices() now also sets the register ID size field
appropriately based on the value returned, so the register ID
supplied to userspace is fully qualified for use with the register
access ioctls.

Fixes: d26c25a9d19b ("arm64: KVM: Tighten guest core register access from userspace")
Signed-off-by: Dave Martin <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Tested-by: Andrew Jones <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
[bwh: Backported to 3.16:
- Don't add unused vcpu parameter
- Adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -46,9 +46,8 @@ static u64 core_reg_offset_from_id(u64 i
return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
}

-static int validate_core_offset(const struct kvm_one_reg *reg)
+static int core_reg_size_from_offset(u64 off)
{
- u64 off = core_reg_offset_from_id(reg->id);
int size;

switch (off) {
@@ -78,13 +77,26 @@ static int validate_core_offset(const st
return -EINVAL;
}

- if (KVM_REG_SIZE(reg->id) == size &&
- IS_ALIGNED(off, size / sizeof(__u32)))
- return 0;
+ if (IS_ALIGNED(off, size / sizeof(__u32)))
+ return size;

return -EINVAL;
}

+static int validate_core_offset(const struct kvm_one_reg *reg)
+{
+ u64 off = core_reg_offset_from_id(reg->id);
+ int size = core_reg_size_from_offset(off);
+
+ if (size < 0)
+ return -EINVAL;
+
+ if (KVM_REG_SIZE(reg->id) != size)
+ return -EINVAL;
+
+ return 0;
+}
+
static int get_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
/*
@@ -197,10 +209,33 @@ unsigned long kvm_arm_num_regs(struct kv
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
{
unsigned int i;
- const u64 core_reg = KVM_REG_ARM64 | KVM_REG_SIZE_U64 | KVM_REG_ARM_CORE;

for (i = 0; i < sizeof(struct kvm_regs) / sizeof(__u32); i++) {
- if (put_user(core_reg | i, uindices))
+ u64 reg = KVM_REG_ARM64 | KVM_REG_ARM_CORE | i;
+ int size = core_reg_size_from_offset(i);
+
+ if (size < 0)
+ continue;
+
+ switch (size) {
+ case sizeof(__u32):
+ reg |= KVM_REG_SIZE_U32;
+ break;
+
+ case sizeof(__u64):
+ reg |= KVM_REG_SIZE_U64;
+ break;
+
+ case sizeof(__uint128_t):
+ reg |= KVM_REG_SIZE_U128;
+ break;
+
+ default:
+ WARN_ON(1);
+ continue;
+ }
+
+ if (put_user(reg, uindices))
return -EFAULT;
uindices++;
}

2019-10-02 19:15:33

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 14/87] powerpc/perf: add missing put_cpu_var in power_pmu_event_init

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Jan Stancek <[email protected]>

commit 68de8867ea5d99127e836c23f6bccf4d44859623 upstream.

One path in power_pmu_event_init() calls get_cpu_var(), but is
missing matching call to put_cpu_var(), which causes preemption
imbalance and crash in user-space:

Page fault in user mode with in_atomic() = 1 mm = c000001fefa5a280
NIP = 3fff9bf2cae0 MSR = 900000014280f032
Oops: Weird page fault, sig: 11 [#23]
SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: <snip>
CPU: 43 PID: 10285 Comm: a.out Tainted: G D 4.0.0-rc5+ #1
task: c000001fe82c9200 ti: c000001fe835c000 task.ti: c000001fe835c000
NIP: 00003fff9bf2cae0 LR: 00003fff9bee4898 CTR: 00003fff9bf2cae0
REGS: c000001fe835fea0 TRAP: 0401 Tainted: G D (4.0.0-rc5+)
MSR: 900000014280f032 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI> CR: 22000028 XER: 00000000
CFAR: 00003fff9bee4894 SOFTE: 1
GPR00: 00003fff9bee494c 00003fffe01c2ee0 00003fff9c084410 0000000010020068
GPR04: 0000000000000000 0000000000000002 0000000000000008 0000000000000001
GPR08: 0000000000000001 00003fff9c074a30 00003fff9bf2cae0 00003fff9bf2cd70
GPR12: 0000000052000022 00003fff9c10b700
NIP [00003fff9bf2cae0] 0x3fff9bf2cae0
LR [00003fff9bee4898] 0x3fff9bee4898
Call Trace:
---[ end trace 5d3d952b5d4185d4 ]---

BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41
in_atomic(): 1, irqs_disabled(): 0, pid: 10285, name: a.out
INFO: lockdep is turned off.
CPU: 43 PID: 10285 Comm: a.out Tainted: G D 4.0.0-rc5+ #1
Call Trace:
[c000001fe835f990] [c00000000089c014] .dump_stack+0x98/0xd4 (unreliable)
[c000001fe835fa10] [c0000000000e4138] .___might_sleep+0x1d8/0x2e0
[c000001fe835faa0] [c000000000888da8] .down_read+0x38/0x110
[c000001fe835fb30] [c0000000000bf2f4] .exit_signals+0x24/0x160
[c000001fe835fbc0] [c0000000000abde0] .do_exit+0xd0/0xe70
[c000001fe835fcb0] [c00000000001f4c4] .die+0x304/0x450
[c000001fe835fd60] [c00000000088e1f4] .do_page_fault+0x2d4/0x900
[c000001fe835fe30] [c000000000008664] handle_page_fault+0x10/0x30
note: a.out[10285] exited with preempt_count 1

Reproducer:
#include <stdio.h>
#include <unistd.h>
#include <syscall.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <linux/perf_event.h>
#include <linux/hw_breakpoint.h>

static struct perf_event_attr event = {
.type = PERF_TYPE_RAW,
.size = sizeof(struct perf_event_attr),
.sample_type = PERF_SAMPLE_BRANCH_STACK,
.branch_sample_type = PERF_SAMPLE_BRANCH_ANY_RETURN,
};

int main()
{
syscall(__NR_perf_event_open, &event, 0, -1, -1, 0);
}

Signed-off-by: Jan Stancek <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
arch/powerpc/perf/core-book3s.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1825,8 +1825,10 @@ static int power_pmu_event_init(struct p
cpuhw->bhrb_filter = ppmu->bhrb_filter_map(
event->attr.branch_sample_type);

- if(cpuhw->bhrb_filter == -1)
+ if (cpuhw->bhrb_filter == -1) {
+ put_cpu_var(cpu_hw_events);
return -EOPNOTSUPP;
+ }
}

put_cpu_var(cpu_hw_events);

2019-10-02 19:15:34

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 53/87] ptrace: restore smp_rmb() in __ptrace_may_access()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Jann Horn <[email protected]>

commit f6581f5b55141a95657ef5742cf6a6bfa20a109f upstream.

Restore the read memory barrier in __ptrace_may_access() that was deleted
a couple years ago. Also add comments on this barrier and the one it pairs
with to explain why they're there (as far as I understand).

Fixes: bfedb589252c ("mm: Add a user_ns owner to mm_struct and fix ptrace permission checks")
Acked-by: Kees Cook <[email protected]>
Acked-by: Oleg Nesterov <[email protected]>
Signed-off-by: Jann Horn <[email protected]>
Signed-off-by: Eric W. Biederman <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
kernel/cred.c | 9 +++++++++
kernel/ptrace.c | 10 ++++++++++
2 files changed, 19 insertions(+)

--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -439,6 +439,15 @@ int commit_creds(struct cred *new)
if (task->mm)
set_dumpable(task->mm, suid_dumpable);
task->pdeath_signal = 0;
+ /*
+ * If a task drops privileges and becomes nondumpable,
+ * the dumpability change must become visible before
+ * the credential change; otherwise, a __ptrace_may_access()
+ * racing with this change may be able to attach to a task it
+ * shouldn't be able to attach to (as if the task had dropped
+ * privileges without becoming nondumpable).
+ * Pairs with a read barrier in __ptrace_may_access().
+ */
smp_wmb();
}

--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -324,6 +324,16 @@ static int __ptrace_may_access(struct ta
return -EPERM;
ok:
rcu_read_unlock();
+ /*
+ * If a task drops privileges and becomes nondumpable (through a syscall
+ * like setresuid()) while we are trying to access it, we must ensure
+ * that the dumpability is read after the credentials; otherwise,
+ * we may be able to attach to a task that we shouldn't be able to
+ * attach to (as if the task had dropped privileges without becoming
+ * nondumpable).
+ * Pairs with a write barrier in commit_creds().
+ */
+ smp_rmb();
mm = task->mm;
if (mm &&
((get_dumpable(mm) != SUID_DUMP_USER) &&

2019-10-02 19:15:37

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 49/87] can: flexcan: fix timeout when set small bitrate

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Joakim Zhang <[email protected]>

commit 247e5356a709eb49a0d95ff2a7f07dac05c8252c upstream.

Current we can meet timeout issue when setting a small bitrate like
10000 as follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock =
30MHZ):

| root@imx6ul7d:~# ip link set can0 up type can bitrate 10000

A link change request failed with some changes committed already.
Interface can0 may have been left with an inconsistent configuration,
please check.

| RTNETLINK answers: Connection timed out

It is caused by calling of flexcan_chip_unfreeze() timeout.

Originally the code is using usleep_range(10, 20) for unfreeze
operation, but the patch (8badd65 can: flexcan: avoid calling
usleep_range from interrupt context) changed it into udelay(10) which is
only a half delay of before, there're also some other delay changes.

After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue.

Meanwhile, Rasmus Villemoes reported that even with a timeout of 100,
flexcan_probe() fails on the MPC8309, which requires a value of at least
140 to work reliably. 250 works for everyone.

Signed-off-by: Joakim Zhang <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/net/can/flexcan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -157,7 +157,7 @@

#define FLEXCAN_MB_CODE_MASK (0xf0ffffff)

-#define FLEXCAN_TIMEOUT_US (50)
+#define FLEXCAN_TIMEOUT_US (250)

/*
* FLEXCAN hardware feature flags

2019-10-02 19:15:45

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 48/87] pktgen: do not sleep with the thread lock held.

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Paolo Abeni <[email protected]>

commit 720f1de4021f09898b8c8443f3b3e995991b6e3a upstream.

Currently, the process issuing a "start" command on the pktgen procfs
interface, acquires the pktgen thread lock and never release it, until
all pktgen threads are completed. The above can blocks indefinitely any
other pktgen command and any (even unrelated) netdevice removal - as
the pktgen netdev notifier acquires the same lock.

The issue is demonstrated by the following script, reported by Matteo:

ip -b - <<'EOF'
link add type dummy
link add type veth
link set dummy0 up
EOF
modprobe pktgen
echo reset >/proc/net/pktgen/pgctrl
{
echo rem_device_all
echo add_device dummy0
} >/proc/net/pktgen/kpktgend_0
echo count 0 >/proc/net/pktgen/dummy0
echo start >/proc/net/pktgen/pgctrl &
sleep 1
rmmod veth

Fix the above releasing the thread lock around the sleep call.

Additionally we must prevent racing with forcefull rmmod - as the
thread lock no more protects from them. Instead, acquire a self-reference
before waiting for any thread. As a side effect, running

rmmod pktgen

while some thread is running now fails with "module in use" error,
before this patch such command hanged indefinitely.

Note: the issue predates the commit reported in the fixes tag, but
this fix can't be applied before the mentioned commit.

v1 -> v2:
- no need to check for thread existence after flipping the lock,
pktgen threads are freed only at net exit time
-

Fixes: 6146e6a43b35 ("[PKTGEN]: Removes thread_{un,}lock() macros.")
Reported-and-tested-by: Matteo Croce <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/core/pktgen.c | 11 +++++++++++
1 file changed, 11 insertions(+)

--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3055,7 +3055,13 @@ static int pktgen_wait_thread_run(struct

if_unlock(t);

+ /* note: 't' will still be around even after the unlock/lock
+ * cycle because pktgen_thread threads are only cleared at
+ * net exit
+ */
+ mutex_unlock(&pktgen_thread_lock);
msleep_interruptible(100);
+ mutex_lock(&pktgen_thread_lock);

if (signal_pending(current))
goto signal;
@@ -3072,6 +3078,10 @@ static int pktgen_wait_all_threads_run(s
struct pktgen_thread *t;
int sig = 1;

+ /* prevent from racing with rmmod */
+ if (!try_module_get(THIS_MODULE))
+ return sig;
+
mutex_lock(&pktgen_thread_lock);

list_for_each_entry(t, &pn->pktgen_threads, th_list) {
@@ -3085,6 +3095,7 @@ static int pktgen_wait_all_threads_run(s
t->control |= (T_STOP);

mutex_unlock(&pktgen_thread_lock);
+ module_put(THIS_MODULE);
return sig;
}


2019-10-02 19:15:49

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 16/87] usb: xhci: avoid null pointer deref when bos field is NULL

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Carsten Schmid <[email protected]>

commit 7aa1bb2ffd84d6b9b5f546b079bb15cd0ab6e76e upstream.

With defective USB sticks we see the following error happen:
usb 1-3: new high-speed USB device number 6 using xhci_hcd
usb 1-3: device descriptor read/64, error -71
usb 1-3: device descriptor read/64, error -71
usb 1-3: new high-speed USB device number 7 using xhci_hcd
usb 1-3: device descriptor read/64, error -71
usb 1-3: unable to get BOS descriptor set
usb 1-3: New USB device found, idVendor=0781, idProduct=5581
usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
...
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008

This comes from the following place:
[ 1660.215380] IP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd]
[ 1660.222092] PGD 0 P4D 0
[ 1660.224918] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 1660.425520] CPU: 1 PID: 38 Comm: kworker/1:1 Tainted: P U W O 4.14.67-apl #1
[ 1660.434277] Workqueue: usb_hub_wq hub_event [usbcore]
[ 1660.439918] task: ffffa295b6ae4c80 task.stack: ffffad4580150000
[ 1660.446532] RIP: 0010:xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd]
[ 1660.453821] RSP: 0018:ffffad4580153c70 EFLAGS: 00010046
[ 1660.459655] RAX: 0000000000000000 RBX: ffffa295b4d7c000 RCX: 0000000000000002
[ 1660.467625] RDX: 0000000000000002 RSI: ffffffff984a55b2 RDI: ffffffff984a55b2
[ 1660.475586] RBP: ffffad4580153cc8 R08: 0000000000d6520a R09: 0000000000000001
[ 1660.483556] R10: ffffad4580a004a0 R11: 0000000000000286 R12: ffffa295b4d7c000
[ 1660.491525] R13: 0000000000010648 R14: ffffa295a84e1800 R15: 0000000000000000
[ 1660.499494] FS: 0000000000000000(0000) GS:ffffa295bfc80000(0000) knlGS:0000000000000000
[ 1660.508530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1660.514947] CR2: 0000000000000008 CR3: 000000025a114000 CR4: 00000000003406a0
[ 1660.522917] Call Trace:
[ 1660.525657] usb_set_usb2_hardware_lpm+0x3d/0x70 [usbcore]
[ 1660.531792] usb_disable_device+0x242/0x260 [usbcore]
[ 1660.537439] usb_disconnect+0xc1/0x2b0 [usbcore]
[ 1660.542600] hub_event+0x596/0x18f0 [usbcore]
[ 1660.547467] ? trace_preempt_on+0xdf/0x100
[ 1660.552040] ? process_one_work+0x1c1/0x410
[ 1660.556708] process_one_work+0x1d2/0x410
[ 1660.561184] ? preempt_count_add.part.3+0x21/0x60
[ 1660.566436] worker_thread+0x2d/0x3f0
[ 1660.570522] kthread+0x122/0x140
[ 1660.574123] ? process_one_work+0x410/0x410
[ 1660.578792] ? kthread_create_on_node+0x60/0x60
[ 1660.583849] ret_from_fork+0x3a/0x50
[ 1660.587839] Code: 00 49 89 c3 49 8b 84 24 50 16 00 00 8d 4a ff 48 8d 04 c8 48 89 ca 4c 8b 10 45 8b 6a 04 48 8b 00 48 89 45 c0 49 8b 86 80 03 00 00 <48> 8b 40 08 8b 40 03 0f 1f 44 00 00 45 85 ff 0f 84 81 01 00 00
[ 1660.608980] RIP: xhci_set_usb2_hardware_lpm+0xdf/0x3d0 [xhci_hcd] RSP: ffffad4580153c70
[ 1660.617921] CR2: 0000000000000008

Tracking this down shows that udev->bos is NULL in the following code:
(xhci.c, in xhci_set_usb2_hardware_lpm)
field = le32_to_cpu(udev->bos->ext_cap->bmAttributes); <<<<<<< here

xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
enable ? "enable" : "disable", port_num + 1);

if (enable) {
/* Host supports BESL timeout instead of HIRD */
if (udev->usb2_hw_lpm_besl_capable) {
/* if device doesn't have a preferred BESL value use a
* default one which works with mixed HIRD and BESL
* systems. See XHCI_DEFAULT_BESL definition in xhci.h
*/
if ((field & USB_BESL_SUPPORT) &&
(field & USB_BESL_BASELINE_VALID))
hird = USB_GET_BESL_BASELINE(field);
else
hird = udev->l1_params.besl;

The failing case is when disabling LPM. So it is sufficient to avoid
access to udev->bos by moving the instruction into the "enable" clause.

Signed-off-by: Carsten Schmid <[email protected]>
Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4178,7 +4178,6 @@ int xhci_set_usb2_hardware_lpm(struct us
pm_addr = port_array[port_num] + PORTPMSC;
pm_val = readl(pm_addr);
hlpm_addr = port_array[port_num] + PORTHLPMC;
- field = le32_to_cpu(udev->bos->ext_cap->bmAttributes);

xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
enable ? "enable" : "disable", port_num + 1);
@@ -4190,6 +4189,7 @@ int xhci_set_usb2_hardware_lpm(struct us
* default one which works with mixed HIRD and BESL
* systems. See XHCI_DEFAULT_BESL definition in xhci.h
*/
+ field = le32_to_cpu(udev->bos->ext_cap->bmAttributes);
if ((field & USB_BESL_SUPPORT) &&
(field & USB_BESL_BASELINE_VALID))
hird = USB_GET_BESL_BASELINE(field);

2019-10-02 19:16:02

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 15/87] powerpc/perf: Fix MMCRA corruption by bhrb_filter

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Ravi Bangoria <[email protected]>

commit 3202e35ec1c8fc19cea24253ff83edf702a60a02 upstream.

Consider a scenario where user creates two events:

1st event:
attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
attr.branch_sample_type = PERF_SAMPLE_BRANCH_ANY;
fd = perf_event_open(attr, 0, 1, -1, 0);

This sets cpuhw->bhrb_filter to 0 and returns valid fd.

2nd event:
attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
attr.branch_sample_type = PERF_SAMPLE_BRANCH_CALL;
fd = perf_event_open(attr, 0, 1, -1, 0);

It overrides cpuhw->bhrb_filter to -1 and returns with error.

Now if power_pmu_enable() gets called by any path other than
power_pmu_add(), ppmu->config_bhrb(-1) will set MMCRA to -1.

Fixes: 3925f46bb590 ("powerpc/perf: Enable branch stack sampling framework")
Signed-off-by: Ravi Bangoria <[email protected]>
Reviewed-by: Madhavan Srinivasan <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
[bwh: Backported to 3.16: drop changes in power9-pmu.c]
Signed-off-by: Ben Hutchings <[email protected]>
---
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1726,6 +1726,7 @@ static int power_pmu_event_init(struct p
int n;
int err;
struct cpu_hw_events *cpuhw;
+ u64 bhrb_filter;

if (!ppmu)
return -ENOENT;
@@ -1822,13 +1823,14 @@ static int power_pmu_event_init(struct p
err = power_check_constraints(cpuhw, events, cflags, n + 1);

if (has_branch_stack(event)) {
- cpuhw->bhrb_filter = ppmu->bhrb_filter_map(
+ bhrb_filter = ppmu->bhrb_filter_map(
event->attr.branch_sample_type);

- if (cpuhw->bhrb_filter == -1) {
+ if (bhrb_filter == -1) {
put_cpu_var(cpu_hw_events);
return -EOPNOTSUPP;
}
+ cpuhw->bhrb_filter = bhrb_filter;
}

put_cpu_var(cpu_hw_events);
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -175,6 +175,7 @@
#define POWER8_MMCRA_IFM1 0x0000000040000000UL
#define POWER8_MMCRA_IFM2 0x0000000080000000UL
#define POWER8_MMCRA_IFM3 0x00000000C0000000UL
+#define POWER8_MMCRA_BHRB_MASK 0x00000000C0000000UL

#define ONLY_PLM \
(PERF_SAMPLE_BRANCH_USER |\
@@ -666,6 +667,8 @@ static u64 power8_bhrb_filter_map(u64 br

static void power8_config_bhrb(u64 pmu_bhrb_filter)
{
+ pmu_bhrb_filter &= POWER8_MMCRA_BHRB_MASK;
+
/* Enable BHRB filter in PMU */
mtspr(SPRN_MMCRA, (mfspr(SPRN_MMCRA) | pmu_bhrb_filter));
}

2019-10-02 19:16:13

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 39/87] signal/ptrace: Don't leak unitialized kernel memory with PTRACE_PEEK_SIGINFO

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: "Eric W. Biederman" <[email protected]>

commit f6e2aa91a46d2bc79fce9b93a988dbe7655c90c0 upstream.

Recently syzbot in conjunction with KMSAN reported that
ptrace_peek_siginfo can copy an uninitialized siginfo to userspace.
Inspecting ptrace_peek_siginfo confirms this.

The problem is that off when initialized from args.off can be
initialized to a negaive value. At which point the "if (off >= 0)"
test to see if off became negative fails because off started off
negative.

Prevent the core problem by adding a variable found that is only true
if a siginfo is found and copied to a temporary in preparation for
being copied to userspace.

Prevent args.off from being truncated when being assigned to off by
testing that off is <= the maximum possible value of off. Convert off
to an unsigned long so that we should not have to truncate args.off,
we have well defined overflow behavior so if we add another check we
won't risk fighting undefined compiler behavior, and so that we have a
type whose maximum value is easy to test for.

Cc: Andrei Vagin <[email protected]>
Reported-by: [email protected]
Fixes: 84c751bd4aeb ("ptrace: add ability to retrieve signals without removing from a queue (v4)")
Signed-off-by: "Eric W. Biederman" <[email protected]>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
kernel/ptrace.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -711,6 +711,10 @@ static int ptrace_peek_siginfo(struct ta
if (arg.nr < 0)
return -EINVAL;

+ /* Ensure arg.off fits in an unsigned long */
+ if (arg.off > ULONG_MAX)
+ return 0;
+
if (arg.flags & PTRACE_PEEKSIGINFO_SHARED)
pending = &child->signal->shared_pending;
else
@@ -718,18 +722,20 @@ static int ptrace_peek_siginfo(struct ta

for (i = 0; i < arg.nr; ) {
siginfo_t info;
- s32 off = arg.off + i;
+ unsigned long off = arg.off + i;
+ bool found = false;

spin_lock_irq(&child->sighand->siglock);
list_for_each_entry(q, &pending->list, list) {
if (!off--) {
+ found = true;
copy_siginfo(&info, &q->info);
break;
}
}
spin_unlock_irq(&child->sighand->siglock);

- if (off >= 0) /* beyond the end of the list */
+ if (!found) /* beyond the end of the list */
break;

#ifdef CONFIG_COMPAT

2019-10-02 19:16:18

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 13/87] tty: max310x: Fix external crystal register setup

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Joe Burmeister <[email protected]>

commit 5d24f455c182d5116dd5db8e1dc501115ecc9c2c upstream.

The datasheet states:

Bit 4: ClockEnSet the ClockEn bit high to enable an external clocking
(crystal or clock generator at XIN). Set the ClockEn bit to 0 to disable
clocking
Bit 1: CrystalEnSet the CrystalEn bit high to enable the crystal
oscillator. When using an external clock source at XIN, CrystalEn must
be set low.

The bit 4, MAX310X_CLKSRC_EXTCLK_BIT, should be set and was not.

This was required to make the MAX3107 with an external crystal on our
board able to send or receive data.

Signed-off-by: Joe Burmeister <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/tty/serial/max310x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -568,7 +568,7 @@ static int max310x_set_ref_clk(struct ma
}

/* Configure clock source */
- clksrc = xtal ? MAX310X_CLKSRC_CRYST_BIT : MAX310X_CLKSRC_EXTCLK_BIT;
+ clksrc = MAX310X_CLKSRC_EXTCLK_BIT | (xtal ? MAX310X_CLKSRC_CRYST_BIT : 0);

/* Configure PLL */
if (pllcfg) {

2019-10-02 19:16:35

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 21/87] ipv4/igmp: fix build error if !CONFIG_IP_MULTICAST

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <[email protected]>

commit 903869bd10e6719b9df6718e785be7ec725df59f upstream.

ip_sf_list_clear_all() needs to be defined even if !CONFIG_IP_MULTICAST

Fixes: 3580d04aa674 ("ipv4/igmp: fix another memory leak in igmpv3_del_delrec()")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/ipv4/igmp.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)

--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -192,6 +192,17 @@ static void ip_ma_put(struct ip_mc_list
pmc != NULL; \
pmc = rtnl_dereference(pmc->next_rcu))

+static void ip_sf_list_clear_all(struct ip_sf_list *psf)
+{
+ struct ip_sf_list *next;
+
+ while (psf) {
+ next = psf->sf_next;
+ kfree(psf);
+ psf = next;
+ }
+}
+
#ifdef CONFIG_IP_MULTICAST

/*
@@ -614,17 +625,6 @@ static void igmpv3_clear_zeros(struct ip
}
}

-static void ip_sf_list_clear_all(struct ip_sf_list *psf)
-{
- struct ip_sf_list *next;
-
- while (psf) {
- next = psf->sf_next;
- kfree(psf);
- psf = next;
- }
-}
-
static void kfree_pmc(struct ip_mc_list *pmc)
{
ip_sf_list_clear_all(pmc->sources);

2019-10-02 19:16:36

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 35/87] s390/crypto: fix possible sleep during spinlock aquired

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Harald Freudenberger <[email protected]>

commit 1c2c7029c008922d4d48902cc386250502e73d51 upstream.

This patch fixes a complain about possible sleep during
spinlock aquired
"BUG: sleeping function called from invalid context at
include/crypto/algapi.h:426"
for the ctr(aes) and ctr(des) s390 specific ciphers.

Instead of using a spinlock this patch introduces a mutex
which is save to be held in sleeping context. Please note
a deadlock is not possible as mutex_trylock() is used.

Signed-off-by: Harald Freudenberger <[email protected]>
Reported-by: Julian Wiedmann <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
[bwh: Backported to 3.16:
- Replace spin_unlock() on all exit paths
- Adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
---
--- a/arch/s390/crypto/aes_s390.c
+++ b/arch/s390/crypto/aes_s390.c
@@ -25,7 +25,7 @@
#include <linux/err.h>
#include <linux/module.h>
#include <linux/init.h>
-#include <linux/spinlock.h>
+#include <linux/mutex.h>
#include "crypt_s390.h"

#define AES_KEYLEN_128 1
@@ -33,7 +33,7 @@
#define AES_KEYLEN_256 4

static u8 *ctrblk;
-static DEFINE_SPINLOCK(ctrblk_lock);
+static DEFINE_MUTEX(ctrblk_lock);
static char keylen_flag;

struct s390_aes_ctx {
@@ -785,7 +785,7 @@ static int ctr_aes_crypt(struct blkciphe
if (!walk->nbytes)
return ret;

- if (spin_trylock(&ctrblk_lock))
+ if (mutex_trylock(&ctrblk_lock))
ctrptr = ctrblk;

memcpy(ctrptr, walk->iv, AES_BLOCK_SIZE);
@@ -801,7 +801,7 @@ static int ctr_aes_crypt(struct blkciphe
n, ctrptr);
if (ret < 0 || ret != n) {
if (ctrptr == ctrblk)
- spin_unlock(&ctrblk_lock);
+ mutex_unlock(&ctrblk_lock);
return -EIO;
}
if (n > AES_BLOCK_SIZE)
@@ -819,7 +819,7 @@ static int ctr_aes_crypt(struct blkciphe
memcpy(ctrbuf, ctrptr, AES_BLOCK_SIZE);
else
memcpy(walk->iv, ctrptr, AES_BLOCK_SIZE);
- spin_unlock(&ctrblk_lock);
+ mutex_unlock(&ctrblk_lock);
} else {
if (!nbytes)
memcpy(walk->iv, ctrptr, AES_BLOCK_SIZE);
--- a/arch/s390/crypto/des_s390.c
+++ b/arch/s390/crypto/des_s390.c
@@ -17,6 +17,7 @@
#include <linux/init.h>
#include <linux/module.h>
#include <linux/crypto.h>
+#include <linux/mutex.h>
#include <crypto/algapi.h>
#include <crypto/des.h>

@@ -25,7 +26,7 @@
#define DES3_KEY_SIZE (3 * DES_KEY_SIZE)

static u8 *ctrblk;
-static DEFINE_SPINLOCK(ctrblk_lock);
+static DEFINE_MUTEX(ctrblk_lock);

struct s390_des_ctx {
u8 iv[DES_BLOCK_SIZE];
@@ -394,7 +395,7 @@ static int ctr_desall_crypt(struct blkci
if (!walk->nbytes)
return ret;

- if (spin_trylock(&ctrblk_lock))
+ if (mutex_trylock(&ctrblk_lock))
ctrptr = ctrblk;

memcpy(ctrptr, walk->iv, DES_BLOCK_SIZE);
@@ -410,7 +411,7 @@ static int ctr_desall_crypt(struct blkci
n, ctrptr);
if (ret < 0 || ret != n) {
if (ctrptr == ctrblk)
- spin_unlock(&ctrblk_lock);
+ mutex_unlock(&ctrblk_lock);
return -EIO;
}
if (n > DES_BLOCK_SIZE)
@@ -428,7 +429,7 @@ static int ctr_desall_crypt(struct blkci
memcpy(ctrbuf, ctrptr, DES_BLOCK_SIZE);
else
memcpy(walk->iv, ctrptr, DES_BLOCK_SIZE);
- spin_unlock(&ctrblk_lock);
+ mutex_unlock(&ctrblk_lock);
} else {
if (!nbytes)
memcpy(walk->iv, ctrptr, DES_BLOCK_SIZE);

2019-10-02 19:16:38

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 05/87] scsi: bnx2fc: fix incorrect cast to u64 on shift operation

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Colin Ian King <[email protected]>

commit d0c0d902339249c75da85fd9257a86cbb98dfaa5 upstream.

Currently an int is being shifted and the result is being cast to a u64
which leads to undefined behaviour if the shift is more than 31 bits. Fix
this by casting the integer value 1 to u64 before the shift operation.

Addresses-Coverity: ("Bad shift operation")
Fixes: 7b594769120b ("[SCSI] bnx2fc: Handle REC_TOV error code from firmware")
Signed-off-by: Colin Ian King <[email protected]>
Acked-by: Saurav Kashyap <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/scsi/bnx2fc/bnx2fc_hwi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/bnx2fc/bnx2fc_hwi.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_hwi.c
@@ -828,7 +828,7 @@ ret_err_rqe:
((u64)err_entry->data.err_warn_bitmap_hi << 32) |
(u64)err_entry->data.err_warn_bitmap_lo;
for (i = 0; i < BNX2FC_NUM_ERR_BITS; i++) {
- if (err_warn_bit_map & (u64) (1 << i)) {
+ if (err_warn_bit_map & ((u64)1 << i)) {
err_warn = i;
break;
}

2019-10-02 19:16:53

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 10/87] drm/gma500/cdv: Check vbt config bits when detecting lvds panels

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Patrik Jakobsson <[email protected]>

commit 7c420636860a719049fae9403e2c87804f53bdde upstream.

Some machines have an lvds child device in vbt even though a panel is
not attached. To make detection more reliable we now also check the lvds
config bits available in the vbt.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Patrik Jakobsson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +++
drivers/gpu/drm/gma500/intel_bios.c | 3 +++
drivers/gpu/drm/gma500/psb_drv.h | 1 +
3 files changed, 7 insertions(+)

--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -620,6 +620,9 @@ void cdv_intel_lvds_init(struct drm_devi
int pipe;
u8 pin;

+ if (!dev_priv->lvds_enabled_in_vbt)
+ return;
+
pin = GMBUS_PORT_PANEL;
if (!lvds_is_present_in_vbt(dev, &pin)) {
DRM_DEBUG_KMS("LVDS is not present in VBT\n");
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -436,6 +436,9 @@ parse_driver_features(struct drm_psb_pri
if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
dev_priv->edp.support = 1;

+ dev_priv->lvds_enabled_in_vbt = driver->lvds_config != 0;
+ DRM_DEBUG_KMS("LVDS VBT config bits: 0x%x\n", driver->lvds_config);
+
/* This bit means to use 96Mhz for DPLL_A or not */
if (driver->primary_lfp_id)
dev_priv->dplla_96mhz = true;
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -533,6 +533,7 @@ struct drm_psb_private {
int lvds_ssc_freq;
bool is_lvds_on;
bool is_mipi_on;
+ bool lvds_enabled_in_vbt;
u32 mipi_ctrl_display;

unsigned int core_freq;

2019-10-02 19:17:03

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 30/87] staging:iio:ad7150: fix threshold mode config bit

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Melissa Wen <[email protected]>

commit df4d737ee4d7205aaa6275158aeebff87fd14488 upstream.

According to the AD7150 configuration register description, bit 7 assumes
value 1 when the threshold mode is fixed and 0 when it is adaptive,
however, the operation that identifies this mode was considering the
opposite values.

This patch renames the boolean variable to describe it correctly and
properly replaces it in the places where it is used.

Fixes: 531efd6aa0991 ("staging:iio:adc:ad7150: chan_spec conv + i2c_smbus commands + drop unused poweroff timeout control.")
Signed-off-by: Melissa Wen <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/staging/iio/cdc/ad7150.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)

--- a/drivers/staging/iio/cdc/ad7150.c
+++ b/drivers/staging/iio/cdc/ad7150.c
@@ -6,6 +6,7 @@
* Licensed under the GPL-2 or later.
*/

+#include <linux/bitfield.h>
#include <linux/interrupt.h>
#include <linux/device.h>
#include <linux/kernel.h>
@@ -129,7 +130,7 @@ static int ad7150_read_event_config(stru
{
int ret;
u8 threshtype;
- bool adaptive;
+ bool thrfixed;
struct ad7150_chip_info *chip = iio_priv(indio_dev);

ret = i2c_smbus_read_byte_data(chip->client, AD7150_CFG);
@@ -137,21 +138,23 @@ static int ad7150_read_event_config(stru
return ret;

threshtype = (ret >> 5) & 0x03;
- adaptive = !!(ret & 0x80);
+
+ /*check if threshold mode is fixed or adaptive*/
+ thrfixed = FIELD_GET(AD7150_CFG_FIX, ret);

switch (type) {
case IIO_EV_TYPE_MAG_ADAPTIVE:
if (dir == IIO_EV_DIR_RISING)
- return adaptive && (threshtype == 0x1);
- return adaptive && (threshtype == 0x0);
+ return !thrfixed && (threshtype == 0x1);
+ return !thrfixed && (threshtype == 0x0);
case IIO_EV_TYPE_THRESH_ADAPTIVE:
if (dir == IIO_EV_DIR_RISING)
- return adaptive && (threshtype == 0x3);
- return adaptive && (threshtype == 0x2);
+ return !thrfixed && (threshtype == 0x3);
+ return !thrfixed && (threshtype == 0x2);
case IIO_EV_TYPE_THRESH:
if (dir == IIO_EV_DIR_RISING)
- return !adaptive && (threshtype == 0x1);
- return !adaptive && (threshtype == 0x0);
+ return thrfixed && (threshtype == 0x1);
+ return thrfixed && (threshtype == 0x0);
default:
break;
}

2019-10-02 19:18:01

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 20/87] ipv4/igmp: fix another memory leak in igmpv3_del_delrec()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <[email protected]>

commit 3580d04aa674383c42de7b635d28e52a1e5bc72c upstream.

syzbot reported memory leaks [1] that I have back tracked to
a missing cleanup from igmpv3_del_delrec() when
(im->sfmode != MCAST_INCLUDE)

Add ip_sf_list_clear_all() and kfree_pmc() helpers to explicitely
handle the cleanups before freeing.

[1]

BUG: memory leak
unreferenced object 0xffff888123e32b00 (size 64):
comm "softirq", pid 0, jiffies 4294942968 (age 8.010s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 e0 00 00 01 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000006105011b>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
[<000000006105011b>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<000000006105011b>] slab_alloc mm/slab.c:3326 [inline]
[<000000006105011b>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<000000004bba8073>] kmalloc include/linux/slab.h:547 [inline]
[<000000004bba8073>] kzalloc include/linux/slab.h:742 [inline]
[<000000004bba8073>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline]
[<000000004bba8073>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085
[<00000000a46a65a0>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475
[<000000005956ca89>] do_ip_setsockopt.isra.0+0x1795/0x1930 net/ipv4/ip_sockglue.c:957
[<00000000848e2d2f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246
[<00000000b9db185c>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
[<000000003028e438>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3130
[<0000000015b65589>] __sys_setsockopt+0x98/0x120 net/socket.c:2078
[<00000000ac198ef0>] __do_sys_setsockopt net/socket.c:2089 [inline]
[<00000000ac198ef0>] __se_sys_setsockopt net/socket.c:2086 [inline]
[<00000000ac198ef0>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
[<000000000a770437>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
[<00000000d3adb93b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: 9c8bb163ae78 ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Hangbin Liu <[email protected]>
Reported-by: syzbot <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/ipv4/igmp.c | 47 ++++++++++++++++++++++++++++++-----------------
1 file changed, 30 insertions(+), 17 deletions(-)

--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -614,6 +614,24 @@ static void igmpv3_clear_zeros(struct ip
}
}

+static void ip_sf_list_clear_all(struct ip_sf_list *psf)
+{
+ struct ip_sf_list *next;
+
+ while (psf) {
+ next = psf->sf_next;
+ kfree(psf);
+ psf = next;
+ }
+}
+
+static void kfree_pmc(struct ip_mc_list *pmc)
+{
+ ip_sf_list_clear_all(pmc->sources);
+ ip_sf_list_clear_all(pmc->tomb);
+ kfree(pmc);
+}
+
static void igmpv3_send_cr(struct in_device *in_dev)
{
struct ip_mc_list *pmc, *pmc_prev, *pmc_next;
@@ -650,7 +668,7 @@ static void igmpv3_send_cr(struct in_dev
else
in_dev->mc_tomb = pmc_next;
in_dev_put(pmc->interface);
- kfree(pmc);
+ kfree_pmc(pmc);
} else
pmc_prev = pmc;
}
@@ -1161,12 +1179,16 @@ static void igmpv3_del_delrec(struct in_
im->crcount = in_dev->mr_qrv ?: IGMP_Unsolicited_Report_Count;
if (im->sfmode == MCAST_INCLUDE) {
im->tomb = pmc->tomb;
+ pmc->tomb = NULL;
+
im->sources = pmc->sources;
+ pmc->sources = NULL;
+
for (psf = im->sources; psf; psf = psf->sf_next)
psf->sf_crcount = im->crcount;
}
in_dev_put(pmc->interface);
- kfree(pmc);
+ kfree_pmc(pmc);
}
spin_unlock_bh(&im->lock);
}
@@ -1187,21 +1209,18 @@ static void igmpv3_clear_delrec(struct i
nextpmc = pmc->next;
ip_mc_clear_src(pmc);
in_dev_put(pmc->interface);
- kfree(pmc);
+ kfree_pmc(pmc);
}
/* clear dead sources, too */
rcu_read_lock();
for_each_pmc_rcu(in_dev, pmc) {
- struct ip_sf_list *psf, *psf_next;
+ struct ip_sf_list *psf;

spin_lock_bh(&pmc->lock);
psf = pmc->tomb;
pmc->tomb = NULL;
spin_unlock_bh(&pmc->lock);
- for (; psf; psf = psf_next) {
- psf_next = psf->sf_next;
- kfree(psf);
- }
+ ip_sf_list_clear_all(psf);
}
rcu_read_unlock();
}
@@ -1881,7 +1900,7 @@ static int ip_mc_add_src(struct in_devic

static void ip_mc_clear_src(struct ip_mc_list *pmc)
{
- struct ip_sf_list *psf, *nextpsf, *tomb, *sources;
+ struct ip_sf_list *tomb, *sources;

spin_lock_bh(&pmc->lock);
tomb = pmc->tomb;
@@ -1893,14 +1912,8 @@ static void ip_mc_clear_src(struct ip_mc
pmc->sfcount[MCAST_EXCLUDE] = 1;
spin_unlock_bh(&pmc->lock);

- for (psf = tomb; psf; psf = nextpsf) {
- nextpsf = psf->sf_next;
- kfree(psf);
- }
- for (psf = sources; psf; psf = nextpsf) {
- nextpsf = psf->sf_next;
- kfree(psf);
- }
+ ip_sf_list_clear_all(tomb);
+ ip_sf_list_clear_all(sources);
}



2019-10-02 19:18:05

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 19/87] igmp: add a missing spin_lock_init()

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: WANG Cong <[email protected]>

commit b4846fc3c8559649277e3e4e6b5cec5348a8d208 upstream.

Andrey reported a lockdep warning on non-initialized
spinlock:

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 4099 Comm: a.out Not tainted 4.12.0-rc6+ #9
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x292/0x395 lib/dump_stack.c:52
register_lock_class+0x717/0x1aa0 kernel/locking/lockdep.c:755
? 0xffffffffa0000000
__lock_acquire+0x269/0x3690 kernel/locking/lockdep.c:3255
lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
__raw_spin_lock_bh ./include/linux/spinlock_api_smp.h:135
_raw_spin_lock_bh+0x36/0x50 kernel/locking/spinlock.c:175
spin_lock_bh ./include/linux/spinlock.h:304
ip_mc_clear_src+0x27/0x1e0 net/ipv4/igmp.c:2076
igmpv3_clear_delrec+0xee/0x4f0 net/ipv4/igmp.c:1194
ip_mc_destroy_dev+0x4e/0x190 net/ipv4/igmp.c:1736

We miss a spin_lock_init() in igmpv3_add_delrec(), probably
because previously we never use it on this code path. Since
we already unlink it from the global mc_tomb list, it is
probably safe not to acquire this spinlock here. It does not
harm to have it although, to avoid conditional locking.

Fixes: c38b7d327aaf ("igmp: acquire pmc lock for ip_mc_clear_src()")
Reported-by: Andrey Konovalov <[email protected]>
Signed-off-by: Cong Wang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
net/ipv4/igmp.c | 1 +
1 file changed, 1 insertion(+)

--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1106,6 +1106,7 @@ static void igmpv3_add_delrec(struct in_
pmc = kzalloc(sizeof(*pmc), GFP_KERNEL);
if (!pmc)
return;
+ spin_lock_init(&pmc->lock);
spin_lock_bh(&im->lock);
pmc->interface = im->interface;
in_dev_hold(in_dev);

2019-10-02 19:18:29

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 01/87] net/mlx4_core: Change the error print to info print

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Yunjian Wang <[email protected]>

commit 00f9fec48157f3734e52130a119846e67a12314b upstream.

The error print within mlx4_flow_steer_promisc_add() should
be a info print.

Fixes: 592e49dda812 ('net/mlx4: Implement promiscuous mode with device managed flow-steering')
Signed-off-by: Yunjian Wang <[email protected]>
Reviewed-by: Tariq Toukan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/net/ethernet/mellanox/mlx4/mcg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/mellanox/mlx4/mcg.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mcg.c
@@ -1329,7 +1329,7 @@ int mlx4_flow_steer_promisc_add(struct m
rule.port = port;
rule.qpn = qpn;
INIT_LIST_HEAD(&rule.list);
- mlx4_err(dev, "going promisc on %x\n", port);
+ mlx4_info(dev, "going promisc on %x\n", port);

return mlx4_flow_attach(dev, &rule, regid_p);
}

2019-10-02 19:18:31

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 07/87] USB: Add LPM quirk for Surface Dock GigE adapter

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Maximilian Luz <[email protected]>

commit ea261113385ac0a71c2838185f39e8452d54b152 upstream.

Without USB_QUIRK_NO_LPM ethernet will not work and rtl8152 will
complain with

r8152 <device...>: Stop submitting intr, status -71

Adding the quirk resolves this. As the dock is externally powered, this
should not have any drawbacks.

Signed-off-by: Maximilian Luz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -64,6 +64,9 @@ static const struct usb_device_id usb_qu
/* Microsoft LifeCam-VX700 v2.0 */
{ USB_DEVICE(0x045e, 0x0770), .driver_info = USB_QUIRK_RESET_RESUME },

+ /* Microsoft Surface Dock Ethernet (RTL8153 GigE) */
+ { USB_DEVICE(0x045e, 0x07c6), .driver_info = USB_QUIRK_NO_LPM },
+
/* Cherry Stream G230 2.0 (G85-231) and 3.0 (G85-232) */
{ USB_DEVICE(0x046a, 0x0023), .driver_info = USB_QUIRK_RESET_RESUME },


2019-10-02 19:19:02

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 3.16 03/87] Btrfs: fix race between ranged fsync and writeback of adjacent ranges

3.16.75-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Filipe Manana <[email protected]>

commit 0c713cbab6200b0ab6473b50435e450a6e1de85d upstream.

When we do a full fsync (the bit BTRFS_INODE_NEEDS_FULL_SYNC is set in the
inode) that happens to be ranged, which happens during a msync() or writes
for files opened with O_SYNC for example, we can end up with a corrupt log,
due to different file extent items representing ranges that overlap with
each other, or hit some assertion failures.

When doing a ranged fsync we only flush delalloc and wait for ordered
exents within that range. If while we are logging items from our inode
ordered extents for adjacent ranges complete, we end up in a race that can
make us insert the file extent items that overlap with others we logged
previously and the assertion failures.

For example, if tree-log.c:copy_items() receives a leaf that has the
following file extents items, all with a length of 4K and therefore there
is an implicit hole in the range 68K to 72K - 1:

(257 EXTENT_ITEM 64K), (257 EXTENT_ITEM 72K), (257 EXTENT_ITEM 76K), ...

It copies them to the log tree. However due to the need to detect implicit
holes, it may release the path, in order to look at the previous leaf to
detect an implicit hole, and then later it will search again in the tree
for the first file extent item key, with the goal of locking again the
leaf (which might have changed due to concurrent changes to other inodes).

However when it locks again the leaf containing the first key, the key
corresponding to the extent at offset 72K may not be there anymore since
there is an ordered extent for that range that is finishing (that is,
somewhere in the middle of btrfs_finish_ordered_io()), and it just
removed the file extent item but has not yet replaced it with a new file
extent item, so the part of copy_items() that does hole detection will
decide that there is a hole in the range starting from 68K to 76K - 1,
and therefore insert a file extent item to represent that hole, having
a key offset of 68K. After that we now have a log tree with 2 different
extent items that have overlapping ranges:

1) The file extent item copied before copy_items() released the path,
which has a key offset of 72K and a length of 4K, representing the
file range 72K to 76K - 1.

2) And a file extent item representing a hole that has a key offset of
68K and a length of 8K, representing the range 68K to 76K - 1. This
item was inserted after releasing the path, and overlaps with the
extent item inserted before.

The overlapping extent items can cause all sorts of unpredictable and
incorrect behaviour, either when replayed or if a fast (non full) fsync
happens later, which can trigger a BUG_ON() when calling
btrfs_set_item_key_safe() through __btrfs_drop_extents(), producing a
trace like the following:

[61666.783269] ------------[ cut here ]------------
[61666.783943] kernel BUG at fs/btrfs/ctree.c:3182!
[61666.784644] invalid opcode: 0000 [#1] PREEMPT SMP
(...)
[61666.786253] task: ffff880117b88c40 task.stack: ffffc90008168000
[61666.786253] RIP: 0010:btrfs_set_item_key_safe+0x7c/0xd2 [btrfs]
[61666.786253] RSP: 0018:ffffc9000816b958 EFLAGS: 00010246
[61666.786253] RAX: 0000000000000000 RBX: 000000000000000f RCX: 0000000000030000
[61666.786253] RDX: 0000000000000000 RSI: ffffc9000816ba4f RDI: ffffc9000816b937
[61666.786253] RBP: ffffc9000816b998 R08: ffff88011dae2428 R09: 0000000000001000
[61666.786253] R10: 0000160000000000 R11: 6db6db6db6db6db7 R12: ffff88011dae2418
[61666.786253] R13: ffffc9000816ba4f R14: ffff8801e10c4118 R15: ffff8801e715c000
[61666.786253] FS: 00007f6060a18700(0000) GS:ffff88023f5c0000(0000) knlGS:0000000000000000
[61666.786253] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[61666.786253] CR2: 00007f6060a28000 CR3: 0000000213e69000 CR4: 00000000000006e0
[61666.786253] Call Trace:
[61666.786253] __btrfs_drop_extents+0x5e3/0xaad [btrfs]
[61666.786253] ? time_hardirqs_on+0x9/0x14
[61666.786253] btrfs_log_changed_extents+0x294/0x4e0 [btrfs]
[61666.786253] ? release_extent_buffer+0x38/0xb4 [btrfs]
[61666.786253] btrfs_log_inode+0xb6e/0xcdc [btrfs]
[61666.786253] ? lock_acquire+0x131/0x1c5
[61666.786253] ? btrfs_log_inode_parent+0xee/0x659 [btrfs]
[61666.786253] ? arch_local_irq_save+0x9/0xc
[61666.786253] ? btrfs_log_inode_parent+0x1f5/0x659 [btrfs]
[61666.786253] btrfs_log_inode_parent+0x223/0x659 [btrfs]
[61666.786253] ? arch_local_irq_save+0x9/0xc
[61666.786253] ? lockref_get_not_zero+0x2c/0x34
[61666.786253] ? rcu_read_unlock+0x3e/0x5d
[61666.786253] btrfs_log_dentry_safe+0x60/0x7b [btrfs]
[61666.786253] btrfs_sync_file+0x317/0x42c [btrfs]
[61666.786253] vfs_fsync_range+0x8c/0x9e
[61666.786253] SyS_msync+0x13c/0x1c9
[61666.786253] entry_SYSCALL_64_fastpath+0x18/0xad

A sample of a corrupt log tree leaf with overlapping extents I got from
running btrfs/072:

item 14 key (295 108 200704) itemoff 2599 itemsize 53
extent data disk bytenr 0 nr 0
extent data offset 0 nr 458752 ram 458752
item 15 key (295 108 659456) itemoff 2546 itemsize 53
extent data disk bytenr 4343541760 nr 770048
extent data offset 606208 nr 163840 ram 770048
item 16 key (295 108 663552) itemoff 2493 itemsize 53
extent data disk bytenr 4343541760 nr 770048
extent data offset 610304 nr 155648 ram 770048
item 17 key (295 108 819200) itemoff 2440 itemsize 53
extent data disk bytenr 4334788608 nr 4096
extent data offset 0 nr 4096 ram 4096

The file extent item at offset 659456 (item 15) ends at offset 823296
(659456 + 163840) while the next file extent item (item 16) starts at
offset 663552.

Another different problem that the race can trigger is a failure in the
assertions at tree-log.c:copy_items(), which expect that the first file
extent item key we found before releasing the path exists after we have
released path and that the last key we found before releasing the path
also exists after releasing the path:

$ cat -n fs/btrfs/tree-log.c
4080 if (need_find_last_extent) {
4081 /* btrfs_prev_leaf could return 1 without releasing the path */
4082 btrfs_release_path(src_path);
4083 ret = btrfs_search_slot(NULL, inode->root, &first_key,
4084 src_path, 0, 0);
4085 if (ret < 0)
4086 return ret;
4087 ASSERT(ret == 0);
(...)
4103 if (i >= btrfs_header_nritems(src_path->nodes[0])) {
4104 ret = btrfs_next_leaf(inode->root, src_path);
4105 if (ret < 0)
4106 return ret;
4107 ASSERT(ret == 0);
4108 src = src_path->nodes[0];
4109 i = 0;
4110 need_find_last_extent = true;
4111 }
(...)

The second assertion implicitly expects that the last key before the path
release still exists, because the surrounding while loop only stops after
we have found that key. When this assertion fails it produces a stack like
this:

[139590.037075] assertion failed: ret == 0, file: fs/btrfs/tree-log.c, line: 4107
[139590.037406] ------------[ cut here ]------------
[139590.037707] kernel BUG at fs/btrfs/ctree.h:3546!
[139590.038034] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
[139590.038340] CPU: 1 PID: 31841 Comm: fsstress Tainted: G W 5.0.0-btrfs-next-46 #1
(...)
[139590.039354] RIP: 0010:assfail.constprop.24+0x18/0x1a [btrfs]
(...)
[139590.040397] RSP: 0018:ffffa27f48f2b9b0 EFLAGS: 00010282
[139590.040730] RAX: 0000000000000041 RBX: ffff897c635d92c8 RCX: 0000000000000000
[139590.041105] RDX: 0000000000000000 RSI: ffff897d36a96868 RDI: ffff897d36a96868
[139590.041470] RBP: ffff897d1b9a0708 R08: 0000000000000000 R09: 0000000000000000
[139590.041815] R10: 0000000000000008 R11: 0000000000000000 R12: 0000000000000013
[139590.042159] R13: 0000000000000227 R14: ffff897cffcbba88 R15: 0000000000000001
[139590.042501] FS: 00007f2efc8dee80(0000) GS:ffff897d36a80000(0000) knlGS:0000000000000000
[139590.042847] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[139590.043199] CR2: 00007f8c064935e0 CR3: 0000000232252002 CR4: 00000000003606e0
[139590.043547] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[139590.043899] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[139590.044250] Call Trace:
[139590.044631] copy_items+0xa3f/0x1000 [btrfs]
[139590.045009] ? generic_bin_search.constprop.32+0x61/0x200 [btrfs]
[139590.045396] btrfs_log_inode+0x7b3/0xd70 [btrfs]
[139590.045773] btrfs_log_inode_parent+0x2b3/0xce0 [btrfs]
[139590.046143] ? do_raw_spin_unlock+0x49/0xc0
[139590.046510] btrfs_log_dentry_safe+0x4a/0x70 [btrfs]
[139590.046872] btrfs_sync_file+0x3b6/0x440 [btrfs]
[139590.047243] btrfs_file_write_iter+0x45b/0x5c0 [btrfs]
[139590.047592] __vfs_write+0x129/0x1c0
[139590.047932] vfs_write+0xc2/0x1b0
[139590.048270] ksys_write+0x55/0xc0
[139590.048608] do_syscall_64+0x60/0x1b0
[139590.048946] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[139590.049287] RIP: 0033:0x7f2efc4be190
(...)
[139590.050342] RSP: 002b:00007ffe743243a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[139590.050701] RAX: ffffffffffffffda RBX: 0000000000008d58 RCX: 00007f2efc4be190
[139590.051067] RDX: 0000000000008d58 RSI: 00005567eca0f370 RDI: 0000000000000003
[139590.051459] RBP: 0000000000000024 R08: 0000000000000003 R09: 0000000000008d60
[139590.051863] R10: 0000000000000078 R11: 0000000000000246 R12: 0000000000000003
[139590.052252] R13: 00000000003d3507 R14: 00005567eca0f370 R15: 0000000000000000
(...)
[139590.055128] ---[ end trace 193f35d0215cdeeb ]---

So fix this race between a full ranged fsync and writeback of adjacent
ranges by flushing all delalloc and waiting for all ordered extents to
complete before logging the inode. This is the simplest way to solve the
problem because currently the full fsync path does not deal with ranges
at all (it assumes a full range from 0 to LLONG_MAX) and it always needs
to look at adjacent ranges for hole detection. For use cases of ranged
fsyncs this can make a few fsyncs slower but on the other hand it can
make some following fsyncs to other ranges do less work or no need to do
anything at all. A full fsync is rare anyway and happens only once after
loading/creating an inode and once after less common operations such as a
shrinking truncate.

This is an issue that exists for a long time, and was often triggered by
generic/127, because it does mmap'ed writes and msync (which triggers a
ranged fsync). Adding support for the tree checker to detect overlapping
extents (next patch in the series) and trigger a WARN() when such cases
are found, and then calling btrfs_check_leaf_full() at the end of
btrfs_insert_file_extent() made the issue much easier to detect. Running
btrfs/072 with that change to the tree checker and making fsstress open
files always with O_SYNC made it much easier to trigger the issue (as
triggering it with generic/127 is very rare).

Reviewed-by: Josef Bacik <[email protected]>
Signed-off-by: Filipe Manana <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
---
fs/btrfs/file.c | 12 ++++++++++++
1 file changed, 12 insertions(+)

--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1889,6 +1889,18 @@ int btrfs_sync_file(struct file *file, l
u64 len;

/*
+ * If the inode needs a full sync, make sure we use a full range to
+ * avoid log tree corruption, due to hole detection racing with ordered
+ * extent completion for adjacent ranges, and assertion failures during
+ * hole detection.
+ */
+ if (test_bit(BTRFS_INODE_NEEDS_FULL_SYNC,
+ &BTRFS_I(inode)->runtime_flags)) {
+ start = 0;
+ end = LLONG_MAX;
+ }
+
+ /*
* The range length can be represented by u64, we have to do the typecasts
* to avoid signed overflow if it's [0, LLONG_MAX] eg. from fsync()
*/

2019-10-02 21:58:44

by Joe Perches

[permalink] [raw]
Subject: Re: [PATCH 3.16 29/87] staging: iio: cdc: Don't put an else right after a return

On Wed, 2019-10-02 at 20:06 +0100, Ben Hutchings wrote:
> 3.16.75-rc1 review patch. If anyone has any objections, please let me know.

This doesn't look necessary.

> ------------------
>
> From: Catalina Mocanu <[email protected]>
>
> commit 288903f6b91e759b0a813219acd376426cbb8f14 upstream.
>
> This fixes the following checkpatch.pl warning:
> WARNING: else is not generally useful after a break or return.
>
> While at it, remove new line for symmetry with the rest of the code.
>
> Signed-off-by: Catalina Mocanu <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Ben Hutchings <[email protected]>
> ---
> drivers/staging/iio/cdc/ad7150.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> --- a/drivers/staging/iio/cdc/ad7150.c
> +++ b/drivers/staging/iio/cdc/ad7150.c
> @@ -143,19 +143,15 @@ static int ad7150_read_event_config(stru
> case IIO_EV_TYPE_MAG_ADAPTIVE:
> if (dir == IIO_EV_DIR_RISING)
> return adaptive && (threshtype == 0x1);
> - else
> - return adaptive && (threshtype == 0x0);
> + return adaptive && (threshtype == 0x0);
> case IIO_EV_TYPE_THRESH_ADAPTIVE:
> if (dir == IIO_EV_DIR_RISING)
> return adaptive && (threshtype == 0x3);
> - else
> - return adaptive && (threshtype == 0x2);
> -
> + return adaptive && (threshtype == 0x2);
> case IIO_EV_TYPE_THRESH:
> if (dir == IIO_EV_DIR_RISING)
> return !adaptive && (threshtype == 0x1);
> - else
> - return !adaptive && (threshtype == 0x0);
> + return !adaptive && (threshtype == 0x0);
> default:
> break;
> }
>

2019-10-03 14:27:47

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 3.16 00/87] 3.16.75-rc1 review

On 10/2/19 12:06 PM, Ben Hutchings wrote:
> This is the start of the stable review cycle for the 3.16.75 release.
> There are 87 patches in this series, which will be posted as responses
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Oct 04 19:06:50 UTC 2019.
> Anything received after that time might be too late.
>
For v3.16.74-87-g815992c3a9a0:

Build results:
total: 136 pass: 122 fail: 14
Failed builds:
alpha:allmodconfig
arm:allmodconfig
arm64:allmodconfig
i386:allyesconfig
i386:allmodconfig
m68k:allmodconfig
mips:allmodconfig
parisc:allmodconfig
powerpc:allmodconfig
s390:allmodconfig
sparc64:allmodconfig
x86_64:allyesconfig
x86_64:allmodconfig
xtensa:allmodconfig
Qemu test results:
total: 229 pass: 229 fail: 0

The error is:

drivers/staging/iio/cdc/ad7150.c:9:10: fatal error: linux/bitfield.h: No such file or directory

which indeed does not exist in v3.16.y. Culprit is commit 6117323f0fbfb
("staging:iio:ad7150: fix threshold mode config bit".

Guenter

2019-10-03 15:03:10

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 3.16 29/87] staging: iio: cdc: Don't put an else right after a return

On Wed, 2019-10-02 at 14:36 -0700, Joe Perches wrote:
> On Wed, 2019-10-02 at 20:06 +0100, Ben Hutchings wrote:
> > 3.16.75-rc1 review patch. If anyone has any objections, please let me know.
>
> This doesn't look necessary.

It allows the next patch to apply cleanly.

Ben.

> > ------------------
> >
> > From: Catalina Mocanu <[email protected]>
> >
> > commit 288903f6b91e759b0a813219acd376426cbb8f14 upstream.
> >
> > This fixes the following checkpatch.pl warning:
> > WARNING: else is not generally useful after a break or return.
> >
> > While at it, remove new line for symmetry with the rest of the code.
> >
> > Signed-off-by: Catalina Mocanu <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Ben Hutchings <[email protected]>
> > ---
> > drivers/staging/iio/cdc/ad7150.c | 10 +++-------
> > 1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > --- a/drivers/staging/iio/cdc/ad7150.c
> > +++ b/drivers/staging/iio/cdc/ad7150.c
> > @@ -143,19 +143,15 @@ static int ad7150_read_event_config(stru
> > case IIO_EV_TYPE_MAG_ADAPTIVE:
> > if (dir == IIO_EV_DIR_RISING)
> > return adaptive && (threshtype == 0x1);
> > - else
> > - return adaptive && (threshtype == 0x0);
> > + return adaptive && (threshtype == 0x0);
> > case IIO_EV_TYPE_THRESH_ADAPTIVE:
> > if (dir == IIO_EV_DIR_RISING)
> > return adaptive && (threshtype == 0x3);
> > - else
> > - return adaptive && (threshtype == 0x2);
> > -
> > + return adaptive && (threshtype == 0x2);
> > case IIO_EV_TYPE_THRESH:
> > if (dir == IIO_EV_DIR_RISING)
> > return !adaptive && (threshtype == 0x1);
> > - else
> > - return !adaptive && (threshtype == 0x0);
> > + return !adaptive && (threshtype == 0x0);
> > default:
> > break;
> > }
> >
--
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.



Attachments:
signature.asc (849.00 B)
This is a digitally signed message part

2019-10-03 15:12:37

by Joe Perches

[permalink] [raw]
Subject: Re: [PATCH 3.16 29/87] staging: iio: cdc: Don't put an else right after a return

On Thu, 2019-10-03 at 15:47 +0100, Ben Hutchings wrote:
> On Wed, 2019-10-02 at 14:36 -0700, Joe Perches wrote:
> > On Wed, 2019-10-02 at 20:06 +0100, Ben Hutchings wrote:
> > > 3.16.75-rc1 review patch. If anyone has any objections, please let me know.
> >
> > This doesn't look necessary.
>
> It allows the next patch to apply cleanly.

Perhaps when you pick patches that are unnecessary
for any other reason but to allow easier picking of
actual fixes, the nominal unnecessary patches could
be marked as necessary for follow-on patches.

Also, when you send these patch series, please use
an email delay of at least 1 second between each
entry in the series as the threading is otherwise
poor in various email clients when sorting by time.


2019-10-04 07:21:34

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 3.16 29/87] staging: iio: cdc: Don't put an else right after a return

On Thu, 2019-10-03 at 08:09 -0700, Joe Perches wrote:
> On Thu, 2019-10-03 at 15:47 +0100, Ben Hutchings wrote:
> > On Wed, 2019-10-02 at 14:36 -0700, Joe Perches wrote:
> > > On Wed, 2019-10-02 at 20:06 +0100, Ben Hutchings wrote:
> > > > 3.16.75-rc1 review patch. If anyone has any objections, please let me know.
> > >
> > > This doesn't look necessary.
> >
> > It allows the next patch to apply cleanly.
>
> Perhaps when you pick patches that are unnecessary
> for any other reason but to allow easier picking of
> actual fixes, the nominal unnecessary patches could
> be marked as necessary for follow-on patches.

I have been doing that lately, but just forgot to do so for this patch.

> Also, when you send these patch series, please use
> an email delay of at least 1 second between each
> entry in the series as the threading is otherwise
> poor in various email clients when sorting by time.

The dates are actually generated before I send them, but I can probably
arrange to override them. Thanks for the suggestion.

Ben.

--
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.



Attachments:
signature.asc (849.00 B)
This is a digitally signed message part

2019-10-04 07:24:50

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 3.16 00/87] 3.16.75-rc1 review

On Thu, 2019-10-03 at 05:54 -0700, Guenter Roeck wrote:
[...]
> The error is:
>
> drivers/staging/iio/cdc/ad7150.c:9:10: fatal error: linux/bitfield.h: No such file or directory
>
> which indeed does not exist in v3.16.y. Culprit is commit 6117323f0fbfb
> ("staging:iio:ad7150: fix threshold mode config bit".

Thanks for checking. I'll drop the two patches for this driver.

Ben.

-
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.



Attachments:
signature.asc (849.00 B)
This is a digitally signed message part

2019-10-04 23:09:44

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 3.16 00/87] 3.16.75-rc1 review

On Wed, Oct 02, 2019 at 08:06:50PM +0100, Ben Hutchings wrote:
> This is the start of the stable review cycle for the 3.16.75 release.
> There are 87 patches in this series, which will be posted as responses
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Oct 04 19:06:50 UTC 2019.
> Anything received after that time might be too late.
>
For v3.16.74-85-g811e39a80ea5:

Build results:
total: 136 pass: 136 fail: 0
Qemu test results:
total: 229 pass: 229 fail: 0

Guenter

2019-10-05 20:31:30

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 3.16 00/87] 3.16.75-rc1 review

On Fri, 2019-10-04 at 16:09 -0700, Guenter Roeck wrote:
> On Wed, Oct 02, 2019 at 08:06:50PM +0100, Ben Hutchings wrote:
> > This is the start of the stable review cycle for the 3.16.75 release.
> > There are 87 patches in this series, which will be posted as responses
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri Oct 04 19:06:50 UTC 2019.
> > Anything received after that time might be too late.
> >
> For v3.16.74-85-g811e39a80ea5:
>
> Build results:
> total: 136 pass: 136 fail: 0
> Qemu test results:
> total: 229 pass: 229 fail: 0

Great, thanks.

Ben.

--
Ben Hutchings
The most exhausting thing in life is being insincere.
- Anne Morrow Lindberg



Attachments:
signature.asc (849.00 B)
This is a digitally signed message part

2019-10-28 23:41:42

by Pavel Shilovskiy

[permalink] [raw]
Subject: RE: [PATCH 3.16 58/87] cifs: add spinlock for the openFileList to cifsInodeInfo

> -----Original Message-----
> From: Ben Hutchings <[email protected]>
> Sent: Wednesday, October 2, 2019 12:07 PM
> To: [email protected]; [email protected]
> Cc: [email protected]; Denis Kirjanov <[email protected]>; Ronnie Sahlberg <[email protected]>; Steven French <[email protected]>; Pavel Shilovskiy <[email protected]>
> Subject: [PATCH 3.16 58/87] cifs: add spinlock for the openFileList to cifsInodeInfo
>
> 3.16.75-rc1 review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Ronnie Sahlberg <[email protected]>
>
> commit 487317c99477d00f22370625d53be3239febabbe upstream.
>
> We can not depend on the tcon->open_file_lock here since in multiuser mode we may have the same file/inode open via multiple different tcons.
>
> The current code is race prone and will crash if one user deletes a file at the same time a different user opens/create the file.
>
> To avoid this we need to have a spinlock attached to the inode and not the tcon.
>
> RHBZ:  1580165
>
> Signed-off-by: Ronnie Sahlberg <[email protected]>
> Signed-off-by: Steve French <[email protected]>
> Reviewed-by: Pavel Shilovsky <[email protected]>
> [bwh: Backported to 3.16: adjust context, indentation]
> Signed-off-by: Ben Hutchings <[email protected]>
> ---
>  fs/cifs/cifsfs.c   | 1 +
>  fs/cifs/cifsglob.h | 5 +++++
>  fs/cifs/file.c     | 8 ++++++--
>  3 files changed, 12 insertions(+), 2 deletions(-)
>
> --- a/fs/cifs/cifsfs.c
> +++ b/fs/cifs/cifsfs.c
> @@ -260,6 +260,7 @@ cifs_alloc_inode(struct super_block *sb)
>         cifs_inode->uniqueid = 0;
>         cifs_inode->createtime = 0;
>         cifs_inode->epoch = 0;
> +       spin_lock_init(&cifs_inode->open_file_lock);
>  #ifdef CONFIG_CIFS_SMB2
>         generate_random_uuid(cifs_inode->lease_key);
>  #endif
> --- a/fs/cifs/cifsglob.h
> +++ b/fs/cifs/cifsglob.h
> @@ -1116,6 +1116,7 @@ struct cifsInodeInfo {
>         struct rw_semaphore lock_sem;   /* protect the fields above */
>         /* BB add in lists for dirty pages i.e. write caching info for oplock */
>         struct list_head openFileList;
> +       spinlock_t      open_file_lock; /* protects openFileList */
>         __u32 cifsAttrs; /* e.g. DOS archive bit, sparse, compressed, system */
>         unsigned int oplock;            /* oplock/lease level we have */
>         unsigned int epoch;             /* used to track lease state changes */
> @@ -1485,10 +1486,14 @@ require use of the stronger protocol */
>   *  tcp_ses_lock protects:
>   *     list operations on tcp and SMB session lists
>   *  tcon->open_file_lock protects the list of open files hanging off the tcon
> + *  inode->open_file_lock protects the openFileList hanging off the
> + inode
>   *  cfile->file_info_lock protects counters and fields in cifs file struct
>   *  f_owner.lock protects certain per file struct operations
>   *  mapping->page_lock protects certain per page operations
>   *
> + *  Note that the cifs_tcon.open_file_lock should be taken before
> + *  not after the cifsInodeInfo.open_file_lock
> + *
>   *  Semaphores
>   *  ----------
>   *  sesSem     operations on smb session
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -337,10 +337,12 @@ cifs_new_fileinfo(struct cifs_fid *fid,
>         list_add(&cfile->tlist, &tcon->openFileList);
>
>         /* if readable file instance put first in list*/
> +       spin_lock(&cinode->open_file_lock);
>         if (file->f_mode & FMODE_READ)
>                 list_add(&cfile->flist, &cinode->openFileList);
>         else
>                 list_add_tail(&cfile->flist, &cinode->openFileList);
> +       spin_unlock(&cinode->open_file_lock);
>         spin_unlock(&tcon->open_file_lock);
>
>         if (fid->purge_cache)
> @@ -412,7 +414,9 @@ void _cifsFileInfo_put(struct cifsFileIn
>         cifs_add_pending_open_locked(&fid, cifs_file->tlink, &open);
>
>         /* remove it from the lists */
> +       spin_lock(&cifsi->open_file_lock);
>         list_del(&cifs_file->flist);
> +       spin_unlock(&cifsi->open_file_lock);
>         list_del(&cifs_file->tlist);
>
>         if (list_empty(&cifsi->openFileList)) { @@ -1850,10 +1854,10 @@ refind_writable:
>                 if (!rc)
>                         return inv_file;
>                 else {
> -                       spin_lock(&tcon->open_file_lock);
> +                       spin_lock(&cifs_inode->open_file_lock);
>                         list_move_tail(&inv_file->flist,
>                                         &cifs_inode->openFileList);
> -                       spin_unlock(&tcon->open_file_lock);
> +                       spin_unlock(&cifs_inode->open_file_lock);
>                         cifsFileInfo_put(inv_file);
>                         ++refind;
>                         inv_file = NULL;
>

Hi Ben,

We have recently found regressions in this patch that are addressed in the following two patches:

cb248819d209d ("cifs: use cifsInodeInfo->open_file_lock while iterating to avoid a panic")
1a67c41596575 ("CIFS: Fix use after free of file info structures")

So, I would suggest either to apply those two patches above or to revert this one.

--
Best regards,
Pavel Shilovsky

2019-10-29 19:32:19

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 3.16 58/87] cifs: add spinlock for the openFileList to cifsInodeInfo

On Mon, 2019-10-28 at 22:19 +0000, Pavel Shilovskiy wrote:
> > -----Original Message-----
> > From: Ben Hutchings <[email protected]>
> > Sent: Wednesday, October 2, 2019 12:07 PM
> > To: [email protected]; [email protected]
> > Cc: [email protected]; Denis Kirjanov <[email protected]>; Ronnie Sahlberg <[email protected]>; Steven French <[email protected]>; Pavel Shilovskiy <[email protected]>
> > Subject: [PATCH 3.16 58/87] cifs: add spinlock for the openFileList to cifsInodeInfo
> >
> > 3.16.75-rc1 review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Ronnie Sahlberg <[email protected]>
> >
> > commit 487317c99477d00f22370625d53be3239febabbe upstream.
[...]
> We have recently found regressions in this patch that are addressed in the following two patches:
>
> cb248819d209d ("cifs: use cifsInodeInfo->open_file_lock while iterating to avoid a panic")
> 1a67c41596575 ("CIFS: Fix use after free of file info structures")
>
> So, I would suggest either to apply those two patches above or to revert this one.

Thanks for pointing thse out. I will try to include those in a later
update.

Ben.

--
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.



Attachments:
signature.asc (849.00 B)
This is a digitally signed message part

2019-11-19 14:51:27

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 3.16 58/87] cifs: add spinlock for the openFileList to cifsInodeInfo

On Tue, 2019-10-29 at 14:15 +0100, Ben Hutchings wrote:
> On Mon, 2019-10-28 at 22:19 +0000, Pavel Shilovskiy wrote:
> > > -----Original Message-----
> > > From: Ben Hutchings <[email protected]>
> > > Sent: Wednesday, October 2, 2019 12:07 PM
> > > To: [email protected]; [email protected]
> > > Cc: [email protected]; Denis Kirjanov <[email protected]>; Ronnie Sahlberg <[email protected]>; Steven French <[email protected]>; Pavel Shilovskiy <[email protected]>
> > > Subject: [PATCH 3.16 58/87] cifs: add spinlock for the openFileList to cifsInodeInfo
> > >
> > > 3.16.75-rc1 review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Ronnie Sahlberg <[email protected]>
> > >
> > > commit 487317c99477d00f22370625d53be3239febabbe upstream.
> [...]
> > We have recently found regressions in this patch that are addressed in the following two patches:
> >
> > cb248819d209d ("cifs: use cifsInodeInfo->open_file_lock while iterating to avoid a panic")
> > 1a67c41596575 ("CIFS: Fix use after free of file info structures")
> >
> > So, I would suggest either to apply those two patches above or to revert this one.
>
> Thanks for pointing thse out. I will try to include those in a later
> update.

I've now queued these up.

Ben.

--
Ben Hutchings
Theory and practice are closer in theory than in practice - John Levine



Attachments:
signature.asc (849.00 B)
This is a digitally signed message part