netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ken-ichirou MATSUZAWA <chamaken@gmail.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: netdev@vger.kernel.org, fw@strlen.de, David Miller <davem@davemloft.net>
Subject: Re: [PATCHv1 net-next 0/5] netlink: mmap: kernel panic and some issues
Date: Sat, 15 Aug 2015 11:25:05 +0900	[thread overview]
Message-ID: <20150815022505.GA30991@gmail.com> (raw)
In-Reply-To: <55CDC51D.1060204@iogearbox.net>

 Hi,

Thank you for taking your time and trying to understand, even though
one of samples is wrong. correct one is:

    rx only mmaped nflog sample:
    https://gist.github.com/chamaken/dc0f80c14862e8061c06/raw/365c8a106840368f313a3791958da9be0f5fbed0/rxring-nflog.c

> >Currently, what happens is that the shared info accesses whatever
> >memory is there in the mmaped region. So when you already do an
> >skb_clone() you should already get into trouble right there f.e. when
> >we test for orphaning frags etc (if at the right offset in the mmap
> >buffer, the tx_flags member would contain a SKBTX_DEV_ZEROCOPY bit).

And I'm afraid of a skb which does not have shared info can be released
by kfree_skb or not if the next frame is valid. i.e. the current
skb->end, shared info points to the next frame's nm_status, say
NL_MMAP_STATUS_SKIP, and handle it as shared info pointer.

> Ken-ichirou, have you observed this issue only in relation to nlmon?

Yes,

> if taps are indeed the only ones affected, it might probably not be
> worth adding that much complexity for a fix itself, but to keep it simple
> instead. I don't know if there are any real users of netlink mmap, but

You mean mmaped skb can not be monitored by nlmon for a while?
I'll follow you, it's tough for me to fix this issue.

> It seems you have some other, separate fixes in your series, so you might
> want to submit them separately against the net tree, instead?

I'll follow you too.
Thank you, I appreciate.

>  include/linux/netlink.h  |  4 ++++
>  net/netlink/af_netlink.c | 12 +++++++-----
>  2 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/netlink.h b/include/linux/netlink.h
> index 9120edb..42cdcd8 100644
> --- a/include/linux/netlink.h
> +++ b/include/linux/netlink.h
> @@ -35,6 +35,10 @@ struct netlink_skb_parms {
>  #define NETLINK_CB(skb)		(*(struct netlink_skb_parms*)&((skb)->cb))
>  #define NETLINK_CREDS(skb)	(&NETLINK_CB((skb)).creds)
> 
> +static inline bool netlink_skb_is_mmaped(const struct sk_buff *skb)
> +{
> +	return NETLINK_CB(skb).flags & NETLINK_SKB_MMAPED;
> +}
> 
>  extern void netlink_table_grab(void);
>  extern void netlink_table_ungrab(void);
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 67d2104..4307446 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -238,6 +238,13 @@ static void __netlink_deliver_tap(struct sk_buff *skb)
> 
>  static void netlink_deliver_tap(struct sk_buff *skb)
>  {
> +	/* Netlink mmaped skbs must not access shared info, and thus
> +	 * are not allowed to be cloned. For now, just don't allow
> +	 * them to get inspected by taps.
> +	 */
> +	if (netlink_skb_is_mmaped(skb))
> +		return;
> +
>  	rcu_read_lock();
> 
>  	if (unlikely(!list_empty(&netlink_tap_all)))
> @@ -278,11 +285,6 @@ static void netlink_rcv_wake(struct sock *sk)
>  }
> 
>  #ifdef CONFIG_NETLINK_MMAP
> -static bool netlink_skb_is_mmaped(const struct sk_buff *skb)
> -{
> -	return NETLINK_CB(skb).flags & NETLINK_SKB_MMAPED;
> -}
> -
>  static bool netlink_rx_is_mmaped(struct sock *sk)
>  {
>  	return nlk_sk(sk)->rx_ring.pg_vec != NULL;
> -- 
> 1.9.3

  reply	other threads:[~2015-08-15  2:25 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-22 13:17 [RFC PATCH 0/5] netlink: mmap kernel panic and some issues Ken-ichirou MATSUZAWA
2015-08-12  8:28 ` [PATCHv1 net-next 0/5] netlink: mmap: " Ken-ichirou MATSUZAWA
2015-08-12  8:31   ` [PATCHv1 net-next 1/5] netlink: mmap: introduce mmaped skb helper functions Ken-ichirou MATSUZAWA
2015-08-12  8:32   ` [PATCHv1 net-next 2/5] netlink: mmap: apply " Ken-ichirou MATSUZAWA
2015-08-12  8:34   ` [PATCHv1 net-next 3/5] netlink: mmap: fix status for not delivered skb Ken-ichirou MATSUZAWA
2015-08-12  8:35   ` [PATCHv1 net-next 4/5] netlink: mmap: update tx type check Ken-ichirou MATSUZAWA
2015-08-12  8:38   ` [PATCHv1 net-next 5/5] netlink: mmap: notify only when NL_MMAP_STATUS_VALID frame exists Ken-ichirou MATSUZAWA
2015-08-12 23:38   ` [PATCHv1 net-next 0/5] netlink: mmap: kernel panic and some issues David Miller
2015-08-14  8:58     ` Ken-ichirou MATSUZAWA
2015-08-14 10:01       ` Daniel Borkmann
2015-08-14 10:38         ` Daniel Borkmann
2015-08-15  2:25           ` Ken-ichirou MATSUZAWA [this message]
2015-08-17 21:02           ` David Miller
2015-08-19 14:29             ` Daniel Borkmann
2015-09-02  0:04               ` Ken-ichirou MATSUZAWA
2015-09-02  9:47                 ` Daniel Borkmann
2015-09-02 11:35                   ` Ken-ichirou MATSUZAWA
2015-09-02 15:56                     ` Daniel Borkmann
2015-09-02 22:27                       ` Ken-ichirou MATSUZAWA
2015-09-07 14:54             ` Daniel Borkmann
2015-09-09  5:59               ` David Miller
2015-09-09  8:53               ` Thomas Graf
2015-09-09  9:22                 ` Daniel Borkmann
2015-08-20  3:43           ` [PATCH net] netlink: mmap: fix tx type check Ken-ichirou MATSUZAWA
2015-08-23 23:06             ` David Miller
2015-08-20  5:54           ` [PATCH net] netlink: rx mmap: fix POLLIN condition Ken-ichirou MATSUZAWA
2015-08-26  3:17             ` David Miller
2015-08-28  7:00               ` Ken-ichirou MATSUZAWA
2015-08-28  7:05                 ` [PATCH net] netlink: mmap: fix lookup frame position Ken-ichirou MATSUZAWA
2015-08-29  5:26                   ` David Miller
2015-08-30 22:54                 ` [PATCH net] netlink: rx mmap: fix POLLIN condition Ken-ichirou MATSUZAWA
2015-08-31  4:56                   ` David Miller
2015-08-20  7:07           ` [PATCH net] netlink: mmap: fix status setting in skb destructor Ken-ichirou MATSUZAWA
2015-08-26  3:22             ` David Miller
2015-08-28  7:37               ` Ken-ichirou MATSUZAWA

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=20150815022505.GA30991@gmail.com \
    --to=chamaken@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).