2020-07-07 15:21:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 00/36] 4.19.132-rc1 review

This is the start of the stable review cycle for the 4.19.132 release.
There are 36 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 Thu, 09 Jul 2020 14:57:34 +0000.
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.132-rc1.gz
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 <[email protected]>
Linux 4.19.132-rc1

Peter Jones <[email protected]>
efi: Make it possible to disable efivar_ssdt entirely

Hou Tao <[email protected]>
dm zoned: assign max_io_len correctly

Marc Zyngier <[email protected]>
irqchip/gic: Atomically update affinity

Hauke Mehrtens <[email protected]>
MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen

Zhang Xiaoxu <[email protected]>
cifs: Fix the target file was deleted when rename failed.

Paul Aurich <[email protected]>
SMB3: Honor lease disabling for multiuser mounts

Paul Aurich <[email protected]>
SMB3: Honor persistent/resilient handle flags for multiuser mounts

Paul Aurich <[email protected]>
SMB3: Honor 'seal' flag for multiuser mounts

Greg Kroah-Hartman <[email protected]>
Revert "ALSA: usb-audio: Improve frames size computation"

J. Bruce Fields <[email protected]>
nfsd: apply umask on fs without ACL support

Wolfram Sang <[email protected]>
i2c: mlxcpld: check correct size of maximum RECV_LEN packet

Chris Packham <[email protected]>
i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665

Christoph Hellwig <[email protected]>
nvme: fix a crash in nvme_mpath_add_disk

Paul Aurich <[email protected]>
SMB3: Honor 'posix' flag for multiuser mounts

Hou Tao <[email protected]>
virtio-blk: free vblk-vqs in error path of virtblk_probe()

Chen-Yu Tsai <[email protected]>
drm: sun4i: hdmi: Remove extra HPD polling

Misono Tomohiro <[email protected]>
hwmon: (acpi_power_meter) Fix potential memory leak in acpi_power_meter_add()

Chu Lin <[email protected]>
hwmon: (max6697) Make sure the OVERT mask is set correctly

Rahul Lakkireddy <[email protected]>
cxgb4: fix SGE queue dump destination buffer context

Rahul Lakkireddy <[email protected]>
cxgb4: use correct type for all-mask IP address comparison

Rahul Lakkireddy <[email protected]>
cxgb4: parse TC-U32 key values and masks natively

Rahul Lakkireddy <[email protected]>
cxgb4: use unaligned conversion for fetching timestamp

Chen Tao <[email protected]>
drm/msm/dpu: fix error return code in dpu_encoder_init

Herbert Xu <[email protected]>
crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()

Douglas Anderson <[email protected]>
kgdb: Avoid suspicious RCU usage warning

Anton Eidelman <[email protected]>
nvme-multipath: fix deadlock between ana_work and scan_work

Sagi Grimberg <[email protected]>
nvme: fix possible deadlock when I/O is blocked

Keith Busch <[email protected]>
nvme-multipath: set bdi capabilities once

Christian Borntraeger <[email protected]>
s390/debug: avoid kernel warning on too large number of pages

Zqiang <[email protected]>
usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect

Qian Cai <[email protected]>
mm/slub: fix stack overruns with SLUB_STATS

Dongli Zhang <[email protected]>
mm/slub.c: fix corrupted freechain in deactivate_slab()

Tuomas Tynkkynen <[email protected]>
usbnet: smsc95xx: Fix use-after-free after removal

Borislav Petkov <[email protected]>
EDAC/amd64: Read back the scrub rate PCI register on F15h

Hugh Dickins <[email protected]>
mm: fix swap cache node allocation mask

Filipe Manana <[email protected]>
btrfs: fix a block group ref counter leak after failure to remove block group


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

Diffstat:

Makefile | 4 +-
arch/mips/kernel/traps.c | 1 +
arch/s390/kernel/debug.c | 3 +-
crypto/af_alg.c | 26 ++---
crypto/algif_aead.c | 9 +-
crypto/algif_hash.c | 9 +-
crypto/algif_skcipher.c | 9 +-
drivers/block/virtio_blk.c | 1 +
drivers/edac/amd64_edac.c | 2 +
drivers/firmware/efi/Kconfig | 11 ++
drivers/firmware/efi/efi.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 5 +-
drivers/hwmon/acpi_power_meter.c | 4 +-
drivers/hwmon/max6697.c | 7 +-
drivers/i2c/algos/i2c-algo-pca.c | 3 +-
drivers/i2c/busses/i2c-mlxcpld.c | 4 +-
drivers/irqchip/irq-gic.c | 14 +--
drivers/md/dm-zoned-target.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c | 6 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 10 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c | 18 +--
.../ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h | 122 ++++++++++++++-------
drivers/net/ethernet/chelsio/cxgb4/sge.c | 2 +-
drivers/net/usb/smsc95xx.c | 2 +-
drivers/nvme/host/core.c | 1 -
drivers/nvme/host/multipath.c | 33 ++++--
drivers/usb/misc/usbtest.c | 1 +
fs/btrfs/extent-tree.c | 19 ++--
fs/cifs/connect.c | 9 +-
fs/cifs/inode.c | 10 +-
fs/nfsd/vfs.c | 6 +
include/crypto/if_alg.h | 4 +-
kernel/debug/debug_core.c | 4 +
mm/slub.c | 30 ++++-
mm/swap_state.c | 3 +-
sound/usb/card.h | 4 -
sound/usb/endpoint.c | 43 +-------
sound/usb/endpoint.h | 1 -
sound/usb/pcm.c | 2 -
40 files changed, 256 insertions(+), 192 deletions(-)



2020-07-07 15:22:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 15/36] cxgb4: use unaligned conversion for fetching timestamp

From: Rahul Lakkireddy <[email protected]>

[ Upstream commit 589b1c9c166dce120e27b32a83a78f55464a7ef9 ]

Use get_unaligned_be64() to fetch the timestamp needed for ns_to_ktime()
conversion.

Fixes following sparse warning:
sge.c:3282:43: warning: cast to restricted __be64

Fixes: a456950445a0 ("cxgb4: time stamping interface for PTP")
Signed-off-by: Rahul Lakkireddy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/chelsio/cxgb4/sge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 6807bc3a44fb7..3d4a765e9e61d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -2742,7 +2742,7 @@ static noinline int t4_systim_to_hwstamp(struct adapter *adapter,

hwtstamps = skb_hwtstamps(skb);
memset(hwtstamps, 0, sizeof(*hwtstamps));
- hwtstamps->hwtstamp = ns_to_ktime(be64_to_cpu(*((u64 *)data)));
+ hwtstamps->hwtstamp = ns_to_ktime(get_unaligned_be64(data));

return RX_PTP_PKT_SUC;
}
--
2.25.1



2020-07-07 15:22:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 16/36] cxgb4: parse TC-U32 key values and masks natively

From: Rahul Lakkireddy <[email protected]>

[ Upstream commit 27f78cb245abdb86735529c13b0a579f57829e71 ]

TC-U32 passes all keys values and masks in __be32 format. The parser
already expects this and hence pass the value and masks in __be32
natively to the parser.

Fixes following sparse warnings in several places:
cxgb4_tc_u32.c:57:21: warning: incorrect type in assignment (different base
types)
cxgb4_tc_u32.c:57:21: expected unsigned int [usertype] val
cxgb4_tc_u32.c:57:21: got restricted __be32 [usertype] val
cxgb4_tc_u32_parse.h:48:24: warning: cast to restricted __be32

