RE: BUILD_BUG_ON(!__builtin_constant_p(feature)) breaks bcc trace tool

From: Michael Ellerman > Sent: 24 January 2017 06:16 > Anton Blanchard writes: > >> We added: > >> > >> BUILD_BUG_ON(!__builtin_constant_p(feature)) > >> > >> to cpu_has_feature() and mmu_has_feature() in order to catch usage > >> issues (such as

RE: [PATCH 3/3] powerpc: bpf: implement in-register swap for 64-bit endian operations

From: 'Naveen N. Rao' > Sent: 23 January 2017 19:22 > On 2017/01/15 09:00AM, Benjamin Herrenschmidt wrote: > > On Fri, 2017-01-13 at 23:22 +0530, 'Naveen N. Rao' wrote: > > > > That rather depends on whether the processor has a store to load > > > > forwarder > > > > that will satisfy the read

RE: [PATCH v4 3/3] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs

From: Ard Biesheuvel > Sent: 18 January 2017 13:53 .. > It turns out that this odd treatment of absolute symbols (i.e., > symbols having section number SHN_ABS) is a known issue in GNU ld > > https://sourceware.org/ml/binutils/2012-05/msg00019.html ... Jeepers - that is truly f*cked. I've even

RE: llist code relies on undefined behaviour, upsets llvm/clang

From: Anton Blanchard > Sent: 15 January 2017 21:36 > I was debugging a hang on a ppc64le kernel built with clang, and it > looks to be undefined behaviour with pointer wrapping in the llist code. > > A test case is below. llist_for_each_entry() does container_of() on a > NULL pointer, which

RE: [PATCH 3/3] powerpc: bpf: implement in-register swap for 64-bit endian operations

From: Naveen N. Rao > Sent: 13 January 2017 17:10 > Generate instructions to perform the endian conversion using registers, > rather than generating two memory accesses. > > The "way easier and faster" comment was obviously for the author, not > the processor. That rather depends on whether the

RE: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'

From: Christophe LEROY > Sent: 13 January 2017 12:15 ... > > Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally > > be true for glibc >= 2.4), and that is all. Mystery solved. Thanks! > > > > Is there a way to know during compilation how the compiler will behave, > in

RE: [RFC 1/4] mm: remove unused TASK_SIZE_OF()

From: Dmitry Safonov > Sent: 30 December 2016 15:57 > All users of TASK_SIZE_OF(tsk) have migrated to mm->task_size or > TASK_SIZE_MAX since: > commit d696ca016d57 ("x86/fsgsbase/64: Use TASK_SIZE_MAX for > FSBASE/GSBASE upper limits"), > commit a06db751c321 ("pagemap: check permissions and

RE: [PATCH] ASoC : fsl_ssi : Correct the condition to check AC97 mode

From: Harisangam, Sharvari (S.) > Sent: 28 December 2016 11:07 > Corrected the condition to check if ssi is configured for AC97 > mode. Other modes like dsp_a also satisfy the ANDing condition. Under the assumption that the constants have 1 bit set nothing is wrong. David ... > -

RE: [PATCH v4 4/7] PCI: Don't update VF BARs while VF memory space is enabled

From: Bjorn Helgaas > Sent: 29 November 2016 04:15 > If we update a VF BAR while it's enabled, there are two potential problems: > > 1) Any driver that's using the VF has a cached BAR value that is stale > after the update, and > > 2) We can't update 64-bit BARs atomically, so the

RE: [PATCH v2] adb: properly mark continued kernel messages

From: Andreas Schwab > Sent: 28 November 2016 20:29 > Use pr_cont where appropriate, and switch to pr_foo throughout. > Additionally, lower messages in adb_probe_task to debug level. Doesn't pr_cont() have its own major problem - garbled messages if there are concurrent writers? So it is best

RE: Coding Style: Reverse XMAS tree declarations ?

From: Lino Sanfilippo > Sent: 04 November 2016 20:07 ... > In this case it is IMHO rather the declaration + initialization that makes > "bar" hard to find at one glance, not the use of RXT. You could do something > like > > [longish list of reverse xmas tree identifiers...] > struct

RE: [PATCH v5 9/9] Documentation: virtual: kvm: Support vcpu preempted check

From: Pan Xinhui > Sent: 20 October 2016 22:28 > Commit ("x86, kvm: support vcpu preempted check") add one field "__u8 > preempted" into struct kvm_steal_time. This field tells if one vcpu is > running or not. > > It is zero if 1) some old KVM deos not support this filed. 2) the vcpu is >

