Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Mon, Sep 12, 2016 at 11:40:35AM +1000, Dave Chinner wrote: > On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote: > > On Wed, Sep 07, 2016 at 09:32:36PM -0700, Dan Williams wrote: > > > My understanding is that it is looking for the VM_MIXEDMAP flag which > > > is already ambiguous for

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Mon, Sep 12, 2016 at 11:40:35AM +1000, Dave Chinner wrote: > On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote: > > On Wed, Sep 07, 2016 at 09:32:36PM -0700, Dan Williams wrote: > > > My understanding is that it is looking for the VM_MIXEDMAP flag which > > > is already ambiguous for

Re: [PATCH] kvm, x86: Properly check whether a pfn is an MMIO or not

> On Jun 22, 2016, at 3:41 PM, Paolo Bonzini wrote: > > > > On 22/06/2016 04:34, KarimAllah Ahmed wrote: >> pfn_valid check is not sufficient because it only checks if a page has a >> struct >> page or not, if for example "mem=" was passed to the kernel some valid pages

Re: [PATCH] kvm, x86: Properly check whether a pfn is an MMIO or not

> On Jun 22, 2016, at 3:41 PM, Paolo Bonzini wrote: > > > > On 22/06/2016 04:34, KarimAllah Ahmed wrote: >> pfn_valid check is not sufficient because it only checks if a page has a >> struct >> page or not, if for example "mem=" was passed to the kernel some valid pages >> won't have a

Re: perf: perf_fuzzer lockup in perf_cgroup_attach

On Wed, Sep 14, 2016 at 7:43 PM, Vince Weaver wrote: > > so the skylake that was fuzzing finally is mostly locked up. > > Really hard to tell what's going, especially as KASLR made looking up the > addresses a big pain. > I would think there is a way to disable KASLR for

Re: perf: perf_fuzzer lockup in perf_cgroup_attach

On Wed, Sep 14, 2016 at 7:43 PM, Vince Weaver wrote: > > so the skylake that was fuzzing finally is mostly locked up. > > Really hard to tell what's going, especially as KASLR made looking up the > addresses a big pain. > I would think there is a way to disable KASLR for this kind of testing!

Re: [PATCH V2 2/3] net-next: dsa: add Qualcomm tag RX/TX handler

On 09/14/2016 03:39 AM, John Crispin wrote: > Add support for the 2-bytes Qualcomm tag that gigabit switches such as > the QCA8337/N might insert when receiving packets, or that we need > to insert while targeting specific switch ports. The tag is inserted > directly behind the ethernet header. >

Re: [PATCH V2 2/3] net-next: dsa: add Qualcomm tag RX/TX handler

On 09/14/2016 03:39 AM, John Crispin wrote: > Add support for the 2-bytes Qualcomm tag that gigabit switches such as > the QCA8337/N might insert when receiving packets, or that we need > to insert while targeting specific switch ports. The tag is inserted > directly behind the ethernet header. >

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

On Wed, Sep 14, 2016 at 10:42:50AM -0700, Stephen Boyd wrote: > > > > > > Hmm.. maybe the confusion is in which registers we should be able to > > > access? Are we talking about the ULPI viewport MMIO register space or > > > the ULPI registers that we access through the viewport? I have a > > >

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

On Wed, Sep 14, 2016 at 10:42:50AM -0700, Stephen Boyd wrote: > > > > > > Hmm.. maybe the confusion is in which registers we should be able to > > > access? Are we talking about the ULPI viewport MMIO register space or > > > the ULPI registers that we access through the viewport? I have a > > >

Re: [PATCH] clk: Add USB3 PHY reset lines

On Thu, Sep 15, 2016 at 10:15 AM, wrote: > From: Vivek Gautam a stale "--from " flag in my command added this line. Will take care of it from next time. > > Adding missing reset lines for USB 3.0 PHY. > > Signed-off-by: Vivek Gautam

Re: [PATCH] clk: Add USB3 PHY reset lines

On Thu, Sep 15, 2016 at 10:15 AM, wrote: > From: Vivek Gautam a stale "--from " flag in my command added this line. Will take care of it from next time. > > Adding missing reset lines for USB 3.0 PHY. > > Signed-off-by: Vivek Gautam > --- [snip] -- Qualcomm Innovation Center, Inc. is a

