search for: in_atomic

...200, Michal Hocko wrote: > > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > > > Not just performance critical, but correctness critical. Since kvfree() > > > may allocate from the vmalloc allocator, I really think that kvfree() > > > should assert that it's !in_atomic(). Otherwise we can get into trouble > > > if we end up calling vfree() and have to take the mutex. > > > > FWIW __vfree already checks for atomic context and put the work into a > > deferred context. So this should be safe. It should be used as a last > > resort,...

...200, Michal Hocko wrote: > > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > > > Not just performance critical, but correctness critical. Since kvfree() > > > may allocate from the vmalloc allocator, I really think that kvfree() > > > should assert that it's !in_atomic(). Otherwise we can get into trouble > > > if we end up calling vfree() and have to take the mutex. > > > > FWIW __vfree already checks for atomic context and put the work into a > > deferred context. So this should be safe. It should be used as a last > > resort,...

...restructuring the code to do eg. splice and free it outside of the lock > > is not always possible. > > Not just performance critical, but correctness critical. Since kvfree() > may allocate from the vmalloc allocator, I really think that kvfree() > should assert that it's !in_atomic(). Otherwise we can get into trouble > if we end up calling vfree() and have to take the mutex. FWIW __vfree already checks for atomic context and put the work into a deferred context. So this should be safe. It should be used as a last resort, though. -- Michal Hocko SUSE Labs

...restructuring the code to do eg. splice and free it outside of the lock > > is not always possible. > > Not just performance critical, but correctness critical. Since kvfree() > may allocate from the vmalloc allocator, I really think that kvfree() > should assert that it's !in_atomic(). Otherwise we can get into trouble > if we end up calling vfree() and have to take the mutex. FWIW __vfree already checks for atomic context and put the work into a deferred context. So this should be safe. It should be used as a last resort, though. -- Michal Hocko SUSE Labs

...020 at 09:12:12AM +0200, Michal Hocko wrote: > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > > Not just performance critical, but correctness critical. Since kvfree() > > may allocate from the vmalloc allocator, I really think that kvfree() > > should assert that it's !in_atomic(). Otherwise we can get into trouble > > if we end up calling vfree() and have to take the mutex. > > FWIW __vfree already checks for atomic context and put the work into a > deferred context. So this should be safe. It should be used as a last > resort, though. Actually, it on...

...t #3. Jan 6 01:04:10 $SERVER 3w-xxxx[2781]: ERROR: Drive error encountered on port 3 on controller ID:2. Check cables and drives for media errors. (0xa) Jan 6 01:04:10 $SERVER kernel: Debug: sleeping function called from invalid context at include/asm/uaccess.h:556 Jan 6 01:04:10 $SERVER kernel: in_atomic():0[expected: 0], irqs_disabled():1 Jan 6 01:04:10 $SERVER kernel: [<c011fbe9>] __might_sleep+0x7d/0x88 Jan 6 01:04:10 $SERVER kernel: [<f885f056>] tw_ioctl+0x478/0xb07 [3w_xxxx] Jan 6 01:04:10 $SERVER kernel: [<c011fec9>] autoremove_wake_function+0x0/0x2d Jan 6 01:04:10 $S...

On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote: > On Wed 17-06-20 04:08:20, Matthew Wilcox wrote: > > If you call vfree() under > > a spinlock, you're in trouble. in_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_inte...

