netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next] rds: do not call ->conn_alloc with GFP_KERNEL
@ 2018-02-12 23:30 Sowmini Varadhan
  2018-02-13 17:04 ` David Miller
  0 siblings, 1 reply; 3+ messages in thread
From: Sowmini Varadhan @ 2018-02-12 23:30 UTC (permalink / raw)
  To: davem, netdev, sowmini.varadhan
  Cc: sowmini.varadhan, santosh.shilimkar, rds-devel

Commit ebeeb1ad9b8a ("rds: tcp: use rds_destroy_pending() to synchronize
netns/module teardown and rds connection/workq management") adds an
rcu read critical section to __rds_conn_create. The memory allocations
in that critcal section need to use GFP_ATOMIC to avoid sleeping.

This patch was verified with syzkaller reproducer.

Reported-by: syzbot+a0564419941aaae3fe3c@syzkaller.appspotmail.com
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Fixes: ebeeb1ad9b8a ("rds: tcp: use rds_destroy_pending() to synchronize
netns/module teardown and rds connection/workq management")
---
 net/rds/connection.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/net/rds/connection.c b/net/rds/connection.c
index 94e190f..d0f5889 100644
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -221,6 +221,8 @@ static void __rds_conn_path_init(struct rds_connection *conn,
 		conn->c_path[i].cp_index = i;
 	}
 	rcu_read_lock();
+	gfp &= ~GFP_KERNEL;
+	gfp |= GFP_ATOMIC;
 	if (rds_destroy_pending(conn))
 		ret = -ENETDOWN;
 	else
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH net-next] rds: do not call ->conn_alloc with GFP_KERNEL
  2018-02-12 23:30 [PATCH net-next] rds: do not call ->conn_alloc with GFP_KERNEL Sowmini Varadhan
@ 2018-02-13 17:04 ` David Miller
  2018-02-13 17:07   ` Sowmini Varadhan
  0 siblings, 1 reply; 3+ messages in thread
From: David Miller @ 2018-02-13 17:04 UTC (permalink / raw)
  To: sowmini.varadhan; +Cc: netdev, santosh.shilimkar, rds-devel

From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Mon, 12 Feb 2018 15:30:38 -0800

> diff --git a/net/rds/connection.c b/net/rds/connection.c
> index 94e190f..d0f5889 100644
> --- a/net/rds/connection.c
> +++ b/net/rds/connection.c
> @@ -221,6 +221,8 @@ static void __rds_conn_path_init(struct rds_connection *conn,
>  		conn->c_path[i].cp_index = i;
>  	}
>  	rcu_read_lock();
> +	gfp &= ~GFP_KERNEL;
> +	gfp |= GFP_ATOMIC;
>  	if (rds_destroy_pending(conn))
>  		ret = -ENETDOWN;
>  	else

I'd never seen this kind of gfp masking before, so I did a grep around
and the only cases I saw of this kind of usage were for things like
GFP_DMA and such.

I could not find one case that did it to convert a sleeping into a non-
sleeping GFP mask.

Let's not over-engineer this.  For one thing, whatever allocation bits
came down from the callers, we are going to lose here.

So just pass straight GFP_ATOMIC into the routines below here instead
of the 'gfp' variable.

Thanks.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH net-next] rds: do not call ->conn_alloc with GFP_KERNEL
  2018-02-13 17:04 ` David Miller
@ 2018-02-13 17:07   ` Sowmini Varadhan
  0 siblings, 0 replies; 3+ messages in thread
From: Sowmini Varadhan @ 2018-02-13 17:07 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, santosh.shilimkar, rds-devel

On (02/13/18 12:04), David Miller wrote:
> 
> Let's not over-engineer this.  For one thing, whatever allocation bits
> came down from the callers, we are going to lose here.

Ok, I was wondering how much of the sk_allocation we want to keep in
the future, so I did this admittedly weird thing. I'll change it
to the obvious and submit v3.

--Sowmini

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-02-13 17:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-02-12 23:30 [PATCH net-next] rds: do not call ->conn_alloc with GFP_KERNEL Sowmini Varadhan
2018-02-13 17:04 ` David Miller
2018-02-13 17:07   ` Sowmini Varadhan

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).