linux-kernel - Re: [PATCH 2.6.19 5/5] fs: freeze

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 7 Nov 2006 23:23:03 +0000
From:	Alasdair G Kergon <agk@...hat.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	Alasdair G Kergon <agk@...hat.com>, linux-kernel@...r.kernel.org,
	dm-devel@...hat.com, Ingo Molnar <mingo@...e.hu>,
	Eric Sandeen <sandeen@...deen.net>,
	Srinivasa DS <srinivasa@...ibm.com>
Subject: Re: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex

On Tue, Nov 07, 2006 at 12:28:37PM -0800, Andrew Morton wrote:
> So...  what does this have to do with switching from mutex to semaphore?

I should have summarised the discussion, sorry.

This has always been a semaphore, but it got changed it to a mutex as part
of a global switch recently - and this indeed generated bug reports
from people who turn debugging on and report the error messages.

So the quick fix in this patch was to put things back how they were.

Now mutex.h states:
 * - only the owner can unlock the mutex
 * - task may not exit with mutex held

 * These semantics are fully enforced when DEBUG_MUTEXES is
 * enabled.

Which begs the question whether the stated semantics are stricter than
is actually necessary.

> If so, it's a bit sad to switch to semaphore just because of some errant
> debugging code.  Perhaps it would be better to create a new
> mutex_unlock_stfu() which suppresses the warning?

Ingo?

> > +	if (down_trylock(&bdev->bd_mount_sem))
> > +		return -EBUSY;
> > +

> This is a functional change which isn't described in the changelog.  What's
> happening here?

Srinivasa added it as a precaution.
Device-mapper should never fall foul of it, but confirming that is not
trivial unless you know the code well, so it's a useful check to prevent a
bug creeping back in.

Alasdair
-- 
agk@...hat.com
-
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/