Re: [RFD] I/O scheduling in blk-mq

> Il giorno 05 ott 2016, alle ore 19:46, Omar Sandoval ha > scritto: > > Hey, Paolo, > > On Wed, Aug 31, 2016 at 05:20:10PM +0200, Paolo Valente wrote: > [snip] >>> Hi, Paolo, >>> >>> I've been working on I/O scheduling for blk-mq with Jens for the past >>> few months

Re: [RFD] I/O scheduling in blk-mq

> Il giorno 05 ott 2016, alle ore 19:46, Omar Sandoval ha > scritto: > > Hey, Paolo, > > On Wed, Aug 31, 2016 at 05:20:10PM +0200, Paolo Valente wrote: > [snip] >>> Hi, Paolo, >>> >>> I've been working on I/O scheduling for blk-mq with Jens for the past >>> few months (splitting time with

Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed

On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson wrote: > On 23 September 2016 at 22:01, Zach Brown wrote: >> Certain board configurations can make highspeed malfunction due to >> timing issues. In these cases a way is needed to force the controller >> and

Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed

On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson wrote: > On 23 September 2016 at 22:01, Zach Brown wrote: >> Certain board configurations can make highspeed malfunction due to >> timing issues. In these cases a way is needed to force the controller >> and card into standard speed even if they

RE: [PATCH] tpm: don't destroy chip device prematurely

> > On Wed, Oct 05, 2016 at 07:48:59AM +, Winkler, Tomas wrote: > > > > down_write(>ops_sem); > > > > chip->ops = NULL; > > > > up_write(>ops_sem); > > > > > > No, that is wrong as well, another thread can issue a TPM command > > > between the device_del and the ops = NULL. Presumably that

RE: [PATCH] tpm: don't destroy chip device prematurely

> > On Wed, Oct 05, 2016 at 07:48:59AM +, Winkler, Tomas wrote: > > > > down_write(>ops_sem); > > > > chip->ops = NULL; > > > > up_write(>ops_sem); > > > > > > No, that is wrong as well, another thread can issue a TPM command > > > between the device_del and the ops = NULL. Presumably that

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

> Il giorno 05 ott 2016, alle ore 21:47, Paolo Valente > ha scritto: > >> >> Il giorno 05 ott 2016, alle ore 20:30, Shaohua Li ha scritto: >> >> On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote: >>> Hello, Paolo. >>> >>> On Wed, Oct 05, 2016

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

> Il giorno 05 ott 2016, alle ore 21:47, Paolo Valente > ha scritto: > >> >> Il giorno 05 ott 2016, alle ore 20:30, Shaohua Li ha scritto: >> >> On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote: >>> Hello, Paolo. >>> >>> On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente

Re: [GIT PULL] overlayfs update for 4.9

On Wed, Oct 05, 2016 at 09:52:10PM +0200, Miklos Szeredi wrote: > Hi Al, > > Please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git > overlayfs-viro > > This has an assortment of fixes and cleanups for overlayfs. > > It also touches the VFS: > > - add the

Re: [GIT PULL] overlayfs update for 4.9

On Wed, Oct 05, 2016 at 09:52:10PM +0200, Miklos Szeredi wrote: > Hi Al, > > Please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git > overlayfs-viro > > This has an assortment of fixes and cleanups for overlayfs. > > It also touches the VFS: > > - add the

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

> Il giorno 05 ott 2016, alle ore 21:08, Shaohua Li ha scritto: > > On Wed, Oct 05, 2016 at 11:30:53AM -0700, Shaohua Li wrote: >> On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote: >>> Hello, Paolo. >>> >>> On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote:

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

> Il giorno 05 ott 2016, alle ore 21:08, Shaohua Li ha scritto: > > On Wed, Oct 05, 2016 at 11:30:53AM -0700, Shaohua Li wrote: >> On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote: >>> Hello, Paolo. >>> >>> On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: In this

Re: [PATCH 00/12] Fixes, cleanup and g_NCR5380_mmio/g_NCR5380 merger

On Tuesday 04 October 2016 07:40:50 Finn Thain wrote: > This patch series has fixes for compatibility, reliability and > performance issues and some cleanup. It also includes a new version > of Ondrej Zary's patch that merges g_NCR5380_mmio into g_NCR5380. > > I've tested this patch series on a

Re: [PATCH 00/12] Fixes, cleanup and g_NCR5380_mmio/g_NCR5380 merger

