Re: [v5 04/12] dt-bindings: soc/fsl: Update reserved memory binding for QBMan

On Mon, Sep 18, 2017 at 04:39:39PM -0400, Roy Pledge wrote: > Updates the QMan and BMan device tree bindings for reserved memory > nodes. This makes the reserved memory allocation compatible with > the shared-dma-pool usage. > > Signed-off-by: Roy Pledge > --- >

Re: [v5 04/12] dt-bindings: soc/fsl: Update reserved memory binding for QBMan

On Mon, Sep 18, 2017 at 04:39:39PM -0400, Roy Pledge wrote: > Updates the QMan and BMan device tree bindings for reserved memory > nodes. This makes the reserved memory allocation compatible with > the shared-dma-pool usage. > > Signed-off-by: Roy Pledge > --- >

Re: [PATCH] nvmem: sunxi-sid: add support for A64/H5's SID controller

On Mon, Sep 18, 2017 at 11:42:04PM +0800, Icenowy Zheng wrote: > Allwinner A64/H5 SoCs come with a SID controller like the one in H3, but > without the silicon bug that makes the initial value at 0x200 wrong, so > the value at 0x200 can be directly read. > > Add support for this kind of SID

Re: [PATCH] nvmem: sunxi-sid: add support for A64/H5's SID controller

On Mon, Sep 18, 2017 at 11:42:04PM +0800, Icenowy Zheng wrote: > Allwinner A64/H5 SoCs come with a SID controller like the one in H3, but > without the silicon bug that makes the initial value at 0x200 wrong, so > the value at 0x200 can be directly read. > > Add support for this kind of SID

[RFC LINUX PATCH] Dcoumentation: dt: mailbox: Add Xilinx IPI Mailbox

Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block in ZynqMP SoC used for the communication between various processor systems. Signed-off-by: Wendy Liang --- .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 88 ++ 1 file changed, 88

[RFC LINUX PATCH] Dcoumentation: dt: mailbox: Add Xilinx IPI Mailbox

Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block in ZynqMP SoC used for the communication between various processor systems. Signed-off-by: Wendy Liang --- .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 88 ++ 1 file changed, 88 insertions(+) create

Re: [PATCH] lib/lz4: make arrays static const, reduces object code size

On 22/09/17 00:09, Christophe JAILLET wrote: > Le 22/09/2017 à 00:19, Colin King a écrit : >> From: Colin Ian King >> >> Don't populate the read-only arrays dec32table and dec64table on the >> stack, instead make them both static const. Makes the object code >> smaller

Re: [PATCH] lib/lz4: make arrays static const, reduces object code size

On 22/09/17 00:09, Christophe JAILLET wrote: > Le 22/09/2017 à 00:19, Colin King a écrit : >> From: Colin Ian King >> >> Don't populate the read-only arrays dec32table and dec64table on the >> stack, instead make them both static const. Makes the object code >> smaller by over 10K bytes: > 10k?

Re: [PATCH v3 1/7] dt-bindings: timer: renesas,cmt: Fix SoC-specific compatible values

On Mon, Sep 18, 2017 at 03:46:41PM +0200, Geert Uytterhoeven wrote: > While the new family-specific compatible values introduced by commit > 6f54cc1adcc8957f ("devicetree: bindings: R-Car Gen2 CMT0 and CMT1 > bindings") use the recommended order ",-", the > new SoC-specific compatible values still

Re: [PATCH v3 1/7] dt-bindings: timer: renesas,cmt: Fix SoC-specific compatible values

On Mon, Sep 18, 2017 at 03:46:41PM +0200, Geert Uytterhoeven wrote: > While the new family-specific compatible values introduced by commit > 6f54cc1adcc8957f ("devicetree: bindings: R-Car Gen2 CMT0 and CMT1 > bindings") use the recommended order ",-", the > new SoC-specific compatible values still

Re: [PATCH] lib/lz4: make arrays static const, reduces object code size

Le 22/09/2017 à 00:19, Colin King a écrit : From: Colin Ian King Don't populate the read-only arrays dec32table and dec64table on the stack, instead make them both static const. Makes the object code smaller by over 10K bytes: 10k? Wouaouh! This is way much more than

Re: [PATCH] lib/lz4: make arrays static const, reduces object code size

Le 22/09/2017 à 00:19, Colin King a écrit : From: Colin Ian King Don't populate the read-only arrays dec32table and dec64table on the stack, instead make them both static const. Makes the object code smaller by over 10K bytes: 10k? Wouaouh! This is way much more than what you usually win with

Re: [PATCH v4 1/2] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller

On Mon, Sep 18, 2017 at 03:46:09PM +0200, Jerome Brunet wrote: > This commit adds the device tree bindings description for Amlogic's GPIO > interrupt controller available on the meson8b, gxbb and gxl SoC families > > Cc: Heiner Kallweit > Signed-off-by: Jerome Brunet

Re: [PATCH v4 1/2] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller

On Mon, Sep 18, 2017 at 03:46:09PM +0200, Jerome Brunet wrote: > This commit adds the device tree bindings description for Amlogic's GPIO > interrupt controller available on the meson8b, gxbb and gxl SoC families > > Cc: Heiner Kallweit > Signed-off-by: Jerome Brunet > --- >

[PATCH] cnic: Fix an error handling path in 'cnic_alloc_bnx2x_resc()'

All the error handling paths 'goto error', except this one. We should also go to error in this case, or some resources will be leaking. Signed-off-by: Christophe JAILLET --- drivers/net/ethernet/broadcom/cnic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] cnic: Fix an error handling path in 'cnic_alloc_bnx2x_resc()'

All the error handling paths 'goto error', except this one. We should also go to error in this case, or some resources will be leaking. Signed-off-by: Christophe JAILLET --- drivers/net/ethernet/broadcom/cnic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] dt-bindings: fix vendor prefix for Abracon

On Thu, Sep 14, 2017 at 11:39:38PM +0200, Alexandre Belloni wrote: > Commit 446810f2dd41 ("of: add vendor prefix for Abracon Corporation") > claimed that "abcn" was used as the vendor prefix while in fact "abracon" > was used in the subsequent commits. It is also the only prefix used in the >

Re: [PATCH] dt-bindings: fix vendor prefix for Abracon

On Thu, Sep 14, 2017 at 11:39:38PM +0200, Alexandre Belloni wrote: > Commit 446810f2dd41 ("of: add vendor prefix for Abracon Corporation") > claimed that "abcn" was used as the vendor prefix while in fact "abracon" > was used in the subsequent commits. It is also the only prefix used in the >

[PATCH] wireless: iwlegacy: make const array static to shink object code size Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit

From: Colin Ian King Don't populate const array ac_to_fifo on the stack in an inlined function, instead make it static. Makes the object code smaller by over 800 bytes: textdata bss dec hex filename 159029 331541216 193399 2f377 4965-mac.o

[PATCH] wireless: iwlegacy: make const array static to shink object code size Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit

From: Colin Ian King Don't populate const array ac_to_fifo on the stack in an inlined function, instead make it static. Makes the object code smaller by over 800 bytes: textdata bss dec hex filename 159029 331541216 193399 2f377 4965-mac.o textdata bss

Re: [PATCH] dt-bindings: nand: denali: reduce the register space in the example

On Thu, Sep 14, 2017 at 04:17:36PM +0900, Masahiro Yamada wrote: > This example allocates too much for register regions. Especially, > there are only two registers in the "nand_data" interface of this > hardware (ADDR: 0x00, DATA: 0x10). > > Signed-off-by: Masahiro Yamada

Re: [PATCH] dt-bindings: nand: denali: reduce the register space in the example

On Thu, Sep 14, 2017 at 04:17:36PM +0900, Masahiro Yamada wrote: > This example allocates too much for register regions. Especially, > there are only two registers in the "nand_data" interface of this > hardware (ADDR: 0x00, DATA: 0x10). > > Signed-off-by: Masahiro Yamada > --- > >

Re: [PATCH v9 4/7] clk: qcom: Add A53 PLL support

On Thu, Sep 21, 2017 at 07:49:37PM +0300, Georgi Djakov wrote: > The CPUs on Qualcomm MSM8916-based platforms are clocked by two PLLs, > a primary (A53) CPU PLL and a secondary fixed-rate GPLL0. These sources > are connected to a mux and half-integer divider, which is feeding the > CPU cores. > >

Re: [PATCH v9 4/7] clk: qcom: Add A53 PLL support

