netdev - Re: [RFC 1/2] net: Introduce recvmmsg socket syscall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090521104052.GB25369@hmsreliant.think-freely.org>
Date:	Thu, 21 May 2009 06:40:52 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	David Miller <davem@...emloft.net>
Cc:	acme@...hat.com, netdev@...r.kernel.org, vanhoof@...hat.com,
	williams@...hat.com
Subject: Re: [RFC 1/2] net: Introduce recvmmsg socket syscall

On Wed, May 20, 2009 at 08:50:44PM -0700, David Miller wrote:
> From: Neil Horman <nhorman@...driver.com>
> Date: Wed, 20 May 2009 22:26:21 -0400
> 
> > I agree, your way of doing this definately lets you layer on top of
> > the existing vetted implementation, which is nice, I just thought
> > that avoiding the creation of another syscall might be worth a
> > little extra work in the kernel.  Instead of arrays of msghdrs, We'd
> > be looking at chains like this: msghdr->(struct msghdr
> > *)msg_control[i].data->msghdr->etc
> > 
> > Not too hard to parse, I dont think.  But I'll defer to brighter
> > minds than mine.  If the creation of another syscall isn't too
> > difficult a barrier to overcome (assuming this is going to occur for
> > sendmsg, and various other i/o ops as well), then your way here is
> > probably the way to go.
> 
> Unfortunately you can't use msg flags for this.
> 
> We accept any message flag we don't understand without signalling
> any errors.
> 

I assume that silently ignoring flags we don't understand is a specified part
of the sockets api?  I was looking at the posix definition of recvmsg and I
don't see where its required that we ignore unknown flags (although I can see
why it would be usefull to do so)

> So there is no way to determine if the kernel supports the flag
> or not.  Whereas with a socket option, we'll always get an error
> on older kernels for unsupported options.
> 
> I think the system call is the cleanest, because it's not only a
> semantic change but also a data type change.  I also think the
> socket option scheme is too cumbersome.  I think it would be
> common for an application to want to use both modes of sending,
> especially if that application uses lots of existing library
> mode to compose some messages.  And extra setsockopt() around
> every call down into that library?  Yikes, good luck getting
> that right all the time.  It's way too error prone.

The new system call is definately cleaner, as it lets you specify the array
semantics in a way that is much more efficient and less cumbersome for both user
and kernel space.  I just thought I'd propose an alternate method that avoids
the need for a new syscall.  It sounds like you and Acme have already hashed
through this though, so I'll sit down :)

Thanks guys!
Neil

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html