On Tuesday 04 October 2016 07:40:50 Finn Thain wrote: > This patch series has fixes for compatibility, reliability and > performance issues and some cleanup. It also includes a new version > of Ondrej Zary's patch that merges g_NCR5380_mmio into g_NCR5380. > > I've tested this patch series on a

Re: [PATCH v2] arm: Added support for getcpu() vDSO using TPIDRURW

On Wed, Oct 05, 2016 at 06:48:05PM +0100, Robin Murphy wrote: > On 05/10/16 17:39, Fredrik Markström wrote: > > The approach I suggested below with the vDSO data page will obviously > > not work on smp, so suggestions are welcome. > > Well, given that it's user-writeable, is there any reason an

Re: [PATCH v2] arm: Added support for getcpu() vDSO using TPIDRURW

On Wed, Oct 05, 2016 at 06:48:05PM +0100, Robin Murphy wrote: > On 05/10/16 17:39, Fredrik Markström wrote: > > The approach I suggested below with the vDSO data page will obviously > > not work on smp, so suggestions are welcome. > > Well, given that it's user-writeable, is there any reason an

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

On Wed, Oct 05, 2016 at 10:09:21AM +0200, Jiri Olsa wrote: > On Tue, Oct 04, 2016 at 03:29:33PM +1100, Michael Ellerman wrote: > > SNIP > > > Which is where we cope with the possibility that we couldn't emulate the > > instruction that hit the breakpoint. Seems that is not an issue on x86, > >

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

On Wed, Oct 05, 2016 at 10:09:21AM +0200, Jiri Olsa wrote: > On Tue, Oct 04, 2016 at 03:29:33PM +1100, Michael Ellerman wrote: > > SNIP > > > Which is where we cope with the possibility that we couldn't emulate the > > instruction that hit the breakpoint. Seems that is not an issue on x86, > >

[GIT PULL] overlayfs update for 4.9

Hi Al, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-viro This has an assortment of fixes and cleanups for overlayfs. It also touches the VFS: - add the vfs_get_link() helper for calling i_op->get_link(); - fix mnt_want_write_file() to freeze

[GIT PULL] overlayfs update for 4.9

Hi Al, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-viro This has an assortment of fixes and cleanups for overlayfs. It also touches the VFS: - add the vfs_get_link() helper for calling i_op->get_link(); - fix mnt_want_write_file() to freeze

Some minor fixes for the perf tools json event code

Fix some issues that turned up in recent testing. -Andi

[PATCH 2/3] perf, tools: Handle completion of upper case events

From: Andi Kleen Vendor events are often specified in upper case. perf list outputs them in lower case. Handle this case in perf-completion.sh so that completion on the upper case events still works. Signed-off-by: Andi Kleen ---

Some minor fixes for the perf tools json event code

Fix some issues that turned up in recent testing. -Andi

[PATCH 2/3] perf, tools: Handle completion of upper case events

From: Andi Kleen Vendor events are often specified in upper case. perf list outputs them in lower case. Handle this case in perf-completion.sh so that completion on the upper case events still works. Signed-off-by: Andi Kleen --- tools/perf/perf-completion.sh | 6 +- 1 file changed, 5

[PATCH 3/3] perf, tools: Fix Intel fixed counter conversions

From: Andi Kleen Intel fixed counters are special cases in the JSON conversion process because their decoding differs between perf and the event files. Add some missing entries in the conversion table. Signed-off-by: Andi Kleen ---

[PATCH 1/3] perf, tools: Handle events including .c and .o

From: Andi Kleen This is a generic bug fix, but it helps with Sukadev's JSON event tree where such events can happen. Any event inclduing a .c/.o/.bpf currently triggers BPF compilation or loading and then an error. This can happen for some Intel JSON events, which cannot

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

> Il giorno 05 ott 2016, alle ore 20:30, Shaohua Li ha scritto: > > On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote: >> Hello, Paolo. >> >> On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: >>> In this respect, for your generic, unpredictable scenario to

[PATCH 3/3] perf, tools: Fix Intel fixed counter conversions

From: Andi Kleen Intel fixed counters are special cases in the JSON conversion process because their decoding differs between perf and the event files. Add some missing entries in the conversion table. Signed-off-by: Andi Kleen --- tools/perf/pmu-events/jevents.c | 2 ++ 1 file changed, 2

[PATCH 1/3] perf, tools: Handle events including .c and .o