RE: [RFC PATCH 2/3] powerpc/pseries: Define & use a type for the plpar_hcall() retvals

From: Balbir Singh > Sent: 19 October 2016 15:00 ... > Here is an example > > - *slot = retbuf[0]; > + *slot = retvals.v[0]; > > Could we hide retvals.v[0] under a macro like > > *slot = hcalls_ret_val(retvals, 0); Ugg.. > Since we could end up with similar issues if > someone

RE: [PATCH] powerpc: link error on orphan sections

From: Michael Ellerman [mailto:m...@ellerman.id.au] > > In the past I've caused orphan sections to error by assigning them > > to the same address as something that exists. > > Works with all linkers, even if the error message isn't as useful. > > How do you assign them an address without knowing

RE: [PATCH] powerpc: link error on orphan sections

From: Michael Ellerman > Sent: 14 October 2016 01:46 ... > > +LDFLAGS_vmlinux:= $(LDFLAGS_vmlinux-y) --orphan-handling=error > > At least some old(er) toolchains don't support that: > > /opt/cross/kisskb/gcc-4.6.3-nolibc/powerpc-linux/bin/powerpc-linux-ld: > unrecognized option '-- >

RE: [net-next 08/13] fsl/fman: check pcsphy pointer before use

From: Madalin Bucur > Sent: 04 October 2016 08:33 > Subject: [net-next 08/13] fsl/fman: check pcsphy pointer before use .. > --- a/drivers/net/ethernet/freescale/fman/fman_memac.c > +++ b/drivers/net/ethernet/freescale/fman/fman_memac.c > @@ -507,6 +507,9 @@ static void

RE: [PATCH 04/13] powerpc: Use soft_enabled_set api to update paca->soft_enabled

From: Nicholas Piggin > Sent: 16 September 2016 12:59 > On Fri, 16 Sep 2016 11:43:13 +0000 > David Laight <david.lai...@aculab.com> wrote: > > > From: Nicholas Piggin > > > Sent: 16 September 2016 10:53 > > > On Thu, 15 Sep 2016 18:31:54 +0530 > >

RE: [PATCH 04/13] powerpc: Use soft_enabled_set api to update paca->soft_enabled

From: Nicholas Piggin > Sent: 16 September 2016 10:53 > On Thu, 15 Sep 2016 18:31:54 +0530 > Madhavan Srinivasan wrote: > > > Force use of soft_enabled_set() wrapper to update paca-soft_enabled > > wherever possisble. Also add a new wrapper function, > >

RE: [PATCH][RFC] Implement arch primitives for busywait loops

