This is the start of the stable review cycle for the 4.19.62 release.
There are 50 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun 28 Jul 2019 03:21:13 PM UTC.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.62-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.19.62-rc1
Kuo-Hsin Yang <vovoy(a)chromium.org>
mm: vmscan: scan anonymous pages on file refaults
Jan Kiszka <jan.kiszka(a)siemens.com>
KVM: nVMX: Clear pending KVM_REQ_GET_VMCS12_PAGES when leaving nested
Paolo Bonzini <pbonzini(a)redhat.com>
KVM: nVMX: do not use dangling shadow VMCS after guest reset
Theodore Ts'o <tytso(a)mit.edu>
ext4: allow directory holes
Ross Zwisler <zwisler(a)chromium.org>
ext4: use jbd2_inode dirty range scoping
Ross Zwisler <zwisler(a)chromium.org>
jbd2: introduce jbd2_inode dirty range scoping
Ross Zwisler <zwisler(a)chromium.org>
mm: add filemap_fdatawait_range_keep_errors()
Theodore Ts'o <tytso(a)mit.edu>
ext4: enforce the immutable flag on open files
Darrick J. Wong <darrick.wong(a)oracle.com>
ext4: don't allow any modifications to an immutable file
Peter Zijlstra <peterz(a)infradead.org>
perf/core: Fix race between close() and fork()
Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
perf/core: Fix exclusive events' grouping
Paul Cercueil <paul(a)crapouillou.net>
MIPS: lb60: Fix pin mappings
Keerthy <j-keerthy(a)ti.com>
gpio: davinci: silence error prints in case of EPROBE_DEFER
Chris Wilson <chris(a)chris-wilson.co.uk>
dma-buf: Discard old fence_excl on retrying get_fences_rcu for realloc
Jérôme Glisse <jglisse(a)redhat.com>
dma-buf: balance refcount inbalance
Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
net: bridge: stp: don't cache eth dest pointer before skb pull
Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
net: bridge: don't cache ether dest pointer on input
Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
net: bridge: mcast: fix stale ipv6 hdr pointer when handling v6 query
Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
net: bridge: mcast: fix stale nsrcs pointer in igmp3/mld2 report handling
Xin Long <lucien.xin(a)gmail.com>
sctp: not bind the socket in sctp_connect
Jakub Kicinski <jakub.kicinski(a)netronome.com>
net/tls: make sure offload also gets the keys wiped
Cong Wang <xiyou.wangcong(a)gmail.com>
net_sched: unset TCQ_F_CAN_BYPASS when adding filters
Cong Wang <xiyou.wangcong(a)gmail.com>
netrom: hold sock when setting skb->destructor
Cong Wang <xiyou.wangcong(a)gmail.com>
netrom: fix a memory leak in nr_rx_frame()
Andreas Steinmetz <ast(a)domdv.de>
macsec: fix checksumming after decryption
Andreas Steinmetz <ast(a)domdv.de>
macsec: fix use-after-free of skb during RX
Aya Levin <ayal(a)mellanox.com>
net/mlx5e: IPoIB, Add error path in mlx5_rdma_setup_rn
Peter Kosyh <p.kosyh(a)gmail.com>
vrf: make sure skb->data contains ip header to make routing
Christoph Paasch <cpaasch(a)apple.com>
tcp: Reset bytes_acked and bytes_received when disconnecting
Eric Dumazet <edumazet(a)google.com>
tcp: fix tcp_set_congestion_control() use from bpf hook
Eric Dumazet <edumazet(a)google.com>
tcp: be more careful in tcp_fragment()
Takashi Iwai <tiwai(a)suse.de>
sky2: Disable MSI on ASUS P6T
Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
sctp: fix error handling on stream scheduler initialization
David Howells <dhowells(a)redhat.com>
rxrpc: Fix send on a connected, but unbound socket
Heiner Kallweit <hkallweit1(a)gmail.com>
r8169: fix issue with confused RX unit after PHY power-down on RTL8411b
Yang Wei <albin_yang(a)163.com>
nfc: fix potential illegal memory access
Jose Abreu <Jose.Abreu(a)synopsys.com>
net: stmmac: Re-work the queue selection for TSO packets
Andrew Lunn <andrew(a)lunn.ch>
net: phy: sfp: hwmon: Fix scaling of RX power
John Hurley <john.hurley(a)netronome.com>
net: openvswitch: fix csum updates for MPLS actions
Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
net: neigh: fix multiple neigh timer scheduling
Florian Westphal <fw(a)strlen.de>
net: make skb_dst_force return true when dst is refcounted
Baruch Siach <baruch(a)tkos.co.il>
net: dsa: mv88e6xxx: wait after reset deactivation
Justin Chen <justinpopo6(a)gmail.com>
net: bcmgenet: use promisc for unsupported filters
Ido Schimmel <idosch(a)mellanox.com>
ipv6: Unlink sibling route in case of failure
David Ahern <dsahern(a)gmail.com>
ipv6: rt6_check should return NULL if 'from' is NULL
Matteo Croce <mcroce(a)redhat.com>
ipv4: don't set IPv6 only flags to IPv4 addresses
Eric Dumazet <edumazet(a)google.com>
igmp: fix memory leak in igmpv3_del_delrec()
Haiyang Zhang <haiyangz(a)microsoft.com>
hv_netvsc: Fix extra rcu_read_unlock in netvsc_recv_callback()
Taehee Yoo <ap420073(a)gmail.com>
caif-hsi: fix possible deadlock in cfhsi_exit_module()
Brian King <brking(a)linux.vnet.ibm.com>
bnx2x: Prevent load reordering in tx completion processing
-------------
Diffstat:
Makefile | 4 +-
arch/mips/jz4740/board-qi_lb60.c | 16 +--
arch/x86/kvm/vmx.c | 10 +-
drivers/dma-buf/dma-buf.c | 1 +
drivers/dma-buf/reservation.c | 4 +
drivers/gpio/gpio-davinci.c | 5 +-
drivers/net/caif/caif_hsi.c | 2 +-
drivers/net/dsa/mv88e6xxx/chip.c | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 3 +
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 57 ++++-----
drivers/net/ethernet/marvell/sky2.c | 7 ++
.../net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 9 +-
drivers/net/ethernet/realtek/r8169.c | 137 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 29 +++--
drivers/net/hyperv/netvsc_drv.c | 1 -
drivers/net/macsec.c | 6 +-
drivers/net/phy/sfp.c | 2 +-
drivers/net/vrf.c | 58 +++++----
fs/ext4/dir.c | 19 ++-
fs/ext4/ext4_jbd2.h | 12 +-
fs/ext4/file.c | 4 +
fs/ext4/inode.c | 24 +++-
fs/ext4/ioctl.c | 46 ++++++-
fs/ext4/move_extent.c | 3 +-
fs/ext4/namei.c | 45 +++++--
fs/jbd2/commit.c | 23 +++-
fs/jbd2/journal.c | 4 +
fs/jbd2/transaction.c | 49 ++++----
include/linux/fs.h | 2 +
include/linux/jbd2.h | 22 ++++
include/linux/perf_event.h | 5 +
include/net/dst.h | 5 +-
include/net/tcp.h | 8 +-
include/net/tls.h | 1 +
kernel/events/core.c | 83 ++++++++++---
mm/filemap.c | 22 ++++
mm/vmscan.c | 6 +-
net/bridge/br_input.c | 8 +-
net/bridge/br_multicast.c | 32 ++---
net/bridge/br_stp_bpdu.c | 3 +-
net/core/filter.c | 2 +-
net/core/neighbour.c | 2 +
net/ipv4/devinet.c | 8 ++
net/ipv4/igmp.c | 8 +-
net/ipv4/tcp.c | 6 +-
net/ipv4/tcp_cong.c | 6 +-
net/ipv4/tcp_output.c | 13 +-
net/ipv6/ip6_fib.c | 18 ++-
net/ipv6/route.c | 2 +-
net/netfilter/nf_queue.c | 6 +-
net/netrom/af_netrom.c | 4 +-
net/nfc/nci/data.c | 2 +-
net/openvswitch/actions.c | 6 +-
net/rxrpc/af_rxrpc.c | 4 +-
net/sched/cls_api.c | 1 +
net/sched/sch_fq_codel.c | 2 -
net/sched/sch_sfq.c | 2 -
net/sctp/socket.c | 20 +--
net/sctp/stream.c | 9 +-
net/tls/tls_device.c | 2 +-
net/tls/tls_main.c | 2 +-
61 files changed, 669 insertions(+), 235 deletions(-)
Just in case it has't been reported.
x86/x86_64 allnoconfig, tinyconfig:
Error log:
arch/x86/events/amd/uncore.c: In function 'amd_uncore_event_init':
events/amd/uncore.c:222:7: error: 'smp_num_siblings' undeclared
"#include <asm/smp.h>" is missing. Added upstream with commit 812af433038f9
("perf/events/amd/uncore: Fix amd_uncore_llc ID to use pre-defined cpu_llc_id").
Guenter
Hello Greg,
Can you please consider including the following patch in the stable linux-4.14.y branch?
This is to fix that NFS client incorrectly handling a failed OPEN and ensure that we present the same verifier.
8fd1ab747d2b("NFSv4: Fix open create exclusive when the server reboots")
Thanks,
Qian Lu
This is a note to let you know that I've just added the patch titled
xhci: Fix crash if scatter gather is used with Immediate Data
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From d39b5bad8658d6d94cb2d98a44a7e159db4f5030 Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Date: Thu, 25 Jul 2019 11:54:21 +0300
Subject: xhci: Fix crash if scatter gather is used with Immediate Data
Transfer (IDT).
A second regression was found in the immediate data transfer (IDT)
support which was added to 5.2 kernel
IDT is used to transfer small amounts of data (up to 8 bytes) in the
field normally used for data dma address, thus avoiding dma mapping.
If the data was not already dma mapped, then IDT support assumed data was
in urb->transfer_buffer, and did not take into accound that even
small amounts of data (8 bytes) can be in a scatterlist instead.
This caused a NULL pointer dereference when sg_dma_len() was used
with non-dma mapped data.
Solve this by not using IDT if scatter gather buffer list is used.
Fixes: 33e39350ebd2 ("usb: xhci: add Immediate Data Transfer support")
Cc: <stable(a)vger.kernel.org> # v5.2
Reported-by: Maik Stohn <maik.stohn(a)seal-one.com>
Tested-by: Maik Stohn <maik.stohn(a)seal-one.com>
CC: Nicolas Saenz Julienne <nsaenzjulienne(a)suse.de>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Link: https://lore.kernel.org/r/1564044861-1445-1-git-send-email-mathias.nyman@li…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 7a264962a1a9..f5c41448d067 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -2175,7 +2175,8 @@ static inline bool xhci_urb_suitable_for_idt(struct urb *urb)
if (!usb_endpoint_xfer_isoc(&urb->ep->desc) && usb_urb_dir_out(urb) &&
usb_endpoint_maxp(&urb->ep->desc) >= TRB_IDT_MAX_SIZE &&
urb->transfer_buffer_length <= TRB_IDT_MAX_SIZE &&
- !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP))
+ !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) &&
+ !urb->num_sgs)
return true;
return false;
--
2.22.0
This is a note to let you know that I've just added the patch titled
iio: imu: mpu6050: add missing available scan masks
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 1244a720572fd1680ac8d6b8a4235f2e8557b810 Mon Sep 17 00:00:00 2001
From: Jean-Baptiste Maneyrol <JManeyrol(a)invensense.com>
Date: Thu, 27 Jun 2019 13:19:53 +0000
Subject: iio: imu: mpu6050: add missing available scan masks
Driver only supports 3-axis gyro and/or 3-axis accel.
For icm20602, temp data is mandatory for all configurations.
Fix all single and double axis configurations (almost never used) and more
importantly fix 3-axis gyro and 6-axis accel+gyro buffer on icm20602 when
temp data is not enabled.
Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol(a)invensense.com>
Fixes: 1615fe41a195 ("iio: imu: mpu6050: Fix FIFO layout for ICM20602")
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
index 53a59957cc54..8a704cd5bddb 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
@@ -845,6 +845,25 @@ static const struct iio_chan_spec inv_mpu_channels[] = {
INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_Z, INV_MPU6050_SCAN_ACCL_Z),
};
+static const unsigned long inv_mpu_scan_masks[] = {
+ /* 3-axis accel */
+ BIT(INV_MPU6050_SCAN_ACCL_X)
+ | BIT(INV_MPU6050_SCAN_ACCL_Y)
+ | BIT(INV_MPU6050_SCAN_ACCL_Z),
+ /* 3-axis gyro */
+ BIT(INV_MPU6050_SCAN_GYRO_X)
+ | BIT(INV_MPU6050_SCAN_GYRO_Y)
+ | BIT(INV_MPU6050_SCAN_GYRO_Z),
+ /* 6-axis accel + gyro */
+ BIT(INV_MPU6050_SCAN_ACCL_X)
+ | BIT(INV_MPU6050_SCAN_ACCL_Y)
+ | BIT(INV_MPU6050_SCAN_ACCL_Z)
+ | BIT(INV_MPU6050_SCAN_GYRO_X)
+ | BIT(INV_MPU6050_SCAN_GYRO_Y)
+ | BIT(INV_MPU6050_SCAN_GYRO_Z),
+ 0,
+};
+
static const struct iio_chan_spec inv_icm20602_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(INV_ICM20602_SCAN_TIMESTAMP),
{
@@ -871,6 +890,28 @@ static const struct iio_chan_spec inv_icm20602_channels[] = {
INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_Z, INV_ICM20602_SCAN_ACCL_Z),
};
+static const unsigned long inv_icm20602_scan_masks[] = {
+ /* 3-axis accel + temp (mandatory) */
+ BIT(INV_ICM20602_SCAN_ACCL_X)
+ | BIT(INV_ICM20602_SCAN_ACCL_Y)
+ | BIT(INV_ICM20602_SCAN_ACCL_Z)
+ | BIT(INV_ICM20602_SCAN_TEMP),
+ /* 3-axis gyro + temp (mandatory) */
+ BIT(INV_ICM20602_SCAN_GYRO_X)
+ | BIT(INV_ICM20602_SCAN_GYRO_Y)
+ | BIT(INV_ICM20602_SCAN_GYRO_Z)
+ | BIT(INV_ICM20602_SCAN_TEMP),
+ /* 6-axis accel + gyro + temp (mandatory) */
+ BIT(INV_ICM20602_SCAN_ACCL_X)
+ | BIT(INV_ICM20602_SCAN_ACCL_Y)
+ | BIT(INV_ICM20602_SCAN_ACCL_Z)
+ | BIT(INV_ICM20602_SCAN_GYRO_X)
+ | BIT(INV_ICM20602_SCAN_GYRO_Y)
+ | BIT(INV_ICM20602_SCAN_GYRO_Z)
+ | BIT(INV_ICM20602_SCAN_TEMP),
+ 0,
+};
+
/*
* The user can choose any frequency between INV_MPU6050_MIN_FIFO_RATE and
* INV_MPU6050_MAX_FIFO_RATE, but only these frequencies are matched by the
@@ -1130,9 +1171,11 @@ int inv_mpu_core_probe(struct regmap *regmap, int irq, const char *name,
if (chip_type == INV_ICM20602) {
indio_dev->channels = inv_icm20602_channels;
indio_dev->num_channels = ARRAY_SIZE(inv_icm20602_channels);
+ indio_dev->available_scan_masks = inv_icm20602_scan_masks;
} else {
indio_dev->channels = inv_mpu_channels;
indio_dev->num_channels = ARRAY_SIZE(inv_mpu_channels);
+ indio_dev->available_scan_masks = inv_mpu_scan_masks;
}
indio_dev->info = &mpu_info;
--
2.22.0
This is a note to let you know that I've just added the patch titled
iio: cros_ec_accel_legacy: Fix incorrect channel setting
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 6cdff99c9f7d7d28b87cf05dd464f7c7736332ae Mon Sep 17 00:00:00 2001
From: Gwendal Grignou <gwendal(a)chromium.org>
Date: Fri, 28 Jun 2019 12:17:09 -0700
Subject: iio: cros_ec_accel_legacy: Fix incorrect channel setting
INFO_SCALE is set both for each channel and all channels.
iio is using all channel setting, so the error was not user visible.
Signed-off-by: Gwendal Grignou <gwendal(a)chromium.org>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/accel/cros_ec_accel_legacy.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c b/drivers/iio/accel/cros_ec_accel_legacy.c
index 46bb2e421bb9..ad19d9c716f4 100644
--- a/drivers/iio/accel/cros_ec_accel_legacy.c
+++ b/drivers/iio/accel/cros_ec_accel_legacy.c
@@ -319,7 +319,6 @@ static const struct iio_chan_spec_ext_info cros_ec_accel_legacy_ext_info[] = {
.modified = 1, \
.info_mask_separate = \
BIT(IIO_CHAN_INFO_RAW) | \
- BIT(IIO_CHAN_INFO_SCALE) | \
BIT(IIO_CHAN_INFO_CALIBBIAS), \
.info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE), \
.ext_info = cros_ec_accel_legacy_ext_info, \
--
2.22.0
This is a note to let you know that I've just added the patch titled
IIO: Ingenic JZ47xx: Set clock divider on probe
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 5a304e1a4ea000177cf25f5ecf26e786dda25b98 Mon Sep 17 00:00:00 2001
From: Maarten ter Huurne <maarten(a)treewalker.org>
Date: Thu, 4 Jul 2019 19:36:56 +0200
Subject: IIO: Ingenic JZ47xx: Set clock divider on probe
The SADC component can run at up to 8 MHz on JZ4725B, but is fed
a 12 MHz input clock (EXT). Divide it by two to get 6 MHz, then
set up another divider to match, to produce a 10us clock.
If the clock dividers are left on their power-on defaults (a divider
of 1), the SADC mostly works, but will occasionally produce erroneous
readings. This led to button presses being detected out of nowhere on
the RS90 every few minutes. With this change, no ghost button presses
were logged in almost a day worth of testing.
The ADCLK register for configuring clock dividers doesn't exist on
JZ4740, so avoid writing it there.
A function has been introduced rather than a flag because there is a lot
of variation between the ADCLK registers on JZ47xx SoCs, both in
the internal layout of the register and in the frequency range
supported by the SADC. So this solution should make it easier
to add support for other JZ47xx SoCs later.
Fixes: 1a78daea107d ("iio: adc: probe should set clock divider")
Signed-off-by: Maarten ter Huurne <maarten(a)treewalker.org>
Signed-off-by: Artur Rojek <contact(a)artur-rojek.eu>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/adc/ingenic-adc.c | 54 +++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/drivers/iio/adc/ingenic-adc.c b/drivers/iio/adc/ingenic-adc.c
index 92b1d5037ac9..e234970b7150 100644
--- a/drivers/iio/adc/ingenic-adc.c
+++ b/drivers/iio/adc/ingenic-adc.c
@@ -11,6 +11,7 @@
#include <linux/iio/iio.h>
#include <linux/io.h>
#include <linux/iopoll.h>
+#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/platform_device.h>
@@ -22,8 +23,11 @@
#define JZ_ADC_REG_ADTCH 0x18
#define JZ_ADC_REG_ADBDAT 0x1c
#define JZ_ADC_REG_ADSDAT 0x20
+#define JZ_ADC_REG_ADCLK 0x28
#define JZ_ADC_REG_CFG_BAT_MD BIT(4)
+#define JZ_ADC_REG_ADCLK_CLKDIV_LSB 0
+#define JZ_ADC_REG_ADCLK_CLKDIV10US_LSB 16
#define JZ_ADC_AUX_VREF 3300
#define JZ_ADC_AUX_VREF_BITS 12
@@ -34,6 +38,8 @@
#define JZ4740_ADC_BATTERY_HIGH_VREF (7500 * 0.986)
#define JZ4740_ADC_BATTERY_HIGH_VREF_BITS 12
+struct ingenic_adc;
+
struct ingenic_adc_soc_data {
unsigned int battery_high_vref;
unsigned int battery_high_vref_bits;
@@ -41,6 +47,7 @@ struct ingenic_adc_soc_data {
size_t battery_raw_avail_size;
const int *battery_scale_avail;
size_t battery_scale_avail_size;
+ int (*init_clk_div)(struct device *dev, struct ingenic_adc *adc);
};
struct ingenic_adc {
@@ -151,6 +158,42 @@ static const int jz4740_adc_battery_scale_avail[] = {
JZ_ADC_BATTERY_LOW_VREF, JZ_ADC_BATTERY_LOW_VREF_BITS,
};
+static int jz4725b_adc_init_clk_div(struct device *dev, struct ingenic_adc *adc)
+{
+ struct clk *parent_clk;
+ unsigned long parent_rate, rate;
+ unsigned int div_main, div_10us;
+
+ parent_clk = clk_get_parent(adc->clk);
+ if (!parent_clk) {
+ dev_err(dev, "ADC clock has no parent\n");
+ return -ENODEV;
+ }
+ parent_rate = clk_get_rate(parent_clk);
+
+ /*
+ * The JZ4725B ADC works at 500 kHz to 8 MHz.
+ * We pick the highest rate possible.
+ * In practice we typically get 6 MHz, half of the 12 MHz EXT clock.
+ */
+ div_main = DIV_ROUND_UP(parent_rate, 8000000);
+ div_main = clamp(div_main, 1u, 64u);
+ rate = parent_rate / div_main;
+ if (rate < 500000 || rate > 8000000) {
+ dev_err(dev, "No valid divider for ADC main clock\n");
+ return -EINVAL;
+ }
+
+ /* We also need a divider that produces a 10us clock. */
+ div_10us = DIV_ROUND_UP(rate, 100000);
+
+ writel(((div_10us - 1) << JZ_ADC_REG_ADCLK_CLKDIV10US_LSB) |
+ (div_main - 1) << JZ_ADC_REG_ADCLK_CLKDIV_LSB,
+ adc->base + JZ_ADC_REG_ADCLK);
+
+ return 0;
+}
+
static const struct ingenic_adc_soc_data jz4725b_adc_soc_data = {
.battery_high_vref = JZ4725B_ADC_BATTERY_HIGH_VREF,
.battery_high_vref_bits = JZ4725B_ADC_BATTERY_HIGH_VREF_BITS,
@@ -158,6 +201,7 @@ static const struct ingenic_adc_soc_data jz4725b_adc_soc_data = {
.battery_raw_avail_size = ARRAY_SIZE(jz4725b_adc_battery_raw_avail),
.battery_scale_avail = jz4725b_adc_battery_scale_avail,
.battery_scale_avail_size = ARRAY_SIZE(jz4725b_adc_battery_scale_avail),
+ .init_clk_div = jz4725b_adc_init_clk_div,
};
static const struct ingenic_adc_soc_data jz4740_adc_soc_data = {
@@ -167,6 +211,7 @@ static const struct ingenic_adc_soc_data jz4740_adc_soc_data = {
.battery_raw_avail_size = ARRAY_SIZE(jz4740_adc_battery_raw_avail),
.battery_scale_avail = jz4740_adc_battery_scale_avail,
.battery_scale_avail_size = ARRAY_SIZE(jz4740_adc_battery_scale_avail),
+ .init_clk_div = NULL, /* no ADCLK register on JZ4740 */
};
static int ingenic_adc_read_avail(struct iio_dev *iio_dev,
@@ -317,6 +362,15 @@ static int ingenic_adc_probe(struct platform_device *pdev)
return ret;
}
+ /* Set clock dividers. */
+ if (soc_data->init_clk_div) {
+ ret = soc_data->init_clk_div(dev, adc);
+ if (ret) {
+ clk_disable_unprepare(adc->clk);
+ return ret;
+ }
+ }
+
/* Put hardware in a known passive state. */
writeb(0x00, adc->base + JZ_ADC_REG_ENABLE);
writeb(0xff, adc->base + JZ_ADC_REG_CTRL);
--
2.22.0
This is a note to let you know that I've just added the patch titled
iio: adc: max9611: Fix misuse of GENMASK macro
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From ae8cc91a7d85e018c0c267f580820b2bb558cd48 Mon Sep 17 00:00:00 2001
From: Joe Perches <joe(a)perches.com>
Date: Tue, 9 Jul 2019 22:04:17 -0700
Subject: iio: adc: max9611: Fix misuse of GENMASK macro
Arguments are supposed to be ordered high then low.
Signed-off-by: Joe Perches <joe(a)perches.com>
Fixes: 69780a3bbc0b ("iio: adc: Add Maxim max9611 ADC driver")
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/adc/max9611.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/max9611.c b/drivers/iio/adc/max9611.c
index 917223d5ff5b..0e3c6529fc4c 100644
--- a/drivers/iio/adc/max9611.c
+++ b/drivers/iio/adc/max9611.c
@@ -83,7 +83,7 @@
#define MAX9611_TEMP_MAX_POS 0x7f80
#define MAX9611_TEMP_MAX_NEG 0xff80
#define MAX9611_TEMP_MIN_NEG 0xd980
-#define MAX9611_TEMP_MASK GENMASK(7, 15)
+#define MAX9611_TEMP_MASK GENMASK(15, 7)
#define MAX9611_TEMP_SHIFT 0x07
#define MAX9611_TEMP_RAW(_r) ((_r) >> MAX9611_TEMP_SHIFT)
#define MAX9611_TEMP_SCALE_NUM 1000000
--
2.22.0
Note, this is the LAST 5.1.y kernel to be released. Everyone should be
moved to the 5.2.y kernel at this point in time. 5.1.y is now
end-of-life.
-------------
I'm announcing the release of the 5.1.21 kernel.
All users of the 5.1 kernel series must upgrade.
The updated 5.1.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.1.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
arch/mips/jz4740/board-qi_lb60.c | 16 -
arch/x86/include/asm/kvm_host.h | 7
arch/x86/kvm/vmx/nested.c | 10 -
arch/x86/kvm/x86.c | 4
block/blk-zoned.c | 46 +++--
drivers/dma-buf/dma-buf.c | 1
drivers/dma-buf/reservation.c | 4
drivers/gpio/gpio-davinci.c | 5
drivers/gpio/gpiolib-of.c | 1
drivers/net/caif/caif_hsi.c | 2
drivers/net/dsa/mv88e6xxx/chip.c | 2
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 3
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 57 ++----
drivers/net/ethernet/marvell/sky2.c | 7
drivers/net/ethernet/mellanox/mlx5/core/en.h | 1
drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c | 10 -
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 3
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 7
drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c | 9
drivers/net/ethernet/mellanox/mlx5/core/lib/port_tun.c | 23 --
drivers/net/ethernet/realtek/r8169.c | 137 +++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 29 ++-
drivers/net/hyperv/netvsc_drv.c | 1
drivers/net/macsec.c | 6
drivers/net/phy/sfp.c | 2
drivers/net/vrf.c | 58 +++---
drivers/scsi/sd_zbc.c | 104 ++++++++---
fs/ext4/dir.c | 19 --
fs/ext4/ext4_jbd2.h | 12 -
fs/ext4/file.c | 4
fs/ext4/inode.c | 24 ++
fs/ext4/ioctl.c | 46 ++++-
fs/ext4/move_extent.c | 3
fs/ext4/namei.c | 45 ++++
fs/jbd2/commit.c | 23 +-
fs/jbd2/journal.c | 4
fs/jbd2/transaction.c | 49 +++--
include/linux/blkdev.h | 5
include/linux/fs.h | 2
include/linux/jbd2.h | 22 ++
include/linux/mlx5/mlx5_ifc.h | 3
include/linux/perf_event.h | 5
include/net/dst.h | 5
include/net/tcp.h | 8
include/net/tls.h | 1
kernel/events/core.c | 83 ++++++---
mm/filemap.c | 22 ++
mm/vmscan.c | 6
net/bridge/br_input.c | 8
net/bridge/br_multicast.c | 23 +-
net/bridge/br_stp_bpdu.c | 3
net/core/filter.c | 2
net/core/neighbour.c | 2
net/ipv4/devinet.c | 8
net/ipv4/igmp.c | 8
net/ipv4/tcp.c | 6
net/ipv4/tcp_cong.c | 6
net/ipv4/tcp_output.c | 13 +
net/ipv6/ip6_fib.c | 18 +
net/ipv6/route.c | 2
net/netfilter/nf_queue.c | 6
net/netrom/af_netrom.c | 4
net/nfc/nci/data.c | 2
net/openvswitch/actions.c | 6
net/rxrpc/af_rxrpc.c | 4
net/sched/cls_api.c | 3
net/sched/sch_fq_codel.c | 2
net/sched/sch_sfq.c | 2
net/sctp/socket.c | 24 --
net/sctp/stream.c | 9
net/tls/tls_device.c | 10 -
net/tls/tls_main.c | 4
net/tls/tls_sw.c | 3
tools/perf/builtin-script.c | 3
tools/testing/selftests/net/txring_overwrite.c | 2
76 files changed, 817 insertions(+), 314 deletions(-)
Alexander Shishkin (1):
perf/core: Fix exclusive events' grouping
Andreas Steinmetz (2):
macsec: fix use-after-free of skb during RX
macsec: fix checksumming after decryption
Andrew Lunn (1):
net: phy: sfp: hwmon: Fix scaling of RX power
Aya Levin (3):
net/mlx5e: IPoIB, Add error path in mlx5_rdma_setup_rn
net/mlx5e: Fix return value from timeout recover function
net/mlx5e: Fix error flow in tx reporter diagnose
Baruch Siach (1):
net: dsa: mv88e6xxx: wait after reset deactivation
Brian King (1):
bnx2x: Prevent load reordering in tx completion processing
Chris Wilson (1):
dma-buf: Discard old fence_excl on retrying get_fences_rcu for realloc
Christoph Paasch (1):
tcp: Reset bytes_acked and bytes_received when disconnecting
Cong Wang (3):
net_sched: unset TCQ_F_CAN_BYPASS when adding filters
netrom: fix a memory leak in nr_rx_frame()
netrom: hold sock when setting skb->destructor
Damien Le Moal (2):
sd_zbc: Fix report zones buffer allocation
block: Limit zone array allocation size
Darrick J. Wong (1):
ext4: don't allow any modifications to an immutable file
David Ahern (1):
ipv6: rt6_check should return NULL if 'from' is NULL
David Howells (1):
rxrpc: Fix send on a connected, but unbound socket
Eli Britstein (1):
net/mlx5e: Fix port tunnel GRE entropy control
Eric Dumazet (3):
igmp: fix memory leak in igmpv3_del_delrec()
tcp: be more careful in tcp_fragment()
tcp: fix tcp_set_congestion_control() use from bpf hook
Florian Westphal (1):
net: make skb_dst_force return true when dst is refcounted
Frank de Brabander (1):
selftests: txring_overwrite: fix incorrect test of mmap() return value
Greg Kroah-Hartman (1):
Linux 5.1.21
Haiyang Zhang (1):
hv_netvsc: Fix extra rcu_read_unlock in netvsc_recv_callback()
Heiner Kallweit (1):
r8169: fix issue with confused RX unit after PHY power-down on RTL8411b
Ido Schimmel (1):
ipv6: Unlink sibling route in case of failure
Jakub Kicinski (3):
net/tls: make sure offload also gets the keys wiped
net/tls: fix poll ignoring partially copied records
net/tls: reject offload of TLS 1.3
Jan Kiszka (1):
KVM: nVMX: Clear pending KVM_REQ_GET_VMCS12_PAGES when leaving nested
John Hurley (1):
net: openvswitch: fix csum updates for MPLS actions
Jose Abreu (1):
net: stmmac: Re-work the queue selection for TSO packets
Justin Chen (1):
net: bcmgenet: use promisc for unsupported filters
Jérôme Glisse (1):
dma-buf: balance refcount inbalance
Keerthy (1):
gpio: davinci: silence error prints in case of EPROBE_DEFER
Kuo-Hsin Yang (1):
mm: vmscan: scan anonymous pages on file refaults
Lorenzo Bianconi (1):
net: neigh: fix multiple neigh timer scheduling
Marcelo Ricardo Leitner (1):
sctp: fix error handling on stream scheduler initialization
Matteo Croce (1):
ipv4: don't set IPv6 only flags to IPv4 addresses
Nikolay Aleksandrov (4):
net: bridge: mcast: fix stale nsrcs pointer in igmp3/mld2 report handling
net: bridge: mcast: fix stale ipv6 hdr pointer when handling v6 query
net: bridge: don't cache ether dest pointer on input
net: bridge: stp: don't cache eth dest pointer before skb pull
Nishka Dasgupta (1):
gpiolib: of: fix a memory leak in of_gpio_flags_quirks()
Paolo Bonzini (2):
KVM: nVMX: do not use dangling shadow VMCS after guest reset
Revert "kvm: x86: Use task structs fpu field for user"
Paul Cercueil (1):
MIPS: lb60: Fix pin mappings
Peter Kosyh (1):
vrf: make sure skb->data contains ip header to make routing
Peter Zijlstra (1):
perf/core: Fix race between close() and fork()
Ross Zwisler (3):
mm: add filemap_fdatawait_range_keep_errors()
jbd2: introduce jbd2_inode dirty range scoping
ext4: use jbd2_inode dirty range scoping
Saeed Mahameed (1):
net/mlx5e: Rx, Fix checksum calculation for new hardware
Song Liu (1):
perf script: Assume native_arch for pipe mode
Taehee Yoo (1):
caif-hsi: fix possible deadlock in cfhsi_exit_module()
Takashi Iwai (1):
sky2: Disable MSI on ASUS P6T
Theodore Ts'o (2):
ext4: enforce the immutable flag on open files
ext4: allow directory holes
Vlad Buslov (1):
net: sched: verify that q!=NULL before setting q->flags
Xin Long (1):
sctp: not bind the socket in sctp_connect
Yang Wei (1):
nfc: fix potential illegal memory access
gcc-9 complains about a blatant uninitialized variable use that
all earlier compiler versions missed:
drivers/iio/adc/rcar-gyroadc.c:510:5: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
Return -EINVAL instead here and a few lines above it where
we accidentally return 0 on failure.
Cc: stable(a)vger.kernel.org
Fixes: 059c53b32329 ("iio: adc: Add Renesas GyroADC driver")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
v2: fix the second return code as well
---
drivers/iio/adc/rcar-gyroadc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/rcar-gyroadc.c b/drivers/iio/adc/rcar-gyroadc.c
index 2d685730f867..c37f201294b2 100644
--- a/drivers/iio/adc/rcar-gyroadc.c
+++ b/drivers/iio/adc/rcar-gyroadc.c
@@ -382,7 +382,7 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev *indio_dev)
dev_err(dev,
"Only %i channels supported with %pOFn, but reg = <%i>.\n",
num_channels, child, reg);
- return ret;
+ return -EINVAL;
}
}
@@ -391,7 +391,7 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev *indio_dev)
dev_err(dev,
"Channel %i uses different ADC mode than the rest.\n",
reg);
- return ret;
+ return -EINVAL;
}
/* Channel is valid, grab the regulator. */
--
2.20.0
Hi,
When one request is dispatched to LLD via dm-rq, if the result is
BLK_STS_*RESOURCE, dm-rq will free the request. However, LLD may allocate
private data for this request, so this way will cause memory leak.
Add .cleanup_rq() callback and implement it in SCSI for fixing the issue,
since SCSI is the only driver which allocates private requst data in
.queue_rq() path.
Another use case of this callback is to free the request and re-submit
bios during cpu hotplug when the hctx is dead, see the following link:
https://lore.kernel.org/linux-block/f122e8f2-5ede-2d83-9ca0-bc713ce66d01@hu…
V2:
- run .cleanup_rq() in blk_mq_free_request(), as suggested by Mike
Ming Lei (2):
blk-mq: add callback of .cleanup_rq
scsi: implement .cleanup_rq callback
block/blk-mq.c | 3 +++
drivers/scsi/scsi_lib.c | 28 ++++++++++++++++++++--------
include/linux/blk-mq.h | 7 +++++++
3 files changed, 30 insertions(+), 8 deletions(-)
Cc: Ewan D. Milne <emilne(a)redhat.com>
Cc: Bart Van Assche <bvanassche(a)acm.org>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Mike Snitzer <snitzer(a)redhat.com>
Cc: dm-devel(a)redhat.com
Cc: <stable(a)vger.kernel.org>
Fixes: 396eaf21ee17 ("blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback")
--
2.20.1
The patch titled
Subject: mm/z3fold.c: fix z3fold_destroy_pool() race condition
has been added to the -mm tree. Its filename is
mm-z3foldc-fix-z3fold_destroy_pool-race-condition.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-z3foldc-fix-z3fold_destroy_pool…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-z3foldc-fix-z3fold_destroy_pool…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Henry Burns <henryburns(a)google.com>
Subject: mm/z3fold.c: fix z3fold_destroy_pool() race condition
The constraint from the zpool use of z3fold_destroy_pool() is there are no
outstanding handles to memory (so no active allocations), but it is
possible for there to be outstanding work on either of the two wqs in the
pool.
Calling z3fold_deregister_migration() before the workqueues are drained
means that there can be allocated pages referencing a freed inode, causing
any thread in compaction to be able to trip over the bad pointer in
PageMovable().
Link: http://lkml.kernel.org/r/20190726224810.79660-2-henryburns@google.com
Fixes: 1f862989b04a ("mm/z3fold.c: support page migration")
Signed-off-by: Henry Burns <henryburns(a)google.com>
Cc: Vitaly Vul <vitaly.vul(a)sony.com>
Cc: Vitaly Wool <vitalywool(a)gmail.com>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: Jonathan Adams <jwadams(a)google.com>
Cc: David Howells <dhowells(a)redhat.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Al Viro <viro(a)zeniv.linux.org.uk
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/z3fold.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/mm/z3fold.c~mm-z3foldc-fix-z3fold_destroy_pool-race-condition
+++ a/mm/z3fold.c
@@ -817,16 +817,19 @@ out:
static void z3fold_destroy_pool(struct z3fold_pool *pool)
{
kmem_cache_destroy(pool->c_handle);
- z3fold_unregister_migration(pool);
/*
* We need to destroy pool->compact_wq before pool->release_wq,
* as any pending work on pool->compact_wq will call
* queue_work(pool->release_wq, &pool->work).
+ *
+ * There are still outstanding pages until both workqueues are drained,
+ * so we cannot unregister migration until then.
*/
destroy_workqueue(pool->compact_wq);
destroy_workqueue(pool->release_wq);
+ z3fold_unregister_migration(pool);
kfree(pool);
}
_
Patches currently in -mm which might be from henryburns(a)google.com are
mm-z3foldc-fix-z3fold_destroy_pool-ordering.patch
mm-z3foldc-fix-z3fold_destroy_pool-race-condition.patch
The patch titled
Subject: mm/z3fold.c: fix z3fold_destroy_pool() ordering
has been added to the -mm tree. Its filename is
mm-z3foldc-fix-z3fold_destroy_pool-ordering.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-z3foldc-fix-z3fold_destroy_pool…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-z3foldc-fix-z3fold_destroy_pool…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Henry Burns <henryburns(a)google.com>
Subject: mm/z3fold.c: fix z3fold_destroy_pool() ordering
The constraint from the zpool use of z3fold_destroy_pool() is there are no
outstanding handles to memory (so no active allocations), but it is
possible for there to be outstanding work on either of the two wqs in the
pool.
If there is work queued on pool->compact_workqueue when it is called,
z3fold_destroy_pool() will do:
z3fold_destroy_pool()
destroy_workqueue(pool->release_wq)
destroy_workqueue(pool->compact_wq)
drain_workqueue(pool->compact_wq)
do_compact_page(zhdr)
kref_put(&zhdr->refcount)
__release_z3fold_page(zhdr, ...)
queue_work_on(pool->release_wq, &pool->work) *BOOM*
So compact_wq needs to be destroyed before release_wq.
Link: http://lkml.kernel.org/r/20190726224810.79660-1-henryburns@google.com
Fixes: 5d03a6613957 ("mm/z3fold.c: use kref to prevent page free/compact race")
Signed-off-by: Henry Burns <henryburns(a)google.com>
Reviewed-by: Shakeel Butt <shakeelb(a)google.com>
Cc: Vitaly Vul <vitaly.vul(a)sony.com>
Cc: Vitaly Wool <vitalywool(a)gmail.com>
Cc: Jonathan Adams <jwadams(a)google.com>
Cc: David Howells <dhowells(a)redhat.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Al Viro <viro(a)zeniv.linux.org.uk
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/z3fold.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/mm/z3fold.c~mm-z3foldc-fix-z3fold_destroy_pool-ordering
+++ a/mm/z3fold.c
@@ -818,8 +818,15 @@ static void z3fold_destroy_pool(struct z
{
kmem_cache_destroy(pool->c_handle);
z3fold_unregister_migration(pool);
- destroy_workqueue(pool->release_wq);
+
+ /*
+ * We need to destroy pool->compact_wq before pool->release_wq,
+ * as any pending work on pool->compact_wq will call
+ * queue_work(pool->release_wq, &pool->work).
+ */
+
destroy_workqueue(pool->compact_wq);
+ destroy_workqueue(pool->release_wq);
kfree(pool);
}
_
Patches currently in -mm which might be from henryburns(a)google.com are
mm-z3foldc-fix-z3fold_destroy_pool-ordering.patch
mm-z3foldc-fix-z3fold_destroy_pool-race-condition.patch
On Fri, 2019-07-26 at 14:17 +0000, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.2.2, v5.1.19, v4.19.60,
> v4.14.134, v4.9.186, v4.4.186.
>
> v5.2.2: Build OK!
> v5.1.19: Build OK!
> v4.19.60: Build OK!
> v4.14.134: Build OK!
> v4.9.186: Failed to apply! Possible dependencies:
> 1af5c410cc0c ("drm/nouveau/i2c: modify aux interface to return length
> actually transferred")
skip v4.9
>
> v4.4.186: Failed to apply! Possible dependencies:
> 1af5c410cc0c ("drm/nouveau/i2c: modify aux interface to return length
> actually transferred")
> 2ed95a4c65a3 ("drm/nouveau: recognise GM200 chipset")
> 7568b1067181 ("drm/nouveau/nvif: split out display interface
> definitions")
> 7d2813c437a0 ("drm/nouveau/ltc/gm204: split implementation from gm107")
> db1eb528462f ("drm/nouveau: s/gm204/gm200/ in a number of places")
> e3d26d086092 ("drm/nouveau/ibus/gm204: split implementation from gk104")
>
>
and skip v4.4
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>
> --
> Thanks,
> Sasha
--
Cheers,
Lyude Paul
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 8a58ddae23796c733c5dfbd717538d89d036c5bd Mon Sep 17 00:00:00 2001
From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Date: Mon, 1 Jul 2019 14:07:55 +0300
Subject: [PATCH] perf/core: Fix exclusive events' grouping
So far, we tried to disallow grouping exclusive events for the fear of
complications they would cause with moving between contexts. Specifically,
moving a software group to a hardware context would violate the exclusivity
rules if both groups contain matching exclusive events.
This attempt was, however, unsuccessful: the check that we have in the
perf_event_open() syscall is both wrong (looks at wrong PMU) and
insufficient (group leader may still be exclusive), as can be illustrated
by running:
$ perf record -e '{intel_pt//,cycles}' uname
$ perf record -e '{cycles,intel_pt//}' uname
ultimately successfully.
Furthermore, we are completely free to trigger the exclusivity violation
by:
perf -e '{cycles,intel_pt//}' -e '{intel_pt//,instructions}'
even though the helpful perf record will not allow that, the ABI will.
The warning later in the perf_event_open() path will also not trigger, because
it's also wrong.
Fix all this by validating the original group before moving, getting rid
of broken safeguards and placing a useful one to perf_install_in_context().
Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: <stable(a)vger.kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Cc: mathieu.poirier(a)linaro.org
Cc: will.deacon(a)arm.com
Fixes: bed5b25ad9c8a ("perf: Add a pmu capability for "exclusive" events")
Link: https://lkml.kernel.org/r/20190701110755.24646-1-alexander.shishkin@linux.i…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 16e38c286d46..e8ad3c590a23 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1055,6 +1055,11 @@ static inline int in_software_context(struct perf_event *event)
return event->ctx->pmu->task_ctx_nr == perf_sw_context;
}
+static inline int is_exclusive_pmu(struct pmu *pmu)
+{
+ return pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE;
+}
+
extern struct static_key perf_swevent_enabled[PERF_COUNT_SW_MAX];
extern void ___perf_sw_event(u32, u64, struct pt_regs *, u64);
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 5dd19bedbf64..eea9d52b010c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2553,6 +2553,9 @@ static int __perf_install_in_context(void *info)
return ret;
}
+static bool exclusive_event_installable(struct perf_event *event,
+ struct perf_event_context *ctx);
+
/*
* Attach a performance event to a context.
*
@@ -2567,6 +2570,8 @@ perf_install_in_context(struct perf_event_context *ctx,
lockdep_assert_held(&ctx->mutex);
+ WARN_ON_ONCE(!exclusive_event_installable(event, ctx));
+
if (event->cpu != -1)
event->cpu = cpu;
@@ -4360,7 +4365,7 @@ static int exclusive_event_init(struct perf_event *event)
{
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ if (!is_exclusive_pmu(pmu))
return 0;
/*
@@ -4391,7 +4396,7 @@ static void exclusive_event_destroy(struct perf_event *event)
{
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ if (!is_exclusive_pmu(pmu))
return;
/* see comment in exclusive_event_init() */
@@ -4411,14 +4416,15 @@ static bool exclusive_event_match(struct perf_event *e1, struct perf_event *e2)
return false;
}
-/* Called under the same ctx::mutex as perf_install_in_context() */
static bool exclusive_event_installable(struct perf_event *event,
struct perf_event_context *ctx)
{
struct perf_event *iter_event;
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ lockdep_assert_held(&ctx->mutex);
+
+ if (!is_exclusive_pmu(pmu))
return true;
list_for_each_entry(iter_event, &ctx->event_list, event_entry) {
@@ -10947,11 +10953,6 @@ SYSCALL_DEFINE5(perf_event_open,
goto err_alloc;
}
- if ((pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE) && group_leader) {
- err = -EBUSY;
- goto err_context;
- }
-
/*
* Look up the group leader (we will attach this event to it):
*/
@@ -11039,6 +11040,18 @@ SYSCALL_DEFINE5(perf_event_open,
move_group = 0;
}
}
+
+ /*
+ * Failure to create exclusive events returns -EBUSY.
+ */
+ err = -EBUSY;
+ if (!exclusive_event_installable(group_leader, ctx))
+ goto err_locked;
+
+ for_each_sibling_event(sibling, group_leader) {
+ if (!exclusive_event_installable(sibling, ctx))
+ goto err_locked;
+ }
} else {
mutex_lock(&ctx->mutex);
}
@@ -11075,9 +11088,6 @@ SYSCALL_DEFINE5(perf_event_open,
* because we need to serialize with concurrent event creation.
*/
if (!exclusive_event_installable(event, ctx)) {
- /* exclusive and group stuff are assumed mutually exclusive */
- WARN_ON_ONCE(move_group);
-
err = -EBUSY;
goto err_locked;
}
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 8a58ddae23796c733c5dfbd717538d89d036c5bd Mon Sep 17 00:00:00 2001
From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Date: Mon, 1 Jul 2019 14:07:55 +0300
Subject: [PATCH] perf/core: Fix exclusive events' grouping
So far, we tried to disallow grouping exclusive events for the fear of
complications they would cause with moving between contexts. Specifically,
moving a software group to a hardware context would violate the exclusivity
rules if both groups contain matching exclusive events.
This attempt was, however, unsuccessful: the check that we have in the
perf_event_open() syscall is both wrong (looks at wrong PMU) and
insufficient (group leader may still be exclusive), as can be illustrated
by running:
$ perf record -e '{intel_pt//,cycles}' uname
$ perf record -e '{cycles,intel_pt//}' uname
ultimately successfully.
Furthermore, we are completely free to trigger the exclusivity violation
by:
perf -e '{cycles,intel_pt//}' -e '{intel_pt//,instructions}'
even though the helpful perf record will not allow that, the ABI will.
The warning later in the perf_event_open() path will also not trigger, because
it's also wrong.
Fix all this by validating the original group before moving, getting rid
of broken safeguards and placing a useful one to perf_install_in_context().
Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: <stable(a)vger.kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Cc: mathieu.poirier(a)linaro.org
Cc: will.deacon(a)arm.com
Fixes: bed5b25ad9c8a ("perf: Add a pmu capability for "exclusive" events")
Link: https://lkml.kernel.org/r/20190701110755.24646-1-alexander.shishkin@linux.i…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 16e38c286d46..e8ad3c590a23 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1055,6 +1055,11 @@ static inline int in_software_context(struct perf_event *event)
return event->ctx->pmu->task_ctx_nr == perf_sw_context;
}
+static inline int is_exclusive_pmu(struct pmu *pmu)
+{
+ return pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE;
+}
+
extern struct static_key perf_swevent_enabled[PERF_COUNT_SW_MAX];
extern void ___perf_sw_event(u32, u64, struct pt_regs *, u64);
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 5dd19bedbf64..eea9d52b010c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2553,6 +2553,9 @@ static int __perf_install_in_context(void *info)
return ret;
}
+static bool exclusive_event_installable(struct perf_event *event,
+ struct perf_event_context *ctx);
+
/*
* Attach a performance event to a context.
*
@@ -2567,6 +2570,8 @@ perf_install_in_context(struct perf_event_context *ctx,
lockdep_assert_held(&ctx->mutex);
+ WARN_ON_ONCE(!exclusive_event_installable(event, ctx));
+
if (event->cpu != -1)
event->cpu = cpu;
@@ -4360,7 +4365,7 @@ static int exclusive_event_init(struct perf_event *event)
{
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ if (!is_exclusive_pmu(pmu))
return 0;
/*
@@ -4391,7 +4396,7 @@ static void exclusive_event_destroy(struct perf_event *event)
{
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ if (!is_exclusive_pmu(pmu))
return;
/* see comment in exclusive_event_init() */
@@ -4411,14 +4416,15 @@ static bool exclusive_event_match(struct perf_event *e1, struct perf_event *e2)
return false;
}
-/* Called under the same ctx::mutex as perf_install_in_context() */
static bool exclusive_event_installable(struct perf_event *event,
struct perf_event_context *ctx)
{
struct perf_event *iter_event;
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ lockdep_assert_held(&ctx->mutex);
+
+ if (!is_exclusive_pmu(pmu))
return true;
list_for_each_entry(iter_event, &ctx->event_list, event_entry) {
@@ -10947,11 +10953,6 @@ SYSCALL_DEFINE5(perf_event_open,
goto err_alloc;
}
- if ((pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE) && group_leader) {
- err = -EBUSY;
- goto err_context;
- }
-
/*
* Look up the group leader (we will attach this event to it):
*/
@@ -11039,6 +11040,18 @@ SYSCALL_DEFINE5(perf_event_open,
move_group = 0;
}
}
+
+ /*
+ * Failure to create exclusive events returns -EBUSY.
+ */
+ err = -EBUSY;
+ if (!exclusive_event_installable(group_leader, ctx))
+ goto err_locked;
+
+ for_each_sibling_event(sibling, group_leader) {
+ if (!exclusive_event_installable(sibling, ctx))
+ goto err_locked;
+ }
} else {
mutex_lock(&ctx->mutex);
}
@@ -11075,9 +11088,6 @@ SYSCALL_DEFINE5(perf_event_open,
* because we need to serialize with concurrent event creation.
*/
if (!exclusive_event_installable(event, ctx)) {
- /* exclusive and group stuff are assumed mutually exclusive */
- WARN_ON_ONCE(move_group);
-
err = -EBUSY;
goto err_locked;
}
When fall-through warnings was enabled by default, commit d93512ef0f0e
("Makefile: Globally enable fall-through warning"), the following
warnings was starting to show up:
In file included from ../arch/arm64/include/asm/kvm_emulate.h:19,
from ../arch/arm64/kvm/regmap.c:13:
../arch/arm64/kvm/regmap.c: In function ‘vcpu_write_spsr32’:
../arch/arm64/include/asm/kvm_hyp.h:31:3: warning: this statement may fall
through [-Wimplicit-fallthrough=]
asm volatile(ALTERNATIVE(__msr_s(r##nvh, "%x0"), \
^~~
../arch/arm64/include/asm/kvm_hyp.h:46:31: note: in expansion of macro ‘write_sysreg_elx’
#define write_sysreg_el1(v,r) write_sysreg_elx(v, r, _EL1, _EL12)
^~~~~~~~~~~~~~~~
../arch/arm64/kvm/regmap.c:180:3: note: in expansion of macro ‘write_sysreg_el1’
write_sysreg_el1(v, SYS_SPSR);
^~~~~~~~~~~~~~~~
../arch/arm64/kvm/regmap.c:181:2: note: here
case KVM_SPSR_ABT:
^~~~
In file included from ../arch/arm64/include/asm/cputype.h:132,
from ../arch/arm64/include/asm/cache.h:8,
from ../include/linux/cache.h:6,
from ../include/linux/printk.h:9,
from ../include/linux/kernel.h:15,
from ../include/asm-generic/bug.h:18,
from ../arch/arm64/include/asm/bug.h:26,
from ../include/linux/bug.h:5,
from ../include/linux/mmdebug.h:5,
from ../include/linux/mm.h:9,
from ../arch/arm64/kvm/regmap.c:11:
../arch/arm64/include/asm/sysreg.h:837:2: warning: this statement may fall
through [-Wimplicit-fallthrough=]
asm volatile("msr " __stringify(r) ", %x0" \
^~~
../arch/arm64/kvm/regmap.c:182:3: note: in expansion of macro ‘write_sysreg’
write_sysreg(v, spsr_abt);
^~~~~~~~~~~~
../arch/arm64/kvm/regmap.c:183:2: note: here
case KVM_SPSR_UND:
^~~~
Rework to add a 'break;' in the swich-case since it didn't have that.
That also made the compiler happy and didn't warn about fall-through.
Cc: stable(a)vger.kernel.org # v3.16+
Fixes: a892819560c4 ("KVM: arm64: Prepare to handle deferred save/restore of 32-bit registers")
Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org>
---
arch/arm64/kvm/regmap.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/kvm/regmap.c b/arch/arm64/kvm/regmap.c
index 0d60e4f0af66..a900181e3867 100644
--- a/arch/arm64/kvm/regmap.c
+++ b/arch/arm64/kvm/regmap.c
@@ -178,13 +178,18 @@ void vcpu_write_spsr32(struct kvm_vcpu *vcpu, unsigned long v)
switch (spsr_idx) {
case KVM_SPSR_SVC:
write_sysreg_el1(v, SYS_SPSR);
+ break;
case KVM_SPSR_ABT:
write_sysreg(v, spsr_abt);
+ break;
case KVM_SPSR_UND:
write_sysreg(v, spsr_und);
+ break;
case KVM_SPSR_IRQ:
write_sysreg(v, spsr_irq);
+ break;
case KVM_SPSR_FIQ:
write_sysreg(v, spsr_fiq);
+ break;
}
}
--
2.20.1
Few patches were recently marked for stable@ but commits are not
backportable as-is and require a few tweaks. Here is 5.1 stable backport.
[PATCH2 of the series applies as-is, I have it here for completeness]
Jan Kiszka (1):
KVM: nVMX: Clear pending KVM_REQ_GET_VMCS12_PAGES when leaving nested
Paolo Bonzini (2):
KVM: nVMX: do not use dangling shadow VMCS after guest reset
Revert "kvm: x86: Use task structs fpu field for user"
arch/x86/include/asm/kvm_host.h | 7 ++++---
arch/x86/kvm/vmx/nested.c | 10 +++++++++-
arch/x86/kvm/x86.c | 4 ++--
3 files changed, 15 insertions(+), 6 deletions(-)
--
2.20.1
Few patches were recently marked for stable@ but commits are not
backportable as-is and require a few tweaks. Here is 5.2 stable backport.
[PATCHes 2/3 of the series apply as-is, I have them here for completeness]
Jan Kiszka (1):
KVM: nVMX: Clear pending KVM_REQ_GET_VMCS12_PAGES when leaving nested
Paolo Bonzini (2):
KVM: nVMX: do not use dangling shadow VMCS after guest reset
Revert "kvm: x86: Use task structs fpu field for user"
arch/x86/include/asm/kvm_host.h | 7 ++++---
arch/x86/kvm/vmx/nested.c | 10 +++++++++-
arch/x86/kvm/x86.c | 4 ++--
3 files changed, 15 insertions(+), 6 deletions(-)
--
2.20.1
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit ffd9a1ba9fdb7f2bd1d1ad9b9243d34e96756ba2 ]
DMA got broken a while back in two different ways:
1) a change in the behaviour of disable_irq() to wait for the interrupt
to finish executing causes us to deadlock at the end of DMA.
2) a change to avoid modifying the scatterlist left the first transfer
uninitialised.
DMA is only used with expansion cards, so has gone unnoticed.
Fixes: fa4e99899932 ("[ARM] dma: RiscPC: don't modify DMA SG entries")
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/arm/mach-rpc/dma.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rpc/dma.c b/arch/arm/mach-rpc/dma.c
index 488d5c3b37f4..799e0b016b62 100644
--- a/arch/arm/mach-rpc/dma.c
+++ b/arch/arm/mach-rpc/dma.c
@@ -128,7 +128,7 @@ static irqreturn_t iomd_dma_handle(int irq, void *dev_id)
} while (1);
idma->state = ~DMA_ST_AB;
- disable_irq(irq);
+ disable_irq_nosync(irq);
return IRQ_HANDLED;
}
@@ -177,6 +177,9 @@ static void iomd_enable_dma(unsigned int chan, dma_t *dma)
DMA_FROM_DEVICE : DMA_TO_DEVICE);
}
+ idma->dma_addr = idma->dma.sg->dma_address;
+ idma->dma_len = idma->dma.sg->length;
+
iomd_writeb(DMA_CR_C, dma_base + CR);
idma->state = DMA_ST_AB;
}
--
2.20.1
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit ffd9a1ba9fdb7f2bd1d1ad9b9243d34e96756ba2 ]
DMA got broken a while back in two different ways:
1) a change in the behaviour of disable_irq() to wait for the interrupt
to finish executing causes us to deadlock at the end of DMA.
2) a change to avoid modifying the scatterlist left the first transfer
uninitialised.
DMA is only used with expansion cards, so has gone unnoticed.
Fixes: fa4e99899932 ("[ARM] dma: RiscPC: don't modify DMA SG entries")
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/arm/mach-rpc/dma.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rpc/dma.c b/arch/arm/mach-rpc/dma.c
index 6d3517dc4772..82aac38fa2cf 100644
--- a/arch/arm/mach-rpc/dma.c
+++ b/arch/arm/mach-rpc/dma.c
@@ -131,7 +131,7 @@ static irqreturn_t iomd_dma_handle(int irq, void *dev_id)
} while (1);
idma->state = ~DMA_ST_AB;
- disable_irq(irq);
+ disable_irq_nosync(irq);
return IRQ_HANDLED;
}
@@ -174,6 +174,9 @@ static void iomd_enable_dma(unsigned int chan, dma_t *dma)
DMA_FROM_DEVICE : DMA_TO_DEVICE);
}
+ idma->dma_addr = idma->dma.sg->dma_address;
+ idma->dma_len = idma->dma.sg->length;
+
iomd_writeb(DMA_CR_C, dma_base + CR);
idma->state = DMA_ST_AB;
}
--
2.20.1
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit ffd9a1ba9fdb7f2bd1d1ad9b9243d34e96756ba2 ]
DMA got broken a while back in two different ways:
1) a change in the behaviour of disable_irq() to wait for the interrupt
to finish executing causes us to deadlock at the end of DMA.
2) a change to avoid modifying the scatterlist left the first transfer
uninitialised.
DMA is only used with expansion cards, so has gone unnoticed.
Fixes: fa4e99899932 ("[ARM] dma: RiscPC: don't modify DMA SG entries")
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/arm/mach-rpc/dma.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rpc/dma.c b/arch/arm/mach-rpc/dma.c
index 6d3517dc4772..82aac38fa2cf 100644
--- a/arch/arm/mach-rpc/dma.c
+++ b/arch/arm/mach-rpc/dma.c
@@ -131,7 +131,7 @@ static irqreturn_t iomd_dma_handle(int irq, void *dev_id)
} while (1);
idma->state = ~DMA_ST_AB;
- disable_irq(irq);
+ disable_irq_nosync(irq);
return IRQ_HANDLED;
}
@@ -174,6 +174,9 @@ static void iomd_enable_dma(unsigned int chan, dma_t *dma)
DMA_FROM_DEVICE : DMA_TO_DEVICE);
}
+ idma->dma_addr = idma->dma.sg->dma_address;
+ idma->dma_len = idma->dma.sg->length;
+
iomd_writeb(DMA_CR_C, dma_base + CR);
idma->state = DMA_ST_AB;
}
--
2.20.1
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit ffd9a1ba9fdb7f2bd1d1ad9b9243d34e96756ba2 ]
DMA got broken a while back in two different ways:
1) a change in the behaviour of disable_irq() to wait for the interrupt
to finish executing causes us to deadlock at the end of DMA.
2) a change to avoid modifying the scatterlist left the first transfer
uninitialised.
DMA is only used with expansion cards, so has gone unnoticed.
Fixes: fa4e99899932 ("[ARM] dma: RiscPC: don't modify DMA SG entries")
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/arm/mach-rpc/dma.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rpc/dma.c b/arch/arm/mach-rpc/dma.c
index fb48f3141fb4..c4c96661eb89 100644
--- a/arch/arm/mach-rpc/dma.c
+++ b/arch/arm/mach-rpc/dma.c
@@ -131,7 +131,7 @@ static irqreturn_t iomd_dma_handle(int irq, void *dev_id)
} while (1);
idma->state = ~DMA_ST_AB;
- disable_irq(irq);
+ disable_irq_nosync(irq);
return IRQ_HANDLED;
}
@@ -174,6 +174,9 @@ static void iomd_enable_dma(unsigned int chan, dma_t *dma)
DMA_FROM_DEVICE : DMA_TO_DEVICE);
}
+ idma->dma_addr = idma->dma.sg->dma_address;
+ idma->dma_len = idma->dma.sg->length;
+
iomd_writeb(DMA_CR_C, dma_base + CR);
idma->state = DMA_ST_AB;
}
--
2.20.1
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit ffd9a1ba9fdb7f2bd1d1ad9b9243d34e96756ba2 ]
DMA got broken a while back in two different ways:
1) a change in the behaviour of disable_irq() to wait for the interrupt
to finish executing causes us to deadlock at the end of DMA.
2) a change to avoid modifying the scatterlist left the first transfer
uninitialised.
DMA is only used with expansion cards, so has gone unnoticed.
Fixes: fa4e99899932 ("[ARM] dma: RiscPC: don't modify DMA SG entries")
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/arm/mach-rpc/dma.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rpc/dma.c b/arch/arm/mach-rpc/dma.c
index fb48f3141fb4..c4c96661eb89 100644
--- a/arch/arm/mach-rpc/dma.c
+++ b/arch/arm/mach-rpc/dma.c
@@ -131,7 +131,7 @@ static irqreturn_t iomd_dma_handle(int irq, void *dev_id)
} while (1);
idma->state = ~DMA_ST_AB;
- disable_irq(irq);
+ disable_irq_nosync(irq);
return IRQ_HANDLED;
}
@@ -174,6 +174,9 @@ static void iomd_enable_dma(unsigned int chan, dma_t *dma)
DMA_FROM_DEVICE : DMA_TO_DEVICE);
}
+ idma->dma_addr = idma->dma.sg->dma_address;
+ idma->dma_len = idma->dma.sg->length;
+
iomd_writeb(DMA_CR_C, dma_base + CR);
idma->state = DMA_ST_AB;
}
--
2.20.1
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 4993e5b37e8bcb55ac90f76eb6d2432647273747 Mon Sep 17 00:00:00 2001
From: Jose Abreu <Jose.Abreu(a)synopsys.com>
Date: Mon, 8 Jul 2019 14:26:28 +0200
Subject: [PATCH] net: stmmac: Re-work the queue selection for TSO packets
Ben Hutchings says:
"This is the wrong place to change the queue mapping.
stmmac_xmit() is called with a specific TX queue locked,
and accessing a different TX queue results in a data race
for all of that queue's state.
I think this commit should be reverted upstream and in all
stable branches. Instead, the driver should implement the
ndo_select_queue operation and override the queue mapping there."
Fixes: c5acdbee22a1 ("net: stmmac: Send TSO packets always from Queue 0")
Suggested-by: Ben Hutchings <ben(a)decadent.org.uk>
Signed-off-by: Jose Abreu <joabreu(a)synopsys.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 06358fe5b245..11b6feb33b54 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3045,17 +3045,8 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
/* Manage oversized TCP frames for GMAC4 device */
if (skb_is_gso(skb) && priv->tso) {
- if (skb_shinfo(skb)->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)) {
- /*
- * There is no way to determine the number of TSO
- * capable Queues. Let's use always the Queue 0
- * because if TSO is supported then at least this
- * one will be capable.
- */
- skb_set_queue_mapping(skb, 0);
-
+ if (skb_shinfo(skb)->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))
return stmmac_tso_xmit(skb, dev);
- }
}
if (unlikely(stmmac_tx_avail(priv, queue) < nfrags + 1)) {
@@ -3872,6 +3863,22 @@ static int stmmac_setup_tc(struct net_device *ndev, enum tc_setup_type type,
}
}
+static u16 stmmac_select_queue(struct net_device *dev, struct sk_buff *skb,
+ struct net_device *sb_dev)
+{
+ if (skb_shinfo(skb)->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)) {
+ /*
+ * There is no way to determine the number of TSO
+ * capable Queues. Let's use always the Queue 0
+ * because if TSO is supported then at least this
+ * one will be capable.
+ */
+ return 0;
+ }
+
+ return netdev_pick_tx(dev, skb, NULL) % dev->real_num_tx_queues;
+}
+
static int stmmac_set_mac_address(struct net_device *ndev, void *addr)
{
struct stmmac_priv *priv = netdev_priv(ndev);
@@ -4088,6 +4095,7 @@ static const struct net_device_ops stmmac_netdev_ops = {
.ndo_tx_timeout = stmmac_tx_timeout,
.ndo_do_ioctl = stmmac_ioctl,
.ndo_setup_tc = stmmac_setup_tc,
+ .ndo_select_queue = stmmac_select_queue,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = stmmac_poll_controller,
#endif
When fall-through warnings was enabled by default, commit d93512ef0f0e
("Makefile: Globally enable fall-through warning"), the following
warnings was starting to show up:
../arch/arm64/kernel/hw_breakpoint.c: In function ‘hw_breakpoint_arch_parse’:
../arch/arm64/kernel/hw_breakpoint.c:540:7: warning: this statement may fall
through [-Wimplicit-fallthrough=]
if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1)
^
../arch/arm64/kernel/hw_breakpoint.c:542:3: note: here
case 2:
^~~~
../arch/arm64/kernel/hw_breakpoint.c:544:7: warning: this statement may fall
through [-Wimplicit-fallthrough=]
if (hw->ctrl.len == ARM_BREAKPOINT_LEN_2)
^
../arch/arm64/kernel/hw_breakpoint.c:546:3: note: here
default:
^~~~~~~
Rework so that the compiler doesn't warn about fall-through. Rework so
the code looks like the arm code. Since the comment in the function
indicates taht this is supposed to behave the same way as arm32 because
it handles 32-bit tasks also.
Cc: stable(a)vger.kernel.org # v3.16+
Fixes: 6ee33c2712fc ("ARM: hw_breakpoint: correct and simplify alignment fixup code")
Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org>
---
arch/arm64/kernel/hw_breakpoint.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index dceb84520948..ea616adf1cf1 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -535,14 +535,17 @@ int hw_breakpoint_arch_parse(struct perf_event *bp,
case 0:
/* Aligned */
break;
- case 1:
- /* Allow single byte watchpoint. */
- if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1)
- break;
case 2:
/* Allow halfword watchpoints and breakpoints. */
if (hw->ctrl.len == ARM_BREAKPOINT_LEN_2)
break;
+ /* Fall through */
+ case 1:
+ case 3:
+ /* Allow single byte watchpoint. */
+ if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1)
+ break;
+ /* Fall through */
default:
return -EINVAL;
}
--
2.20.1
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 2e53840362771c73eb0a5ff71611507e64e8eecd Mon Sep 17 00:00:00 2001
From: "Darrick J. Wong" <darrick.wong(a)oracle.com>
Date: Sun, 9 Jun 2019 21:41:41 -0400
Subject: [PATCH] ext4: don't allow any modifications to an immutable file
Don't allow any modifications to a file that's marked immutable, which
means that we have to flush all the writable pages to make the readonly
and we have to check the setattr/setflags parameters more closely.
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)kernel.org
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index e486e49b31ed..7af835ac8d23 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -269,6 +269,29 @@ static int uuid_is_zero(__u8 u[16])
}
#endif
+/*
+ * If immutable is set and we are not clearing it, we're not allowed to change
+ * anything else in the inode. Don't error out if we're only trying to set
+ * immutable on an immutable file.
+ */
+static int ext4_ioctl_check_immutable(struct inode *inode, __u32 new_projid,
+ unsigned int flags)
+{
+ struct ext4_inode_info *ei = EXT4_I(inode);
+ unsigned int oldflags = ei->i_flags;
+
+ if (!(oldflags & EXT4_IMMUTABLE_FL) || !(flags & EXT4_IMMUTABLE_FL))
+ return 0;
+
+ if ((oldflags & ~EXT4_IMMUTABLE_FL) != (flags & ~EXT4_IMMUTABLE_FL))
+ return -EPERM;
+ if (ext4_has_feature_project(inode->i_sb) &&
+ __kprojid_val(ei->i_projid) != new_projid)
+ return -EPERM;
+
+ return 0;
+}
+
static int ext4_ioctl_setflags(struct inode *inode,
unsigned int flags)
{
@@ -340,6 +363,20 @@ static int ext4_ioctl_setflags(struct inode *inode,
}
}
+ /*
+ * Wait for all pending directio and then flush all the dirty pages
+ * for this file. The flush marks all the pages readonly, so any
+ * subsequent attempt to write to the file (particularly mmap pages)
+ * will come through the filesystem and fail.
+ */
+ if (S_ISREG(inode->i_mode) && !IS_IMMUTABLE(inode) &&
+ (flags & EXT4_IMMUTABLE_FL)) {
+ inode_dio_wait(inode);
+ err = filemap_write_and_wait(inode->i_mapping);
+ if (err)
+ goto flags_out;
+ }
+
handle = ext4_journal_start(inode, EXT4_HT_INODE, 1);
if (IS_ERR(handle)) {
err = PTR_ERR(handle);
@@ -769,7 +806,11 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
return err;
inode_lock(inode);
- err = ext4_ioctl_setflags(inode, flags);
+ err = ext4_ioctl_check_immutable(inode,
+ from_kprojid(&init_user_ns, ei->i_projid),
+ flags);
+ if (!err)
+ err = ext4_ioctl_setflags(inode, flags);
inode_unlock(inode);
mnt_drop_write_file(filp);
return err;
@@ -1139,6 +1180,9 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
goto out;
flags = (ei->i_flags & ~EXT4_FL_XFLAG_VISIBLE) |
(flags & EXT4_FL_XFLAG_VISIBLE);
+ err = ext4_ioctl_check_immutable(inode, fa.fsx_projid, flags);
+ if (err)
+ goto out;
err = ext4_ioctl_setflags(inode, flags);
if (err)
goto out;
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 8a58ddae23796c733c5dfbd717538d89d036c5bd Mon Sep 17 00:00:00 2001
From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Date: Mon, 1 Jul 2019 14:07:55 +0300
Subject: [PATCH] perf/core: Fix exclusive events' grouping
So far, we tried to disallow grouping exclusive events for the fear of
complications they would cause with moving between contexts. Specifically,
moving a software group to a hardware context would violate the exclusivity
rules if both groups contain matching exclusive events.
This attempt was, however, unsuccessful: the check that we have in the
perf_event_open() syscall is both wrong (looks at wrong PMU) and
insufficient (group leader may still be exclusive), as can be illustrated
by running:
$ perf record -e '{intel_pt//,cycles}' uname
$ perf record -e '{cycles,intel_pt//}' uname
ultimately successfully.
Furthermore, we are completely free to trigger the exclusivity violation
by:
perf -e '{cycles,intel_pt//}' -e '{intel_pt//,instructions}'
even though the helpful perf record will not allow that, the ABI will.
The warning later in the perf_event_open() path will also not trigger, because
it's also wrong.
Fix all this by validating the original group before moving, getting rid
of broken safeguards and placing a useful one to perf_install_in_context().
Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: <stable(a)vger.kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Cc: mathieu.poirier(a)linaro.org
Cc: will.deacon(a)arm.com
Fixes: bed5b25ad9c8a ("perf: Add a pmu capability for "exclusive" events")
Link: https://lkml.kernel.org/r/20190701110755.24646-1-alexander.shishkin@linux.i…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 16e38c286d46..e8ad3c590a23 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1055,6 +1055,11 @@ static inline int in_software_context(struct perf_event *event)
return event->ctx->pmu->task_ctx_nr == perf_sw_context;
}
+static inline int is_exclusive_pmu(struct pmu *pmu)
+{
+ return pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE;
+}
+
extern struct static_key perf_swevent_enabled[PERF_COUNT_SW_MAX];
extern void ___perf_sw_event(u32, u64, struct pt_regs *, u64);
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 5dd19bedbf64..eea9d52b010c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2553,6 +2553,9 @@ static int __perf_install_in_context(void *info)
return ret;
}
+static bool exclusive_event_installable(struct perf_event *event,
+ struct perf_event_context *ctx);
+
/*
* Attach a performance event to a context.
*
@@ -2567,6 +2570,8 @@ perf_install_in_context(struct perf_event_context *ctx,
lockdep_assert_held(&ctx->mutex);
+ WARN_ON_ONCE(!exclusive_event_installable(event, ctx));
+
if (event->cpu != -1)
event->cpu = cpu;
@@ -4360,7 +4365,7 @@ static int exclusive_event_init(struct perf_event *event)
{
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ if (!is_exclusive_pmu(pmu))
return 0;
/*
@@ -4391,7 +4396,7 @@ static void exclusive_event_destroy(struct perf_event *event)
{
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ if (!is_exclusive_pmu(pmu))
return;
/* see comment in exclusive_event_init() */
@@ -4411,14 +4416,15 @@ static bool exclusive_event_match(struct perf_event *e1, struct perf_event *e2)
return false;
}
-/* Called under the same ctx::mutex as perf_install_in_context() */
static bool exclusive_event_installable(struct perf_event *event,
struct perf_event_context *ctx)
{
struct perf_event *iter_event;
struct pmu *pmu = event->pmu;
- if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
+ lockdep_assert_held(&ctx->mutex);
+
+ if (!is_exclusive_pmu(pmu))
return true;
list_for_each_entry(iter_event, &ctx->event_list, event_entry) {
@@ -10947,11 +10953,6 @@ SYSCALL_DEFINE5(perf_event_open,
goto err_alloc;
}
- if ((pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE) && group_leader) {
- err = -EBUSY;
- goto err_context;
- }
-
/*
* Look up the group leader (we will attach this event to it):
*/
@@ -11039,6 +11040,18 @@ SYSCALL_DEFINE5(perf_event_open,
move_group = 0;
}
}
+
+ /*
+ * Failure to create exclusive events returns -EBUSY.
+ */
+ err = -EBUSY;
+ if (!exclusive_event_installable(group_leader, ctx))
+ goto err_locked;
+
+ for_each_sibling_event(sibling, group_leader) {
+ if (!exclusive_event_installable(sibling, ctx))
+ goto err_locked;
+ }
} else {
mutex_lock(&ctx->mutex);
}
@@ -11075,9 +11088,6 @@ SYSCALL_DEFINE5(perf_event_open,
* because we need to serialize with concurrent event creation.
*/
if (!exclusive_event_installable(event, ctx)) {
- /* exclusive and group stuff are assumed mutually exclusive */
- WARN_ON_ONCE(move_group);
-
err = -EBUSY;
goto err_locked;
}
When fall-through warnings was enabled by default, d93512ef0f0e
("Makefile: Globally enable fall-through warning"), we could see the
following warnings was starting to show up. However, this was originally
introduced in commit 6ee33c2712fc ("ARM: hw_breakpoint: correct and
simplify alignment fixup code"). Commit d968d2b801d8 ("ARM: 7497/1:
hw_breakpoint: allow single-byte watchpoints on all addresses") was
written with the intent to allow single-byte watchpoints on all
addresses but forgot to move 'case 1:' down below 'case 2:'.
../arch/arm/kernel/hw_breakpoint.c: In function ‘hw_breakpoint_arch_parse’:
../arch/arm/kernel/hw_breakpoint.c:609:7: warning: this statement may fall
through [-Wimplicit-fallthrough=]
if (hw->ctrl.len == ARM_BREAKPOINT_LEN_2)
^
../arch/arm/kernel/hw_breakpoint.c:611:3: note: here
case 3:
^~~~
../arch/arm/kernel/hw_breakpoint.c:613:7: warning: this statement may fall
through [-Wimplicit-fallthrough=]
if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1)
^
../arch/arm/kernel/hw_breakpoint.c:615:3: note: here
default:
^~~~~~~
Rework so 'case 1:' are next to 'case 3:' and also add '/* Fall through
*/' so that the compiler doesn't warn about fall-through.
Cc: stable(a)vger.kernel.org # v3.16
Fixes: 6ee33c2712fc ("ARM: hw_breakpoint: correct and simplify alignment fixup code")
Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org>
---
arch/arm/kernel/hw_breakpoint.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index af8b8e15f589..c14d506969ba 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -603,15 +603,17 @@ int hw_breakpoint_arch_parse(struct perf_event *bp,
case 0:
/* Aligned */
break;
- case 1:
case 2:
/* Allow halfword watchpoints and breakpoints. */
if (hw->ctrl.len == ARM_BREAKPOINT_LEN_2)
break;
+ /* Fall through */
+ case 1:
case 3:
/* Allow single byte watchpoint. */
if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1)
break;
+ /* Fall through */
default:
ret = -EINVAL;
goto out;
--
2.20.1
The patch below was submitted to be applied to the 5.2-stable tree.
I fail to see how this patch meets the stable kernel rules as found at
Documentation/process/stable-kernel-rules.rst.
I could be totally wrong, and if so, please respond to
<stable(a)vger.kernel.org> and let me know why this patch should be
applied. Otherwise, it is now dropped from my patch queues, never to be
seen again.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 19ec11a2233d24a7811836fa735203aaccf95a23 Mon Sep 17 00:00:00 2001
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Date: Thu, 11 Jul 2019 10:29:35 +0200
Subject: [PATCH] gpio: em: remove the gpiochip before removing the irq domain
In commit 8764c4ca5049 ("gpio: em: use the managed version of
gpiochip_add_data()") we implicitly altered the ordering of resource
freeing: since gpiochip_remove() calls gpiochip_irqchip_remove()
internally, we now can potentially use the irq_domain after it was
destroyed in the remove() callback (as devm resources are freed after
remove() has returned).
Use devm_add_action_or_reset() to keep the ordering right and entirely
kill the remove() callback in the driver.
Reported-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Fixes: 8764c4ca5049 ("gpio: em: use the managed version of gpiochip_add_data()")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
diff --git a/drivers/gpio/gpio-em.c b/drivers/gpio/gpio-em.c
index b6af705a4e5f..a87951293aaa 100644
--- a/drivers/gpio/gpio-em.c
+++ b/drivers/gpio/gpio-em.c
@@ -259,6 +259,13 @@ static const struct irq_domain_ops em_gio_irq_domain_ops = {
.xlate = irq_domain_xlate_twocell,
};
+static void em_gio_irq_domain_remove(void *data)
+{
+ struct irq_domain *domain = data;
+
+ irq_domain_remove(domain);
+}
+
static int em_gio_probe(struct platform_device *pdev)
{
struct em_gio_priv *p;
@@ -333,39 +340,30 @@ static int em_gio_probe(struct platform_device *pdev)
return -ENXIO;
}
+ ret = devm_add_action_or_reset(&pdev->dev, em_gio_irq_domain_remove,
+ p->irq_domain);
+ if (ret)
+ return ret;
+
if (devm_request_irq(&pdev->dev, irq[0]->start,
em_gio_irq_handler, 0, name, p)) {
dev_err(&pdev->dev, "failed to request low IRQ\n");
- ret = -ENOENT;
- goto err1;
+ return -ENOENT;
}
if (devm_request_irq(&pdev->dev, irq[1]->start,
em_gio_irq_handler, 0, name, p)) {
dev_err(&pdev->dev, "failed to request high IRQ\n");
- ret = -ENOENT;
- goto err1;
+ return -ENOENT;
}
ret = devm_gpiochip_add_data(&pdev->dev, gpio_chip, p);
if (ret) {
dev_err(&pdev->dev, "failed to add GPIO controller\n");
- goto err1;
+ return ret;
}
return 0;
-
-err1:
- irq_domain_remove(p->irq_domain);
- return ret;
-}
-
-static int em_gio_remove(struct platform_device *pdev)
-{
- struct em_gio_priv *p = platform_get_drvdata(pdev);
-
- irq_domain_remove(p->irq_domain);
- return 0;
}
static const struct of_device_id em_gio_dt_ids[] = {
@@ -376,7 +374,6 @@ MODULE_DEVICE_TABLE(of, em_gio_dt_ids);
static struct platform_driver em_gio_device_driver = {
.probe = em_gio_probe,
- .remove = em_gio_remove,
.driver = {
.name = "em_gio",
.of_match_table = em_gio_dt_ids,
When fall-through warnings was enabled by default, commit d93512ef0f0e
("Makefile: Globally enable fall-through warning"), the following
warning was starting to show up:
../drivers/iommu/arm-smmu-v3.c: In function ‘arm_smmu_write_strtab_ent’:
../drivers/iommu/arm-smmu-v3.c:1189:7: warning: this statement may fall
through [-Wimplicit-fallthrough=]
if (disable_bypass)
^
../drivers/iommu/arm-smmu-v3.c:1191:3: note: here
default:
^~~~~~~
Rework so that the compiler doesn't warn about fall-through. Make it
clearer by calling 'BUG()' when disable_bypass is set, and always
'break;'
Cc: stable(a)vger.kernel.org # v4.2+
Fixes: 5bc0a11664e1 ("iommu/arm-smmu: Don't BUG() if we find aborting STEs with disable_bypass")
Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org>
---
drivers/iommu/arm-smmu-v3.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index a9a9fabd3968..8e5f0565996d 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1186,8 +1186,9 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
ste_live = true;
break;
case STRTAB_STE_0_CFG_ABORT:
- if (disable_bypass)
- break;
+ if (!disable_bypass)
+ BUG();
+ break;
default:
BUG(); /* STE corruption */
}
--
2.20.1
While I had thought I had fixed this issue in:
commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after
->fini()")
It turns out that while I did fix the error messages I was seeing on my
P50 when trying to access i2c busses with the GPU in runtime suspend, I
accidentally had missed one important detail that was mentioned on the
bug report this commit was supposed to fix: that the CPU would only lock
up when trying to access i2c busses _on connected devices_ _while the
GPU is not in runtime suspend_. Whoops. That definitely explains why I
was not able to get my machine to hang with i2c bus interactions until
now, as plugging my P50 into it's dock with an HDMI monitor connected
allowed me to finally reproduce this locally.
Now that I have managed to reproduce this issue properly, it looks like
the problem is much simpler then it looks. It turns out that some
connected devices, such as MST laptop docks, will actually ACK i2c reads
even if no data was actually read:
[ 275.063043] nouveau 0000:01:00.0: i2c: aux 000a: 1: 0000004c 1
[ 275.063447] nouveau 0000:01:00.0: i2c: aux 000a: 00 01101000 10040000
[ 275.063759] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000001
[ 275.064024] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
[ 275.064285] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
[ 275.064594] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
Because we don't handle the situation of i2c ack without any data, we
end up entering an infinite loop in nvkm_i2c_aux_i2c_xfer() since the
value of cnt always remains at 0. This finally properly explains how
this could result in a CPU hang like the ones observed in the
aforementioned commit.
So, fix this by retrying transactions if no data is written or received,
and give up and fail the transaction if we continue to not write or
receive any data after 32 retries.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 24 +++++++++++++------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
index b4e7404fe660..a11637b0f6cc 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c
@@ -40,8 +40,7 @@ nvkm_i2c_aux_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
u8 *ptr = msg->buf;
while (remaining) {
- u8 cnt = (remaining > 16) ? 16 : remaining;
- u8 cmd;
+ u8 cnt, retries, cmd;
if (msg->flags & I2C_M_RD)
cmd = 1;
@@ -51,10 +50,19 @@ nvkm_i2c_aux_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
if (mcnt || remaining > 16)
cmd |= 4; /* MOT */
- ret = aux->func->xfer(aux, true, cmd, msg->addr, ptr, &cnt);
- if (ret < 0) {
- nvkm_i2c_aux_release(aux);
- return ret;
+ for (retries = 0, cnt = 0;
+ retries < 32 && !cnt;
+ retries++) {
+ cnt = min_t(u8, remaining, 16);
+ ret = aux->func->xfer(aux, true, cmd,
+ msg->addr, ptr, &cnt);
+ if (ret < 0)
+ goto out;
+ }
+ if (!cnt) {
+ AUX_TRACE(aux, "no data after 32 retries");
+ ret = -EIO;
+ goto out;
}
ptr += cnt;
@@ -64,8 +72,10 @@ nvkm_i2c_aux_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
msg++;
}
+ ret = num;
+out:
nvkm_i2c_aux_release(aux);
- return num;
+ return ret;
}
static u32
--
2.21.0
The patch below does not apply to the 5.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From a3bf9fbdad600b1e4335dd90979f8d6072e4f602 Mon Sep 17 00:00:00 2001
From: Greg Kurz <groug(a)kaod.org>
Date: Wed, 15 May 2019 12:05:01 +0200
Subject: [PATCH] powerpc/pseries: Fix xive=off command line
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On POWER9, if the hypervisor supports XIVE exploitation mode, the
guest OS will unconditionally requests for the XIVE interrupt mode
even if XIVE was deactivated with the kernel command line xive=off.
Later on, when the spapr XIVE init code handles xive=off, it disables
XIVE and tries to fall back on the legacy mode XICS.
This discrepency causes a kernel panic because the hypervisor is
configured to provide the XIVE interrupt mode to the guest :
kernel BUG at arch/powerpc/sysdev/xics/xics-common.c:135!
...
NIP xics_smp_probe+0x38/0x98
LR xics_smp_probe+0x2c/0x98
Call Trace:
xics_smp_probe+0x2c/0x98 (unreliable)
pSeries_smp_probe+0x40/0xa0
smp_prepare_cpus+0x62c/0x6ec
kernel_init_freeable+0x148/0x448
kernel_init+0x2c/0x148
ret_from_kernel_thread+0x5c/0x68
Look for xive=off during prom_init and don't ask for XIVE in this
case. One exception though: if the host only supports XIVE, we still
want to boot so we ignore xive=off.
Similarly, have the spapr XIVE init code to looking at the interrupt
mode negotiated during CAS, and ignore xive=off if the hypervisor only
supports XIVE.
Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt controller")
Cc: stable(a)vger.kernel.org # v4.20
Reported-by: Pavithra R. Prakash <pavrampu(a)in.ibm.com>
Signed-off-by: Greg Kurz <groug(a)kaod.org>
Reviewed-by: Cédric Le Goater <clg(a)kaod.org>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index bab79c51ba4f..17f1ae7fae2c 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -172,6 +172,7 @@ static unsigned long __prombss prom_tce_alloc_end;
#ifdef CONFIG_PPC_PSERIES
static bool __prombss prom_radix_disable;
+static bool __prombss prom_xive_disable;
#endif
struct platform_support {
@@ -808,6 +809,12 @@ static void __init early_cmdline_parse(void)
}
if (prom_radix_disable)
prom_debug("Radix disabled from cmdline\n");
+
+ opt = prom_strstr(prom_cmd_line, "xive=off");
+ if (opt) {
+ prom_xive_disable = true;
+ prom_debug("XIVE disabled from cmdline\n");
+ }
#endif /* CONFIG_PPC_PSERIES */
}
@@ -1216,10 +1223,17 @@ static void __init prom_parse_xive_model(u8 val,
switch (val) {
case OV5_FEAT(OV5_XIVE_EITHER): /* Either Available */
prom_debug("XIVE - either mode supported\n");
- support->xive = true;
+ support->xive = !prom_xive_disable;
break;
case OV5_FEAT(OV5_XIVE_EXPLOIT): /* Only Exploitation mode */
prom_debug("XIVE - exploitation mode supported\n");
+ if (prom_xive_disable) {
+ /*
+ * If we __have__ to do XIVE, we're better off ignoring
+ * the command line rather than not booting.
+ */
+ prom_printf("WARNING: Ignoring cmdline option xive=off\n");
+ }
support->xive = true;
break;
case OV5_FEAT(OV5_XIVE_LEGACY): /* Only Legacy mode */
diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c
index 575db3b06a6b..2e2d1b8f810f 100644
--- a/arch/powerpc/sysdev/xive/spapr.c
+++ b/arch/powerpc/sysdev/xive/spapr.c
@@ -20,6 +20,7 @@
#include <linux/cpumask.h>
#include <linux/mm.h>
#include <linux/delay.h>
+#include <linux/libfdt.h>
#include <asm/prom.h>
#include <asm/io.h>
@@ -663,6 +664,55 @@ static bool xive_get_max_prio(u8 *max_prio)
return true;
}
+static const u8 *get_vec5_feature(unsigned int index)
+{
+ unsigned long root, chosen;
+ int size;
+ const u8 *vec5;
+
+ root = of_get_flat_dt_root();
+ chosen = of_get_flat_dt_subnode_by_name(root, "chosen");
+ if (chosen == -FDT_ERR_NOTFOUND)
+ return NULL;
+
+ vec5 = of_get_flat_dt_prop(chosen, "ibm,architecture-vec-5", &size);
+ if (!vec5)
+ return NULL;
+
+ if (size <= index)
+ return NULL;
+
+ return vec5 + index;
+}
+
+static bool xive_spapr_disabled(void)
+{
+ const u8 *vec5_xive;
+
+ vec5_xive = get_vec5_feature(OV5_INDX(OV5_XIVE_SUPPORT));
+ if (vec5_xive) {
+ u8 val;
+
+ val = *vec5_xive & OV5_FEAT(OV5_XIVE_SUPPORT);
+ switch (val) {
+ case OV5_FEAT(OV5_XIVE_EITHER):
+ case OV5_FEAT(OV5_XIVE_LEGACY):
+ break;
+ case OV5_FEAT(OV5_XIVE_EXPLOIT):
+ /* Hypervisor only supports XIVE */
+ if (xive_cmdline_disabled)
+ pr_warn("WARNING: Ignoring cmdline option xive=off\n");
+ return false;
+ default:
+ pr_warn("%s: Unknown xive support option: 0x%x\n",
+ __func__, val);
+ break;
+ }
+ }
+
+ return xive_cmdline_disabled;
+}
+
bool __init xive_spapr_init(void)
{
struct device_node *np;
@@ -675,7 +725,7 @@ bool __init xive_spapr_init(void)
const __be32 *reg;
int i;
- if (xive_cmdline_disabled)
+ if (xive_spapr_disabled())
return false;
pr_devel("%s()\n", __func__);
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: hantro: Set DMA max segment size
Author: Francois Buergisser <fbuergisser(a)chromium.org>
Date: Thu Jul 25 10:17:50 2019 -0400
The Hantro codec is typically used in platforms with an IOMMU,
so we need to set a proper DMA segment size. Devices without an
IOMMU will still fallback to default 64KiB segments.
Cc: stable(a)vger.kernel.org
Fixes: 775fec69008d3 ("media: add Rockchip VPU JPEG encoder driver")
Signed-off-by: Francois Buergisser <fbuergisser(a)chromium.org>
Signed-off-by: Ezequiel Garcia <ezequiel(a)collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org>
drivers/staging/media/hantro/hantro_drv.c | 1 +
1 file changed, 1 insertion(+)
---
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index b71a06e9159e..4eae1dbb1ac8 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -731,6 +731,7 @@ static int hantro_probe(struct platform_device *pdev)
dev_err(vpu->dev, "Could not set DMA coherent mask.\n");
return ret;
}
+ vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
for (i = 0; i < vpu->variant->num_irqs; i++) {
const char *irq_name = vpu->variant->irqs[i].name;
From: Francois Buergisser <fbuergisser(a)chromium.org>
The Hantro codec is typically used in platforms with an IOMMU,
so we need to set a proper DMA segment size. Devices without an
IOMMU will still fallback to default 64KiB segments.
Cc: stable(a)vger.kernel.org
Fixes: 775fec69008d3 ("media: add Rockchip VPU JPEG encoder driver")
Signed-off-by: Francois Buergisser <fbuergisser(a)chromium.org>
Signed-off-by: Ezequiel Garcia <ezequiel(a)collabora.com>
---
drivers/staging/media/hantro/hantro_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index b71a06e9159e..4eae1dbb1ac8 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -731,6 +731,7 @@ static int hantro_probe(struct platform_device *pdev)
dev_err(vpu->dev, "Could not set DMA coherent mask.\n");
return ret;
}
+ vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
for (i = 0; i < vpu->variant->num_irqs; i++) {
const char *irq_name = vpu->variant->irqs[i].name;
--
2.22.0
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
I don't know.
Maintainer did not respond, nor to original send nor to resend.
This is a note to let you know that I've just added the patch titled
hpet: Fix division by zero in hpet_time_div()
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 0c7d37f4d9b8446956e97b7c5e61173cdb7c8522 Mon Sep 17 00:00:00 2001
From: Kefeng Wang <wangkefeng.wang(a)huawei.com>
Date: Thu, 11 Jul 2019 21:27:57 +0800
Subject: hpet: Fix division by zero in hpet_time_div()
The base value in do_div() called by hpet_time_div() is truncated from
unsigned long to uint32_t, resulting in a divide-by-zero exception.
UBSAN: Undefined behaviour in ../drivers/char/hpet.c:572:2
division by zero
CPU: 1 PID: 23682 Comm: syz-executor.3 Not tainted 4.4.184.x86_64+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
0000000000000000 b573382df1853d00 ffff8800a3287b98 ffffffff81ad7561
ffff8800a3287c00 ffffffff838b35b0 ffffffff838b3860 ffff8800a3287c20
0000000000000000 ffff8800a3287bb0 ffffffff81b8f25e ffffffff838b35a0
Call Trace:
[<ffffffff81ad7561>] __dump_stack lib/dump_stack.c:15 [inline]
[<ffffffff81ad7561>] dump_stack+0xc1/0x120 lib/dump_stack.c:51
[<ffffffff81b8f25e>] ubsan_epilogue+0x12/0x8d lib/ubsan.c:166
[<ffffffff81b900cb>] __ubsan_handle_divrem_overflow+0x282/0x2c8 lib/ubsan.c:262
[<ffffffff823560dd>] hpet_time_div drivers/char/hpet.c:572 [inline]
[<ffffffff823560dd>] hpet_ioctl_common drivers/char/hpet.c:663 [inline]
[<ffffffff823560dd>] hpet_ioctl_common.cold+0xa8/0xad drivers/char/hpet.c:577
[<ffffffff81e63d56>] hpet_ioctl+0xc6/0x180 drivers/char/hpet.c:676
[<ffffffff81711590>] vfs_ioctl fs/ioctl.c:43 [inline]
[<ffffffff81711590>] file_ioctl fs/ioctl.c:470 [inline]
[<ffffffff81711590>] do_vfs_ioctl+0x6e0/0xf70 fs/ioctl.c:605
[<ffffffff81711eb4>] SYSC_ioctl fs/ioctl.c:622 [inline]
[<ffffffff81711eb4>] SyS_ioctl+0x94/0xc0 fs/ioctl.c:613
[<ffffffff82846003>] tracesys_phase2+0x90/0x95
The main C reproducer autogenerated by syzkaller,
syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
memcpy((void*)0x20000100, "/dev/hpet\000", 10);
syscall(__NR_openat, 0xffffffffffffff9c, 0x20000100, 0, 0);
syscall(__NR_ioctl, r[0], 0x40086806, 0x40000000000000);
Fix it by using div64_ul().
Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com>
Signed-off-by: Zhang HongJun <zhanghongjun2(a)huawei.com>
Cc: stable <stable(a)vger.kernel.org>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
Link: https://lore.kernel.org/r/20190711132757.130092-1-wangkefeng.wang@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/hpet.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 5c39f20378b8..9ac6671bb514 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -567,8 +567,7 @@ static inline unsigned long hpet_time_div(struct hpets *hpets,
unsigned long long m;
m = hpets->hp_tick_freq + (dis >> 1);
- do_div(m, dis);
- return (unsigned long)m;
+ return div64_ul(m, dis);
}
static int
--
2.22.0
In Resize BAR control register, bits[8:12] represents size of BAR.
As per PCIe specification, below is encoded values in register bits
to actual BAR size table:
Bits BAR size
0 1 MB
1 2 MB
2 4 MB
3 8 MB
--
For 1 MB BAR size, BAR size bits should be set to 0 but incorrectly
these bits are set to "1f".
Latest megaraid_sas and mpt3sas adapters which support Resizable BAR
with 1 MB BAR size fails to initialize during system resume from S3 sleep.
Fix: Correctly set BAR size bits to "0" for 1MB BAR size.
CC: stable(a)vger.kernel.org # v4.16+
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203939
Fixes: d3252ace0bc652a1a244455556b6a549f969bf99 ("PCI: Restore resized BAR state on resume")
Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com>
---
drivers/pci/pci.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8abc843..b651f32 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1417,12 +1417,13 @@ static void pci_restore_rebar_state(struct pci_dev *pdev)
for (i = 0; i < nbars; i++, pos += 8) {
struct resource *res;
- int bar_idx, size;
+ int bar_idx, size, order;
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX;
res = pdev->resource + bar_idx;
- size = order_base_2((resource_size(res) >> 20) | 1) - 1;
+ order = order_base_2((resource_size(res) >> 20) | 1);
+ size = order ? order - 1 : 0;
ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE;
ctrl |= size << PCI_REBAR_CTRL_BAR_SHIFT;
pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
--
1.8.3.1
This is a note to let you know that I've just added the patch titled
staging: android: ion: Bail out upon SIGKILL when allocating memory.
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 8f9e86ee795971eabbf372e6d804d6b8578287a7 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Date: Mon, 1 Jul 2019 19:55:19 +0900
Subject: staging: android: ion: Bail out upon SIGKILL when allocating memory.
syzbot found that a thread can stall for minutes inside
ion_system_heap_allocate() after that thread was killed by SIGKILL [1].
Let's check for SIGKILL before doing memory allocation.
[1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f…
Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: stable <stable(a)vger.kernel.org>
Reported-by: syzbot <syzbot+8ab2d0f39fb79fe6ca40(a)syzkaller.appspotmail.com>
Acked-by: Laura Abbott <labbott(a)redhat.com>
Acked-by: Sumit Semwal <sumit.semwal(a)linaro.org>
Link: https://lore.kernel.org/r/d088f188-5f32-d8fc-b9a0-0b404f7501cc@I-love.SAKUR…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ion/ion_page_pool.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c
index fd4995fb676e..f85ec5b16b65 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -8,11 +8,14 @@
#include <linux/list.h>
#include <linux/slab.h>
#include <linux/swap.h>
+#include <linux/sched/signal.h>
#include "ion.h"
static inline struct page *ion_page_pool_alloc_pages(struct ion_page_pool *pool)
{
+ if (fatal_signal_pending(current))
+ return NULL;
return alloc_pages(pool->gfp_mask, pool->order);
}
--
2.22.0
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: vivid: fix device init when no_error_inj=1 and fb disabled
Author: Guillaume Tucker <guillaume.tucker(a)collabora.com>
Date: Wed Jul 24 11:19:22 2019 -0400
Add an extra condition to add the video output control class when the
device has some hdmi outputs defined. This is required to then always
be able to add the display present control, which is enabled when
there are some hdmi outputs.
This fixes the corner case where no_error_inj is enabled and the
device has no frame buffer but some hdmi outputs, as otherwise the
video output control class would be added anyway. Without this fix,
the sanity checks fail in v4l2_ctrl_new() as name is NULL.
Fixes: c533435ffb91 ("media: vivid: add display present control")
Cc: stable(a)vger.kernel.org # for 5.3
Signed-off-by: Guillaume Tucker <guillaume.tucker(a)collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org>
drivers/media/platform/vivid/vivid-ctrls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/drivers/media/platform/vivid/vivid-ctrls.c b/drivers/media/platform/vivid/vivid-ctrls.c
index fb9220e4e640..cb19a9a73092 100644
--- a/drivers/media/platform/vivid/vivid-ctrls.c
+++ b/drivers/media/platform/vivid/vivid-ctrls.c
@@ -1473,7 +1473,7 @@ int vivid_create_controls(struct vivid_dev *dev, bool show_ccs_cap,
v4l2_ctrl_handler_init(hdl_vid_cap, 55);
v4l2_ctrl_new_custom(hdl_vid_cap, &vivid_ctrl_class, NULL);
v4l2_ctrl_handler_init(hdl_vid_out, 26);
- if (!no_error_inj || dev->has_fb)
+ if (!no_error_inj || dev->has_fb || dev->num_hdmi_outputs)
v4l2_ctrl_new_custom(hdl_vid_out, &vivid_ctrl_class, NULL);
v4l2_ctrl_handler_init(hdl_vbi_cap, 21);
v4l2_ctrl_new_custom(hdl_vbi_cap, &vivid_ctrl_class, NULL);
Hello,
First, thank you for maintaining the stable branches!
When testing our MPTCP out-of-tree kernel[1] with KASAN last week-end,
we saw some new warnings, always the same trace and looking like that:
[ 16.464577] ==================================================================
[ 16.465448] BUG: KASAN: slab-out-of-bounds in strscpy+0x49d/0x590
[ 16.466171] Read of size 8 at addr ffff88803525f788 by task confd/330
[ 16.467114]
[ 16.467313] CPU: 0 PID: 330 Comm: confd Not tainted 4.14.133-mptcp+ #2
[ 16.468071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
[ 16.469016] Call Trace:
[ 16.469318] dump_stack+0xa6/0x12e
[ 16.469721] ? _atomic_dec_and_lock+0x1b2/0x1b2
[ 16.470255] ? radix_tree_lookup+0x10/0x10
[ 16.470764] ? strscpy+0x49d/0x590
[ 16.471299] print_address_description+0xa1/0x330
[ 16.471918] ? strscpy+0x49d/0x590
[ 16.472321] kasan_report+0x23f/0x350
[ 16.472751] strscpy+0x49d/0x590
[ 16.473135] ? strncpy+0xd0/0xd0
[ 16.473518] p9dirent_read+0x26b/0x510
[ 16.473977] ? unwind_next_frame+0xc97/0x1eb0
[ 16.474481] ? p9stat_read+0x440/0x440
[ 16.474945] ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 16.475543] ? rcutorture_record_progress+0x10/0x10
[ 16.476123] ? kernel_text_address+0x111/0x120
[ 16.476656] ? __kernel_text_address+0xe/0x30
[ 16.477273] v9fs_dir_readdir_dotl+0x340/0x5b0
[ 16.477900] ? kasan_slab_free+0x12d/0x1a0
[ 16.478377] ? v9fs_dir_readdir+0x810/0x810
[ 16.478887] ? new_slab+0x29f/0x3b0
[ 16.479298] ? iterate_fd+0x300/0x300
[ 16.479728] ? do_filp_open+0x24a/0x3b0
[ 16.480177] ? SyS_getcwd+0x3b7/0x9f0
[ 16.480626] ? may_open_dev+0xc0/0xc0
[ 16.481056] ? get_unused_fd_flags+0x180/0x180
[ 16.481643] ? __up.isra.0+0x230/0x230
[ 16.482195] ? __fdget_pos+0x105/0x170
[ 16.482658] ? iterate_dir+0x171/0x5b0
[ 16.483097] iterate_dir+0x171/0x5b0
[ 16.483518] SyS_getdents+0x1dc/0x3a0
[ 16.483968] ? SyS_old_readdir+0x200/0x200
[ 16.484444] ? SyS_write+0x1c0/0x270
[ 16.484875] ? fillonedir+0x1a0/0x1a0
[ 16.485315] ? SyS_old_readdir+0x200/0x200
[ 16.485791] ? do_syscall_64+0x259/0xa90
[ 16.486258] do_syscall_64+0x259/0xa90
[ 16.486715] ? syscall_return_slowpath+0x340/0x340
[ 16.487320] ? do_page_fault+0x11f/0x400
[ 16.487849] ? __do_page_fault+0xe00/0xe00
[ 16.488305] ? __hrtick_start+0x2f0/0x2f0
[ 16.488752] ? __switch_to_asm+0x31/0x60
[ 16.489189] ? __switch_to_asm+0x31/0x60
[ 16.489626] ? __switch_to_asm+0x25/0x60
[ 16.490063] ? __switch_to_asm+0x31/0x60
[ 16.490500] ? __switch_to_asm+0x31/0x60
[ 16.490940] ? __switch_to_asm+0x31/0x60
[ 16.491377] ? __switch_to_asm+0x25/0x60
[ 16.491820] ? __switch_to_asm+0x31/0x60
[ 16.492305] ? __switch_to_asm+0x31/0x60
[ 16.492769] ? __switch_to_asm+0x31/0x60
[ 16.493306] ? __switch_to_asm+0x31/0x60
[ 16.493917] ? __switch_to_asm+0x31/0x60
[ 16.494402] ? __switch_to_asm+0x25/0x60
[ 16.494859] ? __switch_to_asm+0x31/0x60
[ 16.495344] ? __switch_to_asm+0x31/0x60
[ 16.495798] ? __switch_to_asm+0x31/0x60
[ 16.496283] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 16.496885] RIP: 0033:0x7f0bd5b26855
[ 16.497313] RSP: 002b:00007f0bd69d4d60 EFLAGS: 00000246 ORIG_RAX: 000000000000004e
[ 16.498387] RAX: ffffffffffffffda RBX: 00007f0bb800a910 RCX: 00007f0bd5b26855
[ 16.499221] RDX: 0000000000008000 RSI: 00007f0bb800a910 RDI: 000000000000002c
[ 16.500102] RBP: 00007f0bb800a910 R08: 00007f0bd69d4e10 R09: 0000000000008030
[ 16.500942] R10: 0000000000000076 R11: 0000000000000246 R12: ffffffffffffff70
[ 16.501780] R13: 0000000000000002 R14: 00007f0bb80008d0 R15: 000000000129cb44
[ 16.502641]
[ 16.502819] Allocated by task 330:
[ 16.503230] kasan_kmalloc+0xe4/0x170
[ 16.503799] __kmalloc+0xdd/0x1c0
[ 16.504259] p9pdu_readf+0xbb8/0x2940
[ 16.504707] p9dirent_read+0x174/0x510
[ 16.505154] v9fs_dir_readdir_dotl+0x340/0x5b0
[ 16.505694] iterate_dir+0x171/0x5b0
[ 16.506122] SyS_getdents+0x1dc/0x3a0
[ 16.506573] do_syscall_64+0x259/0xa90
[ 16.507031] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 16.507633]
[ 16.507804] Freed by task 322:
[ 16.508178] kasan_slab_free+0xac/0x1a0
[ 16.508741] kfree+0xcd/0x1e0
[ 16.509194] p9stat_free+0x32/0x200
[ 16.509633] v9fs_vfs_get_link+0x173/0x230
[ 16.510118] ovl_get_link+0x52/0x80
[ 16.510538] trailing_symlink+0x42c/0x5f0
[ 16.511034] path_lookupat+0x1b4/0xc30
[ 16.511481] filename_lookup+0x237/0x470
[ 16.511955] vfs_statx+0xb0/0x120
[ 16.512358] SyS_newstat+0x70/0xc0
[ 16.512759] do_syscall_64+0x259/0xa90
[ 16.513205] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 16.513807]
[ 16.514041] The buggy address belongs to the object at ffff88803525f780
[ 16.514041] which belongs to the cache kmalloc-16 of size 16
[ 16.515645] The buggy address is located 8 bytes inside of
[ 16.515645] 16-byte region [ffff88803525f780, ffff88803525f790)
[ 16.516997] The buggy address belongs to the page:
[ 16.517563] page:ffff88803f5407c0 count:1 mapcount:0 mapping: (null) index:0x0
[ 16.518504] flags: 0xc80000000100(slab)
[ 16.519103] raw: 0000c80000000100 0000000000000000 0000000000000000 0000000180800080
[ 16.520066] raw: ffff88803f4fa900 0000000800000008 ffff888035c01b40 0000000000000000
[ 16.520981] page dumped because: kasan: bad access detected
[ 16.521647]
[ 16.521818] Memory state around the buggy address:
[ 16.522413] ffff88803525f680: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
[ 16.523258] ffff88803525f700: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
[ 16.524118] >ffff88803525f780: 00 02 fc fc fb fb fc fc fb fb fc fc fb fb fc fc
[ 16.525093] ^
[ 16.525591] ffff88803525f800: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
[ 16.526471] ffff88803525f880: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
[ 16.527323] ==================================================================
We are running tests in different KVMs and using 9P for the root RO
partition and others for a shared file system between VMs and the host:
mount -t 9p outshare "${MOUNT_DIR}/overlay/out" -o trans=virtio,version=9p2000.L,access=0,rw
Our out-of-tree kernel does not modify the FS part, nor net/9p.
With Dominique from v9fs project, we analysed the issue[2]. At the end,
it is confirmed that this KASAN warning is not related to our MPTCP
modifications but due to a recent change in the v4.14 stable branch:
84693d060965 (9p: p9dirent_read: check network-provided name length).
In this change backported by Sasha, strcpy() has been replaced by
strscpy(). This is known to cause KASAN false-positives, see:
1a3241ff10d0 (lib/strscpy: Shut up KASAN false-positives in strscpy()).
Note that this commit depends on the two parent ones.
Could it then be possible to also backport these three commits please?
The three commits apply without any issues. I followed the documention
to propose these three commits to stable, the Option 3.
Just for me for next time: is it easier for you to propose the patches
like I did or to only mention the SHA from Linus GIT tree?
- 1a3241ff10d0 (lib/strscpy: Shut up KASAN false-positives in strscpy())
- 7f1e541fc8d5 (compiler.h: Add read_word_at_a_time() function.)
- bdb5ac801af3 (compiler.h, kasan: Avoid duplicating __read_once_size_nocheck())
Cheers,
Matt
[1] https://github.com/multipath-tcp/mptcp/
[2] https://sourceforge.net/p/v9fs/mailman/message/36718122/
Andrey Ryabinin (3):
compiler.h, kasan: Avoid duplicating __read_once_size_nocheck()
compiler.h: Add read_word_at_a_time() function.
lib/strscpy: Shut up KASAN false-positives in strscpy()
include/linux/compiler.h | 22 ++++++++++++++--------
lib/string.c | 2 +-
2 files changed, 15 insertions(+), 9 deletions(-)
Cc: Dominique Martinet <asmadeus(a)codewreck.org>
Cc: Sasha Levin <sashal(a)kernel.org>
--
2.20.1
A second regression was found in the immediate data transfer (IDT)
support which was added to 5.2 kernel
IDT is used to transfer small amounts of data (up to 8 bytes) in the
field normally used for data dma address, thus avoiding dma mapping.
If the data was not already dma mapped, then IDT support assumed data was
in urb->transfer_buffer, and did not take into accound that even
small amounts of data (8 bytes) can be in a scatterlist instead.
This caused a NULL pointer dereference when sg_dma_len() was used
with non-dma mapped data.
Solve this by not using IDT if scatter gather buffer list is used.
Fixes: 33e39350ebd2 ("usb: xhci: add Immediate Data Transfer support")
Cc: <stable(a)vger.kernel.org> # v5.2
Reported-by: Maik Stohn <maik.stohn(a)seal-one.com>
Tested-by: Maik Stohn <maik.stohn(a)seal-one.com>
CC: Nicolas Saenz Julienne <nsaenzjulienne(a)suse.de>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
---
drivers/usb/host/xhci.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 7a26496..f5c4144 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -2175,7 +2175,8 @@ static inline bool xhci_urb_suitable_for_idt(struct urb *urb)
if (!usb_endpoint_xfer_isoc(&urb->ep->desc) && usb_urb_dir_out(urb) &&
usb_endpoint_maxp(&urb->ep->desc) >= TRB_IDT_MAX_SIZE &&
urb->transfer_buffer_length <= TRB_IDT_MAX_SIZE &&
- !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP))
+ !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) &&
+ !urb->num_sgs)
return true;
return false;
--
2.7.4
This is a note to let you know that I've just added the patch titled
usb: wusbcore: fix unbalanced get/put cluster_id
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From f90bf1ece48a736097ea224430578fe586a9544c Mon Sep 17 00:00:00 2001
From: Phong Tran <tranmanphong(a)gmail.com>
Date: Wed, 24 Jul 2019 09:06:01 +0700
Subject: usb: wusbcore: fix unbalanced get/put cluster_id
syzboot reported that
https://syzkaller.appspot.com/bug?extid=fd2bd7df88c606eea4ef
There is not consitency parameter in cluste_id_get/put calling.
In case of getting the id with result is failure, the wusbhc->cluster_id
will not be updated and this can not be used for wusb_cluster_id_put().
Tested report
https://groups.google.com/d/msg/syzkaller-bugs/0znZopp3-9k/oxOrhLkLEgAJ
Reproduce and gdb got the details:
139 addr = wusb_cluster_id_get();
(gdb) n
140 if (addr == 0)
(gdb) print addr
$1 = 254 '\376'
(gdb) n
142 result = __hwahc_set_cluster_id(hwahc, addr);
(gdb) print result
$2 = -71
(gdb) break wusb_cluster_id_put
Breakpoint 3 at 0xffffffff836e3f20: file drivers/usb/wusbcore/wusbhc.c, line 384.
(gdb) s
Thread 2 hit Breakpoint 3, wusb_cluster_id_put (id=0 '\000') at drivers/usb/wusbcore/wusbhc.c:384
384 id = 0xff - id;
(gdb) n
385 BUG_ON(id >= CLUSTER_IDS);
(gdb) print id
$3 = 255 '\377'
Reported-by: syzbot+fd2bd7df88c606eea4ef(a)syzkaller.appspotmail.com
Signed-off-by: Phong Tran <tranmanphong(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20190724020601.15257-1-tranmanphong@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/hwa-hc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/hwa-hc.c b/drivers/usb/host/hwa-hc.c
index 09a8ebd95588..6968b9f2b76b 100644
--- a/drivers/usb/host/hwa-hc.c
+++ b/drivers/usb/host/hwa-hc.c
@@ -159,7 +159,7 @@ static int hwahc_op_start(struct usb_hcd *usb_hcd)
return result;
error_set_cluster_id:
- wusb_cluster_id_put(wusbhc->cluster_id);
+ wusb_cluster_id_put(addr);
error_cluster_id_get:
goto out;
--
2.22.0
This is a note to let you know that I've just added the patch titled
usb-storage: Add a limitation for blk_queue_max_hw_sectors()
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From d74ffae8b8dd17eaa8b82fc163e6aa2076dc8fb1 Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Mon, 22 Jul 2019 19:58:25 +0900
Subject: usb-storage: Add a limitation for blk_queue_max_hw_sectors()
This patch fixes an issue that the following error happens on
swiotlb environment:
xhci-hcd ee000000.usb: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 1338 (slots)
On the kernel v5.1, block settings of a usb-storage with SuperSpeed
were the following so that the block layer will allocate buffers
up to 64 KiB, and then the issue didn't happen.
max_segment_size = 65536
max_hw_sectors_kb = 1024
After the commit 09324d32d2a0 ("block: force an unlimited segment
size on queues with a virt boundary") is applied, the block settings
are the following. So, the block layer will allocate buffers up to
1024 KiB, and then the issue happens:
max_segment_size = 4294967295
max_hw_sectors_kb = 1024
To fix the issue, the usb-storage driver checks the maximum size of
a mapping for the device and then adjusts the max_hw_sectors_kb
if required. After this patch is applied, the block settings will
be the following, and then the issue doesn't happen.
max_segment_size = 4294967295
max_hw_sectors_kb = 256
Fixes: 09324d32d2a0 ("block: force an unlimited segment size on queues with a virt boundary")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Link: https://lore.kernel.org/r/1563793105-20597-1-git-send-email-yoshihiro.shimo…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/scsiglue.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 30790240aec6..05b80211290d 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -28,6 +28,8 @@
* status of a command.
*/
+#include <linux/blkdev.h>
+#include <linux/dma-mapping.h>
#include <linux/module.h>
#include <linux/mutex.h>
@@ -99,6 +101,7 @@ static int slave_alloc (struct scsi_device *sdev)
static int slave_configure(struct scsi_device *sdev)
{
struct us_data *us = host_to_us(sdev->host);
+ struct device *dev = us->pusb_dev->bus->sysdev;
/*
* Many devices have trouble transferring more than 32KB at a time,
@@ -128,6 +131,14 @@ static int slave_configure(struct scsi_device *sdev)
blk_queue_max_hw_sectors(sdev->request_queue, 2048);
}
+ /*
+ * The max_hw_sectors should be up to maximum size of a mapping for
+ * the device. Otherwise, a DMA API might fail on swiotlb environment.
+ */
+ blk_queue_max_hw_sectors(sdev->request_queue,
+ min_t(size_t, queue_max_hw_sectors(sdev->request_queue),
+ dma_max_mapping_size(dev) >> SECTOR_SHIFT));
+
/*
* Some USB host controllers can't do DMA; they have to use PIO.
* They indicate this by setting their dma_mask to NULL. For
--
2.22.0
This is a note to let you know that I've just added the patch titled
usb: pci-quirks: Correct AMD PLL quirk detection
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From f3dccdaade4118070a3a47bef6b18321431f9ac6 Mon Sep 17 00:00:00 2001
From: Ryan Kennedy <ryan5544(a)gmail.com>
Date: Thu, 4 Jul 2019 11:35:28 -0400
Subject: usb: pci-quirks: Correct AMD PLL quirk detection
The AMD PLL USB quirk is incorrectly enabled on newer Ryzen
chipsets. The logic in usb_amd_find_chipset_info currently checks
for unaffected chipsets rather than affected ones. This broke
once a new chipset was added in e788787ef. It makes more sense
to reverse the logic so it won't need to be updated as new
chipsets are added. Note that the core of the workaround in
usb_amd_quirk_pll does correctly check the chipset.
Signed-off-by: Ryan Kennedy <ryan5544(a)gmail.com>
Fixes: e788787ef4f9 ("usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume")
Cc: stable <stable(a)vger.kernel.org>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Link: https://lore.kernel.org/r/20190704153529.9429-2-ryan5544@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/pci-quirks.c | 31 +++++++++++++++++++------------
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 3ce71cbfbb58..ad05c27b3a7b 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -205,7 +205,7 @@ int usb_amd_find_chipset_info(void)
{
unsigned long flags;
struct amd_chipset_info info;
- int ret;
+ int need_pll_quirk = 0;
spin_lock_irqsave(&amd_lock, flags);
@@ -219,21 +219,28 @@ int usb_amd_find_chipset_info(void)
spin_unlock_irqrestore(&amd_lock, flags);
if (!amd_chipset_sb_type_init(&info)) {
- ret = 0;
goto commit;
}
- /* Below chipset generations needn't enable AMD PLL quirk */
- if (info.sb_type.gen == AMD_CHIPSET_UNKNOWN ||
- info.sb_type.gen == AMD_CHIPSET_SB600 ||
- info.sb_type.gen == AMD_CHIPSET_YANGTZE ||
- (info.sb_type.gen == AMD_CHIPSET_SB700 &&
- info.sb_type.rev > 0x3b)) {
+ switch (info.sb_type.gen) {
+ case AMD_CHIPSET_SB700:
+ need_pll_quirk = info.sb_type.rev <= 0x3B;
+ break;
+ case AMD_CHIPSET_SB800:
+ case AMD_CHIPSET_HUDSON2:
+ case AMD_CHIPSET_BOLTON:
+ need_pll_quirk = 1;
+ break;
+ default:
+ need_pll_quirk = 0;
+ break;
+ }
+
+ if (!need_pll_quirk) {
if (info.smbus_dev) {
pci_dev_put(info.smbus_dev);
info.smbus_dev = NULL;
}
- ret = 0;
goto commit;
}
@@ -252,7 +259,7 @@ int usb_amd_find_chipset_info(void)
}
}
- ret = info.probe_result = 1;
+ need_pll_quirk = info.probe_result = 1;
printk(KERN_DEBUG "QUIRK: Enable AMD PLL fix\n");
commit:
@@ -263,7 +270,7 @@ int usb_amd_find_chipset_info(void)
/* Mark that we where here */
amd_chipset.probe_count++;
- ret = amd_chipset.probe_result;
+ need_pll_quirk = amd_chipset.probe_result;
spin_unlock_irqrestore(&amd_lock, flags);
@@ -277,7 +284,7 @@ int usb_amd_find_chipset_info(void)
spin_unlock_irqrestore(&amd_lock, flags);
}
- return ret;
+ return need_pll_quirk;
}
EXPORT_SYMBOL_GPL(usb_amd_find_chipset_info);
--
2.22.0
Add an extra condition to add the video output control class when the
device has some hdmi outputs defined. This is required to then always
be able to add the display present control, which is enabled when
there are some hdmi outputs.
This fixes the corner case where no_error_inj is enabled and the
device has no frame buffer but some hdmi outputs, as otherwise the
video output control class would be added anyway. Without this fix,
the sanity checks fail in v4l2_ctrl_new() as name is NULL.
Fixes: c533435ffb91 ("media: vivid: add display present control")
Cc: stable(a)vger.kernel.org
Signed-off-by: Guillaume Tucker <guillaume.tucker(a)collabora.com>
---
drivers/media/platform/vivid/vivid-ctrls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/vivid/vivid-ctrls.c b/drivers/media/platform/vivid/vivid-ctrls.c
index 3e916c8befb7..7a52f585cab7 100644
--- a/drivers/media/platform/vivid/vivid-ctrls.c
+++ b/drivers/media/platform/vivid/vivid-ctrls.c
@@ -1473,7 +1473,7 @@ int vivid_create_controls(struct vivid_dev *dev, bool show_ccs_cap,
v4l2_ctrl_handler_init(hdl_vid_cap, 55);
v4l2_ctrl_new_custom(hdl_vid_cap, &vivid_ctrl_class, NULL);
v4l2_ctrl_handler_init(hdl_vid_out, 26);
- if (!no_error_inj || dev->has_fb)
+ if (!no_error_inj || dev->has_fb || dev->num_hdmi_outputs)
v4l2_ctrl_new_custom(hdl_vid_out, &vivid_ctrl_class, NULL);
v4l2_ctrl_handler_init(hdl_vbi_cap, 21);
v4l2_ctrl_new_custom(hdl_vbi_cap, &vivid_ctrl_class, NULL);
--
2.20.1
This is a note to let you know that I've just added the patch titled
staging: wilc1000: flush the workqueue before deinit the host
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From fb2b055b7e6e44efda737c7c92f46c0868bb04e5 Mon Sep 17 00:00:00 2001
From: Adham Abozaeid <adham.abozaeid(a)microchip.com>
Date: Mon, 22 Jul 2019 21:38:44 +0000
Subject: staging: wilc1000: flush the workqueue before deinit the host
Before deinitializing the host interface, the workqueue should be flushed
to handle any pending deferred work
Signed-off-by: Adham Abozaeid <adham.abozaeid(a)microchip.com>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20190722213837.21952-1-adham.abozaeid@microchip.c…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index d72fdd333050..736eedef23b6 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1969,6 +1969,7 @@ void wilc_deinit_host_int(struct net_device *net)
priv->p2p_listen_state = false;
+ flush_workqueue(vif->wilc->hif_workqueue);
mutex_destroy(&priv->scan_req_lock);
ret = wilc_deinit(vif);
--
2.22.0