linux-kernel - BUG?: super.c:sget spin

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+jWvaKyLPfFb6b-aGCz8RhCCcsSZ+kz5Co3xSKwPOhsguHFMA@mail.gmail.com>
Date:	Fri, 30 May 2014 00:49:56 +0200
From:	Kai <wildex999@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: BUG?: super.c:sget spin_lock not released?

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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/