On Thu, Sep 21, 2017 at 07:49:37PM +0300, Georgi Djakov wrote: > The CPUs on Qualcomm MSM8916-based platforms are clocked by two PLLs, > a primary (A53) CPU PLL and a secondary fixed-rate GPLL0. These sources > are connected to a mux and half-integer divider, which is feeding the > CPU cores. > >

Re: [PATCH 1/1] net: usb: catc: use setup_timer() helper

From: Allen Pais Date: Thu, 21 Sep 2017 18:24:15 +0530 > Use setup_timer function instead of initializing timer with the > function and data fields. > > Signed-off-by: Allen Pais Applied.

Re: [PATCH 1/1] net: ti: netcp: use setup_timer

From: Allen Pais Date: Thu, 21 Sep 2017 18:32:58 +0530 > Use setup_timer function instead of initializing timer with the > function and data fields. > > Signed-off-by: Allen Pais Applied.

Re: [PATCH 1/1] net: usb: catc: use setup_timer() helper

From: Allen Pais Date: Thu, 21 Sep 2017 18:24:15 +0530 > Use setup_timer function instead of initializing timer with the > function and data fields. > > Signed-off-by: Allen Pais Applied.

Re: [PATCH 1/1] net: ti: netcp: use setup_timer

From: Allen Pais Date: Thu, 21 Sep 2017 18:32:58 +0530 > Use setup_timer function instead of initializing timer with the > function and data fields. > > Signed-off-by: Allen Pais Applied.

Re: [PATCH 1/1] net: wan : hdlc: use setup_timer() helper

From: Allen Pais Date: Thu, 21 Sep 2017 18:17:55 +0530 > Use setup_timer function instead of initializing timer with the > function and data fields. > > Signed-off-by: Allen Pais Applied.

Re: [PATCH 1/1] net: wan : hdlc: use setup_timer() helper

From: Allen Pais Date: Thu, 21 Sep 2017 18:17:55 +0530 > Use setup_timer function instead of initializing timer with the > function and data fields. > > Signed-off-by: Allen Pais Applied.

Re: [PATCH 1/1] net:nfc: use setup_timer

From: Allen Pais Date: Thu, 21 Sep 2017 16:29:33 +0530 > Use setup_timer function instead of initializing timer with the > function and data fields. > > Signed-off-by: Allen Pais Applied.

Re: [PATCH 1/1] net:nfc: use setup_timer

From: Allen Pais Date: Thu, 21 Sep 2017 16:29:33 +0530 > Use setup_timer function instead of initializing timer with the > function and data fields. > > Signed-off-by: Allen Pais Applied.

Re: [PATCH v5 1/4] dt-bindings: Document the STM32 DMAMUX bindings

On Thu, Sep 21, 2017 at 05:29:18PM +0200, Pierre-Yves MORDRET wrote: > This patch adds the documentation of device tree bindings for the STM32 > DMAMUX. > > Signed-off-by: M'boumba Cedric Madianga > Signed-off-by: Pierre-Yves MORDRET > ---

Re: [PATCH v5 1/4] dt-bindings: Document the STM32 DMAMUX bindings

On Thu, Sep 21, 2017 at 05:29:18PM +0200, Pierre-Yves MORDRET wrote: > This patch adds the documentation of device tree bindings for the STM32 > DMAMUX. > > Signed-off-by: M'boumba Cedric Madianga > Signed-off-by: Pierre-Yves MORDRET > --- > Version history: > v5: > v4: > * Add

[PATCH] staging: xgifb: make const array static to shink object code size

From: Colin Ian King Don't populate const array LCDARefreshIndex on the stack, instead make it static. Makes the object code smaller by 340 bytes: Before: textdata bss dec hex filename 84949 12336 0 97285 17c05

[PATCH] staging: xgifb: make const array static to shink object code size

From: Colin Ian King Don't populate const array LCDARefreshIndex on the stack, instead make it static. Makes the object code smaller by 340 bytes: Before: textdata bss dec hex filename 84949 12336 0 97285 17c05 drivers/staging/xgifb/vb_setmode.o After: text

[PATCH] i2c: designware: make const array supported_speeds static to shink object code size

From: Colin Ian King Don't populate const array supported_speeds on the stack, instead make it static. Makes the object code smaller by 150 bytes: Before: textdata bss dec hex filename 84741440 0991426ba i2c-designware-platdrv.o

[PATCH] i2c: designware: make const array supported_speeds static to shink object code size

