[PATCH v2 0/2] sched, xfs: Add PF_MEMALLOC_NOLOCKDEP to fix lockdep problem in xfs

v2: - Update patch to add the frozen flag check as the XFS_TRANS_NO_WRITECOUNT check alone is insufficient. There is a false positive lockdep warning in how the xfs code handle filesystem freeze: Possible unsafe locking scenario: CPU0CPU1

[PATCH 0/2] sched, xfs: Add PF_MEMALLOC_NOLOCKDEP to fix lockdep problem in xfs

There is a false positive lockdep warning in how the xfs code handle filesystem freeze: Possible unsafe locking scenario: CPU0CPU1 lock(sb_internal); lock(fs_reclaim); l

Re: v4.12: register_dcache lockdep problem on boot

On Tue, 25 Jul 2017, Pavel Machek wrote: > Hi! > > I get this one during boot... > > Pavel > [ 12.717617] __lock_acquire+0x86/0x94a > [ 12.720466] lock_acquire+0x4a/0x66 > [ 12.723223] ? mca_reap+0x56/0x115 > [ 12.725972]

v4.12: register_dcache lockdep problem on boot

Hi! I get this one during boot... Pavel [0.00] Linux version 4.12.0+ (pavel@duo) (gcc version 4.9.2 (Debian 4.9.2-10) ) #411 SMP Tue Jul 25 09:04:04 CEST 2017 [0.00] Disabled fast string operations [0.00] x

Re: Lockdep problem

On 01/09/2014 10:24 AM, Stanislaw Gruszka wrote: On Tue, Jan 07, 2014 at 12:28:26PM -0600, Larry Finger wrote: rtnl_mutex --> misc_mtx --> rfkill_global_mutex Possible unsafe locking scenario: CPU0CPU1 lock(rfkill_glo

Re: Lockdep problem

On Tue, Jan 07, 2014 at 12:28:26PM -0600, Larry Finger wrote: > rtnl_mutex --> misc_mtx --> rfkill_global_mutex > > Possible unsafe locking scenario: > > CPU0CPU1 > >lock(rfkill_global_mutex); >

Lockdep problem

A locking dependency problem has been reported for b43 at https://bugzilla.kernel.org/show_bug.cgi?id=67561. I was able to duplicate with the following: 1. Set network under manual, not NetworkManager, control. 2. Start hostapd 3. Use 'rfkill block all' to disable the access point As my skills

Re: lockdep problem conversion semaphore->mutex (dev->sem)

Peter Zijlstra wrote, On 12/08/2007 09:50 PM: > On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote: > >> Which problems? I did not see any special things, it looked rather >> straight forward. What have I overlooked? > > On suspend it locks the whole device tree, this means it has 'unbounded'

Re: lockdep problem conversion semaphore->mutex (dev->sem)

Peter, Thanks for this clear answer. Remy 2007/12/8, Peter Zijlstra <[EMAIL PROTECTED]>: > > On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote: > > > Which problems? I did not see any special things, it looked rather > > straight forward. What have I overlooked? > > On suspend it locks the wh

Re: lockdep problem conversion semaphore->mutex (dev->sem)

On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote: > Which problems? I did not see any special things, it looked rather > straight forward. What have I overlooked? On suspend it locks the whole device tree, this means it has 'unbounded' nesting and holds an 'unbounded' number of locks. Neithe

Re: lockdep problem conversion semaphore->mutex (dev->sem)

Hello Ingo, > no, you are wrong. If you want to do complex locking, you can still do > it: take a look at the dev->sem conversion patches from Peter which > correctly do this. Lockdep has all the facilities for that. > (you just dont know about them) Ok. > the general policy message here is: do

Re: lockdep problem conversion semaphore->mutex (dev->sem)

Hello Peter, > And while you might not see it in-tree anymore, lockdep does help out > tremendously while developing new code. I'm sure that without it the > locking would be in a much worse state than it is today. I am not arguing that, I am also convinced it has done a good job. > I have a goo

Re: lockdep problem conversion semaphore->mutex (dev->sem)

* Remy Bohmer <[EMAIL PROTECTED]> wrote: > But... now we do not transfer the dev->sem to a mutex, because lockdep > will start generating false positives, and thus we mask the lockdep > error, by not converting the dev->sem to what it really is... no, you are wrong. If you want to do complex l

Re: lockdep problem conversion semaphore->mutex (dev->sem)

On Sat, 2007-12-08 at 20:52 +0100, Remy Bohmer wrote: > Hello Peter and Daniel, > > > Yeah, it are different lock instances, however by virtue of sharing the > > same lock init site, they belong to the same lock class. Lockdep works > > by tracking class dependancies, not instance dependancies. >

Re: lockdep problem conversion semaphore->mutex (dev->sem)

Hello Peter and Daniel, > Yeah, it are different lock instances, however by virtue of sharing the > same lock init site, they belong to the same lock class. Lockdep works > by tracking class dependancies, not instance dependancies. The device and its parent both indeed have different pointers/ins

Re: lockdep problem conversion semaphore->mutex (dev->sem)

On Sat, 2007-12-08 at 08:53 -0800, Daniel Walker wrote: > On Sat, 2007-12-08 at 13:16 +0100, Peter Zijlstra wrote: > > On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote: > > > Hello Peter, > > > > > > > > What specifically is wrong with dev->sem ? > > > > > > > > Nothing really, other than tha

Re: lockdep problem conversion semaphore->mutex (dev->sem)

On Sat, 2007-12-08 at 09:06 -0800, Daniel Walker wrote: > On Sat, 2007-12-08 at 18:11 +0100, Peter Zijlstra wrote: > > > > It must be the locking in __driver_attach(), taking dev->parent->sem > > > then taking dev->sem .. Assuming those are different structures, why > > > does lockdep trigger? >

Re: lockdep problem conversion semaphore->mutex (dev->sem)

On Sat, 2007-12-08 at 18:11 +0100, Peter Zijlstra wrote: > > It must be the locking in __driver_attach(), taking dev->parent->sem > > then taking dev->sem .. Assuming those are different structures, why > > does lockdep trigger? > > They aren't different, parent is a struct device again. It's di

Re: lockdep problem conversion semaphore->mutex (dev->sem)

On Sat, 2007-12-08 at 13:16 +0100, Peter Zijlstra wrote: > On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote: > > Hello Peter, > > > > > > What specifically is wrong with dev->sem ? > > > > > > Nothing really, other than that they use semaphores to avoid lockdep :-/ > > > > > > I think I know h

Re: lockdep problem conversion semaphore->mutex (dev->sem)

On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote: > Hello Peter, > > > > What specifically is wrong with dev->sem ? > > > > Nothing really, other than that they use semaphores to avoid lockdep :-/ > > > > I think I know how to annotate this, after Alan Stern explained all the > > use cases, b

lockdep problem conversion semaphore->mutex (dev->sem)

Hello Peter, > > What specifically is wrong with dev->sem ? > > Nothing really, other than that they use semaphores to avoid lockdep :-/ > > I think I know how to annotate this, after Alan Stern explained all the > use cases, but I haven't come around to implementing it. Hope to do that > soonish.