Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 18 4月, 2008 22 次提交
  3. 16 4月, 2008 2 次提交
  5. 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
  7. 12 4月, 2008 1 次提交
  9. 11 4月, 2008 5 次提交
  11. 10 4月, 2008 4 次提交
  13. 09 4月, 2008 2 次提交
  15. 05 4月, 2008 1 次提交
    • L
      Be more careful about marking buffers dirty · 1be62dc1
      由 Linus Torvalds 提交于 
      Mikulas Patocka noted that the optimization where we check if a buffer
was already dirty (and we avoid re-dirtying it) was not really SMP-safe.

Since the read of the old status was not synchronized with anything, an
aggressive CPU re-ordering of memory accesses might have moved that read
up to before the data was even written to the buffer, and another CPU
that cleaned it again, causing the newly dirty state to never actually
hit the disk.

Admittedly this would probably never trigger in practice, but it's still
wrong.

Mikulas sent a patch that fixed the problem, but I dislike the subtlety
of the whole optimization, so this is an alternate fix that is more
explicit about the particular SMP ordering for the optimization, and
separates out the speculative reads of the buffer state into its own
conditional (and makes the memory barrier only happen if we are likely
to actually hit the optimized case in the first place).

I considered removing the optimization entirely, but Andrew argued for
it's continued existence. I'm a push-over.

Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1be62dc1
  17. 04 4月, 2008 1 次提交