lkml.org 
[lkml]   [2015]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [git pull] vfs part 2
    On Wed, Jul 01, 2015 at 10:50:59AM +0300, Andrey Ryabinin wrote:

    > # dmesg | grep fucked
    >
    > [ 114.732166] fucked: sent 2037, server says it got 2047 (err = 0)
    > [ 124.937105] fucked: sent 27, server says it got 4096 (err = 0)
    > [ 154.075400] fucked: sent 19, server says it got 4096 (err = 0)
    >
    > > It's one thing if
    > > you are hitting a buggy server, it gets confused and tells you it has
    > > written more bytes than you told it to write. Quite a different story
    > > in case if we are miscalculating the size we are putting into RWRITE
    TWRITE,
    sorry about the braino.

    > > packet and/or advancing the iterator when we shouldn't...
    > >
    > > What server are you using, BTW? And which transport (virtio or network -
    > > IOW, is it zero-copy path or not)?
    >
    > qemu v2.2.1, virtio transport.

    Hmm... The first one should've hit the zero-copy path then, the last two
    are too short for that... *grumble*

    I wonder if these short writes are getting matched with response from wrong
    request - that would explain full-page responses...

    Could you check if 3.19 was getting anything similar? I.e. in
    p9_client_write() there add
    if (count > rsize)
    printk(KERN_ERR "bogus RWRITE: %d -> %d\n", rsize, count);
    just before
    p9_debug(P9_DEBUG_9P, "<<< RWRITE count %d\n", count);
    and see if that triggers...


    \
     
     \ /
      Last update: 2015-07-01 11:01    [W:3.594 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site