Re: [PATCH v4 0/5] Add a new fchmodat2() syscall

2023-07-26 Thread Rich Felker
On Tue, Jul 11, 2023 at 06:16:02PM +0200, Alexey Gladkov wrote: > In glibc, the fchmodat(3) function has a flags argument according to the > POSIX specification [1], but kernel syscalls has no such argument. > Therefore, libc implementations do workarounds using /proc. However, > this requires

Re: Add fchmodat2() - or add a more general syscall?

2023-07-25 Thread Rich Felker
On Tue, Jul 25, 2023 at 07:39:51PM +0100, David Howells wrote: > Florian Weimer wrote: > > > > Rather than adding a fchmodat2() syscall, should we add a > > > "set_file_attrs()" syscall that takes a mask and allows you to set a bunch > > > of stuff all in one go? Basically, an interface to

Re: [PATCH 09/12] sh: Use of_get_cpu_hwid()

2021-10-27 Thread Rich Felker
On Wed, Oct 06, 2021 at 11:43:29AM -0500, Rob Herring wrote: > Replace open coded parsing of CPU nodes' 'reg' property with > of_get_cpu_hwid(). > > Cc: Yoshinori Sato > Cc: Rich Felker > Cc: linux...@vger.kernel.org > Signed-off-by: Rob Herring > --- > arch

Re: [musl] Re: Linux powerpc new system call instruction and ABI

2021-05-19 Thread Rich Felker
On Wed, May 19, 2021 at 06:09:25PM +, Joakim Tjernlund wrote: > On Wed, 2021-05-19 at 10:22 -0500, Segher Boessenkool wrote: > > On Wed, May 19, 2021 at 03:06:49PM +, Joakim Tjernlund wrote: > > > On Wed, 2021-05-19 at 09:38 -0500, Segher Boessenkool wrote: > > > > On Wed, May 19, 2021 at

Re: [musl] Re: Linux powerpc new system call instruction and ABI

2021-05-19 Thread Rich Felker
On Wed, May 19, 2021 at 10:22:05AM -0500, Segher Boessenkool wrote: > On Wed, May 19, 2021 at 03:06:49PM +, Joakim Tjernlund wrote: > > On Wed, 2021-05-19 at 09:38 -0500, Segher Boessenkool wrote: > > > On Wed, May 19, 2021 at 06:42:40PM +1000, Nicholas Piggin wrote: > > > > Excerpts from

Re: [musl] Re: [PATCH v2] powerpc/64/signal: balance return predictor stack in signal trampoline

2021-01-22 Thread Rich Felker
On Fri, Jan 22, 2021 at 03:19:22PM -0300, Raoni Fassina Firmino wrote: > On Fri, Jan 22, 2021 at 09:44:05AM -0500, Rich Felker wrote: > > Maybe I'm missing something but I don't see how this would break musl; > > we just inspect the PC in the mcontext, which I don't

Re: [musl] Re: [PATCH v2] powerpc/64/signal: balance return predictor stack in signal trampoline

2021-01-22 Thread Rich Felker
On Fri, Jan 22, 2021 at 12:27:14PM +0100, Florian Weimer wrote: > * Nicholas Piggin: > > > diff --git a/arch/powerpc/kernel/vdso64/sigtramp.S > > b/arch/powerpc/kernel/vdso64/sigtramp.S > > index a8cc0409d7d2..bbf68cd01088 100644 > > --- a/arch/powerpc/kernel/vdso64/sigtramp.S > > +++

Re: [PATCH] Adds a new ioctl32 syscall for backwards compatibility layers

2021-01-16 Thread Rich Felker
On Fri, Jan 15, 2021 at 11:17:09PM +0100, Arnd Bergmann wrote: > On Fri, Jan 15, 2021 at 9:01 PM David Laight wrote: > > > > From: sonicadvan...@gmail.com > > > Sent: 15 January 2021 07:03 > > > Problem presented: > > > A backwards compatibility layer that allows running x86-64 and x86 > > >

Re: [PATCH v2] All arch: remove system call sys_sysctl

