Re: [PATCH] bitfield: Use __ffs64(x) to fix missing __ffsdi2()

Hi Geert, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc4] [cannot apply to next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] bitfield: Use __ffs64(x) to fix missing __ffsdi2()

Hi Geert, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc4] [cannot apply to next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 2/3] Input: allow matching device IDs on property bits

Let's allow matching input devices on their property bits, both in-kernel and when generating module aliases. Signed-off-by: Dmitry Torokhov --- drivers/input/input.c | 3 ++- include/linux/input.h | 4 include/linux/mod_devicetable.h |

[PATCH 2/3] Input: allow matching device IDs on property bits

Let's allow matching input devices on their property bits, both in-kernel and when generating module aliases. Signed-off-by: Dmitry Torokhov --- drivers/input/input.c | 3 ++- include/linux/input.h | 4 include/linux/mod_devicetable.h | 3 +++

[PATCH 3/3] Input: joydev - blacklist ds3/ds4/udraw motion sensors

From: Roderick Colenbrander Introduce a device table used for blacklisting devices. We currently blacklist the motion sensor subdevice of THQ Udraw and Sony ds3/ds4. Signed-off-by: Roderick Colenbrander Signed-off-by: Dmitry

[PATCH 3/3] Input: joydev - blacklist ds3/ds4/udraw motion sensors

From: Roderick Colenbrander Introduce a device table used for blacklisting devices. We currently blacklist the motion sensor subdevice of THQ Udraw and Sony ds3/ds4. Signed-off-by: Roderick Colenbrander Signed-off-by: Dmitry Torokhov --- drivers/input/joydev.c | 70

Re: [PATCH 2/5] trace-cmd: Fix NULL pointer being passed to memcpy

On Mon, 9 Oct 2017 16:27:10 -0600 Michael Sartain wrote: > > > - memcpy(option->data, data, size); > > > + > > > + /* Some IDs (like TRACECMD_OPTION_TRACECLOCK) pass NULL data */ > > > + if (data) > > > + memcpy(option->data, data, size); > > > > Is this a

[PATCH 1/3] Input: factor out and export input_device_id matching code

Factor out and export input_match_device_id() so that modules may use it. It will be needed by joydev to blacklist accelerometers in composite devices. Signed-off-by: Dmitry Torokhov --- drivers/input/input.c | 83 +++

Re: [PATCH 2/5] trace-cmd: Fix NULL pointer being passed to memcpy

On Mon, 9 Oct 2017 16:27:10 -0600 Michael Sartain wrote: > > > - memcpy(option->data, data, size); > > > + > > > + /* Some IDs (like TRACECMD_OPTION_TRACECLOCK) pass NULL data */ > > > + if (data) > > > + memcpy(option->data, data, size); > > > > Is this a problem, as when this

[PATCH 1/3] Input: factor out and export input_device_id matching code

Factor out and export input_match_device_id() so that modules may use it. It will be needed by joydev to blacklist accelerometers in composite devices. Signed-off-by: Dmitry Torokhov --- drivers/input/input.c | 83 +++ include/linux/input.h | 3

Re: [PATCH 5/5] trace-cmd: Remove unused view_width variable

On Sat, 12 Aug 2017 11:30:47 -0600 Michael Sartain wrote: This is an annoying warning, but I've kept from doing this because it reminds me that I have an idea to actually use that variable someday. But I've just been procrastinating on doing that. ;-) -- Steve >

Re: [PATCH 5/5] trace-cmd: Remove unused view_width variable

On Sat, 12 Aug 2017 11:30:47 -0600 Michael Sartain wrote: This is an annoying warning, but I've kept from doing this because it reminds me that I have an idea to actually use that variable someday. But I've just been procrastinating on doing that. ;-) -- Steve > Signed-off-by: Michael

Re: [PATCH 4/5] trace-cmd: Use unsigned values in Hsieh's trace_hash fast hash function

On Sat, 12 Aug 2017 11:30:46 -0600 Michael Sartain wrote: > Signed int values were being used where the original code used uint32_t types: > > http://www.azillionmonkeys.com/qed/hash.html > > Right shifting negative int values has implementation-defined and left >

