[PATCH] net: dsa: loop: Check for memory allocation failure

If 'devm_kzalloc' fails, a NULL pointer will be dereferenced. Return -ENOMEM instead, as done for some other memory allocation just a few lines above. Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver") Signed-off-by: Christophe JAILLET ---

[PATCH] net: dsa: loop: Check for memory allocation failure

If 'devm_kzalloc' fails, a NULL pointer will be dereferenced. Return -ENOMEM instead, as done for some other memory allocation just a few lines above. Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver") Signed-off-by: Christophe JAILLET --- drivers/net/dsa/dsa_loop.c | 3 +++ 1 file changed, 3

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

On Fri, May 5, 2017 at 8:55 PM, Robin Murphy wrote: > On 04/05/17 19:41, Oza Oza wrote: > [...] 5) leaves scope of adding PCI flag handling for inbound memory by the new function. >>> >>> Which flags would ever actually matter? DMA windows aren't going to be >>> to

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

On Fri, May 5, 2017 at 8:55 PM, Robin Murphy wrote: > On 04/05/17 19:41, Oza Oza wrote: > [...] 5) leaves scope of adding PCI flag handling for inbound memory by the new function. >>> >>> Which flags would ever actually matter? DMA windows aren't going to be >>> to config or I/O space,

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

Hi Linus, On Fri, 5 May 2017 13:01:34 -0700 Linus Torvalds wrote: > > I actually would have preferred to not get any early merges, but what > I was unhappy about is that I also didn't really get any heads-up > about the cdev_device_add() conflict. > > I did get

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

Hi Linus, On Fri, 5 May 2017 13:01:34 -0700 Linus Torvalds wrote: > > I actually would have preferred to not get any early merges, but what > I was unhappy about is that I also didn't really get any heads-up > about the cdev_device_add() conflict. > > I did get notified about the other

Re: [PATCH] firmware: Google VPD: Fix memory allocation error handling

Le 05/05/2017 à 21:56, Greg KH a écrit : On Fri, May 05, 2017 at 09:08:44PM +0200, Christophe JAILLET wrote: This patch fixes several issues: - if the 1st 'kzalloc' fails, we dereference a NULL pointer - if the 2nd 'kzalloc' fails, there is a memory leak - if 'sysfs_create_bin_file'

Re: [PATCH] firmware: Google VPD: Fix memory allocation error handling

Le 05/05/2017 à 21:56, Greg KH a écrit : On Fri, May 05, 2017 at 09:08:44PM +0200, Christophe JAILLET wrote: This patch fixes several issues: - if the 1st 'kzalloc' fails, we dereference a NULL pointer - if the 2nd 'kzalloc' fails, there is a memory leak - if 'sysfs_create_bin_file'

Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

On Fri, May 05, 2017 at 09:42:40PM -0700, Joe Perches wrote: > On Fri, 2017-05-05 at 21:07 -0700, Greg KH wrote: > > From: Chris Fries > > > > Add %paP and %padP for physical address that need to always be shown > > regardless of kptr restrictions. > > The commit message

Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

On Fri, May 05, 2017 at 09:42:40PM -0700, Joe Perches wrote: > On Fri, 2017-05-05 at 21:07 -0700, Greg KH wrote: > > From: Chris Fries > > > > Add %paP and %padP for physical address that need to always be shown > > regardless of kptr restrictions. > > The commit message could be improved.

[PATCH] x86/boot: Correctly deeclare error() as noreturn

The compressed boot function error() is used to halt execution, but it wasn't marked with "noreturn". This fixes that in preparation for supporting kernel FORTIFY_SOURCE, which uses the noreturn annotation on panic, and calls error(). GCC would warn about a noreturn function calling a non-noreturn

[PATCH] x86/boot: Correctly deeclare error() as noreturn

The compressed boot function error() is used to halt execution, but it wasn't marked with "noreturn". This fixes that in preparation for supporting kernel FORTIFY_SOURCE, which uses the noreturn annotation on panic, and calls error(). GCC would warn about a noreturn function calling a non-noreturn

Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver

On Sat, May 6, 2017 at 6:49 AM, Bjorn Andersson wrote: > On Fri 05 May 13:22 PDT 2017, Jassi Brar wrote: >> How is it supposed to work if a client queues more than one request? > > One such example is found in patch 5 in this series. There are two FIFOs > in shared

Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver

On Sat, May 6, 2017 at 6:49 AM, Bjorn Andersson wrote: > On Fri 05 May 13:22 PDT 2017, Jassi Brar wrote: >> How is it supposed to work if a client queues more than one request? > > One such example is found in patch 5 in this series. There are two FIFOs > in shared memory, one in each direction.

Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

On Fri, 2017-05-05 at 21:07 -0700, Greg KH wrote: > From: Chris Fries > > Add %paP and %padP for physical address that need to always be shown > regardless of kptr restrictions. The commit message could be improved. I had to look at the actual code to see if %papP was

Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

On Fri, 2017-05-05 at 21:07 -0700, Greg KH wrote: > From: Chris Fries > > Add %paP and %padP for physical address that need to always be shown > regardless of kptr restrictions. The commit message could be improved. I had to look at the actual code to see if %papP was supported. > diff --git

Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

On 2017-05-05 17:47, Thomas Garnier wrote: On Fri, May 5, 2017 at 1:23 AM, Daniel Gruss wrote: On 04.05.2017 17:28, Thomas Garnier wrote: Please read the documentation on submitting patches [1] and coding style [2]. I will have a closer look at that. -

Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

On 2017-05-05 17:47, Thomas Garnier wrote: On Fri, May 5, 2017 at 1:23 AM, Daniel Gruss wrote: On 04.05.2017 17:28, Thomas Garnier wrote: Please read the documentation on submitting patches [1] and coding style [2]. I will have a closer look at that. - How this approach prevent the

[patch] device-dax: Tell kbuild DEV_DAX_PMEM depends on DEV_DAX

ERROR: "devm_create_dev_dax" [drivers/dax/dax_pmem.ko] undefined! ERROR: "alloc_dax_region" [drivers/dax/dax_pmem.ko] undefined! ERROR: "dax_region_put" [drivers/dax/dax_pmem.ko] undefined! Signed-off-by: Mike Galbraith --- drivers/dax/Kconfig |2 +- 1 file changed, 1

[patch] device-dax: Tell kbuild DEV_DAX_PMEM depends on DEV_DAX

ERROR: "devm_create_dev_dax" [drivers/dax/dax_pmem.ko] undefined! ERROR: "alloc_dax_region" [drivers/dax/dax_pmem.ko] undefined! ERROR: "dax_region_put" [drivers/dax/dax_pmem.ko] undefined! Signed-off-by: Mike Galbraith --- drivers/dax/Kconfig |2 +- 1 file changed, 1 insertion(+), 1

[RFC 6/6] drivers: uio: Un-restrict sysfs pointers for UIO

From: Chris Fries The addr and size on the UIO devices are required by userspace to function properly. Let's unrestrict these by adding the 'P' modifier to %p and %pa. Cc: William Roberts Cc: Dave Weinstein Signed-off-by:

[RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

From: Chris Fries Add %paP and %padP for physical address that need to always be shown regardless of kptr restrictions. Cc: William Roberts Cc: Dave Weinstein Signed-off-by: Chris Fries Signed-off-by: Greg

[RFC 6/6] drivers: uio: Un-restrict sysfs pointers for UIO

From: Chris Fries The addr and size on the UIO devices are required by userspace to function properly. Let's unrestrict these by adding the 'P' modifier to %p and %pa. Cc: William Roberts Cc: Dave Weinstein Signed-off-by: Chris Fries Signed-off-by: Greg Kroah-Hartman --- drivers/uio/uio.c

[RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options

From: Chris Fries Add %paP and %padP for physical address that need to always be shown regardless of kptr restrictions. Cc: William Roberts Cc: Dave Weinstein Signed-off-by: Chris Fries Signed-off-by: Greg Kroah-Hartman --- Documentation/printk-formats.txt | 10 ++ lib/vsprintf.c

[RFC 3/6] lib: vsprintf: physical address kernel pointer filtering options

From: Dave Weinstein Add the kptr_restrict setting of 4 which results in %pa and %p[rR] values being replaced by zeros. Cc: William Roberts Cc: Chris Fries Signed-off-by: Dave Weinstein Signed-off-by: Greg

[RFC 4/6] lib: vsprintf: default kptr_restrict to the maximum value

From: Dave Weinstein Set the initial value of kptr_restrict to the maximum setting rather than the minimum setting, to ensure that early boot logging is not leaking information. Cc: William Roberts Cc: Chris Fries

[RFC 3/6] lib: vsprintf: physical address kernel pointer filtering options

From: Dave Weinstein Add the kptr_restrict setting of 4 which results in %pa and %p[rR] values being replaced by zeros. Cc: William Roberts Cc: Chris Fries Signed-off-by: Dave Weinstein Signed-off-by: Greg Kroah-Hartman --- Documentation/sysctl/kernel.txt | 8 +++- kernel/sysctl.c

[RFC 4/6] lib: vsprintf: default kptr_restrict to the maximum value

From: Dave Weinstein Set the initial value of kptr_restrict to the maximum setting rather than the minimum setting, to ensure that early boot logging is not leaking information. Cc: William Roberts Cc: Chris Fries Signed-off-by: Dave Weinstein Signed-off-by: Greg Kroah-Hartman ---

[RFC 1/6] lib: vsprintf: additional kernel pointer filtering options

From: Dave Weinstein Add the kptr_restrict setting of 3 which results in both %p and %pK values being replaced by zeros. Add an additional %pP value inspired by the Grsecurity option which explicitly whitelists pointers for output. This patch is based on work by William

[RFC 1/6] lib: vsprintf: additional kernel pointer filtering options

From: Dave Weinstein Add the kptr_restrict setting of 3 which results in both %p and %pK values being replaced by zeros. Add an additional %pP value inspired by the Grsecurity option which explicitly whitelists pointers for output. This patch is based on work by William Roberts Cc: William

[RFC 2/6] lib: vsprintf: whitelist stack traces

From: Dave Weinstein Use the %pP functionality to explicitly allow kernel pointers to be logged for stack traces Cc: William Roberts Cc: Chris Fries Signed-off-by: Dave Weinstein Signed-off-by: Greg

[RFC 2/6] lib: vsprintf: whitelist stack traces

From: Dave Weinstein Use the %pP functionality to explicitly allow kernel pointers to be logged for stack traces Cc: William Roberts Cc: Chris Fries Signed-off-by: Dave Weinstein Signed-off-by: Greg Kroah-Hartman --- arch/arm64/kernel/traps.c | 4 ++-- include/linux/kallsyms.h | 2 +-

[RFC 00/06] printk: add more new kernel pointer filter options.

Here's a short patch series from Chris Fries and Dave Weinstein that implement some new restrictions when printing out kernel pointers, as well as the ability to whitelist kernel pointers where needed. These patches are based on work from William Roberts, and also is inspired by grsecurity's %pP

[RFC 00/06] printk: add more new kernel pointer filter options.

Here's a short patch series from Chris Fries and Dave Weinstein that implement some new restrictions when printing out kernel pointers, as well as the ability to whitelist kernel pointers where needed. These patches are based on work from William Roberts, and also is inspired by grsecurity's %pP

Re: [PATCH 4.4 00/20] 4.4.67-stable review

On Fri, May 05, 2017 at 07:58:50PM -0600, Shuah Khan wrote: > On 05/05/2017 12:32 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.67 release. > > There are 20 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.4 00/20] 4.4.67-stable review

On Fri, May 05, 2017 at 07:58:50PM -0600, Shuah Khan wrote: > On 05/05/2017 12:32 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.67 release. > > There are 20 patches in this series, all will be posted as a response > > to this one. If anyone has any

RE: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

> On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu > wrote: > > On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote: > >> On Fri, May 5, 2017 at 1:39 PM, Kani, Toshimitsu > >> wrote: > > : > >> > > --- > >> > > Changes since the initial RFC: > >> > > *

RE: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

> On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu > wrote: > > On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote: > >> On Fri, May 5, 2017 at 1:39 PM, Kani, Toshimitsu > >> wrote: > > : > >> > > --- > >> > > Changes since the initial RFC: > >> > > * s/writethru/wt/ since we already have

[Patch v3] x86/build: don't add -maccumulate-outgoing-args w/o compiler support

Clang does not support this machine dependent option. Older versions of GCC (pre 3.0) may not support this option, added in 2000, but it's unlikely they can still compile the kernel. Signed-off-by: Nick Desaulniers --- arch/x86/Makefile | 2 +- 1 file changed, 1

[Patch v3] x86/build: don't add -maccumulate-outgoing-args w/o compiler support

Clang does not support this machine dependent option. Older versions of GCC (pre 3.0) may not support this option, added in 2000, but it's unlikely they can still compile the kernel. Signed-off-by: Nick Desaulniers --- arch/x86/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu wrote: > On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote: >> On Fri, May 5, 2017 at 1:39 PM, Kani, Toshimitsu >> wrote: > : >> > > --- >> > > Changes since the initial RFC: >> > > * s/writethru/wt/

Re: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu wrote: > On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote: >> On Fri, May 5, 2017 at 1:39 PM, Kani, Toshimitsu >> wrote: > : >> > > --- >> > > Changes since the initial RFC: >> > > * s/writethru/wt/ since we already have ioremap_wt(), >> > >

Re: [PATCH] staging/media/atomisp/platform/intel-mid change spaces to tabs and comma/assignment space padding

Subject is too long. On Sat, May 06, 2017 at 04:04:50AM +0300, Gideon Sheril wrote: > /* The atomisp uses type==0 for the end-of-list marker, so leave space. */ > @@ -152,13 +152,13 @@ const struct camera_af_platform_data > *camera_get_af_platform_data(void) >

Re: [PATCH] staging/media/atomisp/platform/intel-mid change spaces to tabs and comma/assignment space padding

Subject is too long. On Sat, May 06, 2017 at 04:04:50AM +0300, Gideon Sheril wrote: > /* The atomisp uses type==0 for the end-of-list marker, so leave space. */ > @@ -152,13 +152,13 @@ const struct camera_af_platform_data > *camera_get_af_platform_data(void) >

Re: [PATCH 4.4 00/20] 4.4.67-stable review

On 05/05/2017 12:32 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.67 release. > There are 20 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/20] 4.4.67-stable review

