All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: David Miller <davem@davemloft.net>
Cc: marcelo.leitner@gmail.com, netdev@vger.kernel.org, vyasevich@gmail.com
Subject: Re: [PATCH 1/2] sctp: SCTP_SOCKOPT_PEELOFF return socket pointer for kernel users
Date: Mon, 13 Jul 2015 06:39:11 -0400	[thread overview]
Message-ID: <20150713103911.GA9631@hmsreliant.think-freely.org> (raw)
In-Reply-To: <20150710.182114.1532697560595947999.davem@davemloft.net>

On Fri, Jul 10, 2015 at 06:21:14PM -0700, David Miller wrote:
> From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Date: Thu,  9 Jul 2015 11:15:19 -0300
> 
> > SCTP has this operation to peel off associations from a given socket and
> > create a new socket using this association. We currently have two ways
> > to use this operation:
> > - via getsockopt(), on which it will also create and return a file
> >   descriptor for this new socket
> > - via sctp_do_peeloff(), which is for kernel only
> > 
> > The caveat with using sctp_do_peeloff() directly is that it creates a
> > dependency to SCTP module, while all other operations are handled via
> > kernel_{socket,sendmsg,getsockopt...}() interface. This causes the
> > kernel to load SCTP module even when it's not directly used
> > 
> > This patch then updates SCTP_SOCKOPT_PEELOFF so that for kernel users of
> > this protocol it will not allocate a file descriptor but instead just
> > return the socket pointer directly.
> > 
> > If called by an user application it will work as before.
> > 
> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> 
> I do not like this at all.
> 
> Socket option implementations should not change their behavior or what
> datastructures they consume or return just because the socket happens
> to be a kernel socket.
> 
But in this case its necessecary, as the kernel here can't allocate an fd, due
to serious leakage (see commit 2f2d76cc3e938389feee671b46252dde6880b3b7).
Initially Marcelo had created duplicate code paths, one to return an fd, one to
return a file struct.  If you would rather go in that direction, I'm sure he can
propose it again, but that seems less correct to me than this solution.

> I'm not applying this series, sorry.
> 
> Also, your patch series lacked an intial "PATCH 0/N" posting, so you
> could at least spend the time to discuss this patch series at a high
> level and explain your overall motivations.
> 
That was in the initial posting.  It should have been reposted, but if you're
interested:
http://marc.info/?l=linux-sctp&m=143449456219518&w=2

Regards
Neil

  reply	other threads:[~2015-07-13 10:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-09 14:15 [PATCH 1/2] sctp: SCTP_SOCKOPT_PEELOFF return socket pointer for kernel users Marcelo Ricardo Leitner
2015-07-09 14:15 ` [PATCH 2/2] dlm: avoid using sctp_do_peeloff directly Marcelo Ricardo Leitner
2015-07-10 10:25   ` Neil Horman
2015-07-10 10:25 ` [PATCH 1/2] sctp: SCTP_SOCKOPT_PEELOFF return socket pointer for kernel users Neil Horman
2015-07-11  1:21 ` David Miller
2015-07-13 10:39   ` Neil Horman [this message]
2015-07-13 13:19     ` Marcelo Ricardo Leitner
2015-07-13 18:59     ` David Miller
2015-07-13 19:05       ` Marcelo Ricardo Leitner
2015-07-13 19:58         ` David Miller
2015-07-13 20:06           ` Marcelo Ricardo Leitner

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=20150713103911.GA9631@hmsreliant.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=davem@davemloft.net \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=vyasevich@gmail.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 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.