5.10.94-rc1 review
Subsystems (9)
Greg Kroah-Hartman
maintainerPATCH 442/563 crypto: stm32/crc32 - Fix kernel BUG triggered in probe()
In reply to Greg Kroah-HartmanFrom: Marek Vasut <[email protected]>
commit 29009604ad4e3ef784fd9b9fef6f23610ddf633d upstream.
The include/linux/crypto.h struct crypto_alg field cra_driver_name description states "Unique name of the transformation provider. " ... " this contains the name of the chip or provider and the name of the transformation algorithm."
In case of the stm32-crc driver, field cra_driver_name is identical for all registered transformation providers and set to the name of the driver itself, which is incorrect. This patch fixes it by assigning a unique cra_driver_name to each registered transformation provider.
The kernel crash is triggered when the driver calls crypto_register_shashes() which calls crypto_register_shash(), which calls crypto_register_alg(), which calls __crypto_register_alg(), which returns -EEXIST, which is propagated back through this call chain. Upon -EEXIST from crypto_register_shash(), the crypto_register_shashes() starts unregistering the providers back, and calls crypto_unregister_shash(), which calls crypto_unregister_alg(), and this is where the BUG() triggers due to incorrect cra_refcnt.
--- drivers/crypto/stm32/stm32-crc32.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/crypto/stm32/stm32-crc32.c +2 -2
@@ -279,7 +279,7 @@ static struct shash_alg algs[] = { .digestsize = CHKSUM_DIGEST_SIZE, .base = { .cra_name = "crc32", - .cra_driver_name = DRIVER_NAME, + .cra_driver_name = "stm32-crc32-crc32", .cra_priority = 200, .cra_flags = CRYPTO_ALG_OPTIONAL_KEY, .cra_blocksize = CHKSUM_BLOCK_SIZE,
@@ -301,7 +301,7 @@ static struct shash_alg algs[] = { .digestsize = CHKSUM_DIGEST_SIZE, .base = { .cra_name = "crc32c", - .cra_driver_name = DRIVER_NAME, + .cra_driver_name = "stm32-crc32-crc32c", .cra_priority = 200, .cra_flags = CRYPTO_ALG_OPTIONAL_KEY, .cra_blocksize = CHKSUM_BLOCK_SIZE,
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 443/563 crypto: caam - replace this_cpu_ptr with raw_cpu_ptr
In reply to Greg Kroah-HartmanFrom: Meng Li <[email protected]>
commit efd21e10fc3bf4c6da122470a5ae89ec4ed8d180 upstream.
When enable the kernel debug config, there is below calltrace detected:
BUG: using smp_processor_id() in preemptible [00000000] code: cryptomgr_test/339 caller is debug_smp_processor_id+0x20/0x30 CPU: 9 PID: 339 Comm: cryptomgr_test Not tainted 5.10.63-yocto-standard #1 Hardware name: NXP Layerscape LX2160ARDB (DT) Call trace: dump_backtrace+0x0/0x1a0 show_stack+0x24/0x30 dump_stack+0xf0/0x13c check_preemption_disabled+0x100/0x110 debug_smp_processor_id+0x20/0x30 dpaa2_caam_enqueue+0x10c/0x25c ...... cryptomgr_test+0x38/0x60 kthread+0x158/0x164 ret_from_fork+0x10/0x38
According to the comment in commit ac5d15b4519f("crypto: caam/qi2
- use affine DPIOs "), because preemption is no longer disabled
while trying to enqueue an FQID, it might be possible to run the enqueue on a different CPU(due to migration, when in process context), however this wouldn't be a functionality issue. But there will be above calltrace when enable kernel debug config. So, replace this_cpu_ptr with raw_cpu_ptr to avoid above call trace.
--- drivers/crypto/caam/caamalg_qi2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/crypto/caam/caamalg_qi2.c +1 -1
@@ -5467,7 +5467,7 @@ int dpaa2_caam_enqueue(struct device *dedpaa2_fd_set_len (&fd,dpaa2_fl_get_len (&req->fd_flt[1 ]));dpaa2_fd_set_flc (&fd, req->flc_dma); - ppriv =this_cpu_ptr (priv->ppriv); + ppriv =raw_cpu_ptr (priv->ppriv);for (i =0 ; i < (priv->dpseci_attr.num_tx_queues <<1 ); i++) { err =dpaa2_io_service_enqueue_fq (ppriv->dpio, ppriv->req_fqid, &fd);
Greg Kroah-Hartman
maintainerPATCH 444/563 ubifs: Error path in ubifs_remount_rw() seems to wrongly free write buffers
In reply to Greg Kroah-HartmanFrom: Petr Cvachoucek <[email protected]>
commit 3fea4d9d160186617ff40490ae01f4f4f36b28ff upstream.
it seems freeing the write buffers in the error path of the ubifs_remount_rw() is wrong. It leads later to a kernel oops like this:
[10016.431274] UBIFS (ubi0:0): start fixing up free space [10090.810042] UBIFS (ubi0:0): free space fixup complete [10090.814623] UBIFS error (ubi0:0 pid 512): ubifs_remount_fs: cannot spawn "ubifs_bgt0_0", error -4 [10101.915108] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 517 [10105.275498] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [10105.284352] Mem abort info: [10105.287160] ESR = 0x96000006 [10105.290252] EC = 0x25: DABT (current EL), IL = 32 bits [10105.295592] SET = 0, FnV = 0 [10105.298652] EA = 0, S1PTW = 0 [10105.301848] Data abort info: [10105.304723] ISV = 0, ISS = 0x00000006 [10105.308573] CM = 0, WnR = 0 [10105.311564] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000f03d1000 [10105.318034] [0000000000000030] pgd=00000000f6cee003, pud=00000000f4884003, pmd=0000000000000000 [10105.326783] Internal error: Oops: 96000006 [#1] PREEMPT SMP [10105.332355] Modules linked in: ath10k_pci ath10k_core ath mac80211 libarc4 cfg80211 nvme nvme_core cryptodev(O) [10105.342468] CPU: 3 PID: 518 Comm: touch Tainted: G O 5.4.3 #1 [10105.349517] Hardware name: HYPEX CPU (DT) [10105.353525] pstate: 40000005 (nZcv daif -PAN -UAO) [10105.358324] pc : atomic64_try_cmpxchg_acquire.constprop.22+0x8/0x34 [10105.364596] lr : mutex_lock+0x1c/0x34 [10105.368253] sp : ffff000075633aa0 [10105.371563] x29: ffff000075633aa0 x28: 0000000000000001 [10105.376874] x27: ffff000076fa80c8 x26: 0000000000000004 [10105.382185] x25: 0000000000000030 x24: 0000000000000000 [10105.387495] x23: 0000000000000000 x22: 0000000000000038 [10105.392807] x21: 000000000000000c x20: ffff000076fa80c8 [10105.398119] x19: ffff000076fa8000 x18: 0000000000000000 [10105.403429] x17: 0000000000000000 x16: 0000000000000000 [10105.408741] x15: 0000000000000000 x14: fefefefefefefeff [10105.414052] x13: 0000000000000000 x12: 0000000000000fe0 [10105.419364] x11: 0000000000000fe0 x10: ffff000076709020 [10105.424675] x9 : 0000000000000000 x8 : 00000000000000a0 [10105.429986] x7 : ffff000076fa80f4 x6 : 0000000000000030 [10105.435297] x5 : 0000000000000000 x4 : 0000000000000000 [10105.440609] x3 : 0000000000000000 x2 : ffff00006f276040 [10105.445920] x1 : ffff000075633ab8 x0 : 0000000000000030 [10105.451232] Call trace: [10105.453676] atomic64_try_cmpxchg_acquire.constprop.22+0x8/0x34 [10105.459600] ubifs_garbage_collect+0xb4/0x334 [10105.463956] ubifs_budget_space+0x398/0x458 [10105.468139] ubifs_create+0x50/0x180 [10105.471712] path_openat+0x6a0/0x9b0 [10105.475284] do_filp_open+0x34/0x7c [10105.478771] do_sys_open+0x78/0xe4 [10105.482170] __arm64_sys_openat+0x1c/0x24 [10105.486180] el0_svc_handler+0x84/0xc8 [10105.489928] el0_svc+0x8/0xc [10105.492808] Code: 52800013 17fffffb d2800003 f9800011 (c85ffc05) [10105.498903] ---[ end trace 46b721d93267a586 ]---
To reproduce the problem:
1. Filesystem initially mounted read-only, free space fixup flag set.
2. mount -o remount,rw <mountpoint>
3. it takes some time (free space fixup running)
... try to terminate running mount by CTRL-C
... does not respond, only after free space fixup is complete ... then "ubifs_remount_fs: cannot spawn "ubifs_bgt0_0", error -4"
4. mount -o remount,rw <mountpoint>
... now finished instantly (fixup already done).
5. Create file or just unmount the filesystem and we get the oops.
--- fs/ubifs/super.c | 1 - 1 file changed, 1 deletion(-)
fs/ubifs/super.c +0 -1
@@ -1853,7 +1853,6 @@ out:kthread_stop (c->bgt); c->bgt =NULL ; } -free_wbufs (c);kfree (c->write_reserve_buf); c->write_reserve_buf =NULL ;vfree (c->ileb_buf);
Greg Kroah-Hartman
maintainerPATCH 445/563 tpm: fix NPE on probe for missing device
In reply to Greg Kroah-HartmanFrom: Patrick Williams <[email protected]>
commit 84cc69589700b90a4c8d27b481a51fce8cca6051 upstream.
When using the tpm_tis-spi driver on a system missing the physical TPM, a null pointer exception was observed.
[ 0.938677] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 0.939020] pgd = 10c753cb
[ 0.939237] [00000004] *pgd=00000000
[ 0.939808] Internal error: Oops: 5 [#1] SMP ARM
[ 0.940157] CPU: 0 PID: 48 Comm: kworker/u4:1 Not tainted 5.15.10-dd1e40c #1
[ 0.940364] Hardware name: Generic DT based system
[ 0.940601] Workqueue: events_unbound async_run_entry_fn
[ 0.941048] PC is at tpm_tis_remove+0x28/0xb4
[ 0.941196] LR is at tpm_tis_core_init+0x170/0x6acThis is due to an attempt in 'tpm_tis_remove' to use the drvdata, which was not initialized in 'tpm_tis_core_init' prior to the first error.
Move the initialization of drvdata earlier so 'tpm_tis_remove' has access to it.
--- drivers/char/tpm/tpm_tis_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/char/tpm/tpm_tis_core.c +2 -2
@@ -950,6 +950,8 @@ int tpm_tis_core_init(struct device *dev priv->timeout_max =TPM_TIMEOUT_USECS_MAX ; priv->phy_ops = phy_ops; +dev_set_drvdata (&chip->dev, priv); + rc =tpm_tis_read32 (priv,TPM_DID_VID (0 ), &vendor);if (rc <0 )return rc;
@@ -962,8 +964,6 @@ int tpm_tis_core_init(struct device *dev priv->timeout_max =TIS_TIMEOUT_MAX_ATML ; } -dev_set_drvdata (&chip->dev, priv); -if (is_bsw ()) { priv->ilb_base_addr =ioremap (INTEL_LEGACY_BLK_BASE_ADDR ,ILB_REMAP_SIZE );
Greg Kroah-Hartman
maintainerPATCH 446/563 spi: uniphier: Fix a bug that doesnt point to private data correctly
In reply to Greg Kroah-HartmanFrom: Kunihiko Hayashi <[email protected]>
commit 80bb73a9fbcde4ecc55e12f10c73fabbe68a24d1 upstream.
In uniphier_spi_remove(), there is a wrong code to get private data from the platform device, so the driver can't be removed properly.
The driver should get spi_master from the platform device and retrieve the private data from it.
--- drivers/spi/spi-uniphier.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/spi/spi-uniphier.c +6 -5
@@ -767,12 +767,13 @@ out_master_put:static int uniphier_spi_remove (struct platform_device *pdev) { -struct uniphier_spi_priv *priv =platform_get_drvdata (pdev); +struct spi_master *master =platform_get_drvdata (pdev); +struct uniphier_spi_priv *priv =spi_master_get_devdata (master); -if (priv->master->dma_tx) -dma_release_channel (priv->master->dma_tx); -if (priv->master->dma_rx) -dma_release_channel (priv->master->dma_rx); +if (master->dma_tx) +dma_release_channel (master->dma_tx); +if (master->dma_rx) +dma_release_channel (master->dma_rx);clk_disable_unprepare (priv->clk);
Greg Kroah-Hartman
maintainerPATCH 447/563 xen/gntdev: fix unmap notification order
In reply to Greg Kroah-HartmanFrom: Oleksandr Andrushchenko <[email protected]>
commit ce2f46f3531a03781181b7f4bd1ff9f8c5086e7e upstream.
While working with Xen's libxenvchan library I have faced an issue with unmap notifications sent in wrong order if both UNMAP_NOTIFY_SEND_EVENT and UNMAP_NOTIFY_CLEAR_BYTE were requested: first we send an event channel notification and then clear the notification byte which renders in the below inconsistency (cli_live is the byte which was requested to be cleared on unmap):
[ 444.514243] gntdev_put_map UNMAP_NOTIFY_SEND_EVENT map->notify.event 6 libxenvchan_is_open cli_live 1 [ 444.515239] __unmap_grant_pages UNMAP_NOTIFY_CLEAR_BYTE at 14
Thus it is not possible to reliably implement the checks like
- wait for the notification (UNMAP_NOTIFY_SEND_EVENT)
- check the variable (UNMAP_NOTIFY_CLEAR_BYTE)
because it is possible that the variable gets checked before it is cleared by the kernel.
To fix that we need to re-order the notifications, so the variable is first gets cleared and then the event channel notification is sent. With this fix I can see the correct order of execution:
[ 54.522611] __unmap_grant_pages UNMAP_NOTIFY_CLEAR_BYTE at 14 [ 54.537966] gntdev_put_map UNMAP_NOTIFY_SEND_EVENT map->notify.event 6
libxenvchan_is_open cli_live 0
--- drivers/xen/gntdev.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/xen/gntdev.c +3 -3
@@ -240,13 +240,13 @@ void gntdev_put_map(struct gntdev_priv *if (!refcount_dec_and_test (&map->users))return ; +if (map->pages && !use_ptemod) +unmap_grant_pages (map,0 , map->count); +if (map->notify.flags &UNMAP_NOTIFY_SEND_EVENT ) {notify_remote_via_evtchn (map->notify.event);evtchn_put (map->notify.event); } - -if (map->pages && !use_ptemod) -unmap_grant_pages (map,0 , map->count);gntdev_free_map (map); }
Greg Kroah-Hartman
maintainerPATCH 448/563 fuse: Pass correct lend value to filemap_write_and_wait_range()
In reply to Greg Kroah-HartmanFrom: Xie Yongji <[email protected]>
commit e388164ea385f04666c4633f5dc4f951fca71890 upstream.
The acceptable maximum value of lend parameter in filemap_write_and_wait_range() is LLONG_MAX rather than -1. And there is also some logic depending on LLONG_MAX check in write_cache_pages(). So let's pass LLONG_MAX to filemap_write_and_wait_range() in fuse_writeback_range() instead.
--- fs/fuse/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/fuse/file.c +1 -1
@@ -3251,7 +3251,7 @@ fuse_direct_IO(struct kiocb *iocb, strucstatic int fuse_writeback_range (struct inode *inode,loff_t start,loff_t end) { -int err =filemap_write_and_wait_range (inode->i_mapping, start,-1 ); +int err =filemap_write_and_wait_range (inode->i_mapping, start,LLONG_MAX );if (!err)fuse_sync_writes (inode);
Greg Kroah-Hartman
maintainerPATCH 449/563 serial: Fix incorrect rs485 polarity on uart open
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit d3b3404df318504ec084213ab1065b73f49b0f1d upstream.
Commit a6845e1e1b78 ("serial: core: Consider rs485 settings to drive RTS") sought to deassert RTS when opening an rs485-enabled uart port. That way, the transceiver does not occupy the bus until it transmits data.
Unfortunately, the commit mixed up the logic and *asserted* RTS instead of *deasserting* it:
The commit amended uart_port_dtr_rts(), which raises DTR and RTS when opening an rs232 port. "Raising" actually means lowering the signal that's coming out of the uart, because an rs232 transceiver not only changes a signal's voltage level, it also *inverts* the signal. See the simplified schematic in the MAX232 datasheet for an example:
https://www.ti.com/lit/ds/symlink/max232.pdf
So, to raise RTS on an rs232 port, TIOCM_RTS is *set* in port->mctrl and that results in the signal being driven low.
In contrast to rs232, the signal level for rs485 Transmit Enable is the identity, not the inversion: If the transceiver expects a "high" RTS signal for Transmit Enable, the signal coming out of the uart must also be high, so TIOCM_RTS must be *cleared* in port->mctrl.
The commit did the exact opposite, but it's easy to see why given the confusing semantics of rs232 and rs485. Fix it.
--- drivers/tty/serial/serial_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/tty/serial/serial_core.c +2 -2
@@ -162,7 +162,7 @@ static void uart_port_dtr_rts(struct uarint RTS_after_send = !!(uport->rs485.flags &SER_RS485_RTS_AFTER_SEND );if (raise) { -if (rs485_on && !RTS_after_send) { +if (rs485_on && RTS_after_send) {uart_set_mctrl (uport,TIOCM_DTR );uart_clear_mctrl (uport,TIOCM_RTS ); }else {
@@ -171,7 +171,7 @@ static void uart_port_dtr_rts(struct uar }else {unsigned int clear =TIOCM_DTR ; - clear |= (!rs485_on || !RTS_after_send) ?TIOCM_RTS :0 ; + clear |= (!rs485_on || RTS_after_send) ?TIOCM_RTS :0 ;uart_clear_mctrl (uport, clear); } }
Greg Kroah-Hartman
maintainerPATCH 450/563 cputime, cpuacct: Include guest time in user time in cpuacct.stat
In reply to Greg Kroah-HartmanFrom: Andrey Ryabinin <[email protected]>
commit 9731698ecb9c851f353ce2496292ff9fcea39dff upstream.
cpuacct.stat in no-root cgroups shows user time without guest time included int it. This doesn't match with user time shown in root cpuacct.stat and /proc/<pid>/stat. This also affects cgroup2's cpu.stat in the same way.
Make account_guest_time() to add user time to cgroup's cpustat to fix this.
--- kernel/sched/cputime.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/sched/cputime.c +2 -2
@@ -147,10 +147,10 @@ void account_guest_time(struct task_stru/* Add guest time to cpustat. */ if (task_nice (p) >0 ) { - cpustat[CPUTIME_NICE ] += cputime; +task_group_account_field (p,CPUTIME_NICE , cputime); cpustat[CPUTIME_GUEST_NICE ] += cputime; }else { - cpustat[CPUTIME_USER ] += cputime; +task_group_account_field (p,CPUTIME_USER , cputime); cpustat[CPUTIME_GUEST ] += cputime; } }
Greg Kroah-Hartman
maintainerPATCH 451/563 tracing/kprobes: nmissed not showed correctly for kretprobe
In reply to Greg Kroah-HartmanFrom: Xiangyang Zhang <[email protected]>
commit dfea08a2116fe327f79d8f4d4b2cf6e0c88be11f upstream.
The 'nmissed' column of the 'kprobe_profile' file for kretprobe is not showed correctly, kretprobe can be skipped by two reasons, shortage of kretprobe_instance which is counted by tk->rp.nmissed, and kprobe itself is missed by some reason, so to show the sum.
--- kernel/trace/trace_kprobe.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
kernel/trace/trace_kprobe.c +4 -1
@@ -1183,15 +1183,18 @@ static int probes_profile_seq_show(struc {struct dyn_event *ev = v;struct trace_kprobe *tk; +unsigned long nmissed;if (!is_trace_kprobe (ev))return 0 ; tk =to_trace_kprobe (ev); + nmissed =trace_kprobe_is_return (tk) ? + tk->rp.kp.nmissed + tk->rp.nmissed : tk->rp.kp.nmissed;seq_printf (m," %-44s %15lu %15lu\n" ,trace_probe_name (&tk->tp),trace_kprobe_nhit (tk), - tk->rp.kp.nmissed); + nmissed);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 452/563 iwlwifi: mvm: Increase the scan timeout guard to 30 seconds
In reply to Greg Kroah-HartmanFrom: Ilan Peer <[email protected]>
commit ced50f1133af12f7521bb777fcf4046ca908fb77 upstream.
With the introduction of 6GHz channels the scan guard timeout should be adjusted to account for the following extreme case:
- All 6GHz channels are scanned passively: 58 channels.
- The scan is fragmented with the following parameters: 3 fragments, 95 TUs suspend time, 44 TUs maximal out of channel time.
The above would result with scan time of more than 24 seconds. Thus, set the timeout to 30 seconds.
--- drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/intel/iwlwifi/mvm/scan.c +1 -1
@@ -2157,7 +2157,7 @@ static int iwl_mvm_check_running_scans(sreturn -EIO ; } -#define SCAN_TIMEOUT 20000 +#define SCAN_TIMEOUT 30000void iwl_mvm_scan_timeout_wk (struct work_struct *work) {
Greg Kroah-Hartman
maintainerPATCH 453/563 s390/mm: fix 2KB pgtable release race
In reply to Greg Kroah-HartmanFrom: Alexander Gordeev <[email protected]>
commit c2c224932fd0ee6854d6ebfc8d059c2bcad86606 upstream.
There is a race on concurrent 2KB-pgtables release paths when both upper and lower halves of the containing parent page are freed, one via page_table_free_rcu() + __tlb_remove_table(), and the other via page_table_free(). The race might lead to a corruption as result of remove of list item in page_table_free() concurrently with __free_page() in __tlb_remove_table().
Let's assume first the lower and next the upper 2KB-pgtables are freed from a page. Since both halves of the page are allocated the tracking byte (bits 24-31 of the page _refcount) has value of 0x03 initially:
CPU0 CPU1
---- ----
page_table_free_rcu() // lower half
{
// _refcount[31..24] == 0x03
...
atomic_xor_bits(&page->_refcount,
0x11U << (0 + 24));
// _refcount[31..24] <= 0x12
...
table = table | (1U << 0);
tlb_remove_table(tlb, table);
}
...
__tlb_remove_table()
{
// _refcount[31..24] == 0x12
mask = _table & 3;
// mask <= 0x01
...
page_table_free() // upper half
{
// _refcount[31..24] == 0x12
...
atomic_xor_bits(
&page->_refcount,
1U << (1 + 24));
// _refcount[31..24] <= 0x10
// mask <= 0x10
...
atomic_xor_bits(&page->_refcount,
mask << (4 + 24));
// _refcount[31..24] <= 0x00
// mask <= 0x00
...
if (mask != 0) // == false
break;
fallthrough;
...
if (mask & 3) // == false
...
else
__free_page(page); list_del(&page->lru);
^^^^^^^^^^^^^^^^^^ RACE! ^^^^^^^^^^^^^^^^^^^^^
} ...
}The problem is page_table_free() releases the page as result of lower nibble unset and __tlb_remove_table() observing zero too early. With this update page_table_free() will use the similar logic as page_table_free_rcu() + __tlb_remove_table(), and mark the fragment as pending for removal in the upper nibble until after the list_del().
In other words, the parent page is considered as unreferenced and safe to release only when the lower nibble is cleared already and unsetting a bit in upper nibble results in that nibble turned zero.
--- arch/s390/mm/pgalloc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/s390/mm/pgalloc.c +3 -1
@@ -253,13 +253,15 @@ void page_table_free(struct mm_struct *m/* Free 2K page table fragment of a 4K page */ bit = (__pa (table) & ~PAGE_MASK )/(PTRS_PER_PTE *sizeof (pte_t));spin_lock_bh (&mm->context.lock); - mask =atomic_xor_bits (&page->_refcount,1U << (bit +24 )); + mask =atomic_xor_bits (&page->_refcount,0x11U << (bit +24 )); mask >>=24 ;if (mask &3 )list_add (&page->lru, &mm->context.pgtable_list);else list_del (&page->lru);spin_unlock_bh (&mm->context.lock); + mask =atomic_xor_bits (&page->_refcount,0x10U << (bit +24 )); + mask >>=24 ;if (mask !=0 )return ; }else {
Greg Kroah-Hartman
maintainerPATCH 454/563 device property: Fix fwnode_graph_devcon_match() fwnode leak
In reply to Greg Kroah-HartmanFrom: Sakari Ailus <[email protected]>
commit 4a7f4110f79163fd53ea65438041994ed615e3af upstream.
For each endpoint it encounters, fwnode_graph_devcon_match() checks whether the endpoint's remote port parent device is available. If it is not, it ignores the endpoint but does not put the reference to the remote endpoint port parent fwnode. For available devices the fwnode handle reference is put as expected.
Put the reference for unavailable devices now.
--- drivers/base/property.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/base/property.c +3 -1
@@ -1195,8 +1195,10 @@ fwnode_graph_devcon_match(struct fwnode_fwnode_graph_for_each_endpoint (fwnode, ep) { node =fwnode_graph_get_remote_port_parent (ep); -if (!fwnode_device_is_available (node)) +if (!fwnode_device_is_available (node)) { +fwnode_handle_put (node);continue ; + } ret =match (node, con_id, data);fwnode_handle_put (node);
Greg Kroah-Hartman
maintainerPATCH 455/563 drm/etnaviv: limit submit sizes
In reply to Greg Kroah-HartmanFrom: Lucas Stach <[email protected]>
commit 6dfa2fab8ddd46faa771a102672176bee7a065de upstream.
Currently we allow rediculous amounts of kernel memory being allocated via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put some reasonable limits in to fix this.
The commandstream size is limited to 64KB, which was already a soft limit on older kernels after which the kernel only took submits on a best effort base, so there is no userspace that tries to submit commandstreams larger than this. Even if the whole commandstream is a single incrementing address load, the size limit also limits the number of potential relocs and referenced buffers to slightly under 64K, so use the same limit for those arguments. The performance monitoring infrastructure currently supports less than 50 performance counter signals, so limiting them to 128 on a single submit seems like a reasonably future-proof number for now. This number can be bumped if needed without breaking the interface.
--- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c +6 -0
@@ -469,6 +469,12 @@ int etnaviv_ioctl_gem_submit(struct drm_return -EINVAL ; } +if (args->stream_size >SZ_64K || args->nr_relocs >SZ_64K || + args->nr_bos >SZ_64K || args->nr_pmrs >128 ) { +DRM_ERROR ("submit arguments out of size limits\n" ); +return -EINVAL ; + } +/* * Copy the command submission and bo array to kernel space in * one go, and do this outside of any locks.
Greg Kroah-Hartman
maintainerPATCH 456/563 drm/nouveau/kms/nv04: use vzalloc for nv04_display
In reply to Greg Kroah-HartmanFrom: Ilia Mirkin <[email protected]>
commit bd6e07e72f37f34535bec7eebc807e5fcfe37b43 upstream.
The struct is giant, and triggers an order-7 allocation (512K). There is no reason for this to be kmalloc-type memory, so switch to vmalloc. This should help loading nouveau on low-memory and/or long-running systems.
--- drivers/gpu/drm/nouveau/dispnv04/disp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/nouveau/dispnv04/disp.c +2 -2
@@ -205,7 +205,7 @@ nv04_display_destroy(struct drm_device *nvif_notify_dtor (&disp->flip);nouveau_display (dev)->priv =NULL ; -kfree (disp); +vfree (disp);nvif_object_unmap (&drm->client.device.object); }
@@ -223,7 +223,7 @@ nv04_display_create(struct drm_device *dstruct nv04_display *disp;int i, ret; - disp =kzalloc (sizeof (*disp),GFP_KERNEL ); + disp =vzalloc (sizeof (*disp));if (!disp)return -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 457/563 drm/bridge: analogix_dp: Make PSR-exit block less
In reply to Greg Kroah-HartmanFrom: Brian Norris <[email protected]>
commit c4c6ef229593366ab593d4d424addc7025b54a76 upstream.
Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"), "PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor started using the blocking variant, for a variety of reasons -- quoting Sean Paul's potentially-faulty memory:
"""
- To avoid racing a subsequent PSR entry (if exit takes a long time)
- To avoid racing disable/modeset
- We're not displaying new content while exiting PSR anyways, so there is minimal utility in allowing frames to be submitted
- We're lying to userspace telling them frames are on the screen when we're just dropping them on the floor
"""
However, I'm finding that this blocking transition is causing upwards of 60+ ms of unneeded latency on PSR-exit, to the point that initial cursor movements when leaving PSR are unbearably jumpy.
It turns out that we need to meet in the middle somewhere: Sean is right that we were "lying to userspace" with a non-blocking PSR-exit, but the new blocking behavior is also waiting too long:
According to the eDP specification, the sink device must support PSR entry transitions from both state 4 (ACTIVE_RESYNC) and state 0 (INACTIVE). It also states that in ACTIVE_RESYNC, "the Sink device must display the incoming active frames from the Source device with no visible glitches and/or artifacts."
Thus, for our purposes, we only need to wait for ACTIVE_RESYNC before moving on; we are ready to display video, and subsequent PSR-entry is safe.
Tested on a Samsung Chromebook Plus (i.e., Rockchip RK3399 Gru Kevin), where this saves about 60ms of latency, for PSR-exit that used to take about 80ms.
--- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c +12 -2
@@ -1086,11 +1086,21 @@ int analogix_dp_send_psr_spd(struct analif (!blocking)return 0 ; +/* +* db[1]!=0: entering PSR, wait for fully active remote frame buffer. +* db[1]==0: exiting PSR, wait for either +* (a) ACTIVE_RESYNC - the sink "must display the +* incoming active frames from the Source device with no visible +* glitches and/or artifacts", even though timings may still be +* re-synchronizing; or +* (b) INACTIVE - the transition is fully complete. +*/ ret =readx_poll_timeout (analogix_dp_get_psr_status, dp, psr_status, psr_status >=0 && ((vsc->db[1 ] && psr_status ==DP_PSR_SINK_ACTIVE_RFB ) || - (!vsc->db[1 ] && psr_status ==DP_PSR_SINK_INACTIVE )),1500 , -DP_TIMEOUT_PSR_LOOP_MS *1000 ); + (!vsc->db[1 ] && (psr_status ==DP_PSR_SINK_ACTIVE_RESYNC || + psr_status ==DP_PSR_SINK_INACTIVE ))), +1500 ,DP_TIMEOUT_PSR_LOOP_MS *1000 );if (ret) {dev_warn (dp->dev,"Failed to apply PSR %d\n" , ret);return ret;
Greg Kroah-Hartman
maintainerPATCH 458/563 parisc: Fix lpa and lpa_user defines
In reply to Greg Kroah-HartmanFrom: John David Anglin <[email protected]>
commit db19c6f1a2a353cc8dec35b4789733a3cf6e2838 upstream.
While working on the rewrite to the light-weight syscall and futex code, I experimented with using a hash index based on the user physical address of atomic variable. This exposed two problems with the lpa and lpa_user defines.
Because of the copy instruction, the pa argument needs to be an early clobber argument. This prevents gcc from allocating the va and pa arguments to the same register.
Secondly, the lpa instruction can cause a page fault so we need to catch exceptions.
--- arch/parisc/include/asm/special_insns.h | 44 +++++++++++++++++--------------- 1 file changed, 24 insertions(+), 20 deletions(-)
arch/parisc/include/asm/special_insns.h +24 -20
@@ -2,28 +2,32 @@#ifndef __PARISC_SPECIAL_INSNS_H#define __PARISC_SPECIAL_INSNS_H -#define lpa (va) ({ \ - unsigned long pa; \ - __asm__ __volatile__( \ - "copy %%r0,%0\n\t" \ - "lpa %%r0(%1),%0" \ - : "=r" (pa) \ - : "r" (va) \ - : "memory" \ - ); \ - pa; \ +#define lpa (va) ({ \ + unsigned long pa; \ + __asm__ __volatile__( \ + "copy %%r0,%0\n" \ + "8:\tlpa %%r0(%1),%0\n" \ + "9:\n" \ + ASM_EXCEPTIONTABLE_ENTRY(8b, 9b) \ + : "=&r" (pa) \ + : "r" (va) \ + : "memory" \ + ); \ + pa; \ }) -#define lpa_user (va) ({ \ - unsigned long pa; \ - __asm__ __volatile__( \ - "copy %%r0,%0\n\t" \ - "lpa %%r0(%%sr3,%1),%0" \ - : "=r" (pa) \ - : "r" (va) \ - : "memory" \ - ); \ - pa; \ +#define lpa_user (va) ({ \ + unsigned long pa; \ + __asm__ __volatile__( \ + "copy %%r0,%0\n" \ + "8:\tlpa %%r0(%%sr3,%1),%0\n" \ + "9:\n" \ + ASM_EXCEPTIONTABLE_ENTRY(8b, 9b) \ + : "=&r" (pa) \ + : "r" (va) \ + : "memory" \ + ); \ + pa; \ })#define mfctl (reg) ({ \
Greg Kroah-Hartman
maintainerPATCH 459/563 powerpc/64s/radix: Fix huge vmap false positive
In reply to Greg Kroah-HartmanFrom: Nicholas Piggin <[email protected]>
commit 467ba14e1660b52a2f9338b484704c461bd23019 upstream.
pmd_huge() is defined to false when HUGETLB_PAGE is not configured, but the vmap code still installs huge PMDs. This leads to false bad PMD errors when vunmapping because it is not seen as a huge PTE, and the bad PMD check catches it. The end result may not be much more serious than some bad pmd warning messages, because the pmd_none_or_clear_bad() does what we wanted and clears the huge PTE anyway.
Fix this by checking pmd_is_leaf(), which checks for a PTE regardless of config options. The whole huge/large/leaf stuff is a tangled mess but that's kernel-wide and not something we can improve much in arch/powerpc code.
pmd_page(), pud_page(), etc., called by vmalloc_to_page() on huge vmaps can similarly trigger a false VM_BUG_ON when CONFIG_HUGETLB_PAGE=n, so those checks are adjusted. The checks were added by commit d6eacedd1f0e ("powerpc/book3s: Use config independent helpers for page table walk"), while implementing a similar fix for other page table walking functions.
--- arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++-- arch/powerpc/mm/pgtable_64.c | 14 +++++++++++--- 2 files changed, 13 insertions(+), 5 deletions(-)
arch/powerpc/mm/book3s64/radix_pgtable.c +2 -2
@@ -1152,7 +1152,7 @@ int pud_set_huge(pud_t *pud, phys_addr_tint pud_clear_huge (pud_t *pud) { -if (pud_huge (*pud)) { +if (pud_is_leaf (*pud)) {pud_clear (pud);return 1 ; }
@@ -1199,7 +1199,7 @@ int pmd_set_huge(pmd_t *pmd, phys_addr_tint pmd_clear_huge (pmd_t *pmd) { -if (pmd_huge (*pmd)) { +if (pmd_is_leaf (*pmd)) {pmd_clear (pmd);return 1 ; }
arch/powerpc/mm/pgtable_64.c +11 -3
@@ -102,7 +102,8 @@ EXPORT_SYMBOL(__pte_frag_size_shift);struct page *p4d_page (p4d_t p4d) {if (p4d_is_leaf (p4d)) { -VM_WARN_ON (!p4d_huge (p4d)); +if (!IS_ENABLED (CONFIG_HAVE_ARCH_HUGE_VMAP )) +VM_WARN_ON (!p4d_huge (p4d));return pte_page (p4d_pte (p4d)); }return virt_to_page (p4d_page_vaddr (p4d));
@@ -112,7 +113,8 @@ struct page *p4d_page(p4d_t p4d)struct page *pud_page (pud_t pud) {if (pud_is_leaf (pud)) { -VM_WARN_ON (!pud_huge (pud)); +if (!IS_ENABLED (CONFIG_HAVE_ARCH_HUGE_VMAP )) +VM_WARN_ON (!pud_huge (pud));return pte_page (pud_pte (pud)); }return virt_to_page (pud_page_vaddr (pud));
@@ -125,7 +127,13 @@ struct page *pud_page(pud_t pud)struct page *pmd_page (pmd_t pmd) {if (pmd_is_leaf (pmd)) { -VM_WARN_ON (!(pmd_large (pmd) ||pmd_huge (pmd))); +/* +* vmalloc_to_page may be called on any vmap address (not only +* vmalloc), and it uses pmd_page() etc., when huge vmap is +* enabled so these checks can't be used. +*/ +if (!IS_ENABLED (CONFIG_HAVE_ARCH_HUGE_VMAP )) +VM_WARN_ON (!(pmd_large (pmd) ||pmd_huge (pmd)));return pte_page (pmd_pte (pmd)); }return virt_to_page (pmd_page_vaddr (pmd));
Greg Kroah-Hartman
maintainerPATCH 460/563 PCI: xgene: Fix IB window setup
In reply to Greg Kroah-HartmanFrom: Rob Herring <[email protected]>
commit c7a75d07827a1f33d566e18e6098379cc2a0c2b2 upstream.
Commit 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") broke PCI support on XGene. The cause is the IB resources are now sorted in address order instead of being in DT dma-ranges order. The result is which inbound registers are used for each region are swapped. I don't know the details about this h/w, but it appears that IB region 0 registers can't handle a size greater than 4GB. In any case, limiting the size for region 0 is enough to get back to the original assignment of dma-ranges to regions.
--- drivers/pci/controller/pci-xgene.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pci/controller/pci-xgene.c +1 -1
@@ -467,7 +467,7 @@ static int xgene_pcie_select_ib_reg(u8 *return 1 ; } -if ((size >SZ_1K ) && (size <SZ_1T ) && !(*ib_reg_mask & (1 <<0 ))) { +if ((size >SZ_1K ) && (size <SZ_4G ) && !(*ib_reg_mask & (1 <<0 ))) { *ib_reg_mask |= (1 <<0 );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 461/563 PCI: pciehp: Use down_read/write_nested(reset_lock) to fix lockdep errors
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
commit 085a9f43433f30cbe8a1ade62d9d7827c3217f4d upstream.
Use down_read_nested() and down_write_nested() when taking the ctrl->reset_lock rw-sem, passing the number of PCIe hotplug controllers in the path to the PCI root bus as lock subclass parameter.
This fixes the following false-positive lockdep report when unplugging a Lenovo X1C8 from a Lenovo 2nd gen TB3 dock:
pcieport 0000:06:01.0: pciehp: Slot(1): Link Down
pcieport 0000:06:01.0: pciehp: Slot(1): Card not present
============================================
WARNING: possible recursive locking detected
5.16.0-rc2+ #621 Not tainted
--------------------------------------------
irq/124-pciehp/86 is trying to acquire lock:
ffff8e5ac4299ef8 (&ctrl->reset_lock){.+.+}-{3:3}, at: pciehp_check_presence+0x23/0x80
but task is already holding lock:
ffff8e5ac4298af8 (&ctrl->reset_lock){.+.+}-{3:3}, at: pciehp_ist+0xf3/0x180
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&ctrl->reset_lock);
lock(&ctrl->reset_lock);*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by irq/124-pciehp/86:
#0: ffff8e5ac4298af8 (&ctrl->reset_lock){.+.+}-{3:3}, at: pciehp_ist+0xf3/0x180 #1: ffffffffa3b024e8 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pciehp_unconfigure_device+0x31/0x110 #2: ffff8e5ac1ee2248 (&dev->mutex){....}-{3:3}, at: device_release_driver+0x1c/0x40
stack backtrace: CPU: 4 PID: 86 Comm: irq/124-pciehp Not tainted 5.16.0-rc2+ #621 Hardware name: LENOVO 20U90SIT19/20U90SIT19, BIOS N2WET30W (1.20 ) 08/26/2021 Call Trace: <TASK> dump_stack_lvl+0x59/0x73 __lock_acquire.cold+0xc5/0x2c6 lock_acquire+0xb5/0x2b0 down_read+0x3e/0x50 pciehp_check_presence+0x23/0x80 pciehp_runtime_resume+0x5c/0xa0 device_for_each_child+0x45/0x70 pcie_port_device_runtime_resume+0x20/0x30 pci_pm_runtime_resume+0xa7/0xc0 __rpm_callback+0x41/0x110 rpm_callback+0x59/0x70 rpm_resume+0x512/0x7b0 __pm_runtime_resume+0x4a/0x90 __device_release_driver+0x28/0x240 device_release_driver+0x26/0x40 pci_stop_bus_device+0x68/0x90 pci_stop_bus_device+0x2c/0x90 pci_stop_and_remove_bus_device+0xe/0x20 pciehp_unconfigure_device+0x6c/0x110 pciehp_disable_slot+0x5b/0xe0 pciehp_handle_presence_or_link_change+0xc3/0x2f0 pciehp_ist+0x179/0x180
This lockdep warning is triggered because with Thunderbolt, hotplug ports are nested. When removing multiple devices in a daisy-chain, each hotplug port's reset_lock may be acquired recursively. It's never the same lock, so the lockdep splat is a false positive.
Because locks at the same hierarchy level are never acquired recursively, a per-level lockdep class is sufficient to fix the lockdep warning.
The choice to use one lockdep subclass per pcie-hotplug controller in the path to the root-bus was made to conserve class keys because their number is limited and the complexity grows quadratically with number of keys according to Documentation/locking/lockdep-design.rst.
--- drivers/pci/hotplug/pciehp.h | 3 +++ drivers/pci/hotplug/pciehp_core.c | 2 +- drivers/pci/hotplug/pciehp_hpc.c | 21 ++++++++++++++++++--- 3 files changed, 22 insertions(+), 4 deletions(-)
drivers/pci/hotplug/pciehp.h +3 -0
@@ -72,6 +72,8 @@ extern int pciehp_poll_time;* @reset_lock: prevents access to the Data Link Layer Link Active bit in the * Link Status register and to the Presence Detect State bit in the Slot * Status register during a slot reset which may cause them to flap +* @depth: Number of additional hotplug ports in the path to the root bus, +* used as lock subclass for @reset_lock * @ist_running: flag to keep user request waiting while IRQ thread is running * @request_result: result of last user request submitted to the IRQ thread * @requester: wait queue to wake up on completion of user request,
@@ -103,6 +105,7 @@ struct controller {struct hotplug_slot hotplug_slot;/* hotplug core interface */ struct rw_semaphore reset_lock; +unsigned int depth;unsigned int ist_running;int request_result;wait_queue_head_t requester;
drivers/pci/hotplug/pciehp_core.c +1 -1
@@ -166,7 +166,7 @@ static void pciehp_check_presence(struct {int occupied; -down_read (&ctrl->reset_lock); +down_read_nested (&ctrl->reset_lock, ctrl->depth);mutex_lock (&ctrl->state_lock); occupied =pciehp_card_present_or_link_active (ctrl);
drivers/pci/hotplug/pciehp_hpc.c +18 -3
@@ -583,7 +583,7 @@ static void pciehp_ignore_dpc_link_chang* the corresponding link change may have been ignored above. * Synthesize it to ensure that it is acted on. */ -down_read (&ctrl->reset_lock); +down_read_nested (&ctrl->reset_lock, ctrl->depth);if (!pciehp_check_link_active (ctrl))pciehp_request (ctrl,PCI_EXP_SLTSTA_DLLSC );up_read (&ctrl->reset_lock);
@@ -746,7 +746,7 @@ static irqreturn_t pciehp_ist(int irq, v* Disable requests have higher priority than Presence Detect Changed * or Data Link Layer State Changed events. */ -down_read (&ctrl->reset_lock); +down_read_nested (&ctrl->reset_lock, ctrl->depth);if (events &DISABLE_SLOT )pciehp_handle_disable_request (ctrl);else if (events & (PCI_EXP_SLTSTA_PDC |PCI_EXP_SLTSTA_DLLSC ))
@@ -880,7 +880,7 @@ int pciehp_reset_slot(struct hotplug_sloif (probe)return 0 ; -down_write (&ctrl->reset_lock); +down_write_nested (&ctrl->reset_lock, ctrl->depth);if (!ATTN_BUTTN (ctrl)) { ctrl_mask |=PCI_EXP_SLTCTL_PDCE ;
@@ -936,6 +936,20 @@ static inline void dbg_ctrl(struct contr#define FLAG (x, y) (((x) & (y)) ? '+' : '-') +static inline int pcie_hotplug_depth (struct pci_dev *dev) +{ +struct pci_bus *bus = dev->bus; +int depth =0 ; + +while (bus->parent) { + bus = bus->parent; +if (bus->self && bus->self->is_hotplug_bridge) + depth++; + } + +return depth; +} +struct controller *pcie_init (struct pcie_device *dev) {struct controller *ctrl;
@@ -949,6 +963,7 @@ struct controller *pcie_init(struct pciereturn NULL ; ctrl->pcie = dev; + ctrl->depth =pcie_hotplug_depth (dev->port);pcie_capability_read_dword (pdev,PCI_EXP_SLTCAP , &slot_cap);if (pdev->hotplug_user_indicators)
Greg Kroah-Hartman
maintainerPATCH 462/563 PCI: pciehp: Fix infinite loop in IRQ handler upon power fault
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
commit 23584c1ed3e15a6f4bfab8dc5a88d94ab929ee12 upstream.
The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky: It can only be cleared after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8:
If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot.
The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots").
Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"): The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set. That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop. Fix by setting the power_fault_detected flag already in the hardirq handler.
--- drivers/pci/hotplug/pciehp_hpc.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/pci/hotplug/pciehp_hpc.c +4 -3
@@ -642,6 +642,8 @@ read_status:*/ if (ctrl->power_fault_detected) status &= ~PCI_EXP_SLTSTA_PFD ; +else if (status &PCI_EXP_SLTSTA_PFD ) + ctrl->power_fault_detected = true; events |= status;if (!events) {
@@ -651,7 +653,7 @@ read_status: }if (status) { -pcie_capability_write_word (pdev,PCI_EXP_SLTSTA , events); +pcie_capability_write_word (pdev,PCI_EXP_SLTSTA , status);/* * In MSI mode, all event bits must be zero before the port
@@ -725,8 +727,7 @@ static irqreturn_t pciehp_ist(int irq, v }/* Check Power Fault Detected */ -if ((events &PCI_EXP_SLTSTA_PFD ) && !ctrl->power_fault_detected) { - ctrl->power_fault_detected =1 ; +if (events &PCI_EXP_SLTSTA_PFD ) {ctrl_err (ctrl,"Slot(%s): Power fault\n" ,slot_name (ctrl));pciehp_set_indicators (ctrl,PCI_EXP_SLTCTL_PWR_IND_OFF ,PCI_EXP_SLTCTL_ATTN_IND_ON );
Greg Kroah-Hartman
maintainerPATCH 463/563 PCI: pci-bridge-emul: Make expansion ROM Base Address register read-only
In reply to Greg Kroah-HartmanFrom: Pali Rohár <[email protected]>
commit 1c1a3b4d3e86b997a313ffb297c1129540882859 upstream.
If expansion ROM is unsupported (which is the case of pci-bridge-emul.c driver) then ROM Base Address register must be implemented as read-only register that return 0 when read, same as for unused Base Address registers.
--- drivers/pci/pci-bridge-emul.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/pci/pci-bridge-emul.c +6 -1
@@ -139,8 +139,13 @@ struct pci_bridge_reg_behavior pci_regs_ .ro = GENMASK(7, 0), }, +/* +* If expansion ROM is unsupported then ROM Base Address register must +* be implemented as read-only register that return 0 when read, same +* as for unused Base Address registers. +*/ [PCI_ROM_ADDRESS1 / 4] = { - .rw = GENMASK(31, 11) | BIT(0), + .ro = ~0, },/*
Greg Kroah-Hartman
maintainerPATCH 464/563 PCI: pci-bridge-emul: Properly mark reserved PCIe bits in PCI config space
In reply to Greg Kroah-HartmanFrom: Pali Rohár <[email protected]>
commit 7b067ac63a5730d2fae18399fed7e45f23d36912 upstream.
Some bits in PCI config space are reserved when device is PCIe. Properly define behavior of PCI registers for PCIe emulated bridge and ensure that it would not be possible change these reserved bits.
--- drivers/pci/pci-bridge-emul.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
drivers/pci/pci-bridge-emul.c +21 -0
@@ -295,6 +295,27 @@ int pci_bridge_emul_init(struct pci_bridkfree (bridge->pci_regs_behavior);return -ENOMEM ; } +/* These bits are applicable only for PCI and reserved on PCIe */ + bridge->pci_regs_behavior[PCI_CACHE_LINE_SIZE /4 ].ro &= + ~GENMASK (15 ,8 ); + bridge->pci_regs_behavior[PCI_COMMAND /4 ].ro &= + ~((PCI_COMMAND_SPECIAL |PCI_COMMAND_INVALIDATE | +PCI_COMMAND_VGA_PALETTE |PCI_COMMAND_WAIT | +PCI_COMMAND_FAST_BACK ) | + (PCI_STATUS_66MHZ |PCI_STATUS_FAST_BACK | +PCI_STATUS_DEVSEL_MASK ) <<16 ); + bridge->pci_regs_behavior[PCI_PRIMARY_BUS /4 ].ro &= + ~GENMASK (31 ,24 ); + bridge->pci_regs_behavior[PCI_IO_BASE /4 ].ro &= + ~((PCI_STATUS_66MHZ |PCI_STATUS_FAST_BACK | +PCI_STATUS_DEVSEL_MASK ) <<16 ); + bridge->pci_regs_behavior[PCI_INTERRUPT_LINE /4 ].rw &= + ~((PCI_BRIDGE_CTL_MASTER_ABORT | +BIT (8 ) |BIT (9 ) |BIT (11 )) <<16 ); + bridge->pci_regs_behavior[PCI_INTERRUPT_LINE /4 ].ro &= + ~((PCI_BRIDGE_CTL_FAST_BACK ) <<16 ); + bridge->pci_regs_behavior[PCI_INTERRUPT_LINE /4 ].w1c &= + ~(BIT (10 ) <<16 ); }if (flags &PCI_BRIDGE_EMUL_NO_PREFETCHABLE_BAR ) {
Greg Kroah-Hartman
maintainerPATCH 465/563 PCI: pci-bridge-emul: Fix definitions of reserved bits
In reply to Greg Kroah-HartmanFrom: Pali Rohár <[email protected]>
commit 12998087d9f48b66965b97412069c7826502cd7e upstream.
Some bits in PCI_EXP registers are reserved for non-root ports. Driver pci-bridge-emul.c implements PCIe Root Port device therefore it should not allow setting reserved bits of registers.
Properly define non-reserved bits for all PCI_EXP registers.
--- drivers/pci/pci-bridge-emul.c | 36 +++++++++++++++++++++++++----------- 1 file changed, 25 insertions(+), 11 deletions(-)
drivers/pci/pci-bridge-emul.c +25 -11
@@ -176,41 +176,55 @@ struct pci_bridge_reg_behavior pcie_cap_ [PCI_CAP_LIST_ID / 4] = {/* * Capability ID, Next Capability Pointer and -* Capabilities register are all read-only. +* bits [14:0] of Capabilities register are all read-only. +* Bit 15 of Capabilities register is reserved. */ - .ro = ~0, + .ro = GENMASK(30, 0), }, [PCI_EXP_DEVCAP / 4] = { - .ro = ~0, +/* +* Bits [31:29] and [17:16] are reserved. +* Bits [27:18] are reserved for non-upstream ports. +* Bits 28 and [14:6] are reserved for non-endpoint devices. +* Other bits are read-only. +*/ + .ro = BIT(15) | GENMASK(5, 0), }, [PCI_EXP_DEVCTL / 4] = { -/* Device control register is RW */ - .rw = GENMASK(15, 0), +/* +* Device control register is RW, except bit 15 which is +* reserved for non-endpoints or non-PCIe-to-PCI/X bridges. +*/ + .rw = GENMASK(14, 0),/* * Device status register has bits 6 and [3:0] W1C, [5:4] RO, -* the rest is reserved +* the rest is reserved. Also bit 6 is reserved for non-upstream +* ports. */ - .w1c = (BIT(6) | GENMASK(3, 0)) << 16, + .w1c = GENMASK(3, 0) << 16, .ro = GENMASK(5, 4) << 16, }, [PCI_EXP_LNKCAP / 4] = { -/* All bits are RO, except bit 23 which is reserved */ - .ro = lower_32_bits(~BIT(23)), +/* +* All bits are RO, except bit 23 which is reserved and +* bit 18 which is reserved for non-upstream ports. +*/ + .ro = lower_32_bits(~(BIT(23) | PCI_EXP_LNKCAP_CLKPM)), }, [PCI_EXP_LNKCTL / 4] = {/* * Link control has bits [15:14], [11:3] and [1:0] RW, the -* rest is reserved. +* rest is reserved. Bit 8 is reserved for non-upstream ports. * * Link status has bits [13:0] RO, and bits [15:14] * W1C. */ - .rw = GENMASK(15, 14) | GENMASK(11, 3) | GENMASK(1, 0), + .rw = GENMASK(15, 14) | GENMASK(11, 9) | GENMASK(7, 3) | GENMASK(1, 0), .ro = GENMASK(13, 0) << 16, .w1c = GENMASK(15, 14) << 16, },
Greg Kroah-Hartman
maintainerPATCH 466/563 PCI: pci-bridge-emul: Correctly set PCIe capabilities
In reply to Greg Kroah-HartmanFrom: Pali Rohár <[email protected]>
commit 1f1050c5e1fefb34ac90a506b43e9da803b5f8f7 upstream.
Older mvebu hardware provides PCIe Capability structure only in version 1. New mvebu and aardvark hardware provides it in version 2. So do not force version to 2 in pci_bridge_emul_init() and rather allow drivers to set correct version. Drivers need to set version in pcie_conf.cap field without overwriting PCI_CAP_LIST_ID register. Both drivers (mvebu and aardvark) do not provide slot support yet, so do not set PCI_EXP_FLAGS_SLOT flag.
--- drivers/pci/controller/pci-aardvark.c | 4 +++- drivers/pci/controller/pci-mvebu.c | 8 ++++++++ drivers/pci/pci-bridge-emul.c | 5 +---- 3 files changed, 12 insertions(+), 5 deletions(-)
drivers/pci/controller/pci-aardvark.c +3 -1
@@ -879,7 +879,6 @@ advk_pci_bridge_emul_pcie_conf_read(strureturn PCI_BRIDGE_EMUL_HANDLED ; } -case PCI_CAP_LIST_ID :case PCI_EXP_DEVCAP :case PCI_EXP_DEVCTL : *value =advk_readl (pcie,PCIE_CORE_PCIEXP_CAP + reg);
@@ -960,6 +959,9 @@ static int advk_sw_pci_bridge_init(struc/* Support interrupt A for MSI feature */ bridge->conf.intpin =PCIE_CORE_INT_A_ASSERT_ENABLE ; +/* Aardvark HW provides PCIe Capability structure in version 2 */ + bridge->pcie_conf.cap =cpu_to_le16 (2 ); +/* Indicates supports for Completion Retry Status */ bridge->pcie_conf.rootcap =cpu_to_le16 (PCI_EXP_RTCAP_CRSVIS );
drivers/pci/controller/pci-mvebu.c +8 -0
@@ -573,6 +573,8 @@ static struct pci_bridge_emul_ops mvebu_static void mvebu_pci_bridge_emul_init (struct mvebu_pcie_port *port) {struct pci_bridge_emul *bridge = &port->bridge; +u32 pcie_cap =mvebu_readl (port,PCIE_CAP_PCIEXP ); +u8 pcie_cap_ver = ((pcie_cap >>16 ) &PCI_EXP_FLAGS_VERS ); bridge->conf.vendor =PCI_VENDOR_ID_MARVELL ; bridge->conf.device =mvebu_readl (port,PCIE_DEV_ID_OFF ) >>16 ;
@@ -585,6 +587,12 @@ static void mvebu_pci_bridge_emul_init(s bridge->conf.iolimit =PCI_IO_RANGE_TYPE_32 ; } +/* +* Older mvebu hardware provides PCIe Capability structure only in +* version 1. New hardware provides it in version 2. +*/ + bridge->pcie_conf.cap =cpu_to_le16 (pcie_cap_ver); + bridge->has_pcie = true; bridge->data = port; bridge->ops = &mvebu_pci_bridge_emul_ops;
drivers/pci/pci-bridge-emul.c +1 -4
@@ -297,10 +297,7 @@ int pci_bridge_emul_init(struct pci_bridif (bridge->has_pcie) { bridge->conf.capabilities_pointer =PCI_CAP_PCIE_START ; bridge->pcie_conf.cap_id =PCI_CAP_ID_EXP ; -/* Set PCIe v2, root port, slot support */ - bridge->pcie_conf.cap = -cpu_to_le16 (PCI_EXP_TYPE_ROOT_PORT <<4 |2 | -PCI_EXP_FLAGS_SLOT ); + bridge->pcie_conf.cap |=cpu_to_le16 (PCI_EXP_TYPE_ROOT_PORT <<4 ); bridge->pcie_cap_regs_behavior = kmemdup(pcie_cap_regs_behavior, sizeof(pcie_cap_regs_behavior),
Greg Kroah-Hartman
maintainerPATCH 467/563 PCI: pci-bridge-emul: Set PCI_STATUS_CAP_LIST for PCIe device
In reply to Greg Kroah-HartmanFrom: Pali Rohár <[email protected]>
commit 3be9d243b21724d49b65043d4520d688b6040b36 upstream.
Since all PCI Express device Functions are required to implement the PCI Express Capability structure, Capabilities List bit in PCI Status Register must be hardwired to 1b. Capabilities Pointer register (which is already set by pci-bride-emul.c driver) is valid only when Capabilities List is set to 1b.
--- drivers/pci/pci-bridge-emul.c | 1 + 1 file changed, 1 insertion(+)
drivers/pci/pci-bridge-emul.c +1 -0
@@ -296,6 +296,7 @@ int pci_bridge_emul_init(struct pci_bridif (bridge->has_pcie) { bridge->conf.capabilities_pointer =PCI_CAP_PCIE_START ; + bridge->conf.status |=cpu_to_le16 (PCI_STATUS_CAP_LIST ); bridge->pcie_conf.cap_id =PCI_CAP_ID_EXP ; bridge->pcie_conf.cap |=cpu_to_le16 (PCI_EXP_TYPE_ROOT_PORT <<4 ); bridge->pcie_cap_regs_behavior =
Greg Kroah-Hartman
maintainerPATCH 468/563 xfrm: fix policy lookup for ipv6 gre packets
In reply to Greg Kroah-HartmanFrom: Ghalem Boudour <[email protected]>
commit bcf141b2eb551b3477b24997ebc09c65f117a803 upstream.
On egress side, xfrm lookup is called from __gre6_xmit() with the fl6_gre_key field not initialized leading to policies selectors check failure. Consequently, gre packets are sent without encryption.
On ingress side, INET6_PROTO_NOPOLICY was set, thus packets were not checked against xfrm policies. Like for egress side, fl6_gre_key should be correctly set, this is now done in decode_session6().
--- net/ipv6/ip6_gre.c | 5 ++++- net/xfrm/xfrm_policy.c | 21 +++++++++++++++++++++ 2 files changed, 25 insertions(+), 1 deletion(-)
net/ipv6/ip6_gre.c +4 -1
@@ -755,6 +755,7 @@ static netdev_tx_t __gre6_xmit(struct sk fl6->daddr = key->u.ipv6.dst; fl6->flowlabel = key->label; fl6->flowi6_uid =sock_net_uid (dev_net (dev),NULL ); + fl6->fl6_gre_key =tunnel_id_to_key32 (key->tun_id); dsfield = key->tos; flags = key->tun_flags &
@@ -990,6 +991,7 @@ static netdev_tx_t ip6erspan_tunnel_xmit fl6.daddr = key->u.ipv6.dst; fl6.flowlabel = key->label; fl6.flowi6_uid =sock_net_uid (dev_net (dev),NULL ); + fl6.fl6_gre_key =tunnel_id_to_key32 (key->tun_id); dsfield = key->tos;if (!(tun_info->key.tun_flags &TUNNEL_ERSPAN_OPT ))
@@ -1098,6 +1100,7 @@ static void ip6gre_tnl_link_config_commo fl6->flowi6_oif = p->link; fl6->flowlabel =0 ; fl6->flowi6_proto =IPPROTO_GRE ; + fl6->fl6_gre_key = t->parms.o_key;if (!(p->flags&IP6_TNL_F_USE_ORIG_TCLASS )) fl6->flowlabel |=IPV6_TCLASS_MASK & p->flowinfo;
@@ -1543,7 +1546,7 @@ static void ip6gre_fb_tunnel_init(structstatic struct inet6_protocol ip6gre_protocol__read_mostly = { .handler = gre_rcv, .err_handler = ip6gre_err, - .flags =INET6_PROTO_NOPOLICY |INET6_PROTO_FINAL , + .flags =INET6_PROTO_FINAL , };static void ip6gre_destroy_tunnels (struct net *net,struct list_head *head)
net/xfrm/xfrm_policy.c +21 -0
@@ -33,6 +33,7 @@#include <net/flow.h> #include <net/xfrm.h> #include <net/ip.h> +#include <net/gre.h> #if IS_ENABLED (CONFIG_IPV6_MIP6 )#include <net/mip6.h> #endif
@@ -3455,6 +3456,26 @@ decode_session6(struct sk_buff *skb, str } fl6->flowi6_proto = nexthdr;return ; +case IPPROTO_GRE : +if (!onlyproto && + (nh + offset +12 < skb->data || +pskb_may_pull (skb, nh + offset +12 - skb->data))) { +struct gre_base_hdr *gre_hdr; +__be32 *gre_key; + + nh =skb_network_header (skb); + gre_hdr = (struct gre_base_hdr *)(nh + offset); + gre_key = (__be32 *)(gre_hdr +1 ); + +if (gre_hdr->flags &GRE_KEY ) { +if (gre_hdr->flags &GRE_CSUM ) + gre_key++; + fl6->fl6_gre_key = *gre_key; + } + } + fl6->flowi6_proto = nexthdr; +return ; +#if IS_ENABLED (CONFIG_IPV6_MIP6 )case IPPROTO_MH : offset +=ipv6_optlen (exthdr);
Greg Kroah-Hartman
maintainerPATCH 469/563 btrfs: fix deadlock between quota enable and other quota operations
In reply to Greg Kroah-HartmanFrom: Filipe Manana <[email protected]>
commit 232796df8c1437c41d308d161007f0715bac0a54 upstream.
When enabling quotas, we attempt to commit a transaction while holding the mutex fs_info->qgroup_ioctl_lock. This can result on a deadlock with other quota operations such as:
- qgroup creation and deletion, ioctl BTRFS_IOC_QGROUP_CREATE;
- adding and removing qgroup relations, ioctl BTRFS_IOC_QGROUP_ASSIGN.
This is because these operations join a transaction and after that they attempt to lock the mutex fs_info->qgroup_ioctl_lock. Acquiring that mutex after joining or starting a transaction is a pattern followed everywhere in qgroups, so the quota enablement operation is the one at fault here, and should not commit a transaction while holding that mutex.
Fix this by making the transaction commit while not holding the mutex. We are safe from two concurrent tasks trying to enable quotas because we are serialized by the rw semaphore fs_info->subvol_sem at btrfs_ioctl_quota_ctl(), which is the only call site for enabling quotas.
When this deadlock happens, it produces a trace like the following:
INFO: task syz-executor:25604 blocked for more than 143 seconds. Not tainted 5.15.0-rc6 #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor state:D stack:24800 pid:25604 ppid: 24873 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:4940 [inline] __schedule+0xcd9/0x2530 kernel/sched/core.c:6287 schedule+0xd3/0x270 kernel/sched/core.c:6366 btrfs_commit_transaction+0x994/0x2e90 fs/btrfs/transaction.c:2201 btrfs_quota_enable+0x95c/0x1790 fs/btrfs/qgroup.c:1120 btrfs_ioctl_quota_ctl fs/btrfs/ioctl.c:4229 [inline] btrfs_ioctl+0x637e/0x7b70 fs/btrfs/ioctl.c:5010 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f86920b2c4d RSP: 002b:00007f868f61ac58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f86921d90a0 RCX: 00007f86920b2c4d RDX: 0000000020005e40 RSI: 00000000c0109428 RDI: 0000000000000008 RBP: 00007f869212bd80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f86921d90a0 R13: 00007fff6d233e4f R14: 00007fff6d233ff0 R15: 00007f868f61adc0 INFO: task syz-executor:25628 blocked for more than 143 seconds. Not tainted 5.15.0-rc6 #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor state:D stack:29080 pid:25628 ppid: 24873 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:4940 [inline] __schedule+0xcd9/0x2530 kernel/sched/core.c:6287 schedule+0xd3/0x270 kernel/sched/core.c:6366 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:6425 __mutex_lock_common kernel/locking/mutex.c:669 [inline] __mutex_lock+0xc96/0x1680 kernel/locking/mutex.c:729 btrfs_remove_qgroup+0xb7/0x7d0 fs/btrfs/qgroup.c:1548 btrfs_ioctl_qgroup_create fs/btrfs/ioctl.c:4333 [inline] btrfs_ioctl+0x683c/0x7b70 fs/btrfs/ioctl.c:5014 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
--- fs/btrfs/qgroup.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
fs/btrfs/qgroup.c +19 -0
@@ -941,6 +941,14 @@ int btrfs_quota_enable(struct btrfs_fs_iint ret =0 ;int slot; +/* +* We need to have subvol_sem write locked, to prevent races between +* concurrent tasks trying to enable quotas, because we will unlock +* and relock qgroup_ioctl_lock before setting fs_info->quota_root +* and before setting BTRFS_FS_QUOTA_ENABLED. +*/ +lockdep_assert_held_write (&fs_info->subvol_sem); +mutex_lock (&fs_info->qgroup_ioctl_lock);if (fs_info->quota_root) goto out;
@@ -1118,8 +1126,19 @@ out_add_root: goto out_free_path; } +mutex_unlock (&fs_info->qgroup_ioctl_lock); +/* +* Commit the transaction while not holding qgroup_ioctl_lock, to avoid +* a deadlock with tasks concurrently doing other qgroup operations, such +* adding/removing qgroups or adding/deleting qgroup relations for example, +* because all qgroup operations first start or join a transaction and then +* lock the qgroup_ioctl_lock mutex. +* We are safe from a concurrent task trying to enable quotas, by calling +* this function, since we are serialized by fs_info->subvol_sem. +*/ ret =btrfs_commit_transaction (trans); trans =NULL ; +mutex_lock (&fs_info->qgroup_ioctl_lock);if (ret) goto out_free_path;
Greg Kroah-Hartman
maintainerPATCH 470/563 btrfs: check the root node for uptodate before returning it
In reply to Greg Kroah-HartmanFrom: Josef Bacik <[email protected]>
commit 120de408e4b97504a2d9b5ca534b383de2c73d49 upstream.
Now that we clear the extent buffer uptodate if we fail to write it out we need to check to see if our root node is uptodate before we search down it. Otherwise we could return stale data (or potentially corrupt data that was caught by the write verification step) and think that the path is OK to search down.
--- fs/btrfs/ctree.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-)
fs/btrfs/ctree.c +15 -4
@@ -2589,12 +2589,9 @@ static struct extent_buffer *btrfs_searc {struct btrfs_fs_info *fs_info = root->fs_info;struct extent_buffer *b; -int root_lock; +int root_lock =0 ;int level =0 ; -/* We try very hard to do read locks on the root */ - root_lock =BTRFS_READ_LOCK ; -if (p->search_commit_root) {/* * The commit roots are read only so we always do read locks,
@@ -2632,6 +2629,9 @@ static struct extent_buffer *btrfs_searc goto out; } +/* We try very hard to do read locks on the root */ + root_lock =BTRFS_READ_LOCK ; +/* * If the level is set to maximum, we can skip trying to get the read * lock.
@@ -2658,6 +2658,17 @@ static struct extent_buffer *btrfs_searc level =btrfs_header_level (b); out: +/* +* The root may have failed to write out at some point, and thus is no +* longer valid, return an error in this case. +*/ +if (!extent_buffer_uptodate (b)) { +if (root_lock) +btrfs_tree_unlock_rw (b, root_lock); +free_extent_buffer (b); +return ERR_PTR (-EIO ); + } + p->nodes[level] = b;if (!p->skip_locking) p->locks[level] = root_lock;
Greg Kroah-Hartman
maintainerPATCH 471/563 btrfs: respect the max size in the header when activating swap file
In reply to Greg Kroah-HartmanFrom: Filipe Manana <[email protected]>
commit c2f822635df873c510bda6fb7fd1b10b7c31be2d upstream.
If we extended the size of a swapfile after its header was created (by the mkswap utility) and then try to activate it, we will map the entire file when activating the swap file, instead of limiting to the max size defined in the swap file's header.
Currently test case generic/643 from fstests fails because we do not respect that size limit defined in the swap file's header.
So fix this by not mapping file ranges beyond the max size defined in the swap header.
This is the same type of bug that iomap used to have, and was fixed in commit 36ca7943ac18ae ("mm/swap: consider max pages in iomap_swapfile_add_extent").
--- fs/btrfs/inode.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
fs/btrfs/inode.c +11 -0
@@ -10094,9 +10094,19 @@ static int btrfs_add_swap_extent(struct struct btrfs_swap_info *bsi) {unsigned long nr_pages; +unsigned long max_pages;u64 first_ppage, first_ppage_reported, next_ppage;int ret; +/* +* Our swapfile may have had its size extended after the swap header was +* written. In that case activating the swapfile should not go beyond +* the max size set in the swap header. +*/ +if (bsi->nr_pages >= sis->max) +return 0 ; + + max_pages = sis->max - bsi->nr_pages; first_ppage =ALIGN (bsi->block_start,PAGE_SIZE ) >>PAGE_SHIFT ; next_ppage =ALIGN_DOWN (bsi->block_start + bsi->block_len,PAGE_SIZE ) >>PAGE_SHIFT ;
@@ -10104,6 +10114,7 @@ static int btrfs_add_swap_extent(structif (first_ppage >= next_ppage)return 0 ; nr_pages = next_ppage - first_ppage; + nr_pages =min (nr_pages, max_pages); first_ppage_reported = first_ppage;if (bsi->start ==0 )
Greg Kroah-Hartman
maintainerPATCH 472/563 ext4: make sure to reset inode lockdep class when quota enabling fails
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit 4013d47a5307fdb5c13370b5392498b00fedd274 upstream.
When we succeed in enabling some quota type but fail to enable another one with quota feature, we correctly disable all enabled quota types. However we forget to reset i_data_sem lockdep class. When the inode gets freed and reused, it will inherit this lockdep class (i_data_sem is initialized only when a slab is created) and thus eventually lockdep barfs about possible deadlocks.
--- fs/ext4/super.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
fs/ext4/super.c +12 -1
@@ -6427,8 +6427,19 @@ static int ext4_enable_quotas(struct sup"Failed to enable quota tracking " "(type=%d, err=%d). Please run " "e2fsck to fix.", type, err); -for (type--; type >=0 ; type--) +for (type--; type >=0 ; type--) { +struct inode *inode; + + inode =sb_dqopt (sb)->files[type]; +if (inode) + inode =igrab (inode);dquot_quota_off (sb, type); +if (inode) { +lockdep_set_quota_inode (inode, +I_DATA_SEM_NORMAL ); +iput (inode); + } + }return err; }
Greg Kroah-Hartman
maintainerPATCH 473/563 ext4: make sure quota gets properly shutdown on error
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
commit 15fc69bbbbbc8c72e5f6cc4e1be0f51283c5448e upstream.
When we hit an error when enabling quotas and setting inode flags, we do not properly shutdown quota subsystem despite returning error from Q_QUOTAON quotactl. This can lead to some odd situations like kernel using quota file while it is still writeable for userspace. Make sure we properly cleanup the quota subsystem in case of error.
--- fs/ext4/super.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
fs/ext4/super.c +6 -4
@@ -6341,10 +6341,7 @@ static int ext4_quota_on(struct super_bllockdep_set_quota_inode (path->dentry->d_inode,I_DATA_SEM_QUOTA ); err =dquot_quota_on (sb, type, format_id, path); -if (err) { -lockdep_set_quota_inode (path->dentry->d_inode, -I_DATA_SEM_NORMAL ); - }else { +if (!err) {struct inode *inode =d_inode (path->dentry);handle_t *handle;
@@ -6364,7 +6361,12 @@ static int ext4_quota_on(struct super_blext4_journal_stop (handle); unlock_inode:inode_unlock (inode); +if (err) +dquot_quota_off (sb, type); } +if (err) +lockdep_set_quota_inode (path->dentry->d_inode, +I_DATA_SEM_NORMAL );return err; }
Greg Kroah-Hartman
maintainerPATCH 474/563 ext4: fix a possible ABBA deadlock due to busy PA
In reply to Greg Kroah-HartmanFrom: Chunguang Xu <[email protected]>
commit 8c80fb312d7abf8bcd66cca1d843a80318a2c522 upstream.
We found on older kernel (3.10) that in the scenario of insufficient disk space, system may trigger an ABBA deadlock problem, it seems that this problem still exists in latest kernel, try to fix it here. The main process triggered by this problem is that task A occupies the PA and waits for the jbd2 transaction finish, the jbd2 transaction waits for the completion of task B's IO (plug_list), but task B waits for the release of PA by task A to finish discard, which indirectly forms an ABBA deadlock. The related calltrace is as follows:
Task A
vfs_write
ext4_mb_new_blocks()
ext4_mb_mark_diskspace_used() JBD2
jbd2_journal_get_write_access() -> jbd2_journal_commit_transaction()
->schedule() filemap_fdatawait()
| |
| Task B |
| do_unlinkat() |
| ext4_evict_inode() |
| jbd2_journal_begin_ordered_truncate() |
| filemap_fdatawrite_range() |
| ext4_mb_new_blocks() |-ext4_mb_discard_group_preallocations() <-----
Here, try to cancel ext4_mb_discard_group_preallocations() internal retry due to PA busy, and do a limited number of retries inside ext4_mb_discard_preallocations(), which can circumvent the above problems, but also has some advantages:
1. Since the PA is in a busy state, if other groups have free PAs, keeping the current PA may help to reduce fragmentation.
2. Continue to traverse forward instead of waiting for the current group PA to be released. In most scenarios, the PA discard time can be reduced.
However, in the case of smaller free space, if only a few groups have space, then due to multiple traversals of the group, it may increase CPU overhead. But in contrast, I feel that the overall benefit is better than the cost.
--- fs/ext4/mballoc.c | 40 ++++++++++++++++++---------------------- 1 file changed, 18 insertions(+), 22 deletions(-)
fs/ext4/mballoc.c +18 -22
@@ -4234,7 +4234,7 @@ ext4_mb_release_group_pa(struct ext4_bud*/ static noinline_for_stack intext4_mb_discard_group_preallocations (struct super_block *sb, -ext4_group_t group,int needed) +ext4_group_t group,int *busy) {struct ext4_group_info *grp =ext4_get_group_info (sb, group);struct buffer_head *bitmap_bh =NULL ;
@@ -4242,8 +4242,7 @@ ext4_mb_discard_group_preallocations(strstruct list_head list;struct ext4_buddy e4b;int err; -int busy =0 ; -int free, free_total =0 ; +int free =0 ;mb_debug (sb,"discard preallocation for group %u\n" , group);if (list_empty (&grp->bb_prealloc_list))
@@ -4266,19 +4265,14 @@ ext4_mb_discard_group_preallocations(str goto out_dbg; } -if (needed ==0 ) - needed =EXT4_CLUSTERS_PER_GROUP (sb) +1 ; -INIT_LIST_HEAD (&list); -repeat: - free =0 ;ext4_lock_group (sb, group);list_for_each_entry_safe (pa, tmp, &grp->bb_prealloc_list, pa_group_list) {spin_lock (&pa->pa_lock);if (atomic_read (&pa->pa_count)) {spin_unlock (&pa->pa_lock); - busy =1 ; + *busy =1 ;continue ; }if (pa->pa_deleted) {
@@ -4318,22 +4312,13 @@ repeat:call_rcu (&(pa)->u.pa_rcu, ext4_mb_pa_callback); } - free_total += free; - -/* if we still need more blocks and some PAs were used, try again */ -if (free_total < needed && busy) { -ext4_unlock_group (sb, group); -cond_resched (); - busy =0 ; - goto repeat; - }ext4_unlock_group (sb, group);ext4_mb_unload_buddy (&e4b);put_bh (bitmap_bh); out_dbg:mb_debug (sb,"discarded (%d) blocks preallocated for group %u bb_free (%d)\n" , - free_total, group, grp->bb_free); -return free_total; + free, group, grp->bb_free); +return free; }/*
@@ -4875,13 +4860,24 @@ static int ext4_mb_discard_preallocation {ext4_group_t i, ngroups =ext4_get_groups_count (sb);int ret; -int freed =0 ; +int freed =0 , busy =0 ; +int retry =0 ;trace_ext4_mb_discard_preallocations (sb, needed); + +if (needed ==0 ) + needed =EXT4_CLUSTERS_PER_GROUP (sb) +1 ; + repeat:for (i =0 ; i < ngroups && needed >0 ; i++) { - ret =ext4_mb_discard_group_preallocations (sb, i, needed); + ret =ext4_mb_discard_group_preallocations (sb, i, &busy); freed += ret; needed -= ret; +cond_resched (); + } + +if (needed >0 && busy && ++retry <3 ) { + busy =0 ; + goto repeat; }return freed;
Greg Kroah-Hartman
maintainerPATCH 475/563 ext4: initialize err_blk before calling __ext4_get_inode_loc
In reply to Greg Kroah-HartmanFrom: Harshad Shirwadkar <[email protected]>
commit c27c29c6af4f3f4ce925a2111c256733c5a5b430 upstream.
It is not guaranteed that __ext4_get_inode_loc will definitely set err_blk pointer when it returns EIO. To avoid using uninitialized variables, let's first set err_blk to 0.
--- fs/ext4/inode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/ext4/inode.c +2 -2
@@ -4445,7 +4445,7 @@ has_buffer:static int __ext4_get_inode_loc_noinmem (struct inode *inode,struct ext4_iloc *iloc) { -ext4_fsblk_t err_blk; +ext4_fsblk_t err_blk =0 ;int ret; ret = __ext4_get_inode_loc(inode->i_sb, inode->i_ino, iloc, 0,
@@ -4460,7 +4460,7 @@ static int __ext4_get_inode_loc_noinmem(int ext4_get_inode_loc (struct inode *inode,struct ext4_iloc *iloc) { -ext4_fsblk_t err_blk; +ext4_fsblk_t err_blk =0 ;int ret;/* We have all inode data except xattrs in memory here. */
Greg Kroah-Hartman
maintainerPATCH 476/563 ext4: fix fast commit may miss tracking range for FALLOC_FL_ZERO_RANGE
In reply to Greg Kroah-HartmanFrom: Xin Yin <[email protected]>
commit 5e4d0eba1ccaf19f93222abdeda5a368be141785 upstream.
when call falloc with FALLOC_FL_ZERO_RANGE, to set an range to unwritten, which has been already initialized. If the range is align to blocksize, fast commit will not track range for this change.
Also track range for unwritten range in ext4_map_blocks().
--- fs/ext4/extents.c | 2 -- fs/ext4/inode.c | 7 ++++--- 2 files changed, 4 insertions(+), 5 deletions(-)
fs/ext4/extents.c +0 -2
@@ -4638,8 +4638,6 @@ static long ext4_zero_range(struct file ret =ext4_mark_inode_dirty (handle, inode);if (unlikely (ret)) goto out_handle; -ext4_fc_track_range (handle, inode, offset >> inode->i_sb->s_blocksize_bits, - (offset + len -1 ) >> inode->i_sb->s_blocksize_bits);/* Zero out partial block at the edges of the range */ ret =ext4_zero_partial_blocks (handle, inode, offset, len);if (ret >=0 )
fs/ext4/inode.c +4 -3
@@ -741,10 +741,11 @@ out_sem:if (ret)return ret; } -ext4_fc_track_range (handle, inode, map->m_lblk, - map->m_lblk + map->m_len -1 ); } - +if (retval >0 && (map->m_flags &EXT4_MAP_UNWRITTEN || + map->m_flags &EXT4_MAP_MAPPED )) +ext4_fc_track_range (handle, inode, map->m_lblk, + map->m_lblk + map->m_len -1 );if (retval <0 )ext_debug (inode,"failed with err %d\n" , retval);return retval;
Greg Kroah-Hartman
maintainerPATCH 477/563 ext4: set csum seed in tmp inode while migrating to extents
In reply to Greg Kroah-HartmanFrom: Luís Henriques <[email protected]>
commit e81c9302a6c3c008f5c30beb73b38adb0170ff2d upstream.
When migrating to extents, the temporary inode will have it's own checksum seed. This means that, when swapping the inodes data, the inode checksums will be incorrect.
This can be fixed by recalculating the extents checksums again. Or simply by copying the seed into the temporary inode.
--- fs/ext4/migrate.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
fs/ext4/migrate.c +11 -1
@@ -459,6 +459,17 @@ int ext4_ext_migrate(struct inode *inodeext4_journal_stop (handle); goto out_unlock; } +/* +* Use the correct seed for checksum (i.e. the seed from 'inode'). This +* is so that the metadata blocks will have the correct checksum after +* the migration. +* +* Note however that, if a crash occurs during the migration process, +* the recovery process is broken because the tmp_inode checksums will +* be wrong and the orphans cleanup will fail. +*/ + ei =EXT4_I (inode); +EXT4_I (tmp_inode)->i_csum_seed = ei->i_csum_seed;i_size_write (tmp_inode,i_size_read (inode));/* * Set the i_nlink to zero so it will be deleted later
@@ -502,7 +513,6 @@ int ext4_ext_migrate(struct inode *inode goto out_tmp_inode; } - ei =EXT4_I (inode); i_data = ei->i_data;memset (&lb,0 ,sizeof (lb));
Greg Kroah-Hartman
maintainerPATCH 478/563 ext4: Fix BUG_ON in ext4_bread when write quota data
In reply to Greg Kroah-HartmanFrom: Ye Bin <[email protected]>
commit 380a0091cab482489e9b19e07f2a166ad2b76d5c upstream.
We got issue as follows when run syzkaller:
[ 167.936972] EXT4-fs error (device loop0): __ext4_remount:6314: comm rep: Abort forced by user [ 167.938306] EXT4-fs (loop0): Remounting filesystem read-only [ 167.981637] Assertion failure in ext4_getblk() at fs/ext4/inode.c:847: '(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_FC_REPLAY) || handle != NULL || create == 0' [ 167.983601] ------------[ cut here ]------------ [ 167.984245] kernel BUG at fs/ext4/inode.c:847! [ 167.984882] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI [ 167.985624] CPU: 7 PID: 2290 Comm: rep Tainted: G B 5.16.0-rc5-next-20211217+ #123 [ 167.986823] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 167.988590] RIP: 0010:ext4_getblk+0x17e/0x504 [ 167.989189] Code: c6 01 74 28 49 c7 c0 a0 a3 5c 9b b9 4f 03 00 00 48 c7 c2 80 9c 5c 9b 48 c7 c6 40 b6 5c 9b 48 c7 c7 20 a4 5c 9b e8 77 e3 fd ff <0f> 0b 8b 04 244 [ 167.991679] RSP: 0018:ffff8881736f7398 EFLAGS: 00010282 [ 167.992385] RAX: 0000000000000094 RBX: 1ffff1102e6dee75 RCX: 0000000000000000 [ 167.993337] RDX: 0000000000000001 RSI: ffffffff9b6e29e0 RDI: ffffed102e6dee66 [ 167.994292] RBP: ffff88816a076210 R08: 0000000000000094 R09: ffffed107363fa09 [ 167.995252] R10: ffff88839b1fd047 R11: ffffed107363fa08 R12: ffff88816a0761e8 [ 167.996205] R13: 0000000000000000 R14: 0000000000000021 R15: 0000000000000001 [ 167.997158] FS: 00007f6a1428c740(0000) GS:ffff88839b000000(0000) knlGS:0000000000000000 [ 167.998238] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 167.999025] CR2: 00007f6a140716c8 CR3: 0000000133216000 CR4: 00000000000006e0 [ 167.999987] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 168.000944] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 168.001899] Call Trace: [ 168.002235] <TASK> [ 168.007167] ext4_bread+0xd/0x53 [ 168.007612] ext4_quota_write+0x20c/0x5c0 [ 168.010457] write_blk+0x100/0x220 [ 168.010944] remove_free_dqentry+0x1c6/0x440 [ 168.011525] free_dqentry.isra.0+0x565/0x830 [ 168.012133] remove_tree+0x318/0x6d0 [ 168.014744] remove_tree+0x1eb/0x6d0 [ 168.017346] remove_tree+0x1eb/0x6d0 [ 168.019969] remove_tree+0x1eb/0x6d0 [ 168.022128] qtree_release_dquot+0x291/0x340 [ 168.023297] v2_release_dquot+0xce/0x120 [ 168.023847] dquot_release+0x197/0x3e0 [ 168.024358] ext4_release_dquot+0x22a/0x2d0 [ 168.024932] dqput.part.0+0x1c9/0x900 [ 168.025430] __dquot_drop+0x120/0x190 [ 168.025942] ext4_clear_inode+0x86/0x220 [ 168.026472] ext4_evict_inode+0x9e8/0xa22 [ 168.028200] evict+0x29e/0x4f0 [ 168.028625] dispose_list+0x102/0x1f0 [ 168.029148] evict_inodes+0x2c1/0x3e0 [ 168.030188] generic_shutdown_super+0xa4/0x3b0 [ 168.030817] kill_block_super+0x95/0xd0 [ 168.031360] deactivate_locked_super+0x85/0xd0 [ 168.031977] cleanup_mnt+0x2bc/0x480 [ 168.033062] task_work_run+0xd1/0x170 [ 168.033565] do_exit+0xa4f/0x2b50 [ 168.037155] do_group_exit+0xef/0x2d0 [ 168.037666] __x64_sys_exit_group+0x3a/0x50 [ 168.038237] do_syscall_64+0x3b/0x90 [ 168.038751] entry_SYSCALL_64_after_hwframe+0x44/0xae
In order to reproduce this problem, the following conditions need to be met:
1. Ext4 filesystem with no journal;
2. Filesystem image with incorrect quota data;
3. Abort filesystem forced by user;
4. umount filesystem;
As in ext4_quota_write:
...
if (EXT4_SB(sb)->s_journal && !handle) {
ext4_msg(sb, KERN_WARNING, "Quota write (off=%llu, len=%llu)"
" cancelled because transaction is not started",
(unsigned long long)off, (unsigned long long)len);
return -EIO;
}...
We only check handle if NULL when filesystem has journal. There is need check handle if NULL even when filesystem has no journal.
--- fs/ext4/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext4/super.c +1 -1
@@ -6545,7 +6545,7 @@ static ssize_t ext4_quota_write(struct sstruct buffer_head *bh;handle_t *handle =journal_current_handle (); -if (EXT4_SB (sb)->s_journal && !handle) { +if (!handle) {ext4_msg (sb,KERN_WARNING ,"Quota write (off=%llu, len=%llu)" " cancelled because transaction is not started" , (unsigned long long )off, (unsigned long long )len);
Greg Kroah-Hartman
maintainerPATCH 479/563 ext4: use ext4_ext_remove_space() for fast commit replay delete range
In reply to Greg Kroah-HartmanFrom: Xin Yin <[email protected]>
commit 0b5b5a62b945a141e64011b2f90ee7e46f14be98 upstream.
For now ,we use ext4_punch_hole() during fast commit replay delete range procedure. But it will be affected by inode->i_size, which may not correct during fast commit replay procedure. The following test will failed.
-create & write foo (len 1000K)
-falloc FALLOC_FL_ZERO_RANGE foo (range 400K - 600K) -create & fsync bar
-falloc FALLOC_FL_PUNCH_HOLE foo (range 300K-500K) -fsync foo
-crash before a full commit
After the fast_commit reply procedure, the range 400K-500K will not be removed. Because in this case, when calling ext4_punch_hole() the inode->i_size is 0, and it just retruns with doing nothing.
Change to use ext4_ext_remove_space() instead of ext4_punch_hole() to remove blocks of inode directly.
--- fs/ext4/fast_commit.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
fs/ext4/fast_commit.c +8 -5
@@ -1764,11 +1764,14 @@ ext4_fc_replay_del_range(struct super_bl } } - ret =ext4_punch_hole (inode, -le32_to_cpu (lrange.fc_lblk) << sb->s_blocksize_bits, -le32_to_cpu (lrange.fc_len) << sb->s_blocksize_bits); -if (ret) -jbd_debug (1 ,"ext4_punch_hole returned %d" , ret); +down_write (&EXT4_I (inode)->i_data_sem); + ret =ext4_ext_remove_space (inode, lrange.fc_lblk, + lrange.fc_lblk + lrange.fc_len -1 ); +up_write (&EXT4_I (inode)->i_data_sem); +if (ret) { +iput (inode); +return 0 ; + }ext4_ext_replay_shrink_inode (inode,i_size_read (inode) >> sb->s_blocksize_bits);ext4_mark_inode_dirty (NULL , inode);
Greg Kroah-Hartman
maintainerPATCH 480/563 ext4: fast commit may miss tracking unwritten range during ftruncate
In reply to Greg Kroah-HartmanFrom: Xin Yin <[email protected]>
commit 9725958bb75cdfa10f2ec11526fdb23e7485e8e4 upstream.
If use FALLOC_FL_KEEP_SIZE to alloc unwritten range at bottom, the inode->i_size will not include the unwritten range. When call ftruncate with fast commit enabled, it will miss to track the unwritten range.
Change to trace the full range during ftruncate.
--- fs/ext4/inode.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/ext4/inode.c +1 -2
@@ -5468,8 +5468,7 @@ int ext4_setattr(struct dentry *dentry,ext4_fc_track_range (handle, inode, (attr->ia_size >0 ? attr->ia_size -1 :0 ) >> inode->i_sb->s_blocksize_bits, - (oldsize >0 ? oldsize -1 :0 ) >> - inode->i_sb->s_blocksize_bits); +EXT_MAX_BLOCKS -1 ); else ext4_fc_track_range( handle, inode,
Greg Kroah-Hartman
maintainerPATCH 481/563 ext4: destroy ext4_fc_dentry_cachep kmemcache on module removal
In reply to Greg Kroah-HartmanFrom: Sebastian Andrzej Siewior <[email protected]>
commit ab047d516dea72f011c15c04a929851e4d053109 upstream.
The kmemcache for ext4_fc_dentry_cachep remains registered after module removal.
Destroy ext4_fc_dentry_cachep kmemcache on module removal.
--- fs/ext4/ext4.h | 1 + fs/ext4/fast_commit.c | 5 +++++ fs/ext4/super.c | 2 ++ 3 files changed, 8 insertions(+)
fs/ext4/ext4.h +1 -0
@@ -2778,6 +2778,7 @@ bool ext4_fc_replay_check_excluded(strucvoid ext4_fc_replay_cleanup (struct super_block *sb);int ext4_fc_commit (journal_t *journal,tid_t commit_tid);int __init ext4_fc_init_dentry_cache (void ); +void ext4_fc_destroy_dentry_cache (void );/* mballoc.c */ extern const struct seq_operations ext4_mb_seq_groups_ops;
fs/ext4/fast_commit.c +5 -0
@@ -2169,3 +2169,8 @@ int __init ext4_fc_init_dentry_cache(voireturn 0 ; } + +void ext4_fc_destroy_dentry_cache (void ) +{ +kmem_cache_destroy (ext4_fc_dentry_cachep); +}
fs/ext4/super.c +2 -0
@@ -6729,6 +6729,7 @@ static int __init ext4_init_fs(void) out:unregister_as_ext2 ();unregister_as_ext3 (); +ext4_fc_destroy_dentry_cache (); out05:destroy_inodecache (); out1:
@@ -6755,6 +6756,7 @@ static void __exit ext4_exit_fs(void)unregister_as_ext2 ();unregister_as_ext3 ();unregister_filesystem (&ext4_fs_type); +ext4_fc_destroy_dentry_cache ();destroy_inodecache ();ext4_exit_mballoc ();ext4_exit_sysfs ();
Greg Kroah-Hartman
maintainerPATCH 482/563 ext4: fix null-ptr-deref in __ext4_journal_ensure_credits
In reply to Greg Kroah-HartmanFrom: Ye Bin <[email protected]>
commit 298b5c521746d69c07beb2757292fb5ccc1b0f85 upstream.
We got issue as follows when run syzkaller test:
[ 1901.130043] EXT4-fs error (device vda): ext4_remount:5624: comm syz-executor.5: Abort forced by user [ 1901.130901] Aborting journal on device vda-8. [ 1901.131437] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.16: Detected aborted journal [ 1901.131566] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.11: Detected aborted journal [ 1901.132586] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.18: Detected aborted journal [ 1901.132751] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.9: Detected aborted journal [ 1901.136149] EXT4-fs error (device vda) in ext4_reserve_inode_write:6035: Journal has aborted [ 1901.136837] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-fuzzer: Detected aborted journal [ 1901.136915] ================================================================== [ 1901.138175] BUG: KASAN: null-ptr-deref in __ext4_journal_ensure_credits+0x74/0x140 [ext4] [ 1901.138343] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.13: Detected aborted journal [ 1901.138398] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.1: Detected aborted journal [ 1901.138808] Read of size 8 at addr 0000000000000000 by task syz-executor.17/968 [ 1901.138817] [ 1901.138852] EXT4-fs error (device vda): ext4_journal_check_start:61: comm syz-executor.30: Detected aborted journal [ 1901.144779] CPU: 1 PID: 968 Comm: syz-executor.17 Not tainted 4.19.90-vhulk2111.1.0.h893.eulerosv2r10.aarch64+ #1 [ 1901.146479] Hardware name: linux,dummy-virt (DT) [ 1901.147317] Call trace: [ 1901.147552] dump_backtrace+0x0/0x2d8 [ 1901.147898] show_stack+0x28/0x38 [ 1901.148215] dump_stack+0xec/0x15c [ 1901.148746] kasan_report+0x108/0x338 [ 1901.149207] __asan_load8+0x58/0xb0 [ 1901.149753] __ext4_journal_ensure_credits+0x74/0x140 [ext4] [ 1901.150579] ext4_xattr_delete_inode+0xe4/0x700 [ext4] [ 1901.151316] ext4_evict_inode+0x524/0xba8 [ext4] [ 1901.151985] evict+0x1a4/0x378 [ 1901.152353] iput+0x310/0x428 [ 1901.152733] do_unlinkat+0x260/0x428 [ 1901.153056] __arm64_sys_unlinkat+0x6c/0xc0 [ 1901.153455] el0_svc_common+0xc8/0x320 [ 1901.153799] el0_svc_handler+0xf8/0x160 [ 1901.154265] el0_svc+0x10/0x218 [ 1901.154682] ==================================================================
This issue may happens like this:
Process1 Process2ext4_evict_inode
ext4_journal_start
ext4_truncate
ext4_ind_truncate
ext4_free_branches
ext4_ind_truncate_ensure_credits
ext4_journal_ensure_credits_fn
ext4_journal_restart
handle->h_transaction = NULL;
mount -o remount,abort /mnt
-> trigger JBD abort
start_this_handle -> will return failed
ext4_xattr_delete_inode
ext4_journal_ensure_credits
ext4_journal_ensure_credits_fn
__ext4_journal_ensure_credits
jbd2_handle_buffer_credits
journal = handle->h_transaction->t_journal; ->null-ptr-derefNow, indirect truncate process didn't handle error. To solve this issue maybe simply add check handle is abort in '__ext4_journal_ensure_credits' is enough, and i also think this is necessary.
--- fs/ext4/ext4_jbd2.c | 2 ++ 1 file changed, 2 insertions(+)
fs/ext4/ext4_jbd2.c +2 -0
@@ -162,6 +162,8 @@ int __ext4_journal_ensure_credits(handle {if (!ext4_handle_valid (handle))return 0 ; +if (is_handle_aborted (handle)) +return -EROFS ;if (jbd2_handle_buffer_credits (handle) >= check_cred && handle->h_revoke_credits >= revoke_cred)return 0 ;
Greg Kroah-Hartman
maintainerPATCH 483/563 ext4: dont use the orphan list when migrating an inode
In reply to Greg Kroah-HartmanFrom: Theodore Ts'o <[email protected]>
commit 6eeaf88fd586f05aaf1d48cb3a139d2a5c6eb055 upstream.
We probably want to remove the indirect block to extents migration feature after a deprecation window, but until then, let's fix a potential data loss problem caused by the fact that we put the tmp_inode on the orphan list. In the unlikely case where we crash and do a journal recovery, the data blocks belonging to the inode being migrated are also represented in the tmp_inode on the orphan list --- and so its data blocks will get marked unallocated, and available for reuse.
Instead, stop putting the tmp_inode on the oprhan list. So in the case where we crash while migrating the inode, we'll leak an inode, which is not a disaster. It will be easily fixed the next time we run fsck, and it's better than potentially having blocks getting claimed by two different files, and losing data as a result.
--- fs/ext4/migrate.c | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-)
fs/ext4/migrate.c +4 -15
@@ -437,12 +437,12 @@ int ext4_ext_migrate(struct inode *inodepercpu_down_write (&sbi->s_writepages_rwsem);/* -* Worst case we can touch the allocation bitmaps, a bgd -* block, and a block to link in the orphan list. We do need -* need to worry about credits for modifying the quota inode. +* Worst case we can touch the allocation bitmaps and a block +* group descriptor block. We do need need to worry about +* credits for modifying the quota inode. */ handle =ext4_journal_start (inode,EXT4_HT_MIGRATE , -4 +EXT4_MAXQUOTAS_TRANS_BLOCKS (inode->i_sb)); +3 +EXT4_MAXQUOTAS_TRANS_BLOCKS (inode->i_sb));if (IS_ERR (handle)) { retval =PTR_ERR (handle);
@@ -463,10 +463,6 @@ int ext4_ext_migrate(struct inode *inode* Use the correct seed for checksum (i.e. the seed from 'inode'). This * is so that the metadata blocks will have the correct checksum after * the migration. -* -* Note however that, if a crash occurs during the migration process, -* the recovery process is broken because the tmp_inode checksums will -* be wrong and the orphans cleanup will fail. */ ei =EXT4_I (inode);EXT4_I (tmp_inode)->i_csum_seed = ei->i_csum_seed;
@@ -478,7 +474,6 @@ int ext4_ext_migrate(struct inode *inodeclear_nlink (tmp_inode);ext4_ext_tree_init (handle, tmp_inode); -ext4_orphan_add (handle, tmp_inode);ext4_journal_stop (handle);/*
@@ -503,12 +498,6 @@ int ext4_ext_migrate(struct inode *inode handle =ext4_journal_start (inode,EXT4_HT_MIGRATE ,1 );if (IS_ERR (handle)) { -/* -* It is impossible to update on-disk structures without -* a handle, so just rollback in-core changes and live other -* work to orphan_list_cleanup() -*/ -ext4_orphan_del (NULL , tmp_inode); retval =PTR_ERR (handle); goto out_tmp_inode; }
Greg Kroah-Hartman
maintainerPATCH 484/563 drm/radeon: fix error handling in radeon_driver_open_kms
In reply to Greg Kroah-HartmanFrom: Christian König <[email protected]>
commit 4722f463896cc0ef1a6f1c3cb2e171e949831249 upstream.
The return value was never initialized so the cleanup code executed when it isn't even necessary.
Just add proper error handling.
--- drivers/gpu/drm/radeon/radeon_kms.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
drivers/gpu/drm/radeon/radeon_kms.c +12 -10
@@ -652,18 +652,18 @@ int radeon_driver_open_kms(struct drm_de fpriv =kzalloc (sizeof (*fpriv),GFP_KERNEL );if (unlikely (!fpriv)) { r = -ENOMEM ; - goto out_suspend; + goto err_suspend; }if (rdev->accel_working) { vm = &fpriv->vm; r =radeon_vm_init (rdev, vm);if (r) - goto out_fpriv; + goto err_fpriv; r =radeon_bo_reserve (rdev->ring_tmp_bo.bo, false);if (r) - goto out_vm_fini; + goto err_vm_fini;/* map the ib pool buffer read only into * virtual address space */
@@ -671,7 +671,7 @@ int radeon_driver_open_kms(struct drm_de rdev->ring_tmp_bo.bo);if (!vm->ib_bo_va) { r = -ENOMEM ; - goto out_vm_fini; + goto err_vm_fini; } r = radeon_vm_bo_set_addr(rdev, vm->ib_bo_va,
@@ -679,19 +679,21 @@ int radeon_driver_open_kms(struct drm_deRADEON_VM_PAGE_READABLE | RADEON_VM_PAGE_SNOOPED);if (r) - goto out_vm_fini; + goto err_vm_fini; } file_priv->driver_priv = fpriv; } -if (!r) - goto out_suspend; +pm_runtime_mark_last_busy (dev->dev); +pm_runtime_put_autosuspend (dev->dev); +return 0 ; -out_vm_fini: +err_vm_fini:radeon_vm_fini (rdev, vm); -out_fpriv: +err_fpriv:kfree (fpriv); -out_suspend: + +err_suspend:pm_runtime_mark_last_busy (dev->dev);pm_runtime_put_autosuspend (dev->dev);return r;
Greg Kroah-Hartman
maintainerPATCH 485/563 of: base: Improve argument length mismatch error
In reply to Greg Kroah-HartmanFrom: Baruch Siach <[email protected]>
commit 5d05b811b5acb92fc581a7b328b36646c86f5ab9 upstream.
The cells_name field of of_phandle_iterator might be NULL. Use the phandle name instead. With this change instead of:
OF: /soc/pinctrl@1000000: (null) = 3 found 2
We get:
OF: /soc/pinctrl@1000000: phandle pinctrl@1000000 needs 3, found 2
Which is a more helpful messages making DT debugging easier.
In this particular example the phandle name looks like duplicate of the same node name. But note that the first node is the parent node (it->parent), while the second is the phandle target (it->node). They happen to be the same in the case that triggered this improvement. See commit 72cb4c48a46a ("arm64: dts: qcom: ipq6018: Fix gpio-ranges property").
--- drivers/of/base.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/of/base.c +8 -3
@@ -1328,9 +1328,14 @@ int of_phandle_iterator_next(struct of_p* property data length */ if (it->cur + count > it->list_end) { -pr_err ("%pOF: %s = %d found %td\n" , - it->parent, it->cells_name, - count, it->list_end - it->cur); +if (it->cells_name) +pr_err ("%pOF: %s = %d found %td\n" , + it->parent, it->cells_name, + count, it->list_end - it->cur); +else +pr_err ("%pOF: phandle %s needs %d, found %td\n" , + it->parent,of_node_full_name (it->node), + count, it->list_end - it->cur); goto err; } }
Greg Kroah-Hartman
maintainerPATCH 486/563 firmware: Update Kconfig help text for Google firmware
In reply to Greg Kroah-HartmanFrom: Ben Hutchings <[email protected]>
commit d185a3466f0cd5af8f1c5c782c53bc0e6f2e7136 upstream.
The help text for GOOGLE_FIRMWARE states that it should only be enabled when building a kernel for Google's own servers. However, many of the drivers dependent on it are also useful on Chromebooks or on any platform using coreboot.
Update the help text to reflect this double duty.
--- drivers/firmware/google/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/firmware/google/Kconfig +3 -3
@@ -3,9 +3,9 @@ menuconfig GOOGLE_FIRMWARE bool "Google Firmware Drivers" default n help - These firmware drivers are used by Google's servers. They are - only useful if you are working directly on one of their - proprietary servers. If in doubt, say "N". + These firmware drivers are used by Google servers, + Chromebooks and other devices using coreboot firmware. + If in doubt, say "N". if GOOGLE_FIRMWARE
Greg Kroah-Hartman
maintainerPATCH 487/563 can: mcp251xfd: mcp251xfd_tef_obj_read(): fix typo in error message
In reply to Greg Kroah-HartmanFrom: Marc Kleine-Budde <[email protected]>
commit 99e7cc3b3f85d9a583ab83f386315c59443509ae upstream.
This patch fixes a typo in the error message in mcp251xfd_tef_obj_read(), if trying to read too many objects.
--- drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c +1 -1
@@ -1288,7 +1288,7 @@ mcp251xfd_tef_obj_read(const struct mcp2 len > tx_ring->obj_num || offset + len > tx_ring->obj_num)) {netdev_err (priv->ndev, -"Trying to read to many TEF objects (max=%d, offset=%d, len=%d).\n" , +"Trying to read too many TEF objects (max=%d, offset=%d, len=%d).\n" , tx_ring->obj_num, offset, len);return -ERANGE ; }
Greg Kroah-Hartman
maintainerPATCH 488/563 media: rcar-csi2: Optimize the selection PHTW register
In reply to Greg Kroah-HartmanFrom: Suresh Udipi <[email protected]>
commit 549cc89cd09a85aaa16dc07ef3db811d5cf9bcb1 upstream.
PHTW register is selected based on default bit rate from Table[1]. for the bit rates less than or equal to 250. Currently first value of default bit rate which is greater than or equal to the caculated mbps is selected. This selection can be further improved by selecting the default bit rate which is nearest to the calculated value.
[1] specs r19uh0105ej0200-r-car-3rd-generation.pdf [Table 25.12]
--- drivers/media/platform/rcar-vin/rcar-csi2.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/media/platform/rcar-vin/rcar-csi2.c +8 -1
@@ -976,10 +976,17 @@ static int rcsi2_phtw_write_mbps(struct const struct rcsi2_mbps_reg *values, u16 code) {const struct rcsi2_mbps_reg *value; +const struct rcsi2_mbps_reg *prev_value =NULL ; -for (value = values; value->mbps; value++) +for (value = values; value->mbps; value++) {if (value->mbps >= mbps)break ; + prev_value = value; + } + +if (prev_value && + ((mbps - prev_value->mbps) <= (value->mbps - mbps))) + value = prev_value;if (!value->mbps) {dev_err (priv->dev,"Unsupported PHY speed (%u Mbps)" , mbps);
Greg Kroah-Hartman
maintainerPATCH 489/563 drm/vc4: hdmi: Make sure the device is powered with CEC
In reply to Greg Kroah-HartmanFrom: Maxime Ripard <[email protected]>
commit 20b0dfa86bef0e80b41b0e5ac38b92f23b6f27f9 upstream.
Similarly to what we encountered with the detect hook with DRM, nothing actually prevents any of the CEC callback from being run while the HDMI output is disabled.
However, this is an issue since any register access to the controller when it's powered down will result in a silent hang.
Let's make sure we run the runtime_pm hooks when the CEC adapter is opened and closed by the userspace to avoid that issue.
--- drivers/gpu/drm/vc4/vc4_hdmi.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/gpu/drm/vc4/vc4_hdmi.c +9 -1
@@ -1399,8 +1399,14 @@ static int vc4_hdmi_cec_adap_enable(strustruct vc4_hdmi *vc4_hdmi =cec_get_drvdata (adap);/* clock period in microseconds */ const u32 usecs =1000000 /CEC_CLOCK_FREQ ; -u32 val =HDMI_READ (HDMI_CEC_CNTRL_5 ); +u32 val; +int ret; + + ret =pm_runtime_resume_and_get (&vc4_hdmi->pdev->dev); +if (ret) +return ret; + val =HDMI_READ (HDMI_CEC_CNTRL_5 ); val &= ~(VC4_HDMI_CEC_TX_SW_RESET |VC4_HDMI_CEC_RX_SW_RESET |VC4_HDMI_CEC_CNT_TO_4700_US_MASK |VC4_HDMI_CEC_CNT_TO_4500_US_MASK );
@@ -1525,6 +1531,8 @@ static int vc4_hdmi_cec_init(struct vc4_if (ret <0 ) goto err_delete_cec_adap; +pm_runtime_put (&vc4_hdmi->pdev->dev); +return 0 ; err_delete_cec_adap:
Greg Kroah-Hartman
maintainerPATCH 490/563 media: correct MEDIA_TEST_SUPPORT help text
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
commit 09f4d1513267d0ab712f5d29e7bd136535748709 upstream.
Fix grammar/wording in the help text for MEDIA_TEST_SUPPORT.
--- drivers/media/Kconfig | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/media/Kconfig +4 -4
@@ -142,10 +142,10 @@ config MEDIA_TEST_SUPPORT prompt "Test drivers" if MEDIA_SUPPORT_FILTER default y if !MEDIA_SUPPORT_FILTER help - Those drivers should not be used on production Kernels, but - can be useful on debug ones. It enables several dummy drivers - that simulate a real hardware. Very useful to test userspace - applications and to validate if the subsystem core is doesn't + These drivers should not be used on production kernels, but + can be useful on debug ones. This option enables several dummy drivers + that simulate real hardware. Very useful to test userspace + applications and to validate if the subsystem core doesn't have regressions. Say Y if you want to use some virtual test driver.
Greg Kroah-Hartman
maintainerPATCH 491/563 Documentation: dmaengine: Correctly describe dmatest with channel unset
In reply to Greg Kroah-HartmanFrom: Daniel Thompson <[email protected]>
commit c61d7b2ef141abf81140756b45860a2306f395a2 upstream.
Currently the documentation states that channels must be configured before running the dmatest. This has not been true since commit 6b41030fdc79 ("dmaengine: dmatest: Restore default for channel"). Fix accordingly.
--- Documentation/driver-api/dmaengine/dmatest.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
Documentation/driver-api/dmaengine/dmatest.rst +4 -3
@@ -143,13 +143,14 @@ Part 5 - Handling channel allocation Allocating Channels ------------------- -Channels are required to be configured prior to starting the test run. -Attempting to run the test without configuring the channels will fail. +Channels do not need to be configured prior to starting a test run. Attempting +to run the test without configuring the channels will result in testing any +channels that are available. Example:: % echo 1 > /sys/module/dmatest/parameters/run - dmatest: Could not start test, no channels configured + dmatest: No channels configured, continue with any Channels are registered using the "channel" parameter. Channels can be requested by their name, once requested, the channel is registered and a pending thread is added to the test list.
Greg Kroah-Hartman
maintainerPATCH 492/563 Documentation: ACPI: Fix data node reference documentation
In reply to Greg Kroah-HartmanFrom: Sakari Ailus <[email protected]>
commit a11174952205d082f1658fab4314f0caf706e0a8 upstream.
The data node reference documentation was missing a package that must contain the property values, instead property name and multiple values being present in a single package. This is not aligned with the _DSD spec.
Fix it by adding the package for the values.
Also add the missing "reg" properties to two numbered nodes.
--- Documentation/firmware-guide/acpi/dsd/data-node-references.rst | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
Documentation/firmware-guide/acpi/dsd/data-node-references.rst +8 -2
@@ -5,7 +5,7 @@ Referencing hierarchical data nodes =================================== -:Copyright: |copy| 2018 Intel Corporation +:Copyright: |copy| 2018, 2021 Intel Corporation :Author: Sakari Ailus <[email protected]> ACPI in general allows referring to device objects in the tree only.
@@ -52,12 +52,14 @@ the ANOD object which is also the final Name (NOD0, Package() { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { + Package () { "reg", 0 }, Package () { "random-property", 3 }, } }) Name (NOD1, Package() { ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { + Package () { "reg", 1 }, Package () { "anothernode", "ANOD" }, } })
@@ -74,7 +76,11 @@ the ANOD object which is also the final Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { - Package () { "reference", ^DEV0, "node@1", "anothernode" }, + Package () { + "reference", Package () { + ^DEV0, "node@1", "anothernode" + } + }, } }) }
Greg Kroah-Hartman
maintainerPATCH 493/563 Documentation: refer to config RANDOMIZE_BASE for kernel address-space randomization
In reply to Greg Kroah-HartmanFrom: Lukas Bulwahn <[email protected]>
commit 82ca67321f55a8d1da6ac3ed611da3c32818bb37 upstream.
The config RANDOMIZE_SLAB does not exist, the authors probably intended to refer to the config RANDOMIZE_BASE, which provides kernel address-space randomization. They probably just confused SLAB with BASE (these two four-letter words coincidentally share three common letters), as they also point out the config SLAB_FREELIST_RANDOM as further randomization within the same sentence.
Fix the reference of the config for kernel address-space randomization to the config that provides that.
--- Documentation/admin-guide/hw-vuln/spectre.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/admin-guide/hw-vuln/spectre.rst +1 -1
@@ -468,7 +468,7 @@ Spectre variant 2 before invoking any firmware code to prevent Spectre variant 2 exploits using the firmware. - Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=y + Using kernel address space randomization (CONFIG_RANDOMIZE_BASE=y and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes attacks on the kernel generally more difficult.
Greg Kroah-Hartman
maintainerPATCH 494/563 Documentation: fix firewire.rst ABI file path error
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
commit b0ac702f3329cdc8a06dcaac73183d4b5a2b942d upstream.
Adjust the path of the ABI files for firewire.rst to prevent a documentation build error. Prevents this problem:
Sphinx parallel build error:
docutils.utils.SystemMessage: Documentation/driver-api/firewire.rst:22: (SEVERE/4) Problems with "include" directive path:
InputError: [Errno 2] No such file or directory: '../Documentation/driver-api/ABI/stable/firewire-cdev'.
--- Documentation/driver-api/firewire.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Documentation/driver-api/firewire.rst +2 -2
@@ -19,7 +19,7 @@ of kernel interfaces is available via ex Firewire char device data structures ==================================== -.. include:: /ABI/stable/firewire-cdev +.. include:: ../ABI/stable/firewire-cdev :literal: .. kernel-doc:: include/uapi/linux/firewire-cdev.h
@@ -28,7 +28,7 @@ Firewire char device data structures Firewire device probing and sysfs interfaces ============================================ -.. include:: /ABI/stable/sysfs-bus-firewire +.. include:: ../ABI/stable/sysfs-bus-firewire :literal: .. kernel-doc:: drivers/firewire/core-device.c
Greg Kroah-Hartman
maintainerPATCH 495/563 Bluetooth: hci_sync: Fix not setting adv set duration
In reply to Greg Kroah-HartmanFrom: Luiz Augusto von Dentz <[email protected]>
commit f16a491c65d9eb19398b25aefc10c2d3313d17b3 upstream.
10bbffa3e88e attempted to fix the use of rotation duration as advertising duration but it didn't change the if condition which still uses the duration instead of the timeout.
--- net/bluetooth/hci_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/bluetooth/hci_request.c +1 -1
@@ -2118,7 +2118,7 @@ int __hci_req_enable_ext_advertising(str/* Set duration per instance since controller is responsible for * scheduling it. */ -if (adv_instance && adv_instance->duration) { +if (adv_instance && adv_instance->timeout) {u16 duration = adv_instance->timeout *MSEC_PER_SEC ;/* Time = N * 10 ms */
Greg Kroah-Hartman
maintainerPATCH 496/563 scsi: core: Show SCMD_LAST in text form
In reply to Greg Kroah-HartmanFrom: Bart Van Assche <[email protected]>
commit 3369046e54ca8f82e0cb17740643da2d80d3cfa8 upstream.
The SCSI debugfs code supports showing information about pending commands, including translating SCSI command flags from numeric into text format. Also convert the SCMD_LAST flag from numeric into text form.
--- drivers/scsi/scsi_debugfs.c | 1 + 1 file changed, 1 insertion(+)
drivers/scsi/scsi_debugfs.c +1 -0
@@ -10,6 +10,7 @@ static const char *const scsi_cmd_flags[SCSI_CMD_FLAG_NAME (TAGGED ),SCSI_CMD_FLAG_NAME (UNCHECKED_ISA_DMA ),SCSI_CMD_FLAG_NAME (INITIALIZED ), + SCSI_CMD_FLAG_NAME(LAST), };#undef SCSI_CMD_FLAG_NAME
Greg Kroah-Hartman
maintainerPATCH 497/563 dmaengine: uniphier-xdmac: Fix type of address variables
In reply to Greg Kroah-HartmanFrom: Kunihiko Hayashi <[email protected]>
commit 105a8c525675bb7d4d64871f9b2edf39460de881 upstream.
The variables src_addr and dst_addr handle DMA addresses, so these should be declared as dma_addr_t.
--- drivers/dma/uniphier-xdmac.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/dma/uniphier-xdmac.c +3 -2
@@ -131,8 +131,9 @@ uniphier_xdmac_next_desc(struct uniphierstatic void uniphier_xdmac_chan_start (struct uniphier_xdmac_chan *xc,struct uniphier_xdmac_desc *xd) { -u32 src_mode, src_addr, src_width; -u32 dst_mode, dst_addr, dst_width; +u32 src_mode, src_width; +u32 dst_mode, dst_width; +dma_addr_t src_addr, dst_addr;u32 val, its, tnum;enum dma_slave_buswidth buswidth;
Greg Kroah-Hartman
maintainerPATCH 498/563 RDMA/hns: Modify the mapping attribute of doorbell to device
In reply to Greg Kroah-HartmanFrom: Yixing Liu <[email protected]>
commit 39d5534b1302189c809e90641ffae8cbdc42a8fc upstream.
It is more general for ARM device drivers to use the device attribute to map PCI BAR spaces.
--- drivers/infiniband/hw/hns/hns_roce_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/hw/hns/hns_roce_main.c +1 -1
@@ -359,7 +359,7 @@ static int hns_roce_mmap(struct ib_ucontreturn rdma_user_mmap_io (context, vma,to_hr_ucontext (context)->uar.pfn,PAGE_SIZE , -pgprot_noncached (vma->vm_page_prot), +pgprot_device (vma->vm_page_prot),NULL );/* vm_pgoff: 1 -- TPTR */
Greg Kroah-Hartman
maintainerPATCH 499/563 RDMA/rxe: Fix a typo in opcode name
In reply to Greg Kroah-HartmanFrom: Chengguang Xu <[email protected]>
commit 8d1cfb884e881efd69a3be4ef10772c71cb22216 upstream.
There is a redundant ']' in the name of opcode IB_OPCODE_RC_SEND_MIDDLE, so just fix it.
--- drivers/infiniband/sw/rxe/rxe_opcode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/sw/rxe/rxe_opcode.c +1 -1
@@ -110,7 +110,7 @@ struct rxe_opcode_info rxe_opcode[RXE_NU } }, [IB_OPCODE_RC_SEND_MIDDLE] = { - .name = "IB_OPCODE_RC_SEND_MIDDLE]", + .name = "IB_OPCODE_RC_SEND_MIDDLE", .mask =RXE_PAYLOAD_MASK |RXE_REQ_MASK |RXE_SEND_MASK | RXE_MIDDLE_MASK, .length = RXE_BTH_BYTES,
Greg Kroah-Hartman
maintainerPATCH 500/563 dmaengine: stm32-mdma: fix STM32_MDMA_CTBR_TSEL_MASK
In reply to Greg Kroah-HartmanFrom: Amelie Delaunay <[email protected]>
commit e7f110889a87307fb0fed408a5dee1707796ca04 upstream.
This patch fixes STM32_MDMA_CTBR_TSEL_MASK, which is [5:0], not [7:0].
--- drivers/dma/stm32-mdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/dma/stm32-mdma.c +1 -1
@@ -184,7 +184,7 @@#define STM32_MDMA_CTBR (x) (0x68 + 0x40 * (x))#define STM32_MDMA_CTBR_DBUS BIT(17)#define STM32_MDMA_CTBR_SBUS BIT(16) -#define STM32_MDMA_CTBR_TSEL_MASK GENMASK(7, 0) +#define STM32_MDMA_CTBR_TSEL_MASK GENMASK(5, 0)#define STM32_MDMA_CTBR_TSEL (n) STM32_MDMA_SET(n, \ STM32_MDMA_CTBR_TSEL_MASK)
Greg Kroah-Hartman
maintainerPATCH 501/563 Revert "net/mlx5: Add retry mechanism to the command entry index allocation"
In reply to Greg Kroah-HartmanFrom: Moshe Shemesh <[email protected]>
commit 4f6626b0e140867fd6d5a2e9d4ceaef97f10f46a upstream.
This reverts commit 410bd754cd73c4a2ac3856d9a03d7b08f9c906bf.
The reverted commit had added a retry mechanism to the command entry index allocation. The previous patch ensures that there is a free command entry index once the command work handler holds the command semaphore. Thus the retry mechanism is not needed.
--- drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 21 +-------------------- 1 file changed, 1 insertion(+), 20 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/cmd.c +1 -20
@@ -887,25 +887,6 @@ static bool opcode_allowed(struct mlx5_creturn cmd->allowed_opcode == opcode; } -static int cmd_alloc_index_retry (struct mlx5_cmd *cmd) -{ -unsigned long alloc_end = jiffies +msecs_to_jiffies (1000 ); -int idx; - -retry: - idx =cmd_alloc_index (cmd); -if (idx <0 &&time_before (jiffies, alloc_end)) { -/* Index allocation can fail on heavy load of commands. This is a temporary -* situation as the current command already holds the semaphore, meaning that -* another command completion is being handled and it is expected to release -* the entry index soon. -*/ -cpu_relax (); - goto retry; - } -return idx; -} -bool mlx5_cmd_is_down (struct mlx5_core_dev *dev) { return pci_channel_offline(dev->pdev) ||
@@ -930,7 +911,7 @@ static void cmd_work_handler(struct work sem = ent->page_queue ? &cmd->pages_sem : &cmd->sem;down (sem);if (!ent->page_queue) { - alloc_ret =cmd_alloc_index_retry (cmd); + alloc_ret =cmd_alloc_index (cmd);if (alloc_ret <0 ) {mlx5_core_err_rl (dev,"failed to allocate command entry\n" );if (ent->callback) {
Greg Kroah-Hartman
maintainerPATCH 502/563 powerpc/cell: Fix clang -Wimplicit-fallthrough warning
In reply to Greg Kroah-HartmanFrom: Anders Roxell <[email protected]>
commit e89257e28e844f5d1d39081bb901d9f1183a7705 upstream.
Clang warns:
arch/powerpc/platforms/cell/pervasive.c:81:2: error: unannotated fall-through between switch labels
case SRR1_WAKEEE:
^
arch/powerpc/platforms/cell/pervasive.c:81:2: note: insert 'break;' to avoid fall-through
case SRR1_WAKEEE:
^
break;1 error generated.
Clang is more pedantic than GCC, which does not warn when failing through to a case that is just break or return. Clang's version is more in line with the kernel's own stance in deprecated.rst. Add athe missing break to silence the warning.
--- arch/powerpc/platforms/cell/pervasive.c | 1 + 1 file changed, 1 insertion(+)
arch/powerpc/platforms/cell/pervasive.c +1 -0
@@ -77,6 +77,7 @@ static int cbe_system_reset_exception(stswitch (regs->msr &SRR1_WAKEMASK ) {case SRR1_WAKEDEC :set_dec (1 ); +break ;case SRR1_WAKEEE :/* * Handle these when interrupts get re-enabled and we take
Greg Kroah-Hartman
maintainerPATCH 503/563 powerpc/fsl/dts: Enable WA for erratum A-009885 on fman3l MDIO buses
In reply to Greg Kroah-HartmanFrom: Tobias Waldekranz <[email protected]>
commit 0d375d610fa96524e2ee2b46830a46a7bfa92a9f upstream.
This block is used in (at least) T1024 and T1040, including their variants like T1023 etc.
--- arch/powerpc/boot/dts/fsl/qoriq-fman3l-0.dtsi | 2 ++ 1 file changed, 2 insertions(+)
arch/powerpc/boot/dts/fsl/qoriq-fman3l-0.dtsi +2 -0
@@ -79,6 +79,7 @@ fman0: fman@400000 { #size-cells = <0>; compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio"; reg = <0xfc000 0x1000>; + fsl,erratum-a009885; }; xmdio0: mdio@fd000 {
@@ -86,6 +87,7 @@ fman0: fman@400000 { #size-cells = <0>; compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio"; reg = <0xfd000 0x1000>; + fsl,erratum-a009885; }; };
Greg Kroah-Hartman
maintainerPATCH 504/563 block: Fix fsync always failed if once failed
In reply to Greg Kroah-HartmanFrom: Ye Bin <[email protected]>
commit 8a7518931baa8ea023700987f3db31cb0a80610b upstream.
We do test with inject error fault base on v4.19, after test some time we found sync /dev/sda always failed.
[root@localhost] sync /dev/sda
sync: error syncing '/dev/sda': Input/output error
scsi log as follows:
[19069.812296] sd 0:0:0:0: [sda] tag#64 Send: scmd 0x00000000d03a0b6b [19069.812302] sd 0:0:0:0: [sda] tag#64 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00 [19069.812533] sd 0:0:0:0: [sda] tag#64 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK [19069.812536] sd 0:0:0:0: [sda] tag#64 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00 [19069.812539] sd 0:0:0:0: [sda] tag#64 scsi host busy 1 failed 0 [19069.812542] sd 0:0:0:0: Notifying upper driver of completion (result 0) [19069.812546] sd 0:0:0:0: [sda] tag#64 sd_done: completed 0 of 0 bytes [19069.812549] sd 0:0:0:0: [sda] tag#64 0 sectors total, 0 bytes done. [19069.812564] print_req_error: I/O error, dev sda, sector 0
ftrace log as follows:
rep-306069 [007] .... 19654.923315: block_bio_queue: 8,0 FWS 0 + 0 [rep] rep-306069 [007] .... 19654.923333: block_getrq: 8,0 FWS 0 + 0 [rep]
kworker/7:1H-250 [007] .... 19654.923352: block_rq_issue: 8,0 FF 0 () 0 + 0 [kworker/7:1H]
<idle>-0 [007] ..s. 19654.923562: block_rq_complete: 8,0 FF () 18446744073709551615 + 0 [0]
<idle>-0 [007] d.s. 19654.923576: block_rq_complete: 8,0 WS () 0 + 0 [-5]
As 8d6996630c03 introduce 'fq->rq_status', this data only update when 'flush_rq' reference count isn't zero. If flush request once failed and record error code in 'fq->rq_status'. If there is no chance to update 'fq->rq_status',then do fsync will always failed.
To address this issue reset 'fq->rq_status' after return error code to upper layer.
--- block/blk-flush.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
block/blk-flush.c +3 -1
@@ -236,8 +236,10 @@ static void flush_end_io(struct request* avoiding use-after-free. */ WRITE_ONCE (flush_rq->state,MQ_RQ_IDLE ); -if (fq->rq_status !=BLK_STS_OK ) +if (fq->rq_status !=BLK_STS_OK ) { error = fq->rq_status; + fq->rq_status =BLK_STS_OK ; + }if (!q->elevator) { flush_rq->tag =BLK_MQ_NO_TAG ;
Greg Kroah-Hartman
maintainerPATCH 505/563 arm64/bpf: Remove 128MB limit for BPF JIT programs
In reply to Greg Kroah-HartmanFrom: Russell King <[email protected]>
commit b89ddf4cca43f1269093942cf5c4e457fd45c335 upstream.
Commit 91fc957c9b1d ("arm64/bpf: don't allocate BPF JIT programs in module memory") restricts BPF JIT program allocation to a 128MB region to ensure BPF programs are still in branching range of each other. However this restriction should not apply to the aarch64 JIT, since BPF_JMP | BPF_CALL are implemented as a 64-bit move into a register and then a BLR instruction - which has the effect of being able to call anything without proximity limitation.
The practical reason to relax this restriction on JIT memory is that 128MB of JIT memory can be quickly exhausted, especially where PAGE_SIZE is 64KB - one page is needed per program. In cases where seccomp filters are applied to multiple VMs on VM launch - such filters are classic BPF but converted to BPF - this can severely limit the number of VMs that can be launched. In a world where we support BPF JIT always on, turning off the JIT isn't always an option either.
--- arch/arm64/include/asm/extable.h | 9 --------- arch/arm64/include/asm/memory.h | 5 +---- arch/arm64/kernel/traps.c | 2 +- arch/arm64/mm/ptdump.c | 2 -- arch/arm64/net/bpf_jit_comp.c | 7 ++----- 5 files changed, 4 insertions(+), 21 deletions(-)
arch/arm64/include/asm/extable.h +0 -9
@@ -22,15 +22,6 @@ struct exception_table_entry#define ARCH_HAS_RELATIVE_EXTABLE -static inline bool in_bpf_jit (struct pt_regs *regs) -{ -if (!IS_ENABLED (CONFIG_BPF_JIT )) -return false; - -return regs->pc >=BPF_JIT_REGION_START && - regs->pc <BPF_JIT_REGION_END ; -} -#ifdef CONFIG_BPF_JIT int arm64_bpf_fixup_exception (const struct exception_table_entry *ex,struct pt_regs *regs);
arch/arm64/include/asm/memory.h +1 -4
@@ -44,11 +44,8 @@#define _PAGE_OFFSET (va) (-(UL(1) << (va)))#define PAGE_OFFSET (_PAGE_OFFSET(VA_BITS))#define KIMAGE_VADDR (MODULES_END) -#define BPF_JIT_REGION_START (KASAN_SHADOW_END) -#define BPF_JIT_REGION_SIZE (SZ_128M) -#define BPF_JIT_REGION_END (BPF_JIT_REGION_START + BPF_JIT_REGION_SIZE)#define MODULES_END (MODULES_VADDR + MODULES_VSIZE) -#define MODULES_VADDR (BPF_JIT_REGION_END) +#define MODULES_VADDR (_PAGE_END(VA_BITS_MIN))#define MODULES_VSIZE (SZ_128M)#define VMEMMAP_START (-VMEMMAP_SIZE - SZ_2M)#define VMEMMAP_END (VMEMMAP_START + VMEMMAP_SIZE)
arch/arm64/kernel/traps.c +1 -1
@@ -923,7 +923,7 @@ static struct break_hook bug_break_hookstatic int reserved_fault_handler (struct pt_regs *regs,unsigned int esr) {pr_err ("%s generated an invalid instruction at %pS!\n" , -in_bpf_jit (regs) ?"BPF JIT" :"Kernel text patching" , +"Kernel text patching" , (void *)instruction_pointer (regs));/* We cannot handle this */
arch/arm64/mm/ptdump.c +0 -2
@@ -41,8 +41,6 @@ static struct addr_marker address_marker { 0 /* KASAN_SHADOW_START */, "Kasan shadow start" }, { KASAN_SHADOW_END, "Kasan shadow end" }, #endif - { BPF_JIT_REGION_START, "BPF start" }, - { BPF_JIT_REGION_END, "BPF end" }, { MODULES_VADDR, "Modules start" }, { MODULES_END, "Modules end" }, { VMALLOC_START, "vmalloc() area" },
arch/arm64/net/bpf_jit_comp.c +2 -5
@@ -1136,15 +1136,12 @@ out:u64 bpf_jit_alloc_exec_limit (void ) { -return BPF_JIT_REGION_SIZE ; +return VMALLOC_END -VMALLOC_START ; }void *bpf_jit_alloc_exec (unsigned long size) { -return __vmalloc_node_range (size,PAGE_SIZE ,BPF_JIT_REGION_START , -BPF_JIT_REGION_END ,GFP_KERNEL , -PAGE_KERNEL ,0 ,NUMA_NO_NODE , -__builtin_return_address (0 )); +return vmalloc (size); }void bpf_jit_free_exec (void *addr)
Greg Kroah-Hartman
maintainerPATCH 506/563 bpftool: Remove inclusion of utilities.mak from Makefiles
In reply to Greg Kroah-HartmanFrom: Quentin Monnet <[email protected]>
commit 48f5aef4c458c19ab337eed8c95a6486cc014aa3 upstream.
Bpftool's Makefile, and the Makefile for its documentation, both include scripts/utilities.mak, but they use none of the items defined in this file. Remove the includes.
--- tools/bpf/bpftool/Documentation/Makefile | 1 - tools/bpf/bpftool/Makefile | 1 - 2 files changed, 2 deletions(-)
tools/bpf/bpftool/Documentation/Makefile +0 -1
@@ -1,6 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only include ../../../scripts/Makefile.include -include ../../../scripts/utilities.mak INSTALL ?= install RM ?= rm -f
tools/bpf/bpftool/Makefile +0 -1
@@ -1,6 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only include ../../scripts/Makefile.include -include ../../scripts/utilities.mak ifeq ($(srctree),) srctree := $(patsubst %/,%,$(dir $(CURDIR)))
Greg Kroah-Hartman
maintainerPATCH 507/563 xdp: check prog type before updating BPF link
In reply to Greg Kroah-HartmanFrom: Toke Høiland-Jørgensen <[email protected]>
commit 382778edc8262b7535f00523e9eb22edba1b9816 upstream.
The bpf_xdp_link_update() function didn't check the program type before updating the program, which made it possible to install any program type as an XDP program, which is obviously not good. Syzbot managed to trigger this by swapping in an LWT program on the XDP hook which would crash in a helper call.
Fix this by adding a check and bailing out if the types don't match.
--- net/core/dev.c | 6 ++++++ 1 file changed, 6 insertions(+)
net/core/dev.c +6 -0
@@ -9339,6 +9339,12 @@ static int bpf_xdp_link_update(struct bp goto out_unlock; } old_prog = link->prog; +if (old_prog->type != new_prog->type || + old_prog->expected_attach_type != new_prog->expected_attach_type) { + err = -EINVAL ; + goto out_unlock; + } +if (old_prog == new_prog) {/* no-op, don't disturb drivers */ bpf_prog_put (new_prog);
Greg Kroah-Hartman
maintainerPATCH 508/563 perf evsel: Override attr->sample_period for non-libpfm4 events
In reply to Greg Kroah-HartmanFrom: German Gomez <[email protected]>
commit 3606c0e1a1050d397ad759a62607e419fd8b0ccb upstream.
A previous patch preventing "attr->sample_period" values from being overridden in pfm events changed a related behaviour in arm-spe.
Before said patch:
perf record -c 10000 -e arm_spe_0// -- sleep 1
Would yield an SPE event with period=10000. After the patch, the period in "-c 10000" was being ignored because the arm-spe code initializes sample_period to a non-zero value.
This patch restores the previous behaviour for non-libpfm4 events.
--- tools/perf/util/evsel.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-)
tools/perf/util/evsel.c +17 -8
@@ -1014,6 +1014,17 @@ struct evsel_config_term *__evsel__get_creturn found_term; } +static void evsel__set_default_freq_period (struct record_opts *opts, +struct perf_event_attr *attr) +{ +if (opts->freq) { + attr->freq =1 ; + attr->sample_freq = opts->freq; + }else { + attr->sample_period = opts->default_interval; + } +} +/* * The enable_on_exec/disabled value strategy: *
@@ -1080,14 +1091,12 @@ void evsel__config(struct evsel *evsel,* We default some events to have a default interval. But keep * it a weak assumption overridable by the user. */ -if (!attr->sample_period) { -if (opts->freq) { - attr->freq =1 ; - attr->sample_freq = opts->freq; - }else { - attr->sample_period = opts->default_interval; - } - } +if ((evsel->is_libpfm_event && !attr->sample_period) || + (!evsel->is_libpfm_event && (!attr->sample_period || + opts->user_freq !=UINT_MAX || + opts->user_interval !=ULLONG_MAX ))) +evsel__set_default_freq_period (opts, attr); +/* * If attr->freq was set (here or earlier), ask for period * to be sampled.
Greg Kroah-Hartman
maintainerPATCH 509/563 ipv4: update fib_info_cnt under spinlock protection
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit 0a6e6b3c7db6c34e3d149f09cd714972f8753e3f upstream.
In the past, free_fib_info() was supposed to be called under RTNL protection.
This eventually was no longer the case.
Instead of enforcing RTNL it seems we simply can move fib_info_cnt changes to occur when fib_info_lock is held.
v2: David Laight suggested to update fib_info_cnt only when an entry is added/deleted to/from the hash table, as fib_info_cnt is used to make sure hash table size is optimal.
BUG: KCSAN: data-race in fib_create_info / free_fib_info
write to 0xffffffff86e243a0 of 4 bytes by task 26429 on cpu 0:
fib_create_info+0xe78/0x3440 net/ipv4/fib_semantics.c:1428 fib_table_insert+0x148/0x10c0 net/ipv4/fib_trie.c:1224 fib_magic+0x195/0x1e0 net/ipv4/fib_frontend.c:1087 fib_add_ifaddr+0xd0/0x2e0 net/ipv4/fib_frontend.c:1109 fib_netdev_event+0x178/0x510 net/ipv4/fib_frontend.c:1466 notifier_call_chain kernel/notifier.c:83 [inline] raw_notifier_call_chain+0x53/0xb0 kernel/notifier.c:391 __dev_notify_flags+0x1d3/0x3b0 dev_change_flags+0xa2/0xc0 net/core/dev.c:8872 do_setlink+0x810/0x2410 net/core/rtnetlink.c:2719 rtnl_group_changelink net/core/rtnetlink.c:3242 [inline] __rtnl_newlink net/core/rtnetlink.c:3396 [inline] rtnl_newlink+0xb10/0x13b0 net/core/rtnetlink.c:3506 rtnetlink_rcv_msg+0x745/0x7e0 net/core/rtnetlink.c:5571 netlink_rcv_skb+0x14e/0x250 net/netlink/af_netlink.c:2496 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:5589 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x5fc/0x6c0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x726/0x840 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2409 ___sys_sendmsg net/socket.c:2463 [inline] __sys_sendmsg+0x195/0x230 net/socket.c:2492 __do_sys_sendmsg net/socket.c:2501 [inline] __se_sys_sendmsg net/socket.c:2499 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2499 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffffffff86e243a0 of 4 bytes by task 31505 on cpu 1:
free_fib_info+0x35/0x80 net/ipv4/fib_semantics.c:252 fib_info_put include/net/ip_fib.h:575 [inline] nsim_fib4_rt_destroy drivers/net/netdevsim/fib.c:294 [inline] nsim_fib4_rt_replace drivers/net/netdevsim/fib.c:403 [inline] nsim_fib4_rt_insert drivers/net/netdevsim/fib.c:431 [inline] nsim_fib4_event drivers/net/netdevsim/fib.c:461 [inline] nsim_fib_event drivers/net/netdevsim/fib.c:881 [inline] nsim_fib_event_work+0x15ca/0x2cf0 drivers/net/netdevsim/fib.c:1477 process_one_work+0x3fc/0x980 kernel/workqueue.c:2298 process_scheduled_works kernel/workqueue.c:2361 [inline] worker_thread+0x7df/0xa70 kernel/workqueue.c:2447 kthread+0x2c7/0x2e0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30
value changed: 0x00000d2d -> 0x00000d2e
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 31505 Comm: kworker/1:21 Not tainted 5.16.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events nsim_fib_event_work
--- net/ipv4/fib_semantics.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
net/ipv4/fib_semantics.c +8 -3
@@ -251,7 +251,6 @@ void free_fib_info(struct fib_info *fi)pr_warn ("Freeing alive fib_info %p\n" , fi);return ; } - fib_info_cnt--;call_rcu (&fi->rcu, free_fib_info_rcu); }
@@ -262,6 +261,10 @@ void fib_release_info(struct fib_info *fspin_lock_bh (&fib_info_lock);if (fi && --fi->fib_treeref ==0 ) {hlist_del (&fi->fib_hash); + +/* Paired with READ_ONCE() in fib_create_info(). */ +WRITE_ONCE (fib_info_cnt, fib_info_cnt -1 ); +if (fi->fib_prefsrc)hlist_del (&fi->fib_lhash);if (fi->nh) {
@@ -1431,7 +1434,9 @@ struct fib_info *fib_create_info(struct#endif err = -ENOBUFS ; -if (fib_info_cnt >= fib_info_hash_size) { + +/* Paired with WRITE_ONCE() in fib_release_info() */ +if (READ_ONCE (fib_info_cnt) >= fib_info_hash_size) {unsigned int new_size = fib_info_hash_size <<1 ;struct hlist_head *new_info_hash;struct hlist_head *new_laddrhash;
@@ -1463,7 +1468,6 @@ struct fib_info *fib_create_info(structreturn ERR_PTR (err); } - fib_info_cnt++; fi->fib_net = net; fi->fib_protocol = cfg->fc_protocol; fi->fib_scope = cfg->fc_scope;
@@ -1590,6 +1594,7 @@ link_it: fi->fib_treeref++;refcount_set (&fi->fib_clntref,1 );spin_lock_bh (&fib_info_lock); + fib_info_cnt++;hlist_add_head (&fi->fib_hash, &fib_info_hash[fib_info_hashfn (fi)]);if (fi->fib_prefsrc) {
Greg Kroah-Hartman
maintainerPATCH 510/563 ipv4: avoid quadratic behavior in netns dismantle
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit d07418afea8f1d9896aaf9dc5ae47ac4f45b220c upstream.
net/ipv4/fib_semantics.c uses an hash table of 256 slots, keyed by device ifindexes: fib_info_devhash[DEVINDEX_HASHSIZE]
Problem is that with network namespaces, devices tend to use the same ifindex.
lo device for instance has a fixed ifindex of one, for all network namespaces.
This means that hosts with thousands of netns spend a lot of time looking at some hash buckets with thousands of elements, notably at netns dismantle.
Simply add a per netns perturbation (net_hash_mix()) to spread elements more uniformely.
Also change fib_devindex_hashfn() to use more entropy.
--- net/ipv4/fib_semantics.c | 36 +++++++++++++++++------------------- 1 file changed, 17 insertions(+), 19 deletions(-)
net/ipv4/fib_semantics.c +17 -19
@@ -29,6 +29,7 @@#include <linux/init.h> #include <linux/slab.h> #include <linux/netlink.h> +#include <linux/hash.h> #include <net/arp.h> #include <net/ip.h>
@@ -321,11 +322,15 @@ static inline int nh_comp(struct fib_infstatic inline unsigned int fib_devindex_hashfn (unsigned int val) { -unsigned int mask =DEVINDEX_HASHSIZE -1 ; +return hash_32 (val,DEVINDEX_HASHBITS ); +} + +static struct hlist_head * +fib_info_devhash_bucket (const struct net_device *dev) +{ +u32 val =net_hash_mix (dev_net (dev)) ^ dev->ifindex; -return (val ^ - (val >>DEVINDEX_HASHBITS ) ^ - (val >> (DEVINDEX_HASHBITS *2 ))) & mask; +return &fib_info_devhash[fib_devindex_hashfn (val)]; } static unsigned int fib_info_hashfn_1(int init_val, u8 protocol, u8 scope,
@@ -435,12 +440,11 @@ int ip_fib_check_default(__be32 gw, stru {struct hlist_head *head;struct fib_nh *nh; -unsigned int hash;spin_lock (&fib_info_lock); - hash =fib_devindex_hashfn (dev->ifindex); - head = &fib_info_devhash[hash]; + head =fib_info_devhash_bucket (dev); +hlist_for_each_entry (nh, head, nh_hash) { if (nh->fib_nh_dev == dev && nh->fib_nh_gw4 == gw &&
@@ -1608,12 +1612,10 @@ link_it: }else {change_nexthops (fi) {struct hlist_head *head; -unsigned int hash;if (!nexthop_nh->fib_nh_dev)continue ; - hash =fib_devindex_hashfn (nexthop_nh->fib_nh_dev->ifindex); - head = &fib_info_devhash[hash]; + head =fib_info_devhash_bucket (nexthop_nh->fib_nh_dev);hlist_add_head (&nexthop_nh->nh_hash, head); } endfor_nexthops(fi) }
@@ -1963,8 +1965,7 @@ void fib_nhc_update_mtu(struct fib_nh_covoid fib_sync_mtu (struct net_device *dev,u32 orig_mtu) { -unsigned int hash =fib_devindex_hashfn (dev->ifindex); -struct hlist_head *head = &fib_info_devhash[hash]; +struct hlist_head *head =fib_info_devhash_bucket (dev);struct fib_nh *nh;hlist_for_each_entry (nh, head, nh_hash) {
@@ -1983,12 +1984,11 @@ void fib_sync_mtu(struct net_device *dev*/ int fib_sync_down_dev (struct net_device *dev,unsigned long event,bool force) { -int ret =0 ; -int scope =RT_SCOPE_NOWHERE ; +struct hlist_head *head =fib_info_devhash_bucket (dev);struct fib_info *prev_fi =NULL ; -unsigned int hash =fib_devindex_hashfn (dev->ifindex); -struct hlist_head *head = &fib_info_devhash[hash]; +int scope =RT_SCOPE_NOWHERE ;struct fib_nh *nh; +int ret =0 ;if (force) scope =-1 ;
@@ -2133,7 +2133,6 @@ out:int fib_sync_up (struct net_device *dev,unsigned char nh_flags) {struct fib_info *prev_fi; -unsigned int hash;struct hlist_head *head;struct fib_nh *nh;int ret;
@@ -2149,8 +2148,7 @@ int fib_sync_up(struct net_device *dev, } prev_fi =NULL ; - hash =fib_devindex_hashfn (dev->ifindex); - head = &fib_info_devhash[hash]; + head =fib_info_devhash_bucket (dev); ret =0 ;hlist_for_each_entry (nh, head, nh_hash) {
Greg Kroah-Hartman
maintainerPATCH 511/563 net/fsl: xgmac_mdio: Add workaround for erratum A-009885
In reply to Greg Kroah-HartmanFrom: Tobias Waldekranz <[email protected]>
commit 6198c722019774d38018457a8bfb9ba3ed8c931e upstream.
Once an MDIO read transaction is initiated, we must read back the data register within 16 MDC cycles after the transaction completes. Outside of this window, reads may return corrupt data.
Therefore, disable local interrupts in the critical section, to maximize the probability that we can satisfy this requirement.
--- drivers/net/ethernet/freescale/xgmac_mdio.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-)
drivers/net/ethernet/freescale/xgmac_mdio.c +19 -6
@@ -49,6 +49,7 @@ struct tgec_mdio_controller {struct mdio_fsl_priv {struct tgec_mdio_controller __iomem *mdio_base;bool is_little_endian; +bool has_a009885;bool has_a011043; };
@@ -184,10 +185,10 @@ static int xgmac_mdio_read(struct mii_bu {struct mdio_fsl_priv *priv = (struct mdio_fsl_priv *)bus->priv;struct tgec_mdio_controller __iomem *regs = priv->mdio_base; +unsigned long flags;uint16_t dev_addr;uint32_t mdio_stat;uint32_t mdio_ctl; -uint16_t value;int ret;bool endian = priv->is_little_endian;
@@ -219,12 +220,18 @@ static int xgmac_mdio_read(struct mii_bureturn ret; } +if (priv->has_a009885) +/* Once the operation completes, i.e. MDIO_STAT_BSY clears, we +* must read back the data register within 16 MDC cycles. +*/ +local_irq_save (flags); +/* Initiate the read */ xgmac_write32 (mdio_ctl |MDIO_CTL_READ , ®s->mdio_ctl, endian); ret =xgmac_wait_until_done (&bus->dev, regs, endian);if (ret) -return ret; + goto irq_restore;/* Return all Fs if nothing was there */ if ((xgmac_read32(®s->mdio_stat, endian) & MDIO_STAT_RD_ER) &&
@@ -232,13 +239,17 @@ static int xgmac_mdio_read(struct mii_budev_dbg (&bus->dev,"Error while reading PHY%d reg at %d.%hhu\n" , phy_id, dev_addr, regnum); -return 0xffff ; + ret =0xffff ; + }else { + ret =xgmac_read32 (®s->mdio_data, endian) &0xffff ; +dev_dbg (&bus->dev,"read %04x\n" , ret); } - value =xgmac_read32 (®s->mdio_data, endian) &0xffff ; -dev_dbg (&bus->dev,"read %04x\n" , value); +irq_restore: +if (priv->has_a009885) +local_irq_restore (flags); -return value; +return ret; }static int xgmac_mdio_probe (struct platform_device *pdev)
@@ -282,6 +293,8 @@ static int xgmac_mdio_probe(struct platf priv->is_little_endian =device_property_read_bool (&pdev->dev,"little-endian" ); + priv->has_a009885 =device_property_read_bool (&pdev->dev, +"fsl,erratum-a009885" ); priv->has_a011043 =device_property_read_bool (&pdev->dev,"fsl,erratum-a011043" );
Greg Kroah-Hartman
maintainerPATCH 512/563 net/fsl: xgmac_mdio: Fix incorrect iounmap when removing module
In reply to Greg Kroah-HartmanFrom: Tobias Waldekranz <[email protected]>
commit 3f7c239c7844d2044ed399399d97a5f1c6008e1b upstream.
As reported by sparse: In the remove path, the driver would attempt to unmap its own priv pointer - instead of the io memory that it mapped in probe.
--- drivers/net/ethernet/freescale/xgmac_mdio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/freescale/xgmac_mdio.c +2 -1
@@ -320,9 +320,10 @@ err_ioremap:static int xgmac_mdio_remove (struct platform_device *pdev) {struct mii_bus *bus =platform_get_drvdata (pdev); +struct mdio_fsl_priv *priv = bus->priv;mdiobus_unregister (bus); -iounmap (bus->priv); +iounmap (priv->mdio_base);mdiobus_free (bus);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 513/563 parisc: pdc_stable: Fix memory leak in pdcs_register_pathentries
In reply to Greg Kroah-HartmanFrom: Miaoqian Lin <[email protected]>
commit d24846a4246b6e61ecbd036880a4adf61681d241 upstream.
kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add():
If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.
Fix memory leak by calling kobject_put().
--- drivers/parisc/pdc_stable.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/parisc/pdc_stable.c +3 -1
@@ -979,8 +979,10 @@ pdcs_register_pathentries(void) entry->kobj.kset = paths_kset; err =kobject_init_and_add (&entry->kobj, &ktype_pdcspath,NULL ,"%s" , entry->name); -if (err) +if (err) { +kobject_put (&entry->kobj);return err; + }/* kobject is now registered */ write_lock (&entry->rw_lock);
Greg Kroah-Hartman
maintainerPATCH 514/563 f2fs: compress: fix potential deadlock of compress file
In reply to Greg Kroah-HartmanFrom: Hyeong-Jun Kim <[email protected]>
commit 7377e853967ba45bf409e3b5536624d2cbc99f21 upstream.
There is a potential deadlock between writeback process and a process performing write_begin() or write_cache_pages() while trying to write same compress file, but not compressable, as below:
[Process A] - doing checkpoint
[Process B] [Process C]f2fs_write_cache_pages()
- lock_page() [all pages in cluster, 0-31]
- f2fs_write_multi_pages()
- f2fs_write_raw_pages()
- f2fs_write_single_data_page()
- f2fs_do_write_data_page()
- return -EAGAIN [f2fs_trylock_op() failed]
- unlock_page(page) [e.g., page 0]
- generic_perform_write()
- f2fs_write_begin()
- f2fs_prepare_compress_overwrite()
- prepare_compress_overwrite()
- lock_page() [e.g., page 0]
- lock_page() [e.g., page 1]
- lock_page(page) [e.g., page 0]
Since there is no compress process, it is no longer necessary to hold locks on every pages in cluster within f2fs_write_raw_pages().
This patch changes f2fs_write_raw_pages() to release all locks first and then perform write same as the non-compress file in f2fs_write_cache_pages().
--- fs/f2fs/compress.c | 50 ++++++++++++++++++++++---------------------------- 1 file changed, 22 insertions(+), 28 deletions(-)
fs/f2fs/compress.c +22 -28
@@ -1362,25 +1362,38 @@ static int f2fs_write_raw_pages(struct c enum iostat_type io_type) {struct address_space *mapping = cc->inode->i_mapping; -int _submitted, compr_blocks, ret; -int i =-1 , err =0 ; +int _submitted, compr_blocks, ret, i; compr_blocks =f2fs_compressed_blocks (cc); -if (compr_blocks <0 ) { - err = compr_blocks; - goto out_err; + +for (i =0 ; i < cc->cluster_size; i++) { +if (!cc->rpages[i]) +continue ; + +redirty_page_for_writepage (wbc, cc->rpages[i]); +unlock_page (cc->rpages[i]); } +if (compr_blocks <0 ) +return compr_blocks; +for (i =0 ; i < cc->cluster_size; i++) {if (!cc->rpages[i])continue ; retry_write: +lock_page (cc->rpages[i]); +if (cc->rpages[i]->mapping != mapping) { +continue_unlock:unlock_page (cc->rpages[i]);continue ; } -BUG_ON (!PageLocked (cc->rpages[i])); +if (!PageDirty (cc->rpages[i])) + goto continue_unlock; + +if (!clear_page_dirty_for_io (cc->rpages[i])) + goto continue_unlock; ret = f2fs_write_single_data_page(cc->rpages[i], &_submitted, NULL, NULL, wbc, io_type,
@@ -1395,26 +1408,15 @@ retry_write:* avoid deadlock caused by cluster update race * from foreground operation. */ -if (IS_NOQUOTA (cc->inode)) { - err =0 ; - goto out_err; - } +if (IS_NOQUOTA (cc->inode)) +return 0 ; ret =0 ;cond_resched ();congestion_wait (BLK_RW_ASYNC ,DEFAULT_IO_TIMEOUT ); -lock_page (cc->rpages[i]); - -if (!PageDirty (cc->rpages[i])) { -unlock_page (cc->rpages[i]); -continue ; - } - -clear_page_dirty_for_io (cc->rpages[i]); goto retry_write; } - err = ret; - goto out_err; +return ret; } *submitted += _submitted;
@@ -1423,14 +1425,6 @@ retry_write:f2fs_balance_fs (F2FS_M_SB (mapping), true);return 0 ; -out_err: -for (++i; i < cc->cluster_size; i++) { -if (!cc->rpages[i]) -continue ; -redirty_page_for_writepage (wbc, cc->rpages[i]); -unlock_page (cc->rpages[i]); - } -return err; } int f2fs_write_multi_pages(struct compress_ctx *cc,
Greg Kroah-Hartman
maintainerPATCH 515/563 f2fs: fix to reserve space for IO align feature
In reply to Greg Kroah-HartmanFrom: Chao Yu <[email protected]>
commit 300a842937fbcfb5a189cea9ba15374fdb0b5c6b upstream.
https://bugzilla.kernel.org/show_bug.cgi?id=204137
With below script, we will hit panic during new segment allocation:
DISK=bingo.img
MOUNT_DIR=/mnt/f2fs
dd if=/dev/zero of=$DISK bs=1M count=105
mkfs.f2fe -a 1 -o 19 -t 1 -z 1 -f -q $DISK
mount -t f2fs $DISK $MOUNT_DIR -o "noinline_dentry,flush_merge,noextent_cache,mode=lfs,io_bits=7,fsync_mode=strict"
for (( i = 0; i < 4096; i++ )); do
name=`head /dev/urandom | tr -dc A-Za-z0-9 | head -c 10` mkdir $MOUNT_DIR/$name
done
umount $MOUNT_DIR
rm $DISK
--- fs/f2fs/f2fs.h | 11 +++++++++++ fs/f2fs/segment.h | 3 ++- fs/f2fs/super.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ fs/f2fs/sysfs.c | 4 +++- 4 files changed, 60 insertions(+), 2 deletions(-)
fs/f2fs/f2fs.h +11 -0
@@ -955,6 +955,7 @@ struct f2fs_sm_info {unsigned int segment_count;/* total # of segments */ unsigned int main_segments;/* # of segments in main area */ unsigned int reserved_segments;/* # of reserved segments */ +unsigned int additional_reserved_segments;/* reserved segs for IO align feature */ unsigned int ovp_segments;/* # of overprovision segments */ /* a threshold to reclaim prefree segments */
@@ -1984,6 +1985,11 @@ static inline int inc_valid_block_count(if (!__allow_reserved_blocks (sbi, inode, true)) avail_user_block_count -=F2FS_OPTION (sbi).root_reserved_blocks; + +if (F2FS_IO_ALIGNED (sbi)) + avail_user_block_count -= sbi->blocks_per_seg * +SM_I (sbi)->additional_reserved_segments; +if (unlikely (is_sbi_flag_set (sbi,SBI_CP_DISABLED ))) {if (avail_user_block_count > sbi->unusable_block_count) avail_user_block_count -= sbi->unusable_block_count;
@@ -2229,6 +2235,11 @@ static inline int inc_valid_node_count(sif (!__allow_reserved_blocks (sbi, inode, false)) valid_block_count +=F2FS_OPTION (sbi).root_reserved_blocks; + +if (F2FS_IO_ALIGNED (sbi)) + valid_block_count += sbi->blocks_per_seg * +SM_I (sbi)->additional_reserved_segments; + user_block_count = sbi->user_block_count;if (unlikely (is_sbi_flag_set (sbi,SBI_CP_DISABLED ))) user_block_count -= sbi->unusable_block_count;
fs/f2fs/segment.h +2 -1
@@ -539,7 +539,8 @@ static inline unsigned int free_segmentsstatic inline unsigned int reserved_segments (struct f2fs_sb_info *sbi) { -return SM_I (sbi)->reserved_segments; +return SM_I (sbi)->reserved_segments + +SM_I (sbi)->additional_reserved_segments; }static inline unsigned int free_sections (struct f2fs_sb_info *sbi)
fs/f2fs/super.c +44 -0
56 lines not on this page · raw message
fs/f2fs/sysfs.c +3 -1
@@ -330,7 +330,9 @@ out:if (a->struct_type ==RESERVED_BLOCKS ) {spin_lock (&sbi->stat_lock);if (t > (unsigned long )(sbi->user_block_count - -F2FS_OPTION (sbi).root_reserved_blocks)) { +F2FS_OPTION (sbi).root_reserved_blocks - + sbi->blocks_per_seg * +SM_I (sbi)->additional_reserved_segments)) {spin_unlock (&sbi->stat_lock);return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 516/563 af_unix: annote lockless accesses to unix_tot_inflight & gc_in_progress
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit 9d6d7f1cb67cdee15f1a0e85aacfb924e0e02435 upstream.
wait_for_unix_gc() reads unix_tot_inflight & gc_in_progress without synchronization.
Adds READ_ONCE()/WRITE_ONCE() and their associated comments to better document the intent.
BUG: KCSAN: data-race in unix_inflight / wait_for_unix_gc
write to 0xffffffff86e2b7c0 of 4 bytes by task 9380 on cpu 0:
unix_inflight+0x1e8/0x260 net/unix/scm.c:63 unix_attach_fds+0x10c/0x1e0 net/unix/scm.c:121 unix_scm_to_skb net/unix/af_unix.c:1674 [inline] unix_dgram_sendmsg+0x679/0x16b0 net/unix/af_unix.c:1817 unix_seqpacket_sendmsg+0xcc/0x110 net/unix/af_unix.c:2258 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2409 ___sys_sendmsg net/socket.c:2463 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2549 __do_sys_sendmmsg net/socket.c:2578 [inline] __se_sys_sendmmsg net/socket.c:2575 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2575 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffffffff86e2b7c0 of 4 bytes by task 9375 on cpu 1:
wait_for_unix_gc+0x24/0x160 net/unix/garbage.c:196 unix_dgram_sendmsg+0x8e/0x16b0 net/unix/af_unix.c:1772 unix_seqpacket_sendmsg+0xcc/0x110 net/unix/af_unix.c:2258 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2409 ___sys_sendmsg net/socket.c:2463 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2549 __do_sys_sendmmsg net/socket.c:2578 [inline] __se_sys_sendmmsg net/socket.c:2575 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2575 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0x00000002 -> 0x00000004
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 9375 Comm: syz-executor.1 Not tainted 5.16.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
--- net/unix/garbage.c | 14 +++++++++++--- net/unix/scm.c | 6 ++++-- 2 files changed, 15 insertions(+), 5 deletions(-)
net/unix/garbage.c +11 -3
@@ -192,8 +192,11 @@ void wait_for_unix_gc(void) {/* If number of inflight sockets is insane, * force a garbage collect right now. +* Paired with the WRITE_ONCE() in unix_inflight(), +* unix_notinflight() and gc_in_progress(). */ -if (unix_tot_inflight >UNIX_INFLIGHT_TRIGGER_GC && !gc_in_progress) +if (READ_ONCE (unix_tot_inflight) >UNIX_INFLIGHT_TRIGGER_GC && + !READ_ONCE (gc_in_progress))unix_gc ();wait_event (unix_gc_wait, gc_in_progress == false); }
@@ -213,7 +216,9 @@ void unix_gc(void)if (gc_in_progress) goto out; - gc_in_progress = true; +/* Paired with READ_ONCE() in wait_for_unix_gc(). */ +WRITE_ONCE (gc_in_progress, true); +/* First, select candidates for garbage collection. Only * in-flight sockets are considered, and from those only ones * which don't have any external reference.
@@ -299,7 +304,10 @@ void unix_gc(void)/* All candidates should have been detached by now. */ BUG_ON (!list_empty (&gc_candidates)); - gc_in_progress = false; + +/* Paired with READ_ONCE() in wait_for_unix_gc(). */ +WRITE_ONCE (gc_in_progress, false); +wake_up (&unix_gc_wait); out:
net/unix/scm.c +4 -2
@@ -60,7 +60,8 @@ void unix_inflight(struct user_struct *u }else {BUG_ON (list_empty (&u->link)); } - unix_tot_inflight++; +/* Paired with READ_ONCE() in wait_for_unix_gc() */ +WRITE_ONCE (unix_tot_inflight, unix_tot_inflight +1 ); } user->unix_inflight++;spin_unlock (&unix_gc_lock);
@@ -80,7 +81,8 @@ void unix_notinflight(struct user_structif (atomic_long_dec_and_test (&u->inflight))list_del_init (&u->link); - unix_tot_inflight--; +/* Paired with READ_ONCE() in wait_for_unix_gc() */ +WRITE_ONCE (unix_tot_inflight, unix_tot_inflight -1 ); } user->unix_inflight--;spin_unlock (&unix_gc_lock);
Greg Kroah-Hartman
maintainerPATCH 517/563 clk: Emit a stern warning with writable debugfs enabled
In reply to Greg Kroah-HartmanFrom: Stephen Boyd <[email protected]>
commit 489a71964f9d74e697a12cd0ace20ed829eb1f93 upstream.
We don't want vendors to be enabling this part of the clk code and shipping it to customers. Exposing the ability to change clk frequencies and parents via debugfs is potentially damaging to the system if folks don't know what they're doing. Emit a strong warning so that the message is clear: don't enable this outside of development systems.
--- drivers/clk/clk.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
drivers/clk/clk.c +18 -0
@@ -3314,6 +3314,24 @@ static int __init clk_debug_init(void) {struct clk_core *core; +#ifdef CLOCK_ALLOW_WRITE_DEBUGFS +pr_warn ("\n" ); +pr_warn ("********************************************************************\n" ); +pr_warn ("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n" ); +pr_warn ("** **\n" ); +pr_warn ("** WRITEABLE clk DebugFS SUPPORT HAS BEEN ENABLED IN THIS KERNEL **\n" ); +pr_warn ("** **\n" ); +pr_warn ("** This means that this kernel is built to expose clk operations **\n" ); +pr_warn ("** such as parent or rate setting, enabling, disabling, etc. **\n" ); +pr_warn ("** to userspace, which may compromise security on your system. **\n" ); +pr_warn ("** **\n" ); +pr_warn ("** If you see this message and you are not debugging the **\n" ); +pr_warn ("** kernel, report this immediately to your vendor! **\n" ); +pr_warn ("** **\n" ); +pr_warn ("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n" ); +pr_warn ("********************************************************************\n" ); +#endif + rootdir =debugfs_create_dir ("clk" ,NULL ); debugfs_create_file("clk_summary", 0444, rootdir, &all_lists,
Greg Kroah-Hartman
maintainerPATCH 518/563 clk: si5341: Fix clock HW provider cleanup
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit 49a8f2bc8d88702783c7e163ec84374e9a022f71 upstream.
The call to of_clk_add_hw_provider was not undone on remove or on probe failure, which could cause an oops on a subsequent attempt to retrieve clocks for the removed device. Switch to the devm version of the function to avoid this issue.
--- drivers/clk/clk-si5341.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/clk-si5341.c +1 -1
@@ -1576,7 +1576,7 @@ static int si5341_probe(struct i2c_clienclk_prepare (data->clk[i].hw.clk); } - err =of_clk_add_hw_provider (client->dev.of_node, of_clk_si5341_get, + err =devm_of_clk_add_hw_provider (&client->dev, of_clk_si5341_get, data);if (err) {dev_err (&client->dev,"unable to add clk provider\n" );
Greg Kroah-Hartman
maintainerPATCH 519/563 net/smc: Fix hung_task when removing SMC-R devices
In reply to Greg Kroah-HartmanFrom: Wen Gu <[email protected]>
commit 56d99e81ecbc997a5f984684d0eeb583992b2072 upstream.
A hung_task is observed when removing SMC-R devices. Suppose that a link group has two active links(lnk_A, lnk_B) associated with two different SMC-R devices(dev_A, dev_B). When dev_A is removed, the link group will be removed from smc_lgr_list and added into lgr_linkdown_list. lnk_A will be cleared and smcibdev(A)->lnk_cnt will reach to zero. However, when dev_B is removed then, the link group can't be found in smc_lgr_list and lnk_B won't be cleared, making smcibdev->lnk_cnt never reaches zero, which causes a hung_task.
This patch fixes this issue by restoring the implementation of smc_smcr_terminate_all() to what it was before commit 349d43127dac ("net/smc: fix kernel panic caused by race of smc_sock"). The original implementation also satisfies the intention that make sure QP destroy earlier than CQ destroy because we will always wait for smcibdev->lnk_cnt reaches zero, which guarantees QP has been destroyed.
--- net/smc/smc_core.c | 17 +---------------- 1 file changed, 1 insertion(+), 16 deletions(-)
net/smc/smc_core.c +1 -16
@@ -1002,16 +1002,11 @@ void smc_smcd_terminate_all(struct smcd_/* Called when an SMCR device is removed or the smc module is unloaded. * If smcibdev is given, all SMCR link groups using this device are terminated. * If smcibdev is NULL, all SMCR link groups are terminated. -* -* We must wait here for QPs been destroyed before we destroy the CQs, -* or we won't received any CQEs and cdc_pend_tx_wr cannot reach 0 thus -* smc_sock cannot be released. */ void smc_smcr_terminate_all (struct smc_ib_device *smcibdev) {struct smc_link_group *lgr, *lg;LIST_HEAD (lgr_free_list); -LIST_HEAD (lgr_linkdown_list);int i;spin_lock_bh (&smc_lgr_list.lock);
@@ -1023,7 +1018,7 @@ void smc_smcr_terminate_all(struct smc_ilist_for_each_entry_safe (lgr, lg, &smc_lgr_list.list, list) {for (i =0 ; i <SMC_LINKS_PER_LGR_MAX ; i++) {if (lgr->lnk[i].smcibdev == smcibdev) -list_move_tail (&lgr->list, &lgr_linkdown_list); +smcr_link_down_cond_sched (&lgr->lnk[i]); } } }
@@ -1035,16 +1030,6 @@ void smc_smcr_terminate_all(struct smc_i__smc_lgr_terminate (lgr, false); } -list_for_each_entry_safe (lgr, lg, &lgr_linkdown_list, list) { -for (i =0 ; i <SMC_LINKS_PER_LGR_MAX ; i++) { -if (lgr->lnk[i].smcibdev == smcibdev) { -mutex_lock (&lgr->llc_conf_mutex); -smcr_link_down_cond (&lgr->lnk[i]); -mutex_unlock (&lgr->llc_conf_mutex); - } - } - } -if (smcibdev) {if (atomic_read (&smcibdev->lnk_cnt)) wait_event(smcibdev->lnks_deleted,
Greg Kroah-Hartman
maintainerPATCH 520/563 net: axienet: increase reset timeout
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit 2e5644b1bab2ccea9cfc7a9520af95b94eb0dbf1 upstream.
The previous timeout of 1ms was too short to handle some cases where the core is reset just after the input clocks were started, which will be introduced in an upcoming patch. Increase the timeout to 50ms. Also simplify the reset timeout checking to use read_poll_timeout.
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +9 -10
@@ -496,7 +496,8 @@ static void axienet_setoptions(struct nestatic int __axienet_device_reset (struct axienet_local *lp) { -u32 timeout; +u32 value; +int ret;/* Reset Axi DMA. This would reset Axi Ethernet core as well. The reset * process of Axi DMA takes a while to complete as all pending
@@ -506,15 +507,13 @@ static int __axienet_device_reset(struct* they both reset the entire DMA core, so only one needs to be used. */ axienet_dma_out32 (lp,XAXIDMA_TX_CR_OFFSET ,XAXIDMA_CR_RESET_MASK ); - timeout =DELAY_OF_ONE_MILLISEC ; -while (axienet_dma_in32 (lp,XAXIDMA_TX_CR_OFFSET ) & -XAXIDMA_CR_RESET_MASK ) { -udelay (1 ); -if (--timeout ==0 ) { -netdev_err (lp->ndev,"%s: DMA reset timeout!\n" , - __func__); -return -ETIMEDOUT ; - } + ret =read_poll_timeout (axienet_dma_in32, value, + !(value &XAXIDMA_CR_RESET_MASK ), +DELAY_OF_ONE_MILLISEC ,50000 , false, lp, +XAXIDMA_TX_CR_OFFSET ); +if (ret) { +dev_err (lp->dev,"%s: DMA reset timeout!\n" , __func__); +return ret; }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 521/563 net: axienet: Wait for PhyRstCmplt after core reset
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit b400c2f4f4c53c86594dd57098970d97d488bfde upstream.
When resetting the device, wait for the PhyRstCmplt bit to be set in the interrupt status register before continuing initialization, to ensure that the core is actually ready. When using an external PHY, this also ensures we do not start trying to access the PHY while it is still in reset. The PHY reset is initiated by the core reset which is triggered just above, but remains asserted for 5ms after the core is reset according to the documentation.
The MgtRdy bit could also be waited for, but unfortunately when using 7-series devices, the bit does not appear to work as documented (it seems to behave as some sort of link state indication and not just an indication the transceiver is ready) so it can't really be relied on for this purpose.
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +10 -0
@@ -516,6 +516,16 @@ static int __axienet_device_reset(structreturn ret; } +/* Wait for PhyRstCmplt bit to be set, indicating the PHY reset has finished */ + ret =read_poll_timeout (axienet_ior, value, + value &XAE_INT_PHYRSTCMPLT_MASK , +DELAY_OF_ONE_MILLISEC ,50000 , false, lp, +XAE_IS_OFFSET ); +if (ret) { +dev_err (lp->dev,"%s: timeout waiting for PhyRstCmplt\n" , __func__); +return ret; + } +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 522/563 net: axienet: reset core on initialization prior to MDIO access
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit 04cc2da39698efd7eb2e30c112538922d26f848e upstream.
In some cases where the Xilinx Ethernet core was used in 1000Base-X or SGMII modes, which use the internal PCS/PMA PHY, and the MGT transceiver clock source for the PCS was not running at the time the FPGA logic was loaded, the core would come up in a state where the PCS could not be found on the MDIO bus. To fix this, the Ethernet core (including the PCS) should be reset after enabling the clocks, prior to attempting to access the PCS using of_mdio_find_device.
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +5 -0
@@ -2024,6 +2024,11 @@ static int axienet_probe(struct platform lp->coalesce_count_rx =XAXIDMA_DFT_RX_THRESHOLD ; lp->coalesce_count_tx =XAXIDMA_DFT_TX_THRESHOLD ; +/* Reset core now that clocks are enabled, prior to accessing MDIO */ + ret =__axienet_device_reset (lp); +if (ret) + goto cleanup_clk; + lp->phy_node =of_parse_phandle (pdev->dev.of_node,"phy-handle" ,0 );if (lp->phy_node) { ret =axienet_mdio_setup (lp);
Greg Kroah-Hartman
maintainerPATCH 523/563 net: axienet: add missing memory barriers
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit 95978df6fa328df619c15312e65ece469c2be2d2 upstream.
This driver was missing some required memory barriers:
Use dma_rmb to ensure we see all updates to the descriptor after we see that an entry has been completed.
Use wmb and rmb to avoid stale descriptor status between the TX path and TX complete IRQ path.
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +10 -1
@@ -632,6 +632,8 @@ static int axienet_free_tx_chain(structif (nr_bds ==-1 && !(status &XAXIDMA_BD_STS_COMPLETE_MASK ))break ; +/* Ensure we see complete descriptor update */ +dma_rmb (); phys =desc_get_phys_addr (lp, cur_p); dma_unmap_single(ndev->dev.parent, phys, (cur_p->cntrl & XAXIDMA_BD_CTRL_LENGTH_MASK),
@@ -645,8 +647,10 @@ static int axienet_free_tx_chain(struct cur_p->app1 =0 ; cur_p->app2 =0 ; cur_p->app4 =0 ; - cur_p->status =0 ; cur_p->skb =NULL ; +/* ensure our transmit path and device don't prematurely see status cleared */ +wmb (); + cur_p->status =0 ;if (sizep) *sizep += status &XAXIDMA_BD_STS_ACTUAL_LEN_MASK ;
@@ -704,6 +708,9 @@ static inline int axienet_check_tx_bd_sp int num_frag) {struct axidma_bd *cur_p; + +/* Ensure we see all descriptor updates from device or TX IRQ path */ +rmb (); cur_p = &lp->tx_bd_v[(lp->tx_bd_tail + num_frag) % lp->tx_bd_num];if (cur_p->status &XAXIDMA_BD_STS_ALL_MASK )return NETDEV_TX_BUSY ;
@@ -843,6 +850,8 @@ static void axienet_recv(struct net_devi tail_p = lp->rx_bd_p +sizeof (*lp->rx_bd_v) * lp->rx_bd_ci; +/* Ensure we see complete descriptor update */ +dma_rmb (); phys =desc_get_phys_addr (lp, cur_p);dma_unmap_single (ndev->dev.parent, phys, lp->max_frm_size,DMA_FROM_DEVICE );
Greg Kroah-Hartman
maintainerPATCH 524/563 net: axienet: limit minimum TX ring size
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit 70f5817deddbc6ef3faa35841cab83c280cc653a upstream.
The driver will not work properly if the TX ring size is set to below MAX_SKB_FRAGS + 1 since it needs to hold at least one full maximally fragmented packet in the TX ring. Limit setting the ring size to below this value.
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +3 -1
@@ -43,6 +43,7 @@/* Descriptors defines for Tx and Rx DMA */ #define TX_BD_NUM_DEFAULT 64#define RX_BD_NUM_DEFAULT 1024 +#define TX_BD_NUM_MIN (MAX_SKB_FRAGS + 1)#define TX_BD_NUM_MAX 4096#define RX_BD_NUM_MAX 4096
@@ -1373,7 +1374,8 @@ static int axienet_ethtools_set_ringparaif (ering->rx_pending >RX_BD_NUM_MAX || ering->rx_mini_pending || ering->rx_jumbo_pending || - ering->rx_pending >TX_BD_NUM_MAX ) + ering->tx_pending <TX_BD_NUM_MIN || + ering->tx_pending >TX_BD_NUM_MAX )return -EINVAL ;if (netif_running (ndev))
Greg Kroah-Hartman
maintainerPATCH 525/563 net: axienet: Fix TX ring slot available check
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit 996defd7f8b5dafc1d480b7585c7c62437f80c3c upstream.
The check for whether a TX ring slot was available was incorrect, since a slot which had been loaded with transmit data but the device had not started transmitting would be treated as available, potentially causing non-transmitted slots to be overwritten. The control field in the descriptor should be checked, rather than the status field (which may only be updated when the device completes the entry).
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +2 -2
@@ -643,7 +643,6 @@ static int axienet_free_tx_chain(structif (cur_p->skb && (status &XAXIDMA_BD_STS_COMPLETE_MASK ))dev_consume_skb_irq (cur_p->skb); - cur_p->cntrl =0 ; cur_p->app0 =0 ; cur_p->app1 =0 ; cur_p->app2 =0 ;
@@ -651,6 +650,7 @@ static int axienet_free_tx_chain(struct cur_p->skb =NULL ;/* ensure our transmit path and device don't prematurely see status cleared */ wmb (); + cur_p->cntrl =0 ; cur_p->status =0 ;if (sizep)
@@ -713,7 +713,7 @@ static inline int axienet_check_tx_bd_sp/* Ensure we see all descriptor updates from device or TX IRQ path */ rmb (); cur_p = &lp->tx_bd_v[(lp->tx_bd_tail + num_frag) % lp->tx_bd_num]; -if (cur_p->status &XAXIDMA_BD_STS_ALL_MASK ) +if (cur_p->cntrl)return NETDEV_TX_BUSY ;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 526/563 net: axienet: fix number of TX ring slots for available check
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit aba57a823d2985a2cc8c74a2535f3a88e68d9424 upstream.
The check for the number of available TX ring slots was off by 1 since a slot is required for the skb header as well as each fragment. This could result in overwriting a TX ring slot that was still in use.
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +2 -2
@@ -747,7 +747,7 @@ axienet_start_xmit(struct sk_buff *skb, num_frag =skb_shinfo (skb)->nr_frags; cur_p = &lp->tx_bd_v[lp->tx_bd_tail]; -if (axienet_check_tx_bd_space (lp, num_frag)) { +if (axienet_check_tx_bd_space (lp, num_frag +1 )) {if (netif_queue_stopped (ndev))return NETDEV_TX_BUSY ;
@@ -757,7 +757,7 @@ axienet_start_xmit(struct sk_buff *skb,smp_mb ();/* Space might have just been freed - check again */ -if (axienet_check_tx_bd_space (lp, num_frag)) +if (axienet_check_tx_bd_space (lp, num_frag +1 ))return NETDEV_TX_BUSY ;netif_wake_queue (ndev);
Greg Kroah-Hartman
maintainerPATCH 527/563 net: axienet: fix for TX busy handling
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit bb193e3db8b86a63f26889c99e14fd30c9ebd72a upstream.
Network driver documentation indicates we should be avoiding returning NETDEV_TX_BUSY from ndo_start_xmit in normal cases, since it requires the packets to be requeued. Instead the queue should be stopped after a packet is added to the TX ring when there may not be enough room for an additional one. Also, when TX ring entries are completed, we should only wake the queue if we know there is room for another full maximally fragmented packet.
Print a warning if there is insufficient space at the start of start_xmit, since this should no longer happen.
Combined with increasing the default TX ring size (in a subsequent patch), this appears to recover the TX performance lost by previous changes to actually manage the TX ring state properly.
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 86 ++++++++++++---------- 1 file changed, 47 insertions(+), 39 deletions(-)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +47 -39
@@ -661,6 +661,32 @@ static int axienet_free_tx_chain(struct }/** +* axienet_check_tx_bd_space - Checks if a BD/group of BDs are currently busy +* @lp: Pointer to the axienet_local structure +* @num_frag: The number of BDs to check for +* +* Return: 0, on success +* NETDEV_TX_BUSY, if any of the descriptors are not free +* +* This function is invoked before BDs are allocated and transmission starts. +* This function returns 0 if a BD or group of BDs can be allocated for +* transmission. If the BD or any of the BDs are not free the function +* returns a busy status. This is invoked from axienet_start_xmit. +*/ +static inline int axienet_check_tx_bd_space (struct axienet_local *lp, +int num_frag) +{ +struct axidma_bd *cur_p; + +/* Ensure we see all descriptor updates from device or TX IRQ path */ +rmb (); + cur_p = &lp->tx_bd_v[(lp->tx_bd_tail + num_frag) % lp->tx_bd_num]; +if (cur_p->cntrl) +return NETDEV_TX_BUSY ; +return 0 ; +} + +/** * axienet_start_xmit_done - Invoked once a transmit is completed by the * Axi DMA Tx channel. * @ndev: Pointer to the net_device structure
@@ -689,33 +715,8 @@ static void axienet_start_xmit_done(stru/* Matches barrier in axienet_start_xmit */ smp_mb (); -netif_wake_queue (ndev); -} - -/** -* axienet_check_tx_bd_space - Checks if a BD/group of BDs are currently busy -* @lp: Pointer to the axienet_local structure -* @num_frag: The number of BDs to check for -* -* Return: 0, on success -* NETDEV_TX_BUSY, if any of the descriptors are not free -* -* This function is invoked before BDs are allocated and transmission starts. -* This function returns 0 if a BD or group of BDs can be allocated for -* transmission. If the BD or any of the BDs are not free the function -* returns a busy status. This is invoked from axienet_start_xmit. -*/ -static inline int axienet_check_tx_bd_space (struct axienet_local *lp, -int num_frag) -{ -struct axidma_bd *cur_p; - -/* Ensure we see all descriptor updates from device or TX IRQ path */ -rmb (); - cur_p = &lp->tx_bd_v[(lp->tx_bd_tail + num_frag) % lp->tx_bd_num]; -if (cur_p->cntrl) -return NETDEV_TX_BUSY ; -return 0 ; +if (!axienet_check_tx_bd_space (lp,MAX_SKB_FRAGS +1 )) +netif_wake_queue (ndev); }/**
@@ -748,19 +749,14 @@ axienet_start_xmit(struct sk_buff *skb, cur_p = &lp->tx_bd_v[lp->tx_bd_tail];if (axienet_check_tx_bd_space (lp, num_frag +1 )) { -if (netif_queue_stopped (ndev)) -return NETDEV_TX_BUSY ; - +/* Should not happen as last start_xmit call should have +* checked for sufficient space and queue should only be +* woken when sufficient space is available. +*/ netif_stop_queue (ndev); - -/* Matches barrier in axienet_start_xmit_done */ -smp_mb (); - -/* Space might have just been freed - check again */ -if (axienet_check_tx_bd_space (lp, num_frag +1 )) -return NETDEV_TX_BUSY ; - -netif_wake_queue (ndev); +if (net_ratelimit ()) +netdev_warn (ndev,"TX ring unexpectedly full\n" ); +return NETDEV_TX_BUSY ; }if (skb->ip_summed ==CHECKSUM_PARTIAL ) {
@@ -821,6 +817,18 @@ axienet_start_xmit(struct sk_buff *skb,if (++lp->tx_bd_tail >= lp->tx_bd_num) lp->tx_bd_tail =0 ; +/* Stop queue if next transmit may not have space */ +if (axienet_check_tx_bd_space (lp,MAX_SKB_FRAGS +1 )) { +netif_stop_queue (ndev); + +/* Matches barrier in axienet_start_xmit_done */ +smp_mb (); + +/* Space might have just been freed - check again */ +if (!axienet_check_tx_bd_space (lp,MAX_SKB_FRAGS +1 )) +netif_wake_queue (ndev); + } +return NETDEV_TX_OK ; }
Greg Kroah-Hartman
maintainerPATCH 528/563 net: axienet: increase default TX ring size to 128
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit 2d19c3fd80178160dd505ccd7fed1643831227a5 upstream.
With previous changes to make the driver handle the TX ring size more correctly, the default TX ring size of 64 appears to significantly bottleneck TX performance to around 600 Mbps on a 1 Gbps link on ZynqMP. Increasing this to 128 seems to bring performance up to near line rate and shouldn't cause excess bufferbloat (this driver doesn't yet support modern byte-based queue management).
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +1 -1
@@ -41,7 +41,7 @@#include "xilinx_axienet.h" /* Descriptors defines for Tx and Rx DMA */ -#define TX_BD_NUM_DEFAULT 64 +#define TX_BD_NUM_DEFAULT 128#define RX_BD_NUM_DEFAULT 1024#define TX_BD_NUM_MIN (MAX_SKB_FRAGS + 1)#define TX_BD_NUM_MAX 4096
Greg Kroah-Hartman
maintainerPATCH 529/563 HID: vivaldi: fix handling devices not using numbered reports
In reply to Greg Kroah-HartmanFrom: Dmitry Torokhov <[email protected]>
commit 3fe6acd4dc922237b30e55473c9349c6ce0690f3 upstream.
Unfortunately details of USB HID transport bled into HID core and handling of numbered/unnumbered reports is quite a mess, with hid_report_len() calculating the length according to USB rules, and hid_hw_raw_request() adding report ID to the buffer for both numbered and unnumbered reports.
Untangling it all requres a lot of changes in HID, so for now let's handle this in the driver.
--- drivers/hid/hid-vivaldi.c | 34 ++++++++++++++++++++++++++++------ 1 file changed, 28 insertions(+), 6 deletions(-)
drivers/hid/hid-vivaldi.c +28 -6
@@ -74,10 +74,11 @@ static void vivaldi_feature_mapping(stru struct hid_usage *usage) {struct vivaldi_data *drvdata =hid_get_drvdata (hdev); +struct hid_report *report = field->report;int fn_key;int ret;u32 report_len; -u8 *buf; +u8 *report_data, *buf;if (field->logical !=HID_USAGE_FN_ROW_PHYSMAP || (usage->hid &HID_USAGE_PAGE ) !=HID_UP_ORDINAL )
@@ -89,12 +90,24 @@ static void vivaldi_feature_mapping(struif (fn_key > drvdata->max_function_row_key) drvdata->max_function_row_key = fn_key; - buf =hid_alloc_report_buf (field->report,GFP_KERNEL ); -if (!buf) + report_data = buf =hid_alloc_report_buf (report,GFP_KERNEL ); +if (!report_data)return ; - report_len =hid_report_len (field->report); - ret =hid_hw_raw_request (hdev, field->report->id, buf, + report_len =hid_report_len (report); +if (!report->id) { +/* +* hid_hw_raw_request() will stuff report ID (which will be 0) +* into the first byte of the buffer even for unnumbered +* reports, so we need to account for this to avoid getting +* -EOVERFLOW in return. +* Note that hid_alloc_report_buf() adds 7 bytes to the size +* so we can safely say that we have space for an extra byte. +*/ + report_len++; + } + + ret =hid_hw_raw_request (hdev, report->id, report_data, report_len,HID_FEATURE_REPORT ,HID_REQ_GET_REPORT );if (ret <0 ) {
@@ -103,7 +116,16 @@ static void vivaldi_feature_mapping(stru goto out; } - ret =hid_report_raw_event (hdev,HID_FEATURE_REPORT , buf, +if (!report->id) { +/* +* Undo the damage from hid_hw_raw_request() for unnumbered +* reports. +*/ + report_data++; + report_len--; + } + + ret =hid_report_raw_event (hdev,HID_FEATURE_REPORT , report_data, report_len,0 );if (ret) { dev_warn(&hdev->dev, "failed to report feature %d\n",
Greg Kroah-Hartman
maintainerPATCH 530/563 rtc: pxa: fix null pointer dereference
In reply to Greg Kroah-HartmanFrom: Laurence de Bruxelles <[email protected]>
commit 34127b3632b21e5c391756e724b1198eb9917981 upstream.
With the latest stable kernel versions the rtc on the PXA based Zaurus does not work, when booting I see the following kernel messages:
pxa-rtc pxa-rtc: failed to find rtc clock source pxa-rtc pxa-rtc: Unable to init SA1100 RTC sub-device
pxa-rtc: probe of pxa-rtc failed with error -2
hctosys: unable to open rtc device (rtc0)
I think this is because commit f2997775b111 ("rtc: sa1100: fix possible race condition") moved the allocation of the rtc_device struct out of sa1100_rtc_init and into sa1100_rtc_probe. This means that pxa_rtc_probe also needs to do allocation for the rtc_device struct, otherwise sa1100_rtc_init will try to dereference a null pointer. This patch adds that allocation by copying how sa1100_rtc_probe in drivers/rtc/rtc-sa1100.c does it; after the IRQs are set up a managed rtc_device is allocated.
I've tested this patch with qemu-system-arm -machine akita and with a real Zaurus SL-C1000 applied to 4.19, 5.4, and 5.10.
--- drivers/rtc/rtc-pxa.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/rtc/rtc-pxa.c +4 -0
@@ -330,6 +330,10 @@ static int __init pxa_rtc_probe(struct pif (sa1100_rtc->irq_alarm <0 )return -ENXIO ; + sa1100_rtc->rtc =devm_rtc_allocate_device (&pdev->dev); +if (IS_ERR (sa1100_rtc->rtc)) +return PTR_ERR (sa1100_rtc->rtc); + pxa_rtc->base =devm_ioremap (dev, pxa_rtc->ress->start,resource_size (pxa_rtc->ress));if (!pxa_rtc->base) {
Greg Kroah-Hartman
maintainerPATCH 531/563 vdpa/mlx5: Fix wrong configuration of virtio_version_1_0
In reply to Greg Kroah-HartmanFrom: Eli Cohen <[email protected]>
commit 97143b70aa847f2b0a1f959dde126b76ff7b5376 upstream.
Remove overriding of virtio_version_1_0 which forced the virtqueue object to version 1.
--- drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 -- 1 file changed, 2 deletions(-)
drivers/vdpa/mlx5/net/mlx5_vnet.c +0 -2
@@ -812,8 +812,6 @@ static int create_virtqueue(struct mlx5_MLX5_SET (virtio_q, vq_ctx, umem_3_id, mvq->umem3.id);MLX5_SET (virtio_q, vq_ctx, umem_3_size, mvq->umem3.size);MLX5_SET (virtio_q, vq_ctx, pd, ndev->mvdev.res.pdn); -if (MLX5_CAP_DEV_VDPA_EMULATION (ndev->mvdev.mdev, eth_frame_offload_type)) -MLX5_SET (virtio_q, vq_ctx, virtio_version_1_0,1 ); err =mlx5_cmd_exec (ndev->mvdev.mdev, in, inlen, out,sizeof (out));if (err)
Greg Kroah-Hartman
maintainerPATCH 532/563 virtio_ring: mark ring unused on error
In reply to Greg Kroah-HartmanFrom: Michael S. Tsirkin <[email protected]>
commit 1861ba626ae9b98136f3e504208cdef6b29cd3ec upstream.
A recently added error path does not mark ring unused when exiting on OOM, which will lead to BUG on the next entry in debug builds.
TODO: refactor code so we have START_USE and END_USE in the same function.
--- drivers/virtio/virtio_ring.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/virtio/virtio_ring.c +3 -1
@@ -1124,8 +1124,10 @@ static inline int virtqueue_add_packed(sif (virtqueue_use_indirect (_vq, total_sg)) { err =virtqueue_add_indirect_packed (vq, sgs, total_sg, out_sgs, in_sgs, data, gfp); -if (err != -ENOMEM ) +if (err != -ENOMEM ) { +END_USE (vq);return err; + }/* fall back on direct */ }
Greg Kroah-Hartman
maintainerPATCH 533/563 taskstats: Cleanup the use of task->exit_code
In reply to Greg Kroah-HartmanFrom: Eric W. Biederman <[email protected]>
commit 1b5a42d9c85f0e731f01c8d1129001fd8531a8a0 upstream.
In the function bacct_add_task the code reading task->exit_code was introduced in commit f3cef7a99469 ("[PATCH] csa: basic accounting over taskstats"), and it is not entirely clear what the taskstats interface is trying to return as only returning the exit_code of the first task in a process doesn't make a lot of sense.
As best as I can figure the intent is to return task->exit_code after a task exits. The field is returned with per task fields, so the exit_code of the entire process is not wanted. Only the value of the first task is returned so this is not a useful way to get the per task ptrace stop code. The ordinary case of returning this value is returning after a task exits, which also precludes use for getting a ptrace value.
It is common to for the first task of a process to also be the last task of a process so this field may have done something reasonable by accident in testing.
Make ac_exitcode a reliable per task value by always returning it for every exited task.
Setting ac_exitcode in a sensible mannter makes it possible to continue to provide this value going forward.
--- kernel/tsacct.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
kernel/tsacct.c +3 -4
@@ -38,11 +38,10 @@ void bacct_add_tsk(struct user_namespace stats->ac_btime =clamp_t (time64_t, btime,0 ,U32_MAX ); stats->ac_btime64 = btime; -if (thread_group_leader (tsk)) { +if (tsk->flags &PF_EXITING ) stats->ac_exitcode = tsk->exit_code; -if (tsk->flags &PF_FORKNOEXEC ) - stats->ac_flag |=AFORK ; - } +if (thread_group_leader (tsk) && (tsk->flags &PF_FORKNOEXEC )) + stats->ac_flag |=AFORK ;if (tsk->flags &PF_SUPERPRIV ) stats->ac_flag |=ASU ;if (tsk->flags &PF_DUMPCORE )
Greg Kroah-Hartman
maintainerPATCH 534/563 inet: frags: annotate races around fqdir->dead and fqdir->high_thresh
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit 91341fa0003befd097e190ec2a4bf63ad957c49a upstream.
Both fields can be read/written without synchronization, add proper accessors and documentation.
--- include/net/inet_frag.h | 11 +++++++++-- include/net/ipv6_frag.h | 3 ++- net/ipv4/inet_fragment.c | 8 +++++--- net/ipv4/ip_fragment.c | 3 ++- 4 files changed, 18 insertions(+), 7 deletions(-)
include/net/inet_frag.h +9 -2
@@ -116,8 +116,15 @@ int fqdir_init(struct fqdir **fqdirp, ststatic inline void fqdir_pre_exit (struct fqdir *fqdir) { - fqdir->high_thresh =0 ;/* prevent creation of new frags */ - fqdir->dead = true; +/* Prevent creation of new frags. +* Pairs with READ_ONCE() in inet_frag_find(). +*/ +WRITE_ONCE (fqdir->high_thresh,0 ); + +/* Pairs with READ_ONCE() in inet_frag_kill(), ip_expire() +* and ip6frag_expire_frag_queue(). +*/ +WRITE_ONCE (fqdir->dead, true); }void fqdir_exit (struct fqdir *fqdir);
include/net/ipv6_frag.h +2 -1
@@ -67,7 +67,8 @@ ip6frag_expire_frag_queue(struct net *nestruct sk_buff *head;rcu_read_lock (); -if (fq->q.fqdir->dead) +/* Paired with the WRITE_ONCE() in fqdir_pre_exit(). */ +if (READ_ONCE (fq->q.fqdir->dead)) goto out_rcu_unlock;spin_lock (&fq->q.lock);
net/ipv4/inet_fragment.c +5 -3
@@ -204,9 +204,9 @@ void inet_frag_kill(struct inet_frag_que/* The RCU read lock provides a memory barrier * guaranteeing that if fqdir->dead is false then * the hash table destruction will not start until -* after we unlock. Paired with inet_frags_exit_net(). +* after we unlock. Paired with fqdir_pre_exit(). */ -if (!fqdir->dead) { +if (!READ_ONCE (fqdir->dead)) {rhashtable_remove_fast (&fqdir->rhashtable, &fq->node, fqdir->f->rhash_params);refcount_dec (&fq->refcnt);
@@ -321,9 +321,11 @@ static struct inet_frag_queue *inet_frag/* TODO : call from rcu_read_lock() and no longer use refcount_inc_not_zero() */ struct inet_frag_queue *inet_frag_find (struct fqdir *fqdir,void *key) { +/* This pairs with WRITE_ONCE() in fqdir_pre_exit(). */ +long high_thresh =READ_ONCE (fqdir->high_thresh);struct inet_frag_queue *fq =NULL , *prev; -if (!fqdir->high_thresh ||frag_mem_limit (fqdir) > fqdir->high_thresh) +if (!high_thresh ||frag_mem_limit (fqdir) > high_thresh)return NULL ;rcu_read_lock ();
net/ipv4/ip_fragment.c +2 -1
@@ -144,7 +144,8 @@ static void ip_expire(struct timer_listrcu_read_lock (); -if (qp->q.fqdir->dead) +/* Paired with WRITE_ONCE() in fqdir_pre_exit(). */ +if (READ_ONCE (qp->q.fqdir->dead)) goto out_rcu_unlock;spin_lock (&qp->q.lock);
Greg Kroah-Hartman
maintainerPATCH 535/563 netns: add schedule point in ops_exit_list()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit 2836615aa22de55b8fca5e32fe1b27a67cda625e upstream.
When under stress, cleanup_net() can have to dismantle netns in big numbers. ops_exit_list() currently calls many helpers [1] that have no schedule point, and we can end up with soft lockups, particularly on hosts with many cpus.
Even for moderate amount of netns processed by cleanup_net() this patch avoids latency spikes.
[1] Some of these helpers like fib_sync_up() and fib_sync_down_dev() are very slow because net/ipv4/fib_semantics.c uses host-wide hash tables, and ifindex is used as the only input of two hash functions. ifindexes tend to be the same for all netns (lo.ifindex==1 per instance) This will be fixed in a separate patch.
--- net/core/net_namespace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/core/net_namespace.c +3 -1
@@ -183,8 +183,10 @@ static void ops_exit_list(const struct p {struct net *net;if (ops->exit) { -list_for_each_entry (net, net_exit_list, exit_list) +list_for_each_entry (net, net_exit_list, exit_list) { ops->exit (net); +cond_resched (); + } }if (ops->exit_batch) ops->exit_batch (net_exit_list);
Greg Kroah-Hartman
maintainerPATCH 536/563 xfrm: Dont accidentally set RTO_ONLINK in decode_session4()
In reply to Greg Kroah-HartmanFrom: Guillaume Nault <[email protected]>
commit 23e7b1bfed61e301853b5e35472820d919498278 upstream.
Similar to commit 94e2238969e8 ("xfrm4: strip ECN bits from tos field"), clear the ECN bits from iph->tos when setting ->flowi4_tos. This ensures that the last bit of ->flowi4_tos is cleared, so ip_route_output_key_hash() isn't going to restrict the scope of the route lookup.
Use ~INET_ECN_MASK instead of IPTOS_RT_MASK, because we have no reason to clear the high order bits.
Found by code inspection, compile tested only.
--- net/xfrm/xfrm_policy.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/xfrm/xfrm_policy.c +2 -1
@@ -31,6 +31,7 @@#include <linux/if_tunnel.h> #include <net/dst.h> #include <net/flow.h> +#include <net/inet_ecn.h> #include <net/xfrm.h> #include <net/ip.h> #include <net/gre.h>
@@ -3294,7 +3295,7 @@ decode_session4(struct sk_buff *skb, str fl4->flowi4_proto = iph->protocol; fl4->daddr = reverse ? iph->saddr : iph->daddr; fl4->saddr = reverse ? iph->daddr : iph->saddr; - fl4->flowi4_tos = iph->tos; + fl4->flowi4_tos = iph->tos & ~INET_ECN_MASK ;if (!ip_is_fragment (iph)) {switch (iph->protocol) {
Greg Kroah-Hartman
maintainerPATCH 537/563 gre: Dont accidentally set RTO_ONLINK in gre_fill_metadata_dst()
In reply to Greg Kroah-HartmanFrom: Guillaume Nault <[email protected]>
commit f7716b318568b22fbf0e3be99279a979e217cf71 upstream.
Mask the ECN bits before initialising ->flowi4_tos. The tunnel key may have the last ECN bit set, which will interfere with the route lookup process as ip_route_output_key_hash() interpretes this bit specially (to restrict the route scope).
Found by code inspection, compile tested only.
--- net/ipv4/ip_gre.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
net/ipv4/ip_gre.c +3 -2
@@ -599,8 +599,9 @@ static int gre_fill_metadata_dst(struct key = &info->key;ip_tunnel_init_flow (&fl4,IPPROTO_GRE , key->u.ipv4.dst, key->u.ipv4.src, -tunnel_id_to_key32 (key->tun_id), key->tos,0 , - skb->mark,skb_get_hash (skb)); +tunnel_id_to_key32 (key->tun_id), + key->tos & ~INET_ECN_MASK ,0 , skb->mark, +skb_get_hash (skb)); rt =ip_route_output_key (dev_net (dev), &fl4);if (IS_ERR (rt))return PTR_ERR (rt);
Greg Kroah-Hartman
maintainerPATCH 538/563 libcxgb: Dont accidentally set RTO_ONLINK in cxgb_find_route()
In reply to Greg Kroah-HartmanFrom: Guillaume Nault <[email protected]>
commit a915deaa9abe4fb3a440312c954253a6a733608e upstream.
Mask the ECN bits before calling ip_route_output_ports(). The tos variable might be passed directly from an IPv4 header, so it may have the last ECN bit set. This interferes with the route lookup process as ip_route_output_key_hash() interpretes this bit specially (to restrict the route scope).
Found by code inspection, compile tested only.
--- drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c +2 -1
@@ -32,6 +32,7 @@#include <linux/tcp.h> #include <linux/ipv6.h> +#include <net/inet_ecn.h> #include <net/route.h> #include <net/ip6_route.h>
@@ -99,7 +100,7 @@ cxgb_find_route(struct cxgb4_lld_info *l rt =ip_route_output_ports (&init_net, &fl4,NULL , peer_ip, local_ip, peer_port, local_port,IPPROTO_TCP , - tos,0 ); + tos & ~INET_ECN_MASK ,0 );if (IS_ERR (rt))return NULL ; n =dst_neigh_lookup (&rt->dst, &peer_ip);
Greg Kroah-Hartman
maintainerPATCH 539/563 perf script: Fix hex dump character output
In reply to Greg Kroah-HartmanFrom: Adrian Hunter <[email protected]>
commit 62942e9fda9fd1def10ffcbd5e1c025b3c9eec17 upstream.
Using grep -C with perf script -D can give erroneous results as grep loses lines due to non-printable characters, for example, below the 0020, 0060 and 0070 lines are missing:
$ perf script -D | grep -C10 AUX | head . 0010: 08 00 00 00 00 00 00 00 1f 00 00 00 00 00 00 00 ................ . 0030: 01 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 ................ . 0040: 00 08 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ................ . 0050: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ . 0080: 02 00 00 00 00 00 00 00 1b 00 00 00 00 00 00 00 ................ . 0090: 00 00 00 00 00 00 00 00 ........
0 0 0x450 [0x98]: PERF_RECORD_AUXTRACE_INFO type: 1
PMU Type 8
Time Shift 31
perf's isprint() is a custom implementation from the kernel, but the kernel's _ctype appears to include characters from Latin-1 Supplement which is not compatible with, for example, UTF-8. Fix by checking also isascii().
After:
$ tools/perf/perf script -D | grep -C10 AUX | head . 0010: 08 00 00 00 00 00 00 00 1f 00 00 00 00 00 00 00 ................ . 0020: 03 84 32 2f 00 00 00 00 63 7c 4f d2 fa ff ff ff ..2/....c|O..... . 0030: 01 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 ................ . 0040: 00 08 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ................ . 0050: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ . 0060: 00 02 00 00 00 00 00 00 00 c0 03 00 00 00 00 00 ................ . 0070: e2 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ................ . 0080: 02 00 00 00 00 00 00 00 1b 00 00 00 00 00 00 00 ................ . 0090: 00 00 00 00 00 00 00 00 ........
--- tools/perf/util/debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/util/debug.c +1 -1
@@ -145,7 +145,7 @@ static int trace_event_printer(enum binabreak ;case BINARY_PRINT_CHAR_DATA : printed +=color_fprintf (fp, color,"%c" , -isprint (ch) ? ch :'.' ); +isprint (ch) &&isascii (ch) ? ch :'.' );break ;case BINARY_PRINT_CHAR_PAD : printed +=color_fprintf (fp, color," " );
Greg Kroah-Hartman
maintainerPATCH 540/563 dmaengine: at_xdmac: Dont start transactions at tx_submit level
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
commit bccfb96b59179d4f96cbbd1ddff8fac6d335eae4 upstream.
tx_submit is supposed to push the current transaction descriptor to a pending queue, waiting for issue_pending() to be called. issue_pending() must start the transfer, not tx_submit(), thus remove at_xdmac_start_xfer() from at_xdmac_tx_submit(). Clients of at_xdmac that assume that tx_submit() starts the transfer must be updated and call dma_async_issue_pending() if they miss to call it (one example is atmel_serial).
As the at_xdmac_start_xfer() is now called only from at_xdmac_advance_work() when !at_xdmac_chan_is_enabled(), the at_xdmac_chan_is_enabled() check is no longer needed in at_xdmac_start_xfer(), thus remove it.
--- drivers/dma/at_xdmac.c | 6 ------ 1 file changed, 6 deletions(-)
drivers/dma/at_xdmac.c +0 -6
@@ -338,9 +338,6 @@ static void at_xdmac_start_xfer(struct adev_vdbg (chan2dev (&atchan->chan),"%s: desc 0x%p\n" , __func__, first); -if (at_xdmac_chan_is_enabled (atchan)) -return ; -/* Set transfer as active to not try to start it again. */ first->active_xfer = true;
@@ -430,9 +427,6 @@ static dma_cookie_t at_xdmac_tx_submit(sdev_vdbg (chan2dev (tx->chan),"%s: atchan 0x%p, add desc 0x%p to xfers_list\n" , __func__, atchan, desc);list_add_tail (&desc->xfer_node, &atchan->xfers_list); -if (list_is_singular (&atchan->xfers_list)) -at_xdmac_start_xfer (atchan, desc); -spin_unlock_irqrestore (&atchan->lock, irqflags);return cookie; }
Greg Kroah-Hartman
maintainerPATCH 541/563 dmaengine: at_xdmac: Start transfer for cyclic channels in issue_pending
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
commit e6af9b05bec63cd4d1de2a33968cd0be2a91282a upstream.
Cyclic channels must too call issue_pending in order to start a transfer. Start the transfer in issue_pending regardless of the type of channel. This wrongly worked before, because in the past the transfer was started at tx_submit level when only a desc in the transfer list.
--- drivers/dma/at_xdmac.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/dma/at_xdmac.c +3 -5
@@ -1718,11 +1718,9 @@ static void at_xdmac_issue_pending(strucdev_dbg (chan2dev (&atchan->chan),"%s\n" , __func__); -if (!at_xdmac_chan_is_cyclic (atchan)) { -spin_lock_irqsave (&atchan->lock, flags); -at_xdmac_advance_work (atchan); -spin_unlock_irqrestore (&atchan->lock, flags); - } +spin_lock_irqsave (&atchan->lock, flags); +at_xdmac_advance_work (atchan); +spin_unlock_irqrestore (&atchan->lock, flags);return ; }
Greg Kroah-Hartman
maintainerPATCH 542/563 dmaengine: at_xdmac: Print debug message after realeasing the lock
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
commit 5edc24ac876a928f36f407a0fcdb33b94a3a210f upstream.
It is desirable to do the prints without the lock held if possible, so move the print after the lock is released.
--- drivers/dma/at_xdmac.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/dma/at_xdmac.c +4 -2
@@ -424,10 +424,12 @@ static dma_cookie_t at_xdmac_tx_submit(sspin_lock_irqsave (&atchan->lock, irqflags); cookie =dma_cookie_assign (tx); -dev_vdbg (chan2dev (tx->chan),"%s: atchan 0x%p, add desc 0x%p to xfers_list\n" , - __func__, atchan, desc);list_add_tail (&desc->xfer_node, &atchan->xfers_list);spin_unlock_irqrestore (&atchan->lock, irqflags); + +dev_vdbg (chan2dev (tx->chan),"%s: atchan 0x%p, add desc 0x%p to xfers_list\n" , + __func__, atchan, desc); +return cookie; }
Greg Kroah-Hartman
maintainerPATCH 543/563 dmaengine: at_xdmac: Fix concurrency over xfers_list
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
commit 18deddea9184b62941395889ff7659529c877326 upstream.
Since tx_submit can be called from a hard IRQ, xfers_list must be protected with a lock to avoid concurency on the list's elements. Since at_xdmac_handle_cyclic() is called from a tasklet, spin_lock_irq is enough to protect from a hard IRQ.
--- drivers/dma/at_xdmac.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
drivers/dma/at_xdmac.c +10 -7
@@ -1559,14 +1559,17 @@ static void at_xdmac_handle_cyclic(strucstruct at_xdmac_desc *desc;struct dma_async_tx_descriptor *txd; -if (!list_empty (&atchan->xfers_list)) { - desc =list_first_entry (&atchan->xfers_list, - struct at_xdmac_desc, xfer_node); - txd = &desc->tx_dma_desc; - -if (txd->flags &DMA_PREP_INTERRUPT ) -dmaengine_desc_get_callback_invoke (txd,NULL ); +spin_lock_irq (&atchan->lock); +if (list_empty (&atchan->xfers_list)) { +spin_unlock_irq (&atchan->lock); +return ; } + desc = list_first_entry(&atchan->xfers_list, struct at_xdmac_desc, + xfer_node); +spin_unlock_irq (&atchan->lock); + txd = &desc->tx_dma_desc; +if (txd->flags &DMA_PREP_INTERRUPT ) +dmaengine_desc_get_callback_invoke (txd,NULL ); }static void at_xdmac_handle_error (struct at_xdmac_chan *atchan)
Greg Kroah-Hartman
maintainerPATCH 544/563 dmaengine: at_xdmac: Fix lld view setting
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
commit 1385eb4d14d447cc5d744bc2ac34f43be66c9963 upstream.
AT_XDMAC_CNDC_NDVIEW_NDV3 was set even for AT_XDMAC_MBR_UBC_NDV2, because of the wrong bit handling. Fix it.
--- drivers/dma/at_xdmac.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/dma/at_xdmac.c +3 -1
@@ -89,6 +89,7 @@#define AT_XDMAC_CNDC_NDE (0x1 << 0)/* Channel x Next Descriptor Enable */ #define AT_XDMAC_CNDC_NDSUP (0x1 << 1)/* Channel x Next Descriptor Source Update */ #define AT_XDMAC_CNDC_NDDUP (0x1 << 2)/* Channel x Next Descriptor Destination Update */ +#define AT_XDMAC_CNDC_NDVIEW_MASK GENMASK(28, 27)#define AT_XDMAC_CNDC_NDVIEW_NDV0 (0x0 << 3)/* Channel x Next Descriptor View 0 */ #define AT_XDMAC_CNDC_NDVIEW_NDV1 (0x1 << 3)/* Channel x Next Descriptor View 1 */ #define AT_XDMAC_CNDC_NDVIEW_NDV2 (0x2 << 3)/* Channel x Next Descriptor View 2 */
@@ -353,7 +354,8 @@ static void at_xdmac_start_xfer(struct a*/ if (at_xdmac_chan_is_cyclic (atchan)) reg =AT_XDMAC_CNDC_NDVIEW_NDV1 ; -else if (first->lld.mbr_ubc &AT_XDMAC_MBR_UBC_NDV3 ) +else if ((first->lld.mbr_ubc & +AT_XDMAC_CNDC_NDVIEW_MASK ) ==AT_XDMAC_MBR_UBC_NDV3 ) reg =AT_XDMAC_CNDC_NDVIEW_NDV3 ;else reg =AT_XDMAC_CNDC_NDVIEW_NDV2 ;
Greg Kroah-Hartman
maintainerPATCH 545/563 dmaengine: at_xdmac: Fix at_xdmac_lld struct definition
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
commit 912f7c6f7fac273f40e621447cf17d14b50d6e5b upstream.
The hardware channel next descriptor view structure contains just fields of 32 bits, while dma_addr_t can be of type u64 or u32 depending on CONFIG_ARCH_DMA_ADDR_T_64BIT. Force u32 to comply with what the hardware expects.
--- drivers/dma/at_xdmac.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/dma/at_xdmac.c +9 -9
@@ -221,15 +221,15 @@ struct at_xdmac {/* Linked List Descriptor */ struct at_xdmac_lld { -dma_addr_t mbr_nda;/* Next Descriptor Member */ -u32 mbr_ubc;/* Microblock Control Member */ -dma_addr_t mbr_sa;/* Source Address Member */ -dma_addr_t mbr_da;/* Destination Address Member */ -u32 mbr_cfg;/* Configuration Register */ -u32 mbr_bc;/* Block Control Register */ -u32 mbr_ds;/* Data Stride Register */ -u32 mbr_sus;/* Source Microblock Stride Register */ -u32 mbr_dus;/* Destination Microblock Stride Register */ +u32 mbr_nda;/* Next Descriptor Member */ +u32 mbr_ubc;/* Microblock Control Member */ +u32 mbr_sa;/* Source Address Member */ +u32 mbr_da;/* Destination Address Member */ +u32 mbr_cfg;/* Configuration Register */ +u32 mbr_bc;/* Block Control Register */ +u32 mbr_ds;/* Data Stride Register */ +u32 mbr_sus;/* Source Microblock Stride Register */ +u32 mbr_dus;/* Destination Microblock Stride Register */ };/* 64-bit alignment needed to update CNDA and CUBC registers in an atomic way. */
Greg Kroah-Hartman
maintainerPATCH 546/563 perf probe: Fix ppc64 perf probe add events failed case
In reply to Greg Kroah-HartmanFrom: Zechuan Chen <[email protected]>
commit 4624f199327a704dd1069aca1c3cadb8f2a28c6f upstream.
Because of commit bf794bf52a80c627 ("powerpc/kprobes: Fix kallsyms lookup across powerpc ABIv1 and ABIv2"), in ppc64 ABIv1, our perf command eliminates the need to use the prefix "." at the symbol name.
But when the command "perf probe -a schedule" is executed on ppc64 ABIv1, it obtains two symbol address information through /proc/kallsyms, for example:
cat /proc/kallsyms | grep -w schedule
c000000000657020 T .schedule
c000000000d4fdb8 D schedule
The symbol "D schedule" is not a function symbol, and perf will print:
"p:probe/schedule _text+13958584"Failed to write event: Invalid argument
Therefore, when searching symbols from map and adding probe point for them, a symbol type check is added. If the type of symbol is not a function, skip it.
--- tools/perf/util/probe-event.c | 3 +++ 1 file changed, 3 insertions(+)
tools/perf/util/probe-event.c +3 -0
@@ -3035,6 +3035,9 @@ static int find_probe_trace_events_from_for (j =0 ; j < num_matched_functions; j++) { sym = syms[j]; +if (sym->type !=STT_FUNC ) +continue ; +/* There can be duplicated symbols in the map */ for (i =0 ; i < j; i++)if (sym->start == syms[i]->start) {
Greg Kroah-Hartman
maintainerPATCH 547/563 devlink: Remove misleading internal_flags from health reporter dump
In reply to Greg Kroah-HartmanFrom: Leon Romanovsky <[email protected]>
commit e9538f8270db24d272659e15841854c7ea11119e upstream.
DEVLINK_CMD_HEALTH_REPORTER_DUMP_GET command doesn't have .doit callback and has no use in internal_flags at all. Remove this misleading assignment.
--- net/core/devlink.c | 2 -- 1 file changed, 2 deletions(-)
net/core/devlink.c +0 -2
@@ -7852,8 +7852,6 @@ static const struct genl_small_ops devli GENL_DONT_VALIDATE_DUMP_STRICT, .dumpit = devlink_nl_cmd_health_reporter_dump_get_dumpit, .flags = GENL_ADMIN_PERM, - .internal_flags =DEVLINK_NL_FLAG_NEED_DEVLINK_OR_PORT | - DEVLINK_NL_FLAG_NO_LOCK, }, { .cmd = DEVLINK_CMD_HEALTH_REPORTER_DUMP_CLEAR,
Greg Kroah-Hartman
maintainerPATCH 548/563 arm64: dts: qcom: msm8996: drop not documented adreno properties
In reply to Greg Kroah-HartmanFrom: David Heidelberg <[email protected]>
commit c41910f257a22dc406c60d8826b4a3b5398003a3 upstream.
These properties aren't documented nor implemented in the driver. Drop them.
Fixes warnings as:
$ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/gpu.yaml ... arch/arm64/boot/dts/qcom/msm8996-mtp.dt.yaml: gpu@b00000: 'qcom,gpu-quirk-fault-detect-mask', 'qcom,gpu-quirk-two-pass-use-wfi' do not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/display/msm/gpu.yaml ...
--- arch/arm64/boot/dts/qcom/msm8996.dtsi | 3 --- 1 file changed, 3 deletions(-)
arch/arm64/boot/dts/qcom/msm8996.dtsi +0 -3
@@ -645,9 +645,6 @@ nvmem-cells = <&gpu_speed_bin>; nvmem-cell-names = "speed_bin"; - qcom,gpu-quirk-two-pass-use-wfi; - qcom,gpu-quirk-fault-detect-mask; - operating-points-v2 = <&gpu_opp_table>; gpu_opp_table: opp-table {
Greg Kroah-Hartman
maintainerPATCH 549/563 net: bonding: fix bond_xmit_broadcast return value error bug
In reply to Greg Kroah-HartmanFrom: Jie Wang <[email protected]>
commit 4e5bd03ae34652cd932ab4c91c71c511793df75c upstream.
In Linux bonding scenario, one packet is copied to several copies and sent by all slave device of bond0 in mode 3(broadcast mode). The mode 3 xmit function bond_xmit_broadcast() only ueses the last slave device's tx result as the final result. In this case, if the last slave device is down, then it always return NET_XMIT_DROP, even though the other slave devices xmit success. It may cause the tx statistics error, and cause the application (e.g. scp) consider the network is unreachable.
For example, use the following command to configure server A.
echo 3 > /sys/class/net/bond0/bonding/mode
ifconfig bond0 up
ifenslave bond0 eth0 eth1
ifconfig bond0 192.168.1.125
ifconfig eth0 up
ifconfig eth1 down
The slave device eth0 and eth1 are connected to server B(192.168.1.107). Run the ping 192.168.1.107 -c 3 -i 0.2 command, the following information is displayed.
PING 192.168.1.107 (192.168.1.107) 56(84) bytes of data. 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=0.077 ms 64 bytes from 192.168.1.107: icmp_seq=2 ttl=64 time=0.056 ms 64 bytes from 192.168.1.107: icmp_seq=3 ttl=64 time=0.051 ms
192.168.1.107 ping statistics
0 packets transmitted, 3 received
Actually, the slave device eth0 of the bond successfully sends three ICMP packets, but the result shows that 0 packets are transmitted.
Also if we use scp command to get remote files, the command end with the following printings.
ssh_exchange_identification: read: Connection timed out
So this patch modifies the bond_xmit_broadcast to return NET_XMIT_SUCCESS if one slave device in the bond sends packets successfully. If all slave devices send packets fail, the discarded packets stats is increased. The skb is released when there is no slave device in the bond or the last slave device is down.
--- drivers/net/bonding/bond_main.c | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-)
drivers/net/bonding/bond_main.c +22 -8
@@ -4562,25 +4562,39 @@ static netdev_tx_t bond_xmit_broadcast(sstruct bonding *bond =netdev_priv (bond_dev);struct slave *slave =NULL ;struct list_head *iter; +bool xmit_suc = false; +bool skb_used = false;bond_for_each_slave_rcu (bond, slave, iter) { -if (bond_is_last_slave (bond, slave)) -break ; -if (bond_slave_is_up (slave) && slave->link ==BOND_LINK_UP ) { -struct sk_buff *skb2 =skb_clone (skb,GFP_ATOMIC ); +struct sk_buff *skb2; +if (!(bond_slave_is_up (slave) && slave->link ==BOND_LINK_UP )) +continue ; + +if (bond_is_last_slave (bond, slave)) { + skb2 = skb; + skb_used = true; + }else { + skb2 =skb_clone (skb,GFP_ATOMIC );if (!skb2) {net_err_ratelimited ("%s: Error: %s: skb_clone() failed\n" , bond_dev->name, __func__);continue ; } -bond_dev_queue_xmit (bond, skb2, slave->dev); } + +if (bond_dev_queue_xmit (bond, skb2, slave->dev) ==NETDEV_TX_OK ) + xmit_suc = true; } -if (slave &&bond_slave_is_up (slave) && slave->link ==BOND_LINK_UP ) -return bond_dev_queue_xmit (bond, skb, slave->dev); -return bond_tx_drop (bond_dev, skb); +if (!skb_used) +dev_kfree_skb_any (skb); + +if (xmit_suc) +return NETDEV_TX_OK ; + +atomic_long_inc (&bond_dev->tx_dropped); +return NET_XMIT_DROP ; }/*------------------------- Device initialization ---------------------------*/
Greg Kroah-Hartman
maintainerPATCH 550/563 net_sched: restore "mpu xxx" handling
In reply to Greg Kroah-HartmanFrom: Kevin Bracey <[email protected]>
commit fb80445c438c78b40b547d12b8d56596ce4ccfeb upstream.
commit 56b765b79e9a ("htb: improved accuracy at high rates") broke "overhead X", "linklayer atm" and "mpu X" attributes.
"overhead X" and "linklayer atm" have already been fixed. This restores the "mpu X" handling, as might be used by DOCSIS or Ethernet shaping:
tc class add ... htb rate X overhead 4 mpu 64
The code being fixed is used by htb, tbf and act_police. Cake has its own mpu handling. qdisc_calculate_pkt_len still uses the size table containing values adjusted for mpu by user space.
iproute2 tc has always passed mpu into the kernel via a tc_ratespec structure, but the kernel never directly acted on it, merely stored it so that it could be read back by tc class show.
Rather, tc would generate length-to-time tables that included the mpu (and linklayer) in their construction, and the kernel used those tables.
Since v3.7, the tables were no longer used. Along with "mpu", this also broke "overhead" and "linklayer" which were fixed in 01cb71d2d47b ("net_sched: restore "overhead xxx" handling", v3.10) and 8a8e3d84b171 ("net_sched: restore "linklayer atm" handling", v3.11).
"overhead" was fixed by simply restoring use of tc_ratespec::overhead - this had originally been used by the kernel but was initially omitted from the new non-table-based calculations.
"linklayer" had been handled in the table like "mpu", but the mode was not originally passed in tc_ratespec. The new implementation was made to handle it by getting new versions of tc to pass the mode in an extended tc_ratespec, and for older versions of tc the table contents were analysed at load time to deduce linklayer.
As "mpu" has always been given to the kernel in tc_ratespec, accompanying the mpu-based table, we can restore system functionality with no userspace change by making the kernel act on the tc_ratespec value.
--- include/net/sch_generic.h | 5 +++++ net/sched/sch_generic.c | 1 + 2 files changed, 6 insertions(+)
include/net/sch_generic.h +5 -0
@@ -1261,6 +1261,7 @@ struct psched_ratecfg {u64 rate_bytes_ps;/* bytes per second */ u32 mult;u16 overhead; +u16 mpu;u8 linklayer;u8 shift; };
@@ -1270,6 +1271,9 @@ static inline u64 psched_l2t_ns(const st { len += r->overhead; +if (len < r->mpu) + len = r->mpu; +if (unlikely (r->linklayer ==TC_LINKLAYER_ATM ))return ((u64)(DIV_ROUND_UP (len,48 )*53 ) * r->mult) >> r->shift;
@@ -1292,6 +1296,7 @@ static inline void psched_ratecfg_getrat res->rate =min_t (u64, r->rate_bytes_ps, ~0U ); res->overhead = r->overhead; + res->mpu = r->mpu; res->linklayer = (r->linklayer &TC_LINKLAYER_MASK ); }
net/sched/sch_generic.c +1 -0
@@ -1386,6 +1386,7 @@ void psched_ratecfg_precompute(struct ps {memset (r,0 ,sizeof (*r)); r->overhead = conf->overhead; + r->mpu = conf->mpu; r->rate_bytes_ps =max_t (u64, conf->rate, rate64); r->linklayer = (conf->linklayer &TC_LINKLAYER_MASK ); r->mult =1 ;
Greg Kroah-Hartman
maintainerPATCH 551/563 bcmgenet: add WOL IRQ check
In reply to Greg Kroah-HartmanFrom: Sergey Shtylyov <[email protected]>
commit 9deb48b53e7f4056c2eaa2dc2ee3338df619e4f6 upstream.
The driver neglects to check the result of platform_get_irq_optional()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL. Stop calling devm_request_irq() with the invalid IRQ #s.
--- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/net/ethernet/broadcom/genet/bcmgenet.c +6 -4
@@ -3962,10 +3962,12 @@ static int bcmgenet_probe(struct platfor/* Request the WOL interrupt and advertise suspend if available */ priv->wol_irq_disabled = true; - err =devm_request_irq (&pdev->dev, priv->wol_irq, bcmgenet_wol_isr,0 , - dev->name, priv); -if (!err) -device_set_wakeup_capable (&pdev->dev,1 ); +if (priv->wol_irq >0 ) { + err =devm_request_irq (&pdev->dev, priv->wol_irq, + bcmgenet_wol_isr,0 , dev->name, priv); +if (!err) +device_set_wakeup_capable (&pdev->dev,1 ); + }/* Set the needed headroom to account for any possible * features enabling/disabling at runtime
Greg Kroah-Hartman
maintainerPATCH 552/563 net: ethernet: mtk_eth_soc: fix error checking in mtk_mac_config()
In reply to Greg Kroah-HartmanFrom: Tom Rix <[email protected]>
commit 214b3369ab9b0a6f28d6c970220c209417edbc65 upstream.
Clang static analysis reports this problem mtk_eth_soc.c:394:7: warning: Branch condition evaluates
to a garbage value
if (err)
^~~err is not initialized and only conditionally set. So intitialize err.
--- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mediatek/mtk_eth_soc.c +1 -1
@@ -215,7 +215,7 @@ static void mtk_mac_config(struct phylin phylink_config);struct mtk_eth *eth = mac->hw;u32 mcr_cur, mcr_new, sid, i; -int val, ge_mode, err; +int val, ge_mode, err =0 ;/* MT76x8 has no hardware settings between for the MAC */ if (!MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628) &&
Greg Kroah-Hartman
maintainerPATCH 553/563 net: sfp: fix high power modules without diagnostic monitoring
In reply to Greg Kroah-HartmanFrom: Russell King (Oracle) <[email protected]>
commit 5765cee119bf5a36c94d20eceb37c445508934be upstream.
Commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") unintetionally changed the semantics for high power modules without the digital diagnostics monitoring. We repeatedly attempt to read the power status from the non-existing 0xa2 address in a futile hope this failure is temporary:
[ 8.856051] sfp sfp-eth3: module NTT 0000000000000000 rev 0000 sn 0000000000000000 dc 160408 [ 8.865843] mvpp2 f4000000.ethernet eth3: switched to inband/1000base-x link mode [ 8.873469] sfp sfp-eth3: Failed to read EEPROM: -5 [ 8.983251] sfp sfp-eth3: Failed to read EEPROM: -5 [ 9.103250] sfp sfp-eth3: Failed to read EEPROM: -5
We previosuly assumed such modules were powered up in the correct mode, continuing without further configuration as long as the required power class was supported by the host.
Restore this behaviour, while preserving the intent of subsequent patches to avoid the "Address Change Sequence not supported" warning if we are not going to be accessing the DDM address.
--- drivers/net/phy/sfp.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-)
drivers/net/phy/sfp.c +21 -4
@@ -1589,17 +1589,20 @@ static int sfp_sm_probe_for_phy(struct sstatic int sfp_module_parse_power (struct sfp *sfp) {u32 power_mW =1000 ; +bool supports_a2;if (sfp->id.ext.options &cpu_to_be16 (SFP_OPTIONS_POWER_DECL )) power_mW =1500 ;if (sfp->id.ext.options &cpu_to_be16 (SFP_OPTIONS_HIGH_POWER_LEVEL )) power_mW =2000 ; + supports_a2 = sfp->id.ext.sff8472_compliance != +SFP_SFF8472_COMPLIANCE_NONE || + sfp->id.ext.diagmon &SFP_DIAGMON_DDM ; +if (power_mW > sfp->max_power_mW) {/* Module power specification exceeds the allowed maximum. */ -if (sfp->id.ext.sff8472_compliance == -SFP_SFF8472_COMPLIANCE_NONE && - !(sfp->id.ext.diagmon &SFP_DIAGMON_DDM )) { +if (!supports_a2) {/* The module appears not to implement bus address * 0xa2, so assume that the module powers up in the * indicated mode.
@@ -1616,11 +1619,25 @@ static int sfp_module_parse_power(struct } } +if (power_mW <=1000 ) { +/* Modules below 1W do not require a power change sequence */ + sfp->module_power_mW = power_mW; +return 0 ; + } + +if (!supports_a2) { +/* The module power level is below the host maximum and the +* module appears not to implement bus address 0xa2, so assume +* that the module powers up in the indicated mode. +*/ +return 0 ; + } +/* If the module requires a higher power mode, but also requires * an address change sequence, warn the user that the module may * not be functional. */ -if (sfp->id.ext.diagmon &SFP_DIAGMON_ADDRMODE && power_mW >1000 ) { +if (sfp->id.ext.diagmon &SFP_DIAGMON_ADDRMODE ) {dev_warn (sfp->dev,"Address Change Sequence not supported but module requires %u.%uW, module may not be functional\n" , power_mW /1000 , (power_mW /100 ) %10 );
Greg Kroah-Hartman
maintainerPATCH 554/563 net: mscc: ocelot: fix using match before it is set
In reply to Greg Kroah-HartmanFrom: Tom Rix <[email protected]>
commit baa59504c1cd0cca7d41954a45ee0b3dc78e41a0 upstream.
Clang static analysis reports this issue ocelot_flower.c:563:8: warning: 1st function call argument
is an uninitialized value
!is_zero_ether_addr(match.mask->dst)) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~The variable match is used before it is set. So move the block.
--- drivers/net/ethernet/mscc/ocelot_flower.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
drivers/net/ethernet/mscc/ocelot_flower.c +8 -7
@@ -462,13 +462,6 @@ ocelot_flower_parse_key(struct ocelot *oreturn -EOPNOTSUPP ; } -if (filter->block_id ==VCAP_IS1 && - !is_zero_ether_addr (match.mask->dst)) { -NL_SET_ERR_MSG_MOD (extack, -"Key type S1_NORMAL cannot match on destination MAC" ); -return -EOPNOTSUPP ; - } -/* The hw support mac matches only for MAC_ETYPE key, * therefore if other matches(port, tcp flags, etc) are added * then just bail out
@@ -483,6 +476,14 @@ ocelot_flower_parse_key(struct ocelot *oreturn -EOPNOTSUPP ;flow_rule_match_eth_addrs (rule, &match); + +if (filter->block_id ==VCAP_IS1 && + !is_zero_ether_addr (match.mask->dst)) { +NL_SET_ERR_MSG_MOD (extack, +"Key type S1_NORMAL cannot match on destination MAC" ); +return -EOPNOTSUPP ; + } + filter->key_type =OCELOT_VCAP_KEY_ETYPE ;ether_addr_copy (filter->key.etype.dmac.value, match.key->dst);
Greg Kroah-Hartman
maintainerPATCH 555/563 dt-bindings: display: meson-dw-hdmi: add missing sound-name-prefix property
In reply to Greg Kroah-HartmanFrom: Alexander Stein <[email protected]>
commit 22bf4047d26980807611b7e2030803db375afd87 upstream.
This is used in meson-gx and meson-g12. Add the property to the binding. This fixes the dtschema warning:
hdmi-tx@c883a000: 'sound-name-prefix' does not match any of the
regexes: 'pinctrl-[0-9]+'
--- Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml | 5 +++++ 1 file changed, 5 insertions(+)
Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml +5 -0
@@ -10,6 +10,9 @@ title: Amlogic specific extensions to th maintainers: - Neil Armstrong <[email protected]> +allOf: + - $ref: /schemas/sound/name-prefix.yaml# + description: | The Amlogic Meson Synopsys Designware Integration is composed of - A Synopsys DesignWare HDMI Controller IP
@@ -99,6 +102,8 @@ properties: "#sound-dai-cells": const: 0 + sound-name-prefix: true + required: - compatible - reg
Greg Kroah-Hartman
maintainerPATCH 556/563 dt-bindings: display: meson-vpu: Add missing amlogic,canvas property
In reply to Greg Kroah-HartmanFrom: Alexander Stein <[email protected]>
commit 640f35b871d29cd685ce0ea0762636381beeb98a upstream.
This property was already mentioned in the old textual bindings amlogic,meson-vpu.txt, but got dropped during conversion. Adding it back similar to amlogic,gx-vdec.yaml.
--- Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml | 6 ++++++ 1 file changed, 6 insertions(+)
Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml +6 -0
@@ -78,6 +78,10 @@ properties: interrupts: maxItems: 1 + amlogic,canvas: + description: should point to a canvas provider node + $ref: /schemas/types.yaml#/definitions/phandle + power-domains: maxItems: 1 description: phandle to the associated power domain
@@ -106,6 +110,7 @@ required: - port@1 - "#address-cells" - "#size-cells" + - amlogic,canvas additionalProperties: false
@@ -118,6 +123,7 @@ examples: interrupts = <3>; #address-cells = <1>; #size-cells = <0>; + amlogic,canvas = <&canvas>; /* CVBS VDAC output port */ port@0 {
Greg Kroah-Hartman
maintainerPATCH 557/563 dt-bindings: watchdog: Require samsung,syscon-phandle for Exynos7
In reply to Greg Kroah-HartmanFrom: Sam Protsenko <[email protected]>
commit 33950f9a36aca55c2b1e6062d9b29f3e97f91c40 upstream.
Exynos7 watchdog driver is clearly indicating that its dts node must define syscon phandle property. That was probably forgotten, so add it.
--- Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml +3 -2
@@ -39,8 +39,8 @@ properties: samsung,syscon-phandle: $ref: /schemas/types.yaml#/definitions/phandle description: - Phandle to the PMU system controller node (in case of Exynos5250 - and Exynos5420). + Phandle to the PMU system controller node (in case of Exynos5250, + Exynos5420 and Exynos7). required: - compatible
@@ -58,6 +58,7 @@ allOf: enum: - samsung,exynos5250-wdt - samsung,exynos5420-wdt + - samsung,exynos7-wdt then: required: - samsung,syscon-phandle
Greg Kroah-Hartman
maintainerPATCH 558/563 scripts/dtc: dtx_diff: remove broken example from help text
In reply to Greg Kroah-HartmanFrom: Matthias Schiffer <[email protected]>
commit d8adf5b92a9d2205620874d498c39923ecea8749 upstream.
dtx_diff suggests to use <(...) syntax to pipe two inputs into it, but this has never worked: The /proc/self/fds/... paths passed by the shell will fail the [ -f "${dtx}" ] && [ -r "${dtx}" ] check in compile_to_dts, but even with this check removed, the function cannot work: hexdump will eat up the DTB magic, making the subsequent dtc call fail, as a pipe cannot be rewound.
Simply remove this broken example, as there is already an alternative one that works fine.
--- scripts/dtc/dtx_diff | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
scripts/dtc/dtx_diff +2 -6
@@ -59,12 +59,8 @@ Otherwise DTx is treated as a dts source or '/include/' to be processed. If DTx_1 and DTx_2 are in different architectures, then this script - may not work since \${ARCH} is part of the include path. Two possible - workarounds: - - `basename $0` \\ - <(ARCH=arch_of_dtx_1 `basename $0` DTx_1) \\ - <(ARCH=arch_of_dtx_2 `basename $0` DTx_2) + may not work since \${ARCH} is part of the include path. The following + workaround can be used: `basename $0` ARCH=arch_of_dtx_1 DTx_1 >tmp_dtx_1.dts `basename $0` ARCH=arch_of_dtx_2 DTx_2 >tmp_dtx_2.dts
Greg Kroah-Hartman
maintainerPATCH 559/563 lib82596: Fix IRQ check in sni_82596_probe
In reply to Greg Kroah-HartmanFrom: Miaoqian Lin <[email protected]>
commit 99218cbf81bf21355a3de61cd46a706d36e900e6 upstream.
platform_get_irq() returns negative error number instead 0 on failure. And the doc of platform_get_irq() provides a usage example:
int irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;Fix the check of return value to catch errors correctly.
--- drivers/net/ethernet/i825xx/sni_82596.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/i825xx/sni_82596.c +2 -1
@@ -117,9 +117,10 @@ static int sni_82596_probe(struct platfo netdevice->dev_addr[5 ] =readb (eth_addr +0x06 );iounmap (eth_addr); -if (!netdevice->irq) { +if (netdevice->irq <0 ) {printk (KERN_ERR "%s: IRQ not found for i82596 at 0x%lx\n" , __FILE__, netdevice->base_addr); + retval = netdevice->irq; goto probe_failed; }
Greg Kroah-Hartman
maintainerPATCH 560/563 mm/hmm.c: allow VM_MIXEDMAP to work with hmm_range_fault
In reply to Greg Kroah-HartmanFrom: Alistair Popple <[email protected]>
commit 87c01d57fa23de82fff593a7d070933d08755801 upstream.
hmm_range_fault() can be used instead of get_user_pages() for devices which allow faulting however unlike get_user_pages() it will return an error when used on a VM_MIXEDMAP range.
To make hmm_range_fault() more closely match get_user_pages() remove this restriction. This requires dealing with the !ARCH_HAS_PTE_SPECIAL case in hmm_vma_handle_pte(). Rather than replicating the logic of vm_normal_page() call it directly and do a check for the zero pfn similar to what get_user_pages() currently does.
Also add a test to hmm selftest to verify functionality.
--- lib/test_hmm.c | 24 ++++++++++++++++++ mm/hmm.c | 5 ++- tools/testing/selftests/vm/hmm-tests.c | 42 +++++++++++++++++++++++++++++++++ 3 files changed, 69 insertions(+), 2 deletions(-)
lib/test_hmm.c +24 -0
@@ -965,9 +965,33 @@ static long dmirror_fops_unlocked_ioctl(return 0 ; } +static int dmirror_fops_mmap (struct file *file,struct vm_area_struct *vma) +{ +unsigned long addr; + +for (addr = vma->vm_start; addr < vma->vm_end; addr +=PAGE_SIZE ) { +struct page *page; +int ret; + + page =alloc_page (GFP_KERNEL | __GFP_ZERO); +if (!page) +return -ENOMEM ; + + ret =vm_insert_page (vma, addr, page); +if (ret) { +__free_page (page); +return ret; + } +put_page (page); + } + +return 0 ; +} +static const struct file_operations dmirror_fops = { .open = dmirror_fops_open, .release = dmirror_fops_release, + .mmap = dmirror_fops_mmap, .unlocked_ioctl = dmirror_fops_unlocked_ioctl, .llseek = default_llseek, .owner =THIS_MODULE ,
mm/hmm.c +3 -2
@@ -296,7 +296,8 @@ static int hmm_vma_handle_pte(struct mm_* Since each architecture defines a struct page for the zero page, just * fall through and treat it like a normal page. */ -if (pte_special (pte) && !pte_devmap (pte) && +if (!vm_normal_page (walk->vma, addr, pte) && + !pte_devmap (pte) && !is_zero_pfn (pte_pfn (pte))) {if (hmm_pte_need_fault (hmm_vma_walk, pfn_req_flags,0 )) {pte_unmap (ptep);
@@ -514,7 +515,7 @@ static int hmm_vma_walk_test(unsigned lostruct hmm_range *range = hmm_vma_walk->range;struct vm_area_struct *vma = walk->vma; -if (!(vma->vm_flags & (VM_IO |VM_PFNMAP |VM_MIXEDMAP )) && +if (!(vma->vm_flags & (VM_IO |VM_PFNMAP )) && vma->vm_flags &VM_READ )return 0 ;
tools/testing/selftests/vm/hmm-tests.c +42 -0
48 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 561/563 lib/test_meminit: destroy cache in kmem_cache_alloc_bulk() test
In reply to Greg Kroah-HartmanFrom: Andrey Konovalov <[email protected]>
commit e073e5ef90298d2d6e5e7f04b545a0815e92110c upstream.
Make do_kmem_cache_size_bulk() destroy the cache it creates.
--- lib/test_meminit.c | 1 + 1 file changed, 1 insertion(+)
lib/test_meminit.c +1 -0
@@ -337,6 +337,7 @@ static int __init do_kmem_cache_size_bulif (num)kmem_cache_free_bulk (c, num, objects); } +kmem_cache_destroy (c); *total_failures += fail;return 1 ; }
Greg Kroah-Hartman
maintainerPATCH 562/563 mtd: nand: bbt: Fix corner case in bad block table handling
In reply to Greg Kroah-HartmanFrom: Doyle, Patrick <[email protected]>
commit fd0d8d85f7230052e638a56d1bfea170c488e6bc upstream.
In the unlikely event that both blocks 10 and 11 are marked as bad (on a 32 bit machine), then the process of marking block 10 as bad stomps on cached entry for block 11. There are (of course) other examples.
--- drivers/mtd/nand/bbt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/bbt.c +1 -1
@@ -123,7 +123,7 @@ int nanddev_bbt_set_block_status(structunsigned int rbits = bits_per_block + offs -BITS_PER_LONG ; pos[1 ] &= ~GENMASK (rbits -1 ,0 ); - pos[1 ] |= val >> rbits; + pos[1 ] |= val >> (bits_per_block - rbits); }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 563/563 ath10k: Fix the MTU size on QCA9377 SDIO
In reply to Greg Kroah-HartmanFrom: Fabio Estevam <[email protected]>
commit 09b8cd69edcf2be04a781e1781e98e52a775c9ad upstream.
On an imx6dl-pico-pi board with a QCA9377 SDIO chip, simply trying to connect via ssh to another machine causes:
[ 55.824159] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12 [ 55.832169] ath10k_sdio mmc1:0001:1: failed to submit frame: -12 [ 55.838529] ath10k_sdio mmc1:0001:1: failed to push frame: -12 [ 55.905863] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12 [ 55.913650] ath10k_sdio mmc1:0001:1: failed to submit frame: -12 [ 55.919887] ath10k_sdio mmc1:0001:1: failed to push frame: -12
, leading to an ssh connection failure.
One user inspected the size of frames on Wireshark and reported the followig:
"I was able to narrow the issue down to the mtu. If I set the mtu for the wlan0 device to 1486 instead of 1500, the issue does not happen.
The size of frames that I see on Wireshark is exactly 1500 after setting it to 1486."
Clearing the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE avoids the problem and the ssh command works successfully after that.
Introduce a 'credit_size_workaround' field to ath10k_hw_params for the QCA9377 SDIO, so that the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE is not set in this case.
Tested with QCA9377 SDIO with firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1.
--- drivers/net/wireless/ath/ath10k/core.c | 19 ++++++++++++++++++- drivers/net/wireless/ath/ath10k/hw.h | 3 +++ 2 files changed, 21 insertions(+), 1 deletion(-)
drivers/net/wireless/ath/ath10k/core.c +18 -1
@@ -89,6 +89,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = true, }, {
@@ -123,6 +124,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = true, }, {
@@ -158,6 +160,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, }, {
@@ -187,6 +190,7 @@ static const struct ath10k_hw_params ath .num_wds_entries = 0x20, .uart_pin_workaround = true, .tx_stats_over_pktlog = false, + .credit_size_workaround = false, .bmi_large_size_download = true, .supports_peer_stats_info = true, },
@@ -222,6 +226,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, }, {
@@ -256,6 +261,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, }, {
@@ -290,6 +296,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, }, {
@@ -327,6 +334,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = true, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, .supports_peer_stats_info = true, },
@@ -368,6 +376,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, }, {
@@ -415,6 +424,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, }, {
@@ -459,6 +469,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, }, {
@@ -493,6 +504,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, }, {
@@ -529,6 +541,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = true, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, }, {
@@ -557,6 +570,7 @@ static const struct ath10k_hw_params ath .ast_skid_limit = 0x10, .num_wds_entries = 0x20, .uart_pin_workaround = true, + .credit_size_workaround = true, }, { .id = QCA4019_HW_1_0_DEV_VERSION,
@@ -597,6 +611,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = false, .hw_filter_reset_required = true, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, }, {
@@ -624,6 +639,7 @@ static const struct ath10k_hw_params ath .rri_on_ddr = true, .hw_filter_reset_required = false, .fw_diag_ce_download = false, + .credit_size_workaround = false, .tx_stats_over_pktlog = false, }, };
@@ -697,6 +713,7 @@ static void ath10k_send_suspend_completestatic int ath10k_init_sdio (struct ath10k *ar,enum ath10k_firmware_mode mode) { +bool mtu_workaround = ar->hw_params.credit_size_workaround;int ret;u32 param =0 ;
@@ -714,7 +731,7 @@ static int ath10k_init_sdio(struct ath10 param |=HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET ; -if (mode ==ATH10K_FIRMWARE_MODE_NORMAL ) +if (mode ==ATH10K_FIRMWARE_MODE_NORMAL && !mtu_workaround) param |=HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE ;else param &= ~HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE ;
drivers/net/wireless/ath/ath10k/hw.h +3 -0
@@ -618,6 +618,9 @@ struct ath10k_hw_params {*/ bool uart_pin_workaround; +/* Workaround for the credit size calculation */ +bool credit_size_workaround; +/* tx stats support over pktlog */ bool tx_stats_over_pktlog;
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.94 release. There are 563 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, 26 Jan 2022 18:39:11 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.94-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.94 release. There are 563 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, 26 Jan 2022 18:39:11 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.94-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Tested on arm64 and x86 for 5.10.94-rc1,
Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.10.y
Version: 5.10.94-rc1
Commit: 8688457e4545b8f49cf44e8bce83aff31db395f7
Compiler: gcc version 7.3.0 (GCC)
arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 9018
passed: 9018
failed: 0
timeout: 0
--------------------------------------------------------------------
x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 9018
passed: 9018
failed: 0
timeout: 0
--------------------------------------------------------------------
Hello!
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.94 release. There are 563 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, 26 Jan 2022 18:39:11 +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.10.94-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Regressions detected on arm, arm64, i386, x86.
This is from arm64:
/builds/linux/arch/arm64/mm/extable.c: In function 'fixup_exception':
/builds/linux/arch/arm64/mm/extable.c:17:13: error: implicit declaration of function 'in_bpf_jit' [-Werror=implicit-function-declaration]
17 | if (in_bpf_jit(regs))
| ^~~~~~~~~~ cc1: some warnings being treated as errors
make[3]: *** [/builds/linux/scripts/Makefile.build:280: arch/arm64/mm/extable.o] Error 1
And from Perf on arm, arm64, i386, x86:
libbpf.c: In function 'bpf_object__elf_collect':
libbpf.c:2873:31: error: invalid type argument of '->' (have 'GElf_Shdr' {aka 'Elf64_Shdr'})
2873 | if (sh->sh_type != SHT_PROGBITS)
| ^~
libbpf.c:2877:31: error: invalid type argument of '->' (have 'GElf_Shdr' {aka 'Elf64_Shdr'})
2877 | if (sh->sh_type != SHT_PROGBITS)
| ^~
make[4]: *** [/builds/linux/tools/build/Makefile.build:97: /home/tuxbuild/.cache/tuxmake/builds/current/staticobjs/libbpf.o] Error 1
Greetings!
Daniel Díaz
[email protected]
Quoted 47 lines · Daniel Díaz
Hello!
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.94 release. There are 563 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, 26 Jan 2022 18:39:11 +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.10.94-rc1.gzQuoted 7 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y and the diffstat can be found below.thanks,
greg k-h
Regressions detected on arm, arm64, i386, x86.
This is from arm64:
/builds/linux/arch/arm64/mm/extable.c: In function 'fixup_exception':
/builds/linux/arch/arm64/mm/extable.c:17:13: error: implicit
declaration of function 'in_bpf_jit' [-Werror=implicit-function-declaration]
17 | if (in_bpf_jit(regs))
| ^~~~~~~~~~
cc1: some warnings being treated as errors
make[3]: *** [/builds/linux/scripts/Makefile.build:280:arch/arm64/mm/extable.o] Error 1And from Perf on arm, arm64, i386, x86:
libbpf.c: In function 'bpf_object__elf_collect':
libbpf.c:2873:31: error: invalid type argument of '->' (have
'GElf_Shdr' {aka 'Elf64_Shdr'})
2873 | if (sh->sh_type!=SHT_PROGBITS) | ^~
libbpf.c:2877:31: error: invalid type argument of '->' (have
'GElf_Shdr' {aka 'Elf64_Shdr'})
2877 | if (sh->sh_type!=SHT_PROGBITS) | ^~
make[4]: *** [/builds/linux/tools/build/Makefile.build:97:/home/tuxbuild/.cache/tuxmake/builds/current/staticobjs/libbpf.o] Error 1
Quoted 1 line
Same here.
Signature · 1 line
Florian
Greg Kroah-Hartman
maintainerQuoted 53 lines · Florian Fainelli
Quoted 50 lines · Daniel Díaz
Hello!
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.94 release. There are 563 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, 26 Jan 2022 18:39:11 +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.10.94-rc1.gzQuoted 8 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Regressions detected on arm, arm64, i386, x86.
This is from arm64:
/builds/linux/arch/arm64/mm/extable.c: In function 'fixup_exception':
/builds/linux/arch/arm64/mm/extable.c:17:13: error: implicit
declaration of function 'in_bpf_jit' [-Werror=implicit-function-declaration]
17 | if (in_bpf_jit(regs))
| ^~~~~~~~~~
cc1: some warnings being treated as errors
make[3]: *** [/builds/linux/scripts/Makefile.build:280:arch/arm64/mm/extable.o] Error 1And from Perf on arm, arm64, i386, x86:
libbpf.c: In function 'bpf_object__elf_collect':
libbpf.c:2873:31: error: invalid type argument of '->' (have
'GElf_Shdr' {aka 'Elf64_Shdr'})
2873 | if (sh->sh_type!=SHT_PROGBITS) | ^~ libbpf.c:2877:31: error: invalid type argument of '->' (have
'GElf_Shdr' {aka 'Elf64_Shdr'})
2877 | if (sh->sh_type!=SHT_PROGBITS) | ^~
make[4]: *** [/builds/linux/tools/build/Makefile.build:97:/home/tuxbuild/.cache/tuxmake/builds/current/staticobjs/libbpf.o] Error 1
Quoted 3 lines
Quoted 1 line
Same here.
Thanks, I'll go drop this from all 3 trees now.
greg k-h
Quoted 22 lines · Daniel Díaz
Hello!
Quoted 17 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.94 release. There are 563 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, 26 Jan 2022 18:39:11 +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.10.94-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Regressions detected on arm, arm64, i386, x86 on 5.10 and 5.15.
Quoted 9 lines
This is from arm64:
/builds/linux/arch/arm64/mm/extable.c: In function 'fixup_exception':/builds/linux/arch/arm64/mm/extable.c:17:13: error: implicit declaration of function 'in_bpf_jit' [-Werror=implicit-function-declaration] 17 | if (in_bpf_jit(regs)) | ^~~~~~~~~~ cc1: some warnings being treated as errors make[3]: *** [/builds/linux/scripts/Makefile.build:280: arch/arm64/mm/extable.o] Error 1And from Perf on arm, arm64, i386, x86:
Quoted 8 lines
libbpf.c: In function 'bpf_object__elf_collect':
libbpf.c:2873:31: error: invalid type argument of '->' (have 'GElf_Shdr' {aka 'Elf64_Shdr'})
2873 | if (sh->sh_type != SHT_PROGBITS)
| ^~
libbpf.c:2877:31: error: invalid type argument of '->' (have 'GElf_Shdr' {aka 'Elf64_Shdr'})
2877 | if (sh->sh_type != SHT_PROGBITS)
| ^~
make[4]: *** [/builds/linux/tools/build/Makefile.build:97: /home/tuxbuild/.cache/tuxmake/builds/current/staticobjs/libbpf.o] Error 1Due to this patch,
arm64/bpf: Remove 128MB limit for BPF JIT programs commit b89ddf4cca43f1269093942cf5c4e457fd45c335 upstream.
--
Linaro LKFT
https://lkft.linaro.org