Skip to content
  1. May 07, 2019
    • David Howells's avatar
      afs: Get YFS ACLs and information through xattrs · ae46578b
      David Howells authored
      
      
      The YFS/AuriStor variant of AFS provides more capable ACLs and provides
      per-volume ACLs and per-file ACLs as well as per-directory ACLs.  It also
      provides some extra information that can be retrieved through four ACLs:
      
       (1) afs.yfs.acl
      
           The YFS file ACL (not the same format as afs.acl).
      
       (2) afs.yfs.vol_acl
      
           The YFS volume ACL.
      
       (3) afs.yfs.acl_inherited
      
           "1" if a file's ACL is inherited from its parent directory, "0"
           otherwise.
      
       (4) afs.yfs.acl_num_cleaned
      
           The number of of ACEs removed from the ACL by the server because the
           PT entries were removed from the PTS database (ie. the subject is no
           longer known).
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      ae46578b
    • Joe Gorse's avatar
      afs: implement acl setting · b10494af
      Joe Gorse authored
      
      
      Implements the setting of ACLs in AFS by means of setting the
      afs.acl extended attribute on the file.
      
      Signed-off-by: default avatarJoe Gorse <jhgorse@gmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      b10494af
    • David Howells's avatar
      afs: Get an AFS3 ACL as an xattr · 260f082b
      David Howells authored
      
      
      Implement an xattr on AFS files called "afs.acl" that retrieves a file's
      ACL.  It returns the raw AFS3 ACL from the result of calling FS.FetchACL,
      leaving any interpretation to userspace.
      
      Note that whilst YFS servers will respond to FS.FetchACL, this will render
      a more-advanced YFS ACL down.  Use "afs.yfs.acl" instead for that.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      260f082b
    • David Howells's avatar
      afs: Fix getting the afs.fid xattr · a2f611a3
      David Howells authored
      The AFS3 FID is three 32-bit unsigned numbers and is represented as three
      up-to-8-hex-digit numbers separated by colons to the afs.fid xattr.
      However, with the advent of support for YFS, the FID is now a 64-bit volume
      number, a 96-bit vnode/inode number and a 32-bit uniquifier (as before).
      Whilst the sprintf in afs_xattr_get_fid() has been partially updated (it
      currently ignores the upper 32 bits of the 96-bit vnode number), the size
      of the stack-based buffer has not been increased to match, thereby allowing
      stack corruption to occur.
      
      Fix this by increasing the buffer size appropriately and conditionally
      including the upper part of the vnode number if it is non-zero.  The latter
      requires the lower part to be zero-padded if the upper part is non-zero.
      
      Fixes: 3b6492df
      
       ("afs: Increase to 64-bit volume ID and 96-bit vnode ID for YFS")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      a2f611a3
    • David Howells's avatar
      afs: Fix the afs.cell and afs.volume xattr handlers · c73aa410
      David Howells authored
      Fix the ->get handlers for the afs.cell and afs.volume xattrs to pass the
      source data size to memcpy() rather than target buffer size.
      
      Overcopying the source data occasionally causes the kernel to oops.
      
      Fixes: d3e3b7ea
      
       ("afs: Add metadata xattrs")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      c73aa410
    • Marc Dionne's avatar
      afs: Calculate i_blocks based on file size · c0abbb57
      Marc Dionne authored
      
      
      While it's not possible to give an accurate number for the blocks
      used on the server, populate i_blocks based on the file size so
      that 'du' can give a reasonable estimate.
      
      The value is rounded up to 1K granularity, for consistency with
      what other AFS clients report, and the servers' 1K usage quota
      unit.  Note that the value calculated by 'du' at the root of a
      volume can still be slightly lower than the quota usage on the
      server, as 0-length files are charged 1 quota block, but are
      reported as occupying 0 blocks.  Again, this is consistent with
      other AFS clients.
      
      Signed-off-by: default avatarMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      c0abbb57
    • David Howells's avatar
      afs: Log more information for "kAFS: AFS vnode with undefined type\n" · b134d687
      David Howells authored
      
      
      Log more information when "kAFS: AFS vnode with undefined type\n" is
      displayed due to a vnode record being retrieved from the server that
      appears to have a duff file type (usually 0).  This prints more information
      to try and help pin down the problem.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      b134d687
  2. Apr 25, 2019
    • David Howells's avatar
      afs: Provide mount-time configurable byte-range file locking emulation · 6c6c1d63
      David Howells authored
      
      
      Provide byte-range file locking emulation that can be configured at mount
      time to one of four modes:
      
       (1) flock=local.  Locking is done locally only and no reference is made to
           the server.
      
       (2) flock=openafs.  Byte-range locking is done locally only; whole-file
           locking is done with reference to the server.  Whole-file locks cannot
           be upgraded unless the client holds an exclusive lock.
      
       (3) flock=strict.  Byte-range and whole-file locking both require a
           sufficient whole-file lock on the server.
      
       (4) flock=write.  As strict, but the client always gets an exclusive
           whole-file lock on the server.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      6c6c1d63
    • David Howells's avatar
      afs: Add more tracepoints · 80548b03
      David Howells authored
      
      
      Add four more tracepoints:
      
       (1) afs_make_fs_call1 - Split from afs_make_fs_call but takes a filename
           to log also.
      
       (2) afs_make_fs_call2 - Like the above but takes two filenames to log.
      
       (3) afs_lookup - Log the result of doing a successful lookup, including a
           negative result (fid 0:0).
      
       (4) afs_get_tree - Log the set up of a volume for mounting.
      
      It also extends the name buffer on the afs_edit_dir tracepoint to 24 chars
      and puts quotes around the filename in the text representation.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      80548b03
    • David Howells's avatar
      afs: Implement sillyrename for unlink and rename · 79ddbfa5
      David Howells authored
      
      
      Implement sillyrename for AFS unlink and rename, using the NFS variant
      implementation as a basis.
      
      Note that the asynchronous file locking extender/releaser has to be
      notified with a state change to stop it complaining if there's a race
      between that and the actual file deletion.
      
      A tracepoint, afs_silly_rename, is also added to note the silly rename and
      the cleanup.  The afs_edit_dir tracepoint is given some extra reason
      indicators and the afs_flock_ev tracepoint is given a silly-delete file
      lock cancellation indicator.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      79ddbfa5
    • David Howells's avatar
      afs: Add directory reload tracepoint · 99987c56
      David Howells authored
      
      
      Add a tracepoint (afs_reload_dir) to indicate when a directory is being
      reloaded.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      99987c56
    • David Howells's avatar
      afs: Handle lock rpc ops failing on a file that got deleted · cdfb26b4
      David Howells authored
      Holding a file lock on an AFS file does not prevent it from being deleted
      on the server, so we need to handle an error resulting from that when we
      try setting, extending or releasing a lock.
      
      Fix this by adding a "deleted" lock state and cancelling the lock extension
      process for that file and aborting all waiters for the lock.
      
      Fixes: 0fafdc9f
      
       ("afs: Fix file locking")
      Reported-by: default avatarJonathan Billings <jsbillin@umich.edu>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cdfb26b4
    • David Howells's avatar
      afs: Improve dir check failure reports · 445b1028
      David Howells authored
      
      
      Improve the content of directory check failure reports from:
      
      	kAFS: afs_dir_check_page(6d57): bad magic 1/2 is 0000
      
      to dump more information about the individual blocks in a directory page.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      445b1028
    • David Howells's avatar
      afs: Add file locking tracepoints · d4696601
      David Howells authored
      
      
      Add two tracepoints for monitoring AFS file locking.  Firstly, add one that
      follows the operational part:
      
          echo 1 >/sys/kernel/debug/tracing/events/afs/afs_flock_op/enable
      
      And add a second that more follows the event-driven part:
      
          echo 1 >/sys/kernel/debug/tracing/events/afs/afs_flock_ev/enable
      
      Individual file_lock structs seen by afs are tagged with debugging IDs that
      are displayed in the trace log to make it easier to see what's going on,
      especially as setting the first lock always seems to involve copying the
      file_lock twice.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d4696601
    • David Howells's avatar
      afs: Further fix file locking · 4be5975a
      David Howells authored
      Further fix the file locking in the afs filesystem client in a number of
      ways, including:
      
       (1) Don't submit the operation to obtain a lock from the server in a work
           queue context, but rather do it in the process context of whoever
           issued the requesting system call.
      
       (2) The owner of the file_lock struct at the front of the pending_locks
           queue now owns right to talk to the server.
      
       (3) Write locks can be instantly granted if they don't overlap with any
           other locks *and* we have a write lock on the server.
      
       (4) In the event of an authentication/permission error, all other matching
           pending locks requests are also immediately aborted.
      
       (5) Properly use VFS core locks_lock_file_wait() to distribute the server
           lock amongst local client locks, including waiting for the lock to
           become available.
      
      Test with:
      
      	sqlite3 /afs/.../scratch/billings.sqlite <<EOF
      	CREATE TABLE hosts (
      	    hostname varchar(80),
      	    shorthost varchar(80),
      	    room varchar(30),
      	    building varchar(30),
      	    PRIMARY KEY(shorthost)
      	    );
      	EOF
      
      With the version of sqlite3 that I have, this should fail consistently with
      EAGAIN, whether or not the program is straced (which introduces some delays
      between lock syscalls).
      
      Fixes: 0fafdc9f
      
       ("afs: Fix file locking")
      Reported-by: default avatarJonathan Billings <jsbillin@umich.edu>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      4be5975a
    • David Howells's avatar
      afs: Fix AFS file locking to allow fine grained locks · 68ce801f
      David Howells authored
      
      
      Fix AFS file locking to allow fine grained locks as some applications, such
      as firefox, won't work if they can't take such locks on certain state files
      - thereby preventing the use of kAFS to distribute a home directory.
      
      Note that this cannot be made completely functional as the protocol only
      has provision for whole-file locks, so there exists the possibility of a
      process deadlocking itself by getting a partial read-lock on a file first
      and then trying to get a non-overlapping write-lock - but we got the
      server's read lock with the first lock, so we're now stuck.
      
      OpenAFS solves this by just granting any partial-range lock directly
      without consulting the server - and hoping there's no remote collision.  I
      want to implement that in a separate patch and it requires a bit more
      thought.
      
      Fixes: 8d6c554126b8 ("AFS: implement file locking")
      Reported-by: default avatarJonathan Billings <jsbillings@jsbillings.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      68ce801f
    • David Howells's avatar
      afs: Calculate lock extend timer from set/extend reply reception · a690f60a
      David Howells authored
      
      
      Record the timestamp on the first reply DATA packet received in response to
      a set- or extend-lock operation, then use this to calculate the time
      remaining till the lock expires rather than using whatever time the
      requesting process wakes up and finishes processing the operation as a
      base.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      a690f60a
    • David Howells's avatar
      afs: Split wait from afs_make_call() · 0b9bf381
      David Howells authored
      
      
      Split the call to afs_wait_for_call_to_complete() from afs_make_call() to
      make it easier to handle asynchronous calls and to make it easier to
      convert a synchronous call to an asynchronous one in future, for instance
      when someone tries to interrupt an operation by pressing Ctrl-C.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      0b9bf381
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · cd8dead0
      Linus Torvalds authored
      Pull networking fixes from David Miller:
       "Just the usual assortment of small'ish fixes:
      
         1) Conntrack timeout is sometimes not initialized properly, from
            Alexander Potapenko.
      
         2) Add a reasonable range limit to tcp_min_rtt_wlen to avoid
            undefined behavior. From ZhangXiaoxu.
      
         3) des1 field of descriptor in stmmac driver is initialized with the
            wrong variable. From Yue Haibing.
      
         4) Increase mlxsw pci sw reset timeout a little bit more, from Ido
            Schimmel.
      
         5) Match IOT2000 stmmac devices more accurately, from Su Bao Cheng.
      
         6) Fallback refcount fix in TLS code, from Jakub Kicinski.
      
         7) Fix max MTU check when using XDP in mlx5, from Maxim Mikityanskiy.
      
         8) Fix recursive locking in team driver, from Hangbin Liu.
      
         9) Fix tls_set_device_offload_Rx() deadlock, from Jakub Kicinski.
      
        10) Don't use napi_alloc_frag() outside of softiq context of socionext
            driver, from Ilias Apalodimas.
      
        11) MAC address increment overflow in ncsi, from Tao Ren.
      
        12) Fix a regression in 8K/1M pool switching of RDS, from Zhu Yanjun.
      
        13) ipv4_link_failure has to validate the headers that are actually
            there because RAW sockets can pass in arbitrary garbage, from Eric
            Dumazet"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (43 commits)
        ipv4: add sanity checks in ipv4_link_failure()
        net/rose: fix unbound loop in rose_loopback_timer()
        rxrpc: fix race condition in rxrpc_input_packet()
        net: rds: exchange of 8K and 1M pool
        net: vrf: Fix operation not supported when set vrf mac
        net/ncsi: handle overflow when incrementing mac address
        net: socionext: replace napi_alloc_frag with the netdev variant on init
        net: atheros: fix spelling mistake "underun" -> "underrun"
        spi: ST ST95HF NFC: declare missing of table
        spi: Micrel eth switch: declare missing of table
        net: stmmac: move stmmac_check_ether_addr() to driver probe
        netfilter: fix nf_l4proto_log_invalid to log invalid packets
        netfilter: never get/set skb->tstamp
        netfilter: ebtables: CONFIG_COMPAT: drop a bogus WARN_ON
        Documentation: decnet: remove reference to CONFIG_DECNET_ROUTE_FWMARK
        dt-bindings: add an explanation for internal phy-mode
        net/tls: don't leak IV and record seq when offload fails
        net/tls: avoid potential deadlock in tls_set_device_offload_rx()
        selftests/net: correct the return value for run_afpackettests
        team: fix possible recursive locking when add slaves
        ...
      cd8dead0
    • Linus Torvalds's avatar
      Merge tag 'leds-for-5.1-rc7' of... · 11bfe647
      Linus Torvalds authored
      Merge tag 'leds-for-5.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
      
      Pull LED update from Jacek Anaszewski:
       "A single change to MAINTAINERS:
      
        We announce a new LED reviewer - Dan Murphy"
      
      * tag 'leds-for-5.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds:
        MAINTAINERS: LEDs: Add designated reviewer for LED subsystem
      11bfe647
    • Eric Dumazet's avatar
      ipv4: add sanity checks in ipv4_link_failure() · 20ff83f1
      Eric Dumazet authored
      Before calling __ip_options_compile(), we need to ensure the network
      header is a an IPv4 one, and that it is already pulled in skb->head.
      
      RAW sockets going through a tunnel can end up calling ipv4_link_failure()
      with total garbage in the skb, or arbitrary lengthes.
      
      syzbot report :
      
      BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:355 [inline]
      BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0x294/0x1120 net/ipv4/ip_options.c:123
      Write of size 69 at addr ffff888096abf068 by task syz-executor.4/9204
      
      CPU: 0 PID: 9204 Comm: syz-executor.4 Not tainted 5.1.0-rc5+ #77
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       check_memory_region_inline mm/kasan/generic.c:185 [inline]
       check_memory_region+0x123/0x190 mm/kasan/generic.c:191
       memcpy+0x38/0x50 mm/kasan/common.c:133
       memcpy include/linux/string.h:355 [inline]
       __ip_options_echo+0x294/0x1120 net/ipv4/ip_options.c:123
       __icmp_send+0x725/0x1400 net/ipv4/icmp.c:695
       ipv4_link_failure+0x29f/0x550 net/ipv4/route.c:1204
       dst_link_failure include/net/dst.h:427 [inline]
       vti6_xmit net/ipv6/ip6_vti.c:514 [inline]
       vti6_tnl_xmit+0x10d4/0x1c0c net/ipv6/ip6_vti.c:553
       __netdev_start_xmit include/linux/netdevice.h:4414 [inline]
       netdev_start_xmit include/linux/netdevice.h:4423 [inline]
       xmit_one net/core/dev.c:3292 [inline]
       dev_hard_start_xmit+0x1b2/0x980 net/core/dev.c:3308
       __dev_queue_xmit+0x271d/0x3060 net/core/dev.c:3878
       dev_queue_xmit+0x18/0x20 net/core/dev.c:3911
       neigh_direct_output+0x16/0x20 net/core/neighbour.c:1527
       neigh_output include/net/neighbour.h:508 [inline]
       ip_finish_output2+0x949/0x1740 net/ipv4/ip_output.c:229
       ip_finish_output+0x73c/0xd50 net/ipv4/ip_output.c:317
       NF_HOOK_COND include/linux/netfilter.h:278 [inline]
       ip_output+0x21f/0x670 net/ipv4/ip_output.c:405
       dst_output include/net/dst.h:444 [inline]
       NF_HOOK include/linux/netfilter.h:289 [inline]
       raw_send_hdrinc net/ipv4/raw.c:432 [inline]
       raw_sendmsg+0x1d2b/0x2f20 net/ipv4/raw.c:663
       inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xdd/0x130 net/socket.c:661
       sock_write_iter+0x27c/0x3e0 net/socket.c:988
       call_write_iter include/linux/fs.h:1866 [inline]
       new_sync_write+0x4c7/0x760 fs/read_write.c:474
       __vfs_write+0xe4/0x110 fs/read_write.c:487
       vfs_write+0x20c/0x580 fs/read_write.c:549
       ksys_write+0x14f/0x2d0 fs/read_write.c:599
       __do_sys_write fs/read_write.c:611 [inline]
       __se_sys_write fs/read_write.c:608 [inline]
       __x64_sys_write+0x73/0xb0 fs/read_write.c:608
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x458c29
      Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f293b44bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458c29
      RDX: 0000000000000014 RSI: 00000000200002c0 RDI: 0000000000000003
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f293b44c6d4
      R13: 00000000004c8623 R14: 00000000004ded68 R15: 00000000ffffffff
      
      The buggy address belongs to the page:
      page:ffffea00025aafc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      flags: 0x1fffc0000000000()
      raw: 01fffc0000000000 0000000000000000 ffffffff025a0101 0000000000000000
      raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888096abef80: 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 f2
       ffff888096abf000: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
      >ffff888096abf080: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
                               ^
       ffff888096abf100: 00 00 00 00 f1 f1 f1 f1 00 00 f3 f3 00 00 00 00
       ffff888096abf180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Fixes: ed0de45a
      
       ("ipv4: recompile ip options in ipv4_link_failure")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Stephen Suryaputra <ssuryaextr@gmail.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20ff83f1
    • Eric Dumazet's avatar
      net/rose: fix unbound loop in rose_loopback_timer() · 0453c682
      Eric Dumazet authored
      This patch adds a limit on the number of skbs that fuzzers can queue
      into loopback_queue. 1000 packets for rose loopback seems more than enough.
      
      Then, since we now have multiple cpus in most linux hosts,
      we also need to limit the number of skbs rose_loopback_timer()
      can dequeue at each round.
      
      rose_loopback_queue() can be drop-monitor friendly, calling
      consume_skb() or kfree_skb() appropriately.
      
      Finally, use mod_timer() instead of del_timer() + add_timer()
      
      syzbot report was :
      
      rcu: INFO: rcu_preempt self-detected stall on CPU
      rcu:    0-...!: (10499 ticks this GP) idle=536/1/0x4000000000000002 softirq=103291/103291 fqs=34
      rcu:     (t=10500 jiffies g=140321 q=323)
      rcu: rcu_preempt kthread starved for 10426 jiffies! g140321 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1
      rcu: RCU grace-period kthread stack dump:
      rcu_preempt     I29168    10      2 0x80000000
      Call Trace:
       context_switch kernel/sched/core.c:2877 [inline]
       __schedule+0x813/0x1cc0 kernel/sched/core.c:3518
       schedule+0x92/0x180 kernel/sched/core.c:3562
       schedule_timeout+0x4db/0xfd0 kernel/time/timer.c:1803
       rcu_gp_fqs_loop kernel/rcu/tree.c:1971 [inline]
       rcu_gp_kthread+0x962/0x17b0 kernel/rcu/tree.c:2128
       kthread+0x357/0x430 kernel/kthread.c:253
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      NMI backtrace for cpu 0
      CPU: 0 PID: 7632 Comm: kworker/0:4 Not tainted 5.1.0-rc5+ #172
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: events iterate_cleanup_work
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       nmi_cpu_backtrace.cold+0x63/0xa4 lib/nmi_backtrace.c:101
       nmi_trigger_cpumask_backtrace+0x1be/0x236 lib/nmi_backtrace.c:62
       arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
       trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
       rcu_dump_cpu_stacks+0x183/0x1cf kernel/rcu/tree.c:1223
       print_cpu_stall kernel/rcu/tree.c:1360 [inline]
       check_cpu_stall kernel/rcu/tree.c:1434 [inline]
       rcu_pending kernel/rcu/tree.c:3103 [inline]
       rcu_sched_clock_irq.cold+0x500/0xa4a kernel/rcu/tree.c:2544
       update_process_times+0x32/0x80 kernel/time/timer.c:1635
       tick_sched_handle+0xa2/0x190 kernel/time/tick-sched.c:161
       tick_sched_timer+0x47/0x130 kernel/time/tick-sched.c:1271
       __run_hrtimer kernel/time/hrtimer.c:1389 [inline]
       __hrtimer_run_queues+0x33e/0xde0 kernel/time/hrtimer.c:1451
       hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1509
       local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1035 [inline]
       smp_apic_timer_interrupt+0x120/0x570 arch/x86/kernel/apic/apic.c:1060
       apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
      RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x50 kernel/kcov.c:95
      Code: 89 25 b4 6e ec 08 41 bc f4 ff ff ff e8 cd 5d ea ff 48 c7 05 9e 6e ec 08 00 00 00 00 e9 a4 e9 ff ff 90 90 90 90 90 90 90 90 90 <55> 48 89 e5 48 8b 75 08 65 48 8b 04 25 00 ee 01 00 65 8b 15 c8 60
      RSP: 0018:ffff8880ae807ce0 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
      RAX: ffff88806fd40640 RBX: dffffc0000000000 RCX: ffffffff863fbc56
      RDX: 0000000000000100 RSI: ffffffff863fbc1d RDI: ffff88808cf94228
      RBP: ffff8880ae807d10 R08: ffff88806fd40640 R09: ffffed1015d00f8b
      R10: ffffed1015d00f8a R11: 0000000000000003 R12: ffff88808cf941c0
      R13: 00000000fffff034 R14: ffff8882166cd840 R15: 0000000000000000
       rose_loopback_timer+0x30d/0x3f0 net/rose/rose_loopback.c:91
       call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
       expire_timers kernel/time/timer.c:1362 [inline]
       __run_timers kernel/time/timer.c:1681 [inline]
       __run_timers kernel/time/timer.c:1649 [inline]
       run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
       __do_softirq+0x266/0x95a kernel/softirq.c:293
       do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1027
      
      Fixes: 1da177e4
      
       ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0453c682
    • Eric Dumazet's avatar
      rxrpc: fix race condition in rxrpc_input_packet() · 032be5f1
      Eric Dumazet authored
      After commit 5271953c ("rxrpc: Use the UDP encap_rcv hook"),
      rxrpc_input_packet() is directly called from lockless UDP receive
      path, under rcu_read_lock() protection.
      
      It must therefore use RCU rules :
      
      - udp_sk->sk_user_data can be cleared at any point in this function.
        rcu_dereference_sk_user_data() is what we need here.
      
      - Also, since sk_user_data might have been set in rxrpc_open_socket()
        we must observe a proper RCU grace period before kfree(local) in
        rxrpc_lookup_local()
      
      v4: @local can be NULL in xrpc_lookup_local() as reported by kbuild test robot <lkp@intel.com>
              and Julia Lawall <julia.lawall@lip6.fr>, thanks !
      
      v3,v2 : addressed David Howells feedback, thanks !
      
      syzbot reported :
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 0 PID: 19236 Comm: syz-executor703 Not tainted 5.1.0-rc6 #79
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:__lock_acquire+0xbef/0x3fb0 kernel/locking/lockdep.c:3573
      Code: 00 0f 85 a5 1f 00 00 48 81 c4 10 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 21 00 00 49 81 7d 00 20 54 9c 89 0f 84 cf f4
      RSP: 0018:ffff88809d7aef58 EFLAGS: 00010002
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000000026 RSI: 0000000000000000 RDI: 0000000000000001
      RBP: ffff88809d7af090 R08: 0000000000000001 R09: 0000000000000001
      R10: ffffed1015d05bc7 R11: ffff888089428600 R12: 0000000000000000
      R13: 0000000000000130 R14: 0000000000000001 R15: 0000000000000001
      FS:  00007f059044d700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004b6040 CR3: 00000000955ca000 CR4: 00000000001406f0
      Call Trace:
       lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:4211
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
       _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:152
       skb_queue_tail+0x26/0x150 net/core/skbuff.c:2972
       rxrpc_reject_packet net/rxrpc/input.c:1126 [inline]
       rxrpc_input_packet+0x4a0/0x5536 net/rxrpc/input.c:1414
       udp_queue_rcv_one_skb+0xaf2/0x1780 net/ipv4/udp.c:2011
       udp_queue_rcv_skb+0x128/0x730 net/ipv4/udp.c:2085
       udp_unicast_rcv_skb.isra.0+0xb9/0x360 net/ipv4/udp.c:2245
       __udp4_lib_rcv+0x701/0x2ca0 net/ipv4/udp.c:2301
       udp_rcv+0x22/0x30 net/ipv4/udp.c:2482
       ip_protocol_deliver_rcu+0x60/0x8f0 net/ipv4/ip_input.c:208
       ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234
       NF_HOOK include/linux/netfilter.h:289 [inline]
       NF_HOOK include/linux/netfilter.h:283 [inline]
       ip_local_deliver+0x1e9/0x520 net/ipv4/ip_input.c:255
       dst_input include/net/dst.h:450 [inline]
       ip_rcv_finish+0x1e1/0x300 net/ipv4/ip_input.c:413
       NF_HOOK include/linux/netfilter.h:289 [inline]
       NF_HOOK include/linux/netfilter.h:283 [inline]
       ip_rcv+0xe8/0x3f0 net/ipv4/ip_input.c:523
       __netif_receive_skb_one_core+0x115/0x1a0 net/core/dev.c:4987
       __netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5099
       netif_receive_skb_internal+0x117/0x660 net/core/dev.c:5202
       napi_frags_finish net/core/dev.c:5769 [inline]
       napi_gro_frags+0xade/0xd10 net/core/dev.c:5843
       tun_get_user+0x2f24/0x3fb0 drivers/net/tun.c:1981
       tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2027
       call_write_iter include/linux/fs.h:1866 [inline]
       do_iter_readv_writev+0x5e1/0x8e0 fs/read_write.c:681
       do_iter_write fs/read_write.c:957 [inline]
       do_iter_write+0x184/0x610 fs/read_write.c:938
       vfs_writev+0x1b3/0x2f0 fs/read_write.c:1002
       do_writev+0x15e/0x370 fs/read_write.c:1037
       __do_sys_writev fs/read_write.c:1110 [inline]
       __se_sys_writev fs/read_write.c:1107 [inline]
       __x64_sys_writev+0x75/0xb0 fs/read_write.c:1107
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: 5271953c
      
       ("rxrpc: Use the UDP encap_rcv hook")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      032be5f1
    • Dan Murphy's avatar
      MAINTAINERS: LEDs: Add designated reviewer for LED subsystem · 52fb56f7
      Dan Murphy authored
      
      
      Add a designated reviewer for the LED subsystem as there
      are already two maintainers assigned.
      
      Signed-off-by: default avatarDan Murphy <dmurphy@ti.com>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarJacek Anaszewski <jacek.anaszewski@gmail.com>
      52fb56f7
    • Zhu Yanjun's avatar
      net: rds: exchange of 8K and 1M pool · 4b9fc714
      Zhu Yanjun authored
      Before the commit 490ea596 ("RDS: IB: move FMR code to its own file"),
      when the dirty_count is greater than 9/10 of max_items of 8K pool,
      1M pool is used, Vice versa. After the commit 490ea596 ("RDS: IB: move
      FMR code to its own file"), the above is removed. When we make the
      following tests.
      
      Server:
        rds-stress -r 1.1.1.16 -D 1M
      
      Client:
        rds-stress -r 1.1.1.14 -s 1.1.1.16 -D 1M
      
      The following will appear.
      "
      connecting to 1.1.1.16:4000
      negotiated options, tasks will start in 2 seconds
      Starting up..header from 1.1.1.166:4001 to id 4001 bogus
      ..
      tsks  tx/s  rx/s tx+rx K/s  mbi K/s  mbo K/s tx us/c  rtt us
      cpu %
         1    0    0     0.00     0.00     0.00    0.00 0.00 -1.00
         1    0    0     0.00     0.00     0.00    0.00 0.00 -1.00
         1    0    0     0.00     0.00     0.00    0.00 0.00 -1.00
         1    0    0     0.00     0.00     0.00    0.00 0.00 -1.00
         1    0    0     0.00     0.00     0.00    0.00 0.00 -1.00
      ...
      "
      So this exchange between 8K and 1M pool is added back.
      
      Fixes: commit 490ea596
      
       ("RDS: IB: move FMR code to its own file")
      Signed-off-by: default avatarZhu Yanjun <yanjun.zhu@oracle.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b9fc714
    • Miaohe Lin's avatar
      net: vrf: Fix operation not supported when set vrf mac · 6819e3f6
      Miaohe Lin authored
      
      
      Vrf device is not able to change mac address now because lack of
      ndo_set_mac_address. Complete this in case some apps need to do
      this.
      
      Reported-by: default avatarHui Wang <wanghui104@huawei.com>
      Signed-off-by: default avatarMiaohe Lin <linmiaohe@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6819e3f6
  3. Apr 24, 2019
  4. Apr 23, 2019