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]

Date:	Tue, 6 Jan 2009 15:26:59 -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

Just to clarify, by "previous code", I meant I linked to it. It is not
the code I used for the patch.

wt

On Tue, Jan 6, 2009 at 3:26 PM, Warren Turkal <wt@...guintechs.org> wrote:
> 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/