Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

On Wed, 07 Mar 2018 13:46:24 -0800 Dave Hansen wrote: > From: Dave Hansen > > I think we need to soften the language a bit. It might scare folks > off, especially the: > >We prefer to fully disclose the bug as soon as

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

On Wed, 07 Mar 2018 13:46:24 -0800 Dave Hansen wrote: > From: Dave Hansen > > I think we need to soften the language a bit. It might scare folks > off, especially the: > >We prefer to fully disclose the bug as soon as possible. > > which is not really the case. Linus says: > >

Re: [PATCH v3 3/6] dt-bindings: soc: Add a binding for the Broadcom VCHIQ services. (v3)

Stefan Wahren writes: > Hi Eric, > >> Eric Anholt hat am 9. März 2018 um 19:44 geschrieben: >> >> >> The VCHIQ communication channel can be provided by BCM283x and Capri >> SoCs, to communicate with the VPU-side OS services. >> >> Signed-off-by: Eric

Re: [PATCH v3 3/6] dt-bindings: soc: Add a binding for the Broadcom VCHIQ services. (v3)

Stefan Wahren writes: > Hi Eric, > >> Eric Anholt hat am 9. März 2018 um 19:44 geschrieben: >> >> >> The VCHIQ communication channel can be provided by BCM283x and Capri >> SoCs, to communicate with the VPU-side OS services. >> >> Signed-off-by: Eric Anholt >> --- >> >> v2: VCHI->VCHIQ,

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

On 03/09/2018 02:40 PM, Mike Galbraith wrote: >>> >>> If v2 is to ever supersede v1, as is the normal way of things, core >>> functionality really should be on the v2 boat when it sails. What you >>> left standing on the dock is critical core cpuset functionality. >>> >>> -Mike >> From your

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

On 03/09/2018 02:40 PM, Mike Galbraith wrote: >>> >>> If v2 is to ever supersede v1, as is the normal way of things, core >>> functionality really should be on the v2 boat when it sails. What you >>> left standing on the dock is critical core cpuset functionality. >>> >>> -Mike >> From your

[PATCH] powerpc/64: Fix section mismatch warnings for early boot symbols

Some of the boot code located at the start of kernel text is "init" class, in that it only runs at boot time, however marking it as normal init code is problematic because that puts it into a different section located at the very end of kernel text. e.g., in case the TOC is not set up, we may not

[PATCH] powerpc/64: Fix section mismatch warnings for early boot symbols

Some of the boot code located at the start of kernel text is "init" class, in that it only runs at boot time, however marking it as normal init code is problematic because that puts it into a different section located at the very end of kernel text. e.g., in case the TOC is not set up, we may not

Re: [PATCH v3 3/6] dt-bindings: soc: Add a binding for the Broadcom VCHIQ services. (v3)

Hi Eric, > Eric Anholt hat am 9. März 2018 um 19:44 geschrieben: > > > The VCHIQ communication channel can be provided by BCM283x and Capri > SoCs, to communicate with the VPU-side OS services. > > Signed-off-by: Eric Anholt > --- > > v2: VCHI->VCHIQ,

Re: [PATCH v3 3/6] dt-bindings: soc: Add a binding for the Broadcom VCHIQ services. (v3)

Hi Eric, > Eric Anholt hat am 9. März 2018 um 19:44 geschrieben: > > > The VCHIQ communication channel can be provided by BCM283x and Capri > SoCs, to communicate with the VPU-side OS services. > > Signed-off-by: Eric Anholt > --- > > v2: VCHI->VCHIQ, dropped firmware property, added

Re: Warning from swake_up_all in 4.14.15-rt13 non-RT

