On Sat, 2012-03-03 at 21:55 +0800, Fengguang Wu wrote: > 13 1125 /c/linux/fs/ubifs/file.c <<do_truncation>> <===== deadlockable Sorry, but could you please explain once again how the deadlock may happen? > It seems they are all safe except for ubifs. ubifs may actually > deadlock from the above do_truncation() caller. However it should be > fixable because the ubifs call for writeback_inodes_sb_nr() sounds > very brute force writeback and wait and there may well be better way > out. I do not think this "fixable" - this is part of UBIFS design to force write-back when we are not sure we have enough space. The problem is that we do not know how much space the dirty data in RAM will take on the flash media (after it is actually written-back) - e.g., because we compress all the data (UBIFS performs on-the-flight compression). So we do pessimistic assumptions and allow dirtying more and more data as long as we know for sure that there is enough flash space on the media for the worst-case scenario (data are not compressible). This is what the UBIFS budgeting subsystem does. Once the budgeting sub-system sees that we are not going to have enough flash space for the worst-case scenario, it starts forcing write-back to push some dirty data out to the flash media and update the budgeting numbers, and get more realistic picture. So basically, before you can change _anything_ on UBIFS file-system, you need to budget for the space. Even when you truncate - because truncation is also about allocating more space for writing the updated inode and update the FS index. (Remember, all writes are out-of-place in UBIFS because we work with raw flash, not a block device). -- Best Regards, Artem Bityutskiy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>