linux-kernel - Re: 2.6.29 -mm merge plans

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: <e37d376a0901061526s5d571febu2eb9758050506442@mail.gmail.com>
Date:	Tue, 6 Jan 2009 15:26:04 -0800
From:	"Warren Turkal" <wt@...guintechs.org>
To:	"Christoph Hellwig" <hch@...radead.org>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	"Roman Zippel" <zippel@...ux-m68k.org>,
	"Diego Elio 'Flameeyes' Petten?" <flameeyes@...il.com>
Subject: Re: 2.6.29 -mm merge plans

I have a drive at home with the condition. So empirically, it can happen.

I would also argue that having a journal bit set and then saying that
the journal info block is at 0 makes no sense anyhow since the first
1024 bytes of the volume must be empty on HFS+.

And, I found the previous code from Apple saying that a 0 in the
journal_info_block field indicated that there was no journal.

Is there anything else I should be doing?

wt

On Tue, Jan 6, 2009 at 3:19 PM, Christoph Hellwig <hch@...radead.org> wrote:
> On Tue, Jan 06, 2009 at 03:17:47PM -0800, Andrew Morton wrote:
>> > I'm pretty sure we already had a version better than that in your
>> > tree on the list.  But I've lost track and we should just restart
>> > the review cycle on -fsdevel.
>>
>> Yeah, I have the three hfs patches:
>>
>> hfsplus-identify-journal-info-block-in-volume-header.patch
>> hfsplus-fix-journal-detection.patch
>> hfs-add-basic-export-support.patch
>>
>> in a holding pattern awaiting a second round, due to laggy, incomplete
>> and confusing noises from various people.  It all needs a revisit.
>
> The first two are not for me to decide.  They look fine code-wise,
> but IIRC Roman had some issues with wether the condition should be
> possible at all.
>
> The third one is where I requested a respin, and I'm pretty sure I've
> seen a version with some improvement over the one in your tree.  Let's
> get the latests version back on -fsdevel and review it again.
>
> The one in your tree certainly is not ready.
>
--
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/