From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: Paul Moore <paul.moore@hp.com>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, Chris Van Hoof <vanhoof@redhat.com>,
Clark Williams <williams@redhat.com>,
linux-security-module@vger.kernel.org
Subject: Re: [RFC 1/2] net: Introduce recvmmsg socket syscall
Date: Thu, 21 May 2009 11:47:39 -0300 [thread overview]
Message-ID: <20090521144739.GF5956@ghostprotocols.net> (raw)
In-Reply-To: <200905211016.17328.paul.moore@hp.com>
Em Thu, May 21, 2009 at 10:16:17AM -0400, Paul Moore escreveu:
> On Wednesday 20 May 2009 07:06:52 pm Arnaldo Carvalho de Melo wrote:
> > Meaning receive multiple messages, reducing the number of syscalls and
> > net stack entry/exit operations.
>
> NOTE: adding the LSM list to the CC line
thanks!
> If this approach is accepted I wonder if it would also make sense to move the
> security_socket_recvmsg() hook out of __sock_recvmsg and into the callers. I
> personally can't see a reason why we would need to call into the LSM for each
> message in the case of the new recvmmsg() syscall. The downside is that there
> is now some code duplication (although we are only talking duplicating ~three
> lines of code) but the upside is that we wont end up calling into the LSM for
> each of the messages when recvmmsg() is called which seems to fit well with
> the performance oriented nature of the new syscall.
Agreed that we must do this earlier to avoind vlen calls to
security_socket_recvmsg, but there are many callers of sock_recvmsg...
Also shouldn't recvmmsg have a different LSM hook? It doesn't look right
at first sight to reuse security_socket_recvmsg, as we now are passing
many msghdrs and sockaddrs, etc.
If security_socket_recvmsg receives the msg and inspects it, I think
fully inspecting the mmsg and vlen can be something LSM policies can be
interested in inspecting too, no?
- Arnaldo
next prev parent reply other threads:[~2009-05-21 14:47 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-20 23:06 [RFC 1/2] net: Introduce recvmmsg socket syscall Arnaldo Carvalho de Melo
2009-05-21 0:46 ` Neil Horman
2009-05-21 2:05 ` Arnaldo Carvalho de Melo
2009-05-21 2:26 ` Neil Horman
2009-05-21 3:50 ` David Miller
2009-05-21 10:40 ` Neil Horman
2009-05-21 14:16 ` Paul Moore
2009-05-21 14:47 ` Arnaldo Carvalho de Melo [this message]
2009-05-21 15:03 ` Paul Moore
2009-05-21 15:11 ` Arnaldo Carvalho de Melo
2009-05-21 15:24 ` Paul Moore
2009-05-21 16:10 ` Evgeniy Polyakov
2009-05-21 16:27 ` Arnaldo Carvalho de Melo
2009-05-21 16:33 ` Steven Whitehouse
2009-05-21 16:45 ` Arnaldo Carvalho de Melo
2009-05-21 16:38 ` Caitlin Bestler
2009-05-21 16:55 ` Arnaldo Carvalho de Melo
2009-05-21 17:26 ` Caitlin Bestler
2009-05-21 17:51 ` Arnaldo Carvalho de Melo
2009-05-22 8:32 ` steve
2009-05-22 7:22 ` Rémi Denis-Courmont
2009-05-22 8:31 ` steve
2009-05-22 16:39 ` Caitlin Bestler
2009-05-22 20:06 ` Neil Horman
2009-06-04 1:44 ` Andrew Grover
2009-06-04 1:46 ` Arnaldo Carvalho de Melo
2009-06-04 10:47 ` Neil Horman
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=20090521144739.GF5956@ghostprotocols.net \
--to=acme@redhat.com \
--cc=davem@davemloft.net \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul.moore@hp.com \
--cc=vanhoof@redhat.com \
--cc=williams@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).