lkml.org 
[lkml]   [2019]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: LTP: diotest4.c:476: read to read-only space. returns 0: Success

----- Original Message -----
> I can't do a whole lot with a code snippet that lacks a proper SOB
> header.

I'll resend as a patch, maybe split it to 2 returns instead.

> > diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> > index 2f88d64c2a4d..8615b1f78389 100644
> > --- a/fs/iomap/direct-io.c
> > +++ b/fs/iomap/direct-io.c
> > @@ -318,7 +318,7 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos,
> > loff_t length,
> > if (pad)
> > iomap_dio_zero(dio, iomap, pos, fs_block_size -
> > pad);
> > }
> > - return copied ? copied : ret;
> > + return copied ? (loff_t) copied : ret;
>
> I'm a little confused on this proposed fix -- why does casting size_t
> (aka unsigned long) to loff_t (long long) on a 32-bit system change the
> test outcome?

Ternary operator has a return type and an attempt is made to convert
each of operands to the type of the other. So, in this case "ret"
appears to be converted to type of "copied" first. Both have size of
4 bytes on 32-bit x86:

size_t copied = 0;
int ret = -14;
long long actor_ret = copied ? copied : ret;

On x86_64: actor_ret == -14;
On x86 : actor_ret == 4294967282

> Does this same diotest4 failure happen with XFS? I ask
> because XFS has been using iomap for directio for ages.

Yes, it fails on XFS too.

\
 
 \ /
  Last update: 2019-11-11 09:20    [W:0.088 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site