Re: [PATCH 4/5] trace-cmd: Use unsigned values in Hsieh's trace_hash fast hash function

On Sat, 12 Aug 2017 11:30:46 -0600 Michael Sartain wrote: > Signed int values were being used where the original code used uint32_t types: > > http://www.azillionmonkeys.com/qed/hash.html > > Right shifting negative int values has implementation-defined and left > shifting > has undefined

Re: [PATCH v2 0/5] Switch arm64 over to qrwlock

Hi, On 10/06/2017 08:34 AM, Will Deacon wrote: Hi all, This is version two of the patches I posted yesterday: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/534666.html I'd normally leave it longer before posting again, but Peter had a good suggestion to rework the

Re: [PATCH v2 0/5] Switch arm64 over to qrwlock

Hi, On 10/06/2017 08:34 AM, Will Deacon wrote: Hi all, This is version two of the patches I posted yesterday: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/534666.html I'd normally leave it longer before posting again, but Peter had a good suggestion to rework the

Re: [PATCH 3/5] trace-cmd: Add ULL suffix to MISSING_EVENTS since ints shouldn't be left shifted by 31

On Sat, 12 Aug 2017 11:30:45 -0600 Michael Sartain wrote: > Signed-off-by: Michael Sartain > --- > kbuffer-parse.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kbuffer-parse.c b/kbuffer-parse.c > index

Re: [PATCH 3/5] trace-cmd: Add ULL suffix to MISSING_EVENTS since ints shouldn't be left shifted by 31

On Sat, 12 Aug 2017 11:30:45 -0600 Michael Sartain wrote: > Signed-off-by: Michael Sartain > --- > kbuffer-parse.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kbuffer-parse.c b/kbuffer-parse.c > index 4e6e95e..dde642c 100644 > --- a/kbuffer-parse.c > +++

Re: [PATCH 2/5] trace-cmd: Fix NULL pointer being passed to memcpy

On Mon, Oct 09, 2017 at 06:24:32PM -0400, Steven Rostedt wrote: > On Sat, 12 Aug 2017 11:30:44 -0600 > Michael Sartain wrote: > > > Signed-off-by: Michael Sartain > > --- > > trace-output.c | 6 +- > > 1 file changed, 5 insertions(+), 1

Re: [PATCH 2/5] trace-cmd: Fix NULL pointer being passed to memcpy

On Mon, Oct 09, 2017 at 06:24:32PM -0400, Steven Rostedt wrote: > On Sat, 12 Aug 2017 11:30:44 -0600 > Michael Sartain wrote: > > > Signed-off-by: Michael Sartain > > --- > > trace-output.c | 6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/trace-output.c

Re: [PATCH 2/5] trace-cmd: Fix NULL pointer being passed to memcpy

On Sat, 12 Aug 2017 11:30:44 -0600 Michael Sartain wrote: > Signed-off-by: Michael Sartain > --- > trace-output.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/trace-output.c b/trace-output.c > index

Re: [PATCH 2/5] trace-cmd: Fix NULL pointer being passed to memcpy

On Sat, 12 Aug 2017 11:30:44 -0600 Michael Sartain wrote: > Signed-off-by: Michael Sartain > --- > trace-output.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/trace-output.c b/trace-output.c > index bfe6331..84b21b0 100644 > --- a/trace-output.c > +++

[PATCH v11 4/9] mm: defining memblock_virt_alloc_try_nid_raw

* A new variant of memblock_virt_alloc_* allocations: memblock_virt_alloc_try_nid_raw() - Does not zero the allocated memory - Does not panic if request cannot be satisfied * optimize early system hash allocations Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify

[PATCH v11 4/9] mm: defining memblock_virt_alloc_try_nid_raw

* A new variant of memblock_virt_alloc_* allocations: memblock_virt_alloc_try_nid_raw() - Does not zero the allocated memory - Does not panic if request cannot be satisfied * optimize early system hash allocations Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify

[PATCH v11 9/9] sparc64: optimized struct page zeroing

Add an optimized mm_zero_struct_page(), so struct page's are zeroed without calling memset(). We do eight to ten regular stores based on the size of struct page. Compiler optimizes out the conditions of switch() statement. SPARC-M6 with 15T of memory, single thread performance:

[PATCH v11 9/9] sparc64: optimized struct page zeroing

Add an optimized mm_zero_struct_page(), so struct page's are zeroed without calling memset(). We do eight to ten regular stores based on the size of struct page. Compiler optimizes out the conditions of switch() statement. SPARC-M6 with 15T of memory, single thread performance:

[PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

During early boot, kasan uses vmemmap_populate() to establish its shadow memory. But, that interface is intended for struct pages use. Because of the current project, vmemmap won't be zeroed during allocation, but kasan expects that memory to be zeroed. We are adding a new kasan_map_populate()

[PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

During early boot, kasan uses vmemmap_populate() to establish its shadow memory. But, that interface is intended for struct pages use. Because of the current project, vmemmap won't be zeroed during allocation, but kasan expects that memory to be zeroed. We are adding a new kasan_map_populate()

[PATCH v11 3/9] sparc64: simplify vmemmap_populate

Remove duplicating code by using common functions vmemmap_pud_populate and vmemmap_pgd_populate. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco

[PATCH v11 3/9] sparc64: simplify vmemmap_populate

Remove duplicating code by using common functions vmemmap_pud_populate and vmemmap_pgd_populate. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco Acked-by: David S. Miller Acked-by: Michal Hocko --- arch/sparc/mm/init_64.c | 23

[PATCH v11 6/9] x86/kasan: add and use kasan_map_populate()

During early boot, kasan uses vmemmap_populate() to establish its shadow memory. But, that interface is intended for struct pages use. Because of the current project, vmemmap won't be zeroed during allocation, but kasan expects that memory to be zeroed. We are adding a new kasan_map_populate()

[PATCH v11 6/9] x86/kasan: add and use kasan_map_populate()

During early boot, kasan uses vmemmap_populate() to establish its shadow memory. But, that interface is intended for struct pages use. Because of the current project, vmemmap won't be zeroed during allocation, but kasan expects that memory to be zeroed. We are adding a new kasan_map_populate()

[PATCH v11 8/9] mm: stop zeroing memory during allocation in vmemmap

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. Replace allocators in sprase-vmemmap to use the non-zeroing version. So, we will get the performance improvement

[PATCH v11 8/9] mm: stop zeroing memory during allocation in vmemmap

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. Replace allocators in sprase-vmemmap to use the non-zeroing version. So, we will get the performance improvement

[PATCH v11 0/9] complete deferred page initialization

Changelog: v11 - v10 - Moved kasan_map_populate() implementation from common code into arch specific as discussed with Will Deacon. We do not need "mm/kasan: kasan specific map populate function" anymore, so only 9 patches left. v10 - v9 - Addressed new comments from Michal Hocko. - Sent

[PATCH v11 0/9] complete deferred page initialization

Changelog: v11 - v10 - Moved kasan_map_populate() implementation from common code into arch specific as discussed with Will Deacon. We do not need "mm/kasan: kasan specific map populate function" anymore, so only 9 patches left. v10 - v9 - Addressed new comments from Michal Hocko. - Sent

[PATCH v11 5/9] mm: zero reserved and unavailable struct pages

Some memory is reserved but unavailable: not present in memblock.memory (because not backed by physical pages), but present in memblock.reserved. Such memory has backing struct pages, but they are not initialized by going through __init_single_page(). In some cases these struct pages are accessed

[PATCH v11 5/9] mm: zero reserved and unavailable struct pages

Some memory is reserved but unavailable: not present in memblock.memory (because not backed by physical pages), but present in memblock.reserved. Such memory has backing struct pages, but they are not initialized by going through __init_single_page(). In some cases these struct pages are accessed

Re: [PATCH 0/5] trace-cmd: Fixes for four small bugs plus minor cleanup

On Mon, 9 Oct 2017 16:13:42 -0600 Michael Sartain wrote: > Ping? Were there any concerns with these or things needed to be > done before they could be merged? > Thanks for the ping, this fell back in the todo list of my emails. I'll look at it this week. -- Steve

[PATCH v11 2/9] sparc64/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled there is a case where we set some fields

Re: [PATCH 0/5] trace-cmd: Fixes for four small bugs plus minor cleanup

On Mon, 9 Oct 2017 16:13:42 -0600 Michael Sartain wrote: > Ping? Were there any concerns with these or things needed to be > done before they could be merged? > Thanks for the ping, this fell back in the todo list of my emails. I'll look at it this week. -- Steve

[PATCH v11 2/9] sparc64/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled there is a case where we set some fields

[PATCH v11 1/9] x86/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled, however, we set fields in

[PATCH v11 1/9] x86/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled, however, we set fields in

Re: [PATCH 2/2] media: venus: venc: fix bytesused v4l2_plane field

Hans, On 9.10.2017 15:31, Hans Verkuil wrote: On 09/10/17 14:24, Stanimir Varbanov wrote: This fixes wrongly filled bytesused field of v4l2_plane structure by include data_offset in the plane, Also fill data_offset and bytesused for capture type of buffers only. Signed-off-by: Stanimir

Re: [PATCH 2/2] media: venus: venc: fix bytesused v4l2_plane field

Hans, On 9.10.2017 15:31, Hans Verkuil wrote: On 09/10/17 14:24, Stanimir Varbanov wrote: This fixes wrongly filled bytesused field of v4l2_plane structure by include data_offset in the plane, Also fill data_offset and bytesused for capture type of buffers only. Signed-off-by: Stanimir

Re: [PATCH 1/2] staging: typec: tcpm: Validate source and sink caps

Sorry about delay. Just sent the rebased patchset along with the comments addressed. Thanks & Regards, Badhri. On Mon, Sep 18, 2017 at 3:20 AM, Greg Kroah-Hartman wrote: > On Thu, Sep 07, 2017 at 06:22:13PM -0700, Badhri Jagan Sridharan wrote: >> The source and sink

Re: [PATCH 1/2] staging: typec: tcpm: Validate source and sink caps

Sorry about delay. Just sent the rebased patchset along with the comments addressed. Thanks & Regards, Badhri. On Mon, Sep 18, 2017 at 3:20 AM, Greg Kroah-Hartman wrote: > On Thu, Sep 07, 2017 at 06:22:13PM -0700, Badhri Jagan Sridharan wrote: >> The source and sink caps should follow the

Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically

On 10/09/2017 02:57 PM, Linus Walleij wrote: On Mon, Oct 9, 2017 at 8:10 PM, Grygorii Strashko wrote: At the moment it was merged there were no user of irq_base except gpio-mockup.c. OK I feel calmer. And actually there are shouldn't as calling

Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically

On 10/09/2017 02:57 PM, Linus Walleij wrote: On Mon, Oct 9, 2017 at 8:10 PM, Grygorii Strashko wrote: At the moment it was merged there were no user of irq_base except gpio-mockup.c. OK I feel calmer. And actually there are shouldn't as calling irq_create_mapping() in cycle will not

[PATCH] gpiolib: drop irq_base field from gpio_chip struct

Hence, the last user of irq_base field was removed by commit b4c495f03ae3 ("gpio: mockup: use irq_sim") it can be removed safely. Signed-off-by: Grygorii Strashko --- include/linux/gpio/driver.h | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH] gpiolib: drop irq_base field from gpio_chip struct

Hence, the last user of irq_base field was removed by commit b4c495f03ae3 ("gpio: mockup: use irq_sim") it can be removed safely. Signed-off-by: Grygorii Strashko --- include/linux/gpio/driver.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/gpio/driver.h

[PATCH] bcache: mark expected switch fall-throughs in STRTO_H

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Cc: Kent Overstreet Cc: Shaohua Li Cc: linux-bca...@vger.kernel.org Cc: linux-r...@vger.kernel.org Signed-off-by: Gustavo A. R. Silva

[PATCH] bcache: mark expected switch fall-throughs in STRTO_H

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Cc: Kent Overstreet Cc: Shaohua Li Cc: linux-bca...@vger.kernel.org Cc: linux-r...@vger.kernel.org Signed-off-by: Gustavo A. R. Silva --- drivers/md/bcache/util.c | 7 +++ 1 file

[PATCH 2/2 v2] typec: tcpm: Only request matching pdos

At present, TCPM code assumes that local device supports variable/batt pdos and always selects the pdo with highest possible power within the board limit. This assumption might not hold good for all devices. To overcome this, this patch makes TCPM only accept a source_pdo when there is a matching

[PATCH 2/2 v2] typec: tcpm: Only request matching pdos

At present, TCPM code assumes that local device supports variable/batt pdos and always selects the pdo with highest possible power within the board limit. This assumption might not hold good for all devices. To overcome this, this patch makes TCPM only accept a source_pdo when there is a matching

[PATCH 1/2 v2] typec: tcpm: Validate source and sink caps

The source and sink caps should follow the following rules. This patch validates whether the src_caps/snk_caps adheres to it. 6.4.1 Capabilities Message A Capabilities message (Source Capabilities message or Sink Capabilities message) shall have at least one Power Data Object for vSafe5V. The

Re: [PATCH 0/5] trace-cmd: Fixes for four small bugs plus minor cleanup

Ping? Were there any concerns with these or things needed to be done before they could be merged? Thanks. On Sat, Aug 12, 2017, at 11:30 AM, Michael Sartain wrote: > Thanks much. > -Mike > > --- > > Michael Sartain (5): > trace-cmd: Fix incorrect malloc size arg: *item instead of item >

[PATCH 1/2 v2] typec: tcpm: Validate source and sink caps

The source and sink caps should follow the following rules. This patch validates whether the src_caps/snk_caps adheres to it. 6.4.1 Capabilities Message A Capabilities message (Source Capabilities message or Sink Capabilities message) shall have at least one Power Data Object for vSafe5V. The

Re: [PATCH 0/5] trace-cmd: Fixes for four small bugs plus minor cleanup

Ping? Were there any concerns with these or things needed to be done before they could be merged? Thanks. On Sat, Aug 12, 2017, at 11:30 AM, Michael Sartain wrote: > Thanks much. > -Mike > > --- > > Michael Sartain (5): > trace-cmd: Fix incorrect malloc size arg: *item instead of item >

Re: usb/sound: use-after-free in snd_usb_mixer_interrupt

On Mon, 09 Oct 2017 19:50:39 +0200, Andrey Konovalov wrote: > > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). > > gadgetfs: bound to dummy_udc driver > usb 1-1: new full-speed USB device number

