From: Lars-Peter Clausen <lars@metafoo.de>
To: "Lluís Batlle i Rossell" <viric@viric.name>
Cc: linux-mips@linux-mips.org
Subject: Re: Broken readdir() since 3.5 for ext3 on mips-n32
Date: Mon, 05 Nov 2012 22:33:29 +0100 [thread overview]
Message-ID: <509830A9.5050205@metafoo.de> (raw)
In-Reply-To: <20121105212019.GN2052@vicerveza.homeunix.net>
On 11/05/2012 10:20 PM, Lluís Batlle i Rossell wrote:
> Hello,
>
> with the help of Lars on irc, we've tracked down the issue to a broken readdir()
> in ext3 in n32, introduced in the kernel 3.5 by this commit:
> d7dab39b6e16d5eea78ed3c705d2a2d0772b4f06
>
> That renders ext3 quite useless in mips n32.
>
> In a kernel after that commit, the example program in the 'getdents' man page
> returns this:
> [root@fu2:~/readdir]# ./getdents
> --------------- nread=116 ---------------
> i-node# file type d_reclen d_off d_name
> 3694 regular 20 1780583312 prova.c
> 1037850 regular 24 -985956880 getdents.c
> 1037848 directory 16 -1999547753 .
> 1037849 regular 20 222381689 getdents
> 778241 directory 16 -1849228342 ..
> 3647 regular 20 -1 prova
>
>
> I took Lars suggestion of applying the patch I attach (forcing ext3 to think it
> is a 32-bit system), and then all works. init (upstart) doesn't deadlock anymore, readdir() works fine, and the getdents info looks right:
> [root@fu2:~/readdir]# ./getdents
> --------------- nread=116 ---------------
> i-node# file type d_reclen d_off d_name
> 3694 regular 20 334739480 prova.c
> 1037850 regular 24 473707228 getdents.c
> 1037848 directory 16 824759881 .
> 1037849 regular 20 875064456 getdents
> 778241 directory 16 1524836457 ..
> 3647 regular 20 2147483647 prova
>
> How to solve this, I don't know. But it seems that ext3 thinks that mips-n32
> programs can eat some 64-bit words in d_off.
I think the issue here is that is_compat_task() returns false if both o32 and
n32 support are built into the kernel.
is_compat_task() is defined is
static inline int is_compat_task(void)
{
return test_thread_flag(TIF_32BIT);
}
and TIF_32BIT is defined as
#ifdef CONFIG_MIPS32_O32
#define TIF_32BIT TIF_32BIT_REGS
#elif defined(CONFIG_MIPS32_N32)
#define TIF_32BIT _TIF_32BIT_ADDR
#endif /* CONFIG_MIPS32_O32 */
the n32 personality only sets TIF_32BIT_ADDR, so the test will fail. Also
shouldn't it be '#define TIF_32BIT TIF_32BIT_ADDR' instead of '#define
TIF_32BIT _TIF_32BIT_ADDR'?
>
> Regards,
> Lluís.
>
> On Mon, Nov 05, 2012 at 08:32:21AM +0100, Lluís Batlle i Rossell wrote:
>> This same issue below happens to me in 3.5.7 too. So, the change is somewhere
>> between 3.4 and 3.5.
>>
>> Regards,
>> Lluís.
>>
>> On Mon, Nov 05, 2012 at 12:21:19AM +0100, Lluís Batlle i Rossell wrote:
>>> I've investigated better the issue.
>>>
>>> I found that, in 3.4 vs 3.6.4, the behaviour that changed is that of readdir().
>>>
>>> Using the same userland binaries, I've run a little program in both kernels:
>>> -------- prova.c
>>> #include <sys/types.h>
>>> #include <dirent.h>
>>>
>>> int main() {
>>> DIR *d = opendir("/etc/init");
>>>
>>> if (d == NULL) {
>>> fprintf(stderr, "d NULL\n");
>>> return -1;
>>> }
>>>
>>> struct dirent *ent;
>>> ent = readdir(d);
>>>
>>> if (ent == NULL) {
>>> fprintf(stderr, "ent NULL\n");
>>> return -1;
>>> }
>>> }
>>> -----------
>>>
>>>
>>> This program does not print anything on 3.4, but on 3.6, it prints "ent NULL".
>>>
>>> In both cases, /etc/init is full of symlinks, like this (from a script session
>>> in 3.6.4):
>>> -------
>>> S'ha iniciat l'execució de script a dl 05 nov 2012 00:16:53 CET
>>> sh-4.2# ./prova
>>> ent NULL
>>> sh-4.2# ls -ld /etc/init
>>> drwxr-xr-x 2 root root 4096 5 nov 00:12 /etc/init
>>> sh-4.2# ls -l /etc/init
>>> total 0
>>> lrwxrwxrwx 1 root root 25 5 nov 00:12 atd.conf -> /etc/static/init/atd.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 boot.conf -> /etc/static/init/boot.conf
>>> lrwxrwxrwx 1 root root 40 5 nov 00:12 control-alt-delete.conf -> /etc/static/init/control-alt-delete.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 cron.conf -> /etc/static/init/cron.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 dbus.conf -> /etc/static/init/dbus.conf
>>> lrwxrwxrwx 1 root root 28 5 nov 00:12 dhcpcd.conf -> /etc/static/init/dhcpcd.conf
>>> lrwxrwxrwx 1 root root 37 5 nov 00:12 emergency-shell.conf -> /etc/static/init/emergency-shell.conf
>>> lrwxrwxrwx 1 root root 37 5 nov 00:12 invalidate-nscd.conf -> /etc/static/init/invalidate-nscd.conf
>>> lrwxrwxrwx 1 root root 25 5 nov 00:12 kbd.conf -> /etc/static/init/kbd.conf
>>> lrwxrwxrwx 1 root root 27 5 nov 00:12 klogd.conf -> /etc/static/init/klogd.conf
>>> lrwxrwxrwx 1 root root 25 5 nov 00:12 lvm.conf -> /etc/static/init/lvm.conf
>>> lrwxrwxrwx 1 root root 30 5 nov 00:12 mountall.conf -> /etc/static/init/mountall.conf
>>> lrwxrwxrwx 1 root root 36 5 nov 00:12 mountall-ip-up.conf -> /etc/static/init/mountall-ip-up.conf
>>> lrwxrwxrwx 1 root root 34 5 nov 00:12 mount-failed.conf -> /etc/static/init/mount-failed.conf
>>> lrwxrwxrwx 1 root root 32 5 nov 00:12 networking.conf -> /etc/static/init/networking.conf
>>> lrwxrwxrwx 1 root root 40 5 nov 00:12 network-interfaces.conf -> /etc/static/init/network-interfaces.conf
>>> lrwxrwxrwx 1 root root 32 5 nov 00:12 nix-daemon.conf -> /etc/static/init/nix-daemon.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 nscd.conf -> /etc/static/init/nscd.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 ntpd.conf -> /etc/static/init/ntpd.conf
>>> lrwxrwxrwx 1 root root 30 5 nov 00:12 runlevel.conf -> /etc/static/init/runlevel.conf
>>> lrwxrwxrwx 1 root root 30 5 nov 00:12 shutdown.conf -> /etc/static/init/shutdown.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 sshd.conf -> /etc/static/init/sshd.conf
>>> lrwxrwxrwx 1 root root 29 5 nov 00:12 syslogd.conf -> /etc/static/init/syslogd.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 tty1.conf -> /etc/static/init/tty1.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 tty2.conf -> /etc/static/init/tty2.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 tty3.conf -> /etc/static/init/tty3.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 tty4.conf -> /etc/static/init/tty4.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 tty5.conf -> /etc/static/init/tty5.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 tty6.conf -> /etc/static/init/tty6.conf
>>> lrwxrwxrwx 1 root root 26 5 nov 00:12 udev.conf -> /etc/static/init/udev.conf
>>> lrwxrwxrwx 1 root root 33 5 nov 00:12 udevtrigger.conf -> /etc/static/init/udevtrigger.conf
>>> sh-4.2# exit
>>>
>>> S'ha finalitzat l'execució de script a dl 05 nov 2012 00:17:22 CET
>>> --------
>>>
>>>
>>>
>>>
>>> On Fri, Nov 02, 2012 at 07:38:28PM +0100, Lluís Batlle i Rossell wrote:
>>>> Hello,
>>>>
>>>> updating my kernel from 3.4.2 to 3.6.4, I've noticed that upstart deadlocks at
>>>> the very start. Stracing, I think it has to do with INOTIFY, because it
>>>> deadlocks very early and little more has been done then.
>>>>
>>>> Going 'back' to 3.4.16, makes upstart work fine. I've not tested middle kernels.
>>>>
>>>> I've seen this only on the fuloong minipc (mips n64), but I've done similar
>>>> steps with the same distributions on armv5tel, i686 and x86_64, and there all
>>>> works fine.
>>>>
>>>> Does anybody know of anything broken around inotify, between 3.4 and 3.6 linux
>>>> mips?
>>>>
>>>> Any suggestion on what kernel change could have related to this, and so, get a
>>>> clue about what middle version to test?
>>>>
>>>> Regards,
>>>> Lluís.
>
prev parent reply other threads:[~2012-11-05 21:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-02 18:38 Failing INOTIFY in 3.6.x? Lluís Batlle i Rossell
2012-11-04 23:21 ` Failing readdir() on 3.6 (was: Failing INOTIFY in 3.6.x?) Lluís Batlle i Rossell
2012-11-05 7:32 ` Lluís Batlle i Rossell
2012-11-05 21:20 ` Broken readdir() since 3.5 for ext3 on mips-n32 Lluís Batlle i Rossell
2012-11-05 21:23 ` Lluís Batlle i Rossell
2012-11-05 21:33 ` Lars-Peter Clausen [this message]
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=509830A9.5050205@metafoo.de \
--to=lars@metafoo.de \
--cc=linux-mips@linux-mips.org \
--cc=viric@viric.name \
/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