1. 04 11月, 2011 2 次提交
  2. 02 11月, 2011 2 次提交
  3. 30 10月, 2011 2 次提交
  4. 29 10月, 2011 2 次提交
  5. 28 10月, 2011 2 次提交
    • A
      vfs: do (nearly) lockless generic_file_llseek · ef3d0fd2
      Andi Kleen 提交于
      The i_mutex lock use of generic _file_llseek hurts.  Independent processes
      accessing the same file synchronize over a single lock, even though
      they have no need for synchronization at all.
      
      Under high utilization this can cause llseek to scale very poorly on larger
      systems.
      
      This patch does some rethinking of the llseek locking model:
      
      First the 64bit f_pos is not necessarily atomic without locks
      on 32bit systems. This can already cause races with read() today.
      This was discussed on linux-kernel in the past and deemed acceptable.
      The patch does not change that.
      
      Let's look at the different seek variants:
      
      SEEK_SET: Doesn't really need any locking.
      If there's a race one writer wins, the other loses.
      
      For 32bit the non atomic update races against read()
      stay the same. Without a lock they can also happen
      against write() now.  The read() race was deemed
      acceptable in past discussions, and I think if it's
      ok for read it's ok for write too.
      
      => Don't need a lock.
      
      SEEK_END: This behaves like SEEK_SET plus it reads
      the maximum size too. Reading the maximum size would have the
      32bit atomic problem. But luckily we already have a way to read
      the maximum size without locking (i_size_read), so we
      can just use that instead.
      
      Without i_mutex there is no synchronization with write() anymore,
      however since the write() update is atomic on 64bit it just behaves
      like another racy SEEK_SET.  On non atomic 32bit it's the same
      as SEEK_SET.
      
      => Don't need a lock, but need to use i_size_read()
      
      SEEK_CUR: This has a read-modify-write race window
      on the same file. One could argue that any application
      doing unsynchronized seeks on the same file is already broken.
      But for the sake of not adding a regression here I'm
      using the file->f_lock to synchronize this. Using this
      lock is much better than the inode mutex because it doesn't
      synchronize between processes.
      
      => So still need a lock, but can use a f_lock.
      
      This patch implements this new scheme in generic_file_llseek.
      I dropped generic_file_llseek_unlocked and changed all callers.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      ef3d0fd2
    • S
      Add definition for share encryption · 96814ecb
      Steve French 提交于
      Samba supports a setfs info level to negotiate encrypted
      shares.  This patch adds the defines so we recognize
      this info level.  Later patches will add the enablement
      for it.
      Acked-by: NJeremy Allison <jra@samba.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      96814ecb
  6. 25 10月, 2011 4 次提交
  7. 23 10月, 2011 1 次提交
  8. 21 10月, 2011 1 次提交
  9. 20 10月, 2011 17 次提交
  10. 18 10月, 2011 2 次提交
  11. 17 10月, 2011 1 次提交
    • S
      cifs: Call id to SID mapping functions to change owner/group (try #4 repost) · a5ff3769
      Shirish Pargaonkar 提交于
      Now build security descriptor to change either owner or group at the
      server.  Initially security descriptor was built to change only
      (D)ACL, that functionality has been extended.
      
      When either an Owner or a Group of a file object at the server is changed,
      rest of security descriptor remains same (DACL etc.).
      
      To set security descriptor, it is necessary to open that file
      with permission bits of either WRITE_DAC if DACL is being modified or
      WRITE_OWNER (Take Ownership) if Owner or Group is being changed.
      
      It is the server that decides whether a set security descriptor with
      either owner or group change succeeds or not.
      Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      a5ff3769
  12. 14 10月, 2011 4 次提交