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

2021-01-16 Thread David Laight
... > He's already doing the system call emulation for all the system > calls other than ioctl in user space though. In my experience, > there are actually fairly few ioctl commands that are different > between architectures -- most of them have no misaligned > or architecture-defined struct

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

2021-01-16 Thread David Laight
From: sonicadvan...@gmail.com > Sent: 15 January 2021 07:03 > Problem presented: > A backwards compatibility layer that allows running x86-64 and x86 > processes inside of an AArch64 process. > - CPU is emulated > - Syscall interface is mostly passthrough > - Some syscalls require patching

RE: [PATCH 05/11] iov_iter: merge the compat case into rw_copy_check_uvector

2021-01-08 Thread David Laight
From: Christoph Hellwig > Sent: 21 September 2020 15:34 > > Stop duplicating the iovec verify code, and instead add add a > __import_iovec helper that does the whole verify and import, but takes > a bool compat to decided on the native or compat layout. This also > ends up massively simplifying

RE: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2021-01-01 Thread David Laight
From: Andy Lutomirski > Sent: 29 December 2020 00:36 ... > I mean that the mapping from the name "sync_core" to its semantics is > x86 only. The string "sync_core" appears in the kernel only in > arch/x86, membarrier code, membarrier docs, and a single SGI driver > that is x86-only. Sure, the

RE: [PATCH] powerpc:Don't print raw EIP/LR hex values in dump_stack() and show_regs()

2020-12-21 Thread David Laight
From: Segher Boessenkool > Sent: 21 December 2020 16:32 > > On Mon, Dec 21, 2020 at 04:17:21PM +0100, Christophe Leroy wrote: > > Le 21/12/2020 à 04:27, Xiaoming Ni a écrit : > > >Since the commit 2b0e86cc5de6 ("powerpc/fsl_booke/32: implement KASLR > > >infrastructure"), the powerpc system is

RE: [PATCH] net: ethernet: fs-enet: remove casting dma_alloc_coherent

2020-12-11 Thread David Laight
From: Christophe Leroy > Sent: 11 December 2020 15:22 > > Le 11/12/2020 à 09:52, Xu Wang a écrit : > > Remove casting the values returned by dma_alloc_coherent. > > Can you explain more in the commit log ? > > As far as I can see, dma_alloc_coherent() doesn't return __iomem, and > ring_base

RE: [PATCH] net: ethernet: fs-enet: remove casting dma_alloc_coherent

2020-12-11 Thread David Laight
From: Christophe Leroy > Sent: 11 December 2020 16:43 > > Le 11/12/2020 à 17:07, David Laight a écrit : > > From: Christophe Leroy > >> Sent: 11 December 2020 15:22 > >> > >> Le 11/12/2020 à 09:52, Xu Wang a écrit : > >>> Remove casting the va

RE: [PATCH v6 4/5] PCI: vmd: Update type of the __iomem pointers

2020-11-30 Thread David Laight
From: Krzysztof Wilczynski > Sent: 29 November 2020 23:08 > > Use "void __iomem" instead "char __iomem" pointer type when working with > the accessor functions (with names like readb() or writel(), etc.) to > better match a given accessor function signature where commonly the > address pointing

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-11-02 Thread David Laight
From: 'Greg KH' > Sent: 02 November 2020 13:52 > > On Mon, Nov 02, 2020 at 09:06:38AM +0000, David Laight wrote: > > From: 'Greg KH' > > > Sent: 23 October 2020 15:47 > > > > > > On Fri, Oct 23, 2020 at 02:39:24PM +, David Laight wrote: > >

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-11-02 Thread David Laight
From: 'Greg KH' > Sent: 23 October 2020 15:47 > > On Fri, Oct 23, 2020 at 02:39:24PM +0000, David Laight wrote: > > From: David Hildenbrand > > > Sent: 23 October 2020 15:33 > > ... > > > I just checked against upstream code generated by clang 10 and it >

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-24 Thread David Laight
From: Segher Boessenkool > Sent: 24 October 2020 18:29 > > On Fri, Oct 23, 2020 at 09:28:59PM +0000, David Laight wrote: > > From: Segher Boessenkool > > > Sent: 23 October 2020 19:27 > > > On Fri, Oct 23, 2020 at 06:58:57PM +0100, Al Viro wrote: > > >

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-23 Thread David Laight
From: Segher Boessenkool > Sent: 23 October 2020 19:27 > > On Fri, Oct 23, 2020 at 06:58:57PM +0100, Al Viro wrote: > > On Fri, Oct 23, 2020 at 03:09:30PM +0200, David Hildenbrand wrote: > > > > > Now, I am not a compiler expert, but as I already cited, at least on > > > x86-64 clang expects that

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-23 Thread David Laight
From: David Hildenbrand > Sent: 23 October 2020 15:33 ... > I just checked against upstream code generated by clang 10 and it > properly discards the upper 32bit via a mov w23 w2. > > So at least clang 10 indeed properly assumes we could have garbage and > masks it off. > > Maybe the issue is

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-23 Thread David Laight
From: Arnd Bergmann > Sent: 23 October 2020 14:23 > > On Fri, Oct 23, 2020 at 2:46 PM David Laight wrote: > > > > From: Greg KH > > > Sent: 22 October 2020 14:51 > > > > I've rammed the code into godbolt. > > > > https://godbolt.org/z

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-23 Thread David Laight
From: Greg KH > Sent: 22 October 2020 14:51 I've rammed the code into godbolt. https://godbolt.org/z/9v5PPW Definitely a clang bug. Search for [wx]24 in the clang output. nr_segs comes in as w2 and the initial bound checks are done on w2. w24 is loaded from w2 - I don't believe this changes

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-22 Thread David Laight
From: Al Viro > Sent: 22 October 2020 20:25 > > On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote: > > > Passing an `unsigned long` as an `unsigned int` does no such > > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail > > calls, no masking instructions). > > So

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-22 Thread David Laight
From: Nick Desaulniers > Sent: 22 October 2020 20:05 > ... > Passing an `unsigned long` as an `unsigned int` does no such > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail > calls, no masking instructions). Right but is the called function going to use 32bit ops and/or mask

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-22 Thread David Laight
From: Matthew Wilcox > Sent: 22 October 2020 17:41 > > On Thu, Oct 22, 2020 at 04:35:17PM +0000, David Laight wrote: > > Wait... > > readv(2) defines: > > ssize_t readv(int fd, const struct iovec *iov, int iovcnt); > > It doesn't really matter what the

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-22 Thread David Laight
From: Christoph Hellwig > Sent: 22 October 2020 14:24 > > On Thu, Oct 22, 2020 at 11:36:40AM +0200, David Hildenbrand wrote: > > My thinking: if the compiler that calls import_iovec() has garbage in > > the upper 32 bit > > > > a) gcc will zero it out and not rely on it being zero. > > b) clang

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-22 Thread David Laight
From: Greg KH > Sent: 22 October 2020 15:40 > > On Thu, Oct 22, 2020 at 04:28:20PM +0200, Arnd Bergmann wrote: ... > > Can you attach the iov_iter.s files from the broken build, plus the > > one with 'noinline' for comparison? Maybe something can be seen > > in there. > > I don't know how to

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-22 Thread David Laight
From: David Hildenbrand > Sent: 22 October 2020 10:25 ... > ... especially because I recall that clang and gcc behave slightly > differently: > > https://github.com/hjl-tools/x86-psABI/issues/2 > > "Function args are different: narrow types are sign or zero extended to > 32 bits, depending on

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-22 Thread David Laight
From: David Hildenbrand > Sent: 22 October 2020 10:19 > > On 22.10.20 11:01, Greg KH wrote: > > On Thu, Oct 22, 2020 at 10:48:59AM +0200, David Hildenbrand wrote: > >> On 22.10.20 10:40, David Laight wrote: > >>> From: David Hildenbrand > >>>> Se

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-22 Thread David Laight
From: Greg KH > Sent: 22 October 2020 10:02 ... > I'm running some more tests, trying to narrow things down as just adding > a "noinline" to the function that got moved here doesn't work on Linus's > tree at the moment because the function was split into multiple > functions. I was going to look

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-22 Thread David Laight
From: David Hildenbrand > Sent: 22 October 2020 09:49 ... > >>> But, this looks now to be a compiler bug. I'm using the latest version > >>> of clang and if I put "noinline" at the front of the function, > >>> everything works. > >> > >> Well, the compiler can do more invasive optimizations when

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-22 Thread David Laight
:39AM +0200, Christoph Hellwig wrote: > >>>> From: David Laight > >>>> > >>>> This lets the compiler inline it into import_iovec() generating > >>>> much better code. > >>>> > &

RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-21 Thread David Laight
From: Greg KH > Sent: 21 October 2020 17:13 > > On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote: > > From: David Laight > > > > This lets the compiler inline it into import_iovec() generating > > much better code. > > > >

RE: [PATCH 5/9] fs: remove various compat readv/writev helpers

2020-09-23 Thread David Laight
From: Arnd Bergmann > Sent: 23 September 2020 19:46 ... > Regardless of that, another advantage of having the SYSCALL_DECLAREx() > would be the ability to include that header file from elsewhere with a > different > macro definition to create a machine-readable version of the interface when >

RE: [PATCH 3/9] iov_iter: refactor rw_copy_check_uvector and import_iovec

2020-09-23 Thread David Laight
From: Al Viro > Sent: 23 September 2020 15:17 > > On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote: > > > +struct iovec *iovec_from_user(const struct iovec __user *uvec, > > + unsigned long nr_segs, unsigned long fast_segs, > > Hmm... For fast_segs unsigned long had

RE: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()

2020-09-21 Thread David Laight
From: Al Viro > Sent: 21 September 2020 16:30 > > On Mon, Sep 21, 2020 at 03:21:35PM +0000, David Laight wrote: > > > You really don't want to be looping through the array twice. > > Profiles, please. I did some profiling of send() v sendmsg() much earlier in th

RE: [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector

2020-09-21 Thread David Laight
From: Al Viro > Sent: 21 September 2020 16:11 > On Mon, Sep 21, 2020 at 03:05:32PM +, David Laight wrote: > > > I've actually no idea: > > 1) Why there is an access_ok() check here. > >It will be repeated by the user copy functions. > > Early sanity c

RE: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()

2020-09-21 Thread David Laight
From: Al Viro > Sent: 21 September 2020 16:02 > > On Mon, Sep 21, 2020 at 04:34:25PM +0200, Christoph Hellwig wrote: > > From: David Laight > > > > This is the only direct call of rw_copy_check_uvector(). Removing it > > will allow rw_copy_check_uvector(

RE: [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector

2020-09-21 Thread David Laight
From: Christoph Hellwig > Sent: 21 September 2020 15:34 > > Explicitly check for the magic value insted of implicitly relying on > its numeric representation. Also drop the rather pointless unlikely > annotation. > > Signed-off-by: Christoph Hellwig > --- > lib/iov_iter.c | 5 ++--- > 1 file

RE: let import_iovec deal with compat_iovecs as well

2020-09-21 Thread David Laight
> On Sat, Sep 19, 2020 at 02:24:10PM +0000, David Laight wrote: > > I thought about that change while writing my import_iovec() => > > iovec_import() > > patch - and thought that the io_uring code would (as usual) cause grief. > > > > Christoph - did you see

RE: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-20 Thread David Laight
From: Arnd Bergmann > Sent: 20 September 2020 21:49 > > On Sun, Sep 20, 2020 at 9:28 PM Andy Lutomirski wrote: > > On Sun, Sep 20, 2020 at 12:23 PM Matthew Wilcox wrote: > > > > > > On Sun, Sep 20, 2020 at 08:10:31PM +0100, Al Viro wrote: > > > > IMO it's much saner to mark those and refuse to

RE: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-19 Thread David Laight
From: Al Viro > Sent: 18 September 2020 14:58 > > On Fri, Sep 18, 2020 at 03:44:06PM +0200, Christoph Hellwig wrote: > > On Fri, Sep 18, 2020 at 02:40:12PM +0100, Al Viro wrote: > > > > /* Vector 0x110 is LINUX_32BIT_SYSCALL_TRAP */ > > > > - return

RE: let import_iovec deal with compat_iovecs as well

2020-09-19 Thread David Laight
From: Christoph Hellwig > Sent: 18 September 2020 13:45 > > this series changes import_iovec to transparently deal with comat iovec > structures, and then cleanups up a lot of code dupliation. But to get > there it first has to fix the pre-existing bug that io_uring compat > contexts don't

RE: [PATCH] powerpc: Select HAVE_FUTEX_CMPXCHG

2020-09-19 Thread David Laight
From: Samuel Holland > Sent: 19 September 2020 04:20 > > On powerpc, access_ok() succeeds for the NULL pointer. This breaks the > dynamic check in futex_detect_cmpxchg(), which expects -EFAULT. As a > result, robust futex operations are not functional on powerpc. access_ok(NULL, sane_count) will

RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-10 Thread David Laight
> -Original Message- > From: Segher Boessenkool > Sent: 10 September 2020 16:21 > To: David Laight > Cc: 'Christophe Leroy' ; 'Linus Torvalds' > foundation.org>; linux-arch ; Kees Cook > ; the > arch/x86 maintainers ; Nick Desaulniers > ; Linux

RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-10 Thread David Laight
From: David Laight > Sent: 10 September 2020 10:26 ... > > > I had an 'interesting' idea. > > > > > > Can you use a local asm register variable as an input and output to > > > an 'asm volatile goto' statement? > > > > > > Well you can

RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-10 Thread David Laight
From: Christophe Leroy > Sent: 10 September 2020 09:14 > > Le 10/09/2020 à 10:04, David Laight a écrit : > > From: Linus Torvalds > >> Sent: 09 September 2020 22:34 > >> On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool > >> wrote: > >>>

RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-10 Thread David Laight
From: Linus Torvalds > Sent: 09 September 2020 22:34 > On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool > wrote: > > > > It will not work like this in GCC, no. The LLVM people know about that. > > I do not know why they insist on pushing this, being incompatible and > > everything. > > Umm.

RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-05 Thread David Laight
From: Christophe Leroy > Sent: 05 September 2020 08:16 > > Le 04/09/2020 à 23:01, David Laight a écrit : > > From: Alexey Dobriyan > >> Sent: 04 September 2020 18:58 ... > > What is this strange %fs register you are talking about. > > Figure 2-4 only has CS,

RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-04 Thread David Laight
From: Alexey Dobriyan > Sent: 04 September 2020 18:58 > > On Fri, Sep 04, 2020 at 08:00:24AM +0200, Ingo Molnar wrote: > > * Christoph Hellwig wrote: > > > this series removes the last set_fs() used to force a kernel address > > > space for the uaccess code in the kernel read/write/splice code,

RE: [PATCH 12/14] x86: remove address space overrides using set_fs()

2020-09-04 Thread David Laight
From: Linus Torvalds > Sent: 04 September 2020 00:26 > > On Thu, Sep 3, 2020 at 2:30 PM David Laight wrote: > > > > A non-canonical (is that the right term) address between the highest > > valid user address and the lowest valid kernel address (7ffe to fffe?) >

RE: [PATCH 12/14] x86: remove address space overrides using set_fs()

2020-09-03 Thread David Laight
From: Christoph Hellwig > Sent: 03 September 2020 15:23 > > Stop providing the possibility to override the address space using > set_fs() now that there is no need for that any more. To properly > handle the TASK_SIZE_MAX checking for 4 vs 5-level page tables on > x86 a new alternative is

RE: [PATCH 10/10] powerpc: remove address space overrides using set_fs()

2020-09-02 Thread David Laight
From: Christophe Leroy > Sent: 02 September 2020 15:13 > > > Le 02/09/2020 à 15:51, David Laight a écrit : > > From: Christophe Leroy > >> Sent: 02 September 2020 14:25 > >> Le 02/09/2020 à 15:13, David Laight a écrit : > >>> From: Christ

RE: [PATCH 10/10] powerpc: remove address space overrides using set_fs()

2020-09-02 Thread David Laight
From: Christophe Leroy > Sent: 02 September 2020 14:25 > Le 02/09/2020 à 15:13, David Laight a écrit : > > From: Christoph Hellwig > >> Sent: 02 September 2020 13:37 > >> > >> On Wed, Sep 02, 2020 at 08:15:12AM +0200, Christophe Leroy wrote: > >>>

RE: [PATCH 10/10] powerpc: remove address space overrides using set_fs()

2020-09-02 Thread David Laight
From: Christoph Hellwig > Sent: 02 September 2020 13:37 > > On Wed, Sep 02, 2020 at 08:15:12AM +0200, Christophe Leroy wrote: > >> - return 0; > >> - return (size == 0 || size - 1 <= seg.seg - addr); > >> + if (addr >= TASK_SIZE_MAX) > >> + return false; > >> + if (size == 0)

RE: [PATCH 01/10] fs: don't allow kernel reads and writes without iter ops

2020-08-27 Thread David Laight
From: Christoph Hellwig > Sent: 27 August 2020 16:00 > > Don't allow calling ->read or ->write with set_fs as a preparation for > killing off set_fs. All the instances that we use kernel_read/write on > are using the iter ops already. > > If a file has both the regular ->read/->write methods

RE: Re:Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-24 Thread David Laight
From: Guohua Zhong > Sent: 24 August 2020 14:26 > > >> >In generic version in lib/math/div64.c, there is no checking of 'base' > >> >either. > >> >Do we really want to add this check in the powerpc version only ? > >> > >> >The only user of __div64_32() is do_div() in > >>

RE: [PATCH 09/11] x86: remove address space overrides using set_fs()

2020-08-17 Thread David Laight
From: Christoph Hellwig > Sent: 17 August 2020 08:32 > > Stop providing the possibility to override the address space using > set_fs() now that there is no need for that any more. To properly > handle the TASK_SIZE_MAX checking for 4 vs 5-level page tables on > x86 a new alternative is

RE: [PATCH v2] selftests/powerpc: Fix pkey syscall redefinitions

2020-08-03 Thread David Laight
> > +#undef SYS_pkey_mprotect > > #define SYS_pkey_mprotect 386 > > We shouldn't undef them. > > They should obviously never change, but if the system headers already > have a definition then we should use that, so I think it should be: > > #ifndef SYS_pkey_mprotect > #define

RE: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-16 Thread David Laight
From: Bjorn Helgaas > Sent: 15 July 2020 23:02 > > On Wed, Jul 15, 2020 at 02:24:21PM +0000, David Laight wrote: > > From: Arnd Bergmann > > > Sent: 15 July 2020 07:47 > > > On Wed, Jul 15, 2020 at 1:46 AM Bjorn Helgaas wrote: > > > > &

RE: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-16 Thread David Laight
From: Benjamin Herrenschmidt > Sent: 15 July 2020 23:49 > On Wed, 2020-07-15 at 17:12 -0500, Bjorn Helgaas wrote: > > > I've 'played' with PCIe error handling - without much success. > > > What might be useful is for a driver that has just read ~0u to > > > be able to ask 'has there been an error

RE: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-15 Thread David Laight
From: Oliver O'Halloran > Sent: 15 July 2020 05:19 > > On Wed, Jul 15, 2020 at 8:03 AM Arnd Bergmann wrote: ... > > - config space accesses are very rare compared to memory > > space access and on the hardware side the error handling > > would be similar, but readl/writel don't return

RE: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86

2020-07-15 Thread David Laight
From: Arnd Bergmann > Sent: 15 July 2020 07:47 > On Wed, Jul 15, 2020 at 1:46 AM Bjorn Helgaas wrote: > > So something like: > > > > void pci_read_config_word(struct pci_dev *dev, int where, u16 *val) > > > > and where we used to return anything non-zero, we just set *val = ~0 > > instead? I

RE: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-15 Thread David Laight
From: Jarkko Sakkinen > Sent: 14 July 2020 17:31 .. > There is one arch (nios2), which uses a regular kzalloc(). This means > that both text_alloc() and text_memfree() need to be weaks symbols and > nios2 needs to have overriding text.c to do its thing. That could be handled by an arch-specific

RE: [PATCH] x86: Fix early boot crash on gcc-10, next try

2020-04-27 Thread David Laight
From: Borislav Petkov > Sent: 25 April 2020 18:53 ... > IOW, something like this (ontop) which takes care of the xen case too. > If it needs to be used by all arches, then I'll split the patch: . > - asm (""); > + prevent_tail_call_optimization(); > } One obvious implementation would be

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

2020-04-21 Thread David Laight
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 complex pre-processor asm directives. It optimizes > >> the syscall code

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

2020-04-21 Thread David Laight
From: Adhemerval Zanella > Sent: 21 April 2020 16:01 > > On 21/04/2020 11:39, Rich Felker wrote: > > On Tue, Apr 21, 2020 at 12:28:25PM +0000, David Laight wrote: > >> From: Nicholas Piggin > >>> Sent: 20 April 2020 02:10 > >> ... > >>>&g

RE: hardcoded SIGSEGV in __die() ?

2020-03-25 Thread David Laight
From: Joakim Tjernlund > Sent: 23 March 2020 15:45 ... > > > I tried to follow that chain thinking it would end up sending a signal to > > > user space but I cannot > see > > > that happens. Seems to be related to debugging. > > > > > > In short, I cannot see any signal being delivered to user

RE: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)

2020-02-24 Thread David Laight
From: Geert Uytterhoeven > Sent: 24 February 2020 12:54 > To: Krzysztof Kozlowski ... > > > > diff --git a/drivers/net/wireless/ath/ath5k/ahb.c > > > > b/drivers/net/wireless/ath/ath5k/ahb.c > > > > index 2c9cec8b53d9..8bd01df369fb 100644 > > > > --- a/drivers/net/wireless/ath/ath5k/ahb.c > > >

RE: [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span()

2020-02-05 Thread David Laight
From: Wei Yang > Sent: 05 February 2020 09:59 ... > If it is me, I would like to take out these two similar logic out. > > For example: > > if () { > } else if () { > } else { > goto out; > } I'm pretty sure the kernel layout rules disallow 'else if'. It is

RE: z constraint in powerpc inline assembly ?

2020-01-16 Thread David Laight
> You mean the mpc8xx , but I'm also using the mpc832x which has a e300c2 > core and is capable of executing 2 insns in parallel if not in the same > Unit. That should let you do a memory read and an add. (I can't remember if the ppc has 'add from memory' but that is likely to use both units

RE: z constraint in powerpc inline assembly ?

2020-01-16 Thread David Laight
From: Segher Boessenkool > Sent: 16 January 2020 16:22 ... > > However a loop of 'add with carry' instructions may not be the > > fastest code by any means. > > Because the carry flag is needed for every 'adc' you can't do more > > that one adc per clock. > > This limits you to 8 bytes/clock on a

RE: z constraint in powerpc inline assembly ?

2020-01-16 Thread David Laight
From: Christophe Leroy > Sent: 16 January 2020 06:12 > > I'm trying to see if we could enhance TCP checksum calculations by > splitting inline assembly blocks to give GCC the opportunity to mix it > with other stuff, but I'm getting difficulties with the carry. if you are trying to 'loop carry'

RE: [RFT 00/13] iomap: Constify ioreadX() iomem argument

2020-01-08 Thread David Laight
From: Christophe Leroy > Sent: 08 January 2020 08:49 ... > And as pointed by Arnd, the volatile is really only necessary for the > dereference itself, should the arch use dereferencing. I've had trouble with some versions of gcc and reading of 'volatile unsigned char *'. It tended to follow the

RE: [PATCH] powerpc/tools: Don't quote $objdump in scripts

2019-10-25 Thread David Laight
From: Segher Boessenkool > Sent: 24 October 2019 18:29 > On Thu, Oct 24, 2019 at 11:47:30AM +1100, Michael Ellerman wrote: > > Some of our scripts are passed $objdump and then call it as > > "$objdump". This doesn't work if it contains spaces because we're > > using ccache, for example you get

RE: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

2019-10-21 Thread David Laight
From: Thomas Gleixner > Sent: 20 October 2019 20:53 > On Sun, 20 Oct 2019, Andreas Schwab wrote: > > On Okt 20 2019, Thomas Gleixner wrote: > > > > > POSIX does not mention anything about the validity of the pointer handed > > > to > > > clock_getres(). > > > > Sure it does: "If the argument res

RE: [PATCH v5 03/23] PCI: hotplug: Add a flag for the movable BARs feature

2019-09-30 Thread David Laight
From: Bjorn Helgaas > Sent: 27 September 2019 23:02 > On Fri, Aug 16, 2019 at 07:50:41PM +0300, Sergey Miroshnichenko wrote: > > When hot-adding a device, the bridge may have windows not big enough (or > > fragmented too much) for newly requested BARs to fit in. And expanding > > these bridge

RE: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp

2019-09-04 Thread David Laight
From: Nathan Chancellor [mailto:natechancel...@gmail.com] > Sent: 04 September 2019 01:24 > On Tue, Sep 03, 2019 at 02:31:28PM -0500, Segher Boessenkool wrote: > > On Mon, Sep 02, 2019 at 10:55:53PM -0700, Nathan Chancellor wrote: > > > On Thu, Aug 29, 2019 at 09:59:48AM +000

RE: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp

2019-08-29 Thread David Laight
From: Nathan Chancellor > Sent: 28 August 2019 19:45 ... > However, I think that -fno-builtin-* would be appropriate here because > we are providing our own setjmp implementation, meaning clang should not > be trying to do anything with the builtin implementation like building a > declaration for

RE: [PATCH v1 1/2] open: add close_range()

2019-05-23 Thread David Laight
From: Konstantin Khlebnikov > Sent: 23 May 2019 17:22 > > In addition, the syscall will also work for tasks that do not have procfs > > mounted and on kernels that do not have procfs support compiled in. In such > > situations the only way to make sure that all file descriptors are closed

RE: [PATCH] vsprintf: Do not break early boot with probing addresses

2019-05-15 Thread David Laight
From: Petr Mladek > Sent: 15 May 2019 08:36 > On Tue 2019-05-14 14:37:51, Steven Rostedt wrote: > > > > [ Purple is a nice shade on the bike shed. ;-) ] > > > > On Tue, 14 May 2019 11:02:17 +0200 > > Geert Uytterhoeven wrote: > > > > > On Tue,

RE: [PATCH] vsprintf: Do not break early boot with probing addresses

2019-05-14 Thread David Laight
> And I like Steven's "(fault)" idea. > How about this: > > if ptr < PAGE_SIZE -> "(null)" > if IS_ERR_VALUE(ptr)-> "(fault)" > > -ss Or: if (ptr < PAGE_SIZE) return ptr ? "(null+)" : "(null)"; if IS_ERR_VALUE(ptr)

RE: [PATCH] vsprintf: Do not break early boot with probing addresses

2019-05-13 Thread David Laight
From: christophe leroy > Sent: 10 May 2019 18:35 > Le 10/05/2019 à 18:24, Steven Rostedt a écrit : > > On Fri, 10 May 2019 10:42:13 +0200 > > Petr Mladek wrote: > > > >> static const char *check_pointer_msg(const void *ptr) > >> { > >> - char byte; > >> - > >>if (!ptr) > >>

RE: [PATCH] vsprintf: Do not break early boot with probing addresses

2019-05-09 Thread David Laight
From: Michal Suchánek > Sent: 09 May 2019 14:38 ... > > The problem is the combination of some new code called via printk(), > > check_pointer() which calls probe_kernel_read(). That then calls > > allow_user_access() (PPC_KUAP) and that uses mmu_has_feature() too early > > (before we've patched

RE: [PATCH RFC v4 09/21] PCI: Mark immovable BARs with PCI_FIXED

2019-03-27 Thread David Laight
From: Bjorn Helgaas > Sent: 26 March 2019 20:29 > > On Mon, Mar 11, 2019 at 04:31:10PM +0300, Sergey Miroshnichenko wrote: > > If a PCIe device driver doesn't yet have support for movable BARs, > > mark device's BARs with IORESOURCE_PCI_FIXED. > > I'm hesitant about using IORESOURCE_PCI_FIXED

RE: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER

2018-11-16 Thread David Laight
From: Alexandru Gagniuc > Sent: 15 November 2018 23:16 ... > I've asked around a few people at Dell and they unanimously agree that > _OSC is the correct way to determine ownership of AER. This is all very well, but we have systems (they might be Dell ones) where failure of a PCIe link (even when

RE: powerpc/xmon: Relax frame size for clang

2018-11-02 Thread David Laight
From: Linuxppc-dev [mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org] On Behalf Of > Michael Ellerman > Subject: Re: powerpc/xmon: Relax frame size for clang > > On Wed, 2018-10-31 at 01:09:34 UTC, Joel Stanley wrote: > > When building with clang (8 trunk, 7.0 release) the

RE: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed

2018-11-02 Thread David Laight
From: Paul E. McKenney > Sent: 01 November 2018 17:02 ... > And there is a push to define C++ signed arithmetic as 2s complement, > but there are still 1s complement systems with C compilers. Just not > C++ compilers. Legacy... Hmmm... I've used C compilers for DSPs where signed integer

RE: [PATCH] net: ethernet: fs-enet: Use generic CRC32 implementation

2018-07-24 Thread David Laight
From: Krzysztof Kozlowski > Sent: 23 July 2018 17:20 > Use generic kernel CRC32 implementation because it: > 1. Should be faster (uses lookup tables), Are you sure? The lookup tables are unlikely to be in the data cache and the 6 cache misses kill performance. (Not that it particularly matters

RE: [PATCH] net: ethernet: fs-enet: Use generic CRC32 implementation

2018-07-24 Thread David Laight
From: Krzysztof Kozlowski > Sent: 24 July 2018 12:12 ... > >> Not tested on hardware. > > > > Have you verified that the old and new functions give the > > same result for a few mac addresses? > > It is very easy to use the wrong bits in crc calculations > > or generate the output in the wrong bit

RE: [PATCH v2] powerpc/64: Fix build failure with GCC 8.1

2018-05-29 Thread David Laight
From: Christophe LEROY > Sent: 29 May 2018 10:37 ... > - strncpy(new_part->header.name, name, 12); > + memcpy(new_part->header.name, name, strnlen(name, > sizeof(new_part->header.name))); > >>> > >>> > >>> The comment for nvram_header.lgnth says: > >>> > >>> /*

RE: RFC on writel and writel_relaxed

2018-03-29 Thread David Laight
From: Jason Gunthorpe > Sent: 29 March 2018 15:45 ... > > > When talking about ordering between the devices, the relevant question > > > is what happens if the writel(DEVICE_BAR) triggers DEVICE_BAR to DMA > > > from the DEVICE_FOO. 'ordered' means that in this case > > > writel(DEVICE_FOO) must

RE: RFC on writel and writel_relaxed

2018-03-28 Thread David Laight
From: Benjamin Herrenschmidt > Sent: 28 March 2018 16:13 ... > > I've always wondered exactly what the twi;isync were for - always seemed > > very heavy handed for most mmio reads. > > Particularly if you are doing mmio reads from a data fifo. > > If you do that you should use the "s" version of

RE: RFC on writel and writel_relaxed

2018-03-28 Thread David Laight
From: Benjamin Herrenschmidt > Sent: 28 March 2018 10:56 ... > For example, let's say I have a device with a reset bit and the spec > says the reset bit needs to be set for at least 10us. > > This is wrong: > > writel(1, RESET_REG); > usleep(10); > writel(0, RESET_REG); > >

RE: RFC on writel and writel_relaxed

2018-03-28 Thread David Laight
From: Will Deacon > Sent: 28 March 2018 09:54 ... > > > I don't think so. My reading of memory-barriers.txt says that writeX might > > > expand to outX, and outX is not ordered with respect to other types of > > > memory. > > > > Ugh ? > > > > My understanding of HW at least is the exact opposite.

RE: RFC on writel and writel_relaxed

2018-03-27 Thread David Laight
> Fair enough. I'd rather people used _relaxed by default, but I have to admit > that it will probably just result in them getting things wrong... Certainly requiring the driver writes use explicit barriers should make them understand when and why they are needed - and then put in the correct

RE: RFC on writel and writel_relaxed

2018-03-26 Thread David Laight
> > This is a super performance critical operation for most drivers and > > directly impacts network performance. Perhaps there ought to be writel_nobarrier() (etc) that never contain any barriers at all. This might mean that they are always just the memory operation, but it would make it more

RE: RFC on writel and writel_relaxed

2018-03-22 Thread David Laight
From: Oliver > Sent: 22 March 2018 05:24 ... > > No less painful was doing a byteswapping write to normal memory. > > What was the problem? The reverse indexed load/store instructions are > a little awkward to use, but they work... Finding something that would generate the right instruction

RE: RFC on writel and writel_relaxed

2018-03-21 Thread David Laight
> x86 has compiler barrier inside the relaxed() API so that code does not > get reordered. ARM64 architecturally guarantees device writes to be observed > in order. There are places where you don't even need a compile barrier between every write. I had horrid problems getting some ppc code (for

RE: POWER: Unexpected fault when writing to brk-allocated memory

2017-11-10 Thread David Laight
From: Matthew Wilcox > Sent: 09 November 2017 19:44 > > On Fri, Nov 10, 2017 at 04:15:26AM +1100, Nicholas Piggin wrote: > > So these semantics are what we're going with? Anything that does mmap() is > > guaranteed of getting a 47-bit pointer and it can use the top 17 bits for > > itself? Is

RE: [PATCH] [net-next,v2] ibmvnic: Feature implementation of Vital Product Data (VPD) for the ibmvnic driver

2017-11-06 Thread David Laight
From: David Miller > Sent: 04 November 2017 13:21 > From: Desnes Augusto Nunes do Rosario > Date: Wed, 1 Nov 2017 19:03:32 -0200 > > > + substr = strnstr(adapter->vpd->buff, "RM", adapter->vpd->len); > > + if (!substr) { > > + dev_info(dev, "No FW level

RE: [PATCH 1/4] powerpc/tm: Add commandline option to disable hardware transactional memory

2017-10-23 Thread David Laight
From: Michael Neuling > Sent: 21 October 2017 02:00 > To: David Laight; 'Breno Leitao'; Michael Ellerman > Cc: stew...@linux.vnet.ibm.com; linuxppc-...@ozlabs.org; cyril...@gmail.com > Subject: Re: [PATCH 1/4] powerpc/tm: Add commandline option to disable > hardware trans

RE: [PATCH 1/4] powerpc/tm: Add commandline option to disable hardware transactional memory

2017-10-20 Thread David Laight
> > This patch adds a simple commandline option so that HTM can be > > disabled at boot time. ISTM that being able to disable it after boot would be more useful. (ie in a startup script) David

RE: Adjusting further size determinations?

2017-10-18 Thread David Laight
From: SF Markus Elfring > Unpleasant consequences are possible in both cases. > >> How much do you care to reduce the failure probability further? > > > > Zero. > > I am interested to improve the software situation a bit more here. There are probably better places to spend your time! If

RE: [PATCH] powerpc/lib/sstep: Fix count leading zeros instructions

2017-10-09 Thread David Laight
From: naveen.n@linux.vnet.ibm.com > Sent: 09 October 2017 15:48 ... > This is about the behavior of the gcc builtin being undefined, rather > than the actual cpu instruction itself. I'd have hoped that the ggc builtin just generated the expected cpu instruction. So is only undefined because

RE: [PATCH] powerpc/lib/sstep: Fix count leading zeros instructions

2017-10-09 Thread David Laight
From: Segher Boessenkool > Sent: 09 October 2017 15:21 > On Mon, Oct 09, 2017 at 01:49:26PM +, David Laight wrote: > > From: Sandipan Das > > > Sent: 09 October 2017 12:07 > > > According to the GCC documentation, the behaviour of __builtin_clz() > >

RE: [PATCH] powerpc/lib/sstep: Fix count leading zeros instructions

2017-10-09 Thread David Laight
From: Sandipan Das > Sent: 09 October 2017 12:07 > According to the GCC documentation, the behaviour of __builtin_clz() > and __builtin_clzl() is undefined if the value of the input argument > is zero. Without handling this special case, these builtins have been > used for emulating the following

  1   2   3   4   5   >