From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: netdev@vger.kernel.org
Cc: Neil Horman <nhorman@tuxdriver.com>,
Vlad Yasevich <vyasevich@gmail.com>,
linux-sctp@vger.kernel.org
Subject: [PATCH v2 0/2] Avoid link dependency of dlm on sctp module
Date: Tue, 14 Jul 2015 17:13:23 +0000 [thread overview]
Message-ID: <cover.1436891629.git.marcelo.leitner@gmail.com> (raw)
Hi,
I'm trying to remove a direct dependency of dlm module on sctp one.
Currently dlm code is calling sctp_do_peeloff() directly and this call
only is causing the load of sctp module together with dlm. For that, we
have basically 3 options:
- Doing a module split on dlm
- which I'm avoiding because it was already split and was merged (more
info on patch2 changelog)
- and the sctp code on it is rather small if compared with sctp module
itself
- Using some other infra that gets indirectly activated, like getsockopt()
- It was like this before, but the exposed sockopt created a file
descriptor for the new socket and that create some serious issues.
More info on 2f2d76cc3e93 ("dlm: Do not allocate a fd for peeloff")
- Doing something like ipv6_stub (which is used by vxlan) or similar
- but I don't feel that's a good way out here, it doesn't feel right.
So I'm approaching this by going with 2nd option again but this time
also creating a new sockopt that is only accessible for kernel users of
this protocol, so that we are safe to directly return a struct socket *
via getsockopt() results.
"Kernel users" are identified by sockets that don't have a file
descriptor attached to it, as only kernel users are allowed to do that
and, if original socket has a file descriptor, one should just use the
original option.
I kept __user marker on sctp_getsockopt_peeloff_kernel() prototype and
its helpers just to avoid issues with static checkers.
I tried minimizing the code duplication while adding the new option, but
it's just better to add a whole new function to handle it. As the
sockopt arguments are different, the only thing in common between both
call handlers is the call to sctp_do_peeloff(). All rest would have to
have checks around it.
RFC->v1, from Neil:
- For identifying kernel users, switched from segment_eq() to fd check
- Reused original option to avoid code duplication
v1->v2, from David:
- Back to new sockopt implementation, to avoid changing sockopt arg
format.
Marcelo Ricardo Leitner (2):
sctp: add new getsockopt option SCTP_SOCKOPT_PEELOFF_KERNEL
dlm: avoid using sctp_do_peeloff directly
fs/dlm/lowcomms.c | 17 ++++++++---------
include/uapi/linux/sctp.h | 12 ++++++++++++
net/sctp/socket.c | 37 +++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+), 9 deletions(-)
--
2.4.1
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: netdev@vger.kernel.org
Cc: Neil Horman <nhorman@tuxdriver.com>,
Vlad Yasevich <vyasevich@gmail.com>,
linux-sctp@vger.kernel.org
Subject: [PATCH v2 0/2] Avoid link dependency of dlm on sctp module
Date: Tue, 14 Jul 2015 14:13:23 -0300 [thread overview]
Message-ID: <cover.1436891629.git.marcelo.leitner@gmail.com> (raw)
Hi,
I'm trying to remove a direct dependency of dlm module on sctp one.
Currently dlm code is calling sctp_do_peeloff() directly and this call
only is causing the load of sctp module together with dlm. For that, we
have basically 3 options:
- Doing a module split on dlm
- which I'm avoiding because it was already split and was merged (more
info on patch2 changelog)
- and the sctp code on it is rather small if compared with sctp module
itself
- Using some other infra that gets indirectly activated, like getsockopt()
- It was like this before, but the exposed sockopt created a file
descriptor for the new socket and that create some serious issues.
More info on 2f2d76cc3e93 ("dlm: Do not allocate a fd for peeloff")
- Doing something like ipv6_stub (which is used by vxlan) or similar
- but I don't feel that's a good way out here, it doesn't feel right.
So I'm approaching this by going with 2nd option again but this time
also creating a new sockopt that is only accessible for kernel users of
this protocol, so that we are safe to directly return a struct socket *
via getsockopt() results.
"Kernel users" are identified by sockets that don't have a file
descriptor attached to it, as only kernel users are allowed to do that
and, if original socket has a file descriptor, one should just use the
original option.
I kept __user marker on sctp_getsockopt_peeloff_kernel() prototype and
its helpers just to avoid issues with static checkers.
I tried minimizing the code duplication while adding the new option, but
it's just better to add a whole new function to handle it. As the
sockopt arguments are different, the only thing in common between both
call handlers is the call to sctp_do_peeloff(). All rest would have to
have checks around it.
RFC->v1, from Neil:
- For identifying kernel users, switched from segment_eq() to fd check
- Reused original option to avoid code duplication
v1->v2, from David:
- Back to new sockopt implementation, to avoid changing sockopt arg
format.
Marcelo Ricardo Leitner (2):
sctp: add new getsockopt option SCTP_SOCKOPT_PEELOFF_KERNEL
dlm: avoid using sctp_do_peeloff directly
fs/dlm/lowcomms.c | 17 ++++++++---------
include/uapi/linux/sctp.h | 12 ++++++++++++
net/sctp/socket.c | 37 +++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+), 9 deletions(-)
--
2.4.1
next reply other threads:[~2015-07-14 17:13 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-14 17:13 Marcelo Ricardo Leitner [this message]
2015-07-14 17:13 ` [PATCH v2 0/2] Avoid link dependency of dlm on sctp module Marcelo Ricardo Leitner
2015-07-14 17:13 ` [PATCH v2 1/2] sctp: add new getsockopt option SCTP_SOCKOPT_PEELOFF_KERNEL Marcelo Ricardo Leitner
2015-07-14 17:13 ` Marcelo Ricardo Leitner
2015-07-15 13:18 ` Neil Horman
2015-07-15 13:18 ` Neil Horman
2015-07-15 13:24 ` Marcelo Ricardo Leitner
2015-07-15 13:24 ` Marcelo Ricardo Leitner
2015-07-15 20:58 ` David Miller
2015-07-15 20:58 ` David Miller
2015-07-16 13:50 ` Vlad Yasevich
2015-07-16 13:50 ` Vlad Yasevich
2015-07-16 14:03 ` Marcelo Ricardo Leitner
2015-07-16 14:03 ` Marcelo Ricardo Leitner
2015-07-20 18:53 ` Marcelo Ricardo Leitner
2015-07-20 18:53 ` Marcelo Ricardo Leitner
2015-07-22 13:13 ` David Laight
2015-07-22 13:50 ` Marcelo
2015-07-22 13:50 ` Marcelo
2015-07-14 17:13 ` [PATCH v2 2/2] dlm: avoid using sctp_do_peeloff directly Marcelo Ricardo Leitner
2015-07-14 17:13 ` Marcelo Ricardo Leitner
2015-07-15 13:57 ` [PATCH v2 0/2] Avoid link dependency of dlm on sctp module Neil Horman
2015-07-15 13:57 ` Neil Horman
2015-07-15 20:59 ` David Miller
2015-07-15 20:59 ` David Miller
2015-07-16 11:18 ` Neil Horman
2015-07-16 11:18 ` 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=cover.1436891629.git.marcelo.leitner@gmail.com \
--to=marcelo.leitner@gmail.com \
--cc=linux-sctp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--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.