On 05/05/2017 12:32 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.67 release. > There are 20 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/68] 3.18.52-stable review

On 05/05/2017 12:31 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.52 release. > There are 68 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/68] 3.18.52-stable review

On 05/05/2017 12:31 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.52 release. > There are 68 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: FIO performance regression in 4.11 kernel vs. 4.10 kernel observed on ARM64

Please note the 4.11 and 4.10 log results in my email were reversed - see correction below. Performance regression is observed - FIO performance in 4.11 is much less than 4.10 on ARM64 based platform. On 17-05-05 06:37 PM, Scott Branden wrote: I have updated the kernel to 4.11 and see

Re: FIO performance regression in 4.11 kernel vs. 4.10 kernel observed on ARM64

Please note the 4.11 and 4.10 log results in my email were reversed - see correction below. Performance regression is observed - FIO performance in 4.11 is much less than 4.10 on ARM64 based platform. On 17-05-05 06:37 PM, Scott Branden wrote: I have updated the kernel to 4.11 and see

FIO performance regression in 4.11 kernel vs. 4.10 kernel observed on ARM64

I have updated the kernel to 4.11 and see significant performance drops using fio-2.9. Using FIO the performanced drops from 281 KIOPS to 207 KIOPS using single core and task. Percent performance drop becomes even worse if multi-cores and multi- threads are used. Platform is ARM64 based A72.

