Re: in_compat_syscall() returns from kernel thread for X86_32.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: in_compat_syscall() returns from kernel thread for X86_32.
- From: "Theodore Y. Ts'o" <tytso@xxxxxxx>
- Date: Wed, 24 Oct 2018 09:15:34 -0400
- Cc: Andy Lutomirski <luto@xxxxxxxxxx>, Andreas Dilger <adilger.kernel@xxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Dmitry Safonov <dsafonov@xxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Denys Vlasenko <dvlasenk@xxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Brian Gerst <brgerst@xxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, linux-tip-commits@xxxxxxxxxxxxxxx, jsimmons@xxxxxxxxxxxxx
- In-reply-to: <871s8g6roy.fsf@notabene.neil.brown.name>
- Mail-followup-to: "Theodore Y. Ts'o" <tytso@xxxxxxx>, NeilBrown <neilb@xxxxxxxx>, Andy Lutomirski <luto@xxxxxxxxxx>, Andreas Dilger <adilger.kernel@xxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Dmitry Safonov <dsafonov@xxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Denys Vlasenko <dvlasenk@xxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Brian Gerst <brgerst@xxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, linux-tip-commits@xxxxxxxxxxxxxxx, jsimmons@xxxxxxxxxxxxx
- References: <1460987025-30360-1-git-send-email-dsafonov@virtuozzo.com> <tip-abfb9498ee1327f534df92a7ecaea81a85913bae@git.kernel.org> <87h8hkc9fd.fsf@notabene.neil.brown.name> <CALCETrXB8PE4Ue0BeD0wUS9psLLjpv_pt+nj=SEaj+Nb_dZzUA@mail.gmail.com> <871s8ndg6a.fsf@notabene.neil.brown.name> <CALCETrWH342Y7jKHsYdT=_3fuyDkWhvQLK9z4PTs9jzbfoCVwg@mail.gmail.com> <871s8g6roy.fsf@notabene.neil.brown.name>
- User-agent: Mutt/1.10.1 (2018-07-13)
On Wed, Oct 24, 2018 at 12:47:57PM +1100, NeilBrown wrote:
>
> I doubt it was copied - more likely independent evolution.
> But on reflection, I see that it is probably reasonable that it
> shouldn't be used this way - or at all in this context.
> I'll try to understand what the issues really are and see if I can
> find a solution that doesn't depend on this interface.
> Thanks for your help.
At least for ext4, the primary problem is that we want to use a 64-bit
telldir/seekdir cookie if all 64-bits will make it to user space, and
a 32-bit telldir cookie if only 32 bits will make it userspace. This
impacts NFS as well because if there are people who are still using
NFSv2, which has 32-bit directory offsets, we need to constrain the
telldir/seekdir cookies we give to NFS to be a 32 has as opposed to a
64-bit hash.
- Ted
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]