2020-07-07 15:12:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 00/19] 4.4.230-rc1 review

This is the start of the stable review cycle for the 4.4.230 release.
There are 19 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.4.230-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 4.4.230-rc1

Vasily Averin <[email protected]>
netfilter: nf_conntrack_h323: lost .data_len definition for Q.931/ipv6

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 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"

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

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

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

Shile Zhang <[email protected]>
sched/rt: Show the 'sched_rr_timeslice' SCHED_RR timeslice tuning knob in milliseconds

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

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

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 data block group relocation failure due to concurrent scrub

Anand Jain <[email protected]>
btrfs: cow_file_range() num_bytes and disk_num_bytes are same


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

Diffstat:

Makefile | 4 ++--
arch/mips/kernel/traps.c | 1 +
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/hwmon/acpi_power_meter.c | 4 +++-
drivers/hwmon/max6697.c | 7 +++---
drivers/i2c/algos/i2c-algo-pca.c | 3 ++-
drivers/usb/misc/usbtest.c | 1 +
fs/btrfs/inode.c | 36 ++++++++++++++++++++--------
fs/cifs/connect.c | 3 +++
fs/cifs/inode.c | 10 ++++++--
include/crypto/if_alg.h | 4 ++--
include/linux/sched/sysctl.h | 1 +
kernel/debug/debug_core.c | 4 ++++
kernel/sched/core.c | 5 ++--
kernel/sched/rt.c | 1 +
kernel/sysctl.c | 2 +-
mm/slub.c | 3 ++-
mm/swap_state.c | 3 ++-
net/netfilter/nf_conntrack_h323_main.c | 1 +
sound/usb/card.h | 4 ----
sound/usb/endpoint.c | 43 ++++------------------------------
sound/usb/endpoint.h | 1 -
sound/usb/pcm.c | 2 --
28 files changed, 95 insertions(+), 104 deletions(-)



