From: David Miller <davem@davemloft.net>
To: eparis@redhat.com
Cc: ebiederm@xmission.com, sgrubb@redhat.com, rgb@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-audit@redhat.com, akpm@linux-foundation.org
Subject: Re: [RFC][PATCH] audit: Simplify by assuming the callers socket buffer is large enough
Date: Mon, 10 Mar 2014 15:30:01 -0400 (EDT) [thread overview]
Message-ID: <20140310.153001.1202621819107314058.davem@davemloft.net> (raw)
In-Reply-To: <1394232722.17779.57.camel@flatline.rdu.redhat.com>
From: Eric Paris <eparis@redhat.com>
Date: Fri, 07 Mar 2014 17:52:02 -0500
> The second user Eric patched, audit_send_list(), can grow without bound.
> The number of skb's is going to be the size of the number of audit rules
> that root loaded. We run the list of rules, generate an skb per rule,
> and add all of them to an skb_buff_head. We then pass the skb_buff_head
> to a kthread so that current will be able to read/drain the socket.
> There really is no limit to how big the skb_buff_head could possibly
> grow. This doesn't necessarily absolutely have to be lossless but it
> can actually quite reasonably be a whole lot of data that needs to get
> sent. I know of no way to deliver unbounded lengths of data to the
> current task via netlink without blocking on more space in the socket.
> Even if the socket rmem was MAX_INT, how can we deliver more? The rule
> size is unbounded. How do I get an unbounded amount of data onto this
> side of the socket when I have to generate it all during the request...
This is what netlink dumps are for. It is how we are able to dump
routing tables with millions of routes to userspace.
By using normal netlink requests and netlink_unicast() for this, you
are ignoring an entire mechanism in netlink designed specifically to
handle this kind of situation.
Netlink dumps track state and build one or more SKBs (as necessary),
one by one, to form the reply. It implements flow control, state
tracking for iteration, optimized SKB sizing and allocation, etc.
next prev parent reply other threads:[~2014-03-10 19:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-28 18:49 [PATCH] audit: Use struct net not pid_t to remember the network namespce to reply in Eric W. Biederman
2014-03-01 1:11 ` Richard Guy Briggs
2014-03-01 4:34 ` Eric W. Biederman
2014-03-01 4:36 ` [PATCH] audit: Send replies in the proper network namespace Eric W. Biederman
2014-03-01 4:50 ` [RFC][PATCH] audit: Simplify by assuming the callers socket buffer is large enough Eric W. Biederman
2014-03-04 21:30 ` Andrew Morton
2014-03-04 21:51 ` David Miller
2014-03-04 22:41 ` Eric W. Biederman
2014-03-04 22:50 ` Andrew Morton
2014-03-10 3:06 ` [GIT PULL] namespaces fixes for 3.14-rcX Eric W. Biederman
2014-03-10 13:59 ` Eric Paris
2014-03-10 19:56 ` Eric W. Biederman
2014-03-16 18:36 ` Richard Guy Briggs
2014-03-05 0:21 ` [RFC][PATCH] audit: Simplify by assuming the callers socket buffer is large enough David Miller
2014-03-05 16:59 ` Steve Grubb
2014-03-05 18:06 ` Eric W. Biederman
2014-03-07 22:52 ` Eric Paris
2014-03-08 0:48 ` David Miller
2014-03-08 3:27 ` Steve Grubb
2014-03-08 6:34 ` David Miller
2014-03-08 3:56 ` Eric Paris
2014-03-10 19:30 ` David Miller [this message]
2014-03-10 21:57 ` Eric Paris
2014-03-16 18:19 ` [PATCH] audit: Send replies in the proper network namespace Richard Guy Briggs
2014-03-16 19:13 ` Richard Guy Briggs
2014-03-16 18:15 ` [PATCH] audit: Use struct net not pid_t to remember the network namespce to reply in Richard Guy Briggs
2014-03-16 19:12 ` Richard Guy Briggs
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=20140310.153001.1202621819107314058.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rgb@redhat.com \
--cc=sgrubb@redhat.com \
/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).