[lkml]   [2008]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: vfat BKL/lock_super regression in v2.6.26-rc3-g8f59342
* Linus Torvalds <> [080819 18:19]:
> And I think you hit this issue because you probably mounted the USB stick
> as a "sync" (or dirsync) mount - which is what some distros do by default,
> even if it is known to cause problems for some flash cards that don't do a
> good job at wear levelling.

You're right. I turned on sync a while back so I could just pull the
stick out w/o the need to do a manual sync... probably not a good idea
on my part with respect to the wear of the media.

> But it's good that you did that, because all _my_ testing (which was
> admittedly very deficient) had been done with a default mount without that
> thing.

My ignorance paid off!

> Btw, quite often, the right solution may be to remove one of the locks
> entirely. FAT should actually have been largely BKL free, and my
> conversion of BKL to super-lock was "overly eager" exactly because it's
> easier to find deadlocks (and debug things carefully and handle them as
> they pop up) than it is to find races (which are almost impossible to
> debug and pinpoint).

I totally agree. After spending a couple of hours (while doing other
things) bisecting the tree, I found the commit that introduced the
regression. In contrast, I was able to find the double-lock in 5

> In particular, I think fat_write_inode() really is safe.

I wasn't sure there.

> So I'm pretty sure the right fix is to just remove [un]lock_super()
> entirely from fat_write_inode().

Ok, I will test your patch and let you know in a few minutes.



 \ /
  Last update: 2008-08-20 02:07    [W:0.052 / U:8.780 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site