Re: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

On Tue, Oct 4, 2016 at 12:06 PM, Davidlohr Bueso wrote: > On Thu, 18 Aug 2016, Waiman Long wrote: > >> The osq_lock() and osq_unlock() function may not provide the necessary >> acquire and release barrier in some cases. This patch makes sure >> that the proper barriers are

Re: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

On Tue, Oct 4, 2016 at 12:06 PM, Davidlohr Bueso wrote: > On Thu, 18 Aug 2016, Waiman Long wrote: > >> The osq_lock() and osq_unlock() function may not provide the necessary >> acquire and release barrier in some cases. This patch makes sure >> that the proper barriers are provided when

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

Quoting Tejun Heo (t...@kernel.org): > Hello, Serge. > > On Tue, Oct 04, 2016 at 03:18:40PM -0500, Serge E. Hallyn wrote: > > how about changing the GLOBAL_ROOT_UID check with a targeted > > capability check, like > > > > if (!ns_capable(tcred->user_ns, CAP_SYS_NICE) && > >

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

Quoting Tejun Heo (t...@kernel.org): > Hello, Serge. > > On Tue, Oct 04, 2016 at 03:18:40PM -0500, Serge E. Hallyn wrote: > > how about changing the GLOBAL_ROOT_UID check with a targeted > > capability check, like > > > > if (!ns_capable(tcred->user_ns, CAP_SYS_NICE) && > >

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 05:00:20AM, Vincent Guittot wrote: > > Matt, > > May be you can try this patch which uses utilization in > find_idlest_group. So even if runnable_load_avg is null, the > utilization should not and another cpu will be chosen > https://patchwork.kernel.org/patch/9306939/

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 05:00:20AM, Vincent Guittot wrote: > > Matt, > > May be you can try this patch which uses utilization in > find_idlest_group. So even if runnable_load_avg is null, the > utilization should not and another cpu will be chosen > https://patchwork.kernel.org/patch/9306939/

RE: [PATCH 1/2 v3] pci-hyperv: properly handle pci bus remove

> -Original Message- > From: Long Li > Sent: Monday, October 3, 2016 11:43 PM > To: KY Srinivasan ; Haiyang Zhang > ; Bjorn Helgaas > Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux- >

RE: [PATCH 1/2 v3] pci-hyperv: properly handle pci bus remove

> -Original Message- > From: Long Li > Sent: Monday, October 3, 2016 11:43 PM > To: KY Srinivasan ; Haiyang Zhang > ; Bjorn Helgaas > Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; Long Li > Subject: [PATCH 1/2 v3] pci-hyperv: properly

[PATCH V2 2/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts

The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements") removed PCI_USING penalty from acpi_pci_link_allocate function as there is no longer a fixed size penalty array for both PCI and IRQ interrupts. We need to add the PCI_USING penalty for ISA interrupts too

[PATCH V2 2/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts

The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements") removed PCI_USING penalty from acpi_pci_link_allocate function as there is no longer a fixed size penalty array for both PCI and IRQ interrupts. We need to add the PCI_USING penalty for ISA interrupts too

[PATCH V2 1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"

This reverts commit 5c5087a55390 ("ACPI,PCI,IRQ: reduce static IRQ array size to 16"). The code maintains a fixed size array for IRQ penalties. The array gets updated by external calls such as acpi_penalize_sci_irq, acpi_penalize_isa_irq to reflect the actual interrupt usage of the system. Since

[PATCH V2 3/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"

The SCI function was removed in two steps (first refactor and then remove). This patch does the revert in one step. The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements") refactored the original code so that SCI penalty is calculated dynamically by the time get_penalty function is

[PATCH V2 1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"

This reverts commit 5c5087a55390 ("ACPI,PCI,IRQ: reduce static IRQ array size to 16"). The code maintains a fixed size array for IRQ penalties. The array gets updated by external calls such as acpi_penalize_sci_irq, acpi_penalize_isa_irq to reflect the actual interrupt usage of the system. Since

[PATCH V2 3/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"

The SCI function was removed in two steps (first refactor and then remove). This patch does the revert in one step. The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements") refactored the original code so that SCI penalty is calculated dynamically by the time get_penalty function is

Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver

On Tue, Oct 04, 2016 at 04:58:37PM -0400, Rich Felker wrote: > On Tue, Oct 04, 2016 at 12:06:23AM -0700, Paul E. McKenney wrote: > > On Mon, Oct 03, 2016 at 06:10:39PM -0400, Rich Felker wrote: > > > On Mon, Sep 26, 2016 at 11:27:14PM +0200, Daniel Lezcano wrote: > > > > On 26/09/2016 23:07, Rich

Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver

On Tue, Oct 04, 2016 at 04:58:37PM -0400, Rich Felker wrote: > On Tue, Oct 04, 2016 at 12:06:23AM -0700, Paul E. McKenney wrote: > > On Mon, Oct 03, 2016 at 06:10:39PM -0400, Rich Felker wrote: > > > On Mon, Sep 26, 2016 at 11:27:14PM +0200, Daniel Lezcano wrote: > > > > On 26/09/2016 23:07, Rich

[RFC PATCH v2 2/2] printk: external log buffer (CONFIG_LOGBUFFER)

This debug feature provides a convenient way to collect log entries across multiple, warmboot cycles and to share those entries with a boot loader. It allows the kernel to use an external buffer for kernel log messages and is controlled by an optional command line parameter. The buffer can contain

[RFC PATCH v2 1/2] printk: collect offsets into replaceable structure

Currently, printk relies on several indices that are declared as static global variables in printk.c. This patch collects those into a single structure referenced by a pointer. This allows easier replacement of these indices and pinning to a specific locatino. Signed-off-by: Sean Hudson

[RFC PATCH v2 2/2] printk: external log buffer (CONFIG_LOGBUFFER)

This debug feature provides a convenient way to collect log entries across multiple, warmboot cycles and to share those entries with a boot loader. It allows the kernel to use an external buffer for kernel log messages and is controlled by an optional command line parameter. The buffer can contain

[RFC PATCH v2 1/2] printk: collect offsets into replaceable structure

Currently, printk relies on several indices that are declared as static global variables in printk.c. This patch collects those into a single structure referenced by a pointer. This allows easier replacement of these indices and pinning to a specific locatino. Signed-off-by: Sean Hudson ---

[RFC PATCH v2 0/2] printk: Shared kernel logging

This patch set is based on Linus' v4.8-rc8 tag. This debug feature allows the kernel to use an external buffer and control block for kernel log messages. The feature is controlled by an optional command line parameter. The existing buffer and control block can contain existing log messages from

[RFC PATCH v2 0/2] printk: Shared kernel logging

This patch set is based on Linus' v4.8-rc8 tag. This debug feature allows the kernel to use an external buffer and control block for kernel log messages. The feature is controlled by an optional command line parameter. The existing buffer and control block can contain existing log messages from

Re: [PATCHv1] hwmon: adm9240: handle temperature readings below 0

On 10/05/2016 09:54 AM, Guenter Roeck wrote: > On Tue, Oct 04, 2016 at 05:08:00PM +1300, Chris Packham wrote: >> Unlike the temperature thresholds the temperature data is a 9-bit signed >> value. This allows and additional 0.5 degrees of precision on the >> reading but means we can't rely on

Re: [PATCHv1] hwmon: adm9240: handle temperature readings below 0

On 10/05/2016 09:54 AM, Guenter Roeck wrote: > On Tue, Oct 04, 2016 at 05:08:00PM +1300, Chris Packham wrote: >> Unlike the temperature thresholds the temperature data is a 9-bit signed >> value. This allows and additional 0.5 degrees of precision on the >> reading but means we can't rely on

Re: [PATCH 07/15] clk: sunxi: mod0: improve function-level documentation

On Sat, Oct 01, 2016 at 09:46:24PM +0200, Julia Lawall wrote: > Use the actual function name in the function documentation. > > Issue detected using Coccinelle (http://coccinelle.lip6.fr/) > > Signed-off-by: Julia Lawall Applied, thanks! Maxime -- Maxime Ripard, Free

Re: [PATCH 07/15] clk: sunxi: mod0: improve function-level documentation

On Sat, Oct 01, 2016 at 09:46:24PM +0200, Julia Lawall wrote: > Use the actual function name in the function documentation. > > Issue detected using Coccinelle (http://coccinelle.lip6.fr/) > > Signed-off-by: Julia Lawall Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux

Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver

On Tue, Oct 04, 2016 at 12:06:23AM -0700, Paul E. McKenney wrote: > On Mon, Oct 03, 2016 at 06:10:39PM -0400, Rich Felker wrote: > > On Mon, Sep 26, 2016 at 11:27:14PM +0200, Daniel Lezcano wrote: > > > On 26/09/2016 23:07, Rich Felker wrote: > > > > Ping. Is there anything that still needs to be

Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver

On Tue, Oct 04, 2016 at 12:06:23AM -0700, Paul E. McKenney wrote: > On Mon, Oct 03, 2016 at 06:10:39PM -0400, Rich Felker wrote: > > On Mon, Sep 26, 2016 at 11:27:14PM +0200, Daniel Lezcano wrote: > > > On 26/09/2016 23:07, Rich Felker wrote: > > > > Ping. Is there anything that still needs to be

Re: [PATCHv1] hwmon: adm9240: handle temperature readings below 0

On Tue, Oct 04, 2016 at 05:08:00PM +1300, Chris Packham wrote: > Unlike the temperature thresholds the temperature data is a 9-bit signed > value. This allows and additional 0.5 degrees of precision on the > reading but means we can't rely on sign-extension to handle negative > values. > >

Re: [PATCHv1] hwmon: adm9240: handle temperature readings below 0

On Tue, Oct 04, 2016 at 05:08:00PM +1300, Chris Packham wrote: > Unlike the temperature thresholds the temperature data is a 9-bit signed > value. This allows and additional 0.5 degrees of precision on the > reading but means we can't rely on sign-extension to handle negative > values. > >

[PATCH] staging: i4l: icn: fixed some errors and warnings caught by checkpatch.pl

2 errors "open brace { should be on the previous line" are fixed. Warning "Prefer "pr_debug over printk(KERN_DEBUG... " fixed Few line more tahn 80 character warnings fixed Signed-off-by: Harman Kalra --- drivers/staging/i4l/icn/icn.c |3 +--

[PATCH] staging: i4l: icn: fixed some errors and warnings caught by checkpatch.pl

2 errors "open brace { should be on the previous line" are fixed. Warning "Prefer "pr_debug over printk(KERN_DEBUG... " fixed Few line more tahn 80 character warnings fixed Signed-off-by: Harman Kalra --- drivers/staging/i4l/icn/icn.c |3 +-- drivers/staging/i4l/icn/icn.h |7 --- 2

RE: [PATCH 2/2 v3] pci-hyperv: lock pci bus on device eject

> -Original Message- > From: Long Li > Sent: Monday, October 3, 2016 11:43 PM > To: KY Srinivasan ; Haiyang Zhang > ; Bjorn Helgaas > Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux- >

RE: [PATCH 2/2 v3] pci-hyperv: lock pci bus on device eject

> -Original Message- > From: Long Li > Sent: Monday, October 3, 2016 11:43 PM > To: KY Srinivasan ; Haiyang Zhang > ; Bjorn Helgaas > Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; Long Li > Subject: [PATCH 2/2 v3] pci-hyperv: lock pci bus

Re: Regression in next with ext4 oops

* Kalle Valo [161004 12:42]: > Tony Lindgren writes: > > > * Tony Lindgren [161004 12:17]: > >> Hi, > >> > >> * Al Viro [161004 08:00]: > >> > On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote: >

Re: Regression in next with ext4 oops

* Kalle Valo [161004 12:42]: > Tony Lindgren writes: > > > * Tony Lindgren [161004 12:17]: > >> Hi, > >> > >> * Al Viro [161004 08:00]: > >> > On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote: > >> > > On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote: > >> > > > Never

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

Hello, Serge. On Tue, Oct 04, 2016 at 03:18:40PM -0500, Serge E. Hallyn wrote: > how about changing the GLOBAL_ROOT_UID check with a targeted > capability check, like > > if (!ns_capable(tcred->user_ns, CAP_SYS_NICE) && > !uid_eq(cred->euid, tcred->uid) && >

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

Hello, Serge. On Tue, Oct 04, 2016 at 03:18:40PM -0500, Serge E. Hallyn wrote: > how about changing the GLOBAL_ROOT_UID check with a targeted > capability check, like > > if (!ns_capable(tcred->user_ns, CAP_SYS_NICE) && > !uid_eq(cred->euid, tcred->uid) && >

Re: [RFC PATCH] mm, compaction: allow compaction for GFP_NOFS requests

On Tue, Oct 04, 2016 at 10:12:15AM +0200, Michal Hocko wrote: > From: Michal Hocko > > compaction has been disabled for GFP_NOFS and GFP_NOIO requests since > the direct compaction was introduced by 56de7263fcf3 ("mm: compaction: > direct compact when a high-order allocation

Re: [RFC PATCH] mm, compaction: allow compaction for GFP_NOFS requests

On Tue, Oct 04, 2016 at 10:12:15AM +0200, Michal Hocko wrote: > From: Michal Hocko > > compaction has been disabled for GFP_NOFS and GFP_NOIO requests since > the direct compaction was introduced by 56de7263fcf3 ("mm: compaction: > direct compact when a high-order allocation fails"). The main

Re: [PATCH V3 00/11] block-throttle: add .high limit

Hello, Paolo. On Tue, Oct 04, 2016 at 09:29:48PM +0200, Paolo Valente wrote: > > Hmm... I think we already discussed this but here's a really simple > > case. There are three unknown workloads A, B and C and we want to > > give A certain best-effort guarantees (let's say around 80% of the > >

Re: [PATCH V3 00/11] block-throttle: add .high limit

Hello, Paolo. On Tue, Oct 04, 2016 at 09:29:48PM +0200, Paolo Valente wrote: > > Hmm... I think we already discussed this but here's a really simple > > case. There are three unknown workloads A, B and C and we want to > > give A certain best-effort guarantees (let's say around 80% of the > >

Re: [PATCH v3 4/5] powerpc/mm: restore top-down allocation when using movable_node

On Tue, Oct 04, 2016 at 11:48:30AM +1100, Balbir Singh wrote: On 27/09/16 10:14, Reza Arbab wrote: Right. To be clear, the background info I put in the commit log refers to x86, where the SRAT can describe movable nodes which exist at boot. They're trying to avoid allocations from those nodes

Re: [PATCH v3 4/5] powerpc/mm: restore top-down allocation when using movable_node

On Tue, Oct 04, 2016 at 11:48:30AM +1100, Balbir Singh wrote: On 27/09/16 10:14, Reza Arbab wrote: Right. To be clear, the background info I put in the commit log refers to x86, where the SRAT can describe movable nodes which exist at boot. They're trying to avoid allocations from those nodes

[PATCH] x86/vmware: Skip lapic calibration on VMware.

In virtualized environment the APIC timer calibration could go wrong when the host is overcommitted or the guest is running nested, this would result in the APIC timers operating at an incorrect frequency. Since VMware supports a mechanism to retrieve the local APIC frequency we can ask the

[PATCH] x86/vmware: Skip lapic calibration on VMware.

In virtualized environment the APIC timer calibration could go wrong when the host is overcommitted or the guest is running nested, this would result in the APIC timers operating at an incorrect frequency. Since VMware supports a mechanism to retrieve the local APIC frequency we can ask the

Re: [PATCH 05/17] README: convert it to ReST markup

On Tue, Oct 4, 2016 at 4:42 PM, Diego Viola wrote: > On Wed, Sep 21, 2016 at 4:09 PM, Mauro Carvalho Chehab > wrote: >> Adjust the readme file for it to use the ReST markup: >> >> - add chapter/section markups; >> - use ``foo`` for commands; >> -

Re: [PATCH 05/17] README: convert it to ReST markup

On Tue, Oct 4, 2016 at 4:42 PM, Diego Viola wrote: > On Wed, Sep 21, 2016 at 4:09 PM, Mauro Carvalho Chehab > wrote: >> Adjust the readme file for it to use the ReST markup: >> >> - add chapter/section markups; >> - use ``foo`` for commands; >> - use :: for verbatim and script blocks; >> -

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

Quoting Tejun Heo (t...@kernel.org): > Hello, John. > > On Tue, Oct 04, 2016 at 11:01:12AM -0700, John Stultz wrote: > > So to make sure I understand your suggestion, you're suggesting the > > cgroupfs files like: > > cpuctrl/tasks, > > cpuctrl/bg_non_interactive/tasks, > >

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

Quoting Tejun Heo (t...@kernel.org): > Hello, John. > > On Tue, Oct 04, 2016 at 11:01:12AM -0700, John Stultz wrote: > > So to make sure I understand your suggestion, you're suggesting the > > cgroupfs files like: > > cpuctrl/tasks, > > cpuctrl/bg_non_interactive/tasks, > >

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 04:46:06AM, Vincent Guittot wrote: > > ok so i'm a bit confused there > my understand of your explanation above is that now we left a small > amount of load in runnable_load_avg after the dequeue so another cpu > will be chosen. But this explanation seems to be the opposite of

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 04:46:06AM, Vincent Guittot wrote: > > ok so i'm a bit confused there > my understand of your explanation above is that now we left a small > amount of load in runnable_load_avg after the dequeue so another cpu > will be chosen. But this explanation seems to be the opposite of

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 12:14:22PM, Peter Zijlstra wrote: > On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote: > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 8fb4d1942c14..4a2d3ff772f8 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -3142,7

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 12:14:22PM, Peter Zijlstra wrote: > On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote: > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 8fb4d1942c14..4a2d3ff772f8 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -3142,7

Re: [PATCH V2 2/2] fs/super.c: don't fool lockdep in freeze_super() and thaw_super() paths

On Tue, Oct 04, 2016 at 06:58:27PM +0200, Oleg Nesterov wrote: > I removed this test and then the next run (after reboot) hangs at xfs/073 with > a lot of errors in dmesg like > > XFS (loop2): Failing async write on buffer block 0x9600790. Retrying > async write. >

Re: [PATCH V2 2/2] fs/super.c: don't fool lockdep in freeze_super() and thaw_super() paths

On Tue, Oct 04, 2016 at 06:58:27PM +0200, Oleg Nesterov wrote: > I removed this test and then the next run (after reboot) hangs at xfs/073 with > a lot of errors in dmesg like > > XFS (loop2): Failing async write on buffer block 0x9600790. Retrying > async write. >

Re: [PATCH v6 1/3] usb: ohci-da8xx: Remove code that references mach

On Tue, Oct 04, 2016 at 12:30:58PM -0500, David Lechner wrote: > On 10/04/2016 08:38 AM, Greg Kroah-Hartman wrote: > > On Tue, Oct 04, 2016 at 11:18:03AM +0200, Kevin Hilman wrote: > > > Hi Greg, > > > > > > On Mon, Sep 5, 2016 at 10:00 PM, David Lechner > > > wrote: > > >

Re: [PATCH v6 1/3] usb: ohci-da8xx: Remove code that references mach

On Tue, Oct 04, 2016 at 12:30:58PM -0500, David Lechner wrote: > On 10/04/2016 08:38 AM, Greg Kroah-Hartman wrote: > > On Tue, Oct 04, 2016 at 11:18:03AM +0200, Kevin Hilman wrote: > > > Hi Greg, > > > > > > On Mon, Sep 5, 2016 at 10:00 PM, David Lechner > > > wrote: > > > > Including mach/* is

Re: [PATCH V3 00/11] block-throttle: add .high limit

> Il giorno 04 ott 2016, alle ore 20:28, Shaohua Li ha scritto: > > On Tue, Oct 04, 2016 at 07:43:48PM +0200, Paolo Valente wrote: >> >>> Il giorno 04 ott 2016, alle ore 19:28, Shaohua Li ha scritto: >>> >>> On Tue, Oct 04, 2016 at 07:01:39PM +0200, Paolo Valente

Re: [PATCH V3 00/11] block-throttle: add .high limit

> Il giorno 04 ott 2016, alle ore 20:28, Shaohua Li ha scritto: > > On Tue, Oct 04, 2016 at 07:43:48PM +0200, Paolo Valente wrote: >> >>> Il giorno 04 ott 2016, alle ore 19:28, Shaohua Li ha scritto: >>> >>> On Tue, Oct 04, 2016 at 07:01:39PM +0200, Paolo Valente wrote: > Il giorno

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

Hello, On Tue, Oct 04, 2016 at 12:46:24PM -0700, John Stultz wrote: > Ok. I'll respin this introducing and using a new CAP value. > > That said, while CAP_SYS_NICE seems a bit overloaded here, it doesn't > conceptually have that much friction for use with cpuset and cpuctrl > cgroups: We need

Re: [PATCH] usb/core: Added devspec sysfs entry for devices behind usb hub

On Tue, Oct 04, 2016 at 12:04:40PM -0700, Vijay Kumar wrote: > Grub finds incorrect of_node path for devices behind usb hub. > Added devspec sysfs entry for devices behind usb hub so that > right of_node path is returned during grub sysfs walk for these > devices. > > Signed-off-by: Vijay Kumar

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

Hello, On Tue, Oct 04, 2016 at 12:46:24PM -0700, John Stultz wrote: > Ok. I'll respin this introducing and using a new CAP value. > > That said, while CAP_SYS_NICE seems a bit overloaded here, it doesn't > conceptually have that much friction for use with cpuset and cpuctrl > cgroups: We need

Re: [PATCH] usb/core: Added devspec sysfs entry for devices behind usb hub

On Tue, Oct 04, 2016 at 12:04:40PM -0700, Vijay Kumar wrote: > Grub finds incorrect of_node path for devices behind usb hub. > Added devspec sysfs entry for devices behind usb hub so that > right of_node path is returned during grub sysfs walk for these > devices. > > Signed-off-by: Vijay Kumar

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

On Tue, Oct 4, 2016 at 12:38 PM, Tejun Heo wrote: > Hello, John. > > On Tue, Oct 04, 2016 at 11:01:12AM -0700, John Stultz wrote: >> So to make sure I understand your suggestion, you're suggesting the >> cgroupfs files like: >> cpuctrl/tasks, >> cpuctrl/bg_non_interactive/tasks,

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

On Tue, Oct 4, 2016 at 12:38 PM, Tejun Heo wrote: > Hello, John. > > On Tue, Oct 04, 2016 at 11:01:12AM -0700, John Stultz wrote: >> So to make sure I understand your suggestion, you're suggesting the >> cgroupfs files like: >> cpuctrl/tasks, >> cpuctrl/bg_non_interactive/tasks, >>

[PATCH] lib: crc-itu-t: Fix polynomial comment

The hexidecimal representation (0x1021) can be a bit confusing because the leading 1 (x^16) is not shown. 0x1021 | ||_ x^0 (Usually known as 1) | |__ x^5 | x^12 x^16 (Implicit in size of CRC) Signed-off-by: Chris Lesiak --- include/linux/crc-itu-t.h |

[PATCH] lib: crc-itu-t: Fix polynomial comment

The hexidecimal representation (0x1021) can be a bit confusing because the leading 1 (x^16) is not shown. 0x1021 | ||_ x^0 (Usually known as 1) | |__ x^5 | x^12 x^16 (Implicit in size of CRC) Signed-off-by: Chris Lesiak --- include/linux/crc-itu-t.h | 2 +- lib/crc-itu-t.c

Re: [PATCH V2 2/2] fs/super.c: don't fool lockdep in freeze_super() and thaw_super() paths

On Tue, Oct 04, 2016 at 01:43:43PM +0200, Oleg Nesterov wrote: > On 10/03, Oleg Nesterov wrote: > > > > On 10/03, Dave Chinner wrote: > > > > > > On Fri, Sep 30, 2016 at 07:14:34PM +0200, Oleg Nesterov wrote: > > > > On 09/27, Oleg Nesterov wrote: > > > > > > > > > Jan, I gave up. > > > > > > > >

Re: [PATCH V2 2/2] fs/super.c: don't fool lockdep in freeze_super() and thaw_super() paths

On Tue, Oct 04, 2016 at 01:43:43PM +0200, Oleg Nesterov wrote: > On 10/03, Oleg Nesterov wrote: > > > > On 10/03, Dave Chinner wrote: > > > > > > On Fri, Sep 30, 2016 at 07:14:34PM +0200, Oleg Nesterov wrote: > > > > On 09/27, Oleg Nesterov wrote: > > > > > > > > > Jan, I gave up. > > > > > > > >

Re: [PATCH 05/17] README: convert it to ReST markup

On Wed, Sep 21, 2016 at 4:09 PM, Mauro Carvalho Chehab wrote: > Adjust the readme file for it to use the ReST markup: > > - add chapter/section markups; > - use ``foo`` for commands; > - use :: for verbatim and script blocks; > - replace unsupported markup _foo_ by

Re: [PATCH 05/17] README: convert it to ReST markup

On Wed, Sep 21, 2016 at 4:09 PM, Mauro Carvalho Chehab wrote: > Adjust the readme file for it to use the ReST markup: > > - add chapter/section markups; > - use ``foo`` for commands; > - use :: for verbatim and script blocks; > - replace unsupported markup _foo_ by **foo**; > - add

Re: Regression in next with ext4 oops

Tony Lindgren writes: > * Tony Lindgren [161004 12:17]: >> Hi, >> >> * Al Viro [161004 08:00]: >> > On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote: >> > > On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote: >> >

Re: Regression in next with ext4 oops

Tony Lindgren writes: > * Tony Lindgren [161004 12:17]: >> Hi, >> >> * Al Viro [161004 08:00]: >> > On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote: >> > > On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote: >> > > > Never seen this but I suspect it is a fallout from Al's

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

Hello, John. On Tue, Oct 04, 2016 at 11:01:12AM -0700, John Stultz wrote: > So to make sure I understand your suggestion, you're suggesting the > cgroupfs files like: > cpuctrl/tasks, > cpuctrl/bg_non_interactive/tasks, > cpuset/foreground/tasks, > cpuset/background/tasks, > etc > use ACL

Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

Hello, John. On Tue, Oct 04, 2016 at 11:01:12AM -0700, John Stultz wrote: > So to make sure I understand your suggestion, you're suggesting the > cgroupfs files like: > cpuctrl/tasks, > cpuctrl/bg_non_interactive/tasks, > cpuset/foreground/tasks, > cpuset/background/tasks, > etc > use ACL

Re: [PATCH v3 2/9] hwmon: (core) New hwmon registration API

Hi Jean, On Tue, Oct 04, 2016 at 10:45:59AM +0200, Jean Delvare wrote: > Hi Guenter, > > I see this patch is upstream now, but I had started reviewing it and > maybe some of my comments are still relevant. > As always, I appreciate the feedback. I'll be happy to submit follow-up patches to

Re: [PATCH v3 2/9] hwmon: (core) New hwmon registration API

Hi Jean, On Tue, Oct 04, 2016 at 10:45:59AM +0200, Jean Delvare wrote: > Hi Guenter, > > I see this patch is upstream now, but I had started reviewing it and > maybe some of my comments are still relevant. > As always, I appreciate the feedback. I'll be happy to submit follow-up patches to

RE: [PATCH] igb: Realign bad indentation

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Joe Perches > Sent: Monday, September 26, 2016 8:46 PM > To: Kirsher, Jeffrey T > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org >

RE: [PATCH] igb: Realign bad indentation

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Joe Perches > Sent: Monday, September 26, 2016 8:46 PM > To: Kirsher, Jeffrey T > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH] igb:

Re: [PATCH V3 00/11] block-throttle: add .high limit

> Il giorno 04 ott 2016, alle ore 21:14, Tejun Heo ha scritto: > > Hello, Paolo. > > On Tue, Oct 04, 2016 at 09:02:47PM +0200, Paolo Valente wrote: >> That's exactly what BFQ has succeeded in doing in all the tests >> devised so far. Can you give me a concrete example for

Re: [PATCH V3 00/11] block-throttle: add .high limit

> Il giorno 04 ott 2016, alle ore 21:14, Tejun Heo ha scritto: > > Hello, Paolo. > > On Tue, Oct 04, 2016 at 09:02:47PM +0200, Paolo Valente wrote: >> That's exactly what BFQ has succeeded in doing in all the tests >> devised so far. Can you give me a concrete example for which I can >> try

Re: Regression in next with ext4 oops

* Tony Lindgren [161004 12:17]: > Hi, > > * Al Viro [161004 08:00]: > > On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote: > > > On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote: > > > > Never seen this but I suspect it is a fallout

Re: Regression in next with ext4 oops

* Tony Lindgren [161004 12:17]: > Hi, > > * Al Viro [161004 08:00]: > > On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote: > > > On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote: > > > > Never seen this but I suspect it is a fallout from Al's directory > > > > locking > > >

Re: [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts

Den 03.10.2016 21:42, skrev Eric Anholt: Noralf Trønnes writes: Den 29.09.2016 00:00, skrev Eric Anholt: Noralf Trønnes writes: If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0), the driver has no way to fill/drain the FIFO to

Re: [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts

Den 03.10.2016 21:42, skrev Eric Anholt: Noralf Trønnes writes: Den 29.09.2016 00:00, skrev Eric Anholt: Noralf Trønnes writes: If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0), the driver has no way to fill/drain the FIFO to stop the interrupts. In this case the

Re: Regression in next with ext4 oops

* Theodore Ts'o [161004 12:08]: > On Tue, Oct 04, 2016 at 03:59:15PM +0100, Al Viro wrote: > > Jan is wrong - we do have per-struct-file serialization for getdents() > > et.al. It might be a race between getdents() on *different* struct > > file for the same directory, but

Re: Regression in next with ext4 oops

* Theodore Ts'o [161004 12:08]: > On Tue, Oct 04, 2016 at 03:59:15PM +0100, Al Viro wrote: > > Jan is wrong - we do have per-struct-file serialization for getdents() > > et.al. It might be a race between getdents() on *different* struct > > file for the same directory, but ->private_data is not

[GIT PULL] jfs for 4.9

The following changes since commit b8927721ae9d5ac0582d29d7b8c267d465ad5f00: Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2016-08-29 12:37:11 -0700) are available in the git repository at: git://github.com/kleikamp/linux-shaggy.git

[GIT PULL] jfs for 4.9

The following changes since commit b8927721ae9d5ac0582d29d7b8c267d465ad5f00: Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2016-08-29 12:37:11 -0700) are available in the git repository at: git://github.com/kleikamp/linux-shaggy.git

Re: Regression in next with ext4 oops

Hi, * Al Viro [161004 08:00]: > On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote: > > On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote: > > > Never seen this but I suspect it is a fallout from Al's directory locking > > > changes. In particular

Re: Regression in next with ext4 oops

Hi, * Al Viro [161004 08:00]: > On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote: > > On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote: > > > Never seen this but I suspect it is a fallout from Al's directory locking > > > changes. In particular ext4_htree_fill_tree() builds

Re: [PATCH V3 00/11] block-throttle: add .high limit

Hello, Paolo. On Tue, Oct 04, 2016 at 09:02:47PM +0200, Paolo Valente wrote: > That's exactly what BFQ has succeeded in doing in all the tests > devised so far. Can you give me a concrete example for which I can > try with BFQ and with any other mechanism you deem better. If > you are right,

Re: [PATCH V3 00/11] block-throttle: add .high limit

Hello, Paolo. On Tue, Oct 04, 2016 at 09:02:47PM +0200, Paolo Valente wrote: > That's exactly what BFQ has succeeded in doing in all the tests > devised so far. Can you give me a concrete example for which I can > try with BFQ and with any other mechanism you deem better. If > you are right,

Re: [RFC] arm64: Enforce observed order for spinlock and data

Hi Brent, Could you *please* clarify if you are trying to solve: (a) a correctness issue (e.g. data corruption) seen in practice. (b) a correctness issue (e.g. data corruption) found by inspection. (c) A performance issue, seen in practice. (d) A performance issue, found by inspection. Any one

Re: [RFC] arm64: Enforce observed order for spinlock and data

Hi Brent, Could you *please* clarify if you are trying to solve: (a) a correctness issue (e.g. data corruption) seen in practice. (b) a correctness issue (e.g. data corruption) found by inspection. (c) A performance issue, seen in practice. (d) A performance issue, found by inspection. Any one

Re: Regression in next with ext4 oops

On Tue, Oct 04, 2016 at 03:59:15PM +0100, Al Viro wrote: > Jan is wrong - we do have per-struct-file serialization for getdents() > et.al. It might be a race between getdents() on *different* struct > file for the same directory, but ->private_data is not a problem. So the rb_insert_color() OOPS

Re: Regression in next with ext4 oops

On Tue, Oct 04, 2016 at 03:59:15PM +0100, Al Viro wrote: > Jan is wrong - we do have per-struct-file serialization for getdents() > et.al. It might be a race between getdents() on *different* struct > file for the same directory, but ->private_data is not a problem. So the rb_insert_color() OOPS

Re: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

On Thu, 18 Aug 2016, Waiman Long wrote: The osq_lock() and osq_unlock() function may not provide the necessary acquire and release barrier in some cases. This patch makes sure that the proper barriers are provided when osq_lock() is successful or when osq_unlock() is called. But why do we

Re: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

On Thu, 18 Aug 2016, Waiman Long wrote: The osq_lock() and osq_unlock() function may not provide the necessary acquire and release barrier in some cases. This patch makes sure that the proper barriers are provided when osq_lock() is successful or when osq_unlock() is called. But why do we

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