linux-ext4 - Re: [PATCH] e4defrag: choose the best available posix

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 Jan 2014 11:23:44 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Baruch Siach <baruch@...s.co.il>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH] e4defrag: choose the best available posix_fadvise variant

On Fri, Jan 03, 2014 at 06:57:48AM +0200, Baruch Siach wrote:
> 
> Thanks. You seem to have applied v1 of this patch without the #else comment 
> fix. I'll fix this up in a follow up patch. Please push your tree so I can 
> reference this commit in the log.

Oh, oops.  I'll find the other version of the patch and fix it up.  I
did notice that you had two different patches sent out, and I thought
I had picked the later one, but obviously I didn't.  (Or maybe I
replied to the wrong version.  I'll double check.)

In the future, it would be much appreciated if you included an
explicit v2 in the subject line of the e-mail.

> Another problem with this patch is that it doesn't takes into
> account the problem of passing 64bit values on 32bit
> architectures. See the discussion under NOTES in the syscall(2) man
> page for more information on that. I'll try to address this in
> another patch if you think it's worth it. The solution is likely to
> look quite ugly when taking the arch specific alignment requirements
> also into account. The alternative is to require C library support
> for fadvise64_64 on 32bit architectures.

Ugh.  I wonder how many libc's don't actually support posix_fadvise at
this point.  This hack was put in a at least back in September of
2009.  It's been over three years at this point.  Maybe it's just time
to blow out the build with the error and tell people who complain to
get an upgraded libc.

Even dietlibc has posix_fadvise at this point.  (And fadvise64(),
although interestingly, not posix_fadvise64).

Given how ugly it is to support the syscall, it may be that we're
better off trying to use posix_fadvise64, fadvise64, fadvise, in that
order, and giving up on the direct-call syscall approach.  After all,
syscall interfaces is the reason why we have a C library in the first
place.

You have more experience with uClibc --- are there any platforms where
it doesn't have posix_fadvise, posix_fadvise64, or some similarly
named variant?

Thanks,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html