From: Colin Ian King Don't populate const array supported_speeds on the stack, instead make it static. Makes the object code smaller by 150 bytes: Before: textdata bss dec hex filename 84741440 0991426ba i2c-designware-platdrv.o After: textdata

Re: [PATCH net-next] net: dsa: add port fdb dump

From: Vivien Didelot Date: Wed, 20 Sep 2017 19:32:14 -0400 > Dumping a DSA port's FDB entries is not specific to a DSA slave, so add > a dsa_port_fdb_dump function, similarly to dsa_port_fdb_add and > dsa_port_fdb_del. > > Signed-off-by: Vivien Didelot

Re: [PATCH net-next] net: dsa: add port fdb dump

From: Vivien Didelot Date: Wed, 20 Sep 2017 19:32:14 -0400 > Dumping a DSA port's FDB entries is not specific to a DSA slave, so add > a dsa_port_fdb_dump function, similarly to dsa_port_fdb_add and > dsa_port_fdb_del. > > Signed-off-by: Vivien Didelot Applied.

Re: [PATCH net-next] net: dsa: better scoping of slave functions

From: Vivien Didelot Date: Wed, 20 Sep 2017 19:31:57 -0400 > A few DSA slave functions take a dsa_slave_priv pointer as first > argument, whereas the scope of the slave.c functions is the slave > net_device structure. Fix this and rename dsa_netpoll_send_skb

Re: [PATCH net-next] net: dsa: better scoping of slave functions

From: Vivien Didelot Date: Wed, 20 Sep 2017 19:31:57 -0400 > A few DSA slave functions take a dsa_slave_priv pointer as first > argument, whereas the scope of the slave.c functions is the slave > net_device structure. Fix this and rename dsa_netpoll_send_skb to > dsa_slave_netpoll_send_skb. > >

[PATCH] lib/lz4: make arrays static const, reduces object code size

From: Colin Ian King Don't populate the read-only arrays dec32table and dec64table on the stack, instead make them both static const. Makes the object code smaller by over 10K bytes: Before: textdata bss dec hex filename 31500 0 0

[PATCH] lib/lz4: make arrays static const, reduces object code size

From: Colin Ian King Don't populate the read-only arrays dec32table and dec64table on the stack, instead make them both static const. Makes the object code smaller by over 10K bytes: Before: textdata bss dec hex filename 31500 0 0 315007b0c

Re: [PATCH 1/3] kcov: remove #ifdef CONFIG_RANDOMIZE_BASE

Hi Andrey, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc1 next-20170921] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/kcov-remove-ifdef

Re: [PATCH 1/3] kcov: remove #ifdef CONFIG_RANDOMIZE_BASE

Hi Andrey, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc1 next-20170921] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/kcov-remove-ifdef

Re: [PATCH net-next] net: dsa: use dedicated CPU port

From: Vivien Didelot Date: Wed, 20 Sep 2017 12:28:05 -0400 > Each port in DSA has its own dedicated CPU port currently available in > its parent switch's ds->ports[port].cpu_dp. Use it instead of getting > the unique tree CPU port, which will be deprecated

Re: [PATCH net-next] net: dsa: use dedicated CPU port

From: Vivien Didelot Date: Wed, 20 Sep 2017 12:28:05 -0400 > Each port in DSA has its own dedicated CPU port currently available in > its parent switch's ds->ports[port].cpu_dp. Use it instead of getting > the unique tree CPU port, which will be deprecated soon. > > Signed-off-by: Vivien

[PATCH] e1000: avoid null pointer dereference on invalid stat type

From: Colin Ian King Currently if the stat type is invalid then data[i] is being set either by dereferencing a null pointer p, or it is reading from an incorrect previous location if we had a valid stat type previously. Fix this by nullify pointer p if a stat type is

[PATCH] e1000: avoid null pointer dereference on invalid stat type

From: Colin Ian King Currently if the stat type is invalid then data[i] is being set either by dereferencing a null pointer p, or it is reading from an incorrect previous location if we had a valid stat type previously. Fix this by nullify pointer p if a stat type is invalid and only setting

Re: [PATCH -tip v3 0/7] kprobes/x86: Preempt related enhancements

On 9/19/17 2:58 AM, Masami Hiramatsu wrote: Hi, Here is the 3rd version of the series to improve preempt related behavior in kprobes/x86. This actually includes many enhancements/fixes from the 2nd version, which is https://lkml.org/lkml/2017/9/11/482 With the previous patch, lkp-bot reported