FIO performance regression in 4.11 kernel vs. 4.10 kernel observed on ARM64

I have updated the kernel to 4.11 and see significant performance drops using fio-2.9. Using FIO the performanced drops from 281 KIOPS to 207 KIOPS using single core and task. Percent performance drop becomes even worse if multi-cores and multi- threads are used. Platform is ARM64 based A72.

[PATCH v5 1/3] mailbox: Make startup and shutdown ops optional

Some mailbox hardware doesn't have to perform any additional operations on startup of shutdown, so make these optional. Signed-off-by: Bjorn Andersson --- Changes since v4: - Inline the conditionals, rather than breaking them out into separate functions

[PATCH v5 1/3] mailbox: Make startup and shutdown ops optional

Some mailbox hardware doesn't have to perform any additional operations on startup of shutdown, so make these optional. Signed-off-by: Bjorn Andersson --- Changes since v4: - Inline the conditionals, rather than breaking them out into separate functions drivers/mailbox/mailbox.c | 16

[PATCH v5 3/3] mailbox: Introduce Qualcomm APCS IPC driver

This implements a driver that exposes the IPC bits found in the APCS Global block in various Qualcomm platforms. The bits are used to signal inter-processor communication signals from the application CPU to other masters. Signed-off-by: Bjorn Andersson --- Changes

[PATCH v5 2/3] dt-bindings: mailbox: Introduce Qualcomm APCS global binding

Introduce a binding for the Qualcomm APCS global block, exposing a mailbox for invoking interrupts on remote processors in the system. Signed-off-by: Bjorn Andersson --- Changes since v4: - None .../bindings/mailbox/qcom,apcs-kpss-global.txt | 46

[PATCH v5 3/3] mailbox: Introduce Qualcomm APCS IPC driver

This implements a driver that exposes the IPC bits found in the APCS Global block in various Qualcomm platforms. The bits are used to signal inter-processor communication signals from the application CPU to other masters. Signed-off-by: Bjorn Andersson --- Changes since v4: - Updated commit

[PATCH v5 2/3] dt-bindings: mailbox: Introduce Qualcomm APCS global binding

Introduce a binding for the Qualcomm APCS global block, exposing a mailbox for invoking interrupts on remote processors in the system. Signed-off-by: Bjorn Andersson --- Changes since v4: - None .../bindings/mailbox/qcom,apcs-kpss-global.txt | 46 ++ 1 file changed, 46

Re: drivers/pcmcia/Kconfig

Thanks for feedback! This appears to be my internal issue. 2017-05-06 4:10 GMT+03:00 Randy Dunlap : > On 05/05/17 17:45, as Bari wrote: >> PCCARD entry has menuconfig type. This makes it invisible from, for >> example, gconfig, and we get additional pcmcia modules in

Re: drivers/pcmcia/Kconfig

Thanks for feedback! This appears to be my internal issue. 2017-05-06 4:10 GMT+03:00 Randy Dunlap : > On 05/05/17 17:45, as Bari wrote: >> PCCARD entry has menuconfig type. This makes it invisible from, for >> example, gconfig, and we get additional pcmcia modules in builtin >> tree. This is

Re: RFC: WMI Enhancements

On Fri, May 5, 2017 at 5:51 PM, wrote: >> -Original Message- >> From: Darren Hart [mailto:dvh...@infradead.org] >> Sent: Friday, May 5, 2017 6:45 PM >> To: Limonciello, Mario >> Cc: pali.ro...@gmail.com; r...@rjwysocki.net;

Re: RFC: WMI Enhancements

On Fri, May 5, 2017 at 5:51 PM, wrote: >> -Original Message- >> From: Darren Hart [mailto:dvh...@infradead.org] >> Sent: Friday, May 5, 2017 6:45 PM >> To: Limonciello, Mario >> Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net; >> len.br...@intel.com;

[RELEASE] LTTng-modules 2.10.0-rc1 (KeKriek) and LTTng-UST 2.10.0-rc1 (KeKriek)

