10 Sep, 2020

1 commit

  • [ Upstream commit 1d4adfaf65746203861c72d9d78de349eb97d528 ]

    Fix rxrpc_kernel_get_srtt() to indicate the validity of the returned
    smoothed RTT. If we haven't had any valid samples yet, the SRTT isn't
    useful.

    Fixes: c410bf01933e ("rxrpc: Fix the excessive initial retransmission timeout")
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    David Howells
     

26 Aug, 2020

1 commit

  • [ Upstream commit 5e0b17b026eb7c6de9baa9b0d45a51b05f05abe1 ]

    If an error occurs during the construction of an afs superblock, it's
    possible that an error occurs after a superblock is created, but before
    we've created the root dentry. If the superblock has a dynamic root
    (ie. what's normally mounted on /afs), the afs_kill_super() will call
    afs_dynroot_depopulate() to unpin any created dentries - but this will
    oops if the root hasn't been created yet.

    Fix this by skipping that bit of code if there is no root dentry.

    This leads to an oops looking like:

    general protection fault, ...
    KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
    ...
    RIP: 0010:afs_dynroot_depopulate+0x25f/0x529 fs/afs/dynroot.c:385
    ...
    Call Trace:
    afs_kill_super+0x13b/0x180 fs/afs/super.c:535
    deactivate_locked_super+0x94/0x160 fs/super.c:335
    afs_get_tree+0x1124/0x1460 fs/afs/super.c:598
    vfs_get_tree+0x89/0x2f0 fs/super.c:1547
    do_new_mount fs/namespace.c:2875 [inline]
    path_mount+0x1387/0x2070 fs/namespace.c:3192
    do_mount fs/namespace.c:3205 [inline]
    __do_sys_mount fs/namespace.c:3413 [inline]
    __se_sys_mount fs/namespace.c:3390 [inline]
    __x64_sys_mount+0x27f/0x300 fs/namespace.c:3390
    do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
    entry_SYSCALL_64_after_hwframe+0x44/0xa9

    which is oopsing on this line:

    inode_lock(root->d_inode);

    presumably because sb->s_root was NULL.

    Fixes: 0da0b7fd73e4 ("afs: Display manually added cells in dynamic root mount")
    Reported-by: syzbot+c1eff8205244ae7e11a6@syzkaller.appspotmail.com
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds
    Signed-off-by: Sasha Levin

    David Howells
     

01 Jul, 2020

1 commit

  • [ Upstream commit 719fdd32921fb7e3208db8832d32ae1c2d68900f ]

    The cell name stored in the afs_cell struct is a 64-char + NUL buffer -
    when it needs to be able to handle up to AFS_MAXCELLNAME (256 chars) + NUL.

    Fix this by changing the array to a pointer and allocating the string.

    Found using Coverity.

    Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
    Reported-by: Colin Ian King
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds
    Signed-off-by: Sasha Levin

    David Howells
     

24 Jun, 2020

7 commits

  • [ Upstream commit 4ec89596d06bd481ba827f3b409b938d63914157 ]

    Abort code UAEOVERFLOW is returned when we try and set a time that's out of
    range, but it's currently mapped to EREMOTEIO by the default case.

    Fix UAEOVERFLOW to map instead to EOVERFLOW.

    Found with the generic/258 xfstest. Note that the test is wrong as it
    assumes that the filesystem will support a pre-UNIX-epoch date.

    Fixes: 1eda8bab70ca ("afs: Add support for the UAE error table")
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    David Howells
     
  • [ Upstream commit 38355eec6a7d2b8f2f313f9174736dc877744e59 ]

    Set a flag in the call struct to indicate an unmarshalling error rather
    than return and handle an error from the decoding of file statuses. This
    flag is checked on a successful return from the delivery function.

    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    David Howells
     
  • [ Upstream commit 13fcc6356a94558a0a4857dc00cd26b3834a1b3e ]

    When a lookup is done in an AFS directory, the filesystem will speculate
    and fetch up to 49 other statuses for files in the same directory and fetch
    those as well, turning them into inodes or updating inodes that already
    exist.

    However, occasionally, a callback break might go missing due to NAT timing
    out, but the afs filesystem doesn't then realise that the directory is not
    up to date.

    Alleviate this by using one of the status slots to check the directory in
    which the lookup is being done.

    Reported-by: Dave Botsch
    Suggested-by: Jeffrey Altman
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    David Howells
     
  • [ Upstream commit 3f4aa981816368fe6b1d13c2bfbe76df9687e787 ]

    When doing a partial writeback, afs_write_back_from_locked_page() may
    generate an FS.StoreData RPC request that writes out part of a file when a
    file has been constructed from pieces by doing seek, write, seek, write,
    ... as is done by ld.

    The FS.StoreData RPC is given the current i_size as the file length, but
    the server basically ignores it unless the data length is 0 (in which case
    it's just a truncate operation). The revised file length returned in the
    result of the RPC may then not reflect what we suggested - and this leads
    to i_size getting moved backwards - which causes issues later.

    Fix the client to take account of this by ignoring the returned file size
    unless the data version number jumped unexpectedly - in which case we're
    going to have to clear the pagecache and reload anyway.

    This can be observed when doing a kernel build on an AFS mount. The
    following pair of commands produce the issue:

    ld -m elf_x86_64 -z max-page-size=0x200000 --emit-relocs \
    -T arch/x86/realmode/rm/realmode.lds \
    arch/x86/realmode/rm/header.o \
    arch/x86/realmode/rm/trampoline_64.o \
    arch/x86/realmode/rm/stack.o \
    arch/x86/realmode/rm/reboot.o \
    -o arch/x86/realmode/rm/realmode.elf
    arch/x86/tools/relocs --realmode \
    arch/x86/realmode/rm/realmode.elf \
    >arch/x86/realmode/rm/realmode.relocs

    This results in the latter giving:

    Cannot read ELF section headers 0/18: Success

    as the realmode.elf file got corrupted.

    The sequence of events can also be driven with:

    xfs_io -t -f \
    -c "pwrite -S 0x58 0 0x58" \
    -c "pwrite -S 0x59 10000 1000" \
    -c "close" \
    /afs/example.com/scratch/a

    Fixes: 31143d5d515e ("AFS: implement basic file write support")
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    David Howells
     
  • [ Upstream commit 1f32ef79897052ef7d3d154610d8d6af95abde83 ]

    Fix afs_write_end() to change i_size under vnode->cb_lock rather than
    ->wb_lock so that it doesn't race with afs_vnode_commit_status() and
    afs_getattr().

    The ->wb_lock is only meant to guard access to ->wb_keys which isn't
    accessed by that piece of code.

    Fixes: 4343d00872e1 ("afs: Get rid of the afs_writeback record")
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    David Howells
     
  • [ Upstream commit bb413489288e4e457353bac513fddb6330d245ca ]

    The mtime on an inode needs to be updated when a write is made into an
    mmap'ed section. There are three ways in which this could be done: update
    it when page_mkwrite is called, update it when a page is changed from dirty
    to writeback or leave it to the server and fix the mtime up from the reply
    to the StoreData RPC.

    Found with the generic/215 xfstest.

    Fixes: 1cf7a1518aef ("afs: Implement shared-writeable mmap")
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    David Howells
     
  • [ Upstream commit 2ca068be09bf8e285036603823696140026dcbe7 ]

    Fix afs_put_sysnames() to actually free the specified afs_sysnames
    object after its reference count has been decreased to zero and
    its contents have been released.

    Fixes: 6f8880d8e681557 ("afs: Implement @sys substitution handling")
    Signed-off-by: Zhihao Cheng
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    Zhihao Cheng
     

27 May, 2020

2 commits

  • commit c410bf01933e5e09d142c66c3df9ad470a7eec13 upstream.

    rxrpc currently uses a fixed 4s retransmission timeout until the RTT is
    sufficiently sampled. This can cause problems with some fileservers with
    calls to the cache manager in the afs filesystem being dropped from the
    fileserver because a packet goes missing and the retransmission timeout is
    greater than the call expiry timeout.

    Fix this by:

    (1) Copying the RTT/RTO calculation code from Linux's TCP implementation
    and altering it to fit rxrpc.

    (2) Altering the various users of the RTT to make use of the new SRTT
    value.

    (3) Replacing the use of rxrpc_resend_timeout to use the calculated RTO
    value instead (which is needed in jiffies), along with a backoff.

    Notes:

    (1) rxrpc provides RTT samples by matching the serial numbers on outgoing
    DATA packets that have the RXRPC_REQUEST_ACK set and PING ACK packets
    against the reference serial number in incoming REQUESTED ACK and
    PING-RESPONSE ACK packets.

    (2) Each packet that is transmitted on an rxrpc connection gets a new
    per-connection serial number, even for retransmissions, so an ACK can
    be cross-referenced to a specific trigger packet. This allows RTT
    information to be drawn from retransmitted DATA packets also.

    (3) rxrpc maintains the RTT/RTO state on the rxrpc_peer record rather than
    on an rxrpc_call because many RPC calls won't live long enough to
    generate more than one sample.

    (4) The calculated SRTT value is in units of 8ths of a microsecond rather
    than nanoseconds.

    The (S)RTT and RTO values are displayed in /proc/net/rxrpc/peers.

    Fixes: 17926a79320a ([AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both"")
    Signed-off-by: David Howells
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • [ Upstream commit 9d1be4f4dc5ff1c66c86acfd2c35765d9e3776b3 ]

    Don't call req->page_done() on each page as we finish filling it with
    the data coming from the network. Whilst this might speed up the
    application a bit, it's a problem if there's a network failure and the
    operation has to be reissued.

    If this happens, an oops occurs because afs_readpages_page_done() clears
    the pointer to each page it unlocks and when a retry happens, the
    pointers to the pages it wants to fill are now NULL (and the pages have
    been unlocked anyway).

    Instead, wait till the operation completes successfully and only then
    release all the pages after clearing any terminal gap (the server can
    give us less data than we requested as we're allowed to ask for more
    than is available).

    KASAN produces a bug like the following, and even without KASAN, it can
    oops and panic.

    BUG: KASAN: wild-memory-access in _copy_to_iter+0x323/0x5f4
    Write of size 1404 at addr 0005088000000000 by task md5sum/5235

    CPU: 0 PID: 5235 Comm: md5sum Not tainted 5.7.0-rc3-fscache+ #250
    Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
    Call Trace:
    memcpy+0x39/0x58
    _copy_to_iter+0x323/0x5f4
    __skb_datagram_iter+0x89/0x2a6
    skb_copy_datagram_iter+0x129/0x135
    rxrpc_recvmsg_data.isra.0+0x615/0xd42
    rxrpc_kernel_recv_data+0x1e9/0x3ae
    afs_extract_data+0x139/0x33a
    yfs_deliver_fs_fetch_data64+0x47a/0x91b
    afs_deliver_to_call+0x304/0x709
    afs_wait_for_call_to_complete+0x1cc/0x4ad
    yfs_fs_fetch_data+0x279/0x288
    afs_fetch_data+0x1e1/0x38d
    afs_readpages+0x593/0x72e
    read_pages+0xf5/0x21e
    __do_page_cache_readahead+0x128/0x23f
    ondemand_readahead+0x36e/0x37f
    generic_file_buffered_read+0x234/0x680
    new_sync_read+0x109/0x17e
    vfs_read+0xe6/0x138
    ksys_read+0xd8/0x14d
    do_syscall_64+0x6e/0x8a
    entry_SYSCALL_64_after_hwframe+0x49/0xb3

    Fixes: 196ee9cd2d04 ("afs: Make afs_fs_fetch_data() take a list of pages")
    Fixes: 30062bd13e36 ("afs: Implement YFS support in the fs client")
    Signed-off-by: David Howells
    Reviewed-by: Matthew Wilcox (Oracle)
    Signed-off-by: Linus Torvalds
    Signed-off-by: Sasha Levin

    David Howells
     

02 May, 2020

3 commits

  • [ Upstream commit 3efe55b09a92a59ed8214db801683cf13c9742c4 ]

    Fix the length of the dump of a bad YFSFetchStatus record. The function
    was copied from the AFS version, but the YFS variant contains bigger fields
    and extra information, so expand the dump to match.

    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    David Howells
     
  • commit 69cf3978f3ada4e54beae4ad44868b5627864884 upstream.

    AFS keeps track of the epoch value from the rxrpc protocol to note (a) when
    a fileserver appears to have restarted and (b) when different endpoints of
    a fileserver do not appear to be associated with the same fileserver
    (ie. all probes back from a fileserver from all of its interfaces should
    carry the same epoch).

    However, the AFS_SERVER_FL_HAVE_EPOCH flag that indicates that we've
    received the server's epoch is never set, though it is used.

    Fix this to set the flag when we first receive an epoch value from a probe
    sent to the filesystem client from the fileserver.

    Fixes: 3bf0fb6f33dd ("afs: Probe multiple fileservers simultaneously")
    Signed-off-by: David Howells
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit c4bfda16d1b40d1c5941c61b5aa336bdd2d9904a upstream.

    When an operation is meant to be done uninterruptibly (such as
    FS.StoreData), we should not be allowing volume and server record checking
    to be interrupted.

    Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
    Signed-off-by: David Howells
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     

23 Apr, 2020

5 commits

  • commit 2105c2820d366b76f38e6ad61c75771881ecc532 upstream.

    AFS directories are retained locally as a structured file, with lookup
    being effected by a local search of the file contents. When a modification
    (such as mkdir) happens, the dir file content is modified locally rather
    than redownloading the directory.

    The directory contents are accessed in a number of ways, with a number of
    different locks schemes:

    (1) Download of contents - dvnode->validate_lock/write in afs_read_dir().

    (2) Lookup and readdir - dvnode->validate_lock/read in afs_dir_iterate(),
    downgrading from (1) if necessary.

    (3) d_revalidate of child dentry - dvnode->validate_lock/read in
    afs_do_lookup_one() downgrading from (1) if necessary.

    (4) Edit of dir after modification - page locks on individual dir pages.

    Unfortunately, because (4) uses different locking scheme to (1) - (3),
    nothing protects against the page being scanned whilst the edit is
    underway. Even download is not safe as it doesn't lock the pages - relying
    instead on the validate_lock to serialise as a whole (the theory being that
    directory contents are treated as a block and always downloaded as a
    block).

    Fix this by write-locking dvnode->validate_lock around the edits. Care
    must be taken in the rename case as there may be two different dirs - but
    they need not be locked at the same time. In any case, once the lock is
    taken, the directory version must be rechecked, and the edit skipped if a
    later version has been downloaded by revalidation (there can't have been
    any local changes because the VFS holds the inode lock, but there can have
    been remote changes).

    Fixes: 63a4681ff39c ("afs: Locally edit directory data for mkdir/create/unlink/...")
    Signed-off-by: David Howells
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit 40fc81027f892284ce31f8b6de1e497f5b47e71f upstream.

    If a dentry's version is somewhere between invalid_before and the current
    directory version, we should be setting it forward to the current version,
    not backwards to the invalid_before version. Note that we're only doing
    this at all because dentry::d_fsdata isn't large enough on a 32-bit system.

    Fix this by using a separate variable for invalid_before so that we don't
    accidentally clobber the current dir version.

    Fixes: a4ff7401fbfa ("afs: Keep track of invalid-before version for dentry coherency")
    Signed-off-by: David Howells
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit b98f0ec91c42d87a70da42726b852ac8d78a3257 upstream.

    The afs_deliver_fs_rename() and yfs_deliver_fs_rename() functions both only
    decode the second file status returned unless the parent directories are
    different - unfortunately, this means that the xdr pointer isn't advanced
    and the volsync record will be read incorrectly in such an instance.

    Fix this by always decoding the second status into the second
    status/callback block which wasn't being used if the dirs were the same.

    The afs_update_dentry_version() calls that update the directory data
    version numbers on the dentries can then unconditionally use the second
    status record as this will always reflect the state of the destination dir
    (the two records will be identical if the destination dir is the same as
    the source dir)

    Fixes: 260a980317da ("[AFS]: Add "directory write" support.")
    Fixes: 30062bd13e36 ("afs: Implement YFS support in the fs client")
    Signed-off-by: David Howells
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit 3e0d9892c0e7fa426ca6bf921cb4b543ca265714 upstream.

    If we're decoding an AFSFetchStatus record and we see that the version is 1
    and the abort code is set and we're expecting inline errors, then we store
    the abort code and ignore the remaining status record (which is correct),
    but we don't set the flag to say we got a valid abort code.

    This can affect operation of YFS.RemoveFile2 when removing a file and the
    operation of {,Y}FS.InlineBulkStatus when prospectively constructing or
    updating of a set of inodes during a lookup.

    Fix this to indicate the reception of a valid abort code.

    Fixes: a38a75581e6e ("afs: Fix unlink to handle YFS.RemoveFile2 better")
    Signed-off-by: David Howells
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit c72057b56f7e24865840a6961d801a7f21d30a5f upstream.

    If we receive a status record that has VNOVNODE set in the abort field,
    xdr_decode_AFSFetchStatus() and xdr_decode_YFSFetchStatus() don't advance
    the XDR pointer, thereby corrupting anything subsequent decodes from the
    same block of data.

    This has the potential to affect AFS.InlineBulkStatus and
    YFS.InlineBulkStatus operation, but probably doesn't since the status
    records are extracted as individual blocks of data and the buffer pointer
    is reset between blocks.

    It does affect YFS.RemoveFile2 operation, corrupting the volsync record -
    though that is not currently used.

    Other operations abort the entire operation rather than returning an error
    inline, in which case there is no decoding to be done.

    Fix this by unconditionally advancing the xdr pointer.

    Fixes: 684b0f68cf1c ("afs: Fix AFSFetchStatus decoder to provide OpenAFS compatibility")
    Signed-off-by: David Howells
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     

17 Apr, 2020

1 commit

  • [ Upstream commit e138aa7d3271ac1b0690ae2c9b04d51468dce1d6 ]

    Fix the interruptibility of kernel-initiated client calls so that they're
    either only interruptible when they're waiting for a call slot to come
    available or they're not interruptible at all. Either way, they're not
    interruptible during transmission.

    This should help prevent StoreData calls from being interrupted when
    writeback is in progress. It doesn't, however, handle interruption during
    the receive phase.

    Userspace-initiated calls are still interruptable. After the signal has
    been handled, sendmsg() will return the amount of data copied out of the
    buffer and userspace can perform another sendmsg() call to continue
    transmission.

    Fixes: bc5e3a546d55 ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals")
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    David Howells
     

01 Apr, 2020

4 commits

  • commit 9efcc4a129363187c9bf15338692f107c5c9b6f0 upstream.

    When it's probing all of a fileserver's interfaces to find which one is
    best to use, afs_do_probe_fileserver() takes a lock on the server record
    and notes the pointer to the address list.

    It doesn't, however, pin the address list, so as soon as it drops the
    lock, there's nothing to stop the address list from being freed under
    us.

    Fix this by taking a ref on the address list inside the locked section
    and dropping it at the end of the function.

    Fixes: 3bf0fb6f33dd ("afs: Probe multiple fileservers simultaneously")
    Signed-off-by: David Howells
    Reviewed-by: Marc Dionne
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit 4636cf184d6d9a92a56c2554681ea520dd4fe49a upstream.

    Fix a couple of tracelines to indicate the usage count after the atomic op,
    not the usage count before it to be consistent with other afs and rxrpc
    trace lines.

    Change the wording of the afs_call_trace_work trace ID label from "WORK" to
    "QUEUE" to reflect the fact that it's queueing work, not doing work.

    Fixes: 341f741f04be ("afs: Refcount the afs_call struct")
    Signed-off-by: David Howells
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit 7d7587db0d7fd1138f2afcffdc46a8e15630b944 upstream.

    Fix the handling of signals in client rxrpc calls made by the afs
    filesystem. Ignore signals completely, leaving call abandonment or
    connection loss to be detected by timeouts inside AF_RXRPC.

    Allowing a filesystem call to be interrupted after the entire request has
    been transmitted and an abort sent means that the server may or may not
    have done the action - and we don't know. It may even be worse than that
    for older servers.

    Fixes: bc5e3a546d55 ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals")
    Signed-off-by: David Howells
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit dde9f095583b3f375ba23979045ee10dfcebec2f upstream.

    When an AFS service handler function aborts a call, AF_RXRPC marks the call
    as complete - which means that it's not going to get any more packets from
    the receiver. This is a problem because reception of the final ACK is what
    triggers afs_deliver_to_call() to drop the final ref on the afs_call
    object.

    Instead, aborted AFS service calls may then just sit around waiting for
    ever or until they're displaced by a new call on the same connection
    channel or a connection-level abort.

    Fix this by calling afs_set_call_complete() to finalise the afs_call struct
    representing the call.

    However, we then need to drop the ref that stops the call from being
    deallocated. We can do this in afs_set_call_complete(), as the work queue
    is holding a separate ref of its own, but then we shouldn't do it in
    afs_process_async_call() and afs_delete_async_call().

    call->drop_ref is set to indicate that a ref needs dropping for a call and
    this is dealt with when we transition a call to AFS_CALL_COMPLETE.

    But then we also need to get rid of the ref that pins an asynchronous
    client call. We can do this by the same mechanism, setting call->drop_ref
    for an async client call too.

    We can also get rid of call->incoming since nothing ever sets it and only
    one thing ever checks it (futilely).

    A trace of the rxrpc_call and afs_call struct ref counting looks like:

    -0 [001] ..s5 164.764892: rxrpc_call: c=00000002 SEE u=3 sp=rxrpc_new_incoming_call+0x473/0xb34 a=00000000442095b5
    -0 [001] .Ns5 164.766001: rxrpc_call: c=00000002 QUE u=4 sp=rxrpc_propose_ACK+0xbe/0x551 a=00000000442095b5
    -0 [001] .Ns4 164.766005: rxrpc_call: c=00000002 PUT u=3 sp=rxrpc_new_incoming_call+0xa3f/0xb34 a=00000000442095b5
    -0 [001] .Ns7 164.766433: afs_call: c=00000002 WAKE u=2 o=11 sp=rxrpc_notify_socket+0x196/0x33c
    kworker/1:2-1810 [001] ...1 164.768409: rxrpc_call: c=00000002 SEE u=3 sp=rxrpc_process_call+0x25/0x7ae a=00000000442095b5
    kworker/1:2-1810 [001] ...1 164.769439: rxrpc_tx_packet: c=00000002 e9f1a7a8:95786a88:00000008:09c5 00000001 00000000 02 22 ACK CallAck
    kworker/1:2-1810 [001] ...1 164.769459: rxrpc_call: c=00000002 PUT u=2 sp=rxrpc_process_call+0x74f/0x7ae a=00000000442095b5
    kworker/1:2-1810 [001] ...1 164.770794: afs_call: c=00000002 QUEUE u=3 o=12 sp=afs_deliver_to_call+0x449/0x72c
    kworker/1:2-1810 [001] ...1 164.770829: afs_call: c=00000002 PUT u=2 o=12 sp=afs_process_async_call+0xdb/0x11e
    kworker/1:2-1810 [001] ...2 164.771084: rxrpc_abort: c=00000002 95786a88:00000008 s=0 a=1 e=1 K-1
    kworker/1:2-1810 [001] ...1 164.771461: rxrpc_tx_packet: c=00000002 e9f1a7a8:95786a88:00000008:09c5 00000002 00000000 04 00 ABORT CallAbort
    kworker/1:2-1810 [001] ...1 164.771466: afs_call: c=00000002 PUT u=1 o=12 sp=SRXAFSCB_ProbeUuid+0xc1/0x106

    The abort generated in SRXAFSCB_ProbeUuid(), labelled "K-1", indicates that
    the local filesystem/cache manager didn't recognise the UUID as its own.

    Fixes: 2067b2b3f484 ("afs: Fix the CB.ProbeUuid service handler to reply correctly")
    Signed-off-by: David Howells
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     

29 Jan, 2020

1 commit

  • commit a45ea48e2bcd92c1f678b794f488ca0bda9835b8 upstream.

    The afs filesystem needs to prohibit certain characters from cell names,
    such as '/', as these are used to form filenames in procfs, leading to
    the following warning being generated:

    WARNING: CPU: 0 PID: 3489 at fs/proc/generic.c:178

    Fix afs_alloc_cell() to disallow nonprintable characters, '/', '@' and
    names that begin with a dot.

    Remove the check for "@cell" as that is then redundant.

    This can be tested by running:

    echo add foo/.bar 1.2.3.4 >/proc/fs/afs/cells

    Note that we will also need to deal with:

    - Names ending in ".invalid" shouldn't be passed to the DNS.

    - Names that contain non-valid domainname chars shouldn't be passed to
    the DNS.

    - DNS replies that say "your-dns-needs-immediate-attention." and
    replies containing A records that say 127.0.53.53 should be
    considered invalid.
    [https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf]

    but these need to be dealt with by the kafs-client DNS program rather
    than the kernel.

    Reported-by: syzbot+b904ba7c947a37b4b291@syzkaller.appspotmail.com
    Cc: stable@kernel.org
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     

26 Jan, 2020

1 commit

  • [ Upstream commit 51590df4f3306cb1f43dca54e3ccdd121ab89594 ]

    Fixes gcc '-Wunused-but-set-variable' warning:

    fs/afs/dir_edit.c: In function afs_set_contig_bits:
    fs/afs/dir_edit.c:75:20: warning: variable after set but not used [-Wunused-but-set-variable]
    fs/afs/dir_edit.c: In function afs_set_contig_bits:
    fs/afs/dir_edit.c:75:12: warning: variable before set but not used [-Wunused-but-set-variable]
    fs/afs/dir_edit.c: In function afs_clear_contig_bits:
    fs/afs/dir_edit.c:100:20: warning: variable after set but not used [-Wunused-but-set-variable]
    fs/afs/dir_edit.c: In function afs_clear_contig_bits:
    fs/afs/dir_edit.c:100:12: warning: variable before set but not used [-Wunused-but-set-variable]

    They are never used since commit 63a4681ff39c.

    Fixes: 63a4681ff39c ("afs: Locally edit directory data for mkdir/create/unlink/...")
    Reported-by: Hulk Robot
    Signed-off-by: zhengbin
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    zhengbin
     

18 Jan, 2020

3 commits

  • commit f52b83b0b1c40ada38df917973ab719a4a753951 upstream.

    Fix afs_lookup() to not clobber the version set on a new dentry by
    afs_do_lookup() - especially as it's using the wrong version of the
    version (we need to use the one given to us by whatever op the dir
    contents correspond to rather than what's in the afs_vnode).

    Fixes: 9dd0b82ef530 ("afs: Fix missing dentry data version updating")
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit 40a708bd622b78582ae3d280de29b09b50bd04c0 upstream.

    afs_lookup() has a tracepoint to indicate the outcome of
    d_splice_alias(), passing it the inode to retrieve the fid from.
    However, the function gave up its ref on that inode when it called
    d_splice_alias(), which may have failed and dropped the inode.

    Fix this by caching the fid.

    Fixes: 80548b03991f ("afs: Add more tracepoints")
    Reported-by: Al Viro
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit 106bc79843c3c6f4f00753d1f46e54e815f99377 upstream.

    Fix missing cell comparison in afs_test_super(). Without this, any pair
    volumes that have the same volume ID will share a superblock, no matter the
    cell, unless they're in different network namespaces.

    Normally, most users will only deal with a single cell and so they won't
    see this. Even if they do look into a second cell, they won't see a
    problem unless they happen to hit a volume with the same ID as one they've
    already got mounted.

    Before the patch:

    # ls /afs/grand.central.org/archive
    linuxdev/ mailman/ moin/ mysql/ pipermail/ stage/ twiki/
    # ls /afs/kth.se/
    linuxdev/ mailman/ moin/ mysql/ pipermail/ stage/ twiki/
    # cat /proc/mounts | grep afs
    none /afs afs rw,relatime,dyn,autocell 0 0
    #grand.central.org:root.cell /afs/grand.central.org afs ro,relatime 0 0
    #grand.central.org:root.archive /afs/grand.central.org/archive afs ro,relatime 0 0
    #grand.central.org:root.archive /afs/kth.se afs ro,relatime 0 0

    After the patch:

    # ls /afs/grand.central.org/archive
    linuxdev/ mailman/ moin/ mysql/ pipermail/ stage/ twiki/
    # ls /afs/kth.se/
    admin/ common/ install/ OldFiles/ service/ system/
    bakrestores/ home/ misc/ pkg/ src/ wsadmin/
    # cat /proc/mounts | grep afs
    none /afs afs rw,relatime,dyn,autocell 0 0
    #grand.central.org:root.cell /afs/grand.central.org afs ro,relatime 0 0
    #grand.central.org:root.archive /afs/grand.central.org/archive afs ro,relatime 0 0
    #kth.se:root.cell /afs/kth.se afs ro,relatime 0 0

    Fixes: ^1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Carsten Jacobi
    Signed-off-by: David Howells
    Reviewed-by: Marc Dionne
    Tested-by: Jonathan Billings
    cc: Todd DeSantis
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     

09 Jan, 2020

4 commits

  • [ Upstream commit 1da4bd9f9d187f53618890d7b66b9628bbec3c70 ]

    Fix the lookup method on the dynamic root directory such that creation
    calls, such as mkdir, open(O_CREAT), symlink, etc. fail with EOPNOTSUPP
    rather than failing with some odd error (such as EEXIST).

    lookup() itself tries to create automount directories when it is invoked.
    These are cached locally in RAM and not committed to storage.

    Signed-off-by: David Howells
    Reviewed-by: Marc Dionne
    Tested-by: Jonathan Billings
    Signed-off-by: Sasha Levin

    David Howells
     
  • [ Upstream commit 158d58335393af3956a9c06f0816ee75ed1f1447 ]

    Each AFS mountpoint has strings that define the target to be mounted. This
    is required to end in a dot that is supposed to be stripped off. The
    string can include suffixes of ".readonly" or ".backup" - which are
    supposed to come before the terminal dot. To add to the confusion, the "fs
    lsmount" afs utility does not show the terminal dot when displaying the
    string.

    The kernel mount source string parser, however, assumes that the terminal
    dot marks the suffix and that the suffix is always "" and is thus ignored.
    In most cases, there is no suffix and this is not a problem - but if there
    is a suffix, it is lost and this affects the ability to mount the correct
    volume.

    The command line mount command, on the other hand, is expected not to
    include a terminal dot - so the problem doesn't arise there.

    Fix this by making sure that the dot exists and then stripping it when
    passing the string to the mount configuration.

    Fixes: bec5eb614130 ("AFS: Implement an autocell mount capability [ver #2]")
    Reported-by: Jonathan Billings
    Signed-off-by: David Howells
    Reviewed-by: Marc Dionne
    Tested-by: Jonathan Billings
    Signed-off-by: Sasha Levin

    David Howells
     
  • [ Upstream commit bcbccaf2edcf1b76f73f890e968babef446151a4 ]

    Make the AFS dynamic root superblock R/W so that SELinux can set the
    security label on it. Without this, upgrades to, say, the Fedora
    filesystem-afs RPM fail if afs is mounted on it because the SELinux label
    can't be (re-)applied.

    It might be better to make it possible to bypass the R/O check for LSM
    label application through setxattr.

    Fixes: 4d673da14533 ("afs: Support the AFS dynamic root")
    Signed-off-by: David Howells
    Reviewed-by: Marc Dionne
    cc: selinux@vger.kernel.org
    cc: linux-security-module@vger.kernel.org
    Signed-off-by: Sasha Levin

    David Howells
     
  • [ Upstream commit 9bd0160d12370a076e44f8d1320cde9c83f2c647 ]

    afs_find_server tries to find a server that has an address that
    matches the transport address of an rxrpc peer. The code assumes
    that the transport address is always ipv6, with ipv4 represented
    as ipv4 mapped addresses, but that's not the case. If the transport
    family is AF_INET, srx->transport.sin6.sin6_addr.s6_addr32[] will
    be beyond the actual ipv4 address and will always be 0, and all
    ipv4 addresses will be seen as matching.

    As a result, the first ipv4 address seen on any server will be
    considered a match, and the server returned may be the wrong one.

    One of the consequences is that callbacks received over ipv4 will
    only be correctly applied for the server that happens to have the
    first ipv4 address on the fs_addresses4 list. Callbacks over ipv4
    from all other servers are dropped, causing the client to serve stale
    data.

    This is fixed by looking at the transport family, and comparing ipv4
    addresses based on a sockaddr_in structure rather than a sockaddr_in6.

    Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
    Signed-off-by: Marc Dionne
    Signed-off-by: David Howells
    Signed-off-by: Sasha Levin

    Marc Dionne
     

23 Nov, 2019

2 commits

  • By default s_maxbytes is set to MAX_NON_LFS, which limits the usable
    file size to 2GB, enforced by the vfs.

    Commit b9b1f8d5930a ("AFS: write support fixes") added support for the
    64-bit fetch and store server operations, but did not change this value.
    As a result, attempts to write past the 2G mark result in EFBIG errors:

    $ dd if=/dev/zero of=foo bs=1M count=1 seek=2048
    dd: error writing 'foo': File too large

    Set s_maxbytes to MAX_LFS_FILESIZE.

    Fixes: b9b1f8d5930a ("AFS: write support fixes")
    Signed-off-by: Marc Dionne
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    Marc Dionne
     
  • Servers sending callback breaks to the YFS_CM_SERVICE service may
    send up to YFSCBMAX (1024) fids in a single RPC. Anything over
    AFSCBMAX (50) will cause the assert in afs_break_callbacks to trigger.

    Remove the assert, as the count has already been checked against
    the appropriate max values in afs_deliver_cb_callback and
    afs_deliver_yfs_cb_callback.

    Fixes: 35dbfba3111a ("afs: Implement the YFS cache manager service")
    Signed-off-by: Marc Dionne
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    Marc Dionne
     

20 Nov, 2019

1 commit

  • In afs_wait_for_call_to_complete(), rather than immediately aborting an
    operation if a signal occurs, the code attempts to wait for it to
    complete, using a schedule timeout of 2*RTT (or min 2 jiffies) and a
    check that we're still receiving relevant packets from the server before
    we consider aborting the call. We may even ping the server to check on
    the status of the call.

    However, there's a missing timeout reset in the event that we do
    actually get a packet to process, such that if we then get a couple of
    short stalls, we then time out when progress is actually being made.

    Fix this by resetting the timeout any time we get something to process.
    If it's the failure of the call then the call state will get changed and
    we'll exit the loop shortly thereafter.

    A symptom of this is data fetches and stores failing with EINTR when
    they really shouldn't.

    Fixes: bc5e3a546d55 ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals")
    Signed-off-by: David Howells
    Reviewed-by: Marc Dionne
    Signed-off-by: Linus Torvalds

    David Howells
     

16 Nov, 2019

1 commit

  • When a lookup is done, the afs filesystem will perform a bulk status-fetch
    operation on the requested vnode (file) plus the next 49 other vnodes from
    the directory list (in AFS, directory contents are downloaded as blobs and
    parsed locally). When the results are received, it will speculatively
    populate the inode cache from the extra data.

    However, if the lookup races with another lookup on the same directory, but
    for a different file - one that's in the 49 extra fetches, then if the bulk
    status-fetch operation finishes first, it will try and update the inode
    from the other lookup.

    If this other inode is still in the throes of being created, however, this
    will cause an assertion failure in afs_apply_status():

    BUG_ON(test_bit(AFS_VNODE_UNSET, &vnode->flags));

    on or about fs/afs/inode.c:175 because it expects data to be there already
    that it can compare to.

    Fix this by skipping the update if the inode is being created as the
    creator will presumably set up the inode with the same information.

    Fixes: 39db9815da48 ("afs: Fix application of the results of a inline bulk status fetch")
    Signed-off-by: David Howells
    Reviewed-by: Marc Dionne
    Signed-off-by: Linus Torvalds

    David Howells
     

30 Sep, 2019

1 commit


16 Sep, 2019

1 commit