public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* BUG?: super.c:sget spin_lock not released?
@ 2014-05-29 22:49 Kai
  2014-05-29 23:19 ` Al Viro
  0 siblings, 1 reply; 3+ messages in thread
From: Kai @ 2014-05-29 22:49 UTC (permalink / raw)
  To: linux-kernel

Hello,

I have recently been playing around with writing a custom filesystem
for Linux, and have been reading the source of other filesystems, and
the functions they call into the linux kernel.
While looking at the function sget in super.c I found something strange.

before if(test) it takes a spinlock, however there seems to be two
cases where it does not unlock it.
(Kernel 3.14, super.c line 441)

One:
if(!grab_super(old)) goto retry;
Will jump to before spin_lock(), without releasing it first.

Two:
And if it finds an old sb, it will return without releasing the lock.


This code seems to be the same in 3.14 and in 2.6
I might just be missing how the spin_lock works, and if so I'm sorry.
But this seems really strange to me. Would this not potentially cause
a deadlock on sb_lock?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: BUG?: super.c:sget spin_lock not released?
  2014-05-29 22:49 BUG?: super.c:sget spin_lock not released? Kai
@ 2014-05-29 23:19 ` Al Viro
  2014-05-29 23:37   ` Kai
  0 siblings, 1 reply; 3+ messages in thread
From: Al Viro @ 2014-05-29 23:19 UTC (permalink / raw)
  To: Kai; +Cc: linux-kernel

On Fri, May 30, 2014 at 12:49:56AM +0200, Kai wrote:
> Hello,
> 
> I have recently been playing around with writing a custom filesystem
> for Linux, and have been reading the source of other filesystems, and
> the functions they call into the linux kernel.
> While looking at the function sget in super.c I found something strange.
> 
> before if(test) it takes a spinlock, however there seems to be two
> cases where it does not unlock it.
> (Kernel 3.14, super.c line 441)
> 
> One:
> if(!grab_super(old)) goto retry;
> Will jump to before spin_lock(), without releasing it first.

Er...  So either grab_super() releases that spinlock, or that thing
is screwed.  The next obvious step would be to look into grab_super()...

> Two:
> And if it finds an old sb, it will return without releasing the lock.

... unless something it calls does just that.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: BUG?: super.c:sget spin_lock not released?
  2014-05-29 23:19 ` Al Viro
@ 2014-05-29 23:37   ` Kai
  0 siblings, 0 replies; 3+ messages in thread
From: Kai @ 2014-05-29 23:37 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-kernel

On Fri, May 30, 2014 at 1:19 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, May 30, 2014 at 12:49:56AM +0200, Kai wrote:
>> Hello,
>>
>> I have recently been playing around with writing a custom filesystem
>> for Linux, and have been reading the source of other filesystems, and
>> the functions they call into the linux kernel.
>> While looking at the function sget in super.c I found something strange.
>>
>> before if(test) it takes a spinlock, however there seems to be two
>> cases where it does not unlock it.
>> (Kernel 3.14, super.c line 441)
>>
>> One:
>> if(!grab_super(old)) goto retry;
>> Will jump to before spin_lock(), without releasing it first.
>
> Er...  So either grab_super() releases that spinlock, or that thing
> is screwed.  The next obvious step would be to look into grab_super()...
>
>> Two:
>> And if it finds an old sb, it will return without releasing the lock.
>
> ... unless something it calls does just that.

AH, I knew I was missing something. And so obvious too =(

Thank you for pointing it out to me.
Seems I need to spend more time reading the source code and figuring
out how it all connects.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-05-29 23:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-29 22:49 BUG?: super.c:sget spin_lock not released? Kai
2014-05-29 23:19 ` Al Viro
2014-05-29 23:37   ` Kai

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox