In article <ygjwjlapo2rtv...@bec.de>, Joerg Sonnenberger <jo...@bec.de> wrote: >On Sat, Apr 03, 2021 at 08:14:34PM -0000, Christos Zoulas wrote: >> In article <ygiv7tup4jyz9...@bec.de>, Joerg Sonnenberger ><jo...@bec.de> wrote: >> >On Sat, Apr 03, 2021 at 01:15:15AM -0400, Christos Zoulas wrote: >> >> Yes, I think that the appropriate change is to make those assertions >> >> so if there is a broken filesystem/syscall there is a more obvious >> >> error (rather than infinite loop in read or core-dump in iconv), but let's >> >> see what joerg thinks about all that. >> > >> >The infinite loops are perfectly reasonable behavior for broken kernel >> >input and found in other tools using the interface. IMO the kernel >> >should always do a sanity cap for puffs/fuse here. >> >> Yes, but defensive programming is good. >> >> >The iconv coredump is a buffer overflow, but nothing libarchive can do >> >about. The memory allocated for the dirent is based on the namemax of >> >the filesystem and we kind of have to trust the filesystem to do what it >> >promised. The system call doesn't have a size argument... >> >> Right, but it can check if the size makes sense before using it. > >The next filesystem will put one in the field and we are back...
There is a difference between sub-optimal performance and core-dumping or infinite-looping. christos