On Sat, Apr 17, 2021 at 03:11:49PM -0700, Linus Torvalds wrote:
> On Sat, Apr 17, 2021 at 1:35 PM Al Viro wrote:
> >
> > No, wait - we have non-NULL buf->prev_reclen, so we'll hit
> > with buf->error completely ignored. Nevermind.
>
> Yeah, I'm pretty sure I even tested that -EINTR case at one
On Sat, Apr 17, 2021 at 1:35 PM Al Viro wrote:
>
> No, wait - we have non-NULL buf->prev_reclen, so we'll hit
> with buf->error completely ignored. Nevermind.
Yeah, I'm pretty sure I even tested that -EINTR case at one point.
Of course, it could easily have gotten broken again, so that's not a
On Sat, Apr 17, 2021 at 08:30:42PM +, Al Viro wrote:
> and that thing is still there. However, it does *NOT* do what it might
> appear to be doing; it ends up with getdents() returning -EINVAL instead.
> What we need is
> buf->error = -EINTR;
> in addition to that
[tytso Cc'd]
On Sat, Apr 17, 2021 at 06:09:44PM +, Al Viro wrote:
> > Al - fairly trivial patch applied, comments?
>
> Should be fine... FWIW, I've a patch in the same area, making those suckers
> return bool. Seeing that they are only ever called via dir_emit(),
> dir_emit_dot()
> and
On Sat, Apr 17, 2021 at 12:44 PM Eric Dumazet wrote:
>
> I thought put_cmsg() callers were from the kernel, with no possibility
> for user to abuse this interface trying to push GB of data.
My point is that "I thought" is not good enough for the unsafe interfaces.
It needs to be "I can see that
On Sat, Apr 17, 2021 at 6:03 PM Linus Torvalds
wrote:
>
> On Fri, Apr 16, 2021 at 12:24 PM Eric Dumazet wrote:
> >
> > From: Eric Dumazet
> >
> > We have to loop only to copy u64 values.
> > After this first loop, we copy at most one u32, one u16 and one byte.
>
> As Al mentioned, at least in
On Sat, Apr 17, 2021 at 09:27:04AM -0700, Linus Torvalds wrote:
> On Sat, Apr 17, 2021 at 9:08 AM Linus Torvalds
> wrote:
> >
> > Side note: I'm, looking at the readdir cases that I wrote, and I have
> > to just say that is broken too. So "stones and glass houses" etc, and
> > I'll have to fix
On Sat, Apr 17, 2021 at 9:08 AM Linus Torvalds
wrote:
>
> Side note: I'm, looking at the readdir cases that I wrote, and I have
> to just say that is broken too. So "stones and glass houses" etc, and
> I'll have to fix that too.
In particular, the very very old OLD_READDIR interface that only
On Sat, Apr 17, 2021 at 9:03 AM Linus Torvalds
wrote:
>
> Really. The "unsafe" user accesses are named that way very explicitly,
> and for a very very good reason: the safety needs to be guaranteed and
> obvious within the context of those accesses. Not within some "oh,
> nobody will ever call
On Fri, Apr 16, 2021 at 12:24 PM Eric Dumazet wrote:
>
> From: Eric Dumazet
>
> We have to loop only to copy u64 values.
> After this first loop, we copy at most one u32, one u16 and one byte.
As Al mentioned, at least in trivial cases the compiler understands
that the subsequent loops can only
From: Al Viro On Behalf Of Al Viro
> Sent: 16 April 2021 20:44
> On Fri, Apr 16, 2021 at 12:24:13PM -0700, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > We have to loop only to copy u64 values.
> > After this first loop, we copy at most one u32, one u16 and one byte.
>
> Does it actually
On Fri, Apr 16, 2021 at 10:11 PM Eric Dumazet wrote:
>
> On Fri, Apr 16, 2021 at 9:44 PM Al Viro wrote:
> >
> > On Fri, Apr 16, 2021 at 12:24:13PM -0700, Eric Dumazet wrote:
> > > From: Eric Dumazet
> > >
> > > We have to loop only to copy u64 values.
> > > After this first loop, we copy at
On Fri, Apr 16, 2021 at 9:44 PM Al Viro wrote:
>
> On Fri, Apr 16, 2021 at 12:24:13PM -0700, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > We have to loop only to copy u64 values.
> > After this first loop, we copy at most one u32, one u16 and one byte.
>
> Does it actually yield a better
On Fri, Apr 16, 2021 at 12:24:13PM -0700, Eric Dumazet wrote:
> From: Eric Dumazet
>
> We have to loop only to copy u64 values.
> After this first loop, we copy at most one u32, one u16 and one byte.
Does it actually yield a better code?
FWIW, this
void bar(unsigned);
void foo(unsigned n)
{
14 matches
Mail list logo