From: Andi Kleen This is a generic bug fix, but it helps with Sukadev's JSON event tree where such events can happen. Any event inclduing a .c/.o/.bpf currently triggers BPF compilation or loading and then an error. This can happen for some Intel JSON events, which cannot be used. Fix the

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

> Il giorno 05 ott 2016, alle ore 20:30, Shaohua Li ha scritto: > > On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote: >> Hello, Paolo. >> >> On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: >>> In this respect, for your generic, unpredictable scenario to make >>> sense,

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote: > On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez wrote: > > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > > > >> I did some shuffling around of those code to make initmpfs work, does > >>

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote: > On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez wrote: > > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > > > >> I did some shuffling around of those code to make initmpfs work, does > >> anybody know why

Re: [GIT PULL] ACPI material for v4.9-rc1

On Wed, Oct 5, 2016 at 7:29 PM, Linus Torvalds wrote: > On Sun, Oct 2, 2016 at 3:56 PM, Rafael J. Wysocki wrote: >> >> This goes early as I will be traveling for a good part of the next week. > > So you're presumably traveling, but I thought I'd

Re: [GIT PULL] ACPI material for v4.9-rc1

On Wed, Oct 5, 2016 at 7:29 PM, Linus Torvalds wrote: > On Sun, Oct 2, 2016 at 3:56 PM, Rafael J. Wysocki wrote: >> >> This goes early as I will be traveling for a good part of the next week. > > So you're presumably traveling, but I thought I'd mention this anyway, > since it seems to be new

RE: [net-next 08/13] fsl/fman: check pcsphy pointer before use

> -Original Message- > From: David Laight [mailto:david.lai...@aculab.com] > Sent: Tuesday, October 04, 2016 5:44 PM > To: Madalin-Cristian Bucur ; > net...@vger.kernel.org > Cc: linuxdev.baldr...@gmail.com; linuxppc-...@lists.ozlabs.org; > da...@davemloft.net;

RE: [net-next 08/13] fsl/fman: check pcsphy pointer before use

> -Original Message- > From: David Laight [mailto:david.lai...@aculab.com] > Sent: Tuesday, October 04, 2016 5:44 PM > To: Madalin-Cristian Bucur ; > net...@vger.kernel.org > Cc: linuxdev.baldr...@gmail.com; linuxppc-...@lists.ozlabs.org; > da...@davemloft.net; linux-kernel@vger.kernel.org

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Add enable_sagv option

Em Qua, 2016-10-05 às 11:33 -0400, Lyude escreveu: > This option allows us to manually control the SAGV at module load > time. > This can be useful in situations such as trying to debug watermark > changes, since enabled SAGV + incorrect watermarks = total GPU > annihilation. I'm not a huge fan

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Add enable_sagv option

Em Qua, 2016-10-05 às 11:33 -0400, Lyude escreveu: > This option allows us to manually control the SAGV at module load > time. > This can be useful in situations such as trying to debug watermark > changes, since enabled SAGV + incorrect watermarks = total GPU > annihilation. I'm not a huge fan

[PATCH] net: bgmac: Fix errant feature flag check

During the conversion to the feature flags, a check against ci->id != BCMA_CHIP_ID_BCM47162 became bgmac->feature_flags & BGMAC_FEAT_CLKCTLS instead of !(bgmac->feature_flags & BGMAC_FEAT_CLKCTLS) Reported-by: Rafał Miłecki Signed-off-by: Jon Mason ---

[PATCH] net: bgmac: Fix errant feature flag check

During the conversion to the feature flags, a check against ci->id != BCMA_CHIP_ID_BCM47162 became bgmac->feature_flags & BGMAC_FEAT_CLKCTLS instead of !(bgmac->feature_flags & BGMAC_FEAT_CLKCTLS) Reported-by: Rafał Miłecki Signed-off-by: Jon Mason --- drivers/net/ethernet/broadcom/bgmac.c | 2

Re: [PATCH] printk: introduce kptr_restrict level 3

On Wed, Oct 5, 2016 at 11:04 AM, wrote: > From: William Roberts > > Some out-of-tree modules do not use %pK and just use %p, as it's > the common C paradigm for printing pointers. Because of this, > kptr_restrict has no affect on the

Re: [PATCH] printk: introduce kptr_restrict level 3

On Wed, Oct 5, 2016 at 11:04 AM, wrote: > From: William Roberts > > Some out-of-tree modules do not use %pK and just use %p, as it's > the common C paradigm for printing pointers. Because of this, > kptr_restrict has no affect on the output and thus, no way to > contain the kernel address leak.

Re: [PATCH 1/2] cgroup: Add generic cgroup subsystem permission checks

On Wed, Oct 5, 2016 at 12:16 PM, John Stultz wrote: > On Wed, Oct 5, 2016 at 12:09 PM, Dmitry Torokhov > wrote: >> [ Some comments are form Ricky Zhou , some from >> myself ] >> On Mon, Oct 03, 2016 at 09:41:29PM -0700, John

Re: [PATCH 1/2] cgroup: Add generic cgroup subsystem permission checks

On Wed, Oct 5, 2016 at 12:16 PM, John Stultz wrote: > On Wed, Oct 5, 2016 at 12:09 PM, Dmitry Torokhov > wrote: >> [ Some comments are form Ricky Zhou , some from >> myself ] >> On Mon, Oct 03, 2016 at 09:41:29PM -0700, John Stultz wrote: >>> From: Colin Cross >>> > [snip] >>> + >>> +

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

Ben, On 10/05/2016 03:17 PM, Benjamin LaHaise wrote: Anything's possible when a local user can run code. [snip] That said, local users tend not to DoS themselves. Agree. I thought of something that could be particularly related to the aio implementation; but I guess there's nothing so

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

Ben, On 10/05/2016 03:17 PM, Benjamin LaHaise wrote: Anything's possible when a local user can run code. [snip] That said, local users tend not to DoS themselves. Agree. I thought of something that could be particularly related to the aio implementation; but I guess there's nothing so

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Wed, Oct 5, 2016 at 12:06 PM, Willy Tarreau wrote: > > I have the same doubts, so at least I would not want to run the "sed" > immediately, at least to keep the initial intent. But I think everyone > is right in is own yard when he puts a BUG_ON() when he doesn't know > how to

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Wed, Oct 5, 2016 at 12:06 PM, Willy Tarreau wrote: > > I have the same doubts, so at least I would not want to run the "sed" > immediately, at least to keep the initial intent. But I think everyone > is right in is own yard when he puts a BUG_ON() when he doesn't know > how to handle an unsafe

Re: [PATCH 2/2] cgroup: Add a allow_attach policy for Android

On Wed, Oct 5, 2016 at 12:10 PM, Dmitry Torokhov wrote: > On Mon, Oct 03, 2016 at 09:41:30PM -0700, John Stultz wrote: >> +#ifdef CONFIG_CGROUP_NICE_ATTACH >> +int cgroup_nice_allow_attach(struct cgroup_taskset *tset) >> +{ >> + const struct cred *cred =

Re: [PATCH 2/2] cgroup: Add a allow_attach policy for Android

On Wed, Oct 5, 2016 at 12:10 PM, Dmitry Torokhov wrote: > On Mon, Oct 03, 2016 at 09:41:30PM -0700, John Stultz wrote: >> +#ifdef CONFIG_CGROUP_NICE_ATTACH >> +int cgroup_nice_allow_attach(struct cgroup_taskset *tset) >> +{ >> + const struct cred *cred = current_cred(), *tcred; >> +

Re: [PATCH 1/2] cgroup: Add generic cgroup subsystem permission checks

On Wed, Oct 5, 2016 at 12:09 PM, Dmitry Torokhov wrote: > [ Some comments are form Ricky Zhou , some from > myself ] > On Mon, Oct 03, 2016 at 09:41:29PM -0700, John Stultz wrote: >> From: Colin Cross >> [snip] >> + >> +

Re: [PATCH 1/2] cgroup: Add generic cgroup subsystem permission checks

On Wed, Oct 5, 2016 at 12:09 PM, Dmitry Torokhov wrote: > [ Some comments are form Ricky Zhou , some from > myself ] > On Mon, Oct 03, 2016 at 09:41:29PM -0700, John Stultz wrote: >> From: Colin Cross >> [snip] >> + >> + cset = task_css_set(task); > > Do we need to take css_set_lock

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

On 10/4/2016 2:49 PM, Greg KH wrote: 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.

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

On 10/4/2016 2:49 PM, Greg KH wrote: 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.

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

On Wed, 2016-10-05 at 21:11 +0200, Pavel Machek wrote: > On Wed 2016-10-05 10:53:16, Joe Perches wrote: > > On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote: > > > Hi Pavel, > > > > > > > bluetooth.h is not part of user API, so __ variants are not neccessary > > > > here. > > > > > > > >

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

On Wed, 2016-10-05 at 21:11 +0200, Pavel Machek wrote: > On Wed 2016-10-05 10:53:16, Joe Perches wrote: > > On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote: > > > Hi Pavel, > > > > > > > bluetooth.h is not part of user API, so __ variants are not neccessary > > > > here. > > > > > > > >

Re: ERROR: ftrace_graph_ret_addr" [arch/x86/oprofile/oprofile.ko] undefined!

On Wed, Oct 05, 2016 at 02:23:54PM +, Karl Beldan wrote: > Hi, > > This has already been reported by Fengguang Wu's kbuild test robot: > https://lists.01.org/pipermail/kbuild-all/2016-July/022203.html > but it seems to have slipped through. Hi Karl, Thanks for reporting it. I'll get the

Re: ERROR: ftrace_graph_ret_addr" [arch/x86/oprofile/oprofile.ko] undefined!

On Wed, Oct 05, 2016 at 02:23:54PM +, Karl Beldan wrote: > Hi, > > This has already been reported by Fengguang Wu's kbuild test robot: > https://lists.01.org/pipermail/kbuild-all/2016-July/022203.html > but it seems to have slipped through. Hi Karl, Thanks for reporting it. I'll get the

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

On Wed 2016-10-05 10:53:16, Joe Perches wrote: > On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote: > > Hi Pavel, > > > > > bluetooth.h is not part of user API, so __ variants are not neccessary > > > here. > > > > > > Signed-off-by: Pavel Machek > > > > > > diff --git

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

On Wed 2016-10-05 10:53:16, Joe Perches wrote: > On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote: > > Hi Pavel, > > > > > bluetooth.h is not part of user API, so __ variants are not neccessary > > > here. > > > > > > Signed-off-by: Pavel Machek > > > > > > diff --git

Re: [PATCH 2/2] cgroup: Add a allow_attach policy for Android

On Mon, Oct 03, 2016 at 09:41:30PM -0700, John Stultz wrote: > +#ifdef CONFIG_CGROUP_NICE_ATTACH > +int cgroup_nice_allow_attach(struct cgroup_taskset *tset) > +{ > + const struct cred *cred = current_cred(), *tcred; > + struct task_struct *task; > + struct cgroup_subsys_state *css; >

Re: [PATCH 2/2] cgroup: Add a allow_attach policy for Android

On Mon, Oct 03, 2016 at 09:41:30PM -0700, John Stultz wrote: > +#ifdef CONFIG_CGROUP_NICE_ATTACH > +int cgroup_nice_allow_attach(struct cgroup_taskset *tset) > +{ > + const struct cred *cred = current_cred(), *tcred; > + struct task_struct *task; > + struct cgroup_subsys_state *css; >

Re: [PATCH 1/2] cgroup: Add generic cgroup subsystem permission checks

[ Some comments are form Ricky Zhou , some from myself ] On Mon, Oct 03, 2016 at 09:41:29PM -0700, John Stultz wrote: > From: Colin Cross > > Rather than using explicit euid == 0 checks when trying to move > tasks into a cgroup, move permission checks

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

On Wed, Oct 05, 2016 at 11:30:53AM -0700, Shaohua Li wrote: > On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote: > > Hello, Paolo. > > > > On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: > > > In this respect, for your generic, unpredictable scenario to make > > > sense,

Re: [PATCH 1/2] cgroup: Add generic cgroup subsystem permission checks

[ Some comments are form Ricky Zhou , some from myself ] On Mon, Oct 03, 2016 at 09:41:29PM -0700, John Stultz wrote: > From: Colin Cross > > Rather than using explicit euid == 0 checks when trying to move > tasks into a cgroup, move permission checks into each specific > cgroup subsystem. If a

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

On Wed, Oct 05, 2016 at 11:30:53AM -0700, Shaohua Li wrote: > On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote: > > Hello, Paolo. > > > > On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: > > > In this respect, for your generic, unpredictable scenario to make > > > sense,

Re: [PATCH] random: Fix early crash in credit_entropy_bits

ping thanks, jirka On Wed, Sep 21, 2016 at 05:07:11PM +0200, Jiri Olsa wrote: > From: Jiri Olsa > > When printing out some early acpi messages I hit bug in > work queue code. The system_wq is not initialized at the > time acpi_early_init is called and causes irq storm that >

