On Fri, Oct 30, 2020 at 7:42 PM Dmitry Vyukov wrote:
>
> On Fri, Oct 30, 2020 at 2:02 PM Miklos Szeredi wrote:
> >
> > On Mon, Aug 24, 2020 at 11:00 PM Ondrej Mosnacek
> > wrote:
> > >
> > > On Mon, Aug 24, 2020 at 9:37 PM syzbot
> > > w
On Mon, Aug 24, 2020 at 11:00 PM Ondrej Mosnacek wrote:
>
> On Mon, Aug 24, 2020 at 9:37 PM syzbot
> wrote:
> > syzbot has found a reproducer for the following issue on:
>
> Looping in fsdevel and OverlayFS maintainers, as this seems to be
> FS/OverlayFS related...
Hmm, the oopsing code is alway
On Tue, Oct 4, 2016 at 3:51 AM, David Miller wrote:
> From: Miklos Szeredi
> Date: Thu, 29 Sep 2016 14:09:14 +0200
>
>> @@ -1550,6 +1550,17 @@ static int unix_attach_fds(struct scm_cookie *scm,
>> struct sk_buff *skb)
>> return max_level;
>> }
>&g
escriptors. This prevents problems from a pure in-flight
socket having its buffers modified while the garbage collect is taking
place.
Signed-off-by: Miklos Szeredi
Cc:
---
include/net/af_unix.h | 1 +
net/unix/af_unix.c| 15 +--
net/unix/garbage.c| 5 +
3 files changed, 19
On Tue, Aug 30, 2016 at 11:31 AM, Nikolay Borisov wrote:
>
>
> On 08/30/2016 12:18 PM, Miklos Szeredi wrote:
>> On Tue, Aug 30, 2016 at 12:37 AM, Miklos Szeredi wrote:
>>> On Sat, Aug 27, 2016 at 11:55 AM, Miklos Szeredi
>>> wrote:
>>
>>> c
On Tue, Aug 30, 2016 at 12:37 AM, Miklos Szeredi wrote:
> On Sat, Aug 27, 2016 at 11:55 AM, Miklos Szeredi wrote:
> crash> list -H gc_inflight_list unix_sock.link -s unix_sock.inflight |
> grep counter | cut -d= -f2 | awk '{s+=$1} END {print s}'
> 130
>
On Sat, Aug 27, 2016 at 11:55 AM, Miklos Szeredi wrote:
>
> On Wed, Aug 24, 2016 at 11:40 PM, Hannes Frederic Sowa
> wrote:
> > On 24.08.2016 16:24, Nikolay Borisov wrote:
> >> Hello,
> >>
> >> I hit the following BUG:
> &g
On Wed, Aug 24, 2016 at 11:40 PM, Hannes Frederic Sowa
wrote:
> On 24.08.2016 16:24, Nikolay Borisov wrote:
>> Hello,
>>
>> I hit the following BUG:
>>
>> [1851513.239831] [ cut here ]
>> [1851513.240079] kernel BUG at net/unix/garbage.c:149!
>> [1851513.240313] invalid opc
> > > > mm-page_file_methods.patch
> > > >
> > > > This makes page_offset and others more expensive by adding a
> > > > conditional jump to a function call that is not usually made.
> > > >
> > > > Why do swap pages have a different index to everyone else?
> > >
> > > Because the pag
> > mm-page_file_methods.patch
> >
> > This makes page_offset and others more expensive by adding a
> > conditional jump to a function call that is not usually made.
> >
> > Why do swap pages have a different index to everyone else?
>
> Because the page->index of an anonymous page is
is not really needed. Just require ->set_page_dirty() be
filled in by filesystems which want swapfiles (and others too, in the
longer term, the fallback is just historical crud).
Here's an incremental patch addressing these issues and beautifying
t
> This looks good, patch applied and I'll get this into the
> 2.6.23 merge window.
>
> Once this sits around for a while and we feel super-confident
> with it we can consider a backport into -stable.
OK. Thanks for the review.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe n
> > Dave, I really appreciate the work you do. Please forgive my
> > impatience.
>
> No problem.
>
> Your patch is first in line for me to review tomorrow ok?
Great, thanks.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
> > This may seem low priority and irrelevant, but it _is_ a bug, and it's
> > affecting a real world application. So please take that into
> > consideration.
>
> I'm not the only person who hasn't reviewed your latest patch yet.
>
> You may want to consider that this might have something to do
> > But myself, nor any other developers, are going to review your work
> > any faster if you do things like try to slip things in behind the
> > maintainer's back as you attempted to do yesterday by asking Andrew to
> > put your AF_UNIX garbage collector rewrite directly into his -mm tree.
>
> mm
> > On Tue, 10 Jul 2007 11:50:30 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> >
> > > Can you please add this to -mm. Sometimes that has wonderful effect
> > > on the willingness of people to look at a patch.
> >
> > sure ;)
>
> Andrew
least.
Thanks,
Miklos
From: Miklos Szeredi <[EMAIL PROTECTED]>
Throw out the old mark & sweep garbage collector and put in a
refcounting cycle detecting one.
The old one had a race with recvmsg, that resulted in false positives
and hence data loss. The old algorithm operated on all
From: Miklos Szeredi <[EMAIL PROTECTED]>
Throw out the old mark & sweep garbage collector and put in a
refcounting cycle detecting one.
The old one had a race with recvmsg, that resulted in false positives
and hence data loss. The old algorithm operated on all unix sockets
in the syst
Please review.
Apologies if the patch itself is not too readable due to lots of code
being replaced, but the end result is quite clear I think.
From: Miklos Szeredi <[EMAIL PROTECTED]>
Throw out the old mark & sweep garbage collector and put in a
refcounting cycle detecting one
> > Right. But the devil is in the details, and (as you correctly point
> > out later) to implement this, the whole locking scheme needs to be
> > overhauled. Problems:
> >
> > - Using the queue lock to make the dequeue and the fd detach atomic
> >wrt the GC is difficult, if not impossible:
t or
> >> > vice versa during garbage collection. Since gc is done with a
> >> > spinlock held, this only shows up on SMP.
> >> >
> >> > Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
> >>
> >> I'm going to hold of
> > No, correctness always trumps performance. Lost packets on an AF_UNIX
> > socket are _unexceptable_, and this is definitely not a theoretical
> > problem.
>
> If its so unacceptable why has nobody noticed until now - its a bug
> clearly, it needs fixing clearly, but unless you can produce som
> > > I'm all for fixing this gc mess that we have now. But please don't
> > > expect me to be the one who's doing it.
> >
> > Don't worry, I only expect you to make the situation worse :-)
>
> In any event, I'll try to find some time to look more at your patch.
>
> But just like you don't want
> > I'm all for fixing this gc mess that we have now. But please don't
> > expect me to be the one who's doing it.
>
> Don't worry, I only expect you to make the situation worse :-)
That's real nice. Looks like finding and fixing bugs in not
appreciated in the networking subsystem :-/
Miklos
-
> > but it's not as if it's really going to affect performance
> > in real cases.
>
> Since these circumstances are creatable by any user, we have
> to consider the cases caused by malicious entities.
OK. But then the whole gc thing is already broken, since a user can
DoS socket creation/destruc
> * Thomas Graf <[EMAIL PROTECTED]> 2007-06-18 12:32
> > * Miklos Szeredi <[EMAIL PROTECTED]> 2007-06-18 11:44
> > > Garbage collection only ever happens, if the app is sending AF_UNIX
> > > sockets over AF_UNIX sockets. Which is a rather rare case. And whi
> * Miklos Szeredi <[EMAIL PROTECTED]> 2007-06-18 11:44
> > Garbage collection only ever happens, if the app is sending AF_UNIX
> > sockets over AF_UNIX sockets. Which is a rather rare case. And which
> > is basically why this bug went unnoticed for so long.
>
> > > Secondarily, this bug has been around for years and nobody noticed.
> > > The world will not explode if this bug takes a few more days or
> > > even a week to work out. Let's do it right instead of ramming
> > > arbitrary turds into the kernel.
> >
> > Fine, but just wishing a bug to get fi
> > > > And is anyone working on a better patch?
> > >
> > > I have no idea.
> > >
> > > > Those patches aren't "bad" in the correctness sense. So IMO any one
> > > > of them is better, than having that bug in there.
> > >
> > > You're adding a very serious performance regression, which is
> >
> > And is anyone working on a better patch?
>
> I have no idea.
>
> > Those patches aren't "bad" in the correctness sense. So IMO any one
> > of them is better, than having that bug in there.
>
> You're adding a very serious performance regression, which is
> about as bad as the bug itself.
N
> From: Miklos Szeredi <[EMAIL PROTECTED]>
> Date: Mon, 18 Jun 2007 09:49:32 +0200
>
> > Ping Dave,
> >
> > Since there doesn't seem to be any new ideas forthcoming, can we
> > please decide on either one of my two sumbitted patches?
>
> Yo
away
> > > perfectly good packets with AF_UNIX sockets in them.
> > >
> > > The problems arise when a socket goes from installed to in-flight or
> > > vice versa during garbage collection. Since gc is done with a
> > > spinlock held, this only shows u
ice versa during garbage collection. Since gc is done with a
> > spinlock held, this only shows up on SMP.
> >
> > Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
>
> I'm going to hold off on this one for now.
>
> Holding all of the read locks kind of
r a short duration, and unix_gc() should only rarely be called. So
> > I don't think there's any performance problem here.
>
> It pulls a non-local cacheline into the local thread, that's extremely
> expensive on SMP.
OK, here's an updated patch, that uses -&
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> > Date: Mon, 04 Jun 2007 11:45:32 +0200
> >
> > > > A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
> > > > send()+close() on the peer, causing recv() to return zero, even
> > I just want to win the "who's laziest?" league. It would take me
> > about 5 minutes to get the netdev tree and test compile the change.
> > Of which 5 seconds would be actually updating the patch. I was
> > thought it was OK to pass that 5 seconds worth of hard work to you in
> > order to sa
lector, that can throw away perfectly good
> > packets with AF_UNIX sockets in them.
> >
> > The problems arise when a socket goes from installed to in-flight or
> > vica versa during garbage collection. Since gc is done with a
> > spinlock held, this only shows up
s arise when a socket goes from installed to in-flight or
vica versa during garbage collection. Since gc is done with a
spinlock held, this only shows up on SMP.
The following patch fixes it for me, but it's possibly the wrong
approach.
Signed-off-by: Miklos Szeredi <[EMAIL PROT
-flight or
vica versa during garbage collection. Since gc is done with a
spinlock held, this only shows up on SMP.
The following patch fixes it for me, but it's possibly the wrong
approach.
Signed-off-by: Miklos Szeredi <[EMAIL PROT
From: Miklos Szeredi <[EMAIL PROTECTED]>
A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
send()+close() on the peer, causing recv() to return zero, even though
the sent data should be received.
This happens if the send() and the close() is performed between
skb_dequeue() and ch
patch makes sure, that at least the already installed
fds are sent to userspace. It doesn't solve the issue of losing file
descriptors in case of an EFAULT on the userspace buffer.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/net
41 matches
Mail list logo
