On Fri, Aug 18, 2023 at 05:35:25PM -0700, Jaegeuk Kim wrote: > May I know if this works? > > https://lore.kernel.org/linux-f2fs-devel/20230819003012.3473675-1-jaeg...@kernel.org/T/#u >
Yes, that fixes the problem for me. That makes me wonder, though: Why not just use the _nested functions unconditionally ? Thanks, Guenter > On 08/18, Jaegeuk Kim wrote: > > Chao, > > > > Do you have some bandwidth to address this? Otherwise, I'll do some. > > > > Thanks, > > > > On Fri, Aug 18, 2023 at 6:15 AM Guenter Roeck <li...@roeck-us.net> wrote: > > > > > > On Thu, Aug 17, 2023 at 08:53:19AM -0700, Eric Biggers wrote: > > > > On Thu, Aug 17, 2023 at 10:26:12PM +0800, Chao Yu wrote: > > > > > > > > > > > > > > > > lock(new_inode#2->i_sem) > > > > > > > > > > > > > > > > lock(dir->i_xattr_sem) > > > > > > > > lock(new_inode#1->i_sem) > > > > > > > > > > > > > > > > This looks fine to me. > > > > > > > > > > > > > > > > > > > > > > Based on your feedback, am I correct assuming that you don't plan > > > > > > > to fix this ? > > > > > > > > > > > > I'm quite open to something that I may miss. Chao, what do you > > > > > > think? > > > > > > > > > > Jaegeuk, I agree with you, it looks like a false alarm. > > > > > > > > > > > > > False positive lockdep reports still need to be eliminated, for example > > > > by > > > > fixing the lockdep annotations. Otherwise it's impossible to > > > > distinguish them > > > > from true positives. > > > > > > > > > > Exactly, and that is why I don't test features with known lockdep > > > annotation > > > issues. I'll drop f2fs from my list of features to test for the time > > > being. > > > > > > Guenter _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
