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
> ---
>
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
> ---
>
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
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
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
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
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
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?
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
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
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
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
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
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
> ---
>
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(-)
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
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
>
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
>
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
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
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
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
> ---
>
>
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.
>
>
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.
>
>
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.
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.
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.
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.
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.
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.
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.
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.
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
> ---
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
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
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
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
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
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
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.
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
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.
>
>
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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,
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
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
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
---
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
> >
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
> >
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
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
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
>
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
>
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
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
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
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
>
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
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
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
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
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:
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
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
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
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
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
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,
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,
> -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
>
> -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:
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:]
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:]
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
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
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
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
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
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
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
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
>
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
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
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
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
201 - 300 of 1688 matches
Mail list logo