Re: usb/sound: use-after-free in snd_usb_mixer_interrupt

On Mon, 09 Oct 2017 19:50:39 +0200, Andrey Konovalov wrote: > > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4). > > gadgetfs: bound to dummy_udc driver > usb 1-1: new full-speed USB device number

ATENCIÓN

ATENCIÓN; Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de

ATENCIÓN

ATENCIÓN; Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote: > Anyway, to move this forward I think we need to see a proof of concept > of using selinux to protect access to specific heaps. Aren't Unix permissions enough with separate files or am I misunderstanding what you're looking to see a

Re: [PATCH v5 2/2] staging: ion: create one device entry per heap

On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote: > Anyway, to move this forward I think we need to see a proof of concept > of using selinux to protect access to specific heaps. Aren't Unix permissions enough with separate files or am I misunderstanding what you're looking to see a

Re: [PATCH net-next RFC 4/9] net: dsa: mv88e6xxx: add support for event capture

On Sun, Oct 8, 2017 at 9:06 AM, Richard Cochran wrote: >> +static int mv88e6xxx_ptp_enable_perout(struct mv88e6xxx_chip *chip, >> +struct ptp_clock_request *rq, int on) >> +{ >> + struct timespec ts; >> + u64 ns; >> + int

Re: [PATCH net-next RFC 4/9] net: dsa: mv88e6xxx: add support for event capture

On Sun, Oct 8, 2017 at 9:06 AM, Richard Cochran wrote: >> +static int mv88e6xxx_ptp_enable_perout(struct mv88e6xxx_chip *chip, >> +struct ptp_clock_request *rq, int on) >> +{ >> + struct timespec ts; >> + u64 ns; >> + int pin; >> + int err; >>

Re: [RFC PATCH 4/4] kbuild: evaluate cc-option and friends only when building kernel

Hi, On Tue, Oct 3, 2017 at 8:56 PM, Masahiro Yamada wrote: > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include > index 9ffd3dd..222d0a2 100644 > --- a/scripts/Kbuild.include > +++ b/scripts/Kbuild.include > @@ -96,6 +96,13 @@ try-run = $(shell set -e;

Re: [RFC PATCH 4/4] kbuild: evaluate cc-option and friends only when building kernel

Hi, On Tue, Oct 3, 2017 at 8:56 PM, Masahiro Yamada wrote: > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include > index 9ffd3dd..222d0a2 100644 > --- a/scripts/Kbuild.include > +++ b/scripts/Kbuild.include > @@ -96,6 +96,13 @@ try-run = $(shell set -e;\ > fi;

Re: [PATCH 3/4] kbuild: re-order the code to not parse unnecessary variables

Hi, On Tue, Oct 3, 2017 at 8:56 PM, Masahiro Yamada wrote: > The top Makefile is divided into some sections such as mixed targets, > config targets, build targets, etc. > > When we build mixed targets, Kbuild just invokes submake to process > them one by one. In

Re: [PATCH 3/4] kbuild: re-order the code to not parse unnecessary variables

Hi, On Tue, Oct 3, 2017 at 8:56 PM, Masahiro Yamada wrote: > The top Makefile is divided into some sections such as mixed targets, > config targets, build targets, etc. > > When we build mixed targets, Kbuild just invokes submake to process > them one by one. In this case, compiler-related

Re: [PATCH 2/4] kbuild: move "_all" target out of $(KBUILD_SRC) conditional

Hi, On Tue, Oct 3, 2017 at 8:56 PM, Masahiro Yamada wrote: > The first "_all" occurrence around line 120 is only visible when > KBUILD_SRC is unset. > > If O=... is specified, the working directory is relocated, then the > only second occurrence around line 193 is

Re: [PATCH 2/4] kbuild: move "_all" target out of $(KBUILD_SRC) conditional

Hi, On Tue, Oct 3, 2017 at 8:56 PM, Masahiro Yamada wrote: > The first "_all" occurrence around line 120 is only visible when > KBUILD_SRC is unset. > > If O=... is specified, the working directory is relocated, then the > only second occurrence around line 193 is visible, that is not set > to

Re: [PATCH 1/4] kbuild: replace $(hdr-arch) with $(SRCARCH)

Hi, On Tue, Oct 3, 2017 at 8:56 PM, Masahiro Yamada wrote: > Since commit 5e53879008b9 ("sparc,sparc64: unify Makefile"), hdr-arch > and SRCARCH always match. > > Signed-off-by: Masahiro Yamada > --- > > Makefile

Re: [PATCH 1/4] kbuild: replace $(hdr-arch) with $(SRCARCH)

Hi, On Tue, Oct 3, 2017 at 8:56 PM, Masahiro Yamada wrote: > Since commit 5e53879008b9 ("sparc,sparc64: unify Makefile"), hdr-arch > and SRCARCH always match. > > Signed-off-by: Masahiro Yamada > --- > > Makefile | 21 + > scripts/Makefile.headersinst |

Re: [PATCH v2 00/16] gpio: Tight IRQ chip integration and banked infrastructure

On 10/06/2017 06:07 AM, Thierry Reding wrote: > On Thu, Sep 28, 2017 at 09:22:17AM -0500, Grygorii Strashko wrote: >> >> >> On 09/28/2017 04:56 AM, Thierry Reding wrote: >>> From: Thierry Reding >>> >>> Hi Linus, >>> >>> here's the latest series of patches that implement the

Re: [PATCH v2 00/16] gpio: Tight IRQ chip integration and banked infrastructure

On 10/06/2017 06:07 AM, Thierry Reding wrote: > On Thu, Sep 28, 2017 at 09:22:17AM -0500, Grygorii Strashko wrote: >> >> >> On 09/28/2017 04:56 AM, Thierry Reding wrote: >>> From: Thierry Reding >>> >>> Hi Linus, >>> >>> here's the latest series of patches that implement the tighter IRQ chip

Re: [PATCH v2 14/16] gpio: Add support for banked GPIO controllers

On 09/28/2017 04:56 AM, Thierry Reding wrote: > From: Thierry Reding > > Some GPIO controllers are subdivided into multiple logical blocks called > banks (or ports). This is often caused by the design assigning separate > resources, such as register regions or interrupts,

Re: [PATCH v2 14/16] gpio: Add support for banked GPIO controllers

On 09/28/2017 04:56 AM, Thierry Reding wrote: > From: Thierry Reding > > Some GPIO controllers are subdivided into multiple logical blocks called > banks (or ports). This is often caused by the design assigning separate > resources, such as register regions or interrupts, to each bank, or some

Re: [v11 3/6] mm, oom: cgroup-aware OOM killer

On Thu, 5 Oct 2017, Roman Gushchin wrote: > Traditionally, the OOM killer is operating on a process level. > Under oom conditions, it finds a process with the highest oom score > and kills it. > > This behavior doesn't suit well the system with many running > containers: > > 1) There is no

Re: [v11 3/6] mm, oom: cgroup-aware OOM killer

On Thu, 5 Oct 2017, Roman Gushchin wrote: > Traditionally, the OOM killer is operating on a process level. > Under oom conditions, it finds a process with the highest oom score > and kills it. > > This behavior doesn't suit well the system with many running > containers: > > 1) There is no

Re: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey

On Tue, Oct 3, 2017 at 2:58 AM, Minas Harutyunyan wrote: > > Could you please apply patch from Vardan Mikayelyan "usb: dwc2: Fix > dwc2_hsotg_core_init_disconnected()" submitted at 02/25/2017 > (https://marc.info/?l=linux-usb=148801589931039=2) instead of your >

Re: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey

On Tue, Oct 3, 2017 at 2:58 AM, Minas Harutyunyan wrote: > > Could you please apply patch from Vardan Mikayelyan "usb: dwc2: Fix > dwc2_hsotg_core_init_disconnected()" submitted at 02/25/2017 > (https://marc.info/?l=linux-usb=148801589931039=2) instead of your > "usb: dwc2: Improve gadget state

Re: Read-only `slaves` with shared subtrees?

On Sun, Oct 8, 2017 at 5:15 PM, Ram Pai wrote: >> >> One thing that I don't plan to use, but might be worth thinking about is >> `slave + RW + STICKY` combination. If `master` mounts something RO, >> and `slave` >> is `RW + STICKY`, should the mount appear RW inside the

Re: Read-only `slaves` with shared subtrees?

On Sun, Oct 8, 2017 at 5:15 PM, Ram Pai wrote: >> >> One thing that I don't plan to use, but might be worth thinking about is >> `slave + RW + STICKY` combination. If `master` mounts something RO, >> and `slave` >> is `RW + STICKY`, should the mount appear RW inside the slave? I don't >> find

[PATCH net-next] once: switch to new jump label API

From: Eric Biggers Switch the DO_ONCE() macro from the deprecated jump label API to the new one. The new one is more readable, and for DO_ONCE() it also makes the generated code more icache-friendly: now the one-time initialization code is placed out-of-line at the jump

[PATCH net-next] once: switch to new jump label API

From: Eric Biggers Switch the DO_ONCE() macro from the deprecated jump label API to the new one. The new one is more readable, and for DO_ONCE() it also makes the generated code more icache-friendly: now the one-time initialization code is placed out-of-line at the jump target, rather than at

[PATCH 2/3] cgroup, writeback: implement submit_bh_blkcg_css()

Add wbc->blkcg_css so that the blkcg_css association can be specified independently and implement submit_bh_blkcg_css() using it. This will be used to override cgroup membership on specific buffer_heads. Signed-off-by: Tejun Heo Cc: Jan Kara Cc: Jens Axboe

[PATCH 2/3] cgroup, writeback: implement submit_bh_blkcg_css()

Add wbc->blkcg_css so that the blkcg_css association can be specified independently and implement submit_bh_blkcg_css() using it. This will be used to override cgroup membership on specific buffer_heads. Signed-off-by: Tejun Heo Cc: Jan Kara Cc: Jens Axboe --- fs/buffer.c |

[PATCH 3/3] btrfs: ensure that metadata and flush are issued from the root cgroup

Issuing metdata or otherwise shared IOs from !root cgroup can lead to priority inversion. This patch ensures that those IOs are always issued from the root cgroup. This patch updates btrfs_update_iflags() to not set S_CGROUPWB on btree_inodes. This isn't strictly necessary as those inodes don't

[PATCH 3/3] btrfs: ensure that metadata and flush are issued from the root cgroup

Issuing metdata or otherwise shared IOs from !root cgroup can lead to priority inversion. This patch ensures that those IOs are always issued from the root cgroup. This patch updates btrfs_update_iflags() to not set S_CGROUPWB on btree_inodes. This isn't strictly necessary as those inodes don't

[PATCH 1/3] cgroup, writeback: replace SB_I_CGROUPWB with per-inode S_CGROUPWB

Currently, filesystem can indiate cgroup writeback support per superblock; however, depending on the filesystem, especially if inodes are used to carry metadata, it can be useful to indicate cgroup writeback support per inode. This patch replaces the superblock flag SB_I_CGROUPWB with per-inode

[PATCH 1/3] cgroup, writeback: replace SB_I_CGROUPWB with per-inode S_CGROUPWB

Currently, filesystem can indiate cgroup writeback support per superblock; however, depending on the filesystem, especially if inodes are used to carry metadata, it can be useful to indicate cgroup writeback support per inode. This patch replaces the superblock flag SB_I_CGROUPWB with per-inode

[PATCHSET] cgroup, writeback, btrfs: make sure btrfs issues metadata IOs from the root cgroup

Hello, btrfs has different ways to issue metadata IOs and may end up issuing metadata or otherwise shared IOs from a non-root cgroup, which can lead to priority inversion and ineffective IO isolation. This patchset makes sure that btrfs issues all metadata and shared IOs from the root cgroup by

[PATCHSET] cgroup, writeback, btrfs: make sure btrfs issues metadata IOs from the root cgroup

Hello, btrfs has different ways to issue metadata IOs and may end up issuing metadata or otherwise shared IOs from a non-root cgroup, which can lead to priority inversion and ineffective IO isolation. This patchset makes sure that btrfs issues all metadata and shared IOs from the root cgroup by

Re: [kernel-hardening] [PATCH] lib/vsprintf: add default case to 'i' specifier

On Mon, Oct 09, 2017 at 09:16:09AM -0600, Tycho Andersen wrote: > On Mon, Oct 09, 2017 at 01:59:05PM +1100, Tobin C. Harding wrote: > > %pi leaks kernel addresses if incorrectly specified. > > > > Currently the printk specifier %pi (%pI) contains a switch statement > > without a default clause.

Re: [kernel-hardening] [PATCH] lib/vsprintf: add default case to 'i' specifier

On Mon, Oct 09, 2017 at 09:16:09AM -0600, Tycho Andersen wrote: > On Mon, Oct 09, 2017 at 01:59:05PM +1100, Tobin C. Harding wrote: > > %pi leaks kernel addresses if incorrectly specified. > > > > Currently the printk specifier %pi (%pI) contains a switch statement > > without a default clause.

Re: [PATCH] scsi: libiscsi: fix shifting of DID_REQUEUE host byte

On 10/09/2017 04:33 AM, Johannes Thumshirn wrote: > The SCSI host byte should be shifted left by 16 in order to have > scsi_decide_disposition() do the right thing (.i.e. requeue the command). > > Signed-off-by: Johannes Thumshirn > Fixes: 661134ad3765 ("[SCSI] libiscsi,

Re: [PATCH] scsi: libiscsi: fix shifting of DID_REQUEUE host byte

On 10/09/2017 04:33 AM, Johannes Thumshirn wrote: > The SCSI host byte should be shifted left by 16 in order to have > scsi_decide_disposition() do the right thing (.i.e. requeue the command). > > Signed-off-by: Johannes Thumshirn > Fixes: 661134ad3765 ("[SCSI] libiscsi, bnx2i: make bound ep

<    1   2   3   4   5   6   7   8   9   10   >