2020-06-11 Thread Rich Felker
On Thu, Jun 11, 2020 at 12:01:11PM -0500, Eric W. Biederman wrote: > Rich Felker writes: > > > On Thu, Jun 11, 2020 at 06:43:00AM -0500, Eric W. Biederman wrote: > >> Xiaoming Ni writes: > >> > >> > Since the commit 61a47c1ad3a4dc (&quo

Re: [PATCH v2] All arch: remove system call sys_sysctl

2020-06-11 Thread Rich Felker
On Thu, Jun 11, 2020 at 06:43:00AM -0500, Eric W. Biederman wrote: > Xiaoming Ni writes: > > > Since the commit 61a47c1ad3a4dc ("sysctl: Remove the sysctl system call"), > > sys_sysctl is actually unavailable: any input can only return an error. > > > > We have been warning about people using

Re: [musl] ppc64le and 32-bit LE userland compatibility

2020-06-09 Thread Rich Felker
On Tue, Jun 09, 2020 at 10:29:57AM +, Will Springer wrote: > On Saturday, May 30, 2020 3:56:47 PM PDT you wrote: > > On Friday, May 29, 2020 12:24:27 PM PDT Rich Felker wrote: > > > The argument passing for pread/pwrite is historically a mess and > > > diff

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-05 Thread Rich Felker
On Fri, Jun 05, 2020 at 12:27:02PM -0500, Segher Boessenkool wrote: > On Fri, Jun 05, 2020 at 04:18:18AM +0200, Daniel Kolesa wrote: > > On Fri, Jun 5, 2020, at 01:35, Segher Boessenkool wrote: > > > > The thing is, I've yet to see in which way the ELFv2 ABI *actually* > > > > requires VSX - I

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-04 Thread Rich Felker
On Thu, Jun 04, 2020 at 03:00:51PM -0400, David Edelsohn wrote: > On Thu, Jun 4, 2020 at 1:46 PM Rich Felker wrote: > > > > On Thu, Jun 04, 2020 at 12:33:12PM -0500, Segher Boessenkool wrote: > > > On Thu, Jun 04, 2020 at 01:18:44PM -0400, Rich Felker wrote: > > >

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-04 Thread Rich Felker
On Thu, Jun 04, 2020 at 12:33:12PM -0500, Segher Boessenkool wrote: > On Thu, Jun 04, 2020 at 01:18:44PM -0400, Rich Felker wrote: > > On Thu, Jun 04, 2020 at 12:12:32PM -0500, Segher Boessenkool wrote: > > > On Tue, Jun 02, 2020 at 05:13:25PM +0200, Daniel Kolesa wrote: >

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-04 Thread Rich Felker
On Thu, Jun 04, 2020 at 12:12:32PM -0500, Segher Boessenkool wrote: > On Tue, Jun 02, 2020 at 05:13:25PM +0200, Daniel Kolesa wrote: > > well, ppc64le already cannot be run on those, as far as I know (I > > don't think it's possible to build ppc64le userland without VSX in > > any configuration) >

Re: [musl] Re: ppc64le and 32-bit LE userland compatibility

2020-06-01 Thread Rich Felker
On Mon, Jun 01, 2020 at 09:28:25PM +, Joseph Myers wrote: > On Fri, 29 May 2020, Will Springer via Binutils wrote: > > > Hey all, a couple of us over in #talos-workstation on freenode have been > > working on an effort to bring up a Linux PowerPC userland that runs in > > 32-bit > >

Re: [musl] ppc64le and 32-bit LE userland compatibility

2020-05-29 Thread Rich Felker
On Fri, May 29, 2020 at 07:03:48PM +, Will Springer wrote: > The next problem concerns the ABI more directly. The failure mode was `file` > surfacing EINVAL from pread64 when invoked on an ELF; pread64 was passed a > garbage value for `pos`, which didn't appear to be caused by anything in >

Re: New powerpc vdso calling convention

2020-04-25 Thread Rich Felker
On Sun, Apr 26, 2020 at 08:58:19AM +1000, Nicholas Piggin wrote: > Excerpts from Christophe Leroy's message of April 25, 2020 10:20 pm: > > > > > > Le 25/04/2020 à 12:56, Nicholas Piggin a écrit : > >> Excerpts from Christophe Leroy's message of April 25, 2020 5:47 pm: > >>> > >>> > >>> Le

Re: [musl] Re: New powerpc vdso calling convention

2020-04-25 Thread Rich Felker
On Sat, Apr 25, 2020 at 08:56:54PM +1000, Nicholas Piggin wrote: > >> The ELF v2 ABI convention would suit it well, because the caller already > >> requires the function address for ctr, so having it in r12 will > >> eliminate the need for address calculation, which suits the vdso data > >> page

Re: [musl] New powerpc vdso calling convention

2020-04-24 Thread Rich Felker
On Sat, Apr 25, 2020 at 03:22:27PM +1000, Nicholas Piggin wrote: > As noted in the 'scv' thread, powerpc's vdso calling convention does not > match the C ELF ABI calling convention (or the proposed scv convention). > I think we could implement a new ABI by basically duplicating function > entry

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-24 Thread Rich Felker
On Sat, Apr 25, 2020 at 01:40:24PM +1000, Nicholas Piggin wrote: > Excerpts from Rich Felker's message of April 24, 2020 3:42 am: > > On Thu, Apr 23, 2020 at 02:15:58PM -0300, Adhemerval Zanella wrote: > >> > >> > >> On 23/04/2020 13:43, Rich Felker wrote:

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-23 Thread Rich Felker
On Thu, Apr 23, 2020 at 02:15:58PM -0300, Adhemerval Zanella wrote: > > > On 23/04/2020 13:43, Rich Felker wrote: > > On Thu, Apr 23, 2020 at 01:35:01PM -0300, Adhemerval Zanella wrote: > >> > >> > >> On 23/04/2020 13:18, Rich Felker wrote: >

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-23 Thread Rich Felker
On Thu, Apr 23, 2020 at 01:35:01PM -0300, Adhemerval Zanella wrote: > > > On 23/04/2020 13:18, Rich Felker wrote: > > On Thu, Apr 23, 2020 at 09:13:57AM -0300, Adhemerval Zanella wrote: > >> > >> > >> On 22/04/2020 23:36, Rich Felker wrote: >

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-23 Thread Rich Felker
On Thu, Apr 23, 2020 at 09:13:57AM -0300, Adhemerval Zanella wrote: > > > On 22/04/2020 23:36, Rich Felker wrote: > > On Wed, Apr 22, 2020 at 04:18:36PM +1000, Nicholas Piggin wrote: > >> Yeah I had a bit of a play around with musl (which is very nice code I > >>

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-22 Thread Rich Felker
On Wed, Apr 22, 2020 at 04:18:36PM +1000, Nicholas Piggin wrote: > Yeah I had a bit of a play around with musl (which is very nice code I > must say). The powerpc64 syscall asm is missing ctr clobber by the way. > Fortunately adding it doesn't change code generation for me, but it > should be

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-21 Thread Rich Felker
On Tue, Apr 21, 2020 at 12:28:25PM +, David Laight wrote: > From: Nicholas Piggin > > Sent: 20 April 2020 02:10 > ... > > >> Yes, but does it really matter to optimize this specific usage case > > >> for size? glibc, for instance, tries to leverage the syscall mechanism > > >> by adding some

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-20 Thread Rich Felker
On Mon, Apr 20, 2020 at 02:31:58PM +1000, Nicholas Piggin wrote: > Excerpts from Rich Felker's message of April 20, 2020 2:09 pm: > > On Mon, Apr 20, 2020 at 12:32:21PM +1000, Nicholas Piggin wrote: > >> Excerpts from Rich Felker's message of April 20, 2020 11:34 am: > >> > On Mon, Apr 20, 2020 at

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-19 Thread Rich Felker
On Mon, Apr 20, 2020 at 12:32:21PM +1000, Nicholas Piggin wrote: > Excerpts from Rich Felker's message of April 20, 2020 11:34 am: > > On Mon, Apr 20, 2020 at 11:10:25AM +1000, Nicholas Piggin wrote: > >> Excerpts from Rich Felker's message of April 17, 2020 4:31 am: > >> > Note that because lr is

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-19 Thread Rich Felker
On Mon, Apr 20, 2020 at 11:10:25AM +1000, Nicholas Piggin wrote: > Excerpts from Rich Felker's message of April 17, 2020 4:31 am: > > Note that because lr is clobbered we need at least once normally > > call-clobbered register that's not syscall clobbered to save lr in. > > Otherwise stack frame

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-19 Thread Rich Felker
On Mon, Apr 20, 2020 at 10:27:58AM +1000, Nicholas Piggin wrote: > Excerpts from Szabolcs Nagy's message of April 16, 2020 7:58 pm: > > * Nicholas Piggin via Libc-alpha [2020-04-16 > > 10:16:54 +1000]: > >> Well it would have to test HWCAP and patch in or branch to two > >> completely different

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-16 Thread Rich Felker
On Thu, Apr 16, 2020 at 06:02:35PM -0500, Segher Boessenkool wrote: > On Thu, Apr 16, 2020 at 08:12:19PM +0200, Florian Weimer wrote: > > > I think my choice would be just making the inline syscall be a single > > > call insn to an asm source file that out-of-lines the loading of TOC > > > pointer

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-16 Thread Rich Felker
On Thu, Apr 16, 2020 at 02:31:51PM -0400, Rich Felker wrote: > > While on musl: > > > > : > >0: 48 83 ec 08 sub$0x8,%rsp > >4: 48 63 ffmovslq %edi,%rdi > >7: 48 63 f6

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-16 Thread Rich Felker
On Thu, Apr 16, 2020 at 03:18:42PM -0300, Adhemerval Zanella wrote: > > > On 16/04/2020 14:59, Rich Felker wrote: > > On Thu, Apr 16, 2020 at 02:50:18PM -0300, Adhemerval Zanella wrote: > >> > >> > >> On 16/04/2020 12:37, Rich Felker wrote: >

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-16 Thread Rich Felker
On Thu, Apr 16, 2020 at 02:50:18PM -0300, Adhemerval Zanella wrote: > > > On 16/04/2020 12:37, Rich Felker wrote: > > On Thu, Apr 16, 2020 at 11:16:04AM -0300, Adhemerval Zanella wrote: > >>> My preference would be that it work just like the i386 AT_SYSINFO > >&g

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-16 Thread Rich Felker
On Thu, Apr 16, 2020 at 06:42:32PM +0200, Florian Weimer wrote: > * Rich Felker: > > > On Thu, Apr 16, 2020 at 06:48:44AM +0200, Florian Weimer wrote: > >> * Rich Felker: > >> > >> > My preference would be that it work just like the i386 AT_SYSIN

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-16 Thread Rich Felker
On Thu, Apr 16, 2020 at 11:21:56AM -0400, Jeffrey Walton wrote: > On Wed, Apr 15, 2020 at 8:17 PM Nicholas Piggin wrote: > > > > Excerpts from Rich Felker's message of April 16, 2020 8:55 am: > > > On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote: > > >> I would like to enable

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-16 Thread Rich Felker
On Thu, Apr 16, 2020 at 11:16:04AM -0300, Adhemerval Zanella wrote: > > My preference would be that it work just like the i386 AT_SYSINFO > > where you just replace "int $128" with "call *%%gs:16" and the kernel > > provides a stub in the vdso that performs either scv or the old > > mechanism with

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-16 Thread Rich Felker
On Thu, Apr 16, 2020 at 06:48:44AM +0200, Florian Weimer wrote: > * Rich Felker: > > > My preference would be that it work just like the i386 AT_SYSINFO > > where you just replace "int $128" with "call *%%gs:16" and the kernel > > provides a stub in

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-15 Thread Rich Felker
On Thu, Apr 16, 2020 at 12:53:31PM +1000, Nicholas Piggin wrote: > > Not to mention the dcache line to access > > __hwcap or whatever, and the icache lines to setup access TOC-relative > > access to it. (Of course you could put a copy of its value in TLS at a > > fixed offset, which would somewhat

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-15 Thread Rich Felker
On Thu, Apr 16, 2020 at 12:24:16PM +1000, Nicholas Piggin wrote: > >> > Likewise, it's not useful to have different error return mechanisms > >> > because the caller just has to branch to support both (or the > >> > kernel-provided stub just has to emulate one for it; that could work > >> > if you

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-15 Thread Rich Felker
On Thu, Apr 16, 2020 at 10:16:54AM +1000, Nicholas Piggin wrote: > Excerpts from Rich Felker's message of April 16, 2020 8:55 am: > > On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote: > >> I would like to enable Linux support for the powerpc 'scv' instruction, > >> as a faster

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

2020-04-15 Thread Rich Felker
On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote: > I would like to enable Linux support for the powerpc 'scv' instruction, > as a faster system call instruction. > > This requires two things to be defined: Firstly a way to advertise to > userspace that kernel supports scv, and a

Re: [PATCH v2 2/4] Add fchmodat4(), a new syscall

2019-07-16 Thread Rich Felker
On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote: > man 3p says that fchmodat() takes a flags argument, but the Linux > syscall does not. There doesn't appear to be a good userspace > workaround for this issue but the implementation in the kernel is pretty > straight-forward. The

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-31 Thread Rich Felker
On Fri, Mar 30, 2018 at 09:55:08AM +0200, Pavel Machek wrote: > Hi! > > > Current implementation doesn't randomize address returned by mmap. > > All the entropy ends with choosing mmap_base_addr at the process > > creation. After that mmap build very predictable layout of address > > space. It

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-27 Thread Rich Felker
On Tue, Mar 27, 2018 at 04:49:04PM -0700, Matthew Wilcox wrote: > On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote: > > I agree: pushing this off to libc leaves a lot of things unprotected. > > I think this should live in the kernel. The question I have is about > > making it

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-27 Thread Rich Felker
On Tue, Mar 27, 2018 at 06:16:35PM -0400, Theodore Y. Ts'o wrote: > On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote: > > > /dev/[u]random is not sufficient? > > > > Using /dev/[u]random makes 3 syscalls - open, read, close. This is a > > performance > > issue. > > You may want to

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-23 Thread Rich Felker
On Fri, Mar 23, 2018 at 12:06:18PM -0700, Matthew Wilcox wrote: > On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote: > > On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote: > > > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: > > &g

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-23 Thread Rich Felker
On Fri, Mar 23, 2018 at 12:29:52PM -0700, Matthew Wilcox wrote: > On Fri, Mar 23, 2018 at 03:16:21PM -0400, Rich Felker wrote: > > > Huh, I thought libc was aware of this. Also, I'd expect a libc-based > > > implementation to restrict itself to, eg, only loading libraries in

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

2018-03-23 Thread Rich Felker
On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote: > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: > > Current implementation doesn't randomize address returned by mmap. > > All the entropy ends with choosing mmap_base_addr at the process > > creation. After that mmap

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-15 Thread Rich Felker
On Wed, Mar 15, 2017 at 12:44:47PM -0700, Till Smejkal wrote: > On Wed, 15 Mar 2017, Andy Lutomirski wrote: > > > One advantage of VAS segments is that they can be globally queried by > > > user programs > > > which means that VAS segments can be shared by applications that not > > > necessarily

Re: [PATCH 1/3] futex: remove duplicated code

2017-03-05 Thread Rich Felker
On Fri, Mar 03, 2017 at 01:27:10PM +0100, Jiri Slaby wrote: > There is code duplicated over all architecture's headers for > futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr, > and comparison of the result. > > Remove this duplication and leave up to the arches only the

Re: Build regressions/improvements in v4.7-rc1

2016-06-01 Thread Rich Felker
On Mon, May 30, 2016 at 09:34:07AM +0200, Geert Uytterhoeven wrote: > > + /home/kisskb/slave/src/arch/sh/kernel/setup.c: error: implicit > > declaration of function 'early_init_dt_scan' > > [-Werror=implicit-function-declaration]: => 256:2 > > sh-randconfig Nice find. I think I'm

Re: [PATCH v4 04/16] rtc: sh: provide rtc_class_ops directly

2016-06-01 Thread Rich Felker
me functions. > > This changes the sh rtc-generic device to provide its > rtc_class_ops directly, skipping one of the abstraction > levels. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> I haven't tested any of this, but based on our discussion of the previous version, I'm satisfied

Re: [PATCH v3 04/16] rtc: sh: provide rtc_class_ops directly

2016-04-27 Thread Rich Felker
On Thu, Apr 28, 2016 at 12:34:18AM +0200, Arnd Bergmann wrote: > The rtc-generic driver provides an architecture specific > wrapper on top of the generic rtc_class_ops abstraction, > and on sh, that goes through another indirection using > the rtc_sh_get_time/rtc_sh_set_time functions. > > This