From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 205957] Ext4 64 bit hash breaks 32 bit glibc 2.28+
Date: Sat, 28 Dec 2019 11:20:10 +0000 [thread overview]
Message-ID: <bug-205957-13602-ilzvZjRWFg@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-205957-13602@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205957
--- Comment #12 from Andreas Dilger (adilger.kernelbugzilla@dilger.ca) ---
Created attachment 286491
--> https://bugzilla.kernel.org/attachment.cgi?id=286491&action=edit
add ioctl(EXT4_IOC_SET_DIRLIMIT) to limit directory cookie size
Totally untested prototype patch to add ioctl(fd, EXT4_IOC_SET_DIRLIMIT, 32)
that could be used by glibc/QEMU to force ext4 to return a 32-bit directory
offset cookie for the 64-bit getdirent64() syscall on a per-fd basis.
The glibc patch would look something like the following, though this could
potentially be done only once per open:
+ // It is affected by "__USE_FILE_OFFSET64" and "__USE_LARGEFILE64".
+ if (sizeof (outp->u.d_off) != sizeof (inp->k.d_off))
+ (void *) ioctl (fd, EXT4_IOC_SET_DIRLIMIT, 32); // ignore error return
+
retval = INLINE_SYSCALL_CALL (getdents64, fd, kbuf, kbytes);
If glibc/QEMU want ext4 to be totally transparent w.r.t. the behavior of the
syscalls, then glibc/QEMU would need set the kernel task state so that
is_32bit_api()->in_compat_syscall() return true and hash2pos() and related
functions can determine this directly to return a 32-bit pos in a manner
similar to x86. That is outside my area of expertise, so I can't really
suggest how it might be done. It would also be possible to add some different
logic to is_32bit_api() for ARM/etc. so that it is more transparent to
userspace, but I don't know what it should check.
--
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2019-12-28 11:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-24 14:07 [Bug 205957] New: Ext4 64 bit hash breaks 32 bit glibc 2.28+ bugzilla-daemon
2019-12-24 14:07 ` [Bug 205957] " bugzilla-daemon
2019-12-24 15:09 ` bugzilla-daemon
2019-12-24 18:16 ` bugzilla-daemon
2019-12-25 22:50 ` bugzilla-daemon
2019-12-25 22:51 ` bugzilla-daemon
2019-12-25 22:51 ` bugzilla-daemon
2019-12-25 22:52 ` bugzilla-daemon
2019-12-25 22:52 ` bugzilla-daemon
2019-12-25 22:52 ` bugzilla-daemon
2019-12-25 22:53 ` bugzilla-daemon
2019-12-28 7:50 ` bugzilla-daemon
2019-12-28 9:00 ` bugzilla-daemon
2019-12-28 11:20 ` bugzilla-daemon [this message]
2020-01-05 21:47 ` bugzilla-daemon
2020-01-05 22:08 ` bugzilla-daemon
2020-01-08 23:11 ` bugzilla-daemon
2020-01-09 20:02 ` bugzilla-daemon
2020-10-02 10:03 ` bugzilla-daemon
2020-10-02 10:34 ` bugzilla-daemon
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-205957-13602-ilzvZjRWFg@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-ext4@vger.kernel.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 NNTP newsgroup(s).