On Mon, Jul 9, 2018 at 9:19 AM, Eddie Horng <eddiehorng.tw@xxxxxxxxx> wrote: > 2018-07-07 3:30 GMT+08:00 Amir Goldstein <amir73il@xxxxxxxxx>: >> No. Only need to take care to always lock overlay inode and not underlying >> inode. It says you Acked this change, but you probably don't remember ;-) >> >> c568d68341be locks: fix file locking on overlayfs >> >> Eddie, >> >> Can you try to reproduce with kernel v4.18-rc1, which includes the fix: >> >> 01b39dcc9568 ovl: use inode_insert5() to hash a newly created inode >> >> I wasn't aware that the fix is for a real life bug, but worth the check, >> because leaking locks seems somewhat related to the fix - having >> non unique inode struct for same inode number with combination of >> locks and NFS is asking for trouble. >> >> Thanks, >> Amir. > > Still reproduced the Leaked message on 4.18.0-rc4+. > The use case is build android, the Leaked message seems caused by each > flock() call through the build process, but if I make a simple flock() > on a file unser > the same dir, there's no any problem or dmesg message with that. Could the > problem is caused by many files are writing concurrently in the build process? > I have no clue. Is the leaked lock and crash on the client or the server? If you can get an strace from the process that gets the Leaked message maybe it will give us a clue to the sort of file descriptor of the leaked file and how it was opened. Alternatively print the inode numbers and file types of flock calls to see where we have a mismatch. Thanks, Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
