May 2024 - Linux-stable-mirror

[PATCH v2] serial: core: only stop transmit when HW fifo is empty

by Jonas Gorski

If the circular buffer is empty, it just means we fit all characters to send into the HW fifo, but not that the hardware finished transmitting them. So if we immediately call stop_tx() after that, this may abort any pending characters in the HW fifo, and cause dropped characters on the console. Fix this by only stopping tx when the tx HW fifo is actually empty. Fixes: 8275b48b2780 ("tty: serial: introduce transmit helpers") Cc: stable(a)vger.kernel.org Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> --- (this is v2 of the bcm63xx-uart fix attempt) v1 -> v2 * replace workaround with fix for core issue * add Cc: for stable I'm somewhat confident this is the core issue causing the broken output with bcm63xx-uart, and there is no actual need for the UART_TX_NOSTOP. I wouldn't be surprised if this also fixes mxs-uart for which UART_TX_NOSTOP was introduced. If it does, there is no need for the flag anymore. include/linux/serial_core.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index 55b1f3ba48ac..bb0f2d4ac62f 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -786,7 +786,8 @@ enum UART_TX_FLAGS { if (pending < WAKEUP_CHARS) { \ uart_write_wakeup(__port); \ \ - if (!((flags) & UART_TX_NOSTOP) && pending == 0) \ + if (!((flags) & UART_TX_NOSTOP) && pending == 0 && \ + __port->ops->tx_empty(__port)) \ __port->ops->stop_tx(__port); \ } \ \ -- 2.34.1

1 year, 1 month

2
2
0 0

Re: [PATCH] cpufreq: amd-pstate: fix the highest frequency issue which limit performance

by Thomas Weißschuh

Hi stable team, Please backport the mainline commit bf202e654bfa ("cpufreq: amd-pstate: fix the highest frequency issue which limits performance") to the 6.9 stable series. It fixes a performance regression on AMD Phoenix platforms. It was meant to get into the 6.9 release or the stable branch shortly after, but apparently that didn't happen. On 2024-05-08 13:47:03+0000, Perry Yuan wrote: > To address the performance drop issue, an optimization has been > implemented. The incorrect highest performance value previously set by the > low-level power firmware for AMD CPUs with Family ID 0x19 and Model ID > ranging from 0x70 to 0x7F series has been identified as the cause. > > To resolve this, a check has been implemented to accurately determine the > CPU family and model ID. The correct highest performance value is now set > and the performance drop caused by the incorrect highest performance value > are eliminated. > > Before the fix, the highest frequency was set to 4200MHz, now it is set > to 4971MHz which is correct. > > CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ > 0 0 0 0 0:0:0:0 yes 4971.0000 400.0000 400.0000 > 1 0 0 0 0:0:0:0 yes 4971.0000 400.0000 400.0000 > 2 0 0 1 1:1:1:0 yes 4971.0000 400.0000 4865.8140 > 3 0 0 1 1:1:1:0 yes 4971.0000 400.0000 400.0000 > > v1->v2: > * add test by flag from Gaha Bana > > Fixes: f3a052391822 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support") > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218759 > Signed-off-by: Perry Yuan <perry.yuan(a)amd.com> > Co-developed-by: Mario Limonciello <mario.limonciello(a)amd.com> > Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> > Tested-by: Gaha Bana <gahabana(a)gmail.com> > --- > drivers/cpufreq/amd-pstate.c | 22 +++++++++++++++++++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c > index 2db095867d03..6a342b0c0140 100644 > --- a/drivers/cpufreq/amd-pstate.c > +++ b/drivers/cpufreq/amd-pstate.c > @@ -50,7 +50,8 @@ > > #define AMD_PSTATE_TRANSITION_LATENCY 20000 > #define AMD_PSTATE_TRANSITION_DELAY 1000 > -#define AMD_PSTATE_PREFCORE_THRESHOLD 166 > +#define CPPC_HIGHEST_PERF_PERFORMANCE 196 > +#define CPPC_HIGHEST_PERF_DEFAULT 166 > > /* > * TODO: We need more time to fine tune processors with shared memory solution > @@ -326,6 +327,21 @@ static inline int amd_pstate_enable(bool enable) > return static_call(amd_pstate_enable)(enable); > } > > +static u32 amd_pstate_highest_perf_set(struct amd_cpudata *cpudata) > +{ > + struct cpuinfo_x86 *c = &cpu_data(0); > + > + /* > + * For AMD CPUs with Family ID 19H and Model ID range 0x70 to 0x7f, > + * the highest performance level is set to 196. > + * https://bugzilla.kernel.org/show_bug.cgi?id=218759 > + */ > + if (c->x86 == 0x19 && (c->x86_model >= 0x70 && c->x86_model <= 0x7f)) > + return CPPC_HIGHEST_PERF_PERFORMANCE; > + > + return CPPC_HIGHEST_PERF_DEFAULT; > +} > + > static int pstate_init_perf(struct amd_cpudata *cpudata) > { > u64 cap1; > @@ -342,7 +358,7 @@ static int pstate_init_perf(struct amd_cpudata *cpudata) > * the default max perf. > */ > if (cpudata->hw_prefcore) > - highest_perf = AMD_PSTATE_PREFCORE_THRESHOLD; > + highest_perf = amd_pstate_highest_perf_set(cpudata); > else > highest_perf = AMD_CPPC_HIGHEST_PERF(cap1); > > @@ -366,7 +382,7 @@ static int cppc_init_perf(struct amd_cpudata *cpudata) > return ret; > > if (cpudata->hw_prefcore) > - highest_perf = AMD_PSTATE_PREFCORE_THRESHOLD; > + highest_perf = amd_pstate_highest_perf_set(cpudata); > else > highest_perf = cppc_perf.highest_perf; > > -- > 2.34.1 >

1 year, 1 month

2
1
0 0

[PATCH RFC v2 3/5] KEYS: trusted: Do not use WARN when encode fails

by Jarkko Sakkinen

When asn1_encode_sequence() fails, WARN is not the correct solution. 1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c). 2. Location is known, which makes the stack trace useless. 3. Results a crash if panic_on_warn is set. It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it. Replace WARN with pr_err, and print the return value instead, which is only useful piece of information. Cc: stable(a)vger.kernel.org # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- security/keys/trusted-keys/trusted_tpm2.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c index dfeec06301ce..dbdd6a318b8b 100644 --- a/security/keys/trusted-keys/trusted_tpm2.c +++ b/security/keys/trusted-keys/trusted_tpm2.c @@ -38,6 +38,7 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, u8 *end_work = scratch + SCRATCH_SIZE; u8 *priv, *pub; u16 priv_len, pub_len; + int ret; priv_len = get_unaligned_be16(src) + 2; priv = src; @@ -79,8 +80,11 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, work1 = payload->blob; work1 = asn1_encode_sequence(work1, work1 + sizeof(payload->blob), scratch, work - scratch); - if (WARN(IS_ERR(work1), "BUG: ASN.1 encoder failed")) - return PTR_ERR(work1); + if (IS_ERR(work1)) { + ret = PTR_ERR(work1); + pr_err("ASN.1 encode error %d\n", ret); + return ret; + } return work1 - payload->blob; } -- 2.45.1

