All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Conole <aconole@bytheb.org>
To: Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org
Subject: Re: [PATCH v2] [net] af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag
Date: Sun, 20 Sep 2015 15:07:56 -0400	[thread overview]
Message-ID: <87twqo7vub.fsf@bytheb.org> (raw)
In-Reply-To: <1442767564.29850.35.camel@edumazet-glaptop2.roam.corp.google.com> (Eric Dumazet's message of "Sun, 20 Sep 2015 09:46:04 -0700")

Eric Dumazet <eric.dumazet@gmail.com> writes:

> On Sun, 2015-09-20 at 05:18 -0400, Aaron Conole wrote:
>> From: Aaron Conole <aaron@bytheb.org>
>> 
>
> I am wondering what this is expected to do, and how this code would
> possibly not trigger a crash.
Are you suspecting it should crash from a possible double-lock case?
On line 2125, there is an unconditional unlock, which should be 
guaranteeing that there is no longer a condition to 'double lock' the
socket.

With my patch, I re-do a lock just before entering skb_peek_next, and
then loop to again: label (line 2078); I admit that there is a check
at the top of the loop which I do not include (the check for SOCK_DEAD).
Do you think this check is needed (and the cause for your concern on
the suspected crash)?

I will re-do the testing as you outline later, and report the results.

> Are you 100% sure you tested this patch and code path ?
Yes, 100%; I used the python code attached to the bug before hacking on
this function whatsoever to ensure that the bug still exists in current
kernel (it does). Then after my patch, I reran the same test. There 
were no oops, bugs, panics, or other errors reported.

> Before resending v3, please make sure to compile and test with
> CONFIG_LOCKDEP=y. Add a temporary (in your tree, not final patch)
>
> pr_err_once("went there at least one time\n");
>
> (to make sure this code path was tested)
I will do this testing as requested; my current config does include
LOCKDEP_SUPPORT=y.

> It might be time to get rid of unix_sk macro for a proper function to
> avoid these kind of errors.
>
> diff --git a/include/net/af_unix.h b/include/net/af_unix.h
> index 4a167b30a12f..cb1b9bbda332 100644
> --- a/include/net/af_unix.h
> +++ b/include/net/af_unix.h
> @@ -63,7 +63,11 @@ struct unix_sock {
>  #define UNIX_GC_MAYBE_CYCLE	1
>  	struct socket_wq	peer_wq;
>  };
> -#define unix_sk(__sk) ((struct unix_sock *)__sk)
> +
> +static inline struct unix_sock *unix_sk(struct sock *sk)
> +{
> +	return (struct unix_sock *)sk;
> +}
>  
>  #define peer_wait peer_wq.wait
If you'd like, I'll add this to a V3 version of this patch, re-do
testing with your requested config above, and report the results.

> Thanks.
Thank you for the feedback, it is very good.

-Aaron

  reply	other threads:[~2015-09-20 19:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-20  9:18 [PATCH v2] [net] af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag Aaron Conole
2015-09-20 16:46 ` Eric Dumazet
2015-09-20 19:07   ` Aaron Conole [this message]
2015-09-20 19:21     ` Eric Dumazet
     [not found]       ` <87h9mo7ui9.fsf@bytheb.org>
2015-09-20 19:38         ` Aaron Conole

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=87twqo7vub.fsf@bytheb.org \
    --to=aconole@bytheb.org \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@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.