5.4.104-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 5.4.104-rc1 review
This is the start of the stable review cycle for the 5.4.104 release. There are 22 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 Wed, 10 Mar 2021 12:27:05 +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/v5.x/stable-review/patch-5.4.104-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-5.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.4.104-rc1
Heiner Kallweit <[email protected]>
r8169: fix resuming from suspend on RTL8105e if machine runs on battery
Dan Carpenter <[email protected]>
rsxx: Return -EFAULT if copy_to_user() fails
Chen Jun <[email protected]>
ftrace: Have recordmcount use w8 to read relp->r_info in arm64_is_fake_mcount
Pierre-Louis Bossart <[email protected]>
ALSA: hda: intel-nhlt: verify config type
YueHaibing <[email protected]>
IB/mlx5: Add missing error code
Julian Braha <[email protected]>
RDMA/rxe: Fix missing kconfig dependency on CRYPTO
Colin Ian King <[email protected]>
ALSA: ctxfi: cthw20k2: fix mask on conf to allow 4 bits
Antonio Borneo <[email protected]>
usbip: tools: fix build error for multiple definition
Ard Biesheuvel <[email protected]>
crypto - shash: reduce minimum alignment of shash_desc structure
Timothy E Baldwin <[email protected]>
arm64: ptrace: Fix seccomp of traced syscall -1 (NO_SYSCALL)
Kevin Wang <[email protected]>
drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcie
Milan Broz <[email protected]>
dm verity: fix FEC for RS roots unaligned to block size
Mikulas Patocka <[email protected]>
dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size
Rafael J. Wysocki <[email protected]>
PM: runtime: Update device status before letting suppliers suspend
Filipe Manana <[email protected]>
btrfs: fix warning when creating a directory with smack enabled
Nikolay Borisov <[email protected]>
btrfs: unlock extents in btrfs_zero_range in case of quota reservation errors
Nikolay Borisov <[email protected]>
btrfs: free correct amount of space in btrfs_delayed_inode_reserve_metadata
Dan Carpenter <[email protected]>
btrfs: validate qgroup inherit for SNAP_CREATE_V2 ioctl
Ira Weiny <[email protected]>
btrfs: fix raid6 qstripe kmap
David Sterba <[email protected]>
btrfs: raid56: simplify tracking of Q stripe presence
Jarkko Sakkinen <[email protected]>
tpm, tpm_tis: Decorate tpm_get_timeouts() with request_locality()
Lukasz Majczak <[email protected]>
tpm, tpm_tis: Decorate tpm_tis_gen_interrupt() with request_locality()
-------------
Diffstat:
Makefile | 4 +- arch/arm64/kernel/ptrace.c | 2 +- drivers/base/power/runtime.c | 62 +++++++++++++++++------------ drivers/block/rsxx/core.c | 8 ++-- drivers/char/tpm/tpm_tis_core.c | 30 +++++++++++--- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 +- drivers/infiniband/hw/mlx5/devx.c | 4 +- drivers/infiniband/sw/rxe/Kconfig | 1 + drivers/md/dm-bufio.c | 4 ++ drivers/md/dm-verity-fec.c | 23 ++++++----- drivers/net/ethernet/realtek/r8169_main.c | 2 + fs/btrfs/delayed-inode.c | 2 +- fs/btrfs/file.c | 5 ++- fs/btrfs/ioctl.c | 19 ++++++++- fs/btrfs/raid56.c | 58 ++++++++++++--------------- fs/btrfs/xattr.c | 31 +++++++++++++-- include/crypto/hash.h | 8 ++-- include/linux/crypto.h | 9 +++-- include/sound/intel-nhlt.h | 5 +++ scripts/recordmcount.c | 2 +- sound/hda/intel-nhlt.c | 54 ++++++++++++++++++++----- sound/pci/ctxfi/cthw20k2.c | 2 +- tools/usb/usbip/libsrc/usbip_host_common.c | 2 +- 23 files changed, 232 insertions(+), 109 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/22 tpm, tpm_tis: Decorate tpm_tis_gen_interrupt() with request_locality()
From: Lukasz Majczak <[email protected]>
commit d53a6adfb553969809eb2b736a976ebb5146cd95 upstream.
This is shown with Samsung Chromebook Pro (Caroline) with TPM 1.2 (SLB 9670):
[ 4.324298] TPM returned invalid status [ 4.324806] WARNING: CPU: 2 PID: 1 at drivers/char/tpm/tpm_tis_core.c:275 tpm_tis_status+0x86/0x8f
Background
==========
TCG PC Client Platform TPM Profile (PTP) Specification, paragraph 6.1 FIFO Interface Locality Usage per Register, Table 39 Register Behavior Based on Locality Setting for FIFO - a read attempt to TPM_STS_x Registers returns 0xFF in case of lack of locality.
The fix
=======
Decorate tpm_tis_gen_interrupt() with request_locality() and release_locality().
--- drivers/char/tpm/tpm_tis_core.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
drivers/char/tpm/tpm_tis_core.c +13 -3
@@ -618,12 +618,22 @@ static int tpm_tis_gen_interrupt(structconst char *desc ="attempting to generate an interrupt" ;u32 cap2;cap_t cap; +int ret; +/* TPM 2.0 */ if (chip->flags &TPM_CHIP_FLAG_TPM2 )return tpm2_get_tpm_pt (chip,0x100 , &cap2, desc); -else -return tpm1_getcap (chip,TPM_CAP_PROP_TIS_TIMEOUT , &cap, desc, -0 ); + +/* TPM 1.2 */ + ret =request_locality (chip,0 ); +if (ret <0 ) +return ret; + + ret =tpm1_getcap (chip,TPM_CAP_PROP_TIS_TIMEOUT , &cap, desc,0 ); + +release_locality (chip,0 ); + +return ret; }/* Register the IRQ and issue a command that will cause an interrupt. If an
Greg Kroah-Hartman
maintainerPATCH 2/22 tpm, tpm_tis: Decorate tpm_get_timeouts() with request_locality()
In reply to Greg Kroah-HartmanFrom: Jarkko Sakkinen <[email protected]>
commit a5665ec2affdba21bff3b0d4d3aed83b3951e8ff upstream.
This is shown with Samsung Chromebook Pro (Caroline) with TPM 1.2 (SLB 9670):
[ 4.324298] TPM returned invalid status [ 4.324806] WARNING: CPU: 2 PID: 1 at drivers/char/tpm/tpm_tis_core.c:275 tpm_tis_status+0x86/0x8f
Background
==========
TCG PC Client Platform TPM Profile (PTP) Specification, paragraph 6.1 FIFO Interface Locality Usage per Register, Table 39 Register Behavior Based on Locality Setting for FIFO - a read attempt to TPM_STS_x Registers returns 0xFF in case of lack of locality.
The fix
=======
Decorate tpm_get_timeouts() with request_locality() and release_locality().
--- drivers/char/tpm/tpm_tis_core.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
drivers/char/tpm/tpm_tis_core.c +12 -2
@@ -939,11 +939,21 @@ int tpm_tis_core_init(struct device *devinit_waitqueue_head (&priv->read_queue);init_waitqueue_head (&priv->int_queue);if (irq !=-1 ) { -/* Before doing irq testing issue a command to the TPM in polling mode +/* +* Before doing irq testing issue a command to the TPM in polling mode * to make sure it works. May as well use that command to set the * proper timeouts for the driver. */ -if (tpm_get_timeouts (chip)) { + + rc =request_locality (chip,0 ); +if (rc <0 ) + goto out_err; + + rc =tpm_get_timeouts (chip); + +release_locality (chip,0 ); + +if (rc) {dev_err (dev,"Could not get TPM timeouts and durations\n" ); rc = -ENODEV ; goto out_err;
Greg Kroah-Hartman
maintainerPATCH 3/22 btrfs: raid56: simplify tracking of Q stripe presence
In reply to Greg Kroah-HartmanFrom: David Sterba <[email protected]>
commit c17af96554a8a8777cbb0fd53b8497250e548b43 upstream.
There are temporary variables tracking the index of P and Q stripes, but none of them is really used as such, merely for determining if the Q stripe is present. This leads to compiler warnings with -Wunused-but-set-variable and has been reported several times.
fs/btrfs/raid56.c: In function ‘finish_rmw’:fs/btrfs/raid56.c:1199:6: warning: variable ‘p_stripe’ set but not used [-Wunused-but-set-variable]
1199 | int p_stripe = -1;
| ^~~~~~~~
fs/btrfs/raid56.c: In function ‘finish_parity_scrub’:
fs/btrfs/raid56.c:2356:6: warning: variable ‘p_stripe’ set but not used [-Wunused-but-set-variable]
2356 | int p_stripe = -1;
| ^~~~~~~~Replace the two variables with one that has a clear meaning and also get rid of the warnings. The logic that verifies that there are only 2 valid cases is unchanged.
--- fs/btrfs/raid56.c | 37 +++++++++++++++---------------------- 1 file changed, 15 insertions(+), 22 deletions(-)
fs/btrfs/raid56.c +15 -22
@@ -1198,22 +1198,19 @@ static noinline void finish_rmw(struct bint nr_data = rbio->nr_data;int stripe;int pagenr; -int p_stripe =-1 ; -int q_stripe =-1 ; +bool has_qstripe;struct bio_list bio_list;struct bio *bio;int ret;bio_list_init (&bio_list); -if (rbio->real_stripes - rbio->nr_data ==1 ) { - p_stripe = rbio->real_stripes -1 ; - }else if (rbio->real_stripes - rbio->nr_data ==2 ) { - p_stripe = rbio->real_stripes -2 ; - q_stripe = rbio->real_stripes -1 ; - }else { +if (rbio->real_stripes - rbio->nr_data ==1 ) + has_qstripe = false; +else if (rbio->real_stripes - rbio->nr_data ==2 ) + has_qstripe = true; +else BUG (); - }/* at this point we either have a full stripe, * or we've read the full stripe from the drive.
@@ -1257,7 +1254,7 @@ static noinline void finish_rmw(struct bSetPageUptodate (p); pointers[stripe++] =kmap (p); -if (q_stripe !=-1 ) { +if (has_qstripe) {/* * raid6, add the qstripe and call the
@@ -2355,8 +2352,7 @@ static noinline void finish_parity_scrubint nr_data = rbio->nr_data;int stripe;int pagenr; -int p_stripe =-1 ; -int q_stripe =-1 ; +bool has_qstripe;struct page *p_page =NULL ;struct page *q_page =NULL ;struct bio_list bio_list;
@@ -2366,14 +2362,12 @@ static noinline void finish_parity_scrubbio_list_init (&bio_list); -if (rbio->real_stripes - rbio->nr_data ==1 ) { - p_stripe = rbio->real_stripes -1 ; - }else if (rbio->real_stripes - rbio->nr_data ==2 ) { - p_stripe = rbio->real_stripes -2 ; - q_stripe = rbio->real_stripes -1 ; - }else { +if (rbio->real_stripes - rbio->nr_data ==1 ) + has_qstripe = false; +else if (rbio->real_stripes - rbio->nr_data ==2 ) + has_qstripe = true; +else BUG (); - }if (bbio->num_tgtdevs && bbio->tgtdev_map[rbio->scrubp]) { is_replace =1 ;
@@ -2395,7 +2389,7 @@ static noinline void finish_parity_scrub goto cleanup;SetPageUptodate (p_page); -if (q_stripe !=-1 ) { +if (has_qstripe) { q_page =alloc_page (GFP_NOFS | __GFP_HIGHMEM);if (!q_page) {__free_page (p_page);
@@ -2418,8 +2412,7 @@ static noinline void finish_parity_scrub/* then add the parity stripe */ pointers[stripe++] =kmap (p_page); -if (q_stripe !=-1 ) { - +if (has_qstripe) {/* * raid6, add the qstripe and call the * library function to fill in our p/q
Greg Kroah-Hartman
maintainerPATCH 4/22 btrfs: fix raid6 qstripe kmap
In reply to Greg Kroah-HartmanFrom: Ira Weiny <[email protected]>
commit d70cef0d46729808dc53f145372c02b145c92604 upstream.
When a qstripe is required an extra page is allocated and mapped. There were 3 problems:
1) There is no corresponding call of kunmap() for the qstripe page.
2) There is no reason to map the qstripe page more than once if the number of bits set in rbio->dbitmap is greater than one.
3) There is no reason to map the parity page and unmap it each time through the loop.
The page memory can continue to be reused with a single mapping on each iteration by raid6_call.gen_syndrome() without remapping. So map the page for the duration of the loop.
Similarly, improve the algorithm by mapping the parity page just 1 time.
--- fs/btrfs/raid56.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-)
fs/btrfs/raid56.c +10 -11
@@ -2390,16 +2390,21 @@ static noinline void finish_parity_scrubSetPageUptodate (p_page);if (has_qstripe) { +/* RAID6, allocate and map temp space for the Q stripe */ q_page =alloc_page (GFP_NOFS | __GFP_HIGHMEM);if (!q_page) {__free_page (p_page); goto cleanup; }SetPageUptodate (q_page); + pointers[rbio->real_stripes -1 ] =kmap (q_page); }atomic_set (&rbio->error,0 ); +/* Map the parity stripe just once */ + pointers[nr_data] =kmap (p_page); +for_each_set_bit (pagenr, rbio->dbitmap, rbio->stripe_npages) {struct page *p;void *parity;
@@ -2409,16 +2414,8 @@ static noinline void finish_parity_scrub pointers[stripe] =kmap (p); } -/* then add the parity stripe */ - pointers[stripe++] =kmap (p_page); -if (has_qstripe) { -/* -* raid6, add the qstripe and call the -* library function to fill in our p/q -*/ - pointers[stripe++] =kmap (q_page); - +/* RAID6, call the library function to fill in our P/Q */ raid6_call.gen_syndrome (rbio->real_stripes,PAGE_SIZE , pointers); }else {
@@ -2439,12 +2436,14 @@ static noinline void finish_parity_scrubfor (stripe =0 ; stripe < nr_data; stripe++)kunmap (page_in_rbio (rbio, stripe, pagenr,0 )); -kunmap (p_page); } +kunmap (p_page);__free_page (p_page); -if (q_page) +if (q_page) { +kunmap (q_page);__free_page (q_page); + } writeback:/*
Greg Kroah-Hartman
maintainerPATCH 5/22 btrfs: validate qgroup inherit for SNAP_CREATE_V2 ioctl
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
commit 5011c5a663b9c6d6aff3d394f11049b371199627 upstream.
The problem is we're copying "inherit" from user space but we don't necessarily know that we're copying enough data for a 64 byte struct. Then the next problem is that 'inherit' has a variable size array at the end, and we have to verify that array is the size we expected.
--- fs/btrfs/ioctl.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
fs/btrfs/ioctl.c +18 -1
@@ -1907,7 +1907,10 @@ static noinline int btrfs_ioctl_snap_creif (vol_args->flags &BTRFS_SUBVOL_RDONLY ) readonly = true;if (vol_args->flags &BTRFS_SUBVOL_QGROUP_INHERIT ) { -if (vol_args->size >PAGE_SIZE ) { +u64 nums; + +if (vol_args->size <sizeof (*inherit) || + vol_args->size >PAGE_SIZE ) { ret = -EINVAL ; goto free_args; }
@@ -1916,6 +1919,20 @@ static noinline int btrfs_ioctl_snap_cre ret =PTR_ERR (inherit); goto free_args; } + +if (inherit->num_qgroups >PAGE_SIZE || + inherit->num_ref_copies >PAGE_SIZE || + inherit->num_excl_copies >PAGE_SIZE ) { + ret = -EINVAL ; + goto free_inherit; + } + + nums = inherit->num_qgroups +2 * inherit->num_ref_copies + +2 * inherit->num_excl_copies; +if (vol_args->size !=struct_size (inherit, qgroups, nums)) { + ret = -EINVAL ; + goto free_inherit; + } } ret = btrfs_ioctl_snap_create_transid(file, vol_args->name,
Greg Kroah-Hartman
maintainerPATCH 6/22 btrfs: free correct amount of space in btrfs_delayed_inode_reserve_metadata
In reply to Greg Kroah-HartmanFrom: Nikolay Borisov <[email protected]>
commit 0f9c03d824f6f522d3bc43629635c9765546ebc5 upstream.
Following commit f218ea6c4792 ("btrfs: delayed-inode: Remove wrong qgroup meta reservation calls") this function now reserves num_bytes, rather than the fixed amount of nodesize. As such this requires the same amount to be freed in case of failure. Fix this by adjusting the amount we are freeing.
--- fs/btrfs/delayed-inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/delayed-inode.c +1 -1
@@ -649,7 +649,7 @@ static int btrfs_delayed_inode_reserve_mbtrfs_ino (inode), num_bytes, 1); }else { -btrfs_qgroup_free_meta_prealloc (root, fs_info->nodesize); +btrfs_qgroup_free_meta_prealloc (root, num_bytes); }return ret; }
Greg Kroah-Hartman
maintainerPATCH 7/22 btrfs: unlock extents in btrfs_zero_range in case of quota reservation errors
In reply to Greg Kroah-HartmanFrom: Nikolay Borisov <[email protected]>
commit 4f6a49de64fd1b1dba5229c02047376da7cf24fd upstream.
If btrfs_qgroup_reserve_data returns an error (i.e quota limit reached) the handling logic directly goes to the 'out' label without first unlocking the extent range between lockstart, lockend. This results in deadlocks as other processes try to lock the same extent.
--- fs/btrfs/file.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
fs/btrfs/file.c +4 -1
@@ -3151,8 +3151,11 @@ reserve_space: goto out; ret =btrfs_qgroup_reserve_data (inode, &data_reserved, alloc_start, bytes_to_reserve); -if (ret) +if (ret) { +unlock_extent_cached (&BTRFS_I (inode)->io_tree, lockstart, + lockend, &cached_state); goto out; + } ret = btrfs_prealloc_file_range(inode, mode, alloc_start, alloc_end - alloc_start, i_blocksize(inode),
Greg Kroah-Hartman
maintainerPATCH 8/22 btrfs: fix warning when creating a directory with smack enabled
In reply to Greg Kroah-HartmanFrom: Filipe Manana <[email protected]>
commit fd57a98d6f0c98fa295813087f13afb26c224e73 upstream.
When we have smack enabled, during the creation of a directory smack may attempt to add a "smack transmute" xattr on the inode, which results in the following warning and trace:
WARNING: CPU: 3 PID: 2548 at fs/btrfs/transaction.c:537 start_transaction+0x489/0x4f0 Modules linked in: nft_objref nf_conntrack_netbios_ns (...) CPU: 3 PID: 2548 Comm: mkdir Not tainted 5.9.0-rc2smack+ #81 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:start_transaction+0x489/0x4f0 Code: e9 be fc ff ff (...) RSP: 0018:ffffc90001887d10 EFLAGS: 00010202 RAX: ffff88816f1e0000 RBX: 0000000000000201 RCX: 0000000000000003 RDX: 0000000000000201 RSI: 0000000000000002 RDI: ffff888177849000 RBP: ffff888177849000 R08: 0000000000000001 R09: 0000000000000004 R10: ffffffff825e8f7a R11: 0000000000000003 R12: ffffffffffffffe2 R13: 0000000000000000 R14: ffff88803d884270 R15: ffff8881680d8000 FS: 00007f67317b8440(0000) GS:ffff88817bcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f67247a22a8 CR3: 000000004bfbc002 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? slab_free_freelist_hook+0xea/0x1b0 ? trace_hardirqs_on+0x1c/0xe0 btrfs_setxattr_trans+0x3c/0xf0 __vfs_setxattr+0x63/0x80 smack_d_instantiate+0x2d3/0x360 security_d_instantiate+0x29/0x40 d_instantiate_new+0x38/0x90 btrfs_mkdir+0x1cf/0x1e0 vfs_mkdir+0x14f/0x200 do_mkdirat+0x6d/0x110 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f673196ae6b Code: 8b 05 11 (...) RSP: 002b:00007ffc3c679b18 EFLAGS: 00000246 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX: 00000000000001ff RCX: 00007f673196ae6b RDX: 0000000000000000 RSI: 00000000000001ff RDI: 00007ffc3c67a30d RBP: 00007ffc3c67a30d R08: 00000000000001ff R09: 0000000000000000 R10: 000055d3e39fe930 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc3c679cd8 R14: 00007ffc3c67a30d R15: 00007ffc3c679ce0 irq event stamp: 11029 hardirqs last enabled at (11037): [<ffffffff81153fe6>] console_unlock+0x486/0x670 hardirqs last disabled at (11044): [<ffffffff81153c01>] console_unlock+0xa1/0x670 softirqs last enabled at (8864): [<ffffffff81e0102f>] asm_call_on_stack+0xf/0x20 softirqs last disabled at (8851): [<ffffffff81e0102f>] asm_call_on_stack+0xf/0x20
This happens because at btrfs_mkdir() we call d_instantiate_new() while holding a transaction handle, which results in the following call chain:
btrfs_mkdir()
trans = btrfs_start_transaction(root, 5); d_instantiate_new()
smack_d_instantiate()
__vfs_setxattr()
btrfs_setxattr_trans()
btrfs_start_transaction()
start_transaction()
WARN_ON()
--> a tansaction start has TRANS_EXTWRITERS
set in its type
h->orig_rsv = h->block_rsv
h->block_rsv = NULL
btrfs_end_transaction(trans)Besides the warning triggered at start_transaction, we set the handle's block_rsv to NULL which may cause some surprises later on.
So fix this by making btrfs_setxattr_trans() not start a transaction when we already have a handle on one, stored in current->journal_info, and use that handle. We are good to use the handle because at btrfs_mkdir() we did reserve space for the xattr and the inode item.
--- fs/btrfs/xattr.c | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-)
fs/btrfs/xattr.c +27 -4
@@ -227,11 +227,33 @@ int btrfs_setxattr_trans(struct inode *i {struct btrfs_root *root =BTRFS_I (inode)->root;struct btrfs_trans_handle *trans; +const bool start_trans = (current->journal_info ==NULL );int ret; - trans =btrfs_start_transaction (root,2 ); -if (IS_ERR (trans)) -return PTR_ERR (trans); +if (start_trans) { +/* +* 1 unit for inserting/updating/deleting the xattr +* 1 unit for the inode item update +*/ + trans =btrfs_start_transaction (root,2 ); +if (IS_ERR (trans)) +return PTR_ERR (trans); + }else { +/* +* This can happen when smack is enabled and a directory is being +* created. It happens through d_instantiate_new(), which calls +* smack_d_instantiate(), which in turn calls __vfs_setxattr() to +* set the transmute xattr (XATTR_NAME_SMACKTRANSMUTE) on the +* inode. We have already reserved space for the xattr and inode +* update at btrfs_mkdir(), so just use the transaction handle. +* We don't join or start a transaction, as that will reset the +* block_rsv of the handle and trigger a warning for the start +* case. +*/ +ASSERT (strncmp (name,XATTR_SECURITY_PREFIX , +XATTR_SECURITY_PREFIX_LEN ) ==0 ); + trans = current->journal_info; + } ret =btrfs_setxattr (trans, inode, name, value, size, flags);if (ret)
@@ -242,7 +264,8 @@ int btrfs_setxattr_trans(struct inode *i ret =btrfs_update_inode (trans, root, inode);BUG_ON (ret); out: -btrfs_end_transaction (trans); +if (start_trans) +btrfs_end_transaction (trans);return ret; }
Greg Kroah-Hartman
maintainerPATCH 9/22 PM: runtime: Update device status before letting suppliers suspend
In reply to Greg Kroah-HartmanFrom: Rafael J. Wysocki <[email protected]>
commit 44cc89f764646b2f1f2ea5d1a08b230131707851 upstream.
Because the PM-runtime status of the device is not updated in __rpm_callback(), attempts to suspend the suppliers of the given device triggered by rpm_put_suppliers() called by it may fail.
Fix this by making __rpm_callback() update the device's status to RPM_SUSPENDED before calling rpm_put_suppliers() if the current status of the device is RPM_SUSPENDING and the callback just invoked by it has returned 0 (success).
While at it, modify the code in __rpm_callback() to always check the device's PM-runtime status under its PM lock.
--- drivers/base/power/runtime.c | 62 +++++++++++++++++++++++++------------------ 1 file changed, 37 insertions(+), 25 deletions(-)
drivers/base/power/runtime.c +37 -25
@@ -325,22 +325,22 @@ static void rpm_put_suppliers(struct devstatic int __rpm_callback (int (*cb)(struct device *),struct device *dev) __releases(&dev->power.lock) __acquires(&dev->power.lock) { -int retval, idx;bool use_links = dev->power.links_count >0 ; +bool get = false; +int retval, idx; +bool put;if (dev->power.irq_safe) {spin_unlock (&dev->power.lock); + }else if (!use_links) { +spin_unlock_irq (&dev->power.lock); }else { + get = dev->power.runtime_status ==RPM_RESUMING ; +spin_unlock_irq (&dev->power.lock); -/* -* Resume suppliers if necessary. -* -* The device's runtime PM status cannot change until this -* routine returns, so it is safe to read the status outside of -* the lock. -*/ -if (use_links && dev->power.runtime_status ==RPM_RESUMING ) { +/* Resume suppliers if necessary. */ +if (get) { idx =device_links_read_lock (); retval =rpm_get_suppliers (dev);
@@ -355,24 +355,36 @@ static int __rpm_callback(int (*cb)(struif (dev->power.irq_safe) {spin_lock (&dev->power.lock); - }else { -/* -* If the device is suspending and the callback has returned -* success, drop the usage counters of the suppliers that have -* been reference counted on its resume. -* -* Do that if resume fails too. -*/ -if (use_links - && ((dev->power.runtime_status ==RPM_SUSPENDING && !retval) - || (dev->power.runtime_status ==RPM_RESUMING && retval))) { - idx =device_links_read_lock (); +return retval; + } - fail: -rpm_put_suppliers (dev); +spin_lock_irq (&dev->power.lock); -device_links_read_unlock (idx); - } +if (!use_links) +return retval; + +/* +* If the device is suspending and the callback has returned success, +* drop the usage counters of the suppliers that have been reference +* counted on its resume. +* +* Do that if the resume fails too. +*/ + put = dev->power.runtime_status ==RPM_SUSPENDING && !retval; +if (put) +__update_runtime_status (dev,RPM_SUSPENDED ); +else + put = get && retval; + +if (put) { +spin_unlock_irq (&dev->power.lock); + + idx =device_links_read_lock (); + +fail: +rpm_put_suppliers (dev); + +device_links_read_unlock (idx);spin_lock_irq (&dev->power.lock); }
Greg Kroah-Hartman
maintainerPATCH 10/22 dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size
In reply to Greg Kroah-HartmanFrom: Mikulas Patocka <[email protected]>
commit a14e5ec66a7a66e57b24e2469f9212a78460207e upstream.
dm_bufio_get_device_size returns the device size in blocks. Before returning the value, we must subtract the nubmer of starting sectors. The number of starting sectors may not be divisible by block size.
Note that currently, no target is using dm_bufio_set_sector_offset and dm_bufio_get_device_size simultaneously, so this change has no effect. However, an upcoming dm-verity-fec fix needs this change.
--- drivers/md/dm-bufio.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/md/dm-bufio.c +4 -0
@@ -1438,6 +1438,10 @@ EXPORT_SYMBOL_GPL(dm_bufio_get_block_sizsector_t dm_bufio_get_device_size (struct dm_bufio_client *c) {sector_t s =i_size_read (c->bdev->bd_inode) >>SECTOR_SHIFT ; +if (s >= c->start) + s -= c->start; +else + s =0 ;if (likely (c->sectors_per_block_bits >=0 )) s >>= c->sectors_per_block_bits;else
Greg Kroah-Hartman
maintainerPATCH 11/22 dm verity: fix FEC for RS roots unaligned to block size
In reply to Greg Kroah-HartmanFrom: Milan Broz <[email protected]>
commit df7b59ba9245c4a3115ebaa905e3e5719a3810da upstream.
Optional Forward Error Correction (FEC) code in dm-verity uses Reed-Solomon code and should support roots from 2 to 24.
The error correction parity bytes (of roots lengths per RS block) are stored on a separate device in sequence without any padding.
Currently, to access FEC device, the dm-verity-fec code uses dm-bufio client with block size set to verity data block (usually 4096 or 512 bytes).
Because this block size is not divisible by some (most!) of the roots supported lengths, data repair cannot work for partially stored parity bytes.
This fix changes FEC device dm-bufio block size to "roots << SECTOR_SHIFT" where we can be sure that the full parity data is always available. (There cannot be partial FEC blocks because parity must cover whole sectors.)
Because the optional FEC starting offset could be unaligned to this new block size, we have to use dm_bufio_set_sector_offset() to configure it.
The problem is easily reproduced using veritysetup, e.g. for roots=13:
# create verity device with RS FEC
dd if=/dev/urandom of=data.img bs=4096 count=8 status=none
veritysetup format data.img hash.img --fec-device=fec.img --fec-roots=13 | awk '/^Root hash/{ print $3 }' >roothash# create an erasure that should be always repairable with this roots setting dd if=/dev/zero of=data.img conv=notrunc bs=1 count=8 seek=4088 status=none
# try to read it through dm-verity veritysetup open data.img test hash.img --fec-device=fec.img --fec-roots=13 $(cat roothash) dd if=/dev/mapper/test of=/dev/null bs=4096 status=noxfer # wait for possible recursive recovery in kernel udevadm settle veritysetup close test
With this fix, errors are properly repaired.
device-mapper: verity-fec: 7:1: FEC 0: corrected 8 errors
...
Without it, FEC code usually ends on unrecoverable failure in RS decoder:
device-mapper: verity-fec: 7:1: FEC 0: failed to correct: -74
...
This problem is present in all kernels since the FEC code's introduction (kernel 4.5).
It is thought that this problem is not visible in Android ecosystem because it always uses a default RS roots=2.
Depends-on: a14e5ec66a7a ("dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size")
--- drivers/md/dm-verity-fec.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-)
drivers/md/dm-verity-fec.c +12 -11
@@ -61,19 +61,18 @@ static int fec_decode_rs8(struct dm_veristatic u8 *fec_read_parity (struct dm_verity *v,u64 rsb,int index,unsigned *offset,struct dm_buffer **buf) { -u64 position, block; +u64 position, block, rem;u8 *res; position = (index + rsb) * v->fec->roots; - block = position >> v->data_dev_block_bits; - *offset = (unsigned )(position - (block << v->data_dev_block_bits)); + block =div64_u64_rem (position, v->fec->roots <<SECTOR_SHIFT , &rem); + *offset = (unsigned )rem; - res =dm_bufio_read (v->fec->bufio, v->fec->start + block, buf); + res =dm_bufio_read (v->fec->bufio, block, buf);if (IS_ERR (res)) {DMERR ("%s: FEC %llu: parity read failed (block %llu): %ld" , v->data_dev->name, (unsigned long long )rsb, - (unsigned long long )(v->fec->start + block), -PTR_ERR (res)); + (unsigned long long )block,PTR_ERR (res)); *buf =NULL ; }
@@ -155,7 +154,7 @@ static int fec_decode_bufs(struct dm_ver/* read the next block when we run out of parity bytes */ offset += v->fec->roots; -if (offset >=1 << v->data_dev_block_bits) { +if (offset >= v->fec->roots <<SECTOR_SHIFT ) {dm_bufio_release (buf); par =fec_read_parity (v, rsb, block_offset, &offset, &buf);
@@ -674,7 +673,7 @@ int verity_fec_ctr(struct dm_verity *v) {struct dm_verity_fec *f = v->fec;struct dm_target *ti = v->ti; -u64 hash_blocks; +u64 hash_blocks, fec_blocks;int ret;if (!verity_fec_is_enabled (v)) {
@@ -744,15 +743,17 @@ int verity_fec_ctr(struct dm_verity *v) } f->bufio =dm_bufio_client_create (f->dev->bdev, -1 << v->data_dev_block_bits, + f->roots <<SECTOR_SHIFT ,1 ,0 ,NULL ,NULL );if (IS_ERR (f->bufio)) { ti->error ="Cannot initialize FEC bufio client" ;return PTR_ERR (f->bufio); } -if (dm_bufio_get_device_size (f->bufio) < - ((f->start + f->rounds * f->roots) >> v->data_dev_block_bits)) { +dm_bufio_set_sector_offset (f->bufio, f->start << (v->data_dev_block_bits -SECTOR_SHIFT )); + + fec_blocks =div64_u64 (f->rounds * f->roots, v->fec->roots <<SECTOR_SHIFT ); +if (dm_bufio_get_device_size (f->bufio) < fec_blocks) { ti->error ="FEC device is too small" ;return -E2BIG ; }
Greg Kroah-Hartman
maintainerPATCH 12/22 drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcie
In reply to Greg Kroah-HartmanFrom: Kevin Wang <[email protected]>
commit 1aa46901ee51c1c5779b3b239ea0374a50c6d9ff upstream.
the register offset isn't needed division by 4 to pass RREG32_PCIE()
--- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c +2 -2
@@ -240,7 +240,7 @@ static ssize_t amdgpu_debugfs_regs_pcie_while (size) {uint32_t value; - value =RREG32_PCIE (*pos >>2 ); + value =RREG32_PCIE (*pos); r =put_user (value, (uint32_t *)buf);if (r)return r;
@@ -283,7 +283,7 @@ static ssize_t amdgpu_debugfs_regs_pcie_if (r)return r; -WREG32_PCIE (*pos >>2 , value); +WREG32_PCIE (*pos, value); result +=4 ; buf +=4 ;
Greg Kroah-Hartman
maintainerPATCH 13/22 arm64: ptrace: Fix seccomp of traced syscall -1 (NO_SYSCALL)
In reply to Greg Kroah-HartmanFrom: Timothy E Baldwin <[email protected]>
commit df84fe94708985cdfb78a83148322bcd0a699472 upstream.
Since commit f086f67485c5 ("arm64: ptrace: add support for syscall emulation"), if system call number -1 is called and the process is being traced with PTRACE_SYSCALL, for example by strace, the seccomp check is skipped and -ENOSYS is returned unconditionally (unless altered by the tracer) rather than carrying out action specified in the seccomp filter.
The consequence of this is that it is not possible to reliably strace a seccomp based implementation of a foreign system call interface in which r7/x8 is permitted to be -1 on entry to a system call.
Also trace_sys_enter and audit_syscall_entry are skipped if a system call is skipped.
Fix by removing the in_syscall(regs) check restoring the previous behaviour which is like AArch32, x86 (which uses generic code) and everything else.
--- arch/arm64/kernel/ptrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/kernel/ptrace.c +1 -1
@@ -1844,7 +1844,7 @@ int syscall_trace_enter(struct pt_regs *if (flags & (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE)) {tracehook_report_syscall (regs,PTRACE_SYSCALL_ENTER ); -if (!in_syscall (regs) || (flags & _TIF_SYSCALL_EMU)) +if (flags & _TIF_SYSCALL_EMU)return -1 ; }
Greg Kroah-Hartman
maintainerPATCH 14/22 crypto - shash: reduce minimum alignment of shash_desc structure
In reply to Greg Kroah-HartmanFrom: Ard Biesheuvel <[email protected]>
commit 660d2062190db131d2feaf19914e90f868fe285c upstream.
Unlike many other structure types defined in the crypto API, the 'shash_desc' structure is permitted to live on the stack, which implies its contents may not be accessed by DMA masters. (This is due to the fact that the stack may be located in the vmalloc area, which requires a different virtual-to-physical translation than the one implemented by the DMA subsystem)
Our definition of CRYPTO_MINALIGN_ATTR is based on ARCH_KMALLOC_MINALIGN, which may take DMA constraints into account on architectures that support non-cache coherent DMA such as ARM and arm64. In this case, the value is chosen to reflect the largest cacheline size in the system, in order to ensure that explicit cache maintenance as required by non-coherent DMA masters does not affect adjacent, unrelated slab allocations. On arm64, this value is currently set at 128 bytes.
This means that applying CRYPTO_MINALIGN_ATTR to struct shash_desc is both unnecessary (as it is never used for DMA), and undesirable, given that it wastes stack space (on arm64, performing the alignment costs 112 bytes in the worst case, and the hole between the 'tfm' and '__ctx' members takes up another 120 bytes, resulting in an increased stack footprint of up to 232 bytes.) So instead, let's switch to the minimum SLAB alignment, which does not take DMA constraints into account.
Note that this is a no-op for x86.
--- include/crypto/hash.h | 8 ++++---- include/linux/crypto.h | 9 ++++++--- 2 files changed, 10 insertions(+), 7 deletions(-)
include/crypto/hash.h +4 -4
@@ -141,7 +141,7 @@ struct ahash_alg {struct shash_desc {struct crypto_shash *tfm; - void *__ctx[] CRYPTO_MINALIGN_ATTR; +void *__ctx[]__aligned(ARCH_SLAB_MINALIGN) ; };#define HASH_MAX_DIGESTSIZE 64
@@ -154,9 +154,9 @@ struct shash_desc {#define HASH_MAX_STATESIZE 512 -#define SHASH_DESC_ON_STACK (shash, ctx) \ - char __##shash##_desc[sizeof(struct shash_desc) + \ - HASH_MAX_DESCSIZE] CRYPTO_MINALIGN_ATTR; \ +#define SHASH_DESC_ON_STACK (shash, ctx) \ + char __##shash##_desc[sizeof(struct shash_desc) + HASH_MAX_DESCSIZE] \ + __aligned(__alignof__(struct shash_desc)); \ struct shash_desc *shash = (struct shash_desc *)__##shash##_desc/**
include/linux/crypto.h +6 -3
@@ -130,9 +130,12 @@* The macro CRYPTO_MINALIGN_ATTR (along with the void * type in the actual * declaration) is used to ensure that the crypto_tfm context structure is * aligned correctly for the given architecture so that there are no alignment -* faults for C data types. In particular, this is required on platforms such -* as arm where pointers are 32-bit aligned but there are data types such as -* u64 which require 64-bit alignment. +* faults for C data types. On architectures that support non-cache coherent +* DMA, such as ARM or arm64, it also takes into account the minimal alignment +* that is required to ensure that the context struct member does not share any +* cachelines with the rest of the struct. This is needed to ensure that cache +* maintenance for non-coherent DMA (cache invalidation in particular) does not +* affect data that may be accessed by the CPU concurrently. */ #define CRYPTO_MINALIGN ARCH_KMALLOC_MINALIGN
Greg Kroah-Hartman
maintainerPATCH 15/22 usbip: tools: fix build error for multiple definition
In reply to Greg Kroah-HartmanFrom: Antonio Borneo <[email protected]>
commit d5efc2e6b98fe661dbd8dd0d5d5bfb961728e57a upstream.
With GCC 10, building usbip triggers error for multiple definition of 'udev_context', in:
- libsrc/vhci_driver.c:18 and
- libsrc/usbip_host_common.c:27.
Declare as extern the definition in libsrc/usbip_host_common.c.
--- tools/usb/usbip/libsrc/usbip_host_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/usb/usbip/libsrc/usbip_host_common.c +1 -1
@@ -23,7 +23,7 @@#include "list.h" #include "sysfs_utils.h" -struct udev *udev_context; +extern struct udev *udev_context;static int32_t read_attr_usbip_status (struct usbip_usb_device *udev) {
Greg Kroah-Hartman
maintainerPATCH 16/22 ALSA: ctxfi: cthw20k2: fix mask on conf to allow 4 bits
In reply to Greg Kroah-HartmanFrom: Colin Ian King <[email protected]>
[ Upstream commit 26a9630c72ebac7c564db305a6aee54a8edde70e ]
Currently the mask operation on variable conf is just 3 bits so the switch statement case value of 8 is unreachable dead code. The function daio_mgr_dao_init can be passed a 4 bit value, function dao_rsc_init calls it with conf set to:
conf = (desc->msr & 0x7) | (desc->passthru << 3);
so clearly when desc->passthru is set to 1 then conf can be at least 8.
Fix this by changing the mask to 0xf.
--- sound/pci/ctxfi/cthw20k2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/pci/ctxfi/cthw20k2.c +1 -1
@@ -991,7 +991,7 @@ static int daio_mgr_dao_init(void *blk, unsigned int idx, unsigned int conf)if (idx <4 ) {/* S/PDIF output */ -switch ((conf &0x7 )) { +switch ((conf &0xf )) {case 1 :set_field (&ctl->txctl[idx],ATXCTL_NUC ,0 );break ;
Signature · 1 line
2.30.1
Greg Kroah-Hartman
maintainerPATCH 17/22 RDMA/rxe: Fix missing kconfig dependency on CRYPTO
In reply to Greg Kroah-HartmanFrom: Julian Braha <[email protected]>
[ Upstream commit 475f23b8c66d2892ad6acbf90ed757cafab13de7 ]
When RDMA_RXE is enabled and CRYPTO is disabled, Kbuild gives the following warning:
WARNING: unmet direct dependencies detected for CRYPTO_CRC32
Depends on [n]: CRYPTO [=n]
Selected by [y]:
- RDMA_RXE [=y] && (INFINIBAND_USER_ACCESS [=y] || !INFINIBAND_USER_ACCESS [=y]) && INET [=y] && PCI [=y] && INFINIBAND [=y] && INFINIBAND_VIRT_DMA [=y]
This is because RDMA_RXE selects CRYPTO_CRC32, without depending on or selecting CRYPTO, despite that config option being subordinate to CRYPTO.
--- drivers/infiniband/sw/rxe/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/infiniband/sw/rxe/Kconfig +1 -0
@@ -4,6 +4,7 @@ config RDMA_RXE depends on INET && PCI && INFINIBAND depends on INFINIBAND_VIRT_DMA select NET_UDP_TUNNEL + select CRYPTO select CRYPTO_CRC32 select DMA_VIRT_OPS ---help---
Signature · 1 line
2.30.1
Greg Kroah-Hartman
maintainerPATCH 18/22 IB/mlx5: Add missing error code
In reply to Greg Kroah-HartmanFrom: YueHaibing <[email protected]>
[ Upstream commit 3a9b3d4536e0c25bd3906a28c1f584177e49dd0f ]
Set err to -ENOMEM if kzalloc fails instead of 0.
--- drivers/infiniband/hw/mlx5/devx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/infiniband/hw/mlx5/devx.c +3 -1
@@ -2022,8 +2022,10 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT)( num_alloc_xa_entries++; event_sub =kzalloc (sizeof (*event_sub),GFP_KERNEL ); -if (!event_sub) +if (!event_sub) { + err = -ENOMEM ; goto err; + }list_add_tail (&event_sub->event_list, &sub_list);if (use_eventfd) {
Signature · 1 line
2.30.1
Greg Kroah-Hartman
maintainerPATCH 19/22 ALSA: hda: intel-nhlt: verify config type
In reply to Greg Kroah-HartmanFrom: Pierre-Louis Bossart <[email protected]>
[ Upstream commit a864e8f159b13babf552aff14a5fbe11abc017e4 ]
Multiple bug reports report issues with the SOF and SST drivers when dealing with single microphone cases.
We currently read the DMIC array information unconditionally but we don't check that the configuration type is actually a mic array.
When the DMIC link does not rely on a mic array configuration, the recommendation is to check the format information to infer the maximum number of channels, and map this to the number of microphones.
This leaves a potential for a mismatch between actual microphones available in hardware and what the ACPI table contains, but we have no other source of information.
Note that single microphone configurations can alternatively be handled with a 'mic array' configuration along with a 'vendor-defined' geometry.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201251
--- include/sound/intel-nhlt.h | 5 ++++ sound/hda/intel-nhlt.c | 54 +++++++++++++++++++++++++++++++------- 2 files changed, 50 insertions(+), 9 deletions(-)
include/sound/intel-nhlt.h +5 -0
@@ -112,6 +112,11 @@ struct nhlt_vendor_dmic_array_config {/* TODO add vendor mic config */ } __packed; +enum { +NHLT_CONFIG_TYPE_GENERIC =0 , +NHLT_CONFIG_TYPE_MIC_ARRAY =1 +}; +enum {NHLT_MIC_ARRAY_2CH_SMALL =0xa ,NHLT_MIC_ARRAY_2CH_BIG =0xb ,
sound/hda/intel-nhlt.c +45 -9
76 lines not on this page · raw message
Signature · 1 line
2.30.1
Greg Kroah-Hartman
maintainerPATCH 20/22 ftrace: Have recordmcount use w8 to read relp->r_info in arm64_is_fake_mcount
In reply to Greg Kroah-HartmanFrom: Chen Jun <[email protected]>
[ Upstream commit 999340d51174ce4141dd723105d4cef872b13ee9 ]
On little endian system, Use aarch64_be(gcc v7.3) downloaded from linaro.org to build image with CONFIG_CPU_BIG_ENDIAN = y, CONFIG_FTRACE = y, CONFIG_DYNAMIC_FTRACE = y.
gcc will create symbols of _mcount but recordmcount can not create mcount_loc for *.o.
aarch64_be-linux-gnu-objdump -r fs/namei.o | grep mcount 00000000000000d0 R_AARCH64_CALL26 _mcount
...
0000000000007190 R_AARCH64_CALL26 _mcount
The reason is than funciton arm64_is_fake_mcount can not work correctly. A symbol of _mcount in *.o compiled with big endian compiler likes:
00 00 00 2d 00 00 01 1bw(rp->r_info) will return 0x2d instead of 0x011b. Because w() takes uint32_t as parameter, which truncates rp->r_info.
Use w8() instead w() to read relp->r_info
--- scripts/recordmcount.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
scripts/recordmcount.c +1 -1
@@ -438,7 +438,7 @@ static int arm_is_fake_mcount(Elf32_Rel const *rp)static int arm64_is_fake_mcount (Elf64_Rel const *rp) { -return ELF64_R_TYPE (w (rp->r_info)) !=R_AARCH64_CALL26 ; +return ELF64_R_TYPE (w8 (rp->r_info)) !=R_AARCH64_CALL26 ; }/* 64-bit EM_MIPS has weird ELF64_Rela.r_info.
Signature · 1 line
2.30.1
Greg Kroah-Hartman
maintainerPATCH 21/22 rsxx: Return -EFAULT if copy_to_user() fails
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit 77516d25f54912a7baedeeac1b1b828b6f285152 ]
The copy_to_user() function returns the number of bytes remaining but we want to return -EFAULT to the user if it can't complete the copy. The "st" variable only holds zero on success or negative error codes on failure so the type should be int.
--- drivers/block/rsxx/core.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/block/rsxx/core.c +5 -3
@@ -165,15 +165,17 @@ static ssize_t rsxx_cram_read(struct file *fp, char __user *ubuf, {struct rsxx_cardinfo *card =file_inode (fp)->i_private;char *buf; -ssize_t st; +int st; buf =kzalloc (cnt,GFP_KERNEL );if (!buf)return -ENOMEM ; st =rsxx_creg_read (card,CREG_ADD_CRAM + (u32)*ppos, cnt, buf,1 ); -if (!st) - st =copy_to_user (ubuf, buf, cnt); +if (!st) { +if (copy_to_user (ubuf, buf, cnt)) + st = -EFAULT ; + }kfree (buf);if (st)return st;
Signature · 1 line
2.30.1
Greg Kroah-Hartman
maintainerPATCH 22/22 r8169: fix resuming from suspend on RTL8105e if machine runs on battery
In reply to Greg Kroah-HartmanFrom: Heiner Kallweit <[email protected]>
commit d2a04370817fc7b0172dad2ef2decf907e1a304e upstream.
Armin reported that after referenced commit his RTL8105e is dead when resuming from suspend and machine runs on battery. This patch has been confirmed to fix the issue.
--- drivers/net/ethernet/realtek/r8169_main.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/realtek/r8169_main.c +2 -0
@@ -3959,6 +3959,7 @@ static void rtl_pll_power_down(struct rtswitch (tp->mac_version) { case RTL_GIGA_MAC_VER_25 ... RTL_GIGA_MAC_VER_26: + case RTL_GIGA_MAC_VER_29 ... RTL_GIGA_MAC_VER_30: case RTL_GIGA_MAC_VER_32 ... RTL_GIGA_MAC_VER_33:case RTL_GIGA_MAC_VER_37 :case RTL_GIGA_MAC_VER_39 :
@@ -3989,6 +3990,7 @@ static void rtl_pll_power_up(struct rtl8 {switch (tp->mac_version) { case RTL_GIGA_MAC_VER_25 ... RTL_GIGA_MAC_VER_26: + case RTL_GIGA_MAC_VER_29 ... RTL_GIGA_MAC_VER_30: case RTL_GIGA_MAC_VER_32 ... RTL_GIGA_MAC_VER_33:case RTL_GIGA_MAC_VER_37 :case RTL_GIGA_MAC_VER_39 :
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.104 release. There are 22 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 Wed, 10 Mar 2021 12:27:05 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.104-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.104 release. There are 22 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 Wed, 10 Mar 2021 12:27:05 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.104-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.4:
12 builds: 12 pass, 0 fail
26 boots: 26 pass, 0 fail
57 tests: 57 pass, 0 failLinux version: 5.4.104-rc1-g1d493929c061
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.104 release. There are 22 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 Wed, 10 Mar 2021 12:27:05 +0000. Anything received after that time might be too late.
Build results:
total: 157 pass: 157 fail: 0 Qemu test results: total: 429 pass: 429 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.104 release. There are 22 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 Wed, 10 Mar 2021 12:27:05 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.104-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Tested on arm64 and x86 for 5.4.104-rc1,
Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.4.y
Version: 5.4.104-rc1
Commit: 1d493929c06100abd14b955538afa461dc2c8b69
Compiler: gcc version 7.3.0 (GCC)
arm64:
--------------------------------------------------------------------
Testcase Result Summary:total_num: 4710succeed_num: 4710failed_num: 0timeout_num: 0
x86 (No kernel failures)
--------------------------------------------------------------------
Testcase Result Summary:total_num: 4710succeed_num: 4704failed_num: 6timeout_num: 0
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.104 release. There are 22 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 Wed, 10 Mar 2021 12:27:05 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.104-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.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: 5.4.104-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 1d493929c06100abd14b955538afa461dc2c8b69
git describe: v5.4.103-23-g1d493929c061
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.103-23-g1d493929c061
No regressions (compared to build v5.4.103)
No fixes (compared to build v5.4.103)
Ran 53363 total tests in the following environments and test suites.
Environments
--------------
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- nxp-ls2088-64k_page_size
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan
- x86_64
Test Suites
-----------
* build
* linux-log-parser
* install-android-platform-tools-r2600
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-intel_pstate
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* perf
* v4l2-compliance
* fwts
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kvm
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-tc-testing
* kvm-unit-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-ipc-tests
* network-basic-tests
* kselftest-kexec
* kselftest-vm
* kselftest-x86
* ltp-open-posix-tests
* rcutorture
* kselftest-
* ssuite
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org