linux-kernel - Re: [PATCH 1/3] Preserve the dirty bit in init_page

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: <m1zm3p82yb.fsf@ebiederm.dsl.xmission.com>
Date:	Mon, 28 May 2007 07:58:36 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] Preserve the dirty bit in init_page_buffers

Nick Piggin <nickpiggin@...oo.com.au> writes:

>> Definitely, and it was a royal pain to trace the bug that this
>> caused.  An initial ramdisk having pieces disappear after mkfs
>> is called can look like the entire machine is dying.
>>
>> When we initialize the ramdisk by writing to /dev/ram0 usually in
>> init/do_mounts_rd.c we don't allocate buffer heads but we do set
>> the dirty bit, and the page is in the page cache.  So when we
>> later call getblk it reuses the same page and then calls
>> init_page_buffers.
>
> Hmm, the comment above grow_dev_buffers indicates this should
> not happen. But contrary to the comment, it doesn't go BUG
> unless you're attaching dirty buffers to a page with dirty
> buffers.
>
> I suspect this happens more frequently with rd.c, because unlike
> block_dev.c, it does not create dirty buffers in prepare_write.
> However it could still happen in block_dev.c via mmaped memory,
> as I said earlier.
>
> I'm not saying this patch 1/3 is wrong, but we would at least
> need to revise some comments. The grow_dev_buffers comment looks
> like one of Andrew's. Maybe he can shed some more light on this?

Good question.  It sounds like you are correct.

Either we need to fix those comments or find the root
cause for the need to call cancel_dirty_page in try_to_free_buffers
and fix that.

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/