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: <m14plx9hss.fsf@ebiederm.dsl.xmission.com>
Date:	Mon, 28 May 2007 07:52:35 -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:

> Eric W. Biederman wrote:
>> Nick Piggin <nickpiggin@...oo.com.au> writes:
>
>>>I would have thought we can fix this simply by removing the
>>>broken ramdisk_set_page_dirty (as far as the comment goes, we
>>>set CAP_NO_ACCT_DIRTY anyway, so the normal set_page_dirty
>>>should handle everything properly, no?).
>>
>>
>> No.  I don't know where accounting comes into play.  I didn't
>> trace that path.  But if we have a non-dirty ramdisk page with
>> buffers (basically a hole in the middle or at the end of the ramdisk).
>> We need to set the buffer dirty bits when we write to it.
>
> Accounting is done in set_page_dirty.

Yes.  What I meant was I had not looked at the implications of
accounting, so I had not looked to see if I could use a generic
set_dirty_page.

I only got as far as recognizing that __set_page_dirty_no_writeback as
not the appropriate function to use because we need to handle buffer
heads.

>> So I don't see how it would make sense to reuse the generic
>> set_page_dirty, and handling all of the logic in set_page_dirty
>> to dirty the buffer heads seemed to have made the most sense.
>
> That's what the generic set_page_dirty does. What I want to know
> is why *doesn't* it make sense to reuse the generic set_page_dirty?
> Unless there is a good reason, then reusing is better than writing
> your own.

I did not look at that part in detail.  I only realized
ramdisk_set_dirty_page needed to be modified upon a final review of my
code, as it was not a case I actually hit.

Just skimming through it again quickly I don't see a reason at this
point to preserve a separate set_dirty_page for the ramdisk code.

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/