linux-kernel - Re: [PATCH] rd: Mark ramdisk buffers heads dirty

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]

Message-ID: <m17illeb8f.fsf@ebiederm.dsl.xmission.com>
Date:	Wed, 17 Oct 2007 14:29:20 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Chris Mason <chris.mason@...cle.com>
Cc:	Christian Borntraeger <borntraeger@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nick Piggin <nickpiggin@...oo.com.au>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	"Theodore Ts'o" <tytso@....edu>, stable@...nel.org
Subject: Re: [PATCH] rd: Mark ramdisk buffers heads dirty

Chris Mason <chris.mason@...cle.com> writes:

> In this case, the commit block isn't allowed to be dirty before reiserfs
> decides it is safe to write it.  The journal code expects it is the only
> spot in the kernel setting buffer heads dirty, and it only does so after
> the rest of the log blocks are safely on disk.

Ok.  So the journal code here fundamentally depends on being able to
control the order of the writes, and something else being able to set
the buffer head dirty messes up that control.

> Given this is a ramdisk, the check can be ignored, but I'd rather not
> sprinkle if (ram_disk) into the FS code....

It makes no sense to implement a ramdisk in a way that requires this.

>> At the same time I increasingly don't think we should allow user space
>> to dirty or update our filesystem metadata buffer heads.  That seems
>> like asking for trouble.
>> 
>
> Demanding trouble ;)

Looks like it.  There are even comments in jbd about the same class
of problems.  Apparently dump and tune2fs on mounted filesystems have
triggered some of these issues.  The practical question is any of this
trouble worth handling.

Thinking about it.  I don't believe anyone has ever intentionally built
a filesystem tool that depends on being able to modify a file systems
metadata buffer heads while the filesystem is running, and doing that
would seem to be fragile as it would require a lot of cooperation
between the tool and the filesystem about how the filesystem uses and
implement things.

Now I guess I need to see how difficult a patch would be to give
filesystems magic inodes to keep their metadata buffer heads in.

Eric
-
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/