1. 16 4月, 2008 32 次提交
  2. 15 4月, 2008 2 次提交
    • A
      JFFS2 Fix of panics caused by wrong condition for hole frag creation in write_begin · abe2f414
      Alexey Korolev 提交于
      This fixes a regression introduced in commit
      205c109a when switching to
      write_begin/write_end operations in JFFS2.
      
      The page offset is miscalculated, leading to corruption of the fragment
      lists and subsequently to memory corruption and panics.
      
      [ Side note: the bug is a fairly direct result of the naming.  Nick was
        likely misled by the use of "offs", since we tend to use the notion of
        "offset" not as an absolute position, but as an offset _within_ a page
        or allocation.
      
        Alternatively, a "pgoff_t" is a page index, but not a byte offset -
        our VM naming can be a bit confusing.
      
        So in this case, a VM person would likely have called this a "pos",
        not an "offs", or perhaps talked about byte offsets rather than page
        offsets (since it's counted in bytes, not pages).    - Linus ]
      Signed-off-by: NAlexey Korolev <akorolev@infradead.org>
      Signed-off-by: NVasiliy Leonenko <vasiliy.leonenko@mail.ru>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      abe2f414
    • J
      locks: fix possible infinite loop in fcntl(F_SETLKW) over nfs · 19e729a9
      J. Bruce Fields 提交于
      Miklos Szeredi found the bug:
      
      	"Basically what happens is that on the server nlm_fopen() calls
      	nfsd_open() which returns -EACCES, to which nlm_fopen() returns
      	NLM_LCK_DENIED.
      
      	"On the client this will turn into a -EAGAIN (nlm_stat_to_errno()),
      	which in will cause fcntl_setlk() to retry forever."
      
      So, for example, opening a file on an nfs filesystem, changing
      permissions to forbid further access, then trying to lock the file,
      could result in an infinite loop.
      
      And Trond Myklebust identified the culprit, from Marc Eshel and I:
      
      	7723ec97 "locks: factor out
      	generic/filesystem switch from setlock code"
      
      That commit claimed to just be reshuffling code, but actually introduced
      a behavioral change by calling the lock method repeatedly as long as it
      returned -EAGAIN.
      
      We assumed this would be safe, since we assumed a lock of type SETLKW
      would only return with either success or an error other than -EAGAIN.
      However, nfs does can in fact return -EAGAIN in this situation, and
      independently of whether that behavior is correct or not, we don't
      actually need this change, and it seems far safer not to depend on such
      assumptions about the filesystem's ->lock method.
      
      Therefore, revert the problematic part of the original commit.  This
      leaves vfs_lock_file() and its other callers unchanged, while returning
      fcntl_setlk and fcntl_setlk64 to their former behavior.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Tested-by: NMiklos Szeredi <mszeredi@suse.cz>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Marc Eshel <eshel@almaden.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      19e729a9
  3. 14 4月, 2008 6 次提交