Re: [PATCH -tip v3 0/7] kprobes/x86: Preempt related enhancements

On 9/19/17 2:58 AM, Masami Hiramatsu wrote: Hi, Here is the 3rd version of the series to improve preempt related behavior in kprobes/x86. This actually includes many enhancements/fixes from the 2nd version, which is https://lkml.org/lkml/2017/9/11/482 With the previous patch, lkp-bot reported

Re: [PATCH] KEYS: prevent creating a different user's keyrings

On Tue, Sep 19, 2017 at 05:05:20PM +0100, David Howells wrote: > Eric Biggers wrote: > > > Fix it by marking user and user session keyrings with a flag > > KEY_FLAG_UID_KEYRING. Then, when searching for a user or user session > > keyring by name, skip all keyrings that

Re: [PATCH] KEYS: prevent creating a different user's keyrings

On Tue, Sep 19, 2017 at 05:05:20PM +0100, David Howells wrote: > Eric Biggers wrote: > > > Fix it by marking user and user session keyrings with a flag > > KEY_FLAG_UID_KEYRING. Then, when searching for a user or user session > > keyring by name, skip all keyrings that don't have the flag set.

[RFC PATCH 1/2] capability: introduce sysctl for controlled user-ns capability whitelist

From: Mahesh Bandewar Add a sysctl variable kernel.controlled_userns_caps_whitelist. This takes input as capability mask expressed as two comma separated hex u32 words. The mask, however, is stored in kernel as kernel_cap_t type. Any capabilities that are not part of this

[RFC PATCH 2/2] userns: control capabilities of some user namespaces

From: Mahesh Bandewar With this new notion of "controlled" user-namespaces, the controlled user-namespaces are marked at the time of their creation while the capabilities of processes that belong to them are controlled using the global mask. Init-user-ns is always

[RFC PATCH 1/2] capability: introduce sysctl for controlled user-ns capability whitelist

From: Mahesh Bandewar Add a sysctl variable kernel.controlled_userns_caps_whitelist. This takes input as capability mask expressed as two comma separated hex u32 words. The mask, however, is stored in kernel as kernel_cap_t type. Any capabilities that are not part of this mask will be

[RFC PATCH 2/2] userns: control capabilities of some user namespaces

From: Mahesh Bandewar With this new notion of "controlled" user-namespaces, the controlled user-namespaces are marked at the time of their creation while the capabilities of processes that belong to them are controlled using the global mask. Init-user-ns is always uncontrolled and a process

[RFC PATCH 0/2] capability controlled user-namespaces

From: Mahesh Bandewar TL;DR version - Creating a sandbox environment with namespaces is challenging considering what these sandboxed processes can engage into. e.g. CVE-2017-6074, CVE-2017-7184, CVE-2017-7308 etc. just to name few. Current form of user-namespaces,

[RFC PATCH 0/2] capability controlled user-namespaces

From: Mahesh Bandewar TL;DR version - Creating a sandbox environment with namespaces is challenging considering what these sandboxed processes can engage into. e.g. CVE-2017-6074, CVE-2017-7184, CVE-2017-7308 etc. just to name few. Current form of user-namespaces, however, if changed

Re: [PATCH] gpio: thunderx: remove unused .map() hook from irq_domain_ops

On 09/13/2017 07:37 PM, Masahiro Yamada wrote: This driver implements .alloc() hook, so .map() is not used. Although this comment is true for this driver, it is unclear to me if the statement is true in the general case. Signed-off-by: Masahiro Yamada

Re: [PATCH] gpio: thunderx: remove unused .map() hook from irq_domain_ops

On 09/13/2017 07:37 PM, Masahiro Yamada wrote: This driver implements .alloc() hook, so .map() is not used. Although this comment is true for this driver, it is unclear to me if the statement is true in the general case. Signed-off-by: Masahiro Yamada Tested-by: David Daney ---

Re: [v8 0/4] cgroup-aware OOM killer

On Thu, Sep 21, 2017 at 02:17:25PM -0700, David Rientjes wrote: > On Thu, 21 Sep 2017, Johannes Weiner wrote: > > > That's a ridiculous nak. > > > > The fact that this patch series doesn't solve your particular problem > > is not a technical argument to *reject* somebody else's work to solve > >

Re: [v8 0/4] cgroup-aware OOM killer

