| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 18 Mar 2009 01:08:49 +0900 From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp> To: Mikulas Patocka <mpatocka@...hat.com> Cc: linux-kernel@...r.kernel.org Subject: Re: [PATCH] deadlock when swapping to FAT Mikulas Patocka <mpatocka@...hat.com> writes: > On Sun, 15 Mar 2009, OGAWA Hirofumi wrote: > >> Mikulas Patocka <mpatocka@...hat.com> writes: >> >> > Note that the same race condition is happening in all the other >> > filesystems. Maybe move that i_alloc_sem up to ->bmap method caller? >> >> It can be. However, I guess locking strategy would be per >> filesystems. Because the fs may be using i_alloc_sem in get_block >> already. > > Which ones take it in get_block? I grepped for i_alloc_sem and don't see > them. Besides, it is mostly taken only for read and recursive taking of > read-lock for read is allowed. It is taken for writes only in truncate. I don't know which fs take it, and whether i_alloc_sem is enough for which fs. It was just guess. And important one is locking strategy of that would be per filesystems. E.g. it seems XFS is taking own lock. Well, personally, I don't have objection to add i_alloc_sem, however I'm not sure, what does i_alloc_sem guarantee for other fs. -- OGAWA Hirofumi <hirofumi@...l.parknet.co.jp> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists