Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Wed, Oct 5, 2016 at 2:14 PM, Kees Cook wrote: > Now, it can be argued that killing the process part should be > configurable and that the code should be written to handle a WARN and > clean up and error out nicely. But I still want to retain the "kill > the process

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Wed, Oct 5, 2016 at 2:14 PM, Kees Cook wrote: > Now, it can be argued that killing the process part should be > configurable and that the code should be written to handle a WARN and > clean up and error out nicely. But I still want to retain the "kill > the process immediately" behavior in

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gen9: Get rid of redundant watermark values

Em Qua, 2016-10-05 às 11:33 -0400, Lyude escreveu: > Now that we've make skl_wm_levels make a little more sense, we can > remove all of the redundant wm information. Up until now we'd been > storing two copies of all of the skl watermarks: one being the > skl_pipe_wm structs, the other being the

[GIT PULL] pstore updates for v4.9-rc1

Hi, Please pull these pstore changes for v4.9-rc1. Thanks! -Kees The following changes since commit d71f058617564750261b673ea9b3352382b9cde4: Merge branch 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux (2016-09-07 21:28:26 -0700) are available in the git

[GIT PULL] pstore updates for v4.9-rc1

Hi, Please pull these pstore changes for v4.9-rc1. Thanks! -Kees The following changes since commit d71f058617564750261b673ea9b3352382b9cde4: Merge branch 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux (2016-09-07 21:28:26 -0700) are available in the git

Re: [Intel-gfx] [PATCH 5/6] drm/i915/gen9: Get rid of redundant watermark values

Em Qua, 2016-10-05 às 11:33 -0400, Lyude escreveu: > Now that we've make skl_wm_levels make a little more sense, we can > remove all of the redundant wm information. Up until now we'd been > storing two copies of all of the skl watermarks: one being the > skl_pipe_wm structs, the other being the

Re: [PATCH v2 5/8] blk-mq: Cleanup blk_mq_hw_ctx::cpumask (de-)allocation

Looks fine, Reviewed-by: Sagi Grimberg

Re: [PATCH v2 5/8] blk-mq: Cleanup blk_mq_hw_ctx::cpumask (de-)allocation

Looks fine, Reviewed-by: Sagi Grimberg

Re: [PATCH v2 4/8] blk-mq: Cleanup a loop exit condition

Looks good, Reviewed-by: Sagi Grimberg

Re: [PATCH v2 4/8] blk-mq: Cleanup a loop exit condition

Looks good, Reviewed-by: Sagi Grimberg

Re: [PATCH 01/15 v2] UBIFS: improve function-level documentation

On Sat, Oct 1, 2016 at 10:53 PM, Julia Lawall wrote: > Fix various inconsistencies in the documentation associated with various > functions. > > In the case of fs/ubifs/lprops.c, the second parameter of > ubifs_get_lp_stats was renamed from st to lst in commit 84abf972ccff >

Re: [PATCH 01/15 v2] UBIFS: improve function-level documentation

On Sat, Oct 1, 2016 at 10:53 PM, Julia Lawall wrote: > Fix various inconsistencies in the documentation associated with various > functions. > > In the case of fs/ubifs/lprops.c, the second parameter of > ubifs_get_lp_stats was renamed from st to lst in commit 84abf972ccff > ("UBIFS: add re-mount

Re: kernel BUG at block/bio.c:1785 while trying to issue a discard to LVM on RAID1 md

On Wed, Oct 05, 2016 at 10:31:11PM +0100, Sitsofe Wheeler wrote: > On 3 October 2016 at 17:47, Sitsofe Wheeler wrote: > > > > While trying to do a discard (via blkdiscard --length 1048576 > > /dev/) to an LVM device atop a two disk md RAID1 the > > following oops was generated:

Re: kernel BUG at block/bio.c:1785 while trying to issue a discard to LVM on RAID1 md

On Wed, Oct 05, 2016 at 10:31:11PM +0100, Sitsofe Wheeler wrote: > On 3 October 2016 at 17:47, Sitsofe Wheeler wrote: > > > > While trying to do a discard (via blkdiscard --length 1048576 > > /dev/) to an LVM device atop a two disk md RAID1 the > > following oops was generated: > > > > [

Re: [PATCH v2 3/8] blk-mq: Fix hardware context data node selection

Looks fine, Reviewed-by: Sagi Grimberg

Re: [PATCH v2 3/8] blk-mq: Fix hardware context data node selection

Looks fine, Reviewed-by: Sagi Grimberg

Re: [PATCH v2 2/8] blk-mq: Remove a redundant assignment

Looks good, Reviewed-by: Sagi Grimberg

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

On Wed, Oct 5, 2016 at 10:44 PM, Mark Rutland wrote: > On Wed, Oct 05, 2016 at 08:00:38PM +, Fredrik Markström wrote: >> On Wed, Oct 5, 2016 at 7:48 PM Robin Murphy wrote: >> As far as I understand TPIDRURW isn't anything else then an architecture

Re: [PATCH v2 2/8] blk-mq: Remove a redundant assignment

Looks good, Reviewed-by: Sagi Grimberg

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

On Wed, Oct 5, 2016 at 10:44 PM, Mark Rutland wrote: > On Wed, Oct 05, 2016 at 08:00:38PM +, Fredrik Markström wrote: >> On Wed, Oct 5, 2016 at 7:48 PM Robin Murphy wrote: >> As far as I understand TPIDRURW isn't anything else then an architecture >> specific piece of tls since the last

Re: [PATCH v2 1/8] block: Get rid of unused request_queue::nr_queues member

Looks good, Reviewed-by: Sagi Grimberg

Re: [PATCH v2 1/8] block: Get rid of unused request_queue::nr_queues member

Looks good, Reviewed-by: Sagi Grimberg

[PATCH] spi: dw: Enable Slave Select with GPIO Chip Select.

From: Thor Thayer Currently in the GPIO CS case, the transfer is stalled. The DesignWare IP datasheet points out that the slave must be selected (SER) before the transfer can start [1]. The SPI framework selects the chip using either 1) the internal CS mechanism or

[PATCH] spi: dw: Enable Slave Select with GPIO Chip Select.

From: Thor Thayer Currently in the GPIO CS case, the transfer is stalled. The DesignWare IP datasheet points out that the slave must be selected (SER) before the transfer can start [1]. The SPI framework selects the chip using either 1) the internal CS mechanism or 2) the GPIO CS, but not both.

Re: kernel BUG at block/bio.c:1785 while trying to issue a discard to LVM on RAID1 md

On 3 October 2016 at 17:47, Sitsofe Wheeler wrote: > > While trying to do a discard (via blkdiscard --length 1048576 > /dev/) to an LVM device atop a two disk md RAID1 the > following oops was generated: > > [ 103.306243] md: resync of RAID array md127 > [ 103.306246] md:

Re: kernel BUG at block/bio.c:1785 while trying to issue a discard to LVM on RAID1 md

On 3 October 2016 at 17:47, Sitsofe Wheeler wrote: > > While trying to do a discard (via blkdiscard --length 1048576 > /dev/) to an LVM device atop a two disk md RAID1 the > following oops was generated: > > [ 103.306243] md: resync of RAID array md127 > [ 103.306246] md: minimum _guaranteed_

[GIT PULL] xfs: updates for 4.9-rc1

Hi Linus, Can you please pull the XFS and iomap updates from the tag listed below? The main things in this update are the iomap-based DAX infrastructure, an XFS delalloc rework, and a chunk of fixes to how log recovery schedules writeback to prevent spurious corruption detections when recovery of

[GIT PULL] xfs: updates for 4.9-rc1

Hi Linus, Can you please pull the XFS and iomap updates from the tag listed below? The main things in this update are the iomap-based DAX infrastructure, an XFS delalloc rework, and a chunk of fixes to how log recovery schedules writeback to prevent spurious corruption detections when recovery of

Re: [PATCH v2] Adding missing features of Coresight PTM components

On 5 October 2016 at 05:42, Muhammad Abdul WAHAB wrote: > In the current driver for Coresight components, two features of PTM > components are missing: > > 1. Branch Broadcasting (present also in ETM but called Branch Output) > 2. Return Stack (only present

Re: [PATCH v2] Adding missing features of Coresight PTM components

On 5 October 2016 at 05:42, Muhammad Abdul WAHAB wrote: > In the current driver for Coresight components, two features of PTM > components are missing: > > 1. Branch Broadcasting (present also in ETM but called Branch Output) > 2. Return Stack (only present in PTM v1.0 and PTMv1.1) > > These

[PATCH 1/1] hv: do not lose pending heartbeat vmbus packets

From: Long Li The host keeps sending heartbeat packets independent of the guest responding to them. Even though we respond to the heartbeat messages at interrupt level, we can have situations where there maybe multiple heartbeat messages pending that have not been

[PATCH 1/1] hv: do not lose pending heartbeat vmbus packets

From: Long Li The host keeps sending heartbeat packets independent of the guest responding to them. Even though we respond to the heartbeat messages at interrupt level, we can have situations where there maybe multiple heartbeat messages pending that have not been responded to. For instance

Re: [RFC v3 16/22] bpf/cgroup,landlock: Handle Landlock hooks per cgroup

On Wed, Oct 5, 2016 at 1:58 PM, Mickaël Salaün wrote: > > > On 04/10/2016 01:43, Kees Cook wrote: >> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: >>> This allows to add new eBPF programs to Landlock hooks dedicated to a >>> cgroup thanks to the

Re: [RFC v3 16/22] bpf/cgroup,landlock: Handle Landlock hooks per cgroup

On Wed, Oct 5, 2016 at 1:58 PM, Mickaël Salaün wrote: > > > On 04/10/2016 01:43, Kees Cook wrote: >> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: >>> This allows to add new eBPF programs to Landlock hooks dedicated to a >>> cgroup thanks to the BPF_PROG_ATTACH command. Like for socket

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

On Wed, Oct 05, 2016 at 08:09:17PM +, Winkler, Tomas wrote: > It could, but that patch was not merged yet, and I believe even if > the issue is exposed only with runtime_pm currently, we have a bug > in design even w/o runtime pm. Please don't make changes without any justification :( > >

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

On Wed, Oct 05, 2016 at 08:09:17PM +, Winkler, Tomas wrote: > It could, but that patch was not merged yet, and I believe even if > the issue is exposed only with runtime_pm currently, we have a bug > in design even w/o runtime pm. Please don't make changes without any justification :( > >

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

On Wed, Oct 05, 2016 at 03:03:44PM -0500, Rob Herring wrote: > 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

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

On Wed, Oct 05, 2016 at 03:03:44PM -0500, Rob Herring wrote: > 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

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Wed, Oct 5, 2016 at 12:18 PM, Linus Torvalds wrote: > 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

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Wed, Oct 5, 2016 at 12:18 PM, Linus Torvalds wrote: > 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

How to test CONFIG_MODVERSIONS?

Can someone give me an example of a situation where a kernel built CONFIG_MODVERSIONS would allow a driver to load, but the same kernel built without CONFIG_MODVERSIONS would reject that driver? I'm trying to see if there's value in enabling CONFIG_MODVERSIONS for our internal kernels. --

How to test CONFIG_MODVERSIONS?

Can someone give me an example of a situation where a kernel built CONFIG_MODVERSIONS would allow a driver to load, but the same kernel built without CONFIG_MODVERSIONS would reject that driver? I'm trying to see if there's value in enabling CONFIG_MODVERSIONS for our internal kernels. --

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Wed, Oct 05, 2016 at 12:18:51PM -0700, Linus Torvalds wrote: > Quite frankly, I wouldn't do a sed-script pass to actually change > existing users. I'd just change how the BUG() implementation itself > works. Not make it a direct WARN_ON(), but perhaps something like > > - use WARN_ON() with a

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Wed, Oct 05, 2016 at 12:18:51PM -0700, Linus Torvalds wrote: > Quite frankly, I wouldn't do a sed-script pass to actually change > existing users. I'd just change how the BUG() implementation itself > works. Not make it a direct WARN_ON(), but perhaps something like > > - use WARN_ON() with a

Re: [PATCH] staging: speakup: Replaced obsolete simple_strtoul

Hello, Jitendra Khasdev, on Thu 06 Oct 2016 02:02:58 +0530, wrote: > From: Jitendra Kumar Khasdev > > This patch is for replacing obsolete simple_strtoul to kstrtoul which remove > warning produce by checkpatch. > + unsigned long val; > + > + if (kstrtoul(start,

Re: error: 'struct net_device' has no member named 'nf_hooks_ingress'

On Wed, 2016-10-05 at 22:56 +0200, Michal Sojka wrote: > this commit is now in mainline as > e3b37f11e6e4e6b6f02cc762f182ce233d2c1c9d and it breaks my build: > > net/netfilter/core.c: In function 'nf_set_hooks_head': > net/netfilter/core.c:96:3: error: 'struct net_device' has no member

Re: [PATCH] staging: speakup: Replaced obsolete simple_strtoul

Hello, Jitendra Khasdev, on Thu 06 Oct 2016 02:02:58 +0530, wrote: > From: Jitendra Kumar Khasdev > > This patch is for replacing obsolete simple_strtoul to kstrtoul which remove > warning produce by checkpatch. > + unsigned long val; > + > + if (kstrtoul(start, 10, )) > +

Re: error: 'struct net_device' has no member named 'nf_hooks_ingress'

On Wed, 2016-10-05 at 22:56 +0200, Michal Sojka wrote: > this commit is now in mainline as > e3b37f11e6e4e6b6f02cc762f182ce233d2c1c9d and it breaks my build: > > net/netfilter/core.c: In function 'nf_set_hooks_head': > net/netfilter/core.c:96:3: error: 'struct net_device' has no member

Re: [RFC v3 11/22] seccomp,landlock: Handle Landlock hooks per process hierarchy

On 04/10/2016 01:52, Kees Cook wrote: > On Wed, Sep 14, 2016 at 3:34 PM, Mickaël Salaün wrote: >> >> On 14/09/2016 20:43, Andy Lutomirski wrote: >>> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: A Landlock program will be triggered according

Re: [RFC v3 11/22] seccomp,landlock: Handle Landlock hooks per process hierarchy

On 04/10/2016 01:52, Kees Cook wrote: > On Wed, Sep 14, 2016 at 3:34 PM, Mickaël Salaün wrote: >> >> On 14/09/2016 20:43, Andy Lutomirski wrote: >>> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: A Landlock program will be triggered according to its subtype/origin bitfield.

Re: [RESEND PATCH v2 2/3] cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs

On 4 October 2016 at 20:25, Viresh Kumar wrote: > On 30-09-16, 14:56, Markus Mayer wrote: >> This driver supports voltage and frequency scaling on Broadcom STB SoCs >> using AVS firmware with DFS and DVFS support. >> >> Actual frequency or voltage scaling is done

Re: [RESEND PATCH v2 2/3] cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs

On 4 October 2016 at 20:25, Viresh Kumar wrote: > On 30-09-16, 14:56, Markus Mayer wrote: >> This driver supports voltage and frequency scaling on Broadcom STB SoCs >> using AVS firmware with DFS and DVFS support. >> >> Actual frequency or voltage scaling is done exclusively by the AVS >>

error: 'struct net_device' has no member named 'nf_hooks_ingress'

Hi, On Tue, Oct 04 2016, Sergey Senozhatsky wrote: > On (09/27/16 19:03), Sergey Senozhatsky wrote: >> Hello, >> >> On (09/27/16 16:40), Stephen Rothwell wrote: >> > >> > Changes since 20160923: >> > >> >> seems that commit e3b37f11e6e4e6b6 ("netfilter: replace list_head with >> single linked

error: 'struct net_device' has no member named 'nf_hooks_ingress'

Hi, On Tue, Oct 04 2016, Sergey Senozhatsky wrote: > On (09/27/16 19:03), Sergey Senozhatsky wrote: >> Hello, >> >> On (09/27/16 16:40), Stephen Rothwell wrote: >> > >> > Changes since 20160923: >> > >> >> seems that commit e3b37f11e6e4e6b6 ("netfilter: replace list_head with >> single linked

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

On Wed, Oct 05, 2016 at 09:44:53PM +0100, Mark Rutland wrote: > The zeroing case is similar to the restartable sequences design. So that's > probably worth looking into. You're sending mixed messages: in your previous message, you said: Arguably, someone could have (ab)used TPIDRURW between

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

On Wed, Oct 05, 2016 at 09:44:53PM +0100, Mark Rutland wrote: > The zeroing case is similar to the restartable sequences design. So that's > probably worth looking into. You're sending mixed messages: in your previous message, you said: Arguably, someone could have (ab)used TPIDRURW between

Re: [RFC v3 19/22] landlock: Add interrupted origin

On 04/10/2016 01:46, Kees Cook wrote: > On Wed, Sep 14, 2016 at 6:19 PM, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 3:14 PM, Mickaël Salaün wrote: >>> >>> On 14/09/2016 20:29, Andy Lutomirski wrote: On Wed, Sep 14, 2016 at 12:24 AM, Mickaël

Re: [RFC v3 19/22] landlock: Add interrupted origin

On 04/10/2016 01:46, Kees Cook wrote: > On Wed, Sep 14, 2016 at 6:19 PM, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 3:14 PM, Mickaël Salaün wrote: >>> >>> On 14/09/2016 20:29, Andy Lutomirski wrote: On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: > This third origin of

Re: [PATCH] printk: introduce kptr_restrict level 3

On Wed, Oct 05 2016, william.c.robe...@intel.com 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,

Re: [PATCH] printk: introduce kptr_restrict level 3

On Wed, Oct 05 2016, william.c.robe...@intel.com 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

Re: [RFC v3 16/22] bpf/cgroup,landlock: Handle Landlock hooks per cgroup

On 04/10/2016 01:43, Kees Cook wrote: > On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: >> This allows to add new eBPF programs to Landlock hooks dedicated to a >> cgroup thanks to the BPF_PROG_ATTACH command. Like for socket eBPF >> programs, the Landlock hooks

Re: [RFC v3 16/22] bpf/cgroup,landlock: Handle Landlock hooks per cgroup

On 04/10/2016 01:43, Kees Cook wrote: > On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: >> This allows to add new eBPF programs to Landlock hooks dedicated to a >> cgroup thanks to the BPF_PROG_ATTACH command. Like for socket eBPF >> programs, the Landlock hooks attached to a cgroup are

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

bluetooth.h is not part of user API, so __ variants are not neccessary here. Signed-off-by: Pavel Machek --- v2: not touching stuff that Marcel does not want touched, as it will become API later. diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h

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

bluetooth.h is not part of user API, so __ variants are not neccessary here. Signed-off-by: Pavel Machek --- v2: not touching stuff that Marcel does not want touched, as it will become API later. diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h index

Re: [PATCH v5 1/5] firmware: document user mode helper lock usage

On Fri, Sep 23, 2016 at 10:13:44AM +0200, Daniel Wagner wrote: > On 09/22/2016 04:36 AM, Ming Lei wrote: > >On Sat, Sep 10, 2016 at 6:14 AM, Luis R. Rodriguez wrote: > >>On Fri, Sep 09, 2016 at 02:12:20PM +0200, Daniel Wagner wrote: > >>>From: Daniel Wagner

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

On Wed, Oct 05, 2016 at 09:47:19PM +0200, Paolo Valente wrote: > > > 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

Re: [PATCH v5 1/5] firmware: document user mode helper lock usage

On Fri, Sep 23, 2016 at 10:13:44AM +0200, Daniel Wagner wrote: > On 09/22/2016 04:36 AM, Ming Lei wrote: > >On Sat, Sep 10, 2016 at 6:14 AM, Luis R. Rodriguez wrote: > >>On Fri, Sep 09, 2016 at 02:12:20PM +0200, Daniel Wagner wrote: > >>>From: Daniel Wagner > >>> > >>>The lock is also used to

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

On Wed, Oct 05, 2016 at 09:47:19PM +0200, Paolo Valente wrote: > > > 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: >

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

On Wed, Oct 05, 2016 at 08:00:38PM +, Fredrik Markström wrote: > On Wed, Oct 5, 2016 at 7:48 PM Robin Murphy wrote: > As far as I understand TPIDRURW isn't anything else then an architecture > specific piece of tls since the last patch, possibly slightly faster then a >

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

On Wed, Oct 05, 2016 at 08:00:38PM +, Fredrik Markström wrote: > On Wed, Oct 5, 2016 at 7:48 PM Robin Murphy wrote: > As far as I understand TPIDRURW isn't anything else then an architecture > specific piece of tls since the last patch, possibly slightly faster then a > "__thread u32 x;" > >

Re: [PATCH v5 1/5] firmware: document user mode helper lock usage

On Thu, Sep 22, 2016 at 10:36:39AM +0800, Ming Lei wrote: > On Sat, Sep 10, 2016 at 6:14 AM, Luis R. Rodriguez wrote: > > On Fri, Sep 09, 2016 at 02:12:20PM +0200, Daniel Wagner wrote: > >> From: Daniel Wagner > >> > >> The lock is also used to

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

On Wed, Oct 05, 2016 at 02:25:22PM +0200, Fredrik Markström wrote: > On Tue, Oct 4, 2016 at 7:08 PM Mark Rutland wrote: > > On Tue, Oct 04, 2016 at 05:35:33PM +0200, Fredrik Markstrom wrote: > The way I was trying to defend the breakage was by reasoning that that if it > was

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

On Wed, Oct 05, 2016 at 02:25:22PM +0200, Fredrik Markström wrote: > On Tue, Oct 4, 2016 at 7:08 PM Mark Rutland wrote: > > On Tue, Oct 04, 2016 at 05:35:33PM +0200, Fredrik Markstrom wrote: > The way I was trying to defend the breakage was by reasoning that that if it > was an ABI we broke it

Re: [PATCH v5 1/5] firmware: document user mode helper lock usage

On Thu, Sep 22, 2016 at 10:36:39AM +0800, Ming Lei wrote: > On Sat, Sep 10, 2016 at 6:14 AM, Luis R. Rodriguez wrote: > > On Fri, Sep 09, 2016 at 02:12:20PM +0200, Daniel Wagner wrote: > >> From: Daniel Wagner > >> > >> The lock is also used to generate warnings when a direct > >> firmware load

[PATCH] ARCv2: intc: untangle SMP, MCIP and IDU

The IDU intc is technically part of MCIP (Multi-core IP) hence historically was only available in a SMP hardware build (and thus only in a SMP kernel build). Now that hardware restriction has been lifted, so a UP kernel needs to support it. This requires breaking mcip.c into parts which are

[PATCH] ARCv2: intc: untangle SMP, MCIP and IDU

The IDU intc is technically part of MCIP (Multi-core IP) hence historically was only available in a SMP hardware build (and thus only in a SMP kernel build). Now that hardware restriction has been lifted, so a UP kernel needs to support it. This requires breaking mcip.c into parts which are

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

On Wed, Oct 05, 2016 at 09:57:22PM +0200, Paolo Valente wrote: > > > 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.

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

On Wed, Oct 05, 2016 at 09:57:22PM +0200, Paolo Valente wrote: > > > 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. > >>> > >>>

Re: [PATCH v5 2/5] firmware: encapsulate firmware loading status

On Tue, Sep 13, 2016 at 11:47:08AM +0200, Daniel Wagner wrote: > Hi Luis, > > > On 09/09/2016 02:12 PM, Daniel Wagner wrote: > >The firmware user helper code tracks the current state of the loading > >process via unsigned long status and a complection in struct > >firmware_buf. We only need this

Re: [PATCH v5 2/5] firmware: encapsulate firmware loading status

On Tue, Sep 13, 2016 at 11:47:08AM +0200, Daniel Wagner wrote: > Hi Luis, > > > On 09/09/2016 02:12 PM, Daniel Wagner wrote: > >The firmware user helper code tracks the current state of the loading > >process via unsigned long status and a complection in struct > >firmware_buf. We only need this

Re: [PATCH] fs/block_dev.c: return the right error in thaw_bdev()

On 10/04/2016 03:06 AM, Jan Kara wrote: On Tue 04-10-16 10:53:40, Pierre Morel wrote: When triggering thaw-filesystems via magic sysrq, the system enters a loop in do_thaw_one(), as thaw_bdev() still returns success if bd_fsfreeze_count == 0. To fix this, let thaw_bdev() always return error

Re: [PATCH] fs/block_dev.c: return the right error in thaw_bdev()

On 10/04/2016 03:06 AM, Jan Kara wrote: On Tue 04-10-16 10:53:40, Pierre Morel wrote: When triggering thaw-filesystems via magic sysrq, the system enters a loop in do_thaw_one(), as thaw_bdev() still returns success if bd_fsfreeze_count == 0. To fix this, let thaw_bdev() always return error

4.8 ia64: usercopy: kernel memory exposure attempt detected

This is 4.8 on HP rx2620, with usercopy checks. How do I find out the culprit? [9.013642] VFS: Mounted root (ext4 filesystem) readonly on device 8:3. [9.033645] devtmpfs: mounted [9.033645] Freeing unused kernel memory: 800K (e4b38000 - e4c0) [9.033645] This

[PATCH] staging: speakup: Replaced obsolete simple_strtoul

From: Jitendra Kumar Khasdev This patch is for replacing obsolete simple_strtoul to kstrtoul which remove warning produce by checkpatch. Signed-off-by: Jitendra Kumar Khasdev --- drivers/staging/speakup/varhandlers.c | 6 -- 1 file changed, 4

4.8 ia64: usercopy: kernel memory exposure attempt detected

This is 4.8 on HP rx2620, with usercopy checks. How do I find out the culprit? [9.013642] VFS: Mounted root (ext4 filesystem) readonly on device 8:3. [9.033645] devtmpfs: mounted [9.033645] Freeing unused kernel memory: 800K (e4b38000 - e4c0) [9.033645] This

[PATCH] staging: speakup: Replaced obsolete simple_strtoul

From: Jitendra Kumar Khasdev This patch is for replacing obsolete simple_strtoul to kstrtoul which remove warning produce by checkpatch. Signed-off-by: Jitendra Kumar Khasdev --- drivers/staging/speakup/varhandlers.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

Re: [Intel-gfx] [PATCH 4/6] drm/i915/gen9: Make skl_wm_level per-plane

Em Qua, 2016-10-05 às 11:33 -0400, Lyude escreveu: > Having skl_wm_level contain all of the watermarks for each plane is > annoying since it prevents us from having any sort of object to > represent a single watermark level, something we take advantage of in > the next commit to cut down on all of

Re: [Intel-gfx] [PATCH 4/6] drm/i915/gen9: Make skl_wm_level per-plane

Em Qua, 2016-10-05 às 11:33 -0400, Lyude escreveu: > Having skl_wm_level contain all of the watermarks for each plane is > annoying since it prevents us from having any sort of object to > represent a single watermark level, something we take advantage of in > the next commit to cut down on all of

Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing

On 04/10/2016 00:56, Kees Cook wrote: > On Tue, Sep 20, 2016 at 10:08 AM, Mickaël Salaün wrote: >> >> On 15/09/2016 11:19, Pavel Machek wrote: >>> Hi! >>> This series is a proof of concept to fill some missing part of seccomp as the ability to check syscall

Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing

On 04/10/2016 00:56, Kees Cook wrote: > On Tue, Sep 20, 2016 at 10:08 AM, Mickaël Salaün wrote: >> >> On 15/09/2016 11:19, Pavel Machek wrote: >>> Hi! >>> This series is a proof of concept to fill some missing part of seccomp as the ability to check syscall argument pointers or

Re: kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)

On Wed, 5 Oct 2016, Jani Nikula wrote: > On Wed, 05 Oct 2016, Daniel Vetter wrote: > > Jani Nikula has a patch with a scrip to make the one kernel-doc parser > > into a lint/checker pass over the entire kernel. I think that'd would > > be more robust instead of trying to

Re: kernel-doc-rst-lint (was: Re: [PATCH 00/15] improve function-level documentation)

On Wed, 5 Oct 2016, Jani Nikula wrote: > On Wed, 05 Oct 2016, Daniel Vetter wrote: > > Jani Nikula has a patch with a scrip to make the one kernel-doc parser > > into a lint/checker pass over the entire kernel. I think that'd would > > be more robust instead of trying to approximate the real

Re: [Intel-gfx] [PATCH 2/6] drm/i915/skl: Remove linetime from skl_wm_values

Em Qua, 2016-10-05 às 11:33 -0400, Lyude escreveu: > Next part of cleaning up the watermark code for skl. This is easy, > since > it seems that we never actually needed to keep track of the linetime > in > the skl_wm_values struct anyway. Reviewed-by: Paulo Zanoni > >

Re: [Intel-gfx] [PATCH 2/6] drm/i915/skl: Remove linetime from skl_wm_values

Em Qua, 2016-10-05 às 11:33 -0400, Lyude escreveu: > Next part of cleaning up the watermark code for skl. This is easy, > since > it seems that we never actually needed to keep track of the linetime > in > the skl_wm_values struct anyway. Reviewed-by: Paulo Zanoni > > Signed-off-by: Lyude >

Re: [Intel-gfx] [PATCH 1/6] drm/i915/skl: Move per-pipe ddb allocations into crtc states

Em Qua, 2016-10-05 às 11:33 -0400, Lyude escreveu: > First part of cleaning up all of the skl watermark code. This moves > the > structures for storing the ddb allocations of each pipe into > intel_crtc_state, along with moving the structures for storing the > current ddb allocations active on

Re: [Intel-gfx] [PATCH 1/6] drm/i915/skl: Move per-pipe ddb allocations into crtc states

Em Qua, 2016-10-05 às 11:33 -0400, Lyude escreveu: > First part of cleaning up all of the skl watermark code. This moves > the > structures for storing the ddb allocations of each pipe into > intel_crtc_state, along with moving the structures for storing the > current ddb allocations active on

Re: [PATCH] fs/block_dev.c: return the right error in thaw_bdev()

On Wed, Oct 05, 2016 at 11:59:03AM +0200, Jan Kara wrote: > On Wed 05-10-16 08:47:42, Mateusz Guzik wrote: > > On Tue, Oct 04, 2016 at 11:06:15AM +0200, Jan Kara wrote: > > > On Tue 04-10-16 10:53:40, Pierre Morel wrote: > > > > When triggering thaw-filesystems via magic sysrq, the system enters a

Re: [PATCH] fs/block_dev.c: return the right error in thaw_bdev()

On Wed, Oct 05, 2016 at 11:59:03AM +0200, Jan Kara wrote: > On Wed 05-10-16 08:47:42, Mateusz Guzik wrote: > > On Tue, Oct 04, 2016 at 11:06:15AM +0200, Jan Kara wrote: > > > On Tue 04-10-16 10:53:40, Pierre Morel wrote: > > > > When triggering thaw-filesystems via magic sysrq, the system enters a

Re: [GIT PULL] Staging/IIO driver patches for 4.9-rc1

On Wed, Oct 05, 2016 at 09:32:01AM -0700, Linus Torvalds wrote: > On Wed, Oct 5, 2016 at 12:22 AM, Greg KH wrote: > > > > Here is the big staging and IIO driver pull request for 4.9-rc1. > > > > There are a lot of patches in here, the majority due to the > >

Re: [GIT PULL] Staging/IIO driver patches for 4.9-rc1

On Wed, Oct 05, 2016 at 09:32:01AM -0700, Linus Torvalds wrote: > On Wed, Oct 5, 2016 at 12:22 AM, Greg KH wrote: > > > > Here is the big staging and IIO driver pull request for 4.9-rc1. > > > > There are a lot of patches in here, the majority due to the > > drivers/staging/greybus/ subsystem

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