I have my Linux 2.6 kernel with the necessary HDLC config and also recompiled zaptel accordingly. On modprobe, I get: Found a Wildcard: Digium Wildcard T100P T1/PRI Debug: sleeping function called from invalid context at mm/slab.c:2000 in_atomic():0[expected: 0], irqs_disabled():1 [<0211e605>] __might_sleep+0x82/0x8c [<02144643>] kmem_cache_alloc+0x1d/0x57 [<42ad7a2c>] zt_ctl_ioctl+0x112c/0x16b0 [zaptel] [<022d6c00>] __cond_resched+0x14/0x39 [<428a315a>] ext3_get_inode_loc+0x4f/0x210 [ext3] [<0217269c...

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 that it can be backported to stable. > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > > now as there can be a

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 that it can be backported to stable. > > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > > now as there can be a

...e@netfilter.org ReportedBy: jafo@tummy.com The current ipt_account SVN code (and probably earlier, extending back as far as July of 2005) seem to report the following when you read from the /proc/net/ipt_account file: Debug: sleeping function called from invalid context at mm/slab.c:2063 in_atomic():1[expected: 0], irqs_disabled():0 Call Trace:<ffffffff80131dd7>{__might_sleep+173} <ffffffff8015fcab>{kmem_cache_alloc+34} <ffffffffa01b7130>{:ipt_account:account_seq_start+51} <ffffffff80193624>{seq_read+235} <ffffffff801770bf>{vfs_read+207}...

...environment which leads the following warnings: [ 622.944441] CPU0 attaching NULL sched-domain. [ 622.944446] CPU1 attaching NULL sched-domain. [ 622.944485] CPU0 attaching NULL sched-domain. [ 622.950795] BUG: sleeping function called from invalid context at kernel/mutex.c:616 [ 622.950796] in_atomic(): 1, irqs_disabled(): 1, pid: 10, name: migration/1 [ 622.950796] no locks held by migration/1/10. [ 622.950798] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.12.0-rc5-wl-01249-gb91e82d #317 [ 622.950799] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 622.950802] 0000000000000000 ffff88...

...environment which leads the following warnings: [ 622.944441] CPU0 attaching NULL sched-domain. [ 622.944446] CPU1 attaching NULL sched-domain. [ 622.944485] CPU0 attaching NULL sched-domain. [ 622.950795] BUG: sleeping function called from invalid context at kernel/mutex.c:616 [ 622.950796] in_atomic(): 1, irqs_disabled(): 1, pid: 10, name: migration/1 [ 622.950796] no locks held by migration/1/10. [ 622.950798] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.12.0-rc5-wl-01249-gb91e82d #317 [ 622.950799] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 622.950802] 0000000000000000 ffff88...

...+ if (!IS_ENABLED(CONFIG_PREEMPT_COUNT)) + return; + + if (preempt_count() > 0) + return; + + if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy) + return; + prev_jiffy = jiffies; + + pr_err("BUG: assuming non migratable context at %s:%d\n", file, line); + pr_err("in_atomic(): %d, irqs_disabled(): %d, migration_disabled() %u pid: %d, name: %s\n", + in_atomic(), irqs_disabled(), is_migration_disabled(current), + current->pid, current->comm); + + debug_show_held_locks(current); + dump_stack(); + add_taint(TAINT_WARN, LOCKDEP_STILL_OK); +} +EXPOR...

...an atomic context and in general it's silly to require a sleepable context for triggering a notification. The following is an invalid context bug triggerd by md invoking sysfs_notify() from IO completion path. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1 2 locks held by swapper/1/0: #0: (&(&vblk->vq_lock)->rlock){-.-...}, at: [<ffffffffa0039042>] virtblk_done+0x42/0xe0 [virtio_blk] #1: (&(&bitmap->counts.lock)->rlock){-.....}, at: [<ffffffff81633718>] b...

...an atomic context and in general it's silly to require a sleepable context for triggering a notification. The following is an invalid context bug triggerd by md invoking sysfs_notify() from IO completion path. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1 2 locks held by swapper/1/0: #0: (&(&vblk->vq_lock)->rlock){-.-...}, at: [<ffffffffa0039042>] virtblk_done+0x42/0xe0 [virtio_blk] #1: (&(&bitmap->counts.lock)->rlock){-.....}, at: [<ffffffff81633718>] b...

...eted under locks and > restructuring the code to do eg. splice and free it outside of the lock > is not always possible. Not just performance critical, but correctness critical. Since kvfree() may allocate from the vmalloc allocator, I really think that kvfree() should assert that it's !in_atomic(). Otherwise we can get into trouble if we end up calling vfree() and have to take the mutex.

...t davemloft.net> > > [ 622.944441] CPU0 attaching NULL sched-domain. > [ 622.944446] CPU1 attaching NULL sched-domain. > [ 622.944485] CPU0 attaching NULL sched-domain. > [ 622.950795] BUG: sleeping function called from invalid context at kernel/mutex.c:616 > [ 622.950796] in_atomic(): 1, irqs_disabled(): 1, pid: 10, name: migration/1 > [ 622.950796] no locks held by migration/1/10. > [ 622.950798] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.12.0-rc5-wl-01249-gb91e82d #317 > [ 622.950799] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > [ 622.950802] 000...

...t's silly to require a sleepable context for triggering a > notification. > > The following is an invalid context bug triggerd by md invoking > sysfs_notify() from IO completion path. > > BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586 > in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1 > 2 locks held by swapper/1/0: > #0: (&(&vblk->vq_lock)->rlock){-.-...}, at: [<ffffffffa0039042>] virtblk_done+0x42/0xe0 [virtio_blk] > #1: (&(&bitmap->counts.lock)->rlock){-.....}, at: [<ffffffff...

...introduced by 22396:c1b7aae86cf5. Signed-off-by: KUWAMURA Shin''ya <kuwa@jp.fujitsu.com> changeset: 23704:dfb4fb612b5b user: KUWAMURA Shin''ya <kuwa@jp.fujitsu.com> date: Sat Jul 16 09:16:48 2011 +0100 [IA64] fix warning: "in_atomic" redefined This patch fixes `warning: "in_atomic" redefined''. # It is introduced by 22395:deb438d43e79. Signed-off-by: KUWAMURA Shin''ya <kuwa@jp.fujitsu.com> changeset: 23703:e238234f6cb0 user: Keir Fraser <keir@xen....