RE: hardcoded SIGSEGV in __die() ?

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)

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()

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 ?

> 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 ?

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 ?

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

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

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

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

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

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

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()

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

> > 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

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

> 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

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

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

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

> > 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?

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

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

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

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

RE: [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap

From: Michal Hocko > Sent: 06 October 2017 12:47 > On Fri 06-10-17 11:10:14, David Laight wrote: > > From: Pavel Tatashin > > > Sent: 05 October 2017 22:11 > > > vmemmap_alloc_block() will no longer zero the block, so zero memory > > > at its call sites for

RE: [PATCH v10 09/10] mm: stop zeroing memory during allocation in vmemmap

From: Pavel Tatashin > Sent: 05 October 2017 22:11 > vmemmap_alloc_block() will no longer zero the block, so zero memory > at its call sites for everything except struct pages. Struct page memory > is zero'd by struct page initialization. It seems dangerous to change an allocator to stop zeroing

RE: [PATCH 04/11] ia64: make dma_cache_sync a no-op

From: Christoph Hellwig > Sent: 03 October 2017 11:43 > > ia64 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't > make any sense to do any work in dma_cache_sync given that it must be a > no-op when dma_alloc_attrs returns coherent memory. > > Signed-off-by: Christoph Hellwig

RE: [PATCH 02/11] x86: make dma_cache_sync a no-op

From: Christoph Hellwig > Sent: 03 October 2017 11:43 > x86 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't > make any sense to do any work in dma_cache_sync given that it must be a > no-op when dma_alloc_attrs returns coherent memory. I believe it is just about possible to

RE: [PATCH v2 2/3] powerpc/64: enhance memcmp() with VMX instruction for long bytes comparision

From: Simon Guo > Sent: 27 September 2017 19:34 ... > > On X86 all the AVX registers are caller saved, the system call > > entry could issue the instruction that invalidates them all. > > Kernel code running in the context of a user process could then > > use the registers without saving them. > >

RE: [PATCH v2 2/3] powerpc/64: enhance memcmp() with VMX instruction for long bytes comparision

From: Segher Boessenkool > Sent: 27 September 2017 10:28 ... > You also need nasty code to deal with the start and end of strings, with > conditional branches and whatnot, which quickly overwhelms the benefit > of using vector registers at all. This tradeoff also changes with newer > ISA

RE: [PATCH] mm: fix RODATA_TEST failure "rodata_test: test data was not read only"

From: Segher Boessenkool > Sent: 25 September 2017 08:37 > On Sun, Sep 24, 2017 at 12:17:51PM -0700, Kees Cook wrote: > > On Thu, Sep 21, 2017 at 2:37 AM, Christophe Leroy > > wrote: > > > On powerpc, RODATA_TEST fails with message the following messages: > > > > > > [

RE: [PATCH v2 3/3] powerpc:selftest update memcmp_64 selftest for VMX implementation

From: wei.guo.si...@gmail.com > Sent: 21 September 2017 00:35 > This patch adjust selftest memcmp_64 so that memcmp selftest can be > compiled successfully. ... > #define ITERATIONS 1 > > +#define LARGE_SIZE (5 * 1024) > +#define LARGE_ITERATIONS 1000 ... Measuring performance by doing a

RE: [PATCH v1 1/3] powerpc: Align bytes before fall back to .Lshort in powerpc memcmp

From: Simon Guo > Sent: 20 September 2017 10:57 > On Tue, Sep 19, 2017 at 10:12:50AM +, David Laight wrote: > > From: wei.guo.si...@gmail.com > > > Sent: 19 September 2017 11:04 > > > Currently memcmp() in powerpc will fall back to .Lshort (compare per byte &g

RE: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

From: Helge Deller > Sent: 19 September 2017 21:08 ... > > Using 'unsigned long' for any kind of pointer is an accident > > waiting do happen. > > It also makes it difficult to typecheck the function calls. > > Using 'void *' isn't any better. > > Either a pointer to an undefined struct, or a

RE: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

From: Sergey Senozhatsky > Sent: 19 September 2017 03:06 ... > I'll simply convert everything to `unsigned long'. including the > dereference_function_descriptor() function [I believe there are > still some casts happening when we pass addr from kernel/module > dereference functions to

RE: [PATCH v1 1/3] powerpc: Align bytes before fall back to .Lshort in powerpc memcmp

From: wei.guo.si...@gmail.com > Sent: 19 September 2017 11:04 > Currently memcmp() in powerpc will fall back to .Lshort (compare per byte > mode) if either src or dst address is not 8 bytes aligned. It can be > opmitized if both addresses are with the same offset with 8 bytes boundary. > >

RE: [PATCH kernel] powerpc/powernv: Update comment about shifting IOV BAR

From: Benjamin Herrenschmidt > Sent: 14 September 2017 04:40 > On Thu, 2017-09-14 at 13:18 +1000, Alexey Kardashevskiy wrote: > > On 14/09/17 13:07, Benjamin Herrenschmidt wrote: > > > On Thu, 2017-09-14 at 12:45 +1000, Alexey Kardashevskiy wrote: > > > > On 31/08/17 13:34, Alexey Kardashevskiy

RE: [PATCH 1/2] powerpc/xmon: hdec is now 64bits

From: Balbir Singh > Sent: 30 August 2017 01:28 > ISA 300 defines hypervisor decrementer to be 64 bits in length. > This patch extends the print format for all archs to be 64 bits > > Signed-off-by: Balbir Singh > --- > arch/powerpc/xmon/xmon.c | 2 +- > 1 file changed, 1

RE: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

From: Alex Williamson > Sent: 16 August 2017 17:56 ... > Firmware pissing match... Processors running with 8k or less page size > fall within the recommendations of the PCI spec for register alignment > of MMIO regions of the device and this whole problem becomes less of an > issue. Actually if

RE: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

From: Benjamin Herrenschmidt > Sent: 15 August 2017 02:34 > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > > Taking a step back, though, why does vfio-pci perform this check in the > > > first place? If a malicious guest already has control of a device, any > > > kind of interrupt

RE: [v6 11/15] arm64/kasan: explicitly zero kasan shadow memory

From: Pasha Tatashin > Sent: 08 August 2017 12:49 > Thank you for looking at this change. What you described was in my > previous iterations of this project. > > See for example here: https://lkml.org/lkml/2017/5/5/369 > > I was asked to remove that flag, and only zero memory in place when >

RE: [PATCH v9 14/14] powerpc: rewrite local_t using soft_irq

From: Nicholas Piggin > Sent: 04 August 2017 10:04 > On Fri, 04 Aug 2017 11:40:43 +1000 > Benjamin Herrenschmidt wrote: > > > On Fri, 2017-08-04 at 03:50 +1000, Nicholas Piggin wrote: > > > Hey, so... why are any of these implemented in asm? We should > > > just do them

RE: [RESEND][PATCH V10 0/3] powernv : Add support for OPAL-OCC command/response interface

From: Shilpasri G Bhat > Sent: 31 July 2017 08:43 > In P9, OCC (On-Chip-Controller) supports shared memory based > commad-response interface. Within the shared memory there is an OPAL ^ typo > command buffer and OCC response buffer that can be used to send > inband commands to OCC. The

RE: [PATCH 1/5] Fix packed and aligned attribute warnings.

From: SZ Lin > Sent: 29 July 2017 08:24 ... > diff --git a/drivers/char/tpm/tpm_ibmvtpm.h b/drivers/char/tpm/tpm_ibmvtpm.h > index 91dfe766d080..9f708ca3dc84 100644 > --- a/drivers/char/tpm/tpm_ibmvtpm.h > +++ b/drivers/char/tpm/tpm_ibmvtpm.h > @@ -25,7 +25,7 @@ struct ibmvtpm_crq { > __be16

RE: [RFC Part1 PATCH v3 07/17] x86/mm: Include SEV for encryption memory attribute changes

From: Borislav Petkov > Sent: 27 July 2017 15:59 > On Mon, Jul 24, 2017 at 02:07:47PM -0500, Brijesh Singh wrote: > > From: Tom Lendacky > > > > The current code checks only for sme_active() when determining whether > > to perform the encryption attribute change. Include

RE: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

From: Brijesh Singh > Sent: 26 July 2017 21:07 ... > I am not sure if I understand your concern. > > Are you commenting on amount of code duplication ? If so, I can certainly > improve > and use the similar macro used into header file to generate the functions > body. If you are careful the

RE: [PATCH 3/4] powerpc: pseries: only store the device node basename in full_name

From: Rob Herring > Sent: 25 July 2017 22:44 > With dependencies on full_name containing the entire device node path > removed, stop storing the full_name in nodes created by > dlpar_configure_connector() and pSeries_reconfig_add_node(). ... > dn = kzalloc(sizeof(*dn), GFP_KERNEL); >

RE: [PATCH v3 2/5] powerpc/lib/sstep: Add popcnt instruction emulation

From: Linuxppc-dev [mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org] On Behalf Of > Matt Brown > Sent: 25 July 2017 04:33 > To: linuxppc-dev@lists.ozlabs.org > Subject: [PATCH v3 2/5] powerpc/lib/sstep: Add popcnt instruction emulation > > This adds emulations for the

RE: [RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

From: Brijesh Singh > Sent: 24 July 2017 20:08 > From: Tom Lendacky > > Secure Encrypted Virtualization (SEV) does not support string I/O, so > unroll the string I/O operation into a loop operating on one element at > a time. > > Signed-off-by: Tom Lendacky

RE: [PATCH] tty: Fix TIOCGPTPEER ioctl definition

From: Linuxppc-dev Gleb Fotengauer-Malinovskiy > Sent: 11 July 2017 01:12 > This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag > because it doesn't copy anything from/to userspace to access the > argument. > > Fixes: 54ebbfb1 ("tty: add TIOCGPTPEER ioctl") ... > -#define

RE: [PATCH v2 08/10] powerpc/opal: Add opal_async_wait_response_interruptible() to opal-async

From: Cyril Bur > Sent: 10 July 2017 02:31 > This patch adds an _interruptible version of opal_async_wait_response(). > This is useful when a long running OPAL call is performed on behalf of a > userspace thread, for example, the opal_flash_{read,write,erase} > functions performed by the

RE: [PATCH v5 2/7] powerpc/vmlinux.lds: Align __init_begin to 16M

From: Balbir Singh > Sent: 28 June 2017 18:04 > For CONFIG_STRICT_KERNEL_RWX align __init_begin to 16M. > We use 16M since its the larger of 2M on radix and 16M > on hash for our linear mapping. The plan is to have > .text, .rodata and everything upto __init_begin marked > as RX. Note we still

RE: [PATCH v2] powerpc/powernv: Enable PCI peer-to-peer

From: Frederic Barrat > Sent: 26 June 2017 19:09 > P9 has support for PCI peer-to-peer, enabling a device to write in the > mmio space of another device directly, without interrupting the CPU. > > This patch adds support for it on powernv, by adding a new API to be > called by drivers. The

RE: [PATCH] powerpc/32: Avoid miscompilation w/GCC 4.6.3 - don't inline copy_to/from_user()

From: Michael Ellerman > Sent: 26 June 2017 14:34 .. > Al also pointed out that inlining copy_to/from_user() is probably of little or > no benefit, which is correct ... I was a bit horrified at the x86-64 versions of copy_to/from_user() as well. With code that (tries to) error kernel pointers

RE: [PATCH] soc/qman: Sleep instead of stuck hacking jiffies.

From: Karim Eshapa > Sent: 25 June 2017 16:14 > Use msleep() instead of stucking with > long delay will be more efficient. ... > --- a/drivers/soc/fsl/qbman/qman.c > +++ b/drivers/soc/fsl/qbman/qman.c > @@ -1084,11 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p) >*

RE: [PATCH] powerpc/powernv: Enable PCI peer-to-peer

From: Benjamin Herrenschmidt > Sent: 31 May 2017 03:26 ... > We might also need a way to provide the "initiator" with translated DMA > addresses that allow to target the receiver. Related to that is the ability to allocate memory that two (or more) PCIe devices can DMA to/from. That can be useful

RE: [PATCH 3/3] powerpc/8xx: xmon compile fix

From: Michael Ellerman > Sent: 26 May 2017 08:24 > Nicholas Piggin writes: > > diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c > > index f11f65634aab..438fdb0fb142 100644 > > --- a/arch/powerpc/xmon/xmon.c > > +++ b/arch/powerpc/xmon/xmon.c > > @@ -1242,14

RE: RFC: better timer interface

From: Thomas Gleixner > Sent: 23 May 2017 12:59 > On Tue, 23 May 2017, David Laight wrote: > > > From: Thomas Gleixner > > > Sent: 21 May 2017 19:15 > > ... > > > > timer_start(timer, ms, abs) > > > > > > I'm not even sure, whether we

RE: RFC: better timer interface

From: Thomas Gleixner > Sent: 21 May 2017 19:15 ... > > timer_start(timer, ms, abs) > > I'm not even sure, whether we need absolute timer wheel timers at > all, because most use cases are relative to now. Posix requires absolute timers for some userspace calls (annoying because the code often

RE: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32

From: Arnd Bergmann > Sent: 17 May 2017 22:40 > > On Wed, May 17, 2017 at 11:16 PM, Chris Packham > wrote: > > On 18/05/17 06:18, Borislav Petkov wrote: > > One thing I would like confirmation on is is in_le32 -> ioread32 the > > correct change? I tossed up

RE: [PATCH 2/9] timers: provide a "modern" variant of timers

From: Christoph Hellwig > Sent: 16 May 2017 12:48 > > The new callback gets a pointer to the timer_list itself, which can > then be used to get the containing structure using container_of > instead of casting from and to unsigned long all the time. What about sensible drivers that put some other

RE: [PATCH] spin loop primitives for busy waiting

From: Linus Torvalds > Sent: 11 May 2017 19:48 ... > The one question I have is about "spin_on_cond()": since you > explicitly document that the "no spinning" case is expected to be the > default, I really think that the default implementation should be > along the lines if > > #define

RE: [PATCH v2] powerpc/kprobes: refactor kprobe_lookup_name for safer string operations

From: Paul Clarke > Sent: 04 May 2017 16:07 ... > > + if ((c = strnchr(name, MODULE_NAME_LEN, ':')) != NULL) { > > Shouldn't this be MODULE_NAME_LEN + 1, since the ':' can come after a module > name of length > MODULE_NAME_LEN? No, because MODULE_NAME_LEN includes the terminating '\0'.

RE: [PATCH v2] powerpc/kprobes: refactor kprobe_lookup_name for safer string operations

From: Naveen N. Rao [mailto:naveen.n@linux.vnet.ibm.com] > Sent: 04 May 2017 11:25 > Use safer string manipulation functions when dealing with a > user-provided string in kprobe_lookup_name(). > > Reported-by: David Laight <david.lai...@aculab.com> > Signed-off-by:

RE: [PATCH] powerpc/xive: Fix/improve verbose debug output

From: Michael Ellerman > Sent: 28 April 2017 07:34 ... > Not sure what you mean. You can enable pr_debug()s individually, by > function, by module, by file, or for the whole kernel. It is sort of a shame that you can't turn pr_info() off in the same way. David

RE: [PATCH] kallsyms: optimize kallsyms_lookup_name() for a few cases

From: Naveen N. Rao > Sent: 25 April 2017 17:18 > 1. Fail early for invalid/zero length symbols. > 2. Detect names of the form and skip checking for kernel > symbols in that case. > > Signed-off-by: Naveen N. Rao > --- > Masami, Michael, > I have added two very

RE: [PATCH 8/8] selftests: x86: override clean in lib.mk to fix warnings

From: Linuxppc-dev Michael Ellerman > Shuah Khan writes: > > > Add override for lib.mk clean to fix the following warnings from clean > > target run. > > > > Makefile:44: warning: overriding recipe for target 'clean' > > ../lib.mk:55: warning: ignoring old recipe for

RE: [PATCH 2/8] selftests: lib.mk: define CLEAN macro to allow Makefiles to override clean

From: Shuah Khan > Sent: 22 April 2017 00:15 > Define CLEAN macro to allow Makefiles to override common clean target > in lib.mk. This will help fix the following failures: > > warning: overriding recipe for target 'clean' > ../lib.mk:55: warning: ignoring old recipe for target 'clean' > >

RE: [PATCH v3 4/7] powerpc: kprobes: use safer string functions in kprobe_lookup_name()

From: Naveen N. Rao > Sent: 19 April 2017 13:51 ... > dot_name[0] = '\0'; > - strncat(dot_name, name, sizeof(dot_name) - 1); > + strlcat(dot_name, name, sizeof(dot_name)); ... Is that really zeroing the first byte just so it can append

RE: [PATCH] powerpc/32: Move entry_32 functions just after HEAD functions.

From: Christophe Leroy > By default, PPC8xx PINs an ITLB on the first 8M of memory in order > to avoid any ITLB miss on kernel code. > However, with some debug functions like DEBUG_PAGEALLOC and > (soon to come) DEBUG_RODATA, the PINned TLB is invalidated soon > after startup so ITLB missed start

RE: [PATCH v2 1/5] kprobes: convert kprobe_lookup_name() to a function

From: Naveen N. Rao > Sent: 19 April 2017 09:09 > To: David Laight; Michael Ellerman > Cc: linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Masami > Hiramatsu; Ingo Molnar > Subject: RE: [PATCH v2 1/5] kprobes: convert kprobe_lookup_name() to a > function >

RE: [PATCH v2 1/5] kprobes: convert kprobe_lookup_name() to a function

From: Naveen N. Rao > Sent: 12 April 2017 11:58 ... > +kprobe_opcode_t *kprobe_lookup_name(const char *name) > +{ ... > + char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN]; > + const char *modsym; > + bool dot_appended = false; > + if ((modsym = strchr(name, ':')) != NULL) { > +

RE: [PATCH 1/4] crypto: powerpc - Factor out the core CRC vpmsum algorithm

From: Daniel Axtens > Sent: 15 March 2017 22:30 > Hi David, > > > While not part of this change, the unrolled loops look as though > > they just destroy the cpu cache. > > I'd like be convinced that anything does CRC over long enough buffers > > to make it a gain at all. > > > > With modern (not

RE: [PATCH 1/4] crypto: powerpc - Factor out the core CRC vpmsum algorithm

From: Linuxppc-dev Daniel Axtens > Sent: 15 March 2017 12:38 > The core nuts and bolts of the crc32c vpmsum algorithm will > also work for a number of other CRC algorithms with different > polynomials. Factor out the function into a new asm file. > > To handle multiple users of the function, a

RE: [RFC PATCH 07/13] kernel/fork: Split and export 'mm_alloc' and 'mm_init'

From: Linuxppc-dev Till Smejkal > Sent: 13 March 2017 22:14 > The only way until now to create a new memory map was via the exported > function 'mm_alloc'. Unfortunately, this function not only allocates a new > memory map, but also completely initializes it. However, with the > introduction of

RE: [PATCH] powerpc: Avoid panic during boot due to divide by zero in init_cache_info()

From: Segher Boessenkool > Sent: 06 March 2017 14:18 > On Mon, Mar 06, 2017 at 01:03:19PM +0100, Gabriel Paubert wrote: > > > > > The PowerPC divw etc. instructions do not trap by themselves, but > > > > > recent > > > > > GCC inserts trap instructions on code paths that are always undefined > >

RE: [PATCH v2 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

From: Peter Zijlstra > Sent: 06 March 2017 11:22 > To: Madhavan Srinivasan > Cc: Wang Nan; Alexander Shishkin; linux-ker...@vger.kernel.org; Arnaldo > Carvalho de Melo; Alexei > Starovoitov; Ingo Molnar; Stephane Eranian; Sukadev Bhattiprolu; > linuxppc-dev@lists.ozlabs.org > Subject: Re: [PATCH

RE: [PATCH v2 0/2] Allow configurable stack size (especially 32k on PPC64)

From: Hamish Martin > Sent: 24 February 2017 00:52 > This patch series adds the ability to configure the THREAD_SHIFT value and > thereby alter the stack size on powerpc systems. We are particularly > interested > in configuring for a 32k stack on PPC64. > > Using an NXP T2081 (e6500 PPC64

RE: [RFC][PATCH] powerpc/64s: optimise syscall entry with relon hypercalls

From: Nicholas Piggin > Sent: 10 February 2017 18:23 > After bc3551257a ("powerpc/64: Allow for relocation-on interrupts from > guest to host"), a getppid() system call goes from 307 cycles to 358 > cycles (+17%). This is due significantly to the scratch SPR used by the > hypercall. > > It turns

RE: [PATCH] block: sed-opal: reduce stack size of ioctl handler

From: Arnd Bergmann > Sent: 08 February 2017 21:15 > > When CONFIG_KASAN is in use, the sed_ioctl function uses unusually large > stack, > as each possible ioctl argument gets its own stack area plus redzone: Why not do a single copy_from_user() at the top of sed_ioctl() based on the _IOC_DIR()

RE: ibmvtpm byteswapping inconsistency

From: Michal Suchánek > Sent: 02 February 2017 11:30 ... > The word is marked correctly as __be64 in that patch because count and > handle are swapped to BE when saved to it and the whole word is then > swapped again when loaded. If you just load ((u64)IBMVTPM_VALID_CMD << > 56 |

RE: ibmvtpm byteswapping inconsistency

From: Tyrel Datwyler > Sent: 27 January 2017 18:03 > On 01/26/2017 05:50 PM, Benjamin Herrenschmidt wrote: > > On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote: > >> On 01/26/2017 12:22 PM, Michal Suchnek wrote: > >>> Hello, > >>> > >>> building ibmvtpm I noticed gcc warning complaining

RE: ibmvtpm byteswapping inconsistency

From: Michal Suchánek > building ibmvtpm I noticed gcc warning complaining that second word of > struct ibmvtpm_crq in tpm_ibmvtpm_suspend is uninitialized. > > The structure is defined as > > struct ibmvtpm_crq { > u8 valid; > u8 msg; > __be16 len; > __be32 data;

RE: gcc trunk fails to build kernel on PowerPC64 due to oprofile warnings

From: Anton Blanchard > Sent: 25 January 2017 23:01 > gcc trunk has failed to build PowerPC64 kernels for a month or so. The issue > is in oprofile, which is common code but ends up being sucked into > arch/powerpc and therefore subject to the -Werror applied to arch/powerpc: ... >

<    1   2   3   4   5   6   >