linux-kernel - Re: reiserfs issue with 2.6.32.8

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: <dda83e781003031900x3ca243d9kba1df3a8b0e04105@mail.gmail.com>
Date:	Wed, 3 Mar 2010 19:00:24 -0800
From:	Bret Towe <magnade@...il.com>
To:	Christian Kujau <lists@...dbynature.de>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	reiserfs-devel@...r.kernel.org
Subject: Re: reiserfs issue with 2.6.32.8

On Tue, Feb 23, 2010 at 11:03 PM, Christian Kujau <lists@...dbynature.de> wrote:
> On Tue, 23 Feb 2010 at 21:31, Bret Towe wrote:
>> ok attached is strace log of cp on 2.6.32.9
>
> I've run cp through strace as well (copying something from an XFS
> partition to a reiserfs partition, I guess that's what you did too), and
> noticed a small difference at the end:
>
> < open("/home/foo/1", O_RDONLY)          = 3
> < fstat(3, {st_mode=S_IFREG|0640, st_size=755, ...}) = 0
> < open("2", O_WRONLY|O_CREAT|O_EXCL, 0640) = 4
>
> While your cp(1) did:
>
>> open("downloads/[DB]_Bleach_258_[27104F7A].avi", O_RDONLY) = 3
>> fstat(3, {st_mode=S_IFREG|0644, st_size=178308328, ...}) = 0
>> open("/mdhd/media/Episodes/unwatched/[DB]_Bleach_258_[27104F7A].avi", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EINVAL (Invalid argument)
>
>
> And open(2) will return -EINVAL when:
>   - The implementation does not support synchronised I/O for this file.
>   - The value of the oflag argument is not valid.
>
> As we're not passing O_SYNC, it's the latter, if I read this correctly. Which
> still doesn't explain *why* (the filesystem?) returns "invalid flag".
>
>> now I've had a hd drop out of raid (running checks on it atm)
>
> Hm, maybe it's all hardware related after all, let's see what these checks
> turn up. Strange though, that nothing gets reported in dmesg...

well the hardware update ended up changing more than I thought it would
now on 32bit from 64bit so config is completely new also for the kernel
end result tho is I'm on a 2.6.33 kernel and no issues
--
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/