search for: preempt_count

...n_atomic() only knows if we hold a > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > in __vfree(). So we need the warning in order that preempt people can > tell those without that there is a bug here. ... Unless I am missing something in_interrupt depends on preempt_count() as well so neither of the two is reliable without PREEMPT_COUNT configured. -- Michal Hocko SUSE Labs

...n_atomic() only knows if we hold a > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > in __vfree(). So we need the warning in order that preempt people can > tell those without that there is a bug here. ... Unless I am missing something in_interrupt depends on preempt_count() as well so neither of the two is reliable without PREEMPT_COUNT configured. -- Michal Hocko SUSE Labs

...we hold a > > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > > in __vfree(). So we need the warning in order that preempt people can > > tell those without that there is a bug here. > > ... Unless I am missing something in_interrupt depends on preempt_count() as > well so neither of the two is reliable without PREEMPT_COUNT configured. preempt_count() always tracks whether we're in interrupt context, regardless of CONFIG_PREEMPT. The difference is that CONFIG_PREEMPT will track spinlock acquisitions as well.

...s introduced through the following > commit: This was more a cut'n'paste to show which warning triggered since line numbers are somewhat volatile. > > commit fd1270d5df6a005e1248e87042159a799cc4b2c9 > Date: Wed Apr 16 09:23:48 2014 -0600 > > blk-mq: don't use preempt_count() to check for right CPU > > UP or CONFIG_PREEMPT_NONE will return 0, and what we really > want to check is whether or not we are on the right CPU. > So don't make PREEMPT part of this, just test the CPU in > the mask directly. > > Anyway, I think tha...

...s introduced through the following > commit: This was more a cut'n'paste to show which warning triggered since line numbers are somewhat volatile. > > commit fd1270d5df6a005e1248e87042159a799cc4b2c9 > Date: Wed Apr 16 09:23:48 2014 -0600 > > blk-mq: don't use preempt_count() to check for right CPU > > UP or CONFIG_PREEMPT_NONE will return 0, and what we really > want to check is whether or not we are on the right CPU. > So don't make PREEMPT part of this, just test the CPU in > the mask directly. > > Anyway, I think tha...

On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote: > > On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > > > v4: > > > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > > > so

On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote: > > On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > > > v4: > > > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > > > so

...oted with SYSRQ-B. The kernel is a kernel.org 2.4.18, with the addition of the "premptible kernel" patch (preempt-kernel-rml-2.4.18-5.patch.gz, from Debian package versionned 20020530-1). I attach the config file (with comments stripped). The included "<whatever> exited with preempt_count 1" also occur under normal use (mainly at boot-time and halt-time), which may not be normal as well. The machine did not have anything special scheduled, just usual cron jobs, which had let a 2.4.17 (with other patches, but not the preempt one) run smoothly with a 3-months uptime. Decoded ve...

When doing cpu hotplug in a KVM guest with virtio blk I get warnings like 747.652408] ------------[ cut here ]------------ [ 747.652410] WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 __blk_mq_run_hw_queue+0xd4/0x100 [ 747.652410] Modules linked in: dm_multipath [ 747.652412] CPU: 4 PID: 2895 Comm: kworker/4:1H Tainted: G W 4.14.0+ #191 [ 747.652412] Hardware name: IBM 2964

When doing cpu hotplug in a KVM guest with virtio blk I get warnings like 747.652408] ------------[ cut here ]------------ [ 747.652410] WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 __blk_mq_run_hw_queue+0xd4/0x100 [ 747.652410] Modules linked in: dm_multipath [ 747.652412] CPU: 4 PID: 2895 Comm: kworker/4:1H Tainted: G W 4.14.0+ #191 [ 747.652412] Hardware name: IBM 2964

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

...1f 18 a0 31 c0 e8 ca ad 19 e1 48 89 df 4c 89 e6 b9 00 04 00 00 <f3> a5 e8 ba f7 ff ff e8 b5 f7 ff ff bf 01 00 00 00 e8 c4 f0 19 RIP [<ffffffffa017c3fb>] ttm_tt_swapout+0x135/0x1db [ttm] RSP <ffff88003749fce0> ---[ end trace 8724ec5cfdbfe4ce ]--- note: ttm_swap[1501] exited with preempt_count 3

I recently sent off a fix for lazy vmalloc faults which can happen under = paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a = bit on fixing this. I neglected to notice that since the new call to = flush the MMU update queue is called from the page fault handler, it can = be pre-empted. Both VMI and Xen use per-cpu variables to track lazy = mode state, as all previous

I recently sent off a fix for lazy vmalloc faults which can happen under = paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a = bit on fixing this. I neglected to notice that since the new call to = flush the MMU update queue is called from the page fault handler, it can = be pre-empted. Both VMI and Xen use per-cpu variables to track lazy = mode state, as all previous

...t; This was more a cut'n'paste to show which warning triggered since line numbers are somewhat volatile. >> >>> >>> commit fd1270d5df6a005e1248e87042159a799cc4b2c9 >>> Date: Wed Apr 16 09:23:48 2014 -0600 >>> >>> blk-mq: don't use preempt_count() to check for right CPU >>> >>> UP or CONFIG_PREEMPT_NONE will return 0, and what we really >>> want to check is whether or not we are on the right CPU. >>> So don't make PREEMPT part of this, just test the CPU in >>> the mask...

...t; This was more a cut'n'paste to show which warning triggered since line numbers are somewhat volatile. >> >>> >>> commit fd1270d5df6a005e1248e87042159a799cc4b2c9 >>> Date: Wed Apr 16 09:23:48 2014 -0600 >>> >>> blk-mq: don't use preempt_count() to check for right CPU >>> >>> UP or CONFIG_PREEMPT_NONE will return 0, and what we really >>> want to check is whether or not we are on the right CPU. >>> So don't make PREEMPT part of this, just test the CPU in >>> the mask...

...hich warning triggered since line numbers are somewhat volatile. >>>> >>>>> >>>>> commit fd1270d5df6a005e1248e87042159a799cc4b2c9 >>>>> Date: Wed Apr 16 09:23:48 2014 -0600 >>>>> >>>>> blk-mq: don't use preempt_count() to check for right CPU >>>>> >>>>> UP or CONFIG_PREEMPT_NONE will return 0, and what we really >>>>> want to check is whether or not we are on the right CPU. >>>>> So don't make PREEMPT part of this, just test the C...

...hich warning triggered since line numbers are somewhat volatile. >>>> >>>>> >>>>> commit fd1270d5df6a005e1248e87042159a799cc4b2c9 >>>>> Date: Wed Apr 16 09:23:48 2014 -0600 >>>>> >>>>> blk-mq: don't use preempt_count() to check for right CPU >>>>> >>>>> UP or CONFIG_PREEMPT_NONE will return 0, and what we really >>>>> want to check is whether or not we are on the right CPU. >>>>> So don't make PREEMPT part of this, just test the C...

...kmap_atomic_prot+0x1b/0x100 SS:ESP 0068:f3a83da8 > Jan 6 20:06:23 eser kernel: [19365.563014] CR2: 0000000000000000 > Jan 6 20:06:23 eser kernel: [19365.568714] ---[ end trace afc2be06c7d06a71 > ]--- > Jan 6 20:06:23 eser kernel: [19365.568724] note: gimp-2.6[15675] exited with > preempt_count 2 > ___ > > The kernel is an unpatched v2.6.37. I have not seen something like this before. Bugzilla''s habit of wordwrapping oops traces is fantastically irritating. Please use attachments to avoid this. Either Peter''s new kmap_atomic() stuff blew up or BTRFS is playi...