1 year, 1 month

1
0
0 0

[PATCH RFC 3/5] KEYS: trusted: Do not use WARN when encode fails

by Jarkko Sakkinen

When asn1_encode_sequence() fails, WARN is not the correct solution. 1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c). 2. Location is known, which makes the stack trace useless. 3. Results a crash if panic_on_warn is set. It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it. Replace WARN with pr_err, and print the return value instead, which is only useful piece of information. Cc: stable(a)vger.kernel.org # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- security/keys/trusted-keys/trusted_tpm2.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c index dfeec06301ce..dbdd6a318b8b 100644 --- a/security/keys/trusted-keys/trusted_tpm2.c +++ b/security/keys/trusted-keys/trusted_tpm2.c @@ -38,6 +38,7 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, u8 *end_work = scratch + SCRATCH_SIZE; u8 *priv, *pub; u16 priv_len, pub_len; + int ret; priv_len = get_unaligned_be16(src) + 2; priv = src; @@ -79,8 +80,11 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, work1 = payload->blob; work1 = asn1_encode_sequence(work1, work1 + sizeof(payload->blob), scratch, work - scratch); - if (WARN(IS_ERR(work1), "BUG: ASN.1 encoder failed")) - return PTR_ERR(work1); + if (IS_ERR(work1)) { + ret = PTR_ERR(work1); + pr_err("ASN.1 encode error %d\n", ret); + return ret; + } return work1 - payload->blob; } -- 2.45.1

