Re: [PATCH v2 3/4]: sendfile: remove flags paramter of do_splice_direct()

[Steven Rostedt]

[ Removed matthew@xxxxxx since I'm getting errors in sending to that address ]


On Sat, 2010-05-29 at 09:59 +0800, Changli Gao wrote:
> On Fri, May 28, 2010 at 6:06 PM, Changli Gao <xiaosuo@xxxxxxxxx> wrote:
> > On Fri, May 28, 2010 at 5:40 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >> On Wed, 26 May 2010, Changli Gao wrote:
> >>> remove flags paramter of do_splice_direct().
> >>>
> >>> the flags parameter of do_splice_direct() doesn't mean non-block read of
> >>> in file,
> >>
> >> Actually, it does.  Look at the SPLICE_F_NONBLOCK usage in
> >> __generic_splice_file_read().
> >>
> >
> > Oh, I checked the code again. You're right. However, why don't we
> > check the flags of in file instead in __generic_file_splice_read()?
> >
> 
> I am afraid that __generic_file_splice_read() should not use SPLICE_F_NONBLOCK.
> 
> Here is the comment from the commit 42324c62704365d6a3e89138dea55909d2f26afe :
> 
> <<EOF
> Linus introduced  SPLICE_F_NONBLOCK in commit
> 29e350944fdc2dfca102500790d8ad6d6ff4f69d
> (splice: add SPLICE_F_NONBLOCK flag )
> 
>   It doesn't make the splice itself necessarily nonblocking (because the
>   actual file descriptors that are spliced from/to may block unless they
>   have the O_NONBLOCK flag set), but it makes the splice pipe operations
>   nonblocking.
> 
> Linus intention was clear : let SPLICE_F_NONBLOCK control the splice
> pipe mode only
> EOF
> 
> And I have greped the whole code:
> 


> kernel/trace/trace.c:           if (flags & SPLICE_F_NONBLOCK)
> 
> besides the __generic_file_splice_read(), there are two users: relay
> and trace. I believe they all misuse this flag.
> 


The trace splice never blocks anyway. Since we have no good method to
wake up a waiter. That is, we never know if it is safe to call wakeup,
because a tracepoint may be in a section where the rq lock is held.

The only thing that passing SPLICE_F_NONBLOCK does in that code is to
return -EAGAIN when there is nothing in the buffer. Otherwise, it
returns 0.

-- Steve



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/