But until then, the lock_kernel was one level up in notify_change().
> This does not affect unlink(). It affects ftruncate() and open(O_TRUNC).
And the patch you give affects chown, chgrp, chmod, utime also:
removing a synchronization point if nothing more. Could that matter?
> Given that the drop_inode() path does not take the BKL, I would
> suggest that it is safe to assume that the various filesystem's
> truncate code is safe without this additional VFS-level lock_kernel(),
> and that it can be simply removed.
Isn't doing it when the references have gone rather easier/safer
than when they remain? I'm not sure your argument holds.
> Sound sane?
Of course I want you to be right! But I don't see that you've made
a strong enough case yet. Please show I'm being stupid, someone.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/