On Thu, 29 Aug 2019 16:32:50 +0200 Arnd Bergmann <a...@arndb.de> wrote:
> On Thu, Aug 29, 2019 at 4:19 PM Michal Suchánek <msucha...@suse.de> wrote: > > On Thu, 29 Aug 2019 14:57:39 +0200 Arnd Bergmann <a...@arndb.de> wrote: > > > On Thu, Aug 29, 2019 at 2:37 PM Michal Suchánek <msucha...@suse.de> > > > wrote: > > > > On Thu, 29 Aug 2019 14:19:46 +0200 Arnd Bergmann <a...@arndb.de> wrote: > > > > > > > > > On Thu, Aug 29, 2019 at 12:23 PM Michal Suchanek <msucha...@suse.de> > > > > > wrote: > > > > > In particular, I don't see why you single out llseek here, but leave > > > > > other > > > > > syscalls that are not needed on 64-bit machines such as pread64(). > > > > > > > > Because llseek is not built in fs/ when building 64bit only causing a > > > > link error. > > > > > > > > I initially posted patch to build it always but it was pointed out it > > > > is not needed, and the interface does not make sense on 64bit, and > > > > that platforms that don't have it on 64bit now don't want that useless > > > > code. > > > > > > Ok, please put that into the changeset description then. > > > > > > I looked at uses of __NR__llseek in debian code search and > > > found this one: > > > > > > https://codesearch.debian.net/show?file=umview_0.8.2-1.2%2Fxmview%2Fum_mmap.c&line=328 > > > > > > It looks like this application will try to use llseek instead of lseek > > > when built against kernel headers that define __NR_llseek. > > > > > > > The available documentation says this syscall is for 32bit only so > > using it on 64bit is undefined. The interface is not well-defined in > > that case either. > > That's generally not how it works. If there is an existing application > that relies on the behavior of the system call interface, we should not > change it in a way that breaks the application, regardless of what the > documentation says. Presumably nobody cares about umview on > powerpc64, but there might be other applications doing the same > thing. Actually the umview headers go out of their way to define the llseek syscall as invalid on x86_64 so that the non-llseek path is taken. mview-os/xmview/defs_x86_64_um.h:#define __NR__llseek __NR_doesnotexist It is probably an oversight that this is not done on non-x86. I am not even sure this builds on non-x86 out of the box. > It looks like sparc64 and parisc64 do the same thing as powerpc64, > and provide llseek() calls that may or may not be used by > applications. And if they are supposed to build with !compat it should be removed there as well. > > I think your original approach of always building sys_llseek on > powerpc64 is the safe choice here. That's safe but adds junk to the kernel as pointed out in the reply to that patch. Thanks Michal