On 2018-03-09 18:46:05 [+0100], Peter Zijlstra wrote: > On Fri, Mar 09, 2018 at 12:04:18PM +0100, Sebastian Andrzej Siewior wrote: > > +void swake_add_all_wq(struct swait_queue_head *q, struct wake_q_head *wq) > > { > > struct swait_queue *curr; > > > > while (!list_empty(>task_list)) {

Re: Warning from swake_up_all in 4.14.15-rt13 non-RT

On 2018-03-09 18:46:05 [+0100], Peter Zijlstra wrote: > On Fri, Mar 09, 2018 at 12:04:18PM +0100, Sebastian Andrzej Siewior wrote: > > +void swake_add_all_wq(struct swait_queue_head *q, struct wake_q_head *wq) > > { > > struct swait_queue *curr; > > > > while (!list_empty(>task_list)) {

Re: [PATCH] ASoC: soc-core: Add missing NULL check

On Fri, Mar 09, 2018 at 10:45:16AM -0800, Kees Cook wrote: > On Fri, Mar 9, 2018 at 4:50 AM, Mark Brown wrote: > > On Thu, Mar 08, 2018 at 12:06:53PM -0800, Kees Cook wrote: > >> If a codec is not attached to the sound soc, a NULL deref is possible as a > >> regular user in

Re: [PATCH] ASoC: soc-core: Add missing NULL check

On Fri, Mar 09, 2018 at 10:45:16AM -0800, Kees Cook wrote: > On Fri, Mar 9, 2018 at 4:50 AM, Mark Brown wrote: > > On Thu, Mar 08, 2018 at 12:06:53PM -0800, Kees Cook wrote: > >> If a codec is not attached to the sound soc, a NULL deref is possible as a > >> regular user in /sys. > > I can't

Re: [PATCH] ASoC: soc-core: Add missing NULL check

On Fri 2018-03-09 12:50:50, Mark Brown wrote: > On Thu, Mar 08, 2018 at 12:06:53PM -0800, Kees Cook wrote: > > > If a codec is not attached to the sound soc, a NULL deref is possible as a > > regular user in /sys. > > I can't parse this, sorry. What is the "sound soc"? > > > +++

Re: [PATCH] ASoC: soc-core: Add missing NULL check

On Fri 2018-03-09 12:50:50, Mark Brown wrote: > On Thu, Mar 08, 2018 at 12:06:53PM -0800, Kees Cook wrote: > > > If a codec is not attached to the sound soc, a NULL deref is possible as a > > regular user in /sys. > > I can't parse this, sorry. What is the "sound soc"? > > > +++

Re: [PATCH] rcu: exp: Fix "must hold exp_mutex" comments for QS reporting functions

On Fri, Mar 09, 2018 at 02:57:00PM +0800, Boqun Feng wrote: > On Thu, Mar 08, 2018 at 07:42:55AM -0800, Paul E. McKenney wrote: > > On Thu, Mar 08, 2018 at 04:30:06PM +0800, Boqun Feng wrote: > > > On Thu, Mar 08, 2018 at 12:54:29PM +0800, Boqun Feng wrote: > > > > On Wed, Mar 07, 2018 at

Re: [PATCH] rcu: exp: Fix "must hold exp_mutex" comments for QS reporting functions

On Fri, Mar 09, 2018 at 02:57:00PM +0800, Boqun Feng wrote: > On Thu, Mar 08, 2018 at 07:42:55AM -0800, Paul E. McKenney wrote: > > On Thu, Mar 08, 2018 at 04:30:06PM +0800, Boqun Feng wrote: > > > On Thu, Mar 08, 2018 at 12:54:29PM +0800, Boqun Feng wrote: > > > > On Wed, Mar 07, 2018 at

[RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support

From: Yuqiong Sun Add new CONFIG_IMA_NS config option. Let clone() create a new IMA namespace upon CLONE_NEWNS flag. Add ima_ns data structure in nsproxy. ima_ns is allocated and freed upon IMA namespace creation and exit. Currently, the ima_ns contains no useful IMA data but

[RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support

From: Yuqiong Sun Add new CONFIG_IMA_NS config option. Let clone() create a new IMA namespace upon CLONE_NEWNS flag. Add ima_ns data structure in nsproxy. ima_ns is allocated and freed upon IMA namespace creation and exit. Currently, the ima_ns contains no useful IMA data but only a dummy

[RFC PATCH v2 3/3] ima: mamespace audit status flags

From: Mehmet Kayaalp The iint cache stores whether the file is measured, appraised, audited etc. This patch moves the IMA_AUDITED flag into the per-namespace ns_status, enabling IMA audit mechanism to audit the same file each time it is accessed in a new namespace.

[RFC PATCH v2 3/3] ima: mamespace audit status flags

From: Mehmet Kayaalp The iint cache stores whether the file is measured, appraised, audited etc. This patch moves the IMA_AUDITED flag into the per-namespace ns_status, enabling IMA audit mechanism to audit the same file each time it is accessed in a new namespace. The ns_status is not looked

[RFC PATCH v2 2/3] ima: Add ns_status for storing namespaced iint data

From: Mehmet Kayaalp This patch adds an rbtree to the IMA namespace structure that stores a namespaced version of iint->flags in ns_status struct. Similar to the integrity_iint_cache, both the iint ns_struct are looked up using the inode pointer value. The lookup,

[RFC PATCH v2 2/3] ima: Add ns_status for storing namespaced iint data

From: Mehmet Kayaalp This patch adds an rbtree to the IMA namespace structure that stores a namespaced version of iint->flags in ns_status struct. Similar to the integrity_iint_cache, both the iint ns_struct are looked up using the inode pointer value. The lookup, allocate, and insertion code is

[RFC PATCH v2 0/3] ima: namespacing IMA

This patch set implements an IMA namespace data structure that gets created alongside a mount namespace with CLONE_NEWNS, and lays down the foundation for namespacing the different aspects of IMA (eg. IMA-audit, IMA-measurement, IMA-appraisal). The original PoC patches [1] created a new

[RFC PATCH v2 0/3] ima: namespacing IMA

This patch set implements an IMA namespace data structure that gets created alongside a mount namespace with CLONE_NEWNS, and lays down the foundation for namespacing the different aspects of IMA (eg. IMA-audit, IMA-measurement, IMA-appraisal). The original PoC patches [1] created a new

[PATCH v3] [media] Use common error handling code in 19 functions

From: Markus Elfring Date: Fri, 9 Mar 2018 21:00:12 +0100 Adjust jump targets so that a bit of exception handling can be better reused at the end of these functions. This issue was partly detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH v3] [media] Use common error handling code in 19 functions

From: Markus Elfring Date: Fri, 9 Mar 2018 21:00:12 +0100 Adjust jump targets so that a bit of exception handling can be better reused at the end of these functions. This issue was partly detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- v3: Laurent Pinchart and

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 09:43:32AM +0100, Ingo Molnar wrote: > > * Ram Pai wrote: > > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the contrary applications

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 09:43:32AM +0100, Ingo Molnar wrote: > > * Ram Pai wrote: > > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the contrary applications need the ability to do

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 09:19:53PM +1100, Michael Ellerman wrote: > Ram Pai writes: > > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the contrary applications

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 09:19:53PM +1100, Michael Ellerman wrote: > Ram Pai writes: > > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the contrary applications need the ability to do

[PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

When max() is used in stack array size calculations from literal values (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler thinks this is a dynamic calculation due to the single-eval logic, which is not needed in the literal case. This change removes several accidental stack

[PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

When max() is used in stack array size calculations from literal values (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler thinks this is a dynamic calculation due to the single-eval logic, which is not needed in the literal case. This change removes several accidental stack

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote: > On 03/09/2018 09:12 AM, Ram Pai wrote: > >Once an address range is associated with an allocated pkey, it cannot be > >reverted back to key-0. There is no valid reason for the above behavior. > > mprotect without a key does not

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote: > On 03/09/2018 09:12 AM, Ram Pai wrote: > >Once an address range is associated with an allocated pkey, it cannot be > >reverted back to key-0. There is no valid reason for the above behavior. > > mprotect without a key does not

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 07:37:04PM +1100, Balbir Singh wrote: > On Fri, Mar 9, 2018 at 7:12 PM, Ram Pai wrote: > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 07:37:04PM +1100, Balbir Singh wrote: > On Fri, Mar 9, 2018 at 7:12 PM, Ram Pai wrote: > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the contrary

Re: [PATCH v2] exec: Set file unwritable before LSM check

On Fri, Mar 9, 2018 at 11:47 AM, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 11:30 AM, Kees Cook wrote: >> The LSM check should happen after the file has been confirmed to be >> unchanging. Without this, we could have a race between the

Re: [PATCH v2] exec: Set file unwritable before LSM check

On Fri, Mar 9, 2018 at 11:47 AM, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 11:30 AM, Kees Cook wrote: >> The LSM check should happen after the file has been confirmed to be >> unchanging. Without this, we could have a race between the Time of Check >> (the call to

Re: [PATCH v3] input: bcm5974 - Add driver for Apple Magic Trackpad 2

Am Dienstag, 27. Februar 2018, 17:37:45 CET schrieb Stephan Mueller: Hi Jiri, Dimity, Henrik, > Am Sonntag, 21. Januar 2018, 23:06:55 CET schrieb Stephan Müller: > > Hi Jiri, Dimity, Henrik, > > > Hi, > > > > Changes v3: > > * port to 4.15-rc8 > > * small code cleanups (isolation of type

Re: [PATCH v3] input: bcm5974 - Add driver for Apple Magic Trackpad 2

Am Dienstag, 27. Februar 2018, 17:37:45 CET schrieb Stephan Mueller: Hi Jiri, Dimity, Henrik, > Am Sonntag, 21. Januar 2018, 23:06:55 CET schrieb Stephan Müller: > > Hi Jiri, Dimity, Henrik, > > > Hi, > > > > Changes v3: > > * port to 4.15-rc8 > > * small code cleanups (isolation of type

Re: [PATCH v2] exec: Set file unwritable before LSM check

On Fri, Mar 9, 2018 at 11:30 AM, Kees Cook wrote: > The LSM check should happen after the file has been confirmed to be > unchanging. Without this, we could have a race between the Time of Check > (the call to security_kernel_read_file() which could read the file and > make

Re: [PATCH v2] exec: Set file unwritable before LSM check

On Fri, Mar 9, 2018 at 11:30 AM, Kees Cook wrote: > The LSM check should happen after the file has been confirmed to be > unchanging. Without this, we could have a race between the Time of Check > (the call to security_kernel_read_file() which could read the file and > make access policy

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 7:38 PM, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds > wrote: >> >> How are you going to handle five processes doing the same setup concurrently? > > Side note: it's not just

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 7:38 PM, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds > wrote: >> >> How are you going to handle five processes doing the same setup concurrently? > > Side note: it's not just serialization. It's also "is it actually up > and running". > I think

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

On Fri, 2018-03-09 at 13:20 -0500, Waiman Long wrote: > On 03/09/2018 01:17 PM, Mike Galbraith wrote: > > On Fri, 2018-03-09 at 12:45 -0500, Waiman Long wrote: > >> On 03/09/2018 11:34 AM, Mike Galbraith wrote: > >>> On Fri, 2018-03-09 at 10:35 -0500, Waiman Long wrote: > Given the fact that

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

On Fri, 2018-03-09 at 13:20 -0500, Waiman Long wrote: > On 03/09/2018 01:17 PM, Mike Galbraith wrote: > > On Fri, 2018-03-09 at 12:45 -0500, Waiman Long wrote: > >> On 03/09/2018 11:34 AM, Mike Galbraith wrote: > >>> On Fri, 2018-03-09 at 10:35 -0500, Waiman Long wrote: > Given the fact that

RE: [PATCH v3 5/6] PCI: hv: hv_pci_devices_present(): only queue a new work when necessary

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc:

RE: [PATCH v3 5/6] PCI: hv: hv_pci_devices_present(): only queue a new work when necessary

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc: linux-kernel@vger.kernel.org;

RE: [PATCH v3 6/6] PCI: hv: fix 2 hang issues in hv_compose_msi_msg()

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc:

RE: [PATCH v3 6/6] PCI: hv: fix 2 hang issues in hv_compose_msi_msg()

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc: linux-kernel@vger.kernel.org;

RE: [PATCH v3 4/6] PCI: hv: remove hbus->enum_sem

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc:

RE: [PATCH v3 3/6] PCI: hv: serialize the present/eject work items

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc:

RE: [PATCH v3 4/6] PCI: hv: remove hbus->enum_sem

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc: linux-kernel@vger.kernel.org;

RE: [PATCH v3 3/6] PCI: hv: serialize the present/eject work items

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc: linux-kernel@vger.kernel.org;

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds wrote: > > How are you going to handle five processes doing the same setup concurrently? Side note: it's not just serialization. It's also "is it actually up and running". The rule for "request_module()" (for a real

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 6:55 PM, David Miller wrote: > From: Alexei Starovoitov > Date: Fri, 9 Mar 2018 10:50:49 -0800 > >> On 3/9/18 10:23 AM, Andy Lutomirski wrote: >>> It might not be totally crazy to back it by tmpfs. >> >> interesting. how do you propose to

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds wrote: > > How are you going to handle five processes doing the same setup concurrently? Side note: it's not just serialization. It's also "is it actually up and running". The rule for "request_module()" (for a real module) has been that it

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 6:55 PM, David Miller wrote: > From: Alexei Starovoitov > Date: Fri, 9 Mar 2018 10:50:49 -0800 > >> On 3/9/18 10:23 AM, Andy Lutomirski wrote: >>> It might not be totally crazy to back it by tmpfs. >> >> interesting. how do you propose to do it? >> Something like: >> -

RE: [PATCH v3 2/6] PCI: hv: hv_eject_device_work(): remove the bogus test

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc:

RE: [PATCH v3 1/6] PCI: hv: fix a comment typo in _hv_pcifront_read_config()

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc:

RE: [PATCH v3 2/6] PCI: hv: hv_eject_device_work(): remove the bogus test

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc: linux-kernel@vger.kernel.org;

RE: [PATCH v3 1/6] PCI: hv: fix a comment typo in _hv_pcifront_read_config()

> -Original Message- > From: Dexuan Cui > Sent: Tuesday, March 6, 2018 1:22 PM > To: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; a...@canonical.com; jasow...@redhat.com > Cc: linux-kernel@vger.kernel.org;

Re: [PATCH] perf tools arm64: Add libdw DWARF post unwind support for ARM64

Thanks. I replied to your message with additional information. I will update the commit message and resubmit the patch. MV On 03/09/18 14:29, Arnaldo Carvalho de Melo wrote: Em Fri, Mar 09, 2018 at 01:49:50PM -0500, Martin Vuille escreveu: Hi, I made two other submissions that may also

Re: [PATCH] perf tools arm64: Add libdw DWARF post unwind support for ARM64

Thanks. I replied to your message with additional information. I will update the commit message and resubmit the patch. MV On 03/09/18 14:29, Arnaldo Carvalho de Melo wrote: Em Fri, Mar 09, 2018 at 01:49:50PM -0500, Martin Vuille escreveu: Hi, I made two other submissions that may also

Re: [PATCH] ASoC: soc-core: Add missing NULL check

On Fri 2018-03-09 10:45:16, Kees Cook wrote: > On Fri, Mar 9, 2018 at 4:50 AM, Mark Brown wrote: > > On Thu, Mar 08, 2018 at 12:06:53PM -0800, Kees Cook wrote: > > > >> If a codec is not attached to the sound soc, a NULL deref is possible as a > >> regular user in /sys. > > >

Re: [PATCH] ASoC: soc-core: Add missing NULL check

On Fri 2018-03-09 10:45:16, Kees Cook wrote: > On Fri, Mar 9, 2018 at 4:50 AM, Mark Brown wrote: > > On Thu, Mar 08, 2018 at 12:06:53PM -0800, Kees Cook wrote: > > > >> If a codec is not attached to the sound soc, a NULL deref is possible as a > >> regular user in /sys. > > > > I can't parse

Re: [PATCH 2/3] bus: fsl-mc: add root dprc rescan attribute

On Wed, Mar 07, 2018 at 10:51:36AM -0600, Ioana Ciornei wrote: > Introduce the rescan attribute as a device attribute to > synchronize the fsl-mc bus objects and the MC firmware. > > To rescan the root dprc only, e.g. > echo 1 > /sys/bus/fsl-mc/devices/dprc.1/rescan > > Signed-off-by: Ioana

Re: [PATCH 2/3] bus: fsl-mc: add root dprc rescan attribute

On Wed, Mar 07, 2018 at 10:51:36AM -0600, Ioana Ciornei wrote: > Introduce the rescan attribute as a device attribute to > synchronize the fsl-mc bus objects and the MC firmware. > > To rescan the root dprc only, e.g. > echo 1 > /sys/bus/fsl-mc/devices/dprc.1/rescan > > Signed-off-by: Ioana

Re: [PATCH 1/3] bus: fsl-mc: add restool userspace support

On Wed, Mar 07, 2018 at 10:51:35AM -0600, Ioana Ciornei wrote: > Adding kernel support for restool, a userspace tool for resource > management, means exporting an ioctl capable device file representing > the root resource container. > This new functionality in the fsl-mc bus driver intends to

Re: [PATCH 1/3] bus: fsl-mc: add restool userspace support

On Wed, Mar 07, 2018 at 10:51:35AM -0600, Ioana Ciornei wrote: > Adding kernel support for restool, a userspace tool for resource > management, means exporting an ioctl capable device file representing > the root resource container. > This new functionality in the fsl-mc bus driver intends to

[PATCH v2] exec: Set file unwritable before LSM check

The LSM check should happen after the file has been confirmed to be unchanging. Without this, we could have a race between the Time of Check (the call to security_kernel_read_file() which could read the file and make access policy decisions) and the Time of Use (starting with kernel_read_file()'s

[PATCH v2] exec: Set file unwritable before LSM check

The LSM check should happen after the file has been confirmed to be unchanging. Without this, we could have a race between the Time of Check (the call to security_kernel_read_file() which could read the file and make access policy decisions) and the Time of Use (starting with kernel_read_file()'s

Re: [PATCH] perf tools arm64: Add libdw DWARF post unwind support for ARM64

Em Fri, Mar 09, 2018 at 01:49:50PM -0500, Martin Vuille escreveu: > Hi, > > I made two other submissions that may also have been overlooked: > > https://patchwork.kernel.org/patch/10211401/ -- This one has the S-o-B Ok, replied to that one, I can't see where is it that the symfs is being first

Re: [PATCH] perf tools arm64: Add libdw DWARF post unwind support for ARM64

Em Fri, Mar 09, 2018 at 01:49:50PM -0500, Martin Vuille escreveu: > Hi, > > I made two other submissions that may also have been overlooked: > > https://patchwork.kernel.org/patch/10211401/ -- This one has the S-o-B Ok, replied to that one, I can't see where is it that the symfs is being first

RE: [PATCH] clk: clk-fixed-factor: Use new macro CLK_OF_DECLARE_DRIVER

Hi Stephen, Thanks for the review. > -Original Message- > From: Stephen Boyd [mailto:sb...@kernel.org] > Sent: Friday, March 09, 2018 10:25 AM > To: Rajan Vaja ; mturque...@baylibre.com > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah >

RE: [PATCH] clk: clk-fixed-factor: Use new macro CLK_OF_DECLARE_DRIVER

Hi Stephen, Thanks for the review. > -Original Message- > From: Stephen Boyd [mailto:sb...@kernel.org] > Sent: Friday, March 09, 2018 10:25 AM > To: Rajan Vaja ; mturque...@baylibre.com > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah > ; Michal Simek ; Rajan

Re: [PATCH] perf annotate: Don't prepend symfs path to build_id_filename

dso__build_id_filename calls build_id_cache__linkname build_id_cache__linkname uses buildid_dir symbol__config_symfs includes the symfs directory in buildid_dir So it's not necessary to prepend it again. Should've included those notes in the original submission. Will do better next time.

Re: [PATCH] perf annotate: Don't prepend symfs path to build_id_filename

dso__build_id_filename calls build_id_cache__linkname build_id_cache__linkname uses buildid_dir symbol__config_symfs includes the symfs directory in buildid_dir So it's not necessary to prepend it again. Should've included those notes in the original submission. Will do better next time.

[GIT PULL] platform-drivers-x86 for 4.16-6

Hi Linus, This race condition discovery and the resulting fix landed later than I would have liked in the RC cycle, but I judged it worth fixing now rather than waiting for stable. The Dell drivers have some legacy dependencies we've been slowly untangling. I think a more invasive change should

[GIT PULL] platform-drivers-x86 for 4.16-6

Hi Linus, This race condition discovery and the resulting fix landed later than I would have liked in the RC cycle, but I judged it worth fixing now rather than waiting for stable. The Dell drivers have some legacy dependencies we've been slowly untangling. I think a more invasive change should

[PATCH 1/2] hwmon: (ucd9000) Add gpio chip interface

From: Christopher Bostic Add a struct gpio_chip and define some methods so that this device's I/O can be accessed via /sys/class/gpio. Signed-off-by: Christopher Bostic Signed-off-by: Andrew Jeffery Signed-off-by: Eddie

[PATCH 1/2] hwmon: (ucd9000) Add gpio chip interface

From: Christopher Bostic Add a struct gpio_chip and define some methods so that this device's I/O can be accessed via /sys/class/gpio. Signed-off-by: Christopher Bostic Signed-off-by: Andrew Jeffery Signed-off-by: Eddie James --- drivers/hwmon/pmbus/ucd9000.c | 220

[PATCH 2/2] hwmon: (ucd9000) Add debugfs attributes to provide mfr_status

From: Christopher Bostic Expose the gpiN_fault fields of mfr_status as individual debugfs attributes. This provides a way for users to be easily notified of gpi faults. Also provide the whole mfr_status register in debugfs. Signed-off-by: Christopher Bostic

[PATCH 2/2] hwmon: (ucd9000) Add debugfs attributes to provide mfr_status

From: Christopher Bostic Expose the gpiN_fault fields of mfr_status as individual debugfs attributes. This provides a way for users to be easily notified of gpi faults. Also provide the whole mfr_status register in debugfs. Signed-off-by: Christopher Bostic Signed-off-by: Andrew Jeffery

[PATCH 0/2] hwmon: (ucd9000) Add gpio and debugfs interfaces

The ucd9000 series chips have gpio pins. Add a gpio chip interface to the ucd device so that users can query and set the state of the gpio pins. Add a debugfs interface using the existing pmbus debugfs directory to provide MFR_STATUS and the status of the gpi faults to users. Christopher Bostic

[PATCH 0/2] hwmon: (ucd9000) Add gpio and debugfs interfaces

The ucd9000 series chips have gpio pins. Add a gpio chip interface to the ucd device so that users can query and set the state of the gpio pins. Add a debugfs interface using the existing pmbus debugfs directory to provide MFR_STATUS and the status of the gpi faults to users. Christopher Bostic

Re: [PATCH] perf tools arm64: Add libdw DWARF post unwind support for ARM64

Yes, thought of doing that. Unfortunately it was sent directly from git, so I do not have a copy of the message that was sent. MV On 03/09/18 14:15, Kim Phillips wrote: On Fri, 9 Mar 2018 13:49:50 -0500 Martin Vuille wrote: For

Re: [PATCH] perf tools arm64: Add libdw DWARF post unwind support for ARM64

Yes, thought of doing that. Unfortunately it was sent directly from git, so I do not have a copy of the message that was sent. MV On 03/09/18 14:15, Kim Phillips wrote: On Fri, 9 Mar 2018 13:49:50 -0500 Martin Vuille wrote: For https://patchwork.kernel.org/patch/10211483/, I'm not sure

Re: [PATCH v2] ARM: dts: BCM5301X: Add support for Linksys EA9500

Hi Vivek, On 03/02/2018 11:41 AM, Vivek Unune wrote: > Hardware Info > - > > Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz > Switch- BCM53012 in BCM4709C0KFEBG & external BCM53125 > DDR3 RAM - 256 MB > Flash - 128 MB (Toshiba

Re: [PATCH v2] ARM: dts: BCM5301X: Add support for Linksys EA9500

Hi Vivek, On 03/02/2018 11:41 AM, Vivek Unune wrote: > Hardware Info > - > > Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz > Switch- BCM53012 in BCM4709C0KFEBG & external BCM53125 > DDR3 RAM - 256 MB > Flash - 128 MB (Toshiba

Re: [PATCH] perf tools arm64: Add libdw DWARF post unwind support for ARM64

On Fri, 9 Mar 2018 13:49:50 -0500 Martin Vuille wrote: > For https://patchwork.kernel.org/patch/10211483/, I'm not sure how to go > about doing a reply to all. Hit reply-all from the copy in your Sent folder. Kim

Re: [PATCH] perf tools arm64: Add libdw DWARF post unwind support for ARM64

On Fri, 9 Mar 2018 13:49:50 -0500 Martin Vuille wrote: > For https://patchwork.kernel.org/patch/10211483/, I'm not sure how to go > about doing a reply to all. Hit reply-all from the copy in your Sent folder. Kim

Re: [PATCH] exec: Set file unwritable before LSM check

On Fri, Mar 9, 2018 at 11:07 AM, Kees Cook wrote: > The LSM check should happen after the file has been confirmed to be > unchanging. Without this, we could have a ToCToU issue between the > LSM verification and the actual contents of the file later. Can we please not add

Re: [PATCH] exec: Set file unwritable before LSM check

On Fri, Mar 9, 2018 at 11:07 AM, Kees Cook wrote: > The LSM check should happen after the file has been confirmed to be > unchanging. Without this, we could have a ToCToU issue between the > LSM verification and the actual contents of the file later. Can we please not add random crazy six-letter

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 10:57 AM, David Miller wrote: > > Once the helper UMH is invoked, it runs asynchronously taking eBPF > translation requests. How? Really. See my comment about mutual exclusion. The current patch is *broken* because it doesn't handle it. Really. Think

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 9, 2018 at 10:57 AM, David Miller wrote: > > Once the helper UMH is invoked, it runs asynchronously taking eBPF > translation requests. How? Really. See my comment about mutual exclusion. The current patch is *broken* because it doesn't handle it. Really. Think of it this way - you

Re: [tip:perf/core] perf/x86/intel: Disable userspace RDPMC usage for large PEBS

On Fri, 9 Mar 2018, Peter Zijlstra wrote: > On Fri, Mar 09, 2018 at 09:31:11AM -0500, Vince Weaver wrote: > > On Fri, 9 Mar 2018, tip-bot for Kan Liang wrote: > > > > > Commit-ID: 1af22eba248efe2de25658041a80a3d40fb3e92e > > > Gitweb: > > >

Re: [tip:perf/core] perf/x86/intel: Disable userspace RDPMC usage for large PEBS

On Fri, 9 Mar 2018, Peter Zijlstra wrote: > On Fri, Mar 09, 2018 at 09:31:11AM -0500, Vince Weaver wrote: > > On Fri, 9 Mar 2018, tip-bot for Kan Liang wrote: > > > > > Commit-ID: 1af22eba248efe2de25658041a80a3d40fb3e92e > > > Gitweb: > > >

<    5   6   7   8   9   10   11   12   13   14   >