RE: [PATCH 1/6] PCI: xilinx: Keep both legacy and MSI interrupt references.

On Wed, Sep 14, 2016 at 03:32:44PM +, Bharat Kumar Gogada wrote: > On Thu, Sep 01, 2016 at 03:44:41PM +0530, Bharat Kumar Gogada wrote: > > When built with MSI support the legacy domain reference is being > > overwritten with MSI. > > Instead creating two separate domains for MSI and legacy

RE: [PATCH 1/6] PCI: xilinx: Keep both legacy and MSI interrupt references.

On Wed, Sep 14, 2016 at 03:32:44PM +, Bharat Kumar Gogada wrote: > On Thu, Sep 01, 2016 at 03:44:41PM +0530, Bharat Kumar Gogada wrote: > > When built with MSI support the legacy domain reference is being > > overwritten with MSI. > > Instead creating two separate domains for MSI and legacy

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 09:38:16PM -0700, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 9:31 PM, Alexei Starovoitov > wrote: > > On Wed, Sep 14, 2016 at 09:08:57PM -0700, Andy Lutomirski wrote: > >> On Wed, Sep 14, 2016 at 9:00 PM, Alexei Starovoitov > >>

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 09:38:16PM -0700, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 9:31 PM, Alexei Starovoitov > wrote: > > On Wed, Sep 14, 2016 at 09:08:57PM -0700, Andy Lutomirski wrote: > >> On Wed, Sep 14, 2016 at 9:00 PM, Alexei Starovoitov > >> wrote: > >> > On Wed, Sep 14, 2016 at

[PATCH] clk: Add USB3 PHY reset lines

From: Vivek Gautam Adding missing reset lines for USB 3.0 PHY. Signed-off-by: Vivek Gautam --- - Build tested on clk-next branch. - Tested with my wip branch for usbphy that is available @[1].

[PATCH] clk: Add USB3 PHY reset lines

From: Vivek Gautam Adding missing reset lines for USB 3.0 PHY. Signed-off-by: Vivek Gautam --- - Build tested on clk-next branch. - Tested with my wip branch for usbphy that is available @[1]. [1]https://github.com/vivekgautam1/linux/tree/linaro/integration-linux-qcomlt-usbphy-wip

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 9:31 PM, Alexei Starovoitov wrote: > On Wed, Sep 14, 2016 at 09:08:57PM -0700, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 9:00 PM, Alexei Starovoitov >> wrote: >> > On Wed, Sep 14, 2016 at 07:27:08PM

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 9:31 PM, Alexei Starovoitov wrote: > On Wed, Sep 14, 2016 at 09:08:57PM -0700, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 9:00 PM, Alexei Starovoitov >> wrote: >> > On Wed, Sep 14, 2016 at 07:27:08PM -0700, Andy Lutomirski wrote: >> >> >> > >> >> >> > This RFC

Re: [PATCH v4] arm64: Improve kprobes test for atomic sequence

