Re: reiser4: porting to 3.16: any reason ->aio_read() of struct file_operations has been left out?

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

 



On Thursday 21 August 2014 at 00:30:45, Edward Shishkin wrote:	
> 
> On 08/20/2014 10:34 PM, Ivan Shapovalov wrote:
> > On Wednesday 20 August 2014 at 01:39:42, Edward Shishkin wrote:	
> >> On 08/20/2014 12:32 AM, Ivan Shapovalov wrote:
> >>>   From `git log` I've seen that VFS people intend to replace ->aio_read() and
> >>> ->aio_write() of struct file_operations with new methods ->read_iter() and
> >>> ->write_iter().
> >>>
> >>> (Along with a couple of related new helpers, differing from previous just in
> >>> calling _iter methods instead of aio_ ones.)
> >>>
> >>>   From other filesystems it seems that these are simple drop-in replacements
> >>> (however, well, I have zero familiarity with VFS). So here is a question:
> >>> is there any intentional reason that generic_file_aio_write() is not used
> >>> in reiser4?
> >>
> >> Currently reiser4 is a set of two filesystems which differ in methods
> >> of handling regular files. For VFS we provide "dispatchers", which pass
> >> management to appropriate plugin (UNIX_FILE or CRYPTCOMPRESS).
> >>
> >> UNIX_FILE plugin doesn't use generic write for performance reasons
> >> (I'll try to find the respective mailing thread). CRYPTCOMPRESS doesn't
> >> use it for compatibility reasons: I don't know how how to rewrite it
> >> gracefully using the generic write method.
> >>
> >> Edward.
> >
> > Thanks for explanation! So, does this patch make any sense?
> 
> 
> I haven't looked at this carefully yet, but likely it is correct.
> 
> Thanks,
> Edward.

Turned out it isn't.. The iter_file_splice_write() requires ->write_iter
to be set, or a NULL dereference happens.

At first I've thought that we're out of luck and will need to use the fallback
splice implementation (default_file_splice_write), but just setting
->write_iter to generic_file_write_iter strangely worked.

(By "it works" I mean "splice finishes successfully and does not cause data
corruptions").

Could you please comment on this? :)

Thanks,
-- 
Ivan Shapovalov / intelfx /

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Linux File System Development]     [Linux BTRFS]     [Linux NFS]     [Linux Filesystems]     [Ext4 Filesystem]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Resources]

  Powered by Linux