Fixes: 2e8aad7bf203 ("cxgb4: add parser to translate u32 filters to internal spec")
Signed-off-by: Rahul Lakkireddy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
.../net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c | 18 +--
.../chelsio/cxgb4/cxgb4_tc_u32_parse.h | 122 ++++++++++++------
2 files changed, 91 insertions(+), 49 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c
index c7d2b4dc7568e..9fd0acd1cbd17 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c
@@ -47,7 +47,7 @@ static int fill_match_fields(struct adapter *adap,
bool next_header)
{
unsigned int i, j;
- u32 val, mask;
+ __be32 val, mask;
int off, err;
bool found;

@@ -216,7 +216,7 @@ int cxgb4_config_knode(struct net_device *dev, struct tc_cls_u32_offload *cls)
const struct cxgb4_next_header *next;
bool found = false;
unsigned int i, j;
- u32 val, mask;
+ __be32 val, mask;
int off;

if (t->table[link_uhtid - 1].link_handle) {
@@ -230,10 +230,10 @@ int cxgb4_config_knode(struct net_device *dev, struct tc_cls_u32_offload *cls)

/* Try to find matches that allow jumps to next header. */
for (i = 0; next[i].jump; i++) {
- if (next[i].offoff != cls->knode.sel->offoff ||
- next[i].shift != cls->knode.sel->offshift ||
- next[i].mask != cls->knode.sel->offmask ||
- next[i].offset != cls->knode.sel->off)
+ if (next[i].sel.offoff != cls->knode.sel->offoff ||
+ next[i].sel.offshift != cls->knode.sel->offshift ||
+ next[i].sel.offmask != cls->knode.sel->offmask ||
+ next[i].sel.off != cls->knode.sel->off)
continue;

/* Found a possible candidate. Find a key that
@@ -245,9 +245,9 @@ int cxgb4_config_knode(struct net_device *dev, struct tc_cls_u32_offload *cls)
val = cls->knode.sel->keys[j].val;
mask = cls->knode.sel->keys[j].mask;

- if (next[i].match_off == off &&
- next[i].match_val == val &&
- next[i].match_mask == mask) {
+ if (next[i].key.off == off &&
+ next[i].key.val == val &&
+ next[i].key.mask == mask) {
found = true;
break;
}
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h
index a4b99edcc3399..141085e159e57 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h
@@ -38,12 +38,12 @@
struct cxgb4_match_field {
int off; /* Offset from the beginning of the header to match */
/* Fill the value/mask pair in the spec if matched */
- int (*val)(struct ch_filter_specification *f, u32 val, u32 mask);
+ int (*val)(struct ch_filter_specification *f, __be32 val, __be32 mask);
};

/* IPv4 match fields */
static inline int cxgb4_fill_ipv4_tos(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
f->val.tos = (ntohl(val) >> 16) & 0x000000FF;
f->mask.tos = (ntohl(mask) >> 16) & 0x000000FF;
@@ -52,7 +52,7 @@ static inline int cxgb4_fill_ipv4_tos(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv4_frag(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
u32 mask_val;
u8 frag_val;
@@ -74,7 +74,7 @@ static inline int cxgb4_fill_ipv4_frag(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv4_proto(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
f->val.proto = (ntohl(val) >> 16) & 0x000000FF;
f->mask.proto = (ntohl(mask) >> 16) & 0x000000FF;
@@ -83,7 +83,7 @@ static inline int cxgb4_fill_ipv4_proto(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv4_src_ip(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
memcpy(&f->val.fip[0], &val, sizeof(u32));
memcpy(&f->mask.fip[0], &mask, sizeof(u32));
@@ -92,7 +92,7 @@ static inline int cxgb4_fill_ipv4_src_ip(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv4_dst_ip(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
memcpy(&f->val.lip[0], &val, sizeof(u32));
memcpy(&f->mask.lip[0], &mask, sizeof(u32));
@@ -111,7 +111,7 @@ static const struct cxgb4_match_field cxgb4_ipv4_fields[] = {

/* IPv6 match fields */
static inline int cxgb4_fill_ipv6_tos(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
f->val.tos = (ntohl(val) >> 20) & 0x000000FF;
f->mask.tos = (ntohl(mask) >> 20) & 0x000000FF;
@@ -120,7 +120,7 @@ static inline int cxgb4_fill_ipv6_tos(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv6_proto(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
f->val.proto = (ntohl(val) >> 8) & 0x000000FF;
f->mask.proto = (ntohl(mask) >> 8) & 0x000000FF;
@@ -129,7 +129,7 @@ static inline int cxgb4_fill_ipv6_proto(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv6_src_ip0(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
memcpy(&f->val.fip[0], &val, sizeof(u32));
memcpy(&f->mask.fip[0], &mask, sizeof(u32));
@@ -138,7 +138,7 @@ static inline int cxgb4_fill_ipv6_src_ip0(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv6_src_ip1(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
memcpy(&f->val.fip[4], &val, sizeof(u32));
memcpy(&f->mask.fip[4], &mask, sizeof(u32));
@@ -147,7 +147,7 @@ static inline int cxgb4_fill_ipv6_src_ip1(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv6_src_ip2(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
memcpy(&f->val.fip[8], &val, sizeof(u32));
memcpy(&f->mask.fip[8], &mask, sizeof(u32));
@@ -156,7 +156,7 @@ static inline int cxgb4_fill_ipv6_src_ip2(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv6_src_ip3(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
memcpy(&f->val.fip[12], &val, sizeof(u32));
memcpy(&f->mask.fip[12], &mask, sizeof(u32));
@@ -165,7 +165,7 @@ static inline int cxgb4_fill_ipv6_src_ip3(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv6_dst_ip0(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
memcpy(&f->val.lip[0], &val, sizeof(u32));
memcpy(&f->mask.lip[0], &mask, sizeof(u32));
@@ -174,7 +174,7 @@ static inline int cxgb4_fill_ipv6_dst_ip0(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv6_dst_ip1(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
memcpy(&f->val.lip[4], &val, sizeof(u32));
memcpy(&f->mask.lip[4], &mask, sizeof(u32));
@@ -183,7 +183,7 @@ static inline int cxgb4_fill_ipv6_dst_ip1(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv6_dst_ip2(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
memcpy(&f->val.lip[8], &val, sizeof(u32));
memcpy(&f->mask.lip[8], &mask, sizeof(u32));
@@ -192,7 +192,7 @@ static inline int cxgb4_fill_ipv6_dst_ip2(struct ch_filter_specification *f,
}

static inline int cxgb4_fill_ipv6_dst_ip3(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
memcpy(&f->val.lip[12], &val, sizeof(u32));
memcpy(&f->mask.lip[12], &mask, sizeof(u32));
@@ -216,7 +216,7 @@ static const struct cxgb4_match_field cxgb4_ipv6_fields[] = {

/* TCP/UDP match */
static inline int cxgb4_fill_l4_ports(struct ch_filter_specification *f,
- u32 val, u32 mask)
+ __be32 val, __be32 mask)
{
f->val.fport = ntohl(val) >> 16;
f->mask.fport = ntohl(mask) >> 16;
@@ -237,19 +237,13 @@ static const struct cxgb4_match_field cxgb4_udp_fields[] = {
};

struct cxgb4_next_header {
- unsigned int offset; /* Offset to next header */
- /* offset, shift, and mask added to offset above
+ /* Offset, shift, and mask added to beginning of the header
* to get to next header. Useful when using a header
* field's value to jump to next header such as IHL field
* in IPv4 header.
*/
- unsigned int offoff;
- u32 shift;
- u32 mask;
- /* match criteria to make this jump */
- unsigned int match_off;
- u32 match_val;
- u32 match_mask;
+ struct tc_u32_sel sel;
+ struct tc_u32_key key;
/* location of jump to make */
const struct cxgb4_match_field *jump;
};
@@ -258,26 +252,74 @@ struct cxgb4_next_header {
* IPv4 header.
*/
static const struct cxgb4_next_header cxgb4_ipv4_jumps[] = {
- { .offset = 0, .offoff = 0, .shift = 6, .mask = 0xF,
- .match_off = 8, .match_val = 0x600, .match_mask = 0xFF00,
- .jump = cxgb4_tcp_fields },
- { .offset = 0, .offoff = 0, .shift = 6, .mask = 0xF,
- .match_off = 8, .match_val = 0x1100, .match_mask = 0xFF00,
- .jump = cxgb4_udp_fields },
- { .jump = NULL }
+ {
+ /* TCP Jump */
+ .sel = {
+ .off = 0,
+ .offoff = 0,
+ .offshift = 6,
+ .offmask = cpu_to_be16(0x0f00),
+ },
+ .key = {
+ .off = 8,
+ .val = cpu_to_be32(0x00060000),
+ .mask = cpu_to_be32(0x00ff0000),
+ },
+ .jump = cxgb4_tcp_fields,
+ },
+ {
+ /* UDP Jump */
+ .sel = {
+ .off = 0,
+ .offoff = 0,
+ .offshift = 6,
+ .offmask = cpu_to_be16(0x0f00),
+ },
+ .key = {
+ .off = 8,
+ .val = cpu_to_be32(0x00110000),
+ .mask = cpu_to_be32(0x00ff0000),
+ },
+ .jump = cxgb4_udp_fields,
+ },
+ { .jump = NULL },
};

/* Accept a rule with a jump directly past the 40 Bytes of IPv6 fixed header
* to get to transport layer header.
*/
static const struct cxgb4_next_header cxgb4_ipv6_jumps[] = {
- { .offset = 0x28, .offoff = 0, .shift = 0, .mask = 0,
- .match_off = 4, .match_val = 0x60000, .match_mask = 0xFF0000,
- .jump = cxgb4_tcp_fields },
- { .offset = 0x28, .offoff = 0, .shift = 0, .mask = 0,
- .match_off = 4, .match_val = 0x110000, .match_mask = 0xFF0000,
- .jump = cxgb4_udp_fields },
- { .jump = NULL }
+ {
+ /* TCP Jump */
+ .sel = {
+ .off = 40,
+ .offoff = 0,
+ .offshift = 0,
+ .offmask = 0,
+ },
+ .key = {
+ .off = 4,
+ .val = cpu_to_be32(0x00000600),
+ .mask = cpu_to_be32(0x0000ff00),
+ },
+ .jump = cxgb4_tcp_fields,
+ },
+ {
+ /* UDP Jump */
+ .sel = {
+ .off = 40,
+ .offoff = 0,
+ .offshift = 0,
+ .offmask = 0,
+ },
+ .key = {
+ .off = 4,
+ .val = cpu_to_be32(0x00001100),
+ .mask = cpu_to_be32(0x0000ff00),
+ },
+ .jump = cxgb4_udp_fields,
+ },
+ { .jump = NULL },
};

struct cxgb4_link {
--
2.25.1



2020-07-07 15:22:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 03/36] EDAC/amd64: Read back the scrub rate PCI register on F15h

From: Borislav Petkov <[email protected]>

[ Upstream commit ee470bb25d0dcdf126f586ec0ae6dca66cb340a4 ]

Commit:

da92110dfdfa ("EDAC, amd64_edac: Extend scrub rate support to F15hM60h")

added support for F15h, model 0x60 CPUs but in doing so, missed to read
back SCRCTRL PCI config register on F15h CPUs which are *not* model
0x60. Add that read so that doing

$ cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate

can show the previously set DRAM scrub rate.

Fixes: da92110dfdfa ("EDAC, amd64_edac: Extend scrub rate support to F15hM60h")
Reported-by: Anders Andersson <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: <[email protected]> #v4.4..
Link: https://lkml.kernel.org/r/CAKkunMbNWppx_i6xSdDHLseA2QQmGJqj_crY=NF-GZML5np4Vw@mail.gmail.com
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/edac/amd64_edac.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 268ada29cd987..cbe4158531979 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -261,6 +261,8 @@ static int get_scrub_rate(struct mem_ctl_info *mci)

if (pvt->model == 0x60)
amd64_read_pci_cfg(pvt->F2, F15H_M60H_SCRCTRL, &scrubval);
+ else
+ amd64_read_pci_cfg(pvt->F3, SCRCTRL, &scrubval);
break;

case 0x17:
--
2.25.1



2020-07-07 15:22:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 22/36] virtio-blk: free vblk-vqs in error path of virtblk_probe()

From: Hou Tao <[email protected]>

[ Upstream commit e7eea44eefbdd5f0345a0a8b80a3ca1c21030d06 ]

Else there will be memory leak if alloc_disk() fails.

Fixes: 6a27b656fc02 ("block: virtio-blk: support multi virt queues per virtio-blk device")
Signed-off-by: Hou Tao <[email protected]>
Reviewed-by: Stefano Garzarella <[email protected]>
Reviewed-by: Ming Lei <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/block/virtio_blk.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 9be54e5ef96ae..075523777a4a9 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -882,6 +882,7 @@ static int virtblk_probe(struct virtio_device *vdev)
put_disk(vblk->disk);
out_free_vq:
vdev->config->del_vqs(vdev);
+ kfree(vblk->vqs);
out_free_vblk:
kfree(vblk);
out_free_index:
--
2.25.1



2020-07-07 15:22:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 04/36] usbnet: smsc95xx: Fix use-after-free after removal

From: Tuomas Tynkkynen <[email protected]>

[ Upstream commit b835a71ef64a61383c414d6bf2896d2c0161deca ]

Syzbot reports an use-after-free in workqueue context:

BUG: KASAN: use-after-free in mutex_unlock+0x19/0x40 kernel/locking/mutex.c:737
mutex_unlock+0x19/0x40 kernel/locking/mutex.c:737
__smsc95xx_mdio_read drivers/net/usb/smsc95xx.c:217 [inline]
smsc95xx_mdio_read+0x583/0x870 drivers/net/usb/smsc95xx.c:278
check_carrier+0xd1/0x2e0 drivers/net/usb/smsc95xx.c:644
process_one_work+0x777/0xf90 kernel/workqueue.c:2274
worker_thread+0xa8f/0x1430 kernel/workqueue.c:2420
kthread+0x2df/0x300 kernel/kthread.c:255

It looks like that smsc95xx_unbind() is freeing the structures that are
still in use by the concurrently running workqueue callback. Thus switch
to using cancel_delayed_work_sync() to ensure the work callback really
is no longer active.

Reported-by: [email protected]
Signed-off-by: Tuomas Tynkkynen <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/usb/smsc95xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 6e971628bb50a..c3389bd87c654 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1338,7 +1338,7 @@ static void smsc95xx_unbind(struct usbnet *dev, struct usb_interface *intf)
struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0]);

if (pdata) {
- cancel_delayed_work(&pdata->carrier_check);
+ cancel_delayed_work_sync(&pdata->carrier_check);
netif_dbg(dev, ifdown, dev->net, "free pdata\n");
kfree(pdata);
pdata = NULL;
--
2.25.1



2020-07-07 15:22:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 10/36] nvme: fix possible deadlock when I/O is blocked

From: Sagi Grimberg <[email protected]>

[ Upstream commit 3b4b19721ec652ad2c4fe51dfbe5124212b5f581 ]

Revert fab7772bfbcf ("nvme-multipath: revalidate nvme_ns_head gendisk
in nvme_validate_ns")

When adding a new namespace to the head disk (via nvme_mpath_set_live)
we will see partition scan which triggers I/O on the mpath device node.
This process will usually be triggered from the scan_work which holds
the scan_lock. If I/O blocks (if we got ana change currently have only
available paths but none are accessible) this can deadlock on the head
disk bd_mutex as both partition scan I/O takes it, and head disk revalidation
takes it to check for resize (also triggered from scan_work on a different
path). See trace [1].

The mpath disk revalidation was originally added to detect online disk
size change, but this is no longer needed since commit cb224c3af4df
("nvme: Convert to use set_capacity_revalidate_and_notify") which already
updates resize info without unnecessarily revalidating the disk (the
mpath disk doesn't even implement .revalidate_disk fop).

[1]:
--
kernel: INFO: task kworker/u65:9:494 blocked for more than 241 seconds.
kernel: Tainted: G OE 5.3.5-050305-generic #201910071830
kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kernel: kworker/u65:9 D 0 494 2 0x80004000
kernel: Workqueue: nvme-wq nvme_scan_work [nvme_core]
kernel: Call Trace:
kernel: __schedule+0x2b9/0x6c0
kernel: schedule+0x42/0xb0
kernel: schedule_preempt_disabled+0xe/0x10
kernel: __mutex_lock.isra.0+0x182/0x4f0
kernel: __mutex_lock_slowpath+0x13/0x20
kernel: mutex_lock+0x2e/0x40
kernel: revalidate_disk+0x63/0xa0
kernel: __nvme_revalidate_disk+0xfe/0x110 [nvme_core]
kernel: nvme_revalidate_disk+0xa4/0x160 [nvme_core]
kernel: ? evict+0x14c/0x1b0
kernel: revalidate_disk+0x2b/0xa0
kernel: nvme_validate_ns+0x49/0x940 [nvme_core]
kernel: ? blk_mq_free_request+0xd2/0x100
kernel: ? __nvme_submit_sync_cmd+0xbe/0x1e0 [nvme_core]
kernel: nvme_scan_work+0x24f/0x380 [nvme_core]
kernel: process_one_work+0x1db/0x380
kernel: worker_thread+0x249/0x400
kernel: kthread+0x104/0x140
kernel: ? process_one_work+0x380/0x380
kernel: ? kthread_park+0x80/0x80
kernel: ret_from_fork+0x1f/0x40
...
kernel: INFO: task kworker/u65:1:2630 blocked for more than 241 seconds.
kernel: Tainted: G OE 5.3.5-050305-generic #201910071830
kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kernel: kworker/u65:1 D 0 2630 2 0x80004000
kernel: Workqueue: nvme-wq nvme_scan_work [nvme_core]
kernel: Call Trace:
kernel: __schedule+0x2b9/0x6c0
kernel: schedule+0x42/0xb0
kernel: io_schedule+0x16/0x40
kernel: do_read_cache_page+0x438/0x830
kernel: ? __switch_to_asm+0x34/0x70
kernel: ? file_fdatawait_range+0x30/0x30
kernel: read_cache_page+0x12/0x20
kernel: read_dev_sector+0x27/0xc0
kernel: read_lba+0xc1/0x220
kernel: ? kmem_cache_alloc_trace+0x19c/0x230
kernel: efi_partition+0x1e6/0x708
kernel: ? vsnprintf+0x39e/0x4e0
kernel: ? snprintf+0x49/0x60
kernel: check_partition+0x154/0x244
kernel: rescan_partitions+0xae/0x280
kernel: __blkdev_get+0x40f/0x560
kernel: blkdev_get+0x3d/0x140
kernel: __device_add_disk+0x388/0x480
kernel: device_add_disk+0x13/0x20
kernel: nvme_mpath_set_live+0x119/0x140 [nvme_core]
kernel: nvme_update_ns_ana_state+0x5c/0x60 [nvme_core]
kernel: nvme_set_ns_ana_state+0x1e/0x30 [nvme_core]
kernel: nvme_parse_ana_log+0xa1/0x180 [nvme_core]
kernel: ? nvme_update_ns_ana_state+0x60/0x60 [nvme_core]
kernel: nvme_mpath_add_disk+0x47/0x90 [nvme_core]
kernel: nvme_validate_ns+0x396/0x940 [nvme_core]
kernel: ? blk_mq_free_request+0xd2/0x100
kernel: nvme_scan_work+0x24f/0x380 [nvme_core]
kernel: process_one_work+0x1db/0x380
kernel: worker_thread+0x249/0x400
kernel: kthread+0x104/0x140
kernel: ? process_one_work+0x380/0x380
kernel: ? kthread_park+0x80/0x80
kernel: ret_from_fork+0x1f/0x40
--

Fixes: fab7772bfbcf ("nvme-multipath: revalidate nvme_ns_head gendisk
in nvme_validate_ns")
Signed-off-by: Anton Eidelman <[email protected]>
Signed-off-by: Sagi Grimberg <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/nvme/host/core.c | 1 -
1 file changed, 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 0d60f2f8f3eec..5c9326777334f 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1602,7 +1602,6 @@ static void __nvme_revalidate_disk(struct gendisk *disk, struct nvme_id_ns *id)
if (ns->head->disk) {
nvme_update_disk_info(ns->head->disk, ns, id);
blk_queue_stack_limits(ns->head->disk->queue, ns->queue);
- revalidate_disk(ns->head->disk);
}
#endif
}
--
2.25.1



2020-07-07 15:23:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 27/36] nfsd: apply umask on fs without ACL support

From: J. Bruce Fields <[email protected]>

commit 22cf8419f1319ff87ec759d0ebdff4cbafaee832 upstream.

The server is failing to apply the umask when creating new objects on
filesystems without ACL support.

To reproduce this, you need to use NFSv4.2 and a client and server
recent enough to support umask, and you need to export a filesystem that
lacks ACL support (for example, ext4 with the "noacl" mount option).

Filesystems with ACL support are expected to take care of the umask
themselves (usually by calling posix_acl_create).

For filesystems without ACL support, this is up to the caller of
vfs_create(), vfs_mknod(), or vfs_mkdir().

Reported-by: Elliott Mitchell <[email protected]>
Reported-by: Salvatore Bonaccorso <[email protected]>
Tested-by: Salvatore Bonaccorso <[email protected]>
Fixes: 47057abde515 ("nfsd: add support for the umask attribute")
Cc: [email protected]
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfsd/vfs.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -1206,6 +1206,9 @@ nfsd_create_locked(struct svc_rqst *rqst
iap->ia_mode = 0;
iap->ia_mode = (iap->ia_mode & S_IALLUGO) | type;

+ if (!IS_POSIXACL(dirp))
+ iap->ia_mode &= ~current_umask();
+
err = 0;
host_err = 0;
switch (type) {
@@ -1439,6 +1442,9 @@ do_nfsd_create(struct svc_rqst *rqstp, s
goto out;
}

+ if (!IS_POSIXACL(dirp))
+ iap->ia_mode &= ~current_umask();
+
host_err = vfs_create(dirp, dchild, iap->ia_mode, true);
if (host_err < 0) {
fh_drop_write(fhp);


2020-07-07 15:23:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 30/36] SMB3: Honor persistent/resilient handle flags for multiuser mounts

From: Paul Aurich <[email protected]>

commit 00dfbc2f9c61185a2e662f27c45a0bb29b2a134f upstream.

Without this:

- persistent handles will only be enabled for per-user tcons if the
server advertises the 'Continuous Availabity' capability
- resilient handles would never be enabled for per-user tcons

Signed-off-by: Paul Aurich <[email protected]>
CC: Stable <[email protected]>
Signed-off-by: Steve French <[email protected]>
Reviewed-by: Aurelien Aptel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/connect.c | 2 ++
1 file changed, 2 insertions(+)

--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -4601,6 +4601,8 @@ cifs_construct_tcon(struct cifs_sb_info
vol_info->nocase = master_tcon->nocase;
vol_info->nohandlecache = master_tcon->nohandlecache;
vol_info->local_lease = master_tcon->local_lease;
+ vol_info->resilient = master_tcon->use_resilient;
+ vol_info->persistent = master_tcon->use_persistent;
vol_info->no_linux_ext = !master_tcon->unix_ext;
vol_info->linux_ext = master_tcon->posix_extensions;
vol_info->sectype = master_tcon->ses->sectype;


2020-07-07 15:23:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 29/36] SMB3: Honor seal flag for multiuser mounts

From: Paul Aurich <[email protected]>

commit cc15461c73d7d044d56c47e869a215e49bd429c8 upstream.

Ensure multiuser SMB3 mounts use encryption for all users' tcons if the
mount options are configured to require encryption. Without this, only
the primary tcon and IPC tcons are guaranteed to be encrypted. Per-user
tcons would only be encrypted if the server was configured to require
encryption.

Signed-off-by: Paul Aurich <[email protected]>
CC: Stable <[email protected]>
Signed-off-by: Steve French <[email protected]>
Reviewed-by: Aurelien Aptel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/connect.c | 1 +
1 file changed, 1 insertion(+)

--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -4605,6 +4605,7 @@ cifs_construct_tcon(struct cifs_sb_info
vol_info->linux_ext = master_tcon->posix_extensions;
vol_info->sectype = master_tcon->ses->sectype;
vol_info->sign = master_tcon->ses->sign;
+ vol_info->seal = master_tcon->seal;

rc = cifs_set_vol_auth(vol_info, master_tcon->ses);
if (rc) {


2020-07-07 15:34:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 23/36] SMB3: Honor posix flag for multiuser mounts

From: Paul Aurich <[email protected]>

[ Upstream commit 5391b8e1b7b7e5cfa2dd4ffdc4b8c6b64dfd1866 ]

The flag from the primary tcon needs to be copied into the volume info
so that cifs_get_tcon will try to enable extensions on the per-user
tcon. At that point, since posix extensions must have already been
enabled on the superblock, don't try to needlessly adjust the mount
flags.

Fixes: ce558b0e17f8 ("smb3: Add posix create context for smb3.11 posix mounts")
Fixes: b326614ea215 ("smb3: allow "posix" mount option to enable new SMB311 protocol extensions")
Signed-off-by: Paul Aurich <[email protected]>
Signed-off-by: Steve French <[email protected]>
Reviewed-by: Aurelien Aptel <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/cifs/connect.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 9e569d60c636b..136de62f351a7 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -4602,6 +4602,7 @@ cifs_construct_tcon(struct cifs_sb_info *cifs_sb, kuid_t fsuid)
vol_info->nohandlecache = master_tcon->nohandlecache;
vol_info->local_lease = master_tcon->local_lease;
vol_info->no_linux_ext = !master_tcon->unix_ext;
+ vol_info->linux_ext = master_tcon->posix_extensions;
vol_info->sectype = master_tcon->ses->sectype;
vol_info->sign = master_tcon->ses->sign;

@@ -4629,10 +4630,6 @@ cifs_construct_tcon(struct cifs_sb_info *cifs_sb, kuid_t fsuid)
goto out;
}

- /* if new SMB3.11 POSIX extensions are supported do not remap / and \ */
- if (tcon->posix_extensions)
- cifs_sb->mnt_cifs_flags |= CIFS_MOUNT_POSIX_PATHS;
-
if (cap_unix(ses))
reset_cifs_unix_caps(0, tcon, NULL, vol_info);

--
2.25.1



2020-07-07 15:34:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 01/36] btrfs: fix a block group ref counter leak after failure to remove block group

From: Filipe Manana <[email protected]>

[ Upstream commit 9fecd13202f520f3f25d5b1c313adb740fe19773 ]

When removing a block group, if we fail to delete the block group's item
from the extent tree, we jump to the 'out' label and end up decrementing
the block group's reference count once only (by 1), resulting in a counter
leak because the block group at that point was already removed from the
block group cache rbtree - so we have to decrement the reference count
twice, once for the rbtree and once for our lookup at the start of the
function.

There is a second bug where if removing the free space tree entries (the
call to remove_block_group_free_space()) fails we end up jumping to the
'out_put_group' label but end up decrementing the reference count only
once, when we should have done it twice, since we have already removed
the block group from the block group cache rbtree. This happens because
the reference count decrement for the rbtree reference happens after
attempting to remove the free space tree entries, which is far away from
the place where we remove the block group from the rbtree.

To make things less error prone, decrement the reference count for the
rbtree immediately after removing the block group from it. This also
eleminates the need for two different exit labels on error, renaming
'out_put_label' to just 'out' and removing the old 'out'.

Fixes: f6033c5e333238 ("btrfs: fix block group leak when removing fails")
CC: [email protected] # 4.4+
Reviewed-by: Nikolay Borisov <[email protected]>
Reviewed-by: Anand Jain <[email protected]>
Signed-off-by: Filipe Manana <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/btrfs/extent-tree.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 271e70c45d5bd..ec3aa76d19b7f 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -10286,7 +10286,7 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans,
path = btrfs_alloc_path();
if (!path) {
ret = -ENOMEM;
- goto out_put_group;
+ goto out;
}

/*
@@ -10323,7 +10323,7 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans,
ret = btrfs_orphan_add(trans, BTRFS_I(inode));
if (ret) {
btrfs_add_delayed_iput(inode);
- goto out_put_group;
+ goto out;
}
clear_nlink(inode);
/* One for the block groups ref */
@@ -10346,13 +10346,13 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans,

ret = btrfs_search_slot(trans, tree_root, &key, path, -1, 1);
if (ret < 0)
- goto out_put_group;
+ goto out;
if (ret > 0)
btrfs_release_path(path);
if (ret == 0) {
ret = btrfs_del_item(trans, tree_root, path);
if (ret)
- goto out_put_group;
+ goto out;
btrfs_release_path(path);
}

@@ -10361,6 +10361,9 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans,
&fs_info->block_group_cache_tree);
RB_CLEAR_NODE(&block_group->cache_node);

+ /* Once for the block groups rbtree */
+ btrfs_put_block_group(block_group);
+
if (fs_info->first_logical_byte == block_group->key.objectid)
fs_info->first_logical_byte = (u64)-1;
spin_unlock(&fs_info->block_group_cache_lock);
@@ -10494,10 +10497,7 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans,

ret = remove_block_group_free_space(trans, block_group);
if (ret)
- goto out_put_group;
-
- /* Once for the block groups rbtree */
- btrfs_put_block_group(block_group);
+ goto out;

ret = btrfs_search_slot(trans, root, &key, path, -1, 1);
if (ret > 0)
@@ -10525,10 +10525,9 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans,
free_extent_map(em);
}

-out_put_group:
+out:
/* Once for the lookup reference */
btrfs_put_block_group(block_group);
-out:
btrfs_free_path(path);
return ret;
}
--
2.25.1



2020-07-07 15:35:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 26/36] i2c: mlxcpld: check correct size of maximum RECV_LEN packet

From: Wolfram Sang <[email protected]>

[ Upstream commit 597911287fcd13c3a4b4aa3e0a52b33d431e0a8e ]

I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the
SMBus 2.0 specs. I don't see a reason to add 1 here. Also, fix the errno
to what is suggested for this error.

Fixes: c9bfdc7c16cb ("i2c: mlxcpld: Add support for smbus block read transaction")
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Michael Shych <[email protected]>
Tested-by: Michael Shych <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/i2c/busses/i2c-mlxcpld.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mlxcpld.c b/drivers/i2c/busses/i2c-mlxcpld.c
index 2fd717d8dd30e..71d7bae2cbcad 100644
--- a/drivers/i2c/busses/i2c-mlxcpld.c
+++ b/drivers/i2c/busses/i2c-mlxcpld.c
@@ -337,9 +337,9 @@ static int mlxcpld_i2c_wait_for_tc(struct mlxcpld_i2c_priv *priv)
if (priv->smbus_block && (val & MLXCPLD_I2C_SMBUS_BLK_BIT)) {
mlxcpld_i2c_read_comm(priv, MLXCPLD_LPCI2C_NUM_DAT_REG,
&datalen, 1);
- if (unlikely(datalen > (I2C_SMBUS_BLOCK_MAX + 1))) {
+ if (unlikely(datalen > I2C_SMBUS_BLOCK_MAX)) {
dev_err(priv->dev, "Incorrect smbus block read message len\n");
- return -E2BIG;
+ return -EPROTO;
}
} else {
datalen = priv->xfer.data_len;
--
2.25.1



2020-07-07 15:35:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 20/36] hwmon: (acpi_power_meter) Fix potential memory leak in acpi_power_meter_add()

From: Misono Tomohiro <[email protected]>

[ Upstream commit 8b97f9922211c44a739c5cbd9502ecbb9f17f6d1 ]

Although it rarely happens, we should call free_capabilities()
if error happens after read_capabilities() to free allocated strings.

Fixes: de584afa5e188 ("hwmon driver for ACPI 4.0 power meters")
Signed-off-by: Misono Tomohiro <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/hwmon/acpi_power_meter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/acpi_power_meter.c b/drivers/hwmon/acpi_power_meter.c
index 2f2fb19669580..2f40da04a9445 100644
--- a/drivers/hwmon/acpi_power_meter.c
+++ b/drivers/hwmon/acpi_power_meter.c
@@ -896,7 +896,7 @@ static int acpi_power_meter_add(struct acpi_device *device)

res = setup_attrs(resource);
if (res)
- goto exit_free;
+ goto exit_free_capability;

resource->hwmon_dev = hwmon_device_register(&device->dev);
if (IS_ERR(resource->hwmon_dev)) {
@@ -909,6 +909,8 @@ static int acpi_power_meter_add(struct acpi_device *device)

exit_remove:
remove_attrs(resource);
+exit_free_capability:
+ free_capabilities(resource);
exit_free:
kfree(resource);
exit:
--
2.25.1



2020-07-07 15:35:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 18/36] cxgb4: fix SGE queue dump destination buffer context

From: Rahul Lakkireddy <[email protected]>

[ Upstream commit 1992ded5d111997877a9a25205976d8d03c46814 ]

The data in destination buffer is expected to be be parsed in big
endian. So, use the right context.

Fixes following sparse warning:
cudbg_lib.c:2041:44: warning: incorrect type in assignment (different
base types)
cudbg_lib.c:2041:44: expected unsigned long long [usertype]
cudbg_lib.c:2041:44: got restricted __be64 [usertype]

Fixes: 736c3b94474e ("cxgb4: collect egress and ingress SGE queue contexts")
Signed-off-by: Rahul Lakkireddy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
index 5bc58429bb1c4..c91e155c147ca 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
@@ -1987,7 +1987,6 @@ int cudbg_collect_dump_context(struct cudbg_init *pdbg_init,
u8 mem_type[CTXT_INGRESS + 1] = { 0 };
struct cudbg_buffer temp_buff = { 0 };
struct cudbg_ch_cntxt *buff;
- u64 *dst_off, *src_off;
u8 *ctx_buf;
u8 i, k;
int rc;
@@ -2056,8 +2055,11 @@ int cudbg_collect_dump_context(struct cudbg_init *pdbg_init,
}

for (j = 0; j < max_ctx_qid; j++) {
+ __be64 *dst_off;
+ u64 *src_off;
+
src_off = (u64 *)(ctx_buf + j * SGE_CTXT_SIZE);
- dst_off = (u64 *)buff->data;
+ dst_off = (__be64 *)buff->data;

/* The data is stored in 64-bit cpu order. Convert it
* to big endian before parsing.
--
2.25.1



2020-07-07 15:35:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 12/36] kgdb: Avoid suspicious RCU usage warning

From: Douglas Anderson <[email protected]>

[ Upstream commit 440ab9e10e2e6e5fd677473ee6f9e3af0f6904d6 ]

At times when I'm using kgdb I see a splat on my console about
suspicious RCU usage. I managed to come up with a case that could
reproduce this that looked like this:

WARNING: suspicious RCU usage
5.7.0-rc4+ #609 Not tainted
-----------------------------
kernel/pid.c:395 find_task_by_pid_ns() needs rcu_read_lock() protection!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
3 locks held by swapper/0/1:
#0: ffffff81b6b8e988 (&dev->mutex){....}-{3:3}, at: __device_attach+0x40/0x13c
#1: ffffffd01109e9e8 (dbg_master_lock){....}-{2:2}, at: kgdb_cpu_enter+0x20c/0x7ac
#2: ffffffd01109ea90 (dbg_slave_lock){....}-{2:2}, at: kgdb_cpu_enter+0x3ec/0x7ac

stack backtrace:
CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc4+ #609
Hardware name: Google Cheza (rev3+) (DT)
Call trace:
dump_backtrace+0x0/0x1b8
show_stack+0x1c/0x24
dump_stack+0xd4/0x134
lockdep_rcu_suspicious+0xf0/0x100
find_task_by_pid_ns+0x5c/0x80
getthread+0x8c/0xb0
gdb_serial_stub+0x9d4/0xd04
kgdb_cpu_enter+0x284/0x7ac
kgdb_handle_exception+0x174/0x20c
kgdb_brk_fn+0x24/0x30
call_break_hook+0x6c/0x7c
brk_handler+0x20/0x5c
do_debug_exception+0x1c8/0x22c
el1_sync_handler+0x3c/0xe4
el1_sync+0x7c/0x100
rpmh_rsc_probe+0x38/0x420
platform_drv_probe+0x94/0xb4
really_probe+0x134/0x300
driver_probe_device+0x68/0x100
__device_attach_driver+0x90/0xa8
bus_for_each_drv+0x84/0xcc
__device_attach+0xb4/0x13c
device_initial_probe+0x18/0x20
bus_probe_device+0x38/0x98
device_add+0x38c/0x420

If I understand properly we should just be able to blanket kgdb under
one big RCU read lock and the problem should go away. We'll add it to
the beast-of-a-function known as kgdb_cpu_enter().

With this I no longer get any splats and things seem to work fine.

Signed-off-by: Douglas Anderson <[email protected]>
Link: https://lore.kernel.org/r/20200602154729.v2.1.I70e0d4fd46d5ed2aaf0c98a355e8e1b7a5bb7e4e@changeid
Signed-off-by: Daniel Thompson <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/debug/debug_core.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 6a1dc2613bb92..fbb1bfdd2fa53 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -489,6 +489,7 @@ static int kgdb_cpu_enter(struct kgdb_state *ks, struct pt_regs *regs,
arch_kgdb_ops.disable_hw_break(regs);

acquirelock:
+ rcu_read_lock();
/*
* Interrupts will be restored by the 'trap return' code, except when
* single stepping.
@@ -545,6 +546,7 @@ return_normal:
atomic_dec(&slaves_in_kgdb);
dbg_touch_watchdogs();
local_irq_restore(flags);
+ rcu_read_unlock();
return 0;
}
cpu_relax();
@@ -563,6 +565,7 @@ return_normal:
raw_spin_unlock(&dbg_master_lock);
dbg_touch_watchdogs();
local_irq_restore(flags);
+ rcu_read_unlock();

goto acquirelock;
}
@@ -686,6 +689,7 @@ kgdb_restore:
raw_spin_unlock(&dbg_master_lock);
dbg_touch_watchdogs();
local_irq_restore(flags);
+ rcu_read_unlock();

return kgdb_info[cpu].ret_state;
}
--
2.25.1



2020-07-07 15:35:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 13/36] crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()

From: Herbert Xu <[email protected]>

commit 34c86f4c4a7be3b3e35aa48bd18299d4c756064d upstream.

The locking in af_alg_release_parent is broken as the BH socket
lock can only be taken if there is a code-path to handle the case
where the lock is owned by process-context. Instead of adding
such handling, we can fix this by changing the ref counts to
atomic_t.

This patch also modifies the main refcnt to include both normal
and nokey sockets. This way we don't have to fudge the nokey
ref count when a socket changes from nokey to normal.

Credits go to Mauricio Faria de Oliveira who diagnosed this bug
and sent a patch for it:

https://lore.kernel.org/linux-crypto/[email protected]/

Reported-by: Brian Moyles <[email protected]>
Reported-by: Mauricio Faria de Oliveira <[email protected]>
Fixes: 37f96694cf73 ("crypto: af_alg - Use bh_lock_sock in...")
Cc: <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
crypto/af_alg.c | 26 +++++++++++---------------
crypto/algif_aead.c | 9 +++------
crypto/algif_hash.c | 9 +++------
crypto/algif_skcipher.c | 9 +++------
include/crypto/if_alg.h | 4 ++--
5 files changed, 22 insertions(+), 35 deletions(-)

--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -133,21 +133,15 @@ EXPORT_SYMBOL_GPL(af_alg_release);
void af_alg_release_parent(struct sock *sk)
{
struct alg_sock *ask = alg_sk(sk);
- unsigned int nokey = ask->nokey_refcnt;
- bool last = nokey && !ask->refcnt;
+ unsigned int nokey = atomic_read(&ask->nokey_refcnt);

sk = ask->parent;
ask = alg_sk(sk);

- local_bh_disable();
- bh_lock_sock(sk);
- ask->nokey_refcnt -= nokey;
- if (!last)
- last = !--ask->refcnt;
- bh_unlock_sock(sk);
- local_bh_enable();
+ if (nokey)
+ atomic_dec(&ask->nokey_refcnt);

- if (last)
+ if (atomic_dec_and_test(&ask->refcnt))
sock_put(sk);
}
EXPORT_SYMBOL_GPL(af_alg_release_parent);
@@ -192,7 +186,7 @@ static int alg_bind(struct socket *sock,

err = -EBUSY;
lock_sock(sk);
- if (ask->refcnt | ask->nokey_refcnt)
+ if (atomic_read(&ask->refcnt))
goto unlock;

swap(ask->type, type);
@@ -241,7 +235,7 @@ static int alg_setsockopt(struct socket
int err = -EBUSY;

lock_sock(sk);
- if (ask->refcnt)
+ if (atomic_read(&ask->refcnt) != atomic_read(&ask->nokey_refcnt))
goto unlock;

type = ask->type;
@@ -308,12 +302,14 @@ int af_alg_accept(struct sock *sk, struc

sk2->sk_family = PF_ALG;

- if (nokey || !ask->refcnt++)
+ if (atomic_inc_return_relaxed(&ask->refcnt) == 1)
sock_hold(sk);
- ask->nokey_refcnt += nokey;
+ if (nokey) {
+ atomic_inc(&ask->nokey_refcnt);
+ atomic_set(&alg_sk(sk2)->nokey_refcnt, 1);
+ }
alg_sk(sk2)->parent = sk;
alg_sk(sk2)->type = type;
- alg_sk(sk2)->nokey_refcnt = nokey;

newsock->ops = type->ops;
newsock->state = SS_CONNECTED;
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -388,7 +388,7 @@ static int aead_check_key(struct socket
struct alg_sock *ask = alg_sk(sk);

lock_sock(sk);
- if (ask->refcnt)
+ if (!atomic_read(&ask->nokey_refcnt))
goto unlock_child;

psk = ask->parent;
@@ -400,11 +400,8 @@ static int aead_check_key(struct socket
if (crypto_aead_get_flags(tfm->aead) & CRYPTO_TFM_NEED_KEY)
goto unlock;

- if (!pask->refcnt++)
- sock_hold(psk);
-
- ask->refcnt = 1;
- sock_put(psk);
+ atomic_dec(&pask->nokey_refcnt);
+ atomic_set(&ask->nokey_refcnt, 0);

err = 0;

--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -306,7 +306,7 @@ static int hash_check_key(struct socket
struct alg_sock *ask = alg_sk(sk);

lock_sock(sk);
- if (ask->refcnt)
+ if (!atomic_read(&ask->nokey_refcnt))
goto unlock_child;

psk = ask->parent;
@@ -318,11 +318,8 @@ static int hash_check_key(struct socket
if (crypto_ahash_get_flags(tfm) & CRYPTO_TFM_NEED_KEY)
goto unlock;

- if (!pask->refcnt++)
- sock_hold(psk);
-
- ask->refcnt = 1;
- sock_put(psk);
+ atomic_dec(&pask->nokey_refcnt);
+ atomic_set(&ask->nokey_refcnt, 0);

err = 0;

--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -215,7 +215,7 @@ static int skcipher_check_key(struct soc
struct alg_sock *ask = alg_sk(sk);

lock_sock(sk);
- if (ask->refcnt)
+ if (!atomic_read(&ask->nokey_refcnt))
goto unlock_child;

psk = ask->parent;
@@ -227,11 +227,8 @@ static int skcipher_check_key(struct soc
if (crypto_skcipher_get_flags(tfm) & CRYPTO_TFM_NEED_KEY)
goto unlock;

- if (!pask->refcnt++)
- sock_hold(psk);
-
- ask->refcnt = 1;
- sock_put(psk);
+ atomic_dec(&pask->nokey_refcnt);
+ atomic_set(&ask->nokey_refcnt, 0);

err = 0;

--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -34,8 +34,8 @@ struct alg_sock {

struct sock *parent;

- unsigned int refcnt;
- unsigned int nokey_refcnt;
+ atomic_t refcnt;
+ atomic_t nokey_refcnt;

const struct af_alg_type *type;
void *private;


2020-07-07 15:35:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 05/36] mm/slub.c: fix corrupted freechain in deactivate_slab()

From: Dongli Zhang <[email protected]>

[ Upstream commit 52f23478081ae0dcdb95d1650ea1e7d52d586829 ]

The slub_debug is able to fix the corrupted slab freelist/page.
However, alloc_debug_processing() only checks the validity of current
and next freepointer during allocation path. As a result, once some
objects have their freepointers corrupted, deactivate_slab() may lead to
page fault.

Below is from a test kernel module when 'slub_debug=PUF,kmalloc-128
slub_nomerge'. The test kernel corrupts the freepointer of one free
object on purpose. Unfortunately, deactivate_slab() does not detect it
when iterating the freechain.

BUG: unable to handle page fault for address: 00000000123456f8
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
... ...
RIP: 0010:deactivate_slab.isra.92+0xed/0x490
... ...
Call Trace:
___slab_alloc+0x536/0x570
__slab_alloc+0x17/0x30
__kmalloc+0x1d9/0x200
ext4_htree_store_dirent+0x30/0xf0
htree_dirblock_to_tree+0xcb/0x1c0
ext4_htree_fill_tree+0x1bc/0x2d0
ext4_readdir+0x54f/0x920
iterate_dir+0x88/0x190
__x64_sys_getdents+0xa6/0x140
do_syscall_64+0x49/0x170
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Therefore, this patch adds extra consistency check in deactivate_slab().
Once an object's freepointer is corrupted, all following objects
starting at this object are isolated.

[[email protected]: fix build with CONFIG_SLAB_DEBUG=n]
Signed-off-by: Dongli Zhang <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Cc: Joe Jin <[email protected]>
Cc: Christoph Lameter <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
mm/slub.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)

diff --git a/mm/slub.c b/mm/slub.c
index b94ba8d35a025..473e0a8afb802 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -645,6 +645,20 @@ static void slab_fix(struct kmem_cache *s, char *fmt, ...)
va_end(args);
}

+static bool freelist_corrupted(struct kmem_cache *s, struct page *page,
+ void *freelist, void *nextfree)
+{
+ if ((s->flags & SLAB_CONSISTENCY_CHECKS) &&
+ !check_valid_pointer(s, page, nextfree)) {
+ object_err(s, page, freelist, "Freechain corrupt");
+ freelist = NULL;
+ slab_fix(s, "Isolate corrupted freechain");
+ return true;
+ }
+
+ return false;
+}
+
static void print_trailer(struct kmem_cache *s, struct page *page, u8 *p)
{
unsigned int off; /* Offset of last byte */
@@ -1328,6 +1342,11 @@ static inline void inc_slabs_node(struct kmem_cache *s, int node,
static inline void dec_slabs_node(struct kmem_cache *s, int node,
int objects) {}

+static bool freelist_corrupted(struct kmem_cache *s, struct page *page,
+ void *freelist, void *nextfree)
+{
+ return false;
+}
#endif /* CONFIG_SLUB_DEBUG */

/*
@@ -2013,6 +2032,14 @@ static void deactivate_slab(struct kmem_cache *s, struct page *page,
void *prior;
unsigned long counters;

+ /*
+ * If 'nextfree' is invalid, it is possible that the object at
+ * 'freelist' is already corrupted. So isolate all objects
+ * starting at 'freelist'.
+ */
+ if (freelist_corrupted(s, page, freelist, nextfree))
+ break;
+
do {
prior = page->freelist;
counters = page->counters;
--
2.25.1



2020-07-07 15:35:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 32/36] cifs: Fix the target file was deleted when rename failed.

From: Zhang Xiaoxu <[email protected]>

commit 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2 upstream.

When xfstest generic/035, we found the target file was deleted
if the rename return -EACESS.

In cifs_rename2, we unlink the positive target dentry if rename
failed with EACESS or EEXIST, even if the target dentry is positived
before rename. Then the existing file was deleted.

We should just delete the target file which created during the
rename.

Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Zhang Xiaoxu <[email protected]>
Cc: [email protected]
Signed-off-by: Steve French <[email protected]>
Reviewed-by: Aurelien Aptel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/inode.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -1783,6 +1783,7 @@ cifs_rename2(struct inode *source_dir, s
FILE_UNIX_BASIC_INFO *info_buf_target;
unsigned int xid;
int rc, tmprc;
+ bool new_target = d_really_is_negative(target_dentry);

if (flags & ~RENAME_NOREPLACE)
return -EINVAL;
@@ -1859,8 +1860,13 @@ cifs_rename2(struct inode *source_dir, s
*/

unlink_target:
- /* Try unlinking the target dentry if it's not negative */
- if (d_really_is_positive(target_dentry) && (rc == -EACCES || rc == -EEXIST)) {
+ /*
+ * If the target dentry was created during the rename, try
+ * unlinking it if it's not negative
+ */
+ if (new_target &&
+ d_really_is_positive(target_dentry) &&
+ (rc == -EACCES || rc == -EEXIST)) {
if (d_is_dir(target_dentry))
tmprc = cifs_rmdir(target_dir, target_dentry);
else


2020-07-07 15:35:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 36/36] efi: Make it possible to disable efivar_ssdt entirely

From: Peter Jones <[email protected]>

commit 435d1a471598752446a72ad1201b3c980526d869 upstream.

In most cases, such as CONFIG_ACPI_CUSTOM_DSDT and
CONFIG_ACPI_TABLE_UPGRADE, boot-time modifications to firmware tables
are tied to specific Kconfig options. Currently this is not the case
for modifying the ACPI SSDT via the efivar_ssdt kernel command line
option and associated EFI variable.

This patch adds CONFIG_EFI_CUSTOM_SSDT_OVERLAYS, which defaults
disabled, in order to allow enabling or disabling that feature during
the build.

Cc: <[email protected]>
Signed-off-by: Peter Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/firmware/efi/Kconfig | 11 +++++++++++
drivers/firmware/efi/efi.c | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)

--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -179,6 +179,17 @@ config RESET_ATTACK_MITIGATION
have been evicted, since otherwise it will trigger even on clean
reboots.

+config EFI_CUSTOM_SSDT_OVERLAYS
+ bool "Load custom ACPI SSDT overlay from an EFI variable"
+ depends on EFI_VARS && ACPI
+ default ACPI_TABLE_UPGRADE
+ help
+ Allow loading of an ACPI SSDT overlay from an EFI variable specified
+ by a kernel command line option.
+
+ See Documentation/admin-guide/acpi/ssdt-overlays.rst for more
+ information.
+
endmenu

config UEFI_CPER
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -236,7 +236,7 @@ static void generic_ops_unregister(void)
efivars_unregister(&generic_efivars);
}

-#if IS_ENABLED(CONFIG_ACPI)
+#ifdef CONFIG_EFI_CUSTOM_SSDT_OVERLAYS
#define EFIVAR_SSDT_NAME_MAX 16
static char efivar_ssdt[EFIVAR_SSDT_NAME_MAX] __initdata;
static int __init efivar_ssdt_setup(char *str)


2020-07-07 15:36:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 35/36] dm zoned: assign max_io_len correctly

From: Hou Tao <[email protected]>

commit 7b2377486767503d47265e4d487a63c651f6b55d upstream.

The unit of max_io_len is sector instead of byte (spotted through
code review), so fix it.

Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target")
Cc: [email protected]
Signed-off-by: Hou Tao <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>


---
drivers/md/dm-zoned-target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/dm-zoned-target.c
+++ b/drivers/md/dm-zoned-target.c
@@ -789,7 +789,7 @@ static int dmz_ctr(struct dm_target *ti,
}

/* Set target (no write same support) */
- ti->max_io_len = dev->zone_nr_sectors << 9;
+ ti->max_io_len = dev->zone_nr_sectors;
ti->num_flush_bios = 1;
ti->num_discard_bios = 1;
ti->num_write_zeroes_bios = 1;


2020-07-07 15:36:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 09/36] nvme-multipath: set bdi capabilities once

From: Keith Busch <[email protected]>

[ Upstream commit b2ce4d90690bd29ce5b554e203cd03682dd59697 ]

The queues' backing device info capabilities don't change with each
namespace revalidation. Set it only when each path's request_queue
is initially added to a multipath queue.

Signed-off-by: Keith Busch <[email protected]>
Reviewed-by: Sagi Grimberg <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/nvme/host/multipath.c | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index 588864beabd80..6f584a9515f42 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -11,6 +11,7 @@
* more details.
*/

+#include <linux/backing-dev.h>
#include <linux/moduleparam.h>
#include <trace/events/block.h>
#include "nvme.h"
@@ -521,6 +522,13 @@ void nvme_mpath_add_disk(struct nvme_ns *ns, struct nvme_id_ns *id)
nvme_mpath_set_live(ns);
mutex_unlock(&ns->head->lock);
}
+
+ if (bdi_cap_stable_pages_required(ns->queue->backing_dev_info)) {
+ struct backing_dev_info *info =
+ ns->head->disk->queue->backing_dev_info;
+
+ info->capabilities |= BDI_CAP_STABLE_WRITES;
+ }
}

void nvme_mpath_remove_disk(struct nvme_ns_head *head)
--
2.25.1



2020-07-07 15:36:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 19/36] hwmon: (max6697) Make sure the OVERT mask is set correctly

From: Chu Lin <[email protected]>

[ Upstream commit 016983d138cbe99a5c0aaae0103ee88f5300beb3 ]

Per the datasheet for max6697, OVERT mask and ALERT mask are different.
For example, the 7th bit of OVERT is the local channel but for alert
mask, the 6th bit is the local channel. Therefore, we can't apply the
same mask for both registers. In addition to that, the max6697 driver
is supposed to be compatibale with different models. I manually went over
all the listed chips and made sure all chip types have the same layout.

Testing;
mask value of 0x9 should map to 0x44 for ALERT and 0x84 for OVERT.
I used iotool to read the reg value back to verify. I only tested this
change on max6581.

Reference:
https://datasheets.maximintegrated.com/en/ds/MAX6581.pdf
https://datasheets.maximintegrated.com/en/ds/MAX6697.pdf
https://datasheets.maximintegrated.com/en/ds/MAX6699.pdf

Signed-off-by: Chu Lin <[email protected]>
Fixes: 5372d2d71c46e ("hwmon: Driver for Maxim MAX6697 and compatibles")
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/hwmon/max6697.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/max6697.c b/drivers/hwmon/max6697.c
index 221fd14920576..6df28fe0577da 100644
--- a/drivers/hwmon/max6697.c
+++ b/drivers/hwmon/max6697.c
@@ -47,8 +47,9 @@ static const u8 MAX6697_REG_CRIT[] = {
* Map device tree / platform data register bit map to chip bit map.
* Applies to alert register and over-temperature register.
*/
-#define MAX6697_MAP_BITS(reg) ((((reg) & 0x7e) >> 1) | \
+#define MAX6697_ALERT_MAP_BITS(reg) ((((reg) & 0x7e) >> 1) | \
(((reg) & 0x01) << 6) | ((reg) & 0x80))
+#define MAX6697_OVERT_MAP_BITS(reg) (((reg) >> 1) | (((reg) & 0x01) << 7))

#define MAX6697_REG_STAT(n) (0x44 + (n))

@@ -587,12 +588,12 @@ static int max6697_init_chip(struct max6697_data *data,
return ret;

ret = i2c_smbus_write_byte_data(client, MAX6697_REG_ALERT_MASK,
- MAX6697_MAP_BITS(pdata->alert_mask));
+ MAX6697_ALERT_MAP_BITS(pdata->alert_mask));
if (ret < 0)
return ret;

ret = i2c_smbus_write_byte_data(client, MAX6697_REG_OVERT_MASK,
- MAX6697_MAP_BITS(pdata->over_temperature_mask));
+ MAX6697_OVERT_MAP_BITS(pdata->over_temperature_mask));
if (ret < 0)
return ret;

--
2.25.1



2020-07-07 15:37:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 21/36] drm: sun4i: hdmi: Remove extra HPD polling

From: Chen-Yu Tsai <[email protected]>

[ Upstream commit bda8eaa6dee7525f4dac950810a85a88bf6c2ba0 ]

The HPD sense mechanism in Allwinner's old HDMI encoder hardware is more
or less an input-only GPIO. Other GPIO-based HPD implementations
directly return the current state, instead of polling for a specific
state and returning the other if that times out.

Remove the I/O polling from sun4i_hdmi_connector_detect() and directly
return a known state based on the current reading. This also gets rid
of excessive CPU usage by kworker as reported on Stack Exchange [1] and
Armbian forums [2].

[1] https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi
[2] https://forum.armbian.com/topic/14282-headless-systems-and-sun4i_drm_hdmi-a10a20/

Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 8ad36f574df8c..7e7fa8cef2ade 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -242,9 +242,8 @@ sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)
struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
unsigned long reg;

- if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
- reg & SUN4I_HDMI_HPD_HIGH,
- 0, 500000)) {
+ reg = readl(hdmi->base + SUN4I_HDMI_HPD_REG);
+ if (reg & SUN4I_HDMI_HPD_HIGH) {
cec_phys_addr_invalidate(hdmi->cec_adap);
return connector_status_disconnected;
}
--
2.25.1



2020-07-07 15:37:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 17/36] cxgb4: use correct type for all-mask IP address comparison

From: Rahul Lakkireddy <[email protected]>

[ Upstream commit f286dd8eaad5a2758750f407ab079298e0bcc8a5 ]

Use correct type to check for all-mask exact match IP addresses.

Fixes following sparse warnings due to big endian value checks
against 0xffffffff in is_addr_all_mask():
cxgb4_filter.c:977:25: warning: restricted __be32 degrades to integer
cxgb4_filter.c:983:37: warning: restricted __be32 degrades to integer
cxgb4_filter.c:984:37: warning: restricted __be32 degrades to integer
cxgb4_filter.c:985:37: warning: restricted __be32 degrades to integer
cxgb4_filter.c:986:37: warning: restricted __be32 degrades to integer

Fixes: 3eb8b62d5a26 ("cxgb4: add support to create hash-filters via tc-flower offload")
Signed-off-by: Rahul Lakkireddy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
index 7dddb9e748b81..86745f33a252d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
@@ -810,16 +810,16 @@ static bool is_addr_all_mask(u8 *ipmask, int family)
struct in_addr *addr;

addr = (struct in_addr *)ipmask;
- if (addr->s_addr == 0xffffffff)
+ if (ntohl(addr->s_addr) == 0xffffffff)
return true;
} else if (family == AF_INET6) {
struct in6_addr *addr6;

addr6 = (struct in6_addr *)ipmask;
- if (addr6->s6_addr32[0] == 0xffffffff &&
- addr6->s6_addr32[1] == 0xffffffff &&
- addr6->s6_addr32[2] == 0xffffffff &&
- addr6->s6_addr32[3] == 0xffffffff)
+ if (ntohl(addr6->s6_addr32[0]) == 0xffffffff &&
+ ntohl(addr6->s6_addr32[1]) == 0xffffffff &&
+ ntohl(addr6->s6_addr32[2]) == 0xffffffff &&
+ ntohl(addr6->s6_addr32[3]) == 0xffffffff)
return true;
}
return false;
--
2.25.1



2020-07-07 18:17:43

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 10/36] nvme: fix possible deadlock when I/O is blocked

Hi!

> From: Sagi Grimberg <[email protected]>
>
> [ Upstream commit 3b4b19721ec652ad2c4fe51dfbe5124212b5f581 ]
>
> Revert fab7772bfbcf ("nvme-multipath: revalidate nvme_ns_head gendisk
> in nvme_validate_ns")
>
> When adding a new namespace to the head disk (via nvme_mpath_set_live)
> we will see partition scan which triggers I/O on the mpath device node.
> This process will usually be triggered from the scan_work which holds
> the scan_lock. If I/O blocks (if we got ana change currently have only
> available paths but none are accessible) this can deadlock on the head
> disk bd_mutex as both partition scan I/O takes it, and head disk revalidation
> takes it to check for resize (also triggered from scan_work on a different
> path). See trace [1].
>
> The mpath disk revalidation was originally added to detect online disk
> size change, but this is no longer needed since commit cb224c3af4df
> ("nvme: Convert to use set_capacity_revalidate_and_notify") which
> already

AFAICT cb224c3af4df is not applied to 4.19-stable series, so this is
not safe according to the changelog.

cb224c3af4df is simple enough, but AFAICT
set_capacity_revalidate_and_notify() is missing in 4.19.132-rc1.

Best regards,
Pavel

> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 0d60f2f8f3eec..5c9326777334f 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1602,7 +1602,6 @@ static void __nvme_revalidate_disk(struct gendisk *disk, struct nvme_id_ns *id)
> if (ns->head->disk) {
> nvme_update_disk_info(ns->head->disk, ns, id);
> blk_queue_stack_limits(ns->head->disk->queue, ns->queue);
> - revalidate_disk(ns->head->disk);
> }
> #endif
> }

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachments:
(No filename) (1.85 kB)
 signature.asc (188.00 B)
Digital signature Download all attachments

2020-07-07 21:28:59

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 13/36] crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()

Hi!

> This patch also modifies the main refcnt to include both normal
> and nokey sockets. This way we don't have to fudge the nokey
> ref count when a socket changes from nokey to normal.
>
> Credits go to Mauricio Faria de Oliveira who diagnosed this bug
> and sent a patch for it:


> @@ -308,12 +302,14 @@ int af_alg_accept(struct sock *sk, struc
>
> sk2->sk_family = PF_ALG;
>
> - if (nokey || !ask->refcnt++)
> + if (atomic_inc_return_relaxed(&ask->refcnt) == 1)
> sock_hold(sk);
> - ask->nokey_refcnt += nokey;
> + if (nokey) {
> + atomic_inc(&ask->nokey_refcnt);
> + atomic_set(&alg_sk(sk2)->nokey_refcnt, 1);
> + }

Should we set the nokey_refcnt to 0 using atomic_set, too?
Aternatively, should the nokey_refcnt be initialized using
ATOMIC_INIT()?

Best regards,
Pavel


--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachments:
(No filename) (973.00 B)
 signature.asc (188.00 B)
Digital signature Download all attachments

2020-07-07 21:35:13

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 17/36] cxgb4: use correct type for all-mask IP address comparison

Hi!

> From: Rahul Lakkireddy <[email protected]>
>
> [ Upstream commit f286dd8eaad5a2758750f407ab079298e0bcc8a5 ]
>
> Use correct type to check for all-mask exact match IP addresses.
>
> Fixes following sparse warnings due to big endian value checks
> against 0xffffffff in is_addr_all_mask():
> cxgb4_filter.c:977:25: warning: restricted __be32 degrades to integer
> cxgb4_filter.c:983:37: warning: restricted __be32 degrades to integer
> cxgb4_filter.c:984:37: warning: restricted __be32 degrades to integer
> cxgb4_filter.c:985:37: warning: restricted __be32 degrades to integer
> cxgb4_filter.c:986:37: warning: restricted __be32 degrades to integer

> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
> index 7dddb9e748b81..86745f33a252d 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
> @@ -810,16 +810,16 @@ static bool is_addr_all_mask(u8 *ipmask, int family)
> struct in_addr *addr;
>
> addr = (struct in_addr *)ipmask;
> - if (addr->s_addr == 0xffffffff)
> + if (ntohl(addr->s_addr) == 0xffffffff)

Endianity does not really matter for ~0, but can compiler figure it
out?

would it be better to do these tests as

if (foo == htonl(0xffffffff))

to make it clear to the compiler?

Thanks,
Pavel

> } else if (family == AF_INET6) {
> struct in6_addr *addr6;
>
> addr6 = (struct in6_addr *)ipmask;
> - if (addr6->s6_addr32[0] == 0xffffffff &&
> - addr6->s6_addr32[1] == 0xffffffff &&
> - addr6->s6_addr32[2] == 0xffffffff &&
> - addr6->s6_addr32[3] == 0xffffffff)
> + if (ntohl(addr6->s6_addr32[0]) == 0xffffffff &&
> + ntohl(addr6->s6_addr32[1]) == 0xffffffff &&
> + ntohl(addr6->s6_addr32[2]) == 0xffffffff &&
> + ntohl(addr6->s6_addr32[3]) == 0xffffffff)
> return true;
> }
> return false;

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachments:
(No filename) (2.08 kB)
 signature.asc (188.00 B)
Digital signature Download all attachments

2020-07-08 00:05:30

by Herbert Xu

[permalink] [raw]
Subject: Re: [PATCH 4.19 13/36] crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()

On Tue, Jul 07, 2020 at 11:25:31PM +0200, Pavel Machek wrote:
>
> > @@ -308,12 +302,14 @@ int af_alg_accept(struct sock *sk, struc
> >
> > sk2->sk_family = PF_ALG;
> >
> > - if (nokey || !ask->refcnt++)
> > + if (atomic_inc_return_relaxed(&ask->refcnt) == 1)
> > sock_hold(sk);
> > - ask->nokey_refcnt += nokey;
> > + if (nokey) {
> > + atomic_inc(&ask->nokey_refcnt);
> > + atomic_set(&alg_sk(sk2)->nokey_refcnt, 1);
> > + }
>
> Should we set the nokey_refcnt to 0 using atomic_set, too?
> Aternatively, should the nokey_refcnt be initialized using
> ATOMIC_INIT()?

What are you asking for? It's already being set with atomic_set.
Or are you asking it to be set to 0 instead of 1? No it needs to
be 1 for the socket destructor.

Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2020-07-08 03:08:43

by Sasha Levin

[permalink] [raw]
Subject: Re: [PATCH 4.19 10/36] nvme: fix possible deadlock when I/O is blocked

On Tue, Jul 07, 2020 at 08:16:41PM +0200, Pavel Machek wrote:
>Hi!
>
>> From: Sagi Grimberg <[email protected]>
>>
>> [ Upstream commit 3b4b19721ec652ad2c4fe51dfbe5124212b5f581 ]
>>
>> Revert fab7772bfbcf ("nvme-multipath: revalidate nvme_ns_head gendisk
>> in nvme_validate_ns")
>>
>> When adding a new namespace to the head disk (via nvme_mpath_set_live)
>> we will see partition scan which triggers I/O on the mpath device node.
>> This process will usually be triggered from the scan_work which holds
>> the scan_lock. If I/O blocks (if we got ana change currently have only
>> available paths but none are accessible) this can deadlock on the head
>> disk bd_mutex as both partition scan I/O takes it, and head disk revalidation
>> takes it to check for resize (also triggered from scan_work on a different
>> path). See trace [1].
>>
>> The mpath disk revalidation was originally added to detect online disk
>> size change, but this is no longer needed since commit cb224c3af4df
>> ("nvme: Convert to use set_capacity_revalidate_and_notify") which
>> already
>
>AFAICT cb224c3af4df is not applied to 4.19-stable series, so this is
>not safe according to the changelog.
>
>cb224c3af4df is simple enough, but AFAICT
>set_capacity_revalidate_and_notify() is missing in 4.19.132-rc1.

Good point... It might be the case that e598a72faeb5 ("block/genhd:
Notify udev about capacity change") is safe to take along with
cb224c3af4df.

I'll look at it once these releases are out, but for now I'll drop this
commit. Thanks!

--
Thanks,
Sasha

2020-07-08 05:56:56

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/36] 4.19.132-rc1 review

On Tue, 7 Jul 2020 at 20:48, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.132 release.
> There are 36 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 Thu, 09 Jul 2020 14:57:34 +0000.
> 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.132-rc1.gz
> 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

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 4.19.132-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 168e2945aaf526364ca3aa3e674490d363c32a33
git describe: v4.19.130-164-g168e2945aaf5
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.130-164-g168e2945aaf5

No regressions (compared to build v4.19.130)

No fixes (compared to build v4.19.130)

Ran 33084 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* v4l2-compliance
* kvm-unit-tests
* ltp-controllers-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-io-tests
* network-basic-tests
* perf
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net

--
Linaro LKFT
https://lkft.linaro.org

2020-07-08 08:42:38

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/36] 4.19.132-rc1 review


On 07/07/2020 16:16, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.132 release.
> There are 36 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 Thu, 09 Jul 2020 14:57:34 +0000.
> 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.132-rc1.gz
> 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

All tests are passing for Tegra ...

Test results for stable-v4.19:
11 builds: 11 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 38 pass, 0 fail

Linux version: 4.19.132-rc1-g168e2945aaf5
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2020-07-08 10:43:10

by Chris Paterson

[permalink] [raw]
Subject: RE: [PATCH 4.19 00/36] 4.19.132-rc1 review

Hello Greg,

> From: [email protected] <[email protected]> On
> Behalf Of Greg Kroah-Hartman
> Sent: 07 July 2020 16:17
>
> This is the start of the stable review cycle for the 4.19.132 release.
> There are 36 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 Thu, 09 Jul 2020 14:57:34 +0000.
> Anything received after that time might be too late.

No build/boot issues seen for CIP configs with Linux 4.19.132-rc1 (168e2945aaf5).

Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/164002971
GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=168e29#table

Kind regards, Chris

>
> 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.132-rc1.gz
> 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 <[email protected]>
> Linux 4.19.132-rc1
>
> Peter Jones <[email protected]>
> efi: Make it possible to disable efivar_ssdt entirely
>
> Hou Tao <[email protected]>
> dm zoned: assign max_io_len correctly
>
> Marc Zyngier <[email protected]>
> irqchip/gic: Atomically update affinity
>
> Hauke Mehrtens <[email protected]>
> MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen
>
> Zhang Xiaoxu <[email protected]>
> cifs: Fix the target file was deleted when rename failed.
>
> Paul Aurich <[email protected]>
> SMB3: Honor lease disabling for multiuser mounts
>
> Paul Aurich <[email protected]>
> SMB3: Honor persistent/resilient handle flags for multiuser mounts
>
> Paul Aurich <[email protected]>
> SMB3: Honor 'seal' flag for multiuser mounts
>
> Greg Kroah-Hartman <[email protected]>
> Revert "ALSA: usb-audio: Improve frames size computation"
>
> J. Bruce Fields <[email protected]>
> nfsd: apply umask on fs without ACL support
>
> Wolfram Sang <[email protected]>
> i2c: mlxcpld: check correct size of maximum RECV_LEN packet
>
> Chris Packham <[email protected]>
> i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665
>
> Christoph Hellwig <[email protected]>
> nvme: fix a crash in nvme_mpath_add_disk
>
> Paul Aurich <[email protected]>
> SMB3: Honor 'posix' flag for multiuser mounts
>
> Hou Tao <[email protected]>
> virtio-blk: free vblk-vqs in error path of virtblk_probe()
>
> Chen-Yu Tsai <[email protected]>
> drm: sun4i: hdmi: Remove extra HPD polling
>
> Misono Tomohiro <[email protected]>
> hwmon: (acpi_power_meter) Fix potential memory leak in
> acpi_power_meter_add()
>
> Chu Lin <[email protected]>
> hwmon: (max6697) Make sure the OVERT mask is set correctly
>
> Rahul Lakkireddy <[email protected]>
> cxgb4: fix SGE queue dump destination buffer context
>
> Rahul Lakkireddy <[email protected]>
> cxgb4: use correct type for all-mask IP address comparison
>
> Rahul Lakkireddy <[email protected]>
> cxgb4: parse TC-U32 key values and masks natively
>
> Rahul Lakkireddy <[email protected]>
> cxgb4: use unaligned conversion for fetching timestamp
>
> Chen Tao <[email protected]>
> drm/msm/dpu: fix error return code in dpu_encoder_init
>
> Herbert Xu <[email protected]>
> crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()
>
> Douglas Anderson <[email protected]>
> kgdb: Avoid suspicious RCU usage warning
>
> Anton Eidelman <[email protected]>
> nvme-multipath: fix deadlock between ana_work and scan_work
>
> Sagi Grimberg <[email protected]>
> nvme: fix possible deadlock when I/O is blocked
>
> Keith Busch <[email protected]>
> nvme-multipath: set bdi capabilities once
>
> Christian Borntraeger <[email protected]>
> s390/debug: avoid kernel warning on too large number of pages
>
> Zqiang <[email protected]>
> usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect
>
> Qian Cai <[email protected]>
> mm/slub: fix stack overruns with SLUB_STATS
>
> Dongli Zhang <[email protected]>
> mm/slub.c: fix corrupted freechain in deactivate_slab()
>
> Tuomas Tynkkynen <[email protected]>
> usbnet: smsc95xx: Fix use-after-free after removal
>
> Borislav Petkov <[email protected]>
> EDAC/amd64: Read back the scrub rate PCI register on F15h
>
> Hugh Dickins <[email protected]>
> mm: fix swap cache node allocation mask
>
> Filipe Manana <[email protected]>
> btrfs: fix a block group ref counter leak after failure to remove block group
>
>
> -------------
>
> Diffstat:
>
> Makefile | 4 +-
> arch/mips/kernel/traps.c | 1 +
> arch/s390/kernel/debug.c | 3 +-
> crypto/af_alg.c | 26 ++---
> crypto/algif_aead.c | 9 +-
> crypto/algif_hash.c | 9 +-
> crypto/algif_skcipher.c | 9 +-
> drivers/block/virtio_blk.c | 1 +
> drivers/edac/amd64_edac.c | 2 +
> drivers/firmware/efi/Kconfig | 11 ++
> drivers/firmware/efi/efi.c | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 5 +-
> drivers/hwmon/acpi_power_meter.c | 4 +-
> drivers/hwmon/max6697.c | 7 +-
> drivers/i2c/algos/i2c-algo-pca.c | 3 +-
> drivers/i2c/busses/i2c-mlxcpld.c | 4 +-
> drivers/irqchip/irq-gic.c | 14 +--
> drivers/md/dm-zoned-target.c | 2 +-
> drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c | 6 +-
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 10 +-
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c | 18 +--
> .../ethernet/chelsio/cxgb4/cxgb4_tc_u32_parse.h | 122
> ++++++++++++++-------
> drivers/net/ethernet/chelsio/cxgb4/sge.c | 2 +-
> drivers/net/usb/smsc95xx.c | 2 +-
> drivers/nvme/host/core.c | 1 -
> drivers/nvme/host/multipath.c | 33 ++++--
> drivers/usb/misc/usbtest.c | 1 +
> fs/btrfs/extent-tree.c | 19 ++--
> fs/cifs/connect.c | 9 +-
> fs/cifs/inode.c | 10 +-
> fs/nfsd/vfs.c | 6 +
> include/crypto/if_alg.h | 4 +-
> kernel/debug/debug_core.c | 4 +
> mm/slub.c | 30 ++++-
> mm/swap_state.c | 3 +-
> sound/usb/card.h | 4 -
> sound/usb/endpoint.c | 43 +-------
> sound/usb/endpoint.h | 1 -
> sound/usb/pcm.c | 2 -
> 40 files changed, 256 insertions(+), 192 deletions(-)
>

2020-07-08 12:51:23

by Rahul Lakkireddy

[permalink] [raw]
Subject: Re: [PATCH 4.19 17/36] cxgb4: use correct type for all-mask IP address comparison

On Tuesday, July 07/07/20, 2020 at 23:33:26 +0200, Pavel Machek wrote:
> Hi!
>
> > From: Rahul Lakkireddy <[email protected]>
> >
> > [ Upstream commit f286dd8eaad5a2758750f407ab079298e0bcc8a5 ]
> >
> > Use correct type to check for all-mask exact match IP addresses.
> >
> > Fixes following sparse warnings due to big endian value checks
> > against 0xffffffff in is_addr_all_mask():
> > cxgb4_filter.c:977:25: warning: restricted __be32 degrades to integer
> > cxgb4_filter.c:983:37: warning: restricted __be32 degrades to integer
> > cxgb4_filter.c:984:37: warning: restricted __be32 degrades to integer
> > cxgb4_filter.c:985:37: warning: restricted __be32 degrades to integer
> > cxgb4_filter.c:986:37: warning: restricted __be32 degrades to integer
>
> > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
> > index 7dddb9e748b81..86745f33a252d 100644
> > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
> > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
> > @@ -810,16 +810,16 @@ static bool is_addr_all_mask(u8 *ipmask, int family)
> > struct in_addr *addr;
> >
> > addr = (struct in_addr *)ipmask;
> > - if (addr->s_addr == 0xffffffff)
> > + if (ntohl(addr->s_addr) == 0xffffffff)
>
> Endianity does not really matter for ~0, but can compiler figure it
> out?
>
> would it be better to do these tests as
>
> if (foo == htonl(0xffffffff))
>
> to make it clear to the compiler?
>

Sure, I'll update all checks to follow above approach. Will send a
patch.

>
> > } else if (family == AF_INET6) {
> > struct in6_addr *addr6;
> >
> > addr6 = (struct in6_addr *)ipmask;
> > - if (addr6->s6_addr32[0] == 0xffffffff &&
> > - addr6->s6_addr32[1] == 0xffffffff &&
> > - addr6->s6_addr32[2] == 0xffffffff &&
> > - addr6->s6_addr32[3] == 0xffffffff)
> > + if (ntohl(addr6->s6_addr32[0]) == 0xffffffff &&
> > + ntohl(addr6->s6_addr32[1]) == 0xffffffff &&
> > + ntohl(addr6->s6_addr32[2]) == 0xffffffff &&
> > + ntohl(addr6->s6_addr32[3]) == 0xffffffff)
> > return true;
> > }
> > return false;
>

Thanks,
Rahul

2020-07-08 15:07:51

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/36] 4.19.132-rc1 review

On 7/7/20 9:16 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.132 release.
> There are 36 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 Thu, 09 Jul 2020 14:57:34 +0000.
> 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.132-rc1.gz
> 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
>

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

2020-07-08 15:18:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/36] 4.19.132-rc1 review

On Wed, Jul 08, 2020 at 10:41:35AM +0000, Chris Paterson wrote:
> Hello Greg,
>
> > From: [email protected] <[email protected]> On
> > Behalf Of Greg Kroah-Hartman
> > Sent: 07 July 2020 16:17
> >
> > This is the start of the stable review cycle for the 4.19.132 release.
> > There are 36 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 Thu, 09 Jul 2020 14:57:34 +0000.
> > Anything received after that time might be too late.
>
> No build/boot issues seen for CIP configs with Linux 4.19.132-rc1 (168e2945aaf5).
>
> Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/164002971
> GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
> Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=168e29#table

Thanks for testing two of these and letting me know.

greg k-h

2020-07-08 17:55:25

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/36] 4.19.132-rc1 review

On Tue, Jul 07, 2020 at 05:16:52PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.132 release.
> There are 36 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.
>
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 420 pass: 420 fail: 0

Guenter