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? Thanks, Eddie -- 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
