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.

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.

I think your original approach of always building sys_llseek on
powerpc64 is the safe choice here.

     Arnd

Reply via email to