Re: [PATCH v9 5/8] ima: make process_buffer_measurement() generic

On Fri, 2019-10-25 at 10:32 -0700, Lakshmi Ramasubramanian wrote: > > On 10/25/2019 10:24 AM, Nayna Jain wrote: > > > > On 10/24/19 10:20 AM, Lakshmi Ramasubramanian wrote: > >> On 10/23/19 8:47 PM, Nayna Jain wrote: > >> > >> Hi Nayna, > >> > >>> +void process_buffer_measurement(const void

Re: [PATCH v9 2/8] powerpc/ima: add support to initialize ima policy rules

On Fri, 2019-10-25 at 12:02 -0500, Nayna Jain wrote: > On 10/24/19 12:35 PM, Lakshmi Ramasubramanian wrote: > > On 10/23/2019 8:47 PM, Nayna Jain wrote: > > > >> +/* > >> + * The "secure_rules" are enabled only on "secureboot" enabled systems. > >> + * These rules verify the file signatures

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

On Sat, Oct 26, 2019 at 08:48:27PM +0200, Thomas Gleixner wrote: > On Sat, 26 Oct 2019, Christophe Leroy wrote: > Let's look at the code: > > __cvdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz) > { > const struct vdso_data *vd = __arch_get_vdso_data(); > >

[Bug 205327] kmemleak reports various leaks in "swapper/0"

https://bugzilla.kernel.org/show_bug.cgi?id=205327 --- Comment #2 from Erhard F. (erhar...@mailbox.org) --- Created attachment 285661 --> https://bugzilla.kernel.org/attachment.cgi?id=285661=edit dmesg (kernel 5.4.0-rc4, PowerMac G5 7,3) -- You are receiving this mail because: You are

[Bug 205327] kmemleak reports various leaks in "swapper/0"

https://bugzilla.kernel.org/show_bug.cgi?id=205327 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 285659 --> https://bugzilla.kernel.org/attachment.cgi?id=285659=edit 5.4.0-rc4 kernel .config (PowerMac G5 7,3) -- You are receiving this mail because: You are

[Bug 205327] New: kmemleak reports various leaks in "swapper/0"

https://bugzilla.kernel.org/show_bug.cgi?id=205327 Bug ID: 205327 Summary: kmemleak reports various leaks in "swapper/0" Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.4-rc4 Hardware: PPC-64 OS: Linux

[PATCH RESEND v14 6/6] Documentation: path-lookup: mention LOOKUP_MAGICLINK_JUMPED

Now that we have a special flag to signify magic-link jumps, mention it within the path-lookup docs. And now that "magic link" is the correct term for nd_jump_link()-style symlinks, clean up references to this type of "symlink". Signed-off-by: Aleksa Sarai ---

[PATCH RESEND v14 5/6] selftests: add openat2(2) selftests

Test all of the various openat2(2) flags. A small stress-test of a symlink-rename attack is included to show that the protections against ".."-based attacks are sufficient. The main things these self-tests are enforcing are: * The struct+usize ABI for openat2(2) and copy_struct_from_user() to

[PATCH RESEND v14 4/6] open: introduce openat2(2) syscall

/* Background. */ For a very long time, extending openat(2) with new features has been incredibly frustrating. This stems from the fact that openat(2) is possibly the most famous counter-example to the mantra "don't silently accept garbage from userspace" -- it doesn't check whether unknown flags

[PATCH RESEND v14 3/6] namei: permit ".." resolution with LOOKUP_{IN_ROOT, BENEATH}

This patch allows for LOOKUP_BENEATH and LOOKUP_IN_ROOT to safely permit ".." resolution (in the case of LOOKUP_BENEATH the resolution will still fail if ".." resolution would resolve a path outside of the root -- while LOOKUP_IN_ROOT will chroot(2)-style scope it). Magic-link jumps are still

[PATCH RESEND v14 2/6] namei: LOOKUP_IN_ROOT: chroot-like path resolution

/* Background. */ Container runtimes or other administrative management processes will often interact with root filesystems while in the host mount namespace, because the cost of doing a chroot(2) on every operation is too prohibitive (especially in Go, which cannot safely use vfork). However, a

[PATCH RESEND v14 1/6] namei: O_BENEATH-style resolution restriction flags

/* Background. */ The need for some sort of control over VFS's path resolution (to avoid malicious paths resulting in inadvertent breakouts) has been a very long-standing desire of many userspace applications throughout the history of Unix. While some improvements have been made (such as

[PATCH RESEND v14 0/6] open: introduce openat2(2) syscall

This patchset is being developed here: Patch changelog: v14: [] * The magic-link changes (and O_EMPTYPATH) have been dropped from this series -- they will be

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

On Sat, 26 Oct 2019, Christophe Leroy wrote: > Le 26/10/2019 à 17:53, Thomas Gleixner a écrit : > > > > > > gettimeofday:    vdso: 750 nsec/call > > > > > > > > > > > > gettimeofday:    vdso: 1533 nsec/call > > > > > > > > Small improvement (3%) with the proposed change: > > > > > > > >

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

Le 26/10/2019 à 17:53, Thomas Gleixner a écrit : On Tue, 22 Oct 2019, Christophe Leroy wrote: Le 22/10/2019 à 11:01, Christophe Leroy a écrit : Le 21/10/2019 à 23:29, Thomas Gleixner a écrit : On Mon, 21 Oct 2019, Christophe Leroy wrote: This is a tentative to switch powerpc/32 vdso to

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

Le 26/10/2019 à 15:55, Andy Lutomirski a écrit : On Tue, Oct 22, 2019 at 6:56 AM Christophe Leroy wrote: The performance is rather disappoiting. That's most likely all calculation in the C implementation are based on 64 bits math and converted to 32 bits at the very end. I guess C

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

On Tue, 22 Oct 2019, Christophe Leroy wrote: > Le 22/10/2019 à 11:01, Christophe Leroy a écrit : > > Le 21/10/2019 à 23:29, Thomas Gleixner a écrit : > > > On Mon, 21 Oct 2019, Christophe Leroy wrote: > > > > > > > This is a tentative to switch powerpc/32 vdso to generic C > > > > implementation.

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

On Tue, Oct 22, 2019 at 6:56 AM Christophe Leroy wrote: > > > >>> The performance is rather disappoiting. That's most likely all > >>> calculation in the C implementation are based on 64 bits math and > >>> converted to 32 bits at the very end. I guess C implementation should > >>> use 32 bits

[PATCH AUTOSEL 4.19 40/59] net/ibmvnic: Fix EOI when running in XIVE mode.

From: Cédric Le Goater [ Upstream commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab ] pSeries machines on POWER9 processors can run with the XICS (legacy) interrupt mode or with the XIVE exploitation interrupt mode. These interrupt contollers have different interfaces for interrupt management :

[PATCH AUTOSEL 5.3 58/99] net/ibmvnic: Fix EOI when running in XIVE mode.

From: Cédric Le Goater [ Upstream commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab ] pSeries machines on POWER9 processors can run with the XICS (legacy) interrupt mode or with the XIVE exploitation interrupt mode. These interrupt contollers have different interfaces for interrupt management :

Re: loop nesting in alignment exception and machine check

Hi, Le 26/10/2019 à 09:23, Wangshaobo (bobo) a écrit : Hi, I encountered a problem about a loop nesting occurred in manufacturing the alignment exception in machine check, trigger background is : problem: machine checkout or critical interrupt ->…->kbox_write[for recording last words] ->

loop nesting in alignment exception and machine check

Hi, I encountered a problem about a loop nesting occurred in manufacturing the alignment exception in machine check, trigger background is : problem: machine checkout or critical interrupt ->...->kbox_write[for recording last words] -> memcpy(irremap_addr, src,size):_GLOBAL(memcpy)... when we

[PATCH] ide: remove set but not used variable 'hwif'

Fix the following gcc warning: drivers/ide/pmac.c: In function pmac_ide_setup_device: drivers/ide/pmac.c:1027:14: warning: variable hwif set but not used [-Wunused-but-set-variable] Fixes: d58b0c39e32f ("powerpc/macio: Rework hotplug media bay support") Reported-by: Hulk Robot Signed-off-by:

Re: [PATCH 10/10] ocxl: Conditionally bind SCM devices to the generic OCXL driver

On Fri, Oct 25, 2019 at 03:47:05PM +1100, Alastair D'Silva wrote: > From: Alastair D'Silva > > This patch allows the user to bind OpenCAPI SCM devices to the generic OCXL > driver. This completely misses any explanation of why you'd want that. The what is rather obvious from the patch. >

Re: Onboard SD card doesn't work anymore after the 'mmc-v5.4-2' updates

On Fri, Oct 25, 2019 at 05:28:45PM -0500, Rob Herring wrote: > This doesn't work?: > > if (IS_ENABLED(CONFIG_PPC) || of_dma_is_coherent(dev->of_node)) > value |= ESDHC_DMA_SNOOP; > else > value &= ~ESDHC_DMA_SNOOP; > > While I said use the