On Mon, 12 Sep 2016 21:07:40 -0400 David Long wrote: > > After the patch the function reads as follows: > > > enum kprobe_insn __kprobes > > arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn > > *asi) > > { > > enum kprobe_insn decoded; > >

Re: [PATCH v4] arm64: Improve kprobes test for atomic sequence

On Mon, 12 Sep 2016 21:07:40 -0400 David Long wrote: > > After the patch the function reads as follows: > > > enum kprobe_insn __kprobes > > arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn > > *asi) > > { > > enum kprobe_insn decoded; > > kprobe_opcode_t insn =

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 09:08:57PM -0700, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 9:00 PM, Alexei Starovoitov > wrote: > > On Wed, Sep 14, 2016 at 07:27:08PM -0700, Andy Lutomirski wrote: > >> >> > > >> >> > This RFC handle both cgroup and seccomp approaches

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 09:08:57PM -0700, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 9:00 PM, Alexei Starovoitov > wrote: > > On Wed, Sep 14, 2016 at 07:27:08PM -0700, Andy Lutomirski wrote: > >> >> > > >> >> > This RFC handle both cgroup and seccomp approaches in a similar way. I > >> >> >

Re: [PATCH] KVM: VMX: Enable MSR-BASED TPR shadow even if w/o APICv

2016-09-15 12:08 GMT+08:00 Mika Penttilä : > On 09/14/2016 10:58 AM, Wanpeng Li wrote: >> From: Wanpeng Li >> >> I observed that kvmvapic(to optimize flexpriority=N or AMD) is used >> to boost TPR access when testing kvm-unit-test/eventinj.flat

Re: [PATCH] KVM: VMX: Enable MSR-BASED TPR shadow even if w/o APICv

2016-09-15 12:08 GMT+08:00 Mika Penttilä : > On 09/14/2016 10:58 AM, Wanpeng Li wrote: >> From: Wanpeng Li >> >> I observed that kvmvapic(to optimize flexpriority=N or AMD) is used >> to boost TPR access when testing kvm-unit-test/eventinj.flat tpr case >> on my haswell desktop (w/ flexpriority,

Re: [PATCH] KVM: VMX: Enable MSR-BASED TPR shadow even if w/o APICv

On 09/14/2016 10:58 AM, Wanpeng Li wrote: > From: Wanpeng Li > > I observed that kvmvapic(to optimize flexpriority=N or AMD) is used > to boost TPR access when testing kvm-unit-test/eventinj.flat tpr case > on my haswell desktop (w/ flexpriority, w/o APICv). Commit

Re: [PATCH] KVM: VMX: Enable MSR-BASED TPR shadow even if w/o APICv

On 09/14/2016 10:58 AM, Wanpeng Li wrote: > From: Wanpeng Li > > I observed that kvmvapic(to optimize flexpriority=N or AMD) is used > to boost TPR access when testing kvm-unit-test/eventinj.flat tpr case > on my haswell desktop (w/ flexpriority, w/o APICv). Commit (8d14695f9542 > x86, apicv:

Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware

On Wed, 2016-09-14 at 21:08 -0500, Eric W. Biederman wrote: > Ian Kent writes: > > > On Wed, 2016-09-14 at 12:28 -0500, Eric W. Biederman wrote: > > > Ian Kent writes: > > > > > > > If an automount mount is clone(2)ed into a file system that is > > > >

Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware

On Wed, 2016-09-14 at 21:08 -0500, Eric W. Biederman wrote: > Ian Kent writes: > > > On Wed, 2016-09-14 at 12:28 -0500, Eric W. Biederman wrote: > > > Ian Kent writes: > > > > > > > If an automount mount is clone(2)ed into a file system that is > > > > propagation private, when it later

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 9:00 PM, Alexei Starovoitov wrote: > On Wed, Sep 14, 2016 at 07:27:08PM -0700, Andy Lutomirski wrote: >> >> > >> >> > This RFC handle both cgroup and seccomp approaches in a similar way. I >> >> > don't see why building on top of cgroup v2 is

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 9:00 PM, Alexei Starovoitov wrote: > On Wed, Sep 14, 2016 at 07:27:08PM -0700, Andy Lutomirski wrote: >> >> > >> >> > This RFC handle both cgroup and seccomp approaches in a similar way. I >> >> > don't see why building on top of cgroup v2 is a problem. Is there >> >> >

[PATCH] rtc/rtc-cmos: Initialize hpet timer before irq is registered

We have observed on few x86 machines with rtc-cmos device that hpet_rtc_interrupt() is called just after irq registration and before cmos_do_probe() could call hpet_rtc_timer_init(). So, neither hpet_default_delta nor hpet_t1_cmp is initialized by the time interrupt is raised in the given

[PATCH] rtc/rtc-cmos: Initialize hpet timer before irq is registered

We have observed on few x86 machines with rtc-cmos device that hpet_rtc_interrupt() is called just after irq registration and before cmos_do_probe() could call hpet_rtc_timer_init(). So, neither hpet_default_delta nor hpet_t1_cmp is initialized by the time interrupt is raised in the given

rcu_sched self-detected stall on CPU

Hello, I've been testing out KASAN and experimenting with some other new config settings related to security and kernel hardening, I ran into a problem though and I've attached a snippet of my kernel log of the stack trace as well as my kernel config. Also intermittently (every few seconds just

rcu_sched self-detected stall on CPU

Hello, I've been testing out KASAN and experimenting with some other new config settings related to security and kernel hardening, I ran into a problem though and I've attached a snippet of my kernel log of the stack trace as well as my kernel config. Also intermittently (every few seconds just

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 07:27:08PM -0700, Andy Lutomirski wrote: > >> > > >> > This RFC handle both cgroup and seccomp approaches in a similar way. I > >> > don't see why building on top of cgroup v2 is a problem. Is there > >> > security issues with delegation? > >> > >> What I mean is: cgroup v2

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 07:27:08PM -0700, Andy Lutomirski wrote: > >> > > >> > This RFC handle both cgroup and seccomp approaches in a similar way. I > >> > don't see why building on top of cgroup v2 is a problem. Is there > >> > security issues with delegation? > >> > >> What I mean is: cgroup v2

RE: [PATCH] dmaengine: dmatest: Restore "memcpy" as default mode

> -Original Message- > From: Eugeniy Paltsev [mailto:eugeniy.palt...@synopsys.com] > Sent: Wednesday, September 14, 2016 11:11 PM > To: dmaeng...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Appana Durga Kedareswara Rao > ; vinod.k...@intel.com;

RE: [PATCH] dmaengine: dmatest: Restore "memcpy" as default mode

> -Original Message- > From: Eugeniy Paltsev [mailto:eugeniy.palt...@synopsys.com] > Sent: Wednesday, September 14, 2016 11:11 PM > To: dmaeng...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Appana Durga Kedareswara Rao > ; vinod.k...@intel.com; dan.j.willi...@intel.com; >

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Thu, 15 Sep 2016 12:31:33 +1000 Dave Chinner wrote: > On Wed, Sep 14, 2016 at 08:19:36PM +1000, Nicholas Piggin wrote: > > On Wed, 14 Sep 2016 17:39:02 +1000 > > Dave Chinner wrote: > > > Ok, looking back over your example, you seem to be

RE: [PATCH for-next 10/20] IB/hns: Modify the init of iboe lock

> -Original Message- > From: Leon Romanovsky [mailto:l...@kernel.org] > Sent: Wednesday, September 14, 2016 6:05 AM > To: Salil Mehta > Cc: dledf...@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen); > xuwei (O); mehta.salil@gmail.com; linux-r...@vger.kernel.org; >

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Thu, 15 Sep 2016 12:31:33 +1000 Dave Chinner wrote: > On Wed, Sep 14, 2016 at 08:19:36PM +1000, Nicholas Piggin wrote: > > On Wed, 14 Sep 2016 17:39:02 +1000 > > Dave Chinner wrote: > > > Ok, looking back over your example, you seem to be suggesting a new > > > page fault behaviour is

RE: [PATCH for-next 10/20] IB/hns: Modify the init of iboe lock

> -Original Message- > From: Leon Romanovsky [mailto:l...@kernel.org] > Sent: Wednesday, September 14, 2016 6:05 AM > To: Salil Mehta > Cc: dledf...@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen); > xuwei (O); mehta.salil@gmail.com; linux-r...@vger.kernel.org; >

[PATCH v3) posix-timers: make it configurable

Many embedded systems typically don't need them. This removes about 22KB from the kernel binary size on ARM when configured out. Corresponding syscalls are routed to a stub logging the attempt to use those syscalls which should be enough of a clue if they were disabled without proper

[PATCH v3) posix-timers: make it configurable

Many embedded systems typically don't need them. This removes about 22KB from the kernel binary size on ARM when configured out. Corresponding syscalls are routed to a stub logging the attempt to use those syscalls which should be enough of a clue if they were disabled without proper

linux-next: build warning after merge of the lightnvm tree

Hi Matias, After merging the lightnvm tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/lightnvm/sysfs.c: In function 'nvm_sysfs_register_dev': drivers/lightnvm/sysfs.c:184:2: warning: ignoring return value of 'device_add', declared with attribute

linux-next: build warning after merge of the lightnvm tree

Hi Matias, After merging the lightnvm tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/lightnvm/sysfs.c: In function 'nvm_sysfs_register_dev': drivers/lightnvm/sysfs.c:184:2: warning: ignoring return value of 'device_add', declared with attribute

RE: [PATCH for-next 13/20] IB/hns: Add check for some NULL pointer scenes

> -Original Message- > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- > ow...@vger.kernel.org] On Behalf Of Leon Romanovsky > Sent: Tuesday, September 13, 2016 8:00 AM > To: Salil Mehta > Cc: dledf...@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen); > xuwei (O);

RE: [PATCH for-next 13/20] IB/hns: Add check for some NULL pointer scenes

> -Original Message- > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- > ow...@vger.kernel.org] On Behalf Of Leon Romanovsky > Sent: Tuesday, September 13, 2016 8:00 AM > To: Salil Mehta > Cc: dledf...@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen); > xuwei (O);

[PATCH -next] mailbox: platform_mhu: Remove redundant dev_err call in platform_mhu_probe()

From: Wei Yongjun There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun --- drivers/mailbox/platform_mhu.c | 4 +--- 1 file changed, 1 insertion(+),

[PATCH -next] mailbox: platform_mhu: Remove redundant dev_err call in platform_mhu_probe()

From: Wei Yongjun There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun --- drivers/mailbox/platform_mhu.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH -next] nbd: fix return value check

From: Wei Yongjun In case of error, the function blk_mq_alloc_request() or blk_mq_init_queue() returns ERR_PTR() not NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: fd8383fd88a2 ("nbd: convert to blkmq") Signed-off-by: Wei Yongjun

[PATCH -next] nbd: fix return value check

From: Wei Yongjun In case of error, the function blk_mq_alloc_request() or blk_mq_init_queue() returns ERR_PTR() not NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: fd8383fd88a2 ("nbd: convert to blkmq") Signed-off-by: Wei Yongjun ---

[PATCH -next] drm/sun4i: backend: remove redundant dev_err call in sun4i_backend_bind()

From: Wei Yongjun There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun --- drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +--- 1 file changed, 1

[PATCH -next] drm/sun4i: backend: remove redundant dev_err call in sun4i_backend_bind()

From: Wei Yongjun There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun --- drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

Re: [PATCH 0/5] Make /sys/class/net per net namespace objects belong to container

On Mon, Aug 29, 2016 at 5:38 AM, Eric W. Biederman wrote: > David Miller writes: > >> From: Dmitry Torokhov >> Date: Tue, 16 Aug 2016 15:33:10 -0700 >> >>> There are objects in /sys hierarchy (/sys/class/net/) that logically

Re: [PATCH 0/5] Make /sys/class/net per net namespace objects belong to container

On Mon, Aug 29, 2016 at 5:38 AM, Eric W. Biederman wrote: > David Miller writes: > >> From: Dmitry Torokhov >> Date: Tue, 16 Aug 2016 15:33:10 -0700 >> >>> There are objects in /sys hierarchy (/sys/class/net/) that logically belong >>> to a namespace/container. Unfortunately all sysfs objects

[PATCH] DRM: i915: Fix gen8 graphics on Broadwell-U. These patches stop the random gpu hang on my XPS-13-9343, kernel version 4.8-rc5.

Signed-off-by: bobcao3 --- drivers/gpu/drm/i915/i915_gem_gtt.c | 6 drivers/gpu/drm/i915/i915_gem_stolen.c | 61 - drivers/gpu/drm/i915/i915_reg.h | 6 drivers/gpu/drm/i915/intel_ringbuffer.c | 19 +- 4 files

[PATCH] DRM: i915: Fix gen8 graphics on Broadwell-U. These patches stop the random gpu hang on my XPS-13-9343, kernel version 4.8-rc5.

Signed-off-by: bobcao3 --- drivers/gpu/drm/i915/i915_gem_gtt.c | 6 drivers/gpu/drm/i915/i915_gem_stolen.c | 61 - drivers/gpu/drm/i915/i915_reg.h | 6 drivers/gpu/drm/i915/intel_ringbuffer.c | 19 +- 4 files changed, 59

Re: [PATCH] cpufreq: CPPC: Avoid overflow when calculating desired_perf

Hi Rafael, On Wed, Sep 14, 2016 at 5:50 PM, Rafael J. Wysocki wrote: > On Wednesday, September 14, 2016 04:08:28 PM Hoan Tran wrote: >> This patch fixes overflow issue when calculating the desired_perf. >> >> Signed-off-by: Hoan Tran >> --- >>

Re: [PATCH] cpufreq: CPPC: Avoid overflow when calculating desired_perf

Hi Rafael, On Wed, Sep 14, 2016 at 5:50 PM, Rafael J. Wysocki wrote: > On Wednesday, September 14, 2016 04:08:28 PM Hoan Tran wrote: >> This patch fixes overflow issue when calculating the desired_perf. >> >> Signed-off-by: Hoan Tran >> --- >> drivers/cpufreq/cppc_cpufreq.c | 3 ++- >> 1 file

perf: perf_fuzzer lockup in perf_cgroup_attach

so the skylake that was fuzzing finally is mostly locked up. Really hard to tell what's going, especially as KASLR made looking up the addresses a big pain. The best I can tell things are getting wedged somehow in perf_cgroup_switch() while interrupts are disabled. Interrupts are never

perf: perf_fuzzer lockup in perf_cgroup_attach

so the skylake that was fuzzing finally is mostly locked up. Really hard to tell what's going, especially as KASLR made looking up the addresses a big pain. The best I can tell things are getting wedged somehow in perf_cgroup_switch() while interrupts are disabled. Interrupts are never

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Wed, Sep 14, 2016 at 08:19:36PM +1000, Nicholas Piggin wrote: > On Wed, 14 Sep 2016 17:39:02 +1000 > Dave Chinner wrote: > > Ok, looking back over your example, you seem to be suggesting a new > > page fault behaviour is required from filesystems that has not been > >

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

On Wed, Sep 14, 2016 at 08:19:36PM +1000, Nicholas Piggin wrote: > On Wed, 14 Sep 2016 17:39:02 +1000 > Dave Chinner wrote: > > Ok, looking back over your example, you seem to be suggesting a new > > page fault behaviour is required from filesystems that has not been > > described or explained,

[PATCH -next] staging: fsl-mc: remove .owner field for driver

From: Wei Yongjun Remove .owner field if calls are used which set it automatically. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: Wei Yongjun --- drivers/staging/fsl-mc/bus/fsl-mc-allocator.c | 1 - 1 file

[PATCH -next] staging: fsl-mc: remove .owner field for driver

From: Wei Yongjun Remove .owner field if calls are used which set it automatically. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: Wei Yongjun --- drivers/staging/fsl-mc/bus/fsl-mc-allocator.c | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 7:19 PM, Alexei Starovoitov wrote: > On Wed, Sep 14, 2016 at 06:25:07PM -0700, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 3:11 PM, Mickaël Salaün wrote: >> > >> > On 14/09/2016 20:27, Andy Lutomirski wrote: >> >> On

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 7:19 PM, Alexei Starovoitov wrote: > On Wed, Sep 14, 2016 at 06:25:07PM -0700, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 3:11 PM, Mickaël Salaün wrote: >> > >> > On 14/09/2016 20:27, Andy Lutomirski wrote: >> >> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün

[PATCH -next] staging: fsl-mc: use list_del_init instead of list_del/INIT_LIST_HEAD

From: Wei Yongjun Using list_del_init() instead of list_del() + INIT_LIST_HEAD(). Signed-off-by: Wei Yongjun --- drivers/staging/fsl-mc/bus/fsl-mc-allocator.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

[PATCH -next] staging: fsl-mc: use list_del_init instead of list_del/INIT_LIST_HEAD

From: Wei Yongjun Using list_del_init() instead of list_del() + INIT_LIST_HEAD(). Signed-off-by: Wei Yongjun --- drivers/staging/fsl-mc/bus/fsl-mc-allocator.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c

Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware

Ian Kent writes: > On Wed, 2016-09-14 at 12:28 -0500, Eric W. Biederman wrote: >> Ian Kent writes: >> >> > If an automount mount is clone(2)ed into a file system that is >> > propagation private, when it later expires in the originating >> > namespace

Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Wed, Sep 14, 2016 at 6:17 PM, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey wrote: >> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen >> wrote: >>> On 09/14/2016 02:01 PM, Kyle Huey wrote: > >>> Is any of

[PATCH -next] staging: android: ion: Fix return value check in hi6220_ion_probe()

From: Wei Yongjun In case of error, the function ion_device_create() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun ---

Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware

Ian Kent writes: > On Wed, 2016-09-14 at 12:28 -0500, Eric W. Biederman wrote: >> Ian Kent writes: >> >> > If an automount mount is clone(2)ed into a file system that is >> > propagation private, when it later expires in the originating >> > namespace subsequent calls to autofs ->d_automount()

Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Wed, Sep 14, 2016 at 6:17 PM, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey wrote: >> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen >> wrote: >>> On 09/14/2016 02:01 PM, Kyle Huey wrote: > >>> Is any of this useful to optimize away at compile-time? We have config >>>

[PATCH -next] staging: android: ion: Fix return value check in hi6220_ion_probe()

From: Wei Yongjun In case of error, the function ion_device_create() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun --- drivers/staging/android/ion/hisilicon/hi6220_ion.c | 4 ++-- 1 file changed,

Re: [PATCH v2 3/3] x86,arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

On Wed, Sep 14, 2016 at 6:54 PM, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 6:47 PM, Kyle Huey wrote: >> On Wed, Sep 14, 2016 at 6:29 PM, Andy Lutomirski wrote: >>> On Wed, Sep 14, 2016 at 2:01 PM, Kyle Huey

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 06:25:07PM -0700, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 3:11 PM, Mickaël Salaün wrote: > > > > On 14/09/2016 20:27, Andy Lutomirski wrote: > >> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: > >>> Add a new flag

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On Wed, Sep 14, 2016 at 06:25:07PM -0700, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 3:11 PM, Mickaël Salaün wrote: > > > > On 14/09/2016 20:27, Andy Lutomirski wrote: > >> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: > >>> Add a new flag CGRP_NO_NEW_PRIVS for each cgroup. This

Re: [PATCH v2 3/3] x86,arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

