* [PATCH] Avoid capable() call in UNIX buffer check unless necessary
@ 2009-11-18 15:17 Dan Smith
[not found] ` <1258557477-28642-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Dan Smith @ 2009-11-18 15:17 UTC (permalink / raw)
To: containers-qjLDD68F18O7TbgM5vRIOg
As pointed out by Serge, we shouldn't call capable() unless we know we'll
need to exercise the ability.
Signed-off-by: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org
---
net/unix/checkpoint.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/net/unix/checkpoint.c b/net/unix/checkpoint.c
index 23040ce..55dfac1 100644
--- a/net/unix/checkpoint.c
+++ b/net/unix/checkpoint.c
@@ -278,9 +278,18 @@ static int sock_read_buffer_sendmsg(struct ckpt_ctx *ctx,
unix_sk(sk)->peer->sk_shutdown &= ~SHUTDOWN_MASK;
}
- /* Make sure there's room in the send buffer */
+ /* Make sure there's room in the send buffer: Worst case, we
+ * give them the benefit of the doubt and set the buffer limit
+ * to the system default. This should cover the case where
+ * the user set the limit low after loading up the buffer.
+ *
+ * However, if there isn't room in the buffer and the system
+ * default won't accommodate them either, then increase the
+ * limit as needed, only if they have CAP_NET_ADMIN.
+ */
sndbuf = sk->sk_sndbuf;
if (((sk->sk_sndbuf - atomic_read(&sk->sk_wmem_alloc)) < h->lin_len) &&
+ (h->lin_len > sysctl_wmem_max) &&
capable(CAP_NET_ADMIN))
sk->sk_sndbuf += h->lin_len;
else
--
1.6.2.5
^ permalink raw reply related [flat|nested] 3+ messages in thread[parent not found: <1258557477-28642-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH] Avoid capable() call in UNIX buffer check unless necessary [not found] ` <1258557477-28642-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> @ 2009-11-18 15:35 ` Serge E. Hallyn 2009-11-25 18:52 ` Oren Laadan 1 sibling, 0 replies; 3+ messages in thread From: Serge E. Hallyn @ 2009-11-18 15:35 UTC (permalink / raw) To: Dan Smith; +Cc: containers-qjLDD68F18O7TbgM5vRIOg Quoting Dan Smith (danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org): > As pointed out by Serge, we shouldn't call capable() unless we know we'll > need to exercise the ability. > > Signed-off-by: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> > Cc: serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org thanks Acked-by: Serge Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> > --- > net/unix/checkpoint.c | 11 ++++++++++- > 1 files changed, 10 insertions(+), 1 deletions(-) > > diff --git a/net/unix/checkpoint.c b/net/unix/checkpoint.c > index 23040ce..55dfac1 100644 > --- a/net/unix/checkpoint.c > +++ b/net/unix/checkpoint.c > @@ -278,9 +278,18 @@ static int sock_read_buffer_sendmsg(struct ckpt_ctx *ctx, > unix_sk(sk)->peer->sk_shutdown &= ~SHUTDOWN_MASK; > } > > - /* Make sure there's room in the send buffer */ > + /* Make sure there's room in the send buffer: Worst case, we > + * give them the benefit of the doubt and set the buffer limit > + * to the system default. This should cover the case where > + * the user set the limit low after loading up the buffer. > + * > + * However, if there isn't room in the buffer and the system > + * default won't accommodate them either, then increase the > + * limit as needed, only if they have CAP_NET_ADMIN. > + */ > sndbuf = sk->sk_sndbuf; > if (((sk->sk_sndbuf - atomic_read(&sk->sk_wmem_alloc)) < h->lin_len) && > + (h->lin_len > sysctl_wmem_max) && > capable(CAP_NET_ADMIN)) > sk->sk_sndbuf += h->lin_len; > else > -- > 1.6.2.5 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Avoid capable() call in UNIX buffer check unless necessary [not found] ` <1258557477-28642-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> 2009-11-18 15:35 ` Serge E. Hallyn @ 2009-11-25 18:52 ` Oren Laadan 1 sibling, 0 replies; 3+ messages in thread From: Oren Laadan @ 2009-11-25 18:52 UTC (permalink / raw) To: Dan Smith; +Cc: containers-qjLDD68F18O7TbgM5vRIOg Queued for v19-rc2, thanks. Oren. Dan Smith wrote: > As pointed out by Serge, we shouldn't call capable() unless we know we'll > need to exercise the ability. > > Signed-off-by: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> > Cc: serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org > --- > net/unix/checkpoint.c | 11 ++++++++++- > 1 files changed, 10 insertions(+), 1 deletions(-) > > diff --git a/net/unix/checkpoint.c b/net/unix/checkpoint.c > index 23040ce..55dfac1 100644 > --- a/net/unix/checkpoint.c > +++ b/net/unix/checkpoint.c > @@ -278,9 +278,18 @@ static int sock_read_buffer_sendmsg(struct ckpt_ctx *ctx, > unix_sk(sk)->peer->sk_shutdown &= ~SHUTDOWN_MASK; > } > > - /* Make sure there's room in the send buffer */ > + /* Make sure there's room in the send buffer: Worst case, we > + * give them the benefit of the doubt and set the buffer limit > + * to the system default. This should cover the case where > + * the user set the limit low after loading up the buffer. > + * > + * However, if there isn't room in the buffer and the system > + * default won't accommodate them either, then increase the > + * limit as needed, only if they have CAP_NET_ADMIN. > + */ > sndbuf = sk->sk_sndbuf; > if (((sk->sk_sndbuf - atomic_read(&sk->sk_wmem_alloc)) < h->lin_len) && > + (h->lin_len > sysctl_wmem_max) && > capable(CAP_NET_ADMIN)) > sk->sk_sndbuf += h->lin_len; > else ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-11-25 18:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-18 15:17 [PATCH] Avoid capable() call in UNIX buffer check unless necessary Dan Smith
[not found] ` <1258557477-28642-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-11-18 15:35 ` Serge E. Hallyn
2009-11-25 18:52 ` Oren Laadan
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.