On Sun, Feb 23, 2025 at 08:12:21PM +0100, Miklos Szeredi wrote: > On Sun, 23 Feb 2025 at 01:28, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, Feb 20, 2025 at 11:02:58AM +0100, Miklos Szeredi wrote: > > > > > The solution is to just remove this truncation. This can cause a > > > regression in a filesystem that relies on supplying a symlink larger than > > > the file size, but this is unlikely. If that happens we'd need to make > > > this behavior conditional. > > > > Note, BTW, that page *contents* must not change at all, so truncation is > > only safe if we have ->i_size guaranteed to be stable. > > > > Core pathwalk really counts upon the string remaining immutable, and that > > does include the string returned by ->get_link(). > > Page contents will not change after initial readlink, but page could > get invalidated and a fresh page filled with new value for the same > object. *nod* My point is that truncation of something that might be traversed by another pathwalk is a hard bug - we only get away with doing that in page_get_link() because it's idempotent. If ->i_size can change, we are not allowed to do that.