2020-07-07 15:13:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 08/19] 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
@@ -130,21 +130,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);
@@ -189,7 +183,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);
@@ -238,7 +232,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;
@@ -305,12 +299,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
@@ -528,7 +528,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;
@@ -540,11 +540,8 @@ static int aead_check_key(struct socket
if (!tfm->has_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
@@ -252,7 +252,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;
@@ -264,11 +264,8 @@ static int hash_check_key(struct socket
if (!tfm->has_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
@@ -774,7 +774,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;
@@ -786,11 +786,8 @@ static int skcipher_check_key(struct soc
if (!tfm->has_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
@@ -30,8 +30,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:13:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 06/19] usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect

From: Zqiang <[email protected]>

[ Upstream commit 28ebeb8db77035e058a510ce9bd17c2b9a009dba ]

BUG: memory leak
unreferenced object 0xffff888055046e00 (size 256):
comm "kworker/2:9", pid 2570, jiffies 4294942129 (age 1095.500s)
hex dump (first 32 bytes):
00 70 04 55 80 88 ff ff 18 bb 5a 81 ff ff ff ff .p.U......Z.....
f5 96 78 81 ff ff ff ff 37 de 8e 81 ff ff ff ff ..x.....7.......
backtrace:
[<00000000d121dccf>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000d121dccf>] slab_post_alloc_hook mm/slab.h:586 [inline]
[<00000000d121dccf>] slab_alloc_node mm/slub.c:2786 [inline]
[<00000000d121dccf>] slab_alloc mm/slub.c:2794 [inline]
[<00000000d121dccf>] kmem_cache_alloc_trace+0x15e/0x2d0 mm/slub.c:2811
[<000000005c3c3381>] kmalloc include/linux/slab.h:555 [inline]
[<000000005c3c3381>] usbtest_probe+0x286/0x19d0
drivers/usb/misc/usbtest.c:2790
[<000000001cec6910>] usb_probe_interface+0x2bd/0x870
drivers/usb/core/driver.c:361
[<000000007806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551
[<00000000a3308c3e>] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724
[<000000003ef66004>] __device_attach_driver+0x1b6/0x240
drivers/base/dd.c:831
[<00000000eee53e97>] bus_for_each_drv+0x14e/0x1e0 drivers/base/bus.c:431
[<00000000bb0648d0>] __device_attach+0x1f9/0x350 drivers/base/dd.c:897
[<00000000838b324a>] device_initial_probe+0x1a/0x20 drivers/base/dd.c:944
[<0000000030d501c1>] bus_probe_device+0x1e1/0x280 drivers/base/bus.c:491
[<000000005bd7adef>] device_add+0x131d/0x1c40 drivers/base/core.c:2504
[<00000000a0937814>] usb_set_configuration+0xe84/0x1ab0
drivers/usb/core/message.c:2030
[<00000000e3934741>] generic_probe+0x6a/0xe0 drivers/usb/core/generic.c:210
[<0000000098ade0f1>] usb_probe_device+0x90/0xd0
drivers/usb/core/driver.c:266
[<000000007806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551
[<00000000a3308c3e>] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724

Acked-by: Alan Stern <[email protected]>
Reported-by: Kyungtae Kim <[email protected]>
Signed-off-by: Zqiang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/usb/misc/usbtest.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index bc92a498ec03d..9f19aa950bb19 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -2703,6 +2703,7 @@ static void usbtest_disconnect(struct usb_interface *intf)

usb_set_intfdata(intf, NULL);
dev_dbg(&intf->dev, "disconnect\n");
+ kfree(dev->buf);
kfree(dev);
}

--
2.25.1



2020-07-07 15:13:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 02/19] btrfs: fix data block group relocation failure due to concurrent scrub

From: Filipe Manana <[email protected]>

[ Upstream commit 432cd2a10f1c10cead91fe706ff5dc52f06d642a ]

When running relocation of a data block group while scrub is running in
parallel, it is possible that the relocation will fail and abort the
current transaction with an -EINVAL error:

[134243.988595] BTRFS info (device sdc): found 14 extents, stage: move data extents
[134243.999871] ------------[ cut here ]------------
[134244.000741] BTRFS: Transaction aborted (error -22)
[134244.001692] WARNING: CPU: 0 PID: 26954 at fs/btrfs/ctree.c:1071 __btrfs_cow_block+0x6a7/0x790 [btrfs]
[134244.003380] Modules linked in: btrfs blake2b_generic xor raid6_pq (...)
[134244.012577] CPU: 0 PID: 26954 Comm: btrfs Tainted: G W 5.6.0-rc7-btrfs-next-58 #5
[134244.014162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[134244.016184] RIP: 0010:__btrfs_cow_block+0x6a7/0x790 [btrfs]
[134244.017151] Code: 48 c7 c7 (...)
[134244.020549] RSP: 0018:ffffa41607863888 EFLAGS: 00010286
[134244.021515] RAX: 0000000000000000 RBX: ffff9614bdfe09c8 RCX: 0000000000000000
[134244.022822] RDX: 0000000000000001 RSI: ffffffffb3d63980 RDI: 0000000000000001
[134244.024124] RBP: ffff961589e8c000 R08: 0000000000000000 R09: 0000000000000001
[134244.025424] R10: ffffffffc0ae5955 R11: 0000000000000000 R12: ffff9614bd530d08
[134244.026725] R13: ffff9614ced41b88 R14: ffff9614bdfe2a48 R15: 0000000000000000
[134244.028024] FS: 00007f29b63c08c0(0000) GS:ffff9615ba600000(0000) knlGS:0000000000000000
[134244.029491] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[134244.030560] CR2: 00007f4eb339b000 CR3: 0000000130d6e006 CR4: 00000000003606f0
[134244.031997] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[134244.033153] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[134244.034484] Call Trace:
[134244.034984] btrfs_cow_block+0x12b/0x2b0 [btrfs]
[134244.035859] do_relocation+0x30b/0x790 [btrfs]
[134244.036681] ? do_raw_spin_unlock+0x49/0xc0
[134244.037460] ? _raw_spin_unlock+0x29/0x40
[134244.038235] relocate_tree_blocks+0x37b/0x730 [btrfs]
[134244.039245] relocate_block_group+0x388/0x770 [btrfs]
[134244.040228] btrfs_relocate_block_group+0x161/0x2e0 [btrfs]
[134244.041323] btrfs_relocate_chunk+0x36/0x110 [btrfs]
[134244.041345] btrfs_balance+0xc06/0x1860 [btrfs]
[134244.043382] ? btrfs_ioctl_balance+0x27c/0x310 [btrfs]
[134244.045586] btrfs_ioctl_balance+0x1ed/0x310 [btrfs]
[134244.045611] btrfs_ioctl+0x1880/0x3760 [btrfs]
[134244.049043] ? do_raw_spin_unlock+0x49/0xc0
[134244.049838] ? _raw_spin_unlock+0x29/0x40
[134244.050587] ? __handle_mm_fault+0x11b3/0x14b0
[134244.051417] ? ksys_ioctl+0x92/0xb0
[134244.052070] ksys_ioctl+0x92/0xb0
[134244.052701] ? trace_hardirqs_off_thunk+0x1a/0x1c
[134244.053511] __x64_sys_ioctl+0x16/0x20
[134244.054206] do_syscall_64+0x5c/0x280
[134244.054891] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[134244.055819] RIP: 0033:0x7f29b51c9dd7
[134244.056491] Code: 00 00 00 (...)
[134244.059767] RSP: 002b:00007ffcccc1dd08 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
[134244.061168] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f29b51c9dd7
[134244.062474] RDX: 00007ffcccc1dda0 RSI: 00000000c4009420 RDI: 0000000000000003
[134244.063771] RBP: 0000000000000003 R08: 00005565cea4b000 R09: 0000000000000000
[134244.065032] R10: 0000000000000541 R11: 0000000000000202 R12: 00007ffcccc2060a
[134244.066327] R13: 00007ffcccc1dda0 R14: 0000000000000002 R15: 00007ffcccc1dec0
[134244.067626] irq event stamp: 0
[134244.068202] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[134244.069351] hardirqs last disabled at (0): [<ffffffffb2abdedf>] copy_process+0x74f/0x2020
[134244.070909] softirqs last enabled at (0): [<ffffffffb2abdedf>] copy_process+0x74f/0x2020
[134244.072392] softirqs last disabled at (0): [<0000000000000000>] 0x0
[134244.073432] ---[ end trace bd7c03622e0b0a99 ]---

The -EINVAL error comes from the following chain of function calls:

__btrfs_cow_block() <-- aborts the transaction
btrfs_reloc_cow_block()
replace_file_extents()
get_new_location() <-- returns -EINVAL

When relocating a data block group, for each allocated extent of the block
group, we preallocate another extent (at prealloc_file_extent_cluster()),
associated with the data relocation inode, and then dirty all its pages.
These preallocated extents have, and must have, the same size that extents
from the data block group being relocated have.

Later before we start the relocation stage that updates pointers (bytenr
field of file extent items) to point to the the new extents, we trigger
writeback for the data relocation inode. The expectation is that writeback
will write the pages to the previously preallocated extents, that it
follows the NOCOW path. That is generally the case, however, if a scrub
is running it may have turned the block group that contains those extents
into RO mode, in which case writeback falls back to the COW path.

However in the COW path instead of allocating exactly one extent with the
expected size, the allocator may end up allocating several smaller extents
due to free space fragmentation - because we tell it at cow_file_range()
that the minimum allocation size can match the filesystem's sector size.
This later breaks the relocation's expectation that an extent associated
to a file extent item in the data relocation inode has the same size as
the respective extent pointed by a file extent item in another tree - in
this case the extent to which the relocation inode poins to is smaller,
causing relocation.c:get_new_location() to return -EINVAL.

For example, if we are relocating a data block group X that has a logical
address of X and the block group has an extent allocated at the logical
address X + 128KiB with a size of 64KiB:

1) At prealloc_file_extent_cluster() we allocate an extent for the data
relocation inode with a size of 64KiB and associate it to the file
offset 128KiB (X + 128KiB - X) of the data relocation inode. This
preallocated extent was allocated at block group Z;

2) A scrub running in parallel turns block group Z into RO mode and
starts scrubing its extents;

3) Relocation triggers writeback for the data relocation inode;

4) When running delalloc (btrfs_run_delalloc_range()), we try first the
NOCOW path because the data relocation inode has BTRFS_INODE_PREALLOC
set in its flags. However, because block group Z is in RO mode, the
NOCOW path (run_delalloc_nocow()) falls back into the COW path, by
calling cow_file_range();

5) At cow_file_range(), in the first iteration of the while loop we call
btrfs_reserve_extent() to allocate a 64KiB extent and pass it a minimum
allocation size of 4KiB (fs_info->sectorsize). Due to free space
fragmentation, btrfs_reserve_extent() ends up allocating two extents
of 32KiB each, each one on a different iteration of that while loop;

6) Writeback of the data relocation inode completes;

