public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "danny.milo at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user
Date: Fri, 02 Oct 2020 09:36:03 +0000	[thread overview]
Message-ID: <bug-23960-131-9haqaAxsFN@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-23960-131@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=23960

--- Comment #59 from Danny Milosavljevic <danny.milo at gmail dot com> ---
(In reply to Adhemerval Zanella from comment #32)
> I am not against in reverting back to use SYS_getdents for getdents64

SYS_getdents has 32 bit slots, including d_off, in the result and thus the
kernel cannot tell you the truth in the result.  Having the kernel paper over
this seems unwise--this would be/is basically the kernel lying to you.  As with
all lies, the kernel then has to keep some kind of table which lies it told to
whom and be consistent with them.  Why do that?

> although it is a subpar resolution for a kernel issue.  Newer architectures
> with mixed 32 and 64 bits support will continue to be broken without a
> proper kernel fix since they use SYS_getdents64 for getdents.

The kernel is the wrong place to work around this.  glibc should be using 64
bit struct dirent so it can actually handle the truth.

> What I think we should do is:
> 
>   1. *Deprecate* non-LFS usage in a multi-step way as discussed in
> libc-alpha [1]. We will need to take care of the issue brought by Joseph,
> but it will mean eventually the non-LFS interfaces will be just provided as
> compatibility symbols.

I agree.

>   2. Push to distro on 32-bits to *stop* building packages in non-LFS mode
> as default. Some distro already gets this right, but it seems some still
> lacking support.

For that to happen, please make glibc at least emit a warning--although with a
problem this bad, I'd prefer an error--if _FILE_OFFSET_BITS != 64 and
SIZEOF_LONG < 8 and readdir is used.

I use this in dirent.h:

#ifndef _LIBC
#if __SIZEOF_LONG__ < 8
#ifndef __USE_FILE_OFFSET64
#if defined(_FILE_OFFSET_BITS) && _FILE_OFFSET_BITS == 32
#warning \"Using -D_FILE_OFFSET_BITS=32 and using readdir is a bad idea, see
<https://bugzilla.kernel.org/show_bug.cgi?id=205957>\"
#else
#undef readdir
#define readdir @READDIR_WITHOUT_FILE_OFFSET64_IS_A_REALLY_BAD_IDEA@
#endif
#endif
#endif
#endif

It's much better to find problems this way than to have programs fail at random
times at runtime depending on file system internals.

Or use gcc's "deprecated" attribute on readdir, with a message, in order to at
least warn.  But, really, does this sound like something harmless enough to
only warn?  It does not to me.

>   3. Continue to push kernel developers to provide a correct fix for this
> issue. 

We shouldn't do that in the kernel (see beginning of this text).

It's impossible to store a 64 bit result into a 32 bit slot.

Also, if you call SYS_getdents64, you should expect a 64 bit result.  It's in
the name.

Please don't use SYS_getdents.  Just please mandate LFS instead.  This should
have been done long (decades) ago.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2020-10-02  9:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-23960-131@http.sourceware.org/bugzilla/>
2019-05-01 20:33 ` chewi at gentoo dot org
2020-09-17 21:42 ` tg at mirbsd dot de
2020-10-02  8:54 ` danny.milo at gmail dot com
2020-10-02  9:36 ` danny.milo at gmail dot com [this message]
2020-10-02  9:46 ` fweimer at redhat dot com
2020-10-02 10:41 ` danny.milo at gmail dot com
2020-10-02 11:03 ` danny.milo at gmail dot com
2020-10-02 13:17 ` jrtc27 at jrtc27 dot com
2020-10-02 14:22 ` adhemerval.zanella at linaro dot org
2020-10-02 23:06 ` tg at mirbsd dot de
2020-10-03 13:54 ` fweimer at redhat dot com
2020-10-03 13:55 ` fweimer at redhat dot com
2021-08-24 11:48 ` glaubitz at physik dot fu-berlin.de
2022-05-15 20:53 ` glaubitz at physik dot fu-berlin.de
2022-05-16 12:06 ` adhemerval.zanella at linaro dot org
2022-05-16 20:11 ` glaubitz at physik dot fu-berlin.de
2022-05-16 20:15 ` adhemerval.zanella at linaro dot org
2022-05-17  4:39 ` sam at gentoo dot org
2022-12-06 15:50 ` glaubitz at physik dot fu-berlin.de
2023-01-13  4:52 ` deller at gmx dot de
2023-12-29 23:52 ` sam at gentoo dot org
2024-01-05  8:33 ` sam at gentoo dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-23960-131-9haqaAxsFN@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).