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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.