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
next prev parent 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 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.