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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, May 30, 2010 at 12:20 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> [ 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.
>

But why not use (file->f_flags & O_NONBLOCK) instead, as
tracing_splice_read_pipe() does?


-- 
Regards,
Changli Gao(xiaosuo@xxxxxxxxx)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux