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
next prev parent 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$(echo .)org \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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