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:7.252 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site