Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 516988 - >=sys-fs/e2fsprogs-1.42.10: fails to build on <uclibc-0.9.33.2-r14 due to missing fallocate64().
Summary: >=sys-fs/e2fsprogs-1.42.10: fails to build on <uclibc-0.9.33.2-r14 due to mis...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on: 539226
Blocks: CVE-2015-0247
  Show dependency tree
 
Reported: 2014-07-12 18:24 UTC by Anthony Basile
Modified: 2015-02-07 13:17 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Use posix_fallocate64() if fallocate64() is unavailable (0001-Use-posix_fallocate64-if-fallocate64-is-unavailable.patch,3.71 KB, patch)
2014-07-12 18:55 UTC, Anthony Basile
Details | Diff
Use posix_fallocate64() if fallocate64() is unavailable (0001-misc-e4defrag.c-use-posix_fallocate64-if-fallocate64.patch,4.01 KB, patch)
2014-07-31 19:05 UTC, Anthony Basile
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Basile gentoo-dev 2014-07-12 18:24:54 UTC
The build fails upon trying to compile misc/e4defag:

make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/var/tmp/portage/sys-fs/e2fsprogs-1.42.10/work/e2fsprogs-1.42.10/debugfs'
making all in misc
make[2]: Entering directory `/var/tmp/portage/sys-fs/e2fsprogs-1.42.10/work/e2fsprogs-1.42.10/misc'
x86_64-gentoo-linux-uclibc-gcc -c -I. -I../lib -I../lib  -D_GNU_SOURCE -O2 -pipe e4defrag.c -o e4defrag.o
e4defrag.c:201:2: error: #error fallocate64 not available!
make[2]: *** [e4defrag.o] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-fs/e2fsprogs-1.42.10/work/e2fsprogs-1.42.10/misc'
make[1]: *** [all-progs-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/sys-fs/e2fsprogs-1.42.10/work/e2fsprogs-1.42.10'
make: *** [all] Error 2


The code intentionally commits suicide with

#ifndef HAVE_FALLOCATE64
#error fallocate64 not available!
#endif /* ! HAVE_FALLOCATE64 */


Indeed, uclibc doesn't have fallocate64() but it *does* have posix_fallocate64().  Since fallocate64() is called with mode = 0, the behaviour of the two should be the same.  man 2 fallocate for reference.

We could either port fallocate/fallocate64() to uclibc or make e2fsprogs more posix-ish.  I blame e2fsprogs.  The patch is easy enough.  Patching just the C file for now (eventually we need to get the build system checking for all the right stuff):


--- e4defrag.c.orig	2014-07-12 18:23:07.455118894 +0000
+++ e4defrag.c	2014-07-12 18:23:30.828248798 +0000
@@ -197,10 +197,6 @@
 #error sync_file_range not available!
 #endif /* ! HAVE_SYNC_FILE_RANGE */
 
-#ifndef HAVE_FALLOCATE64
-#error fallocate64 not available!
-#endif /* ! HAVE_FALLOCATE64 */
-
 /*
  * get_mount_point() -	Get device's mount point.
  *
@@ -1552,7 +1548,7 @@
 	/* Allocate space for donor inode */
 	orig_group_tmp = orig_group_head;
 	do {
-		ret = fallocate64(donor_fd, 0,
+		ret = posix_fallocate64(donor_fd,
 		  (loff_t)orig_group_tmp->start->data.logical * block_size,
 		  (loff_t)orig_group_tmp->len * block_size);
 		if (ret < 0) {


I will be masking =sys-fs/e2fsprogs-1.42.10 on uclibc profiles until this is fixed.

Reproducible: Always
Comment 1 Anthony Basile gentoo-dev 2014-07-12 18:55:20 UTC
Created attachment 380646 [details, diff]
Use posix_fallocate64() if fallocate64() is unavailable

This patch applies against git/HEAD:

    git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git

I'll send it upstream.
Comment 2 Anthony Basile gentoo-dev 2014-07-12 19:07:46 UTC
(In reply to Anthony Basile from comment #1)
> Created attachment 380646 [details, diff] [details, diff]
> Use posix_fallocate64() if fallocate64() is unavailable
> 
> This patch applies against git/HEAD:
> 
>     git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
> 
> I'll send it upstream.

Hmm ... not sure where upstream is.  I tried to just email it directly to Ts'o
Comment 3 Anthony Basile gentoo-dev 2014-07-31 19:05:20 UTC
Created attachment 381958 [details, diff]
Use posix_fallocate64() if fallocate64() is unavailable

Updated version of the patch emailed to linux-ext4@vger.kernel.org.  See

    http://www.spinics.net/lists/linux-ext4/msg44537.html

for any discussions.
Comment 4 SpanKY gentoo-dev 2014-08-03 14:38:44 UTC
looks reasonable to me ... i might even suggest they should only use posix_fallocate considering that func is in POSIX and fallocate is not
Comment 5 Anthony Basile gentoo-dev 2014-08-20 18:14:42 UTC
(In reply to SpanKY from comment #4)
> looks reasonable to me ... i might even suggest they should only use
> posix_fallocate considering that func is in POSIX and fallocate is not

Here's Ts'o response and then mine to him:

http://www.spinics.net/lists/linux-ext4/msg44671.html

His concern is that some implementations of posix_fallocate() just fall back on brute force zero-ing.  At least for uclibc and musl this is not the case.  I don't know of any libc that does that and doesn't just syscall fallocate.

Anyhow, if the kernel doesn't provide the syscall, how else can you implement fallocate except by brute force?  I'm not sure what else to say to him.
Comment 6 Anthony Basile gentoo-dev 2014-09-13 13:04:08 UTC
(In reply to Anthony Basile from comment #5)
> (In reply to SpanKY from comment #4)
> > looks reasonable to me ... i might even suggest they should only use
> > posix_fallocate considering that func is in POSIX and fallocate is not
> 
> Here's Ts'o response and then mine to him:
> 
> http://www.spinics.net/lists/linux-ext4/msg44671.html
> 
> His concern is that some implementations of posix_fallocate() just fall back
> on brute force zero-ing.  At least for uclibc and musl this is not the case.
> I don't know of any libc that does that and doesn't just syscall fallocate.
> 
> Anyhow, if the kernel doesn't provide the syscall, how else can you
> implement fallocate except by brute force?  I'm not sure what else to say to
> him.

Rather than fight ext4 upstream, I've gotten fallocate/fallocate64 into uclibc.  The commit is at

http://git.uclibc.org/uClibc/commit/?id=33a12b5540b8abbc4ee0ecb3a51912b3c7868517

It still needs to be backported to 0.9.33.  It doesn't apply cleanly.  I can prepare a backport patch but how do I get it into 0.9.33?
Comment 7 Anthony Basile gentoo-dev 2014-09-16 11:27:33 UTC
(In reply to Anthony Basile from comment #6)
> 
> It still needs to be backported to 0.9.33.  It doesn't apply cleanly.  I can
> prepare a backport patch but how do I get it into 0.9.33?

I emailed the backport to the list:

http://lists.uclibc.org/pipermail/uclibc/2014-September/048621.html

I have yet to check how it applies against the current uClibc-0.9.33.2-patches-14.tar.bz.
Comment 8 Anthony Basile gentoo-dev 2014-11-11 11:13:44 UTC
(In reply to Anthony Basile from comment #7)
> (In reply to Anthony Basile from comment #6)
> > 
> > It still needs to be backported to 0.9.33.  It doesn't apply cleanly.  I can
> > prepare a backport patch but how do I get it into 0.9.33?
> 
> I emailed the backport to the list:
> 
> http://lists.uclibc.org/pipermail/uclibc/2014-September/048621.html
> 
> I have yet to check how it applies against the current
> uClibc-0.9.33.2-patches-14.tar.bz.

ping.  Can I get this in the next patchset.
Comment 9 Anthony Basile gentoo-dev 2015-01-10 16:34:42 UTC
@mike, I added the needed patches to the patchset in cvs, rolled a patch using make-tarball.sh and put it on woodpecker's /space/distfile-local and in my dev space at ~blueness/uclibc.  Its PATCH_VER="15".  I also bumped the ebuild to 0.9.33.2-r13. I'd like to stabilize this in about 1-2 months because it is blocking progress on e2fsprogs on all my uclibc builds.

Please let me know if I did anything wrong.
Comment 10 Anthony Basile gentoo-dev 2015-02-07 13:17:27 UTC
>=uclibc-0.9.33.2-r14 is now stable on all but m68k sh and sparc.  All versions of e2fsprogs up to the latest 1.42.12 build fine.  I'm going to close this bug in favor of but #539226 which is the final stablereq for m68k sh and sparc.