Re: [PATCH 13/18] io_uring: add file set registration

On 2/8/19 5:17 AM, Alan Jenkins wrote:

quoted

+static int io_sqe_files_scm(struct io_ring_ctx *ctx)
+{
+#if defined(CONFIG_NET)
+	struct scm_fp_list *fpl = ctx->user_files;
+	struct sk_buff *skb;
+	int i;
+
+	skb =  __alloc_skb(0, GFP_KERNEL, 0, NUMA_NO_NODE);
+	if (!skb)
+		return -ENOMEM;
+
+	skb->sk = ctx->ring_sock->sk;
+	skb->destructor = unix_destruct_scm;
+
+	fpl->user = get_uid(ctx->user);
+	for (i = 0; i < fpl->count; i++) {
+		get_file(fpl->fp[i]);
+		unix_inflight(fpl->user, fpl->fp[i]);
+		fput(fpl->fp[i]);
+	}
+
+	UNIXCB(skb).fp = fpl;
+	skb_queue_head(&ctx->ring_sock->sk->sk_receive_queue, skb);

This code sounds elegant if you know about the existence of unix_gc(), 
but quite mysterious if you don't.  (E.g. why "inflight"?)  Could we 
have a brief comment, to comfort mortal readers on their journey?

/* A message on a unix socket can hold a reference to a file. This can 
cause a reference cycle. So there is a garbage collector for unix 
sockets, which we hook into here. */

Yes that's a good idea, I've added a comment as to why we go through the
trouble of doing this socket + skb dance.

I think this is bypassing too_many_unix_fds() though?  I understood that 
was intended to bound kernel memory allocation, at least in principle.

As the code stands above, it'll cap it at 253. I'm just now reworking it
to NOT be limited to the SCM max fd count, but still impose a limit of
1024 on the number of registered files. This is important to cap the
memory allocation attempt as well.

Also, this code relies on CONFIG_NET.  To handle the case where 
CONFIG_NET is not enabled, don't you still need to forbid registering an 
io_uring fd ?

Good point, we do still need to reject the io_uring fd itself if
CONFIG_UNIX is not enabled. Done.

-- 
Jens Axboe

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>