1. 08 4月, 2017 1 次提交
    • M
      orangefs: move features validation to fix filesystem hang · cefdc26e
      Martin Brandenburg 提交于
      Without this fix (and another to the userspace component itself
      described later), the kernel will be unable to process any OrangeFS
      requests after the userspace component is restarted (due to a crash or
      at the administrator's behest).
      
      The bug here is that inside orangefs_remount, the orangefs_request_mutex
      is locked.  When the userspace component restarts while the filesystem
      is mounted, it sends a ORANGEFS_DEV_REMOUNT_ALL ioctl to the device,
      which causes the kernel to send it a few requests aimed at synchronizing
      the state between the two.  While this is happening the
      orangefs_request_mutex is locked to prevent any other requests going
      through.
      
      This is only half of the bugfix.  The other half is in the userspace
      component which outright ignores(!) requests made before it considers
      the filesystem remounted, which is after the ioctl returns.  Of course
      the ioctl doesn't return until after the userspace component responds to
      the request it ignores.  The userspace component has been changed to
      allow ORANGEFS_VFS_OP_FEATURES regardless of the mount status.
      
      Mike Marshall says:
       "I've tested this patch against the fixed userspace part. This patch is
        real important, I hope it can make it into 4.11...
      
        Here's what happens when the userspace daemon is restarted, without
        the patch:
      
          =============================================
          [ INFO: possible recursive locking detected ]
          [   4.10.0-00007-ge98bdb30 #1 Not tainted    ]
          ---------------------------------------------
          pvfs2-client-co/29032 is trying to acquire lock:
           (orangefs_request_mutex){+.+.+.}, at: service_operation+0x3c7/0x7b0 [orangefs]
                        but task is already holding lock:
           (orangefs_request_mutex){+.+.+.}, at: dispatch_ioctl_command+0x1bf/0x330 [orangefs]
      
          CPU: 0 PID: 29032 Comm: pvfs2-client-co Not tainted 4.10.0-00007-ge98bdb30 #1
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014
          Call Trace:
           __lock_acquire+0x7eb/0x1290
           lock_acquire+0xe8/0x1d0
           mutex_lock_killable_nested+0x6f/0x6e0
           service_operation+0x3c7/0x7b0 [orangefs]
           orangefs_remount+0xea/0x150 [orangefs]
           dispatch_ioctl_command+0x227/0x330 [orangefs]
           orangefs_devreq_ioctl+0x29/0x70 [orangefs]
           do_vfs_ioctl+0xa3/0x6e0
           SyS_ioctl+0x79/0x90"
      Signed-off-by: NMartin Brandenburg <martin@omnibond.com>
      Acked-by: NMike Marshall <hubcap@omnibond.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cefdc26e
  2. 02 3月, 2017 1 次提交
  3. 04 10月, 2016 1 次提交
  4. 22 9月, 2016 1 次提交
  5. 16 8月, 2016 1 次提交
  6. 13 8月, 2016 1 次提交
    • M
      orangefs: add features op · 482664dd
      Martin Brandenburg 提交于
      This is a new userspace operation, which will be done if the client-core
      version is greater than or equal to 2.9.6. This will provide a way to
      implement optional features and to determine which features are
      supported by the client-core. If the client-core version is older than
      2.9.6, no optional features are supported and the op will not be done.
      
      The intent is to allow protocol extensions without relying on the
      client-core's current behavior of ignoring what it doesn't understand.
      Signed-off-by: NMartin Brandenburg <martin@omnibond.com>
      482664dd
  7. 26 3月, 2016 2 次提交
  8. 24 3月, 2016 1 次提交
  9. 25 2月, 2016 2 次提交
  10. 05 2月, 2016 1 次提交
    • M
      Orangefs: clean up slab allocation. · 2d4cae0d
      Mike Marshall 提交于
      A couple of caches were no longer needed:
      
       - iov_iter improvements to orangefs_devreq_write_iter eliminated
         the need for the dev_req_cache.
      
       - removal (months ago) of the old AIO code eliminated the need
         for the kiocb_cache.
      
      Also, deobfuscation of use of GFP_KERNEL when calling kmem_cache_(z)alloc
      for remaining caches.
      Signed-off-by: NMike Marshall <hubcap@omnibond.com>
      2d4cae0d
  11. 14 1月, 2016 1 次提交
  12. 05 1月, 2016 1 次提交
  13. 05 12月, 2015 1 次提交
  14. 04 12月, 2015 1 次提交
  15. 14 11月, 2015 3 次提交
  16. 03 10月, 2015 3 次提交