Hi, Here are release candidates 1 for LTTng kernel and user-space tracers 2.10. This release is named "KeKriek", which is a sour mashed golden wheat ale brewed by the Dunham microbrewery in Quebec. The new features included are: - A new "blocking" mode for LTTng-UST (it has been requested for a

[RELEASE] LTTng-modules 2.10.0-rc1 (KeKriek) and LTTng-UST 2.10.0-rc1 (KeKriek)

Hi, Here are release candidates 1 for LTTng kernel and user-space tracers 2.10. This release is named "KeKriek", which is a sour mashed golden wheat ale brewed by the Dunham microbrewery in Quebec. The new features included are: - A new "blocking" mode for LTTng-UST (it has been requested for a

Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver

On Fri 05 May 13:22 PDT 2017, Jassi Brar wrote: > On Sat, May 6, 2017 at 1:23 AM, Jeffrey Hugo wrote: > > On 5/5/2017 1:22 PM, Jassi Brar wrote: > >> > >> On Sat, May 6, 2017 at 12:07 AM, Bjorn Andersson > >> wrote: > >>> > > > > There is no way

Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver

On Fri 05 May 13:22 PDT 2017, Jassi Brar wrote: > On Sat, May 6, 2017 at 1:23 AM, Jeffrey Hugo wrote: > > On 5/5/2017 1:22 PM, Jassi Brar wrote: > >> > >> On Sat, May 6, 2017 at 12:07 AM, Bjorn Andersson > >> wrote: > >>> > > > > There is no way to determine if the remote processor has observed

Re: drivers/pcmcia/Kconfig

On 05/05/17 17:45, as Bari wrote: > PCCARD entry has menuconfig type. This makes it invisible from, for > example, gconfig, and we get additional pcmcia modules in builtin > tree. This is unexpected behaviour. > Looks like the entry was improperly refactored since 2.6.24. What kernel version are

Re: drivers/pcmcia/Kconfig

On 05/05/17 17:45, as Bari wrote: > PCCARD entry has menuconfig type. This makes it invisible from, for > example, gconfig, and we get additional pcmcia modules in builtin > tree. This is unexpected behaviour. > Looks like the entry was improperly refactored since 2.6.24. What kernel version are

[PATCH] staging/media/atomisp/platform/intel-mid change spaces to tabs and comma/assignment space padding

atomisp_gmin_platform.c: Fix ERROR: spaces instead of tabs and comma/assignment padding error. Signed-off-by: Gideon Sheril --- .../platform/intel-mid/atomisp_gmin_platform.c | 166 ++--- 1 file changed, 83 insertions(+), 83 deletions(-) diff --git

[PATCH] staging/media/atomisp/platform/intel-mid change spaces to tabs and comma/assignment space padding

atomisp_gmin_platform.c: Fix ERROR: spaces instead of tabs and comma/assignment padding error. Signed-off-by: Gideon Sheril --- .../platform/intel-mid/atomisp_gmin_platform.c | 166 ++--- 1 file changed, 83 insertions(+), 83 deletions(-) diff --git

RE: RFC: WMI Enhancements

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Friday, May 5, 2017 6:45 PM > To: Limonciello, Mario > Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net; > len.br...@intel.com; corentin.ch...@gmail.com;

RE: RFC: WMI Enhancements

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Friday, May 5, 2017 6:45 PM > To: Limonciello, Mario > Cc: pali.ro...@gmail.com; r...@rjwysocki.net; l...@amacapital.net; > len.br...@intel.com; corentin.ch...@gmail.com; l...@kernel.org; >

drivers/pcmcia/Kconfig

PCCARD entry has menuconfig type. This makes it invisible from, for example, gconfig, and we get additional pcmcia modules in builtin tree. This is unexpected behaviour. Looks like the entry was improperly refactored since 2.6.24. I would like to hear others' opinion.

drivers/pcmcia/Kconfig

PCCARD entry has menuconfig type. This makes it invisible from, for example, gconfig, and we get additional pcmcia modules in builtin tree. This is unexpected behaviour. Looks like the entry was improperly refactored since 2.6.24. I would like to hear others' opinion.

[ANNOUNCE] trace-cmd 2.6.1

Announce of trace-cmd 2.6.1 It's been a while since I released any official version of trace-cmd, and there's been lots of updates (although it took me a while to even push those up to the repo). Here's a brief list of what's happened since 2.6: trace-cmd record: --max-graph-depth has

[ANNOUNCE] trace-cmd 2.6.1

Announce of trace-cmd 2.6.1 It's been a while since I released any official version of trace-cmd, and there's been lots of updates (although it took me a while to even push those up to the repo). Here's a brief list of what's happened since 2.6: trace-cmd record: --max-graph-depth has

Re: RFC: WMI Enhancements

On Fri, May 05, 2017 at 09:55:46PM +, mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Darren Hart [mailto:dvh...@infradead.org] > > Sent: Thursday, April 20, 2017 3:45 PM > > To: Pali Rohár > > Cc: Limonciello, Mario

Re: RFC: WMI Enhancements

On Fri, May 05, 2017 at 09:55:46PM +, mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Darren Hart [mailto:dvh...@infradead.org] > > Sent: Thursday, April 20, 2017 3:45 PM > > To: Pali Rohár > > Cc: Limonciello, Mario ; r...@rjwysocki.net; > > l...@amacapital.net;

Re: [PATCH v2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

On Fri, May 05, 2017 at 09:42:14PM +0100, Matt Fleming wrote: > (Including the folks from SGI since this was hit on a UV system) Wasn't there a BIOS fix supplied at some point which obviated the need to boot with efi=old_map on SGI boxes? -- Regards/Gruss, Boris. Good mailing practices for

Re: [PATCH v2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

On Fri, May 05, 2017 at 09:42:14PM +0100, Matt Fleming wrote: > (Including the folks from SGI since this was hit on a UV system) Wasn't there a BIOS fix supplied at some point which obviated the need to boot with efi=old_map on SGI boxes? -- Regards/Gruss, Boris. Good mailing practices for

[PATCH] cxlflash: Select IRQ_POLL

The driver now uses IRQ_POLL and needs to select it to avoid the following build error. ERROR: ".irq_poll_complete" [drivers/scsi/cxlflash/cxlflash.ko] undefined! ERROR: ".irq_poll_sched" [drivers/scsi/cxlflash/cxlflash.ko] undefined! ERROR: ".irq_poll_disable" [drivers/scsi/cxlflash/cxlflash.ko]

[PATCH] cxlflash: Select IRQ_POLL

The driver now uses IRQ_POLL and needs to select it to avoid the following build error. ERROR: ".irq_poll_complete" [drivers/scsi/cxlflash/cxlflash.ko] undefined! ERROR: ".irq_poll_sched" [drivers/scsi/cxlflash/cxlflash.ko] undefined! ERROR: ".irq_poll_disable" [drivers/scsi/cxlflash/cxlflash.ko]

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

Joonas Lahtinen: > Filing a bug in freedesktop.org with all the details is the fastest way > of getting help. Without the bug (and with such little information as > the previous e-mail) it's hard to estimate the extent and nature of the > bug. My original report was

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

Joonas Lahtinen: > Filing a bug in freedesktop.org with all the details is the fastest way > of getting help. Without the bug (and with such little information as > the previous e-mail) it's hard to estimate the extent and nature of the > bug. My original report was

[PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This patchset introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch was inspired from GRKERNSEC_HARDEN_TTY. This patch would have prevented

[PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This patchset introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch was inspired from GRKERNSEC_HARDEN_TTY. This patch would have prevented

[PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch depends on patch 1/2 This patch was inspired from GRKERNSEC_HARDEN_TTY. This

[PATCH v6 1/2] security: tty: Add owner user namespace to tty_struct

This patch adds struct user_namespace *owner_user_ns to the tty_struct. Then it is set to current_user_ns() in the alloc_tty_struct function. This is done to facilitate capability checks against the original user namespace that allocated the tty. E.g. ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)

[PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch depends on patch 1/2 This patch was inspired from GRKERNSEC_HARDEN_TTY. This

[PATCH v6 1/2] security: tty: Add owner user namespace to tty_struct

This patch adds struct user_namespace *owner_user_ns to the tty_struct. Then it is set to current_user_ns() in the alloc_tty_struct function. This is done to facilitate capability checks against the original user namespace that allocated the tty. E.g. ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.12-1 tag

Linus Torvalds writes: > On Fri, May 5, 2017 at 6:20 AM, Michael Ellerman wrote: >> >> Also due to a screw-up on my part, we need a hunk added when you merge >> the powerpc tree with the KVM tree: >> >> diff --git

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.12-1 tag

Linus Torvalds writes: > On Fri, May 5, 2017 at 6:20 AM, Michael Ellerman wrote: >> >> Also due to a screw-up on my part, we need a hunk added when you merge >> the powerpc tree with the KVM tree: >> >> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c >> index

Re: [PATCH] scsi: qedf: Avoid reading past end of buffer

On Fri, May 5, 2017 at 4:01 PM, Bart Van Assche wrote: > On Fri, 2017-05-05 at 15:42 -0700, Kees Cook wrote: >> diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c >> index cceddd995a4b..a5c97342fd5d 100644 >> --- a/drivers/scsi/qedf/qedf_main.c

Re: [PATCH] scsi: qedf: Avoid reading past end of buffer

On Fri, May 5, 2017 at 4:01 PM, Bart Van Assche wrote: > On Fri, 2017-05-05 at 15:42 -0700, Kees Cook wrote: >> diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c >> index cceddd995a4b..a5c97342fd5d 100644 >> --- a/drivers/scsi/qedf/qedf_main.c >> +++

Re: [PATCH v3 1/7] iommu/arm-smmu-v3: Introduce SMMU option PAGE0_REGS_ONLY for ThunderX2 errata #74

On 05.05.17 17:38:05, Geetha sowjanya wrote: > From: Linu Cherian > > Cavium ThunderX2 SMMU implementation doesn't support page 1 register space > and PAGE0_REGS_ONLY option will be enabled as an errata workaround. > > This option when turned on, replaces all page 1

Re: [PATCH v3 1/7] iommu/arm-smmu-v3: Introduce SMMU option PAGE0_REGS_ONLY for ThunderX2 errata #74

On 05.05.17 17:38:05, Geetha sowjanya wrote: > From: Linu Cherian > > Cavium ThunderX2 SMMU implementation doesn't support page 1 register space > and PAGE0_REGS_ONLY option will be enabled as an errata workaround. > > This option when turned on, replaces all page 1 offsets used for >

Re: [PATCH] scsi: qedf: Avoid reading past end of buffer

On Fri, 2017-05-05 at 15:42 -0700, Kees Cook wrote: > diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c > index cceddd995a4b..a5c97342fd5d 100644 > --- a/drivers/scsi/qedf/qedf_main.c > +++ b/drivers/scsi/qedf/qedf_main.c > @@ -2895,7 +2895,7 @@ static int

Re: [PATCH] scsi: qedf: Avoid reading past end of buffer

On Fri, 2017-05-05 at 15:42 -0700, Kees Cook wrote: > diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c > index cceddd995a4b..a5c97342fd5d 100644 > --- a/drivers/scsi/qedf/qedf_main.c > +++ b/drivers/scsi/qedf/qedf_main.c > @@ -2895,7 +2895,7 @@ static int

[PATCH] perf, tools: Support srccode output

From: Andi Kleen When looking at PT or brstackinsn traces with perf script it can be very useful to see the source code. This adds a simple facility to print them with perf script, if the information is available through dwarf % perf record ... % perf script -F

[PATCH] perf, tools: Support srccode output

From: Andi Kleen When looking at PT or brstackinsn traces with perf script it can be very useful to see the source code. This adds a simple facility to print them with perf script, if the information is available through dwarf % perf record ... % perf script -F insn,ip,sym,srccode ...

  1   2   3   4   5   6   7   8   9   10   >