On Thu, Aug 29, 2019 at 4:19 PM Michal Suchánek [off-list ref] wrote:

On Thu, 29 Aug 2019 14:57:39 +0200 Arnd Bergmann [off-list ref] wrote:

quoted

On Thu, Aug 29, 2019 at 2:37 PM Michal Suchánek [off-list ref] wrote:

quoted

On Thu, 29 Aug 2019 14:19:46 +0200 Arnd Bergmann [off-list ref] wrote:

quoted

On Thu, Aug 29, 2019 at 12:23 PM Michal Suchanek [off-list ref] 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