linux-kernel - Re: Problems with hfsplus on ipods in 2.6.38+

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:	Fri, 15 Jul 2011 09:39:00 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Daniel Barkalow <barkalow@...ervon.org>,
	Christoph Hellwig <hch@...era.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Problems with hfsplus on ipods in 2.6.38+

On Thu, Jul 14, 2011 at 09:26:11PM -0400, Daniel Barkalow wrote:
> Okay, I've applied that patch set, and it worked for me without any issues 
> thus far. If you're interested in the debugging output from a device that 
> doesn't work with vanilla but doesn't oops or panic with that patch set, 
> it's attached. I'm using 32-bit x86, if that helps for tracking down 
> differences.

Hrm, looks like I used %lu for sector_t instead of %llu, and that's
messing up the output on 32-bit builds. What I am able to see looks
correct though. I put up a new version of the patches with the output
fixed along with a new build on the bug.

I've had some success producing problems using scsi_debug with a 64-bit
build, specifically with 1K or 2K sectors. Actually a lot of odd things
happen with those sector sizes, and they happen whether using my patch
or reverting the two patches that change hfsplus to using bio, so those
problems seem unrelated. What I see is that the free/used space numbers
reported by df don't make sense given the actual files I've copied to
the volume. If I "fill" the volume (in quotes because really I haven't
copied in enough data to fill the volume, but it says it's full anyway)
df reports complete garbage. Then if I proceed to remove all files from
the volume df still reports that 50% of the space is used. These
problems aren't present with 512 byte or 4K sectors.

What I also see are GPFs in memory allocation code, which is what I
believe others have seen with my patch, and so far I haven't seen those
with the reversions. So I'm suspecting memory corruption, but I don't
yet see where the corruption is coming form. I found one problem, but I
don't suspect it's responsible for the GPFs.

I'm still investigating, but I won't really be able to spend much more
time on it until Monday.

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