Re: [PATCH] random: Fix early crash in credit_entropy_bits

ping thanks, jirka On Wed, Sep 21, 2016 at 05:07:11PM +0200, Jiri Olsa wrote: > From: Jiri Olsa > > When printing out some early acpi messages I hit bug in > work queue code. The system_wq is not initialized at the > time acpi_early_init is called and causes irq storm that > makes

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Wed, Oct 05, 2016 at 08:52:54AM -0700, Linus Torvalds wrote: > On Tue, Oct 4, 2016 at 10:44 PM, Willy Tarreau wrote: > > > > I think instead we should completely remove any simple way to halt the > > system and document how to do it. > > Having slept on it, I suspect you're

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Wed, Oct 05, 2016 at 08:52:54AM -0700, Linus Torvalds wrote: > On Tue, Oct 4, 2016 at 10:44 PM, Willy Tarreau wrote: > > > > I think instead we should completely remove any simple way to halt the > > system and document how to do it. > > Having slept on it, I suspect you're right. I worry

Fw: [PATCH v2] cinergyT2-core: don't do DMA on stack

Sorry, forgot to C/C people that are at the "Re: Problem with VMAP_STACK=y" thread. Forwarded message: Date: Wed, 5 Oct 2016 15:54:18 -0300 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab

Fw: [PATCH v2] cinergyT2-core: don't do DMA on stack

Sorry, forgot to C/C people that are at the "Re: Problem with VMAP_STACK=y" thread. Forwarded message: Date: Wed, 5 Oct 2016 15:54:18 -0300 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , Mauro Carvalho Chehab , Mauro Carvalho Chehab Subject: [PATCH v2]

Re: Problem with VMAP_STACK=y

Hi Johannes, Em Wed, 5 Oct 2016 20:29:45 +0200 Johannes Stezenbach escreveu: > On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote: > > static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap) > > { > > - char query[] = {

Re: Problem with VMAP_STACK=y

Hi Johannes, Em Wed, 5 Oct 2016 20:29:45 +0200 Johannes Stezenbach escreveu: > On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote: > > static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap) > > { > > - char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION }; > >

[PATCH 1/1] rtc: add century field data boundary

According to ACPI specification, the century field data should be ranged 0-63. so if it's over this range, it could cause system RTC settings error including alarmwakeup settings. So it's required to have this boundary for safe RTC init settings. Signed-off-by: Andrew Kim

[PATCH 1/1] rtc: add century field data boundary

According to ACPI specification, the century field data should be ranged 0-63. so if it's over this range, it could cause system RTC settings error including alarmwakeup settings. So it's required to have this boundary for safe RTC init settings. Signed-off-by: Andrew Kim ---

Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed

On 23 September 2016 at 22:01, Zach Brown wrote: > Certain board configurations can make highspeed malfunction due to > timing issues. In these cases a way is needed to force the controller > and card into standard speed even if they otherwise appear to be capable > of

Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed

On 23 September 2016 at 22:01, Zach Brown wrote: > Certain board configurations can make highspeed malfunction due to > timing issues. In these cases a way is needed to force the controller > and card into standard speed even if they otherwise appear to be capable > of highspeed. > > The

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

On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote: > Hello, Paolo. > > On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: > > In this respect, for your generic, unpredictable scenario to make > > sense, there must exist at least one real system that meets the > > requirements

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

On Wed, Oct 05, 2016 at 10:49:46AM -0400, Tejun Heo wrote: > Hello, Paolo. > > On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: > > In this respect, for your generic, unpredictable scenario to make > > sense, there must exist at least one real system that meets the > > requirements

Re: Problem with VMAP_STACK=y

On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote: > static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap) > { > - char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION }; > - char state[3]; > + struct dvb_usb_device *d = adap->dev; > + struct

Re: Problem with VMAP_STACK=y

On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote: > static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap) > { > - char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION }; > - char state[3]; > + struct dvb_usb_device *d = adap->dev; > + struct

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

On Wed, Oct 05, 2016 at 02:58:12PM -0300, Mauricio Faria de Oliveira wrote: > Hi Benjamin, > > On 10/05/2016 02:41 PM, Benjamin LaHaise wrote: > >I'd suggest increasing the default limit by changing how it is calculated. > >The current number came about 13 years ago when machines had orders of >

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