From: Nicholas Piggin > Sent: 16 September 2016 12:52 > On Fri, 16 Sep 2016 11:30:58 +0000 > David Laight <david.lai...@aculab.com> wrote: > > > From: Nicholas Piggin > > > Sent: 16 September 2016 09:58 > > > Implementing busy wait loops with cpu_relax(

RE: [PATCH][RFC] Implement arch primitives for busywait loops

From: Nicholas Piggin > Sent: 16 September 2016 09:58 > Implementing busy wait loops with cpu_relax() in callers poses > some difficulties for powerpc. > > First, we want to put our SMT thread into a low priority mode for the > duration of the loop, but then return to normal priority after

RE: [Linux-ima-devel] [PATCH 1/7] ima: on soft reboot, restore the measurement list

From: Linuxppc-dev [mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org] On Behalf Of > > > So given what you have above, you'd use something like: > > > > > > struct ima_kexec_hdr { > > > u16 version; > > > u16 _reserved0; > > > u32 _reserved1; > > > u64 buffer_size; >

RE: [PATCH 1/7] ima: on soft reboot, restore the measurement list

From: Thiago Jung Bauermann > Sent: 09 August 2016 14:19 ... > > > > +/* Some details preceding the binary serialized measurement list */ > > > > +struct ima_kexec_hdr { > > > > + unsigned short version; > > > > + unsigned long buffer_size; > > > > + unsigned long count; > > > >

RE: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

From: Arnd Bergmann > Sent: 08 August 2016 16:13 > > On Monday, August 8, 2016 2:49:11 PM CEST David Laight wrote: > > > > > If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always > > > return 0. it'll not call ucc_fast_free for any failure. Insi

RE: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Arvind Yadav > IS_ERR_VALUE() assumes that parameter is an unsigned long. > It can not be used to check if 'unsigned int' is passed insted. > Which tends to reflect an error. > In 64bit architectures sizeof

RE: [v5.1] ucc_fast: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

From: Arvind Yadav > Sent: 04 August 2016 17:53 > IS_ERR_VALUE() assumes that parameter is an unsigned long. > It can not be used to check if 'unsigned int' is passed insted. > Which tends to reflect an error. > In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8. > IS_ERR_VALUE(x) is

RE: [PATCH] cxl: Use fixed width predefined types in data structure.

From: Philippe Bergheaud > Sent: 04 August 2016 14:56 > This patch fixes a regression introduced by commit b810253. > It substitutes the type __u8 to u8 in the uapi header cxl.h, > because the latter is not always defined in userland build > environments, in particular when cross-compiling libcxl

RE: [v3] UCC_GETH/UCC_FAST: Use IS_ERR_VALUE_U32 API to avoid IS_ERR_VALUE abuses.

From: Arvind Yadav > Sent: 23 July 2016 19:06 > IS_ERR_VALUE() assumes that its parameter is an unsigned long. > It can not be used to check if an 'unsigned int' reflects an error. > As they pass an 'unsigned int' into a function that takes an > 'unsigned long' argument. This happens to work

RE: [PATCH v3 02/11] mm: Hardened usercopy

From: Josh Poimboeuf > Sent: 22 July 2016 18:46 .. > > >> +/* > > >> + * Checks if a given pointer and length is contained by the current > > >> + * stack frame (if possible). > > >> + * > > >> + * 0: not at all on the stack > > >> + * 1: fully within a valid stack frame > > >> + * 2: fully

RE: [PATCH 05/14] powerpc/pseries: 4GB exception handler offsets

From: Nicholas Piggin > Sent: 21 July 2016 07:44 ... > @@ -739,7 +739,8 @@ kvmppc_skip_Hinterrupt: > * Ensure that any handlers that get invoked from the exception prologs > * above are below the first 64KB (0x1) of the kernel image because > * the prologs assemble the addresses of these

RE: [PATCH v3 00/11] mm: Hardened usercopy

From: Kees Cook > Sent: 20 July 2016 16:32 ... > Yup: that's exactly what it's doing: walking up the stack. :) Remind me to make sure all our customers run kernels with it disabled. David ___ Linuxppc-dev mailing list

RE: [PATCH] crypto: vmx - Ignore generated files

From: Paulo Flabiano Smorigo > Sent: 19 July 2016 14:36 > Ignore assembly files generated by the perl script. ... > diff --git a/drivers/crypto/vmx/.gitignore b/drivers/crypto/vmx/.gitignore > new file mode 100644 > index 000..af4a7ce > --- /dev/null > +++ b/drivers/crypto/vmx/.gitignore > @@

RE: [RFC 3/3] kexec: extend kexec_file_load system call

From: Dave Young > On 07/15/16 at 02:19pm, Mark Rutland wrote: > > On Fri, Jul 15, 2016 at 09:09:55AM -0400, Vivek Goyal wrote: > > > On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote: > > > > > > [..] > > > > -SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd, > > > >

RE: [PATCH v3 00/11] mm: Hardened usercopy

From: Kees Cook > Sent: 15 July 2016 22:44 > This is a start of the mainline port of PAX_USERCOPY[1]. ... > - if address range is in the current process stack, it must be within the > current stack frame (if such checking is possible) or at least entirely > within the current process's stack.

RE: [PATCH for-4.8 03/12] powerpc/mm: use _raw variant of page table accessors

From: Aneesh Kumar K.V > Sent: 13 July 2016 10:35 > > This switch few of the page table accessor to use the __raw variant > and does the cpu to big endian conversion of constants. This helps in > generating better code. It might be better to say that checks for a value being 0 don't depend on

RE: [PATCH 1/2] crypto: vmx - Adding asm subroutines for XTS

From: Paulo Flabiano Smorigo > Sent: 11 July 2016 20:08 > > This patch add XTS subroutines using VMX-crypto driver. > > It gives a boost of 20 times using XTS. > > These code has been adopted from OpenSSL project in collaboration > with the original author (Andy Polyakov ).

RE: [PATCH] Need proper type casting before assignment, Remove compilation Warning.

From: Arvind Yadav > Sent: 07 July 2016 19:38 > -Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to > assigned in ucc_fast_tx_virtual_fifo_base_offset and > ucc_fast_rx_virtual_fifo_base_offset. These variable are 'unsigned int'. > So before assginment need a proper type

RE: [PATCH 3/4] perf annotate: add powerpc support

From: Ravi Bangoria > Sent: 28 June 2016 12:37 > > Powerpc has long list of branch instructions and hardcoding them in table > appears to be error-prone. So, add new function to find instruction > instead of creating table. > > Signed-off-by: Naveen N. Rao >

RE: [PATCH v2] cpuidle: Fix last_residency division

From: Arnd Bergmann > Sent: 24 June 2016 20:43 > On Friday, June 24, 2016 9:31:35 PM CEST Shreyas B Prabhu wrote: > > > If those functions are called less often than cpuidle_enter_state(), > > > we could just move the division there. Since the divisor is constant, > > > do_div() can convert it

RE: [PATCH v2] cpuidle: Fix last_residency division

From: Shreyas B. Prabhu > Sent: 24 June 2016 09:24 > > Snooze is a poll idle state in powernv and pseries platforms. Snooze > has a timeout so that if a cpu stays in snooze for more than target > residency of the next available idle state, then it would exit thereby > giving chance to the cpuidle

RE: livepatch: change to a per-task consistency model

From: Jiri Kosina > Sent: 23 May 2016 19:45 > > Related, please can we have a flag for the sleep and/or process so that > > an uninterruptible sleep doesn't trigger the 'hung task' detector > > TASK_KILLABLE Not sure that does what I want. It appears to allow some 'kill' actions to wake the

RE: livepatch: change to a per-task consistency model

From: Jiri Kosina > Sent: 18 May 2016 21:23 > On Wed, 18 May 2016, Josh Poimboeuf wrote: > > > Yeah, I think this situation -- a task sleeping on an affected function > > in uninterruptible state for a long period of time -- would be > > exceedingly rare and not something we need to worry about

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: 13 May 2016 06:33 ... > Simply denying direct writes to the vector table or preventing mapping > of the vector table into the user address space does not provide any > tangible form of protection. Many devices make use of window

RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

From: Tian, Kevin > Sent: 05 May 2016 10:37 ... > > Acutually, we are not aimed at accessing MSI-X table from > > guest. So I think it's safe to passthrough MSI-X table if we > > can make sure guest kernel would not touch MSI-X table in > > normal code path such as para-virtualized guest kernel on

RE: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

From: Andy Lutomirski > Sent: 02 May 2016 19:13 ... > I hope your plans include rewriting the current stack unwinder > completely. The thing in print_context_stack is (a) > hard-to-understand and hard-to-modify crap and (b) is called in a loop > from another file using totally ridiculous

RE: [PATCH] powerpc: Add support for userspace P9 copy paste

From: Chris Smart > Sent: 28 April 2016 00:52 ... > >In that case what actually completes the copy? > >I think you'd need to be inside a 'restartable atomic sequence' > >in which case the cp_abort need only be done when the/a RAS > >block is detected. > > > >Or have I missed something?? > > It's

RE: [PATCH] powerpc: Add support for userspace P9 copy paste

From: Chris Smart > Sent: 26 April 2016 01:29 > The copy paste facility introduced in POWER9 provides an optimised > mechanism for a userspace application to copy a cacheline. This is > provided by a pair of instructions, copy and paste, while a third, > cp_abort (copy paste abort), provides a

RE: [PATCH v1 08/23] ata: sata_dwc_460ex: don't call ata_sff_qc_issue() on DMA commands

From: Andy Shevchenko > Sent: 21 April 2016 19:15 > ata_sff_qc_issue() can't handle DMA commands and thus we have to avoid it for > them. Do call ata_bmdma_qc_issue() instead for this case. > > Suggested-by: Christian Lamparter > Signed-off-by: Andy Shevchenko

RE: [RFC v6 06/10] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

From: Yongji Xie > Sent: 18 April 2016 11:59 > We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP > which indicates all devices on the bus are protected by the > hardware which supports IRQ remapping(intel naming). > > This flag will be used to know whether it's safe to expose > MSI-X

RE: [PATCH] powerpc/config: Disable the 4KiB erase granularity of SPI flash

From: Zhiqiang Hou > Sent: 07 April 2016 04:17 ... > > Is there a reason specific to 85xx to have a different default than every > > other > > platform except lpc18xx? The description of MTD_SPI_NOR_USE_4K_SECTORS > > acknowledges that erase speed is a tradeoff. Why is that concern more > >

RE: [PATCH v2 2/4] lib: update single-char callers of strtobool

From: Kees Cook > Sent: 04 February 2016 21:01 > Some callers of strtobool were passing a pointer to unterminated strings. > In preparation of adding multi-character processing to kstrtobool, update > the callers to not pass single-character pointers, and switch to using the > new

RE: [RFC PATCH v3 3/5] PCI: Add host bridge attribute to indicate filtering of MSIs is supported

From: Yongji Xie > Sent: 15 January 2016 07:06 > > MSI-X tables are not allowed to be mmapped in vfio-pci > driver in case that user get to touch this directly. > This will cause some performance issues when when PCI > adapters have critical registers in the same page as > the MSI-X table. ... If

RE: cxl: Fix DSI misses when the context owning task exits

From: Vaibhav Jain > Sent: 14 January 2016 07:51 > David Laight <david.lai...@aculab.com> writes: > > > I don't even claim to understand the linux model for handling process > > address maps, nor what the cxl driver is doing, but the above looks > > more than dod

RE: cxl: Fix DSI misses when the context owning task exits

From: Michael Ellerman > Sent: 11 January 2016 09:14 > On Tue, 2015-24-11 at 10:56:18 UTC, Vaibhav Jain wrote: > > Presently when a user-space process issues CXL_IOCTL_START_WORK ioctl we > > store the pid of the current task_struct and use it to get pointer to > > the mm_struct of the process,

RE: Build failure: -Wno-unused-const-variable DNE on old GCC

From: Michael Ellerman > Sent: 08 January 2016 02:17 > > I doubt you plan to fix all those. So making -Werror configurable seems like > > the only way forward, then. (Glad you agreed!) > > Yep, I'm happy to make Werror configurable. > > cxl can probably just use the existing PPC_WERROR.

RE: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

From: Alex Williamson > Sent: 17 December 2015 21:07 ... > > Is this all related to the statements in the PCI(e) spec that the > > MSI-X table and Pending bit array should in their own BARs? > > (ISTR it even suggests a BAR each.) > > > > Since the MSI-X table exists in device memory/registers

RE: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

> The MSI-X table is paravirtualized on vfio in general and interrupt > remapping theoretically protects against errant interrupts, so why is > this PPC64 specific? We have the same safeguards on x86 if we want to > decide they're sufficient. Offhand, the only way I can think that a > device can

RE: [PATCH v2 3/5] printk/nmi: Try hard to print Oops message in NMI context

From: Russell King - ARM Linux > Sent: 04 December 2015 17:13 ... > I have a slightly different view... > > > > I don't see bust_spinlocks() dealing with any of these locks, so IMHO > > > trying to make this work in NMI context strikes me as making the > > > existing solution more unreliable on

RE: [PATCH v2 5/5] printk/nmi: Increase the size of the temporary buffer

From: yalin wang > Sent: 30 November 2015 16:42 > > On Nov 27, 2015, at 19:09, Petr Mladek wrote: > > > > Testing has shown that the backtrace sometimes does not fit > > into the 4kB temporary buffer that is used in NMI context. > > > > The warnings are gone when I double the

RE: [PATCH 0/8] FP/VEC/VSX switching optimisations

From: Cyril Bur > Sent: 18 November 2015 03:27 ... > The goal of these patches is to rework how the 'math' registers (FP, VEC > and VSX) are context switched. Currently the kernel adopts a lazy approach, > always switching userspace tasks with all three facilities disabled and > loads in each set

RE: [PATCH] of: Print rather than WARN'ing when overlap check fails

From: Michael Ellerman > Sent: 10 November 2015 05:09 > __rmem_check_for_overlap() is called very early in boot, and on some > powerpc systems it's not safe to call WARN that early in boot. > > If the overlap check fails the system will oops instead of printing a > warning. Furthermore because

RE: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

From: Paul E. McKenney > Sent: 21 October 2015 00:35 ... > There is also the question of whether the barrier forces ordering > of unrelated stores, everything initially zero and all accesses > READ_ONCE() or WRITE_ONCE(): > > P0 P1 P2 P3 > X = 1;

RE: [PATCH V5 1/6] powerpc/powernv: don't enable SRIOV when VF BAR has non 64bit-prefetchable BAR

From: Benjamin Herrenschmidt > Sent: 09 October 2015 09:15 > On Fri, 2015-10-09 at 10:46 +0800, Wei Yang wrote: > > On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If > > a SRIOV device's IOV BAR is not 64bit-prefetchable, this is not assigned > > from 64bit prefetchable

RE: [PATCH v2 08/25] powerpc/8xx: Map IMMR area with 512k page at a fixed address

From: Scott Wood > Sent: 24 September 2015 21:14 > > Isn't this a more general problem? > > > > If there are multiple remap requests for the same physical page > > shouldn't the kernel be just increasing a reference count somewhere > > and returning address in the same virtual page? > > This

RE: [PATCH v2 08/25] powerpc/8xx: Map IMMR area with 512k page at a fixed address

From: Christophe Leroy > Sent: 22 September 2015 17:51 ... > Traditionaly, each driver manages one computer board which has its > own components with its own memory maps. > But on embedded chips like the MPC8xx, the SOC has all registers > located in the same IO area. > > When looking at ioremaps

RE: [PATCH v2 12/30] cxlflash: Refine host/device attributes

From: Brian King > Sent: 18 September 2015 22:35 ... > > + for (i = 0; i < CXLFLASH_NUM_VLUNS; i++, buf += 22) > > Rather than this bug prone hard coded 22, how about never incrementing buf > and do something > similar to this: > > > + bytes += scnprintf(buf, PAGE_SIZE, "%03d:

RE: [PATCH v2 09/30] cxlflash: Fix to stop interrupt processing on remove

From: Linuxppc-dev Matthew R. Ochs > Sent: 16 September 2015 22:28 > Interrupt processing can run in parallel to a remove operation. This > can lead to a condition where the interrupt handler is processing with > memory that has been freed. > > To avoid processing an interrupt while memory may be

RE: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

From: Segher Boessenkool > Sent: 17 September 2015 04:19 > On Thu, Sep 17, 2015 at 12:50:12PM +1000, Michael Ellerman wrote: > > On Wed, 2015-09-16 at 21:54 -0400, Steven Rostedt wrote: > > > This could be a symptom and not the problem. What the above shows is > > > that ftrace tried to convert

RE: [PATCH 2/3] drivers/ps3: Fix ps3-vuart null dereference

From: Colin Ian King > Sent: 14 September 2015 20:35 > On the unlikely event that drv is null, the current code will > perform a null pointer dereference with it when printing a dev_dbg > message. Instead, the BUG_ON check on drv should be performed > before we emit the dev_dbg message. ... >

RE: memcpy regression

> > What about run-time patching memcpy() after the caches are initialised? > > Yeah, that's the solution we use on 64-bit. > > It also means you can have cpu specific optimisations, which can be patched in > or out using the cpu feature patching. I've noticed x86 doing that. For newer Intel

RE: memcpy regression

From: Michal Sojka > >> I think GCC uses memcpy() in well known situations like initialising > >> structures or copying structures. > >> Shouldn't we just avoid this kind of actions in the very few early init > >> functions ? > > Which are the "very few" early init functions? Can you make a list,

RE: [PATCH] powerpc32: memcpy: only use dcbz once cache is enabled

From: Christophe Leroy > Sent: 07 September 2015 15:25 ... > diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S > index 2ef50c6..05b3096 100644 > --- a/arch/powerpc/lib/copy_32.S > +++ b/arch/powerpc/lib/copy_32.S > @@ -172,7 +172,16 @@ _GLOBAL(memcpy) > mtctr r0 >

RE: [PATCH v2 05/10] cxl: Refactor adaptor init/teardown

From: Cyril Bur Sent: 11 August 2015 07:01 ... You have a dilema with the use of ugly if (rc = foo()). I don't like it but the file is littered with it. Looks like the majority of uses in this file the conditional block is only one line then it makes sense (or at least in terms of numbers

RE: [PATCH] powerpc/hvsi: Fix endianness issues in the HVSI driver

From: Laurent Dufour Sent: 31 July 2015 10:30 This patch fixes several endianness issues detected when running the HVSI driver in little endian mode. These issues are raised in little endian mode because the data exchanged in memory between the kernel and the hypervisor has to be in big

RE: [PATCH v5 02/46] usb: gadget: add endpoint capabilities flags

From: Robert Baldyga Sent: 31 July 2015 15:00 Introduce struct usb_ep_caps which contains information about capabilities of usb endpoints - supported transfer types and directions. This structure should be filled by UDC driver for each of its endpoints, and will be used in epautoconf in new

RE: [PATCH v3 2/2] powerpc: add support for csum_add()

From: Scott Wood Sent: 26 May 2015 20:43 ... I was thinking of all 64bit targets, not 32bit ones. Oh, you mean move it out of arch/powerpc? Sounds reasonable, but someone should probably check what the resulting code looks like on other common arches. OTOH, if we're going to modify

RE: [PATCH v3 2/2] powerpc: add support for csum_add()

From: Scott Wood ... I'd also have thought that the 64bit C version above would be generally 'good'. It doesn't generate the addc/addze sequence. At least with GCC 4.8.2, it does something like: mr tmp0, csum li tmp1, 0 li tmp2, 0 addc

RE: [PATCH v3 2/2] powerpc: add support for csum_add()

From: Linuxppc-dev Christophe Leroy Sent: 19 May 2015 16:19 ... diff --git a/arch/powerpc/include/asm/checksum.h b/arch/powerpc/include/asm/checksum.h index 5e43d2d..e8d9ef4 100644 --- a/arch/powerpc/include/asm/checksum.h +++ b/arch/powerpc/include/asm/checksum.h @@ -130,6 +130,22 @@

RE: [PATCH v2 0/6] powerpc32: replace memcpy and memset by cacheable alternatives

From: Christophe Leroy Sent: 19 May 2015 11:08 This patchset implements use of cacheable versions of memset and memcpy since when the destination is not cacheable, memset_io and memcpy_toio are used. This isn't the right list to ask, but: Can someone fix the x86 versions of memset/memcpy

RE: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure

From: Thomas Gleixner Sent: 22 April 2015 09:45 On Tue, 21 Apr 2015, Thomas Gleixner wrote: On Tue, 21 Apr 2015, Arnd Bergmann wrote: I know there are concerns about this, in particular because C11 and POSIX both require tv_nsec to be 'long', unlike timeval-tv_usec, which is a

RE: [PATCH 07/11] powerpc/8xx: macro for handling CPU15 errata

From: Christophe Leroy Sent: 20 April 2015 06:27 Having a macro will help keep clear code. ... * We have to use the MD_xxx registers for the tablewalk because the * equivalent MI_xxx registers only perform the attribute functions. */ + +#ifdef CONFIG_8xx_CPU15 +#define

RE: [PATCH v3 03/17] crypto: talitos - talitos_ptr renamed ptr for more lisibility

From: Christophe Leroy Linux CodyingStyle recommends to use short variables for local variables. ptr is just good enough for those 3 lines functions. It helps keep single lines shorter than 80 characters. ... -static void to_talitos_ptr(struct talitos_ptr *talitos_ptr, dma_addr_t dma_addr)

RE: [PATCH v8 RFC 1/3] sparc: Break up monolithic iommu table/lock into finer graularity pools and lock

From: Sowmini Varadhan Investigation of multithreaded iperf experiments on an ethernet interface show the iommu-lock as the hottest lock identified by lockstat, with something of the order of 21M contentions out of 27M acquisitions, and an average wait time of 26 us for the lock. This is not

RE: [PATCHv2] powerpc: comvert relocs_check to a shell script using grep

From: Stephen Rothwell This runs a bit faster and removes another use of perl from the kernel build. ... diff --git a/arch/powerpc/relocs_check.sh b/arch/powerpc/relocs_check.sh new file mode 100755 index ..182eae9cc40d --- /dev/null +++ b/arch/powerpc/relocs_check.sh @@ -0,0

RE: [PATCH v1 1/3] SHA1 for PPC/SPE - assembler

From: Markus Stockhausen [PATCH v1 1/3] SHA1 for PPC/SPE - assembler This is the assembler code for SHA1 implementation with the SIMD SPE instruction set. With the enhanced instruction set we can operate on 2 32 bit words in parallel. That helps reducing the time to calculate W16-W79. For

RE: [PATCH 1/7] Add die_spin_lock_{irqsave,irqrestore}

From: Ingo Molnar ... So why not trylock and time out here after a few seconds, instead of indefinitely supressing some potentially vital output due to some other CPU crashing/locking with the lock held? I've used that for status requests that usually lock a table to get a consistent view. If

RE: [PATCH v1 2/7] AES for PPC/SPE - aes tables

From: Markus Stockhausen 4K AES tables for big endian I can't help feeling that you could give more information about how the values are generated. ... + * These big endian AES encryption/decryption tables are designed to be simply + * accessed by a combination of rlwimi/lwz instructions

RE: [PATCH 0/5] powerpc: Get rid of redundant arch specific swab functions

From: David Gibson arch/powerpc/include/asm/swab.h includes some powerpc specific byteswapping functions, which are implemented in terms of powerpc's built in byte reversed load/store instructions. There are two problems with this: 1) They're not necessary - gcc is perfectly capable of

RE: [PATCH v2 07/11] powerpc/8xx: macro for handling CPU15 errata

From Christophe Leroy Having a macro will help keep clear code. It might remove an #if but it doesn't really help. All it means is that anyone reading the code has to hunt for the definition before proceeding. Some comment about what (and why) the extra code is needed might help. ... +

RE: [PATCH v2 07/11] powerpc/8xx: macro for handling CPU15 errata

From: leroy Le 20/01/2015 12:09, David Laight a écrit : From Christophe Leroy Having a macro will help keep clear code. It might remove an #if but it doesn't really help. All it means is that anyone reading the code has to hunt for the definition before proceeding. Some comment

RE: [PATCH 1/2] powerpc: Add 64bit optimised memcmp

From: Joakim Tjernlund On Mon, 2015-01-12 at 11:55 +1100, Anton Blanchard wrote: Hi David, The unrolled loop (deleted) looks excessive. On a modern cpu with multiple execution units you can usually manage to get the loop overhead to execute in parallel to the actual 'work'. So

RE: [PATCH 1/2] powerpc: Add 64bit optimised memcmp

From: Anton Blanchard I noticed ksm spending quite a lot of time in memcmp on a large KVM box. The current memcmp loop is very unoptimised - byte at a time compares with no loop unrolling. We can do much much better. Optimise the loop in a few ways: - Unroll the byte at a time loop -

RE: [PATCH 05/11] powerpc/8xx: Optimise access to swapper_pg_dir

On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote: All accessed to PGD entries are done via 0(r11). By using lower part of swapper_pg_dir as load index to r11, we can remove the ori instruction. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr Nice :) Acked-by:

RE: [PATCH 05/11] powerpc/8xx: Optimise access to swapper_pg_dir

From: leroy christophe Le 06/01/2015 13:08, David Laight a écrit : On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote: All accessed to PGD entries are done via 0(r11). By using lower part of swapper_pg_dir as load index to r11, we can remove the ori instruction. Signed-off

RE: [RFC PATCH 0/2] powerpc: CR based local atomic operation implementation

From: Rusty Russell David Laight david.lai...@aculab.com writes: From: Madhavan Srinivasan [mailto:ma...@linux.vnet.ibm.com] ... I also wonder if it is possible to inspect the interrupted code to determine the start/end of the RAS block. (Easiest if you assume that there is a single

RE: [PATCH] powerpc/kernel: Make syscall_exit a local label

From: Michael Ellerman Currently when we back trace something that is in a syscall we see something like this: [c000] [c000] SyS_read+0x6c/0x110 [c000] [c000] syscall_exit+0x0/0x98 Although it's entirely correct, seeing syscall_exit at the

RE: [RFC PATCH 0/2] powerpc: CR based local atomic operation implementation

From: Madhavan Srinivasan [mailto:ma...@linux.vnet.ibm.com] ... I also wonder if it is possible to inspect the interrupted code to determine the start/end of the RAS block. (Easiest if you assume that there is a single 'write' instruction as the last entry in the block.) So each

RE: [RFC PATCH 0/2] powerpc: CR based local atomic operation implementation

From: Madhavan Srinivasan On Thursday 27 November 2014 07:35 PM, David Laight wrote: From: Madhavan Srinivasan This patchset create the infrastructure to handle the CR based local_* atomic operations. Local atomic operations are fast and highly reentrant per CPU counters. Used for percpu

RE: [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t

From: Benjamin Herrenschmidt On Fri, 2014-11-28 at 08:45 +0530, Madhavan Srinivasan wrote: Can't we just unconditionally clear at as long as we do that after we've saved it ? In that case, it's just a matter for the fixup code to check the saved version rather than the actual CR.. I

RE: [RFC PATCH 0/2] powerpc: CR based local atomic operation implementation

From: Madhavan Srinivasan This patchset create the infrastructure to handle the CR based local_* atomic operations. Local atomic operations are fast and highly reentrant per CPU counters. Used for percpu variable updates. Local atomic operations only guarantee variable modification atomicity

RE: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

From: David Hildenbrand ... Although it might not be optimal, but keeping a separate counter for pagefault_disable() as part of the preemption counter seems to be the only doable thing right now. I am not sure if a completely separated counter is even possible, increasing the size of

<    1   2   3   4   5   6   >