7) Relocation proceeds and ends up at relocation.c:replace_file_extents(),
with a leaf which has a file extent item that points to the data extent
from block group X, that has a logical address (bytenr) of X + 128KiB
and a size of 64KiB. Then it calls get_new_location(), which does a
lookup in the data relocation tree for a file extent item starting at
offset 128KiB (X + 128KiB - X) and belonging to the data relocation
inode. It finds a corresponding file extent item, however that item
points to an extent that has a size of 32KiB, which doesn't match the
expected size of 64KiB, resuling in -EINVAL being returned from this
function and propagated up to __btrfs_cow_block(), which aborts the
current transaction.

To fix this make sure that at cow_file_range() when we call the allocator
we pass it a minimum allocation size corresponding the desired extent size
if the inode belongs to the data relocation tree, otherwise pass it the
filesystem's sector size as the minimum allocation size.

CC: [email protected] # 4.4+
Reviewed-by: Josef Bacik <[email protected]>
Signed-off-by: Filipe Manana <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/btrfs/inode.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index ef8ed0cd8075a..b1125778b9080 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -926,6 +926,7 @@ static noinline int cow_file_range(struct inode *inode,
u64 alloc_hint = 0;
u64 num_bytes;
unsigned long ram_size;
+ u64 min_alloc_size;
u64 cur_alloc_size;
u64 blocksize = root->sectorsize;
struct btrfs_key ins;
@@ -972,12 +973,28 @@ static noinline int cow_file_range(struct inode *inode,
alloc_hint = get_extent_allocation_hint(inode, start, num_bytes);
btrfs_drop_extent_cache(inode, start, start + num_bytes - 1, 0);

+ /*
+ * Relocation relies on the relocated extents to have exactly the same
+ * size as the original extents. Normally writeback for relocation data
+ * extents follows a NOCOW path because relocation preallocates the
+ * extents. However, due to an operation such as scrub turning a block
+ * group to RO mode, it may fallback to COW mode, so we must make sure
+ * an extent allocated during COW has exactly the requested size and can
+ * not be split into smaller extents, otherwise relocation breaks and
+ * fails during the stage where it updates the bytenr of file extent
+ * items.
+ */
+ if (root->root_key.objectid == BTRFS_DATA_RELOC_TREE_OBJECTID)
+ min_alloc_size = num_bytes;
+ else
+ min_alloc_size = root->sectorsize;
+
while (num_bytes > 0) {
unsigned long op;

cur_alloc_size = num_bytes;
ret = btrfs_reserve_extent(root, cur_alloc_size,
- root->sectorsize, 0, alloc_hint,
+ min_alloc_size, 0, alloc_hint,
&ins, 1, 1);
if (ret < 0)
goto out_unlock;
--
2.25.1



2020-07-07 15:13:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 12/19] 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 1e5cd39d0cc2f..bdc3efacd0d25 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -757,6 +757,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:13:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 14/19] Revert "ALSA: usb-audio: Improve frames size computation"

From: Greg Kroah-Hartman <[email protected]>

This reverts commit 02c56650f3c118d3752122996d96173d26bb13aa which is
commit f0bd62b64016508938df9babe47f65c2c727d25c upstream.

It causes a number of reported issues and a fix for it has not hit
Linus's tree yet. Revert this to resolve those problems.

Cc: Alexander Tsoy <[email protected]>
Cc: Takashi Iwai <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: Hans de Goede <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/usb/card.h | 4 ----
sound/usb/endpoint.c | 43 +++++--------------------------------------
sound/usb/endpoint.h | 1 -
sound/usb/pcm.c | 2 --
4 files changed, 5 insertions(+), 45 deletions(-)

--- a/sound/usb/card.h
+++ b/sound/usb/card.h
@@ -80,10 +80,6 @@ struct snd_usb_endpoint {
dma_addr_t sync_dma; /* DMA address of syncbuf */

unsigned int pipe; /* the data i/o pipe */
- unsigned int framesize[2]; /* small/large frame sizes in samples */
- unsigned int sample_rem; /* remainder from division fs/fps */
- unsigned int sample_accum; /* sample accumulator */
- unsigned int fps; /* frames per second */
unsigned int freqn; /* nominal sampling rate in fs/fps in Q16.16 format */
unsigned int freqm; /* momentary sampling rate in fs/fps in Q16.16 format */
int freqshift; /* how much to shift the feedback value to get Q16.16 */
--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -137,12 +137,12 @@ int snd_usb_endpoint_implicit_feedback_s

/*
* For streaming based on information derived from sync endpoints,
- * prepare_outbound_urb_sizes() will call slave_next_packet_size() to
+ * prepare_outbound_urb_sizes() will call next_packet_size() to
* determine the number of samples to be sent in the next packet.
*
- * For implicit feedback, slave_next_packet_size() is unused.
+ * For implicit feedback, next_packet_size() is unused.
*/
-int snd_usb_endpoint_slave_next_packet_size(struct snd_usb_endpoint *ep)
+int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep)
{
unsigned long flags;
int ret;
@@ -159,29 +159,6 @@ int snd_usb_endpoint_slave_next_packet_s
return ret;
}

-/*
- * For adaptive and synchronous endpoints, prepare_outbound_urb_sizes()
- * will call next_packet_size() to determine the number of samples to be
- * sent in the next packet.
- */
-int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep)
-{
- int ret;
-
- if (ep->fill_max)
- return ep->maxframesize;
-
- ep->sample_accum += ep->sample_rem;
- if (ep->sample_accum >= ep->fps) {
- ep->sample_accum -= ep->fps;
- ret = ep->framesize[1];
- } else {
- ret = ep->framesize[0];
- }
-
- return ret;
-}
-
static void retire_outbound_urb(struct snd_usb_endpoint *ep,
struct snd_urb_ctx *urb_ctx)
{
@@ -226,8 +203,6 @@ static void prepare_silent_urb(struct sn

if (ctx->packet_size[i])
counts = ctx->packet_size[i];
- else if (ep->sync_master)
- counts = snd_usb_endpoint_slave_next_packet_size(ep);
else
counts = snd_usb_endpoint_next_packet_size(ep);

@@ -904,17 +879,10 @@ int snd_usb_endpoint_set_params(struct s
ep->maxpacksize = fmt->maxpacksize;
ep->fill_max = !!(fmt->attributes & UAC_EP_CS_ATTR_FILL_MAX);

- if (snd_usb_get_speed(ep->chip->dev) == USB_SPEED_FULL) {
+ if (snd_usb_get_speed(ep->chip->dev) == USB_SPEED_FULL)
ep->freqn = get_usb_full_speed_rate(rate);
- ep->fps = 1000;
- } else {
+ else
ep->freqn = get_usb_high_speed_rate(rate);
- ep->fps = 8000;
- }
-
- ep->sample_rem = rate % ep->fps;
- ep->framesize[0] = rate / ep->fps;
- ep->framesize[1] = (rate + (ep->fps - 1)) / ep->fps;

/* calculate the frequency in 16.16 format */
ep->freqm = ep->freqn;
@@ -973,7 +941,6 @@ int snd_usb_endpoint_start(struct snd_us
ep->active_mask = 0;
ep->unlink_mask = 0;
ep->phase = 0;
- ep->sample_accum = 0;

snd_usb_endpoint_start_quirk(ep);

--- a/sound/usb/endpoint.h
+++ b/sound/usb/endpoint.h
@@ -27,7 +27,6 @@ void snd_usb_endpoint_release(struct snd
void snd_usb_endpoint_free(struct snd_usb_endpoint *ep);

int snd_usb_endpoint_implicit_feedback_sink(struct snd_usb_endpoint *ep);
-int snd_usb_endpoint_slave_next_packet_size(struct snd_usb_endpoint *ep);
int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep);

void snd_usb_handle_sync_urb(struct snd_usb_endpoint *ep,
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -1473,8 +1473,6 @@ static void prepare_playback_urb(struct
for (i = 0; i < ctx->packets; i++) {
if (ctx->packet_size[i])
counts = ctx->packet_size[i];
- else if (ep->sync_master)
- counts = snd_usb_endpoint_slave_next_packet_size(ep);
else
counts = snd_usb_endpoint_next_packet_size(ep);



2020-07-07 15:13:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 15/19] 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
@@ -4206,6 +4206,7 @@ cifs_construct_tcon(struct cifs_sb_info
vol_info->no_linux_ext = !master_tcon->unix_ext;
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:13:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 19/19] netfilter: nf_conntrack_h323: lost .data_len definition for Q.931/ipv6

From: Vasily Averin <[email protected]>

Could you please push this patch into stable@?
it fixes memory corruption in kernels v3.5 .. v4.10

Lost .data_len definition leads to write beyond end of
struct nf_ct_h323_master. Usually it corrupts following
struct nf_conn_nat, however if nat is not loaded it corrupts
following slab object.

In mainline this problem went away in v4.11,
after commit 9f0f3ebeda47 ("netfilter: helpers: remove data_len usage
for inkernel helpers") however many stable kernels are still affected.

Fixes: 1afc56794e03 ("netfilter: nf_ct_helper: implement variable length helper private data") # v3.5
cc: [email protected]
Reviewed-by: Florian Westphal <[email protected]>
Signed-off-by: Vasily Averin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/netfilter/nf_conntrack_h323_main.c | 1 +
1 file changed, 1 insertion(+)

--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
@@ -1225,6 +1225,7 @@ static struct nf_conntrack_helper nf_con
{
.name = "Q.931",
.me = THIS_MODULE,
+ .data_len = sizeof(struct nf_ct_h323_master),
.tuple.src.l3num = AF_INET6,
.tuple.src.u.tcp.port = cpu_to_be16(Q931_PORT),
.tuple.dst.protonum = IPPROTO_TCP,


2020-07-07 15:14:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 17/19] 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
@@ -1737,6 +1737,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;
@@ -1813,8 +1814,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:15:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 07/19] 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 9c939c6bf21cb..321ccdbb73649 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -488,6 +488,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.
@@ -542,6 +543,7 @@ return_normal:
atomic_dec(&slaves_in_kgdb);
dbg_touch_watchdogs();
local_irq_restore(flags);
+ rcu_read_unlock();
return 0;
}
cpu_relax();
@@ -560,6 +562,7 @@ return_normal:
raw_spin_unlock(&dbg_master_lock);
dbg_touch_watchdogs();
local_irq_restore(flags);
+ rcu_read_unlock();

goto acquirelock;
}
@@ -677,6 +680,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:16:33

by Takashi Iwai

[permalink] [raw]
Subject: Re: [PATCH 4.4 14/19] Revert "ALSA: usb-audio: Improve frames size computation"

On Tue, 07 Jul 2020 17:10:17 +0200,
Greg Kroah-Hartman wrote:
>
> From: Greg Kroah-Hartman <[email protected]>
>
> This reverts commit 02c56650f3c118d3752122996d96173d26bb13aa which is
> commit f0bd62b64016508938df9babe47f65c2c727d25c upstream.
>
> It causes a number of reported issues and a fix for it has not hit
> Linus's tree yet.

FYI, I'm going to send a pull request to Linus in tomorrow.
So the fix will be available in a couple of days.
Though...

> Revert this to resolve those problems.

... I'm not against the revert itself if this needs to be addressed
right now.


thanks,

Takashi

>
> Cc: Alexander Tsoy <[email protected]>
> Cc: Takashi Iwai <[email protected]>
> Cc: Sasha Levin <[email protected]>
> Cc: Hans de Goede <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> sound/usb/card.h | 4 ----
> sound/usb/endpoint.c | 43 +++++--------------------------------------
> sound/usb/endpoint.h | 1 -
> sound/usb/pcm.c | 2 --
> 4 files changed, 5 insertions(+), 45 deletions(-)
>
> --- a/sound/usb/card.h
> +++ b/sound/usb/card.h
> @@ -80,10 +80,6 @@ struct snd_usb_endpoint {
> dma_addr_t sync_dma; /* DMA address of syncbuf */
>
> unsigned int pipe; /* the data i/o pipe */
> - unsigned int framesize[2]; /* small/large frame sizes in samples */
> - unsigned int sample_rem; /* remainder from division fs/fps */
> - unsigned int sample_accum; /* sample accumulator */
> - unsigned int fps; /* frames per second */
> unsigned int freqn; /* nominal sampling rate in fs/fps in Q16.16 format */
> unsigned int freqm; /* momentary sampling rate in fs/fps in Q16.16 format */
> int freqshift; /* how much to shift the feedback value to get Q16.16 */
> --- a/sound/usb/endpoint.c
> +++ b/sound/usb/endpoint.c
> @@ -137,12 +137,12 @@ int snd_usb_endpoint_implicit_feedback_s
>
> /*
> * For streaming based on information derived from sync endpoints,
> - * prepare_outbound_urb_sizes() will call slave_next_packet_size() to
> + * prepare_outbound_urb_sizes() will call next_packet_size() to
> * determine the number of samples to be sent in the next packet.
> *
> - * For implicit feedback, slave_next_packet_size() is unused.
> + * For implicit feedback, next_packet_size() is unused.
> */
> -int snd_usb_endpoint_slave_next_packet_size(struct snd_usb_endpoint *ep)
> +int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep)
> {
> unsigned long flags;
> int ret;
> @@ -159,29 +159,6 @@ int snd_usb_endpoint_slave_next_packet_s
> return ret;
> }
>
> -/*
> - * For adaptive and synchronous endpoints, prepare_outbound_urb_sizes()
> - * will call next_packet_size() to determine the number of samples to be
> - * sent in the next packet.
> - */
> -int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep)
> -{
> - int ret;
> -
> - if (ep->fill_max)
> - return ep->maxframesize;
> -
> - ep->sample_accum += ep->sample_rem;
> - if (ep->sample_accum >= ep->fps) {
> - ep->sample_accum -= ep->fps;
> - ret = ep->framesize[1];
> - } else {
> - ret = ep->framesize[0];
> - }
> -
> - return ret;
> -}
> -
> static void retire_outbound_urb(struct snd_usb_endpoint *ep,
> struct snd_urb_ctx *urb_ctx)
> {
> @@ -226,8 +203,6 @@ static void prepare_silent_urb(struct sn
>
> if (ctx->packet_size[i])
> counts = ctx->packet_size[i];
> - else if (ep->sync_master)
> - counts = snd_usb_endpoint_slave_next_packet_size(ep);
> else
> counts = snd_usb_endpoint_next_packet_size(ep);
>
> @@ -904,17 +879,10 @@ int snd_usb_endpoint_set_params(struct s
> ep->maxpacksize = fmt->maxpacksize;
> ep->fill_max = !!(fmt->attributes & UAC_EP_CS_ATTR_FILL_MAX);
>
> - if (snd_usb_get_speed(ep->chip->dev) == USB_SPEED_FULL) {
> + if (snd_usb_get_speed(ep->chip->dev) == USB_SPEED_FULL)
> ep->freqn = get_usb_full_speed_rate(rate);
> - ep->fps = 1000;
> - } else {
> + else
> ep->freqn = get_usb_high_speed_rate(rate);
> - ep->fps = 8000;
> - }
> -
> - ep->sample_rem = rate % ep->fps;
> - ep->framesize[0] = rate / ep->fps;
> - ep->framesize[1] = (rate + (ep->fps - 1)) / ep->fps;
>
> /* calculate the frequency in 16.16 format */
> ep->freqm = ep->freqn;
> @@ -973,7 +941,6 @@ int snd_usb_endpoint_start(struct snd_us
> ep->active_mask = 0;
> ep->unlink_mask = 0;
> ep->phase = 0;
> - ep->sample_accum = 0;
>
> snd_usb_endpoint_start_quirk(ep);
>
> --- a/sound/usb/endpoint.h
> +++ b/sound/usb/endpoint.h
> @@ -27,7 +27,6 @@ void snd_usb_endpoint_release(struct snd
> void snd_usb_endpoint_free(struct snd_usb_endpoint *ep);
>
> int snd_usb_endpoint_implicit_feedback_sink(struct snd_usb_endpoint *ep);
> -int snd_usb_endpoint_slave_next_packet_size(struct snd_usb_endpoint *ep);
> int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep);
>
> void snd_usb_handle_sync_urb(struct snd_usb_endpoint *ep,
> --- a/sound/usb/pcm.c
> +++ b/sound/usb/pcm.c
> @@ -1473,8 +1473,6 @@ static void prepare_playback_urb(struct
> for (i = 0; i < ctx->packets; i++) {
> if (ctx->packet_size[i])
> counts = ctx->packet_size[i];
> - else if (ep->sync_master)
> - counts = snd_usb_endpoint_slave_next_packet_size(ep);
> else
> counts = snd_usb_endpoint_next_packet_size(ep);
>
>
>

2020-07-07 15:20:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 14/19] Revert "ALSA: usb-audio: Improve frames size computation"

On Tue, Jul 07, 2020 at 05:13:59PM +0200, Takashi Iwai wrote:
> On Tue, 07 Jul 2020 17:10:17 +0200,
> Greg Kroah-Hartman wrote:
> >
> > From: Greg Kroah-Hartman <[email protected]>
> >
> > This reverts commit 02c56650f3c118d3752122996d96173d26bb13aa which is
> > commit f0bd62b64016508938df9babe47f65c2c727d25c upstream.
> >
> > It causes a number of reported issues and a fix for it has not hit
> > Linus's tree yet.
>
> FYI, I'm going to send a pull request to Linus in tomorrow.
> So the fix will be available in a couple of days.
> Though...
>
> > Revert this to resolve those problems.
>
> ... I'm not against the revert itself if this needs to be addressed
> right now.

It kind of does, I've gotten lots of distro complaints about it. As the
original wasn't originally tagged for stable, we should just revert it
for now so that people have working systems again.

thanks,

greg k-h

2020-07-08 07:04:22

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/19] 4.4.230-rc1 review

On Tue, 7 Jul 2020 at 20:41, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.4.230 release.
> There are 19 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.4.230-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.4.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.4.230-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: c19eba6b34341e17e0a49be45b010f483dd95de7
git describe: v4.4.229-20-gc19eba6b3434
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.229-20-gc19eba6b3434


No regressions (compared to build v4.4.228-155-gc19eba6b3434)

No fixes (compared to build v4.4.228-155-gc19eba6b3434)

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

Environments
--------------
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- x15 - arm
- x86_64
- x86-kasan

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


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

kernel: 4.4.230-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.230-rc1-hikey-20200707-761
git commit: 1e4ecd8e5eab1c328ff83cd29d52021eb6035bc8
git describe: 4.4.230-rc1-hikey-20200707-761
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.230-rc1-hikey-20200707-761


No regressions (compared to build 4.4.229-rc1-hikey-20200629-759)


No fixes (compared to build 4.4.229-rc1-hikey-20200629-759)

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

Environments
--------------
- hi6220-hikey - arm64

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* kselftest/drivers
* kselftest/filesystems
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-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
* perf
* spectre-meltdown-checker-test
* v4l2-compliance

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

2020-07-08 08:40:56

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/19] 4.4.230-rc1 review


On 07/07/2020 16:10, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.230 release.
> There are 19 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.4.230-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.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


All tests are passing for Tegra ...

Test results for stable-v4.4:
6 builds: 6 pass, 0 fail
12 boots: 12 pass, 0 fail
25 tests: 25 pass, 0 fail

Linux version: 4.4.230-rc1-gc19eba6b3434
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2020-07-08 10:42:10

by Chris Paterson

[permalink] [raw]
Subject: RE: [PATCH 4.4 00/19] 4.4.230-rc1 review



Kind regards, Chris

> -----Original Message-----
> From: [email protected] <[email protected]> On
> Behalf Of Greg Kroah-Hartman
> Sent: 07 July 2020 16:10
> To: [email protected]
> Cc: Greg Kroah-Hartman <[email protected]>; torvalds@linux-
> foundation.org; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: [PATCH 4.4 00/19] 4.4.230-rc1 review
>
> This is the start of the stable review cycle for the 4.4.230 release.
> There are 19 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.4.230-rc1 (c19eba6b3434).

Build/test pipeline/logs: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/164002925
GitLab CI pipeline: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.4.y.yml
Relevant LAVA jobs: https://lava.ciplatform.org/scheduler/alljobs?length=25&search=c19eba#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.4.230-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.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <[email protected]>
> Linux 4.4.230-rc1
>
> Vasily Averin <[email protected]>
> netfilter: nf_conntrack_h323: lost .data_len definition for Q.931/ipv6
>
> 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 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"
>
> Chris Packham <[email protected]>
> i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665
>
> Hou Tao <[email protected]>
> virtio-blk: free vblk-vqs in error path of virtblk_probe()
>
> 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
>
> Shile Zhang <[email protected]>
> sched/rt: Show the 'sched_rr_timeslice' SCHED_RR timeslice tuning knob in
> milliseconds
>
> 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
>
> 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
>
> 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 data block group relocation failure due to concurrent scrub
>
> Anand Jain <[email protected]>
> btrfs: cow_file_range() num_bytes and disk_num_bytes are same
>
>
> -------------
>
> Diffstat:
>
> Makefile | 4 ++--
> arch/mips/kernel/traps.c | 1 +
> 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/hwmon/acpi_power_meter.c | 4 +++-
> drivers/hwmon/max6697.c | 7 +++---
> drivers/i2c/algos/i2c-algo-pca.c | 3 ++-
> drivers/usb/misc/usbtest.c | 1 +
> fs/btrfs/inode.c | 36 ++++++++++++++++++++--------
> fs/cifs/connect.c | 3 +++
> fs/cifs/inode.c | 10 ++++++--
> include/crypto/if_alg.h | 4 ++--
> include/linux/sched/sysctl.h | 1 +
> kernel/debug/debug_core.c | 4 ++++
> kernel/sched/core.c | 5 ++--
> kernel/sched/rt.c | 1 +
> kernel/sysctl.c | 2 +-
> mm/slub.c | 3 ++-
> mm/swap_state.c | 3 ++-
> net/netfilter/nf_conntrack_h323_main.c | 1 +
> sound/usb/card.h | 4 ----
> sound/usb/endpoint.c | 43 ++++------------------------------
> sound/usb/endpoint.h | 1 -
> sound/usb/pcm.c | 2 --
> 28 files changed, 95 insertions(+), 104 deletions(-)
>

2020-07-08 15:19:42

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/19] 4.4.230-rc1 review

On 7/7/20 9:10 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.230 release.
> There are 19 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.4.230-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.4.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 17:54:10

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/19] 4.4.230-rc1 review

On Tue, Jul 07, 2020 at 05:10:03PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.230 release.
> There are 19 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.
>
Build results:
total: 169 pass: 169 fail: 0
Qemu test results:
total: 332 pass: 332 fail: 0

Guenter