On Wed, Oct 05, 2016 at 02:58:12PM -0300, Mauricio Faria de Oliveira wrote: > Hi Benjamin, > > On 10/05/2016 02:41 PM, Benjamin LaHaise wrote: > >I'd suggest increasing the default limit by changing how it is calculated. > >The current number came about 13 years ago when machines had orders of >

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez wrote: > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > >> I did some shuffling around of those code to make initmpfs work, does >> anybody know why initramfs extraction _before_ we initialize drivers >> would

[GIT PULL] sound updates for 4.9-rc1

Linus, please pull sound fixes for v4.9-rc1 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-4.9-rc1 The topmost commit is eeea8b40cd2866ca24f25e5ef09225edb076ae45 sound updates for 4.9-rc1

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez wrote: > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > >> I did some shuffling around of those code to make initmpfs work, does >> anybody know why initramfs extraction _before_ we initialize drivers >> would be a bad thing? > >

[GIT PULL] sound updates for 4.9-rc1

Linus, please pull sound fixes for v4.9-rc1 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-4.9-rc1 The topmost commit is eeea8b40cd2866ca24f25e5ef09225edb076ae45 sound updates for 4.9-rc1

[PATCH] printk: introduce kptr_restrict level 3

From: William Roberts Some out-of-tree modules do not use %pK and just use %p, as it's the common C paradigm for printing pointers. Because of this, kptr_restrict has no affect on the output and thus, no way to contain the kernel address leak. Introduce

[PATCH] printk: introduce kptr_restrict level 3

From: William Roberts Some out-of-tree modules do not use %pK and just use %p, as it's the common C paradigm for printing pointers. Because of this, kptr_restrict has no affect on the output and thus, no way to contain the kernel address leak. Introduce kptr_restrict level 3 that causes the

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

On Tue, Oct 04, 2016 at 07:55:12PM -0300, Mauricio Faria de Oliveira wrote: > Hi Benjamin, Kent, and others, > > Would you please comment / answer about this possible problem? > Any feedback is appreciated. I'd suggest increasing the default limit by changing how it is calculated. The current

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

On Tue, Oct 04, 2016 at 07:55:12PM -0300, Mauricio Faria de Oliveira wrote: > Hi Benjamin, Kent, and others, > > Would you please comment / answer about this possible problem? > Any feedback is appreciated. I'd suggest increasing the default limit by changing how it is calculated. The current

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote: > > kernel_read_file_from_path() can try to read a file from > > the system's filesystem. This is typically done for firmware > > for instance, which lives in /lib/firmware. One issue

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote: > > kernel_read_file_from_path() can try to read a file from > > the system's filesystem. This is typically done for firmware > > for instance, which lives in /lib/firmware. One issue

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

Hi Benjamin, On 10/05/2016 02:41 PM, Benjamin LaHaise wrote: I'd suggest increasing the default limit by changing how it is calculated. The current number came about 13 years ago when machines had orders of magnitude less RAM than they do today. Thanks for the suggestion. Does the default

Re: aio: questions with ioctx_alloc() and large num_possible_cpus()

Hi Benjamin, On 10/05/2016 02:41 PM, Benjamin LaHaise wrote: I'd suggest increasing the default limit by changing how it is calculated. The current number came about 13 years ago when machines had orders of magnitude less RAM than they do today. Thanks for the suggestion. Does the default

[GIT PULL] namespace related changes for 4.9-rc1

Linus, Please pull the for-linus branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus HEAD: 069d5ac9ae0d271903cc4607890616418118379a autofs: Fix automounts by using current_real_cred()->uid This set of changes is a number of

[GIT PULL] namespace related changes for 4.9-rc1

Linus, Please pull the for-linus branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus HEAD: 069d5ac9ae0d271903cc4607890616418118379a autofs: Fix automounts by using current_real_cred()->uid This set of changes is a number of

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote: > Hi Pavel, > > > bluetooth.h is not part of user API, so __ variants are not neccessary > > here. > > > > Signed-off-by: Pavel Machek > > > > diff --git a/include/net/bluetooth/bluetooth.h > >

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote: > Hi Pavel, > > > bluetooth.h is not part of user API, so __ variants are not neccessary > > here. > > > > Signed-off-by: Pavel Machek > > > > diff --git a/include/net/bluetooth/bluetooth.h > > b/include/net/bluetooth/bluetooth.h [] >

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