On Thu, Sep 21, 2017 at 02:17:25PM -0700, David Rientjes wrote: > On Thu, 21 Sep 2017, Johannes Weiner wrote: > > > That's a ridiculous nak. > > > > The fact that this patch series doesn't solve your particular problem > > is not a technical argument to *reject* somebody else's work to solve > >

[PATCH] generic: Add nocheck shutdown stress test

Most shutdown tests only run on filesystems with metadata journaling, so we lose coverage. Add a shutdown stress test that doesn't check for consistency, so does not require journaling. Signed-off-by: Khazhismel Kumykov --- tests/generic/999 | 84

[PATCH] generic: Add nocheck shutdown stress test

Most shutdown tests only run on filesystems with metadata journaling, so we lose coverage. Add a shutdown stress test that doesn't check for consistency, so does not require journaling. Signed-off-by: Khazhismel Kumykov --- tests/generic/999 | 84

Re: [v8 0/4] cgroup-aware OOM killer

On Thu, 21 Sep 2017, Johannes Weiner wrote: > That's a ridiculous nak. > > The fact that this patch series doesn't solve your particular problem > is not a technical argument to *reject* somebody else's work to solve > a different problem. It's not a regression when behavior is completely >

Re: [v8 0/4] cgroup-aware OOM killer

On Thu, 21 Sep 2017, Johannes Weiner wrote: > That's a ridiculous nak. > > The fact that this patch series doesn't solve your particular problem > is not a technical argument to *reject* somebody else's work to solve > a different problem. It's not a regression when behavior is completely >

Contribution to Linux Kernel.

Hello, My name is Javier, live in Argentina, and work as a Linux Server admin in the Network Operations Center of an ISP. Would like to know, how can I start contributing to the Linux kernel. Sorry for the inconvenience. Regards, Javier Romero

Contribution to Linux Kernel.

Hello, My name is Javier, live in Argentina, and work as a Linux Server admin in the Network Operations Center of an ISP. Would like to know, how can I start contributing to the Linux kernel. Sorry for the inconvenience. Regards, Javier Romero

Re: [PATCH v2 00/40] tracing: Inter-event (e.g. latency) support

Hi Steve, On Thu, 2017-09-21 at 16:20 -0400, Steven Rostedt wrote: > On Tue, 19 Sep 2017 13:44:28 -0500 > Tom Zanussi wrote: > > > Yeah, it's almost ready. At this point, I've addressed all the comments > > except for: > > > > - PATCH v2 25/40] tracing: Add

Re: [PATCH v2 00/40] tracing: Inter-event (e.g. latency) support

Hi Steve, On Thu, 2017-09-21 at 16:20 -0400, Steven Rostedt wrote: > On Tue, 19 Sep 2017 13:44:28 -0500 > Tom Zanussi wrote: > > > Yeah, it's almost ready. At this point, I've addressed all the comments > > except for: > > > > - PATCH v2 25/40] tracing: Add support for dynamic tracepoints >

[GIT PULL] libnvdimm fixes for 4.14-rc2

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive a crash fix and corresponding regression test enabling for the crash scenario. The unit test for this crash is available in ndctl-v58.2. This branch has received a build

[GIT PULL] libnvdimm fixes for 4.14-rc2

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive a crash fix and corresponding regression test enabling for the crash scenario. The unit test for this crash is available in ndctl-v58.2. This branch has received a build

[PATCH v2 2/3] KEYS: don't revoke uninstantiated key in request_key_auth_new()