1 year, 1 month

1
0
0 0

From Financial Crimes Enforcement Network

by Financial Crimes Enforcement Network

Notice... Your fund that was stopped from completion has been released and ready to be transferred indicate if this email id is active for more details Regards Mr. Rowland Cole

1 year, 1 month

1
0
0 0

[PATCH 5.15] nfsd: don't allow nfsd threads to be signalled.

by cel＠kernel.org

From: NeilBrown <neilb(a)suse.de> [ Upstream commit 3903902401451b1cd9d797a8c79769eb26ac7fe5 ] The original implementation of nfsd used signals to stop threads during shutdown. In Linux 2.3.46pre5 nfsd gained the ability to shutdown threads internally it if was asked to run "0" threads. After this user-space transitioned to using "rpc.nfsd 0" to stop nfsd and sending signals to threads was no longer an important part of the API. In commit 3ebdbe5203a8 ("SUNRPC: discard svo_setup and rename svc_set_num_threads_sync()") (v5.17-rc1~75^2~41) we finally removed the use of signals for stopping threads, using kthread_stop() instead. This patch makes the "obvious" next step and removes the ability to signal nfsd threads - or any svc threads. nfsd stops allowing signals and we don't check for their delivery any more. This will allow for some simplification in later patches. A change worth noting is in nfsd4_ssc_setup_dul(). There was previously a signal_pending() check which would only succeed when the thread was being shut down. It should really have tested kthread_should_stop() as well. Now it just does the latter, not the former. Signed-off-by: NeilBrown <neilb(a)suse.de> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> --- fs/nfs/callback.c | 9 +-------- fs/nfsd/nfs4proc.c | 5 ++--- fs/nfsd/nfssvc.c | 12 ------------ net/sunrpc/svc_xprt.c | 16 ++++++---------- 4 files changed, 9 insertions(+), 33 deletions(-) Greg, Sasha - This is the third resend for this fix. Why isn't it applied to origin/linux-5.15.y yet? diff --git a/fs/nfs/callback.c b/fs/nfs/callback.c index 456af7d230cf..46a0a2d6962e 100644 --- a/fs/nfs/callback.c +++ b/fs/nfs/callback.c @@ -80,9 +80,6 @@ nfs4_callback_svc(void *vrqstp) set_freezable(); while (!kthread_freezable_should_stop(NULL)) { - - if (signal_pending(current)) - flush_signals(current); /* * Listen for a request on the socket */ @@ -112,11 +109,7 @@ nfs41_callback_svc(void *vrqstp) set_freezable(); while (!kthread_freezable_should_stop(NULL)) { - - if (signal_pending(current)) - flush_signals(current); - - prepare_to_wait(&serv->sv_cb_waitq, &wq, TASK_INTERRUPTIBLE); + prepare_to_wait(&serv->sv_cb_waitq, &wq, TASK_IDLE); spin_lock_bh(&serv->sv_cb_lock); if (!list_empty(&serv->sv_cb_list)) { req = list_first_entry(&serv->sv_cb_list, diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c index c14f5ac1484c..6779291efca9 100644 --- a/fs/nfsd/nfs4proc.c +++ b/fs/nfsd/nfs4proc.c @@ -1317,12 +1317,11 @@ static __be32 nfsd4_ssc_setup_dul(struct nfsd_net *nn, char *ipaddr, /* found a match */ if (ni->nsui_busy) { /* wait - and try again */ - prepare_to_wait(&nn->nfsd_ssc_waitq, &wait, - TASK_INTERRUPTIBLE); + prepare_to_wait(&nn->nfsd_ssc_waitq, &wait, TASK_IDLE); spin_unlock(&nn->nfsd_ssc_lock); /* allow 20secs for mount/unmount for now - revisit */ - if (signal_pending(current) || + if (kthread_should_stop() || (schedule_timeout(20*HZ) == 0)) { finish_wait(&nn->nfsd_ssc_waitq, &wait); kfree(work); diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c index 4c1a0a1623e5..3d4fd40c987b 100644 --- a/fs/nfsd/nfssvc.c +++ b/fs/nfsd/nfssvc.c @@ -938,15 +938,6 @@ nfsd(void *vrqstp) current->fs->umask = 0; - /* - * thread is spawned with all signals set to SIG_IGN, re-enable - * the ones that will bring down the thread - */ - allow_signal(SIGKILL); - allow_signal(SIGHUP); - allow_signal(SIGINT); - allow_signal(SIGQUIT); - atomic_inc(&nfsdstats.th_cnt); set_freezable(); @@ -971,9 +962,6 @@ nfsd(void *vrqstp) validate_process_creds(); } - /* Clear signals before calling svc_exit_thread() */ - flush_signals(current); - atomic_dec(&nfsdstats.th_cnt); out: diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c index 67ccf1a6459a..b19592673eef 100644 --- a/net/sunrpc/svc_xprt.c +++ b/net/sunrpc/svc_xprt.c @@ -700,8 +700,8 @@ static int svc_alloc_arg(struct svc_rqst *rqstp) /* Made progress, don't sleep yet */ continue; - set_current_state(TASK_INTERRUPTIBLE); - if (signalled() || kthread_should_stop()) { + set_current_state(TASK_IDLE); + if (kthread_should_stop()) { set_current_state(TASK_RUNNING); return -EINTR; } @@ -736,7 +736,7 @@ rqst_should_sleep(struct svc_rqst *rqstp) return false; /* are we shutting down? */ - if (signalled() || kthread_should_stop()) + if (kthread_should_stop()) return false; /* are we freezing? */ @@ -758,11 +758,7 @@ static struct svc_xprt *svc_get_next_xprt(struct svc_rqst *rqstp, long timeout) if (rqstp->rq_xprt) goto out_found; - /* - * We have to be able to interrupt this wait - * to bring down the daemons ... - */ - set_current_state(TASK_INTERRUPTIBLE); + set_current_state(TASK_IDLE); smp_mb__before_atomic(); clear_bit(SP_CONGESTED, &pool->sp_flags); clear_bit(RQ_BUSY, &rqstp->rq_flags); @@ -784,7 +780,7 @@ static struct svc_xprt *svc_get_next_xprt(struct svc_rqst *rqstp, long timeout) if (!time_left) atomic_long_inc(&pool->sp_stats.threads_timedout); - if (signalled() || kthread_should_stop()) + if (kthread_should_stop()) return ERR_PTR(-EINTR); return ERR_PTR(-EAGAIN); out_found: @@ -882,7 +878,7 @@ int svc_recv(struct svc_rqst *rqstp, long timeout) try_to_freeze(); cond_resched(); err = -EINTR; - if (signalled() || kthread_should_stop()) + if (kthread_should_stop()) goto out; xprt = svc_get_next_xprt(rqstp, timeout); base-commit: 284087d4f7d57502b5a41b423b771f16cc6d157a -- 2.44.0

1 year, 1 month

3
2
0 0

[BUG] Linux 6.8.10 NPE

by Chris Rankin

Hi, I am using vanilla Linux 6.8.10, and I've just noticed this BUG in my dmesg log. I have no idea what triggered it, and especially since I have not even mounted any NFS filesystems?! Cheers, Chris [ 9114.607417] BUG: kernel NULL pointer dereference, address: 0000000000000068 [ 9114.613082] #PF: supervisor read access in kernel mode [ 9114.616929] #PF: error_code(0x0000) - not-present page [ 9114.620775] PGD 0 P4D 0 [ 9114.622013] Oops: 0000 [#16] PREEMPT SMP PTI [ 9114.624987] CPU: 2 PID: 16501 Comm: sadc Tainted: G D I 6.8.10 #1 [ 9114.630993] Hardware name: Gigabyte Technology Co., Ltd. EX58-UD3R/EX58-UD3R, BIOS FB 05/04/2009 [ 9114.638561] RIP: 0010:nfsd_show+0x39/0x18e [nfsd] [ 9114.642026] Code: fb 48 83 ec 10 48 8b 47 70 8b 2d 34 9b 03 00 48 8b 80 b0 00 00 00 4c 8b a0 60 02 00 00 e8 99 84 f2 df 49 8b 84 24 f8 0b 00 00 <48> 8b 2c e8 e8 6d c0 f2 df 48 8d bd 00 03 00 00 e8 8f ff ff ff 48 [ 9114.659472] RSP: 0018:ffffc9000b1afcf8 EFLAGS: 00010202 [ 9114.663405] RAX: 0000000000000000 RBX: ffff88810cd5de80 RCX: 0000000000001000 [ 9114.669239] RDX: ffff88813f45b900 RSI: 0000000000000001 RDI: ffff88810cd5de80 [ 9114.675069] RBP: 000000000000000d R08: 0000000000400cc0 R09: 00000000ffffffff [ 9114.680905] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa11e51e0 [ 9114.686737] R13: ffffc9000b1afef8 R14: ffff88810cd5de80 R15: ffffffff81a2a520 [ 9114.692586] FS: 00007f3637e49740(0000) GS:ffff888343c80000(0000) knlGS:0000000000000000 [ 9114.699370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9114.703809] CR2: 0000000000000068 CR3: 000000027a18c000 CR4: 00000000000006f0 [ 9114.709642] Call Trace: [ 9114.710798] <TASK> [ 9114.711602] ? __die_body+0x1a/0x5c [ 9114.713802] ? page_fault_oops+0x321/0x36e [ 9114.716636] ? exc_page_fault+0x105/0x117 [ 9114.719348] ? asm_exc_page_fault+0x22/0x30 [ 9114.722237] ? nfsd_show+0x39/0x18e [nfsd] [ 9114.725103] ? nfsd_show+0x31/0x18e [nfsd] [ 9114.727954] seq_read_iter+0x171/0x353 [ 9114.730410] seq_read+0xe0/0x108 [ 9114.732350] ? startup_64+0x1/0x60 [ 9114.734458] proc_reg_read+0x8c/0xa7 [ 9114.736746] vfs_read+0xa6/0x1bf [ 9114.738685] ? __do_sys_newfstat+0x34/0x5c [ 9114.741486] ksys_read+0x74/0xc0 [ 9114.743418] do_syscall_64+0x6c/0xdc [ 9114.745695] entry_SYSCALL_64_after_hwframe+0x60/0x68 [ 9114.749449] RIP: 0033:0x7f3638039cc1 [ 9114.751752] Code: 00 48 8b 15 59 81 0d 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 b0 aa 01 00 f3 0f 1e fa 80 3d 85 03 0e 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec [ 9114.769198] RSP: 002b:00007ffec523c288 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 9114.775499] RAX: ffffffffffffffda RBX: 000055619e0982e0 RCX: 00007f3638039cc1 [ 9114.781332] RDX: 0000000000000400 RSI: 000055619e0a3b70 RDI: 0000000000000004 [ 9114.787166] RBP: 00007ffec523c2c0 R08: 0000000000000001 R09: 0000000000000000 [ 9114.792997] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3638111050 [ 9114.798830] R13: 00007f3638110f00 R14: 0000000000000000 R15: 000055619e0982e0 [ 9114.804668] </TASK> [ 9114.805559] Modules linked in: udf usb_storage snd_seq_dummy rpcrdma rdma_cm iw_cm ib_cm ib_core nf_nat_ftp nf_conntrack_ftp cfg80211 af_packet nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_tables ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables it87 hwmon_vid bnep binfmt_misc snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel uvcvideo btusb uvc btintel btbcm videobuf2_vmalloc snd_intel_dspcfg videobuf2_memops bluetooth videobuf2_v4l2 snd_hda_codec videodev snd_usb_audio intel_powerclamp coretemp snd_virtuoso snd_hda_core kvm_intel snd_oxygen_lib videobuf2_common ecdh_generic snd_usbmidi_lib snd_mpu401_uart snd_hwdep mc snd_rawmidi [ 9114.805644] input_leds joydev led_class snd_seq rfkill kvm ecc snd_seq_device gpio_ich pktcdvd snd_pcm iTCO_wdt r8169 irqbypass i2c_i801 snd_hrtimer realtek snd_timer mdio_devres intel_cstate snd libphy acpi_cpufreq i2c_smbus pcspkr intel_uncore psmouse lpc_ich i7core_edac mxm_wmi soundcore tiny_power_button button nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm_mod loop fuse dax configfs nfnetlink zram zsmalloc ext4 crc32c_generic crc16 mbcache jbd2 amdgpu video amdxcp i2c_algo_bit mfd_core drm_ttm_helper ttm hid_microsoft drm_exec gpu_sched drm_suballoc_helper drm_buddy drm_display_helper sr_mod usbhid sd_mod cdrom drm_kms_helper ahci pata_jmicron libahci drm uhci_hcd libata ehci_pci ehci_hcd xhci_pci firewire_ohci xhci_hcd firewire_core scsi_mod crc32c_intel sha512_ssse3 usbcore drm_panel_orientation_quirks sha256_ssse3 cec serio_raw sha1_ssse3 rc_core crc_itu_t bsg usb_common scsi_common wmi msr [last unloaded: sg] [ 9114.974386] CR2: 0000000000000068 [ 9114.976469] ---[ end trace 0000000000000000 ]--- [ 9114.979859] RIP: 0010:nfsd_show+0x39/0x18e [nfsd] [ 9114.983413] Code: fb 48 83 ec 10 48 8b 47 70 8b 2d 34 9b 03 00 48 8b 80 b0 00 00 00 4c 8b a0 60 02 00 00 e8 99 84 f2 df 49 8b 84 24 f8 0b 00 00 <48> 8b 2c e8 e8 6d c0 f2 df 48 8d bd 00 03 00 00 e8 8f ff ff ff 48 [ 9115.000909] RSP: 0018:ffffc90002edfcf8 EFLAGS: 00010202 [ 9115.004850] RAX: 0000000000000000 RBX: ffff88813fee9780 RCX: 0000000000001000 [ 9115.010725] RDX: ffff88810b474740 RSI: 0000000000000001 RDI: ffff88813fee9780 [ 9115.016621] RBP: 000000000000000d R08: 0000000000400cc0 R09: 00000000ffffffff [ 9115.022507] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa11e51e0 [ 9115.028414] R13: ffffc90002edfef8 R14: ffff88813fee9780 R15: ffffffff81a2a520 [ 9115.034338] FS: 00007f3637e49740(0000) GS:ffff888343c00000(0000) knlGS:0000000000000000 [ 9115.041191] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9115.045739] CR2: 00007f7171a17ef0 CR3: 000000027a18c000 CR4: 00000000000006f0

1 year, 1 month

1
0
0 0

[PATCH stable] block/mq-deadline: fix different priority request on the same zone

by Wu Bo

Zoned devices request sequential writing on the same zone. That means if 2 requests on the saem zone, the lower pos request need to dispatch to device first. While different priority has it's own tree & list, request with high priority will be disptch first. So if requestA & requestB are on the same zone. RequestA is BE and pos is X+0. ReqeustB is RT and pos is X+1. RequestB will be disptched before requestA, which got an ERROR from zoned device. This is found in a practice scenario when using F2FS on zoned device. And it is very easy to reproduce: 1. Use fsstress to run 8 test processes 2. Use ionice to change 4/8 processes to RT priority Fixes: c807ab520fc3 ("block/mq-deadline: Add I/O priority support") Cc: <stable(a)vger.kernel.org> Signed-off-by: Wu Bo <bo.wu(a)vivo.com> --- block/mq-deadline.c | 31 +++++++++++++++++++++++++++++++ include/linux/blk-mq.h | 15 +++++++++++++++ 2 files changed, 46 insertions(+) diff --git a/block/mq-deadline.c b/block/mq-deadline.c index 02a916ba62ee..6a05dd86e8ca 100644 --- a/block/mq-deadline.c +++ b/block/mq-deadline.c @@ -539,6 +539,37 @@ static struct request *__dd_dispatch_request(struct deadline_data *dd, if (started_after(dd, rq, latest_start)) return NULL; + if (!blk_rq_is_seq_zoned_write(rq)) + goto skip_check; + /* + * To ensure sequential writing, check the lower priority class to see + * if there is a request on the same zone and need to be dispatched + * first + */ + ioprio_class = dd_rq_ioclass(rq); + prio = ioprio_class_to_prio[ioprio_class]; + prio++; + for (; prio <= DD_PRIO_MAX; prio++) { + struct request *temp_rq; + unsigned long flags; + bool can_dispatch; + + if (!dd_queued(dd, prio)) + continue; + + temp_rq = deadline_from_pos(&dd->per_prio[prio], data_dir, blk_rq_pos(rq)); + if (temp_rq && blk_req_zone_in_one(temp_rq, rq) && + blk_rq_pos(temp_rq) < blk_rq_pos(rq)) { + spin_lock_irqsave(&dd->zone_lock, flags); + can_dispatch = blk_req_can_dispatch_to_zone(temp_rq); + spin_unlock_irqrestore(&dd->zone_lock, flags); + if (!can_dispatch) + return NULL; + rq = temp_rq; + per_prio = &dd->per_prio[prio]; + } + } +skip_check: /* * rq is the selected appropriate request. */ diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h index d3d8fd8e229b..bca1e639e0f3 100644 --- a/include/linux/blk-mq.h +++ b/include/linux/blk-mq.h @@ -1202,6 +1202,15 @@ static inline bool blk_req_can_dispatch_to_zone(struct request *rq) return true; return !blk_req_zone_is_write_locked(rq); } + +static inline bool blk_req_zone_in_one(struct request *rq_a, + struct request *rq_b) +{ + unsigned int zone_sectors = rq_a->q->limits.chunk_sectors; + + return round_down(blk_rq_pos(rq_a), zone_sectors) == + round_down(blk_rq_pos(rq_b), zone_sectors); +} #else /* CONFIG_BLK_DEV_ZONED */ static inline bool blk_rq_is_seq_zoned_write(struct request *rq) { @@ -1229,6 +1238,12 @@ static inline bool blk_req_can_dispatch_to_zone(struct request *rq) { return true; } + +static inline bool blk_req_zone_in_one(struct request *rq_a, + struct request *rq_b) +{ + return false; +} #endif /* CONFIG_BLK_DEV_ZONED */ #endif /* BLK_MQ_H */ -- 2.35.3

1 year, 1 month

3
5
0 0

[PATCH] net: ks8851: Fix another TX stall caused by wrong ISR flag handling

by Ronald Wahl

From: Ronald Wahl <ronald.wahl(a)raritan.com> Under some circumstances it may happen that the ks8851 Ethernet driver stops sending data. Currently the interrupt handler resets the interrupt status flags in the hardware after handling TX. With this approach we may lose interrupts in the time window between handling the TX interrupt and resetting the TX interrupt status bit. When all of the three following conditions are true then transmitting data stops: - TX queue is stopped to wait for room in the hardware TX buffer - no queued SKBs in the driver (txq) that wait for being written to hw - hardware TX buffer is empty and the last TX interrupt was lost This is because reenabling the TX queue happens when handling the TX interrupt status but if the TX status bit has already been cleared then this interrupt will never come. With this commit the interrupt status flags will be cleared before they are handled. That way we stop losing interrupts. The wrong handling of the ISR flags was there from the beginning but with commit 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overrun") the issue becomes apparent. Fixes: 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overrun") Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Eric Dumazet <edumazet(a)google.com> Cc: Jakub Kicinski <kuba(a)kernel.org> Cc: Paolo Abeni <pabeni(a)redhat.com> Cc: Simon Horman <horms(a)kernel.org> Cc: netdev(a)vger.kernel.org Cc: stable(a)vger.kernel.org # 5.10+ Signed-off-by: Ronald Wahl <ronald.wahl(a)raritan.com> --- drivers/net/ethernet/micrel/ks8851_common.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/drivers/net/ethernet/micrel/ks8851_common.c b/drivers/net/ethernet/micrel/ks8851_common.c index 502518cdb461..6453c92f0fa7 100644 --- a/drivers/net/ethernet/micrel/ks8851_common.c +++ b/drivers/net/ethernet/micrel/ks8851_common.c @@ -328,7 +328,6 @@ static irqreturn_t ks8851_irq(int irq, void *_ks) { struct ks8851_net *ks = _ks; struct sk_buff_head rxq; - unsigned handled = 0; unsigned long flags; unsigned int status; struct sk_buff *skb; @@ -336,24 +335,17 @@ static irqreturn_t ks8851_irq(int irq, void *_ks) ks8851_lock(ks, &flags); status = ks8851_rdreg16(ks, KS_ISR); + ks8851_wrreg16(ks, KS_ISR, status); netif_dbg(ks, intr, ks->netdev, "%s: status 0x%04x\n", __func__, status); - if (status & IRQ_LCI) - handled |= IRQ_LCI; - if (status & IRQ_LDI) { u16 pmecr = ks8851_rdreg16(ks, KS_PMECR); pmecr &= ~PMECR_WKEVT_MASK; ks8851_wrreg16(ks, KS_PMECR, pmecr | PMECR_WKEVT_LINK); - - handled |= IRQ_LDI; } - if (status & IRQ_RXPSI) - handled |= IRQ_RXPSI; - if (status & IRQ_TXI) { unsigned short tx_space = ks8851_rdreg16(ks, KS_TXMIR); @@ -365,20 +357,12 @@ static irqreturn_t ks8851_irq(int irq, void *_ks) if (netif_queue_stopped(ks->netdev)) netif_wake_queue(ks->netdev); spin_unlock(&ks->statelock); - - handled |= IRQ_TXI; } - if (status & IRQ_RXI) - handled |= IRQ_RXI; - if (status & IRQ_SPIBEI) { netdev_err(ks->netdev, "%s: spi bus error\n", __func__); - handled |= IRQ_SPIBEI; } - ks8851_wrreg16(ks, KS_ISR, handled); - if (status & IRQ_RXI) { /* the datasheet says to disable the rx interrupt during * packet read-out, however we're masking the interrupt -- 2.45.0

1 year, 1 month

3
2
0 0

[PATCH v1 1/1] x86/cpu: Fix boot on Intel Quark X1000

by Andy Shevchenko

The initial change to set x86_virt_bits to the correct value straight away broke boot on Intel Quark X1000 CPUs (which are family 5, model 9, stepping 0) With deeper investigation it appears that the Quark doesn't have the bit 19 set in 0x01 CPUID leaf, which means it doesn't provide any clflush instructions and hence the cache alignment is set to 0. The actual cache line size is 16 bytes, hence we may set the alignment accordingly. At the same time the physical and virtual address bits are retrieved via 0x80000008 CPUID leaf. Note, we don't really care about the value of x86_clflush_size as it is either used with a proper check for the instruction to be present, or, like in PCI case, it assumes 32 bytes for all supported 32-bit CPUs that have actually smaller cache line sizes and don't advertise it. The commit fbf6449f84bf ("x86/sev-es: Set x86_virt_bits to the correct value straight away, instead of a two-phase approach") basically revealed the issue that has been present from day 1 of introducing the Quark support. Fixes: aece118e487a ("x86: Add cpu_detect_cache_sizes to init_intel() add Quark legacy_cache()") Cc: stable(a)vger.kernel.org Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- arch/x86/kernel/cpu/intel.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index be30d7fa2e66..2bffae158dd5 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -321,6 +321,15 @@ static void early_init_intel(struct cpuinfo_x86 *c) #ifdef CONFIG_X86_64 set_cpu_cap(c, X86_FEATURE_SYSENTER32); #else + /* + * The Quark doesn't have bit 19 set in 0x01 CPUID leaf, which means + * it doesn't provide any clflush instructions and hence the cache + * alignment is set to 0. The actual cache line size is 16 bytes, + * hence set the alignment accordingly. At the same time the physical + * and virtual address bits are retrieved via 0x80000008 CPUID leaf. + */ + if (c->x86 == 5 && c->x86_model == 9) + c->x86_cache_alignment = 16; /* Netburst reports 64 bytes clflush size, but does IO in 128 bytes */ if (c->x86 == 15 && c->x86_cache_alignment == 64) c->x86_cache_alignment = 128; -- 2.43.0.rc1.1336.g36b5255a03ac

1 year, 1 month

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024