On Wed, Sep 14, 2016 at 6:54 PM, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 6:47 PM, Kyle Huey wrote: >> On Wed, Sep 14, 2016 at 6:29 PM, Andy Lutomirski wrote: >>> On Wed, Sep 14, 2016 at 2:01 PM, Kyle Huey wrote: > + +int set_cpuid_mode(struct task_struct *task, unsigned long

[PATCH 1/4] x86/dumpstack: simplify in_exception_stack()

in_exception_stack() does some bad, bad things just so the unwinder can print different values for different areas of the debug exception stack. There's no need to clarify where exactly on the stack it is. Just print "#DB" and be done with it. Signed-off-by: Josh Poimboeuf

[PATCH 3/4] x86/dumpstack: support for unwinding empty irq stacks

When an interrupt happens in entry code while running on a software irq stack, and the irq stack was empty, regs->sp will contain the stack end address (e.g., irq_stack_ptr). If the regs are passed to dump_trace(), get_stack_info() will report STACK_TYPE_UNKNOWN, causing dump_trace() to return

[PATCH 2/4] x86/dumpstack: add get_stack_info() interface

valid_stack_ptr() is buggy: it assumes that all stacks are of size THREAD_SIZE, which is not true for exception stacks. So the walk_stack() callbacks will need to know the location of the beginning of the stack as well as the end. Another issue is that in general the various features of a stack

[PATCH 1/4] x86/dumpstack: simplify in_exception_stack()

in_exception_stack() does some bad, bad things just so the unwinder can print different values for different areas of the debug exception stack. There's no need to clarify where exactly on the stack it is. Just print "#DB" and be done with it. Signed-off-by: Josh Poimboeuf ---

[PATCH 3/4] x86/dumpstack: support for unwinding empty irq stacks

When an interrupt happens in entry code while running on a software irq stack, and the irq stack was empty, regs->sp will contain the stack end address (e.g., irq_stack_ptr). If the regs are passed to dump_trace(), get_stack_info() will report STACK_TYPE_UNKNOWN, causing dump_trace() to return

[PATCH 2/4] x86/dumpstack: add get_stack_info() interface

valid_stack_ptr() is buggy: it assumes that all stacks are of size THREAD_SIZE, which is not true for exception stacks. So the walk_stack() callbacks will need to know the location of the beginning of the stack as well as the end. Another issue is that in general the various features of a stack

[PATCH 0/4] x86/dumpstack: yet more stack dump improvements

This is the last batch before the new unwinder. Josh Poimboeuf (4): x86/dumpstack: simplify in_exception_stack() x86/dumpstack: add get_stack_info() interface x86/dumpstack: support for unwinding empty irq stacks x86/dumpstack: add recursion checking for all stacks

[PATCH 4/4] x86/dumpstack: add recursion checking for all stacks

in_exception_stack() has some recursion checking which makes sure the stack trace code never traverses a given exception stack more than once. This prevents an infinite loop if corruption somehow causes a stack's "next stack" pointer to point to itself (directly or indirectly). The recursion

[PATCH 0/4] x86/dumpstack: yet more stack dump improvements

This is the last batch before the new unwinder. Josh Poimboeuf (4): x86/dumpstack: simplify in_exception_stack() x86/dumpstack: add get_stack_info() interface x86/dumpstack: support for unwinding empty irq stacks x86/dumpstack: add recursion checking for all stacks

[PATCH 4/4] x86/dumpstack: add recursion checking for all stacks

in_exception_stack() has some recursion checking which makes sure the stack trace code never traverses a given exception stack more than once. This prevents an infinite loop if corruption somehow causes a stack's "next stack" pointer to point to itself (directly or indirectly). The recursion

Re: [PATCH v2 3/3] x86,arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

On Wed, Sep 14, 2016 at 6:47 PM, Kyle Huey wrote: > On Wed, Sep 14, 2016 at 6:29 PM, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 2:01 PM, Kyle Huey wrote: >>> + >>> +int set_cpuid_mode(struct task_struct *task, unsigned long val)

Re: [PATCH v2 3/3] x86,arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

On Wed, Sep 14, 2016 at 6:47 PM, Kyle Huey wrote: > On Wed, Sep 14, 2016 at 6:29 PM, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 2:01 PM, Kyle Huey wrote: >>> + >>> +int set_cpuid_mode(struct task_struct *task, unsigned long val) >>> +{ >>> + /* Only disable/enable_cpuid() if it is

Re: [PATCH v5 1/5] kexec_file: Include the purgatory segment in the kexec image checksum.

Hello Stephen, Am Donnerstag, 15 September 2016, 11:43:08 schrieb Stephen Rothwell: > Hi Thiago, > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 2a1f0ce7c59a..dcd1679f3005 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -1792,6 +1792,11 @@ config SECCOMP > >

Re: [PATCH v5 1/5] kexec_file: Include the purgatory segment in the kexec image checksum.

Hello Stephen, Am Donnerstag, 15 September 2016, 11:43:08 schrieb Stephen Rothwell: > Hi Thiago, > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 2a1f0ce7c59a..dcd1679f3005 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -1792,6 +1792,11 @@ config SECCOMP > >

Re: [PATCH v2 3/3] x86,arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

On Wed, Sep 14, 2016 at 6:29 PM, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 2:01 PM, Kyle Huey wrote: >> Intel supports faulting on the CPUID instruction in newer processors. Bit >> 31 of MSR_PLATFORM_INFO advertises support for this feature. It is

Re: [PATCH v2 3/3] x86,arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

On Wed, Sep 14, 2016 at 6:29 PM, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 2:01 PM, Kyle Huey wrote: >> Intel supports faulting on the CPUID instruction in newer processors. Bit >> 31 of MSR_PLATFORM_INFO advertises support for this feature. It is >> documented in detail in Section 2.3.2

Re: [PATCH v4 3/4] gpu: ipu-ic: Add complete image conversion support with tiling

Hi Philipp, On 09/06/2016 02:26 AM, Philipp Zabel wrote: Hi Steve, Am Mittwoch, den 17.08.2016, 17:50 -0700 schrieb Steve Longerbeam: This patch implements complete image conversion support to ipu-ic, with tiling to support scaling to and from images up to 4096x4096. Image rotation is also

Re: [PATCH v4 3/4] gpu: ipu-ic: Add complete image conversion support with tiling

Hi Philipp, On 09/06/2016 02:26 AM, Philipp Zabel wrote: Hi Steve, Am Mittwoch, den 17.08.2016, 17:50 -0700 schrieb Steve Longerbeam: This patch implements complete image conversion support to ipu-ic, with tiling to support scaling to and from images up to 4096x4096. Image rotation is also

  1   2   3   4   5   6   7   8   9   10   >