From: Eric Biggers If key_instantiate_and_link() were to fail (which fortunately isn't possible currently), the call to key_revoke(authkey) would crash with a NULL pointer dereference in request_key_auth_revoke() because the key has not yet been instantiated. Fix this by

[PATCH v2 2/3] KEYS: don't revoke uninstantiated key in request_key_auth_new()

From: Eric Biggers If key_instantiate_and_link() were to fail (which fortunately isn't possible currently), the call to key_revoke(authkey) would crash with a NULL pointer dereference in request_key_auth_revoke() because the key has not yet been instantiated. Fix this by removing the call to

[PATCH v2 0/3] KEYS: fix error handling in request_key_auth_new()

From: Eric Biggers Fix a reference leak and a NULL pointer dereference in the error handling paths of request_key_auth_new(). Eric Biggers (3): KEYS: fix cred refcount leak in request_key_auth_new() KEYS: don't revoke uninstantiated key in request_key_auth_new() KEYS:

[PATCH v2 0/3] KEYS: fix error handling in request_key_auth_new()

From: Eric Biggers Fix a reference leak and a NULL pointer dereference in the error handling paths of request_key_auth_new(). Eric Biggers (3): KEYS: fix cred refcount leak in request_key_auth_new() KEYS: don't revoke uninstantiated key in request_key_auth_new() KEYS: use kmemdup() in

[PATCH v2 3/3] KEYS: use kmemdup() in request_key_auth_new()

From: Eric Biggers kmemdup() is preferred to kmalloc() followed by memcpy(). Signed-off-by: Eric Biggers --- security/keys/request_key_auth.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/security/keys/request_key_auth.c

[PATCH v2 3/3] KEYS: use kmemdup() in request_key_auth_new()

From: Eric Biggers kmemdup() is preferred to kmalloc() followed by memcpy(). Signed-off-by: Eric Biggers --- security/keys/request_key_auth.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/security/keys/request_key_auth.c b/security/keys/request_key_auth.c index

[PATCH v2 1/3] KEYS: fix cred refcount leak in request_key_auth_new()

From: Eric Biggers In request_key_auth_new(), if key_alloc() or key_instantiate_and_link() were to fail, we would leak a reference to the 'struct cred'. Currently this can only happen if key_alloc() fails to allocate memory. But it still should be fixed, as it is a more

[PATCH v2 1/3] KEYS: fix cred refcount leak in request_key_auth_new()

From: Eric Biggers In request_key_auth_new(), if key_alloc() or key_instantiate_and_link() were to fail, we would leak a reference to the 'struct cred'. Currently this can only happen if key_alloc() fails to allocate memory. But it still should be fixed, as it is a more severe bug waiting to

Re: [PATCH] Input: add support for the Samsung S6SY761 touchscreen

Hi Andi, On Thu, Sep 21, 2017 at 10:29:50PM +0900, Andi Shyti wrote: > The S6SY761 touchscreen is a capicitive multi-touch controller > for mobile use. It's connected with i2c at the address 0x48. > > This commit provides a basic version of the driver which can > handle only initialization,

Re: [PATCH] Input: add support for the Samsung S6SY761 touchscreen

Hi Andi, On Thu, Sep 21, 2017 at 10:29:50PM +0900, Andi Shyti wrote: > The S6SY761 touchscreen is a capicitive multi-touch controller > for mobile use. It's connected with i2c at the address 0x48. > > This commit provides a basic version of the driver which can > handle only initialization,

RE: [PATCH 07/12] platform/x86: dell-wmi-smbios: Use Dell WMI descriptor check

> -Original Message- > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > Sent: Thursday, September 21, 2017 11:44 AM > To: Limonciello, Mario > Cc: dvh...@infradead.org; LKML ; Platform Driver >

RE: [PATCH 07/12] platform/x86: dell-wmi-smbios: Use Dell WMI descriptor check

> -Original Message- > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > Sent: Thursday, September 21, 2017 11:44 AM > To: Limonciello, Mario > Cc: dvh...@infradead.org; LKML ; Platform Driver > ; quasi...@google.com; Pali Rohár > > Subject: Re: [PATCH 07/12] platform/x86:

Re: [Outreachy kernel] [PATCH] staging: vc04_services: Remove typedef struct

On Fri, 22 Sep 2017, Harsha Sharma wrote: > Remove typedef from struct as linux-kernel coding style tends to > avoid using typedefs > > Done using following coccinelle semantic patch > > @r1@ > type T; > @@ > > typedef struct { ... } T; > > @script:python c1@ > T2; > T << r1.T; > @@ > if T[-2:]

Re: [Outreachy kernel] [PATCH] staging: vc04_services: Remove typedef struct

On Fri, 22 Sep 2017, Harsha Sharma wrote: > Remove typedef from struct as linux-kernel coding style tends to > avoid using typedefs > > Done using following coccinelle semantic patch > > @r1@ > type T; > @@ > > typedef struct { ... } T; > > @script:python c1@ > T2; > T << r1.T; > @@ > if T[-2:]

[PATCH 2/2] mm: oom: show unreclaimable slab info when kernel panic

Kernel may panic when oom happens without killable process sometimes it is caused by huge unreclaimable slabs used by kernel. Although kdump could help debug such problem, however, kdump is not available on all architectures and it might be malfunction sometime. And, since kernel already panic it

[PATCH 2/2] mm: oom: show unreclaimable slab info when kernel panic

Kernel may panic when oom happens without killable process sometimes it is caused by huge unreclaimable slabs used by kernel. Although kdump could help debug such problem, however, kdump is not available on all architectures and it might be malfunction sometime. And, since kernel already panic it

[PATCH 0/2 v5] oom: capture unreclaimable slab info in oom message when kernel panic

Recently we ran into a oom issue, kernel panic due to no killable process. The dmesg shows huge unreclaimable slabs used almost 100% memory, but kdump doesn't capture vmcore due to some reason. So, it may sound better to capture unreclaimable slab info in oom message when kernel panic to aid

[PATCH 0/2 v5] oom: capture unreclaimable slab info in oom message when kernel panic

Recently we ran into a oom issue, kernel panic due to no killable process. The dmesg shows huge unreclaimable slabs used almost 100% memory, but kdump doesn't capture vmcore due to some reason. So, it may sound better to capture unreclaimable slab info in oom message when kernel panic to aid

[PATCH 1/2] tools: slabinfo: add "-U" option to show unreclaimable slabs only

Add "-U" option to show unreclaimable slabs only. "-U" and "-S" together can tell us what unreclaimable slabs use the most memory to help debug huge unreclaimable slabs issue. Signed-off-by: Yang Shi Acked-by: Christoph Lameter Acked-by: David Rientjes

[PATCH 1/2] tools: slabinfo: add "-U" option to show unreclaimable slabs only

Add "-U" option to show unreclaimable slabs only. "-U" and "-S" together can tell us what unreclaimable slabs use the most memory to help debug huge unreclaimable slabs issue. Signed-off-by: Yang Shi Acked-by: Christoph Lameter Acked-by: David Rientjes --- tools/vm/slabinfo.c | 11

Re: [kernel-hardening] [PATCH v3 3/3] x86/fpu: reinitialize FPU registers if restoring FPU state fails

On Thu, 2017-09-21 at 11:52 -0700, Eric Biggers wrote: > From: Eric Biggers > > Userspace can change the FPU state of a task using the ptrace() or > rt_sigreturn() system calls.  Because reserved bits in the FPU state > can > cause the XRSTOR instruction to fail, the kernel

Re: [kernel-hardening] [PATCH v3 3/3] x86/fpu: reinitialize FPU registers if restoring FPU state fails

On Thu, 2017-09-21 at 11:52 -0700, Eric Biggers wrote: > From: Eric Biggers > > Userspace can change the FPU state of a task using the ptrace() or > rt_sigreturn() system calls.  Because reserved bits in the FPU state > can > cause the XRSTOR instruction to fail, the kernel has to carefully >

Re: [PATCH 4/4] ALSA: emu10k1: Cocci spatch "alloc_cast"

On Thu, 21 Sep 2017 19:39:15 +0200, Al Viro wrote: > > On Thu, Sep 21, 2017 at 08:33:46AM +0200, Thomas Meyer wrote: > > Remove casting the values returned by memory allocation functions like > > kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc." > > Found by coccinelle spatch

Re: [PATCH 4/4] ALSA: emu10k1: Cocci spatch "alloc_cast"

On Thu, 21 Sep 2017 19:39:15 +0200, Al Viro wrote: > > On Thu, Sep 21, 2017 at 08:33:46AM +0200, Thomas Meyer wrote: > > Remove casting the values returned by memory allocation functions like > > kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc." > > Found by coccinelle spatch

Re: [PATCH] KEYS: fix cred refcount leak in request_key_auth_new()

On Tue, Sep 19, 2017 at 04:46:08PM +0100, David Howells wrote: > Eric Biggers wrote: > > > In request_key_auth_new(), if alloc_key() or key_instantiate_and_link() > > were to fail, we would leak a reference to the 'struct cred'. Currently > > this can only happen if

Re: [PATCH] KEYS: fix cred refcount leak in request_key_auth_new()

On Tue, Sep 19, 2017 at 04:46:08PM +0100, David Howells wrote: > Eric Biggers wrote: > > > In request_key_auth_new(), if alloc_key() or key_instantiate_and_link() > > were to fail, we would leak a reference to the 'struct cred'. Currently > > this can only happen if alloc_key() fails to to

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