Re: [PATCH 1/2] init/main: Fix double "the" in comment

On 23-03-17, 17:00, Viresh Kumar wrote: > s/the\ the/the > > Signed-off-by: Viresh Kumar > --- > init/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/init/main.c b/init/main.c > index f9c9d9948203..717b2ab803e5 100644 > --- a/init/main.c

Re: [PATCH 1/2] init/main: Fix double "the" in comment

On 23-03-17, 17:00, Viresh Kumar wrote: > s/the\ the/the > > Signed-off-by: Viresh Kumar > --- > init/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/init/main.c b/init/main.c > index f9c9d9948203..717b2ab803e5 100644 > --- a/init/main.c > +++ b/init/main.c > @@

[PATCH] pci-sysfs: Make PCI bridge attribute visible in sysfs

From: vwong Export the PCIe link attributes of PCI bridges to sysfs. Signed-off-by: Wong Vee Khee Signed-off-by: Hui Chun Ong --- drivers/pci/pci-sysfs.c | 197 +-

Re: [PATCH] soc/tegra: pmc: Don't allocate struct tegra_powergate on stack

On 21-03-17, 16:09, Viresh Kumar wrote: > On 21-03-17, 10:37, Jon Hunter wrote: > > > > On 21/03/17 05:24, Viresh Kumar wrote: > > > The size of the struct tegra_powergate is quite big and if any more > > > fields are added to the internal genpd structure, following warnings are > > > thrown: > >

[PATCH] pci-sysfs: Make PCI bridge attribute visible in sysfs

From: vwong Export the PCIe link attributes of PCI bridges to sysfs. Signed-off-by: Wong Vee Khee Signed-off-by: Hui Chun Ong --- drivers/pci/pci-sysfs.c | 197 +- include/uapi/linux/pci_regs.h | 4 + 2 files changed, 197 insertions(+), 4

Re: [PATCH] soc/tegra: pmc: Don't allocate struct tegra_powergate on stack

On 21-03-17, 16:09, Viresh Kumar wrote: > On 21-03-17, 10:37, Jon Hunter wrote: > > > > On 21/03/17 05:24, Viresh Kumar wrote: > > > The size of the struct tegra_powergate is quite big and if any more > > > fields are added to the internal genpd structure, following warnings are > > > thrown: > >

Re: [PATCH] MAINTAINERS: drop akarwar from mwifiex

On Thu, Apr 13, 2017 at 6:47 PM, Kalle Valo wrote: > Brian Norris writes: > >> His email is bouncing, and I expect he's not doing this work any more. >> >> Cc: Amitkumar Karwar >> Cc: Nishant Sarmukadam

Re: [PATCH] MAINTAINERS: drop akarwar from mwifiex

On Thu, Apr 13, 2017 at 6:47 PM, Kalle Valo wrote: > Brian Norris writes: > >> His email is bouncing, and I expect he's not doing this work any more. >> >> Cc: Amitkumar Karwar >> Cc: Nishant Sarmukadam >> Cc: Ganapathi Bhat >> Cc: Xinming Hu >> Signed-off-by: Brian Norris >> --- >> Or

Re: your mail

On Sat, Apr 15, 2017 at 02:17:31PM +0200, Michal Hocko wrote: > Hi, > here I 3 more preparatory patches which I meant to send on Thursday but > forgot... After more thinking about pfn walkers I have realized that > the current code doesn't check offline holes in zones. From a quick > review that

Re: your mail

On Sat, Apr 15, 2017 at 02:17:31PM +0200, Michal Hocko wrote: > Hi, > here I 3 more preparatory patches which I meant to send on Thursday but > forgot... After more thinking about pfn walkers I have realized that > the current code doesn't check offline holes in zones. From a quick > review that

Re: [RFC/RFT][PATCH 1/2] cpufreq: schedutil: Use policy-dependent transition delays

On 11-04-17, 00:20, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Make the schedutil governor take the initial (default) value of the > rate_limit_us sysfs attribute from the (new) transition_delay_us > policy parameter (to be set by the scaling driver). > >

Re: [RFC/RFT][PATCH 1/2] cpufreq: schedutil: Use policy-dependent transition delays

On 11-04-17, 00:20, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Make the schedutil governor take the initial (default) value of the > rate_limit_us sysfs attribute from the (new) transition_delay_us > policy parameter (to be set by the scaling driver). > > That will allow scaling

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 13-04-17, 14:43, Sudeep Holla wrote: > Interesting. My understand of power domain and in particular power > domain performance was that it would control both. The abstract number > you introduce would hide clocks and regulators. > > But if the concept treats it just as yet another regulator,

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 13-04-17, 14:43, Sudeep Holla wrote: > Interesting. My understand of power domain and in particular power > domain performance was that it would control both. The abstract number > you introduce would hide clocks and regulators. > > But if the concept treats it just as yet another regulator,

Re: [PATCH V2] mm/madvise: Move up the behavior parameter validation

On Fri, Apr 14, 2017 at 07:21:41PM +0530, Anshuman Khandual wrote: > The madvise_behavior_valid() function should be called before > acting upon the behavior parameter. Hence move up the function. > This also includes MADV_SOFT_OFFLINE and MADV_HWPOISON options > as valid behavior parameter for

Re: [PATCH V2] mm/madvise: Move up the behavior parameter validation

On Fri, Apr 14, 2017 at 07:21:41PM +0530, Anshuman Khandual wrote: > The madvise_behavior_valid() function should be called before > acting upon the behavior parameter. Hence move up the function. > This also includes MADV_SOFT_OFFLINE and MADV_HWPOISON options > as valid behavior parameter for

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 13-04-17, 14:42, Sudeep Holla wrote: > What I was referring is about power domain provider with multiple power > domains(simply #power-domain-cells=<1> case as explained in the > power-domain specification. I am not sure if we should be looking to target such a situation for now, as that would

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 13-04-17, 14:42, Sudeep Holla wrote: > What I was referring is about power domain provider with multiple power > domains(simply #power-domain-cells=<1> case as explained in the > power-domain specification. I am not sure if we should be looking to target such a situation for now, as that would

RE: [EXT] Re: [PATCH] MAINTAINERS: drop akarwar from mwifiex

Hi Kalle/Brian, > Brian Norris writes: > > > His email is bouncing, and I expect he's not doing this work any > more. > > > > Cc: Amitkumar Karwar > > Cc: Nishant Sarmukadam > > Cc: Ganapathi Bhat > >

RE: [EXT] Re: [PATCH] MAINTAINERS: drop akarwar from mwifiex

Hi Kalle/Brian, > Brian Norris writes: > > > His email is bouncing, and I expect he's not doing this work any > more. > > > > Cc: Amitkumar Karwar > > Cc: Nishant Sarmukadam > > Cc: Ganapathi Bhat > > Cc: Xinming Hu > > Signed-off-by: Brian Norris > > --- > > Or alternatively, we can

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 16/04/17 04:32 PM, Benjamin Herrenschmidt wrote: >> I'll consider this. Given the fact I can use your existing >> get_dev_pagemap infrastructure to look up the p2pmem device this >> probably isn't as hard as I thought it would be anyway (we probably >> don't even need a page flag). We'd just

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 16/04/17 04:32 PM, Benjamin Herrenschmidt wrote: >> I'll consider this. Given the fact I can use your existing >> get_dev_pagemap infrastructure to look up the p2pmem device this >> probably isn't as hard as I thought it would be anyway (we probably >> don't even need a page flag). We'd just

Re: [PATCH v2 0/15] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

On 2017/04/14 10:50, Takiguchi, Yasunari wrote: > From: Yasunari Takiguchi > > Hi, > > This is the patch series (version 2) of Sony CXD2880 DVB-T2/T tuner + > demodulator driver. > The driver supports DVB-API and interfaces through SPI. > > We have tested the

Re: [PATCH v2 0/15] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

On 2017/04/14 10:50, Takiguchi, Yasunari wrote: > From: Yasunari Takiguchi > > Hi, > > This is the patch series (version 2) of Sony CXD2880 DVB-T2/T tuner + > demodulator driver. > The driver supports DVB-API and interfaces through SPI. > > We have tested the driver on Raspberry Pi 3 and got

Re: [PATCH v2 01/15] [dt-bindings] [media] Add document file for CXD2880 SPI I/F

> From: Yasunari Takiguchi > > This is the document file for Sony CXD2880 DVB-T2/T tuner + demodulator. > It contains the description of the SPI adapter binding. > > Signed-off-by: Yasunari Takiguchi > Signed-off-by: Masayuki Yamamoto

Re: [PATCH v2 01/15] [dt-bindings] [media] Add document file for CXD2880 SPI I/F

> From: Yasunari Takiguchi > > This is the document file for Sony CXD2880 DVB-T2/T tuner + demodulator. > It contains the description of the SPI adapter binding. > > Signed-off-by: Yasunari Takiguchi > Signed-off-by: Masayuki Yamamoto > Signed-off-by: Hideki Nozawa > Signed-off-by: Kota

Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS

On Thu, Apr 13, 2017 at 12:39 PM, Balbir Singh wrote: >>> >>> Yes. It was derived from TASK_SIZE : >>> >>> http://lxr.free-electrons.com/source/arch/powerpc/include/asm/processor.h#L105 >>> >> >> That is getting update to 128TB by default and conditionally to 512TB >> > >

Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS

On Thu, Apr 13, 2017 at 12:39 PM, Balbir Singh wrote: >>> >>> Yes. It was derived from TASK_SIZE : >>> >>> http://lxr.free-electrons.com/source/arch/powerpc/include/asm/processor.h#L105 >>> >> >> That is getting update to 128TB by default and conditionally to 512TB >> > > Since this is compile

Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup

Hi Johannes, On Thu, Apr 13, 2017 at 12:01:47PM -0400, Johannes Weiner wrote: > On Thu, Apr 13, 2017 at 01:30:47PM +0900, Minchan Kim wrote: > > On Thu, Mar 30, 2017 at 12:40:32PM -0700, Tim Murray wrote: > > > As a result, I think there's still a need for relative priority > > > between mem

Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup

Hi Johannes, On Thu, Apr 13, 2017 at 12:01:47PM -0400, Johannes Weiner wrote: > On Thu, Apr 13, 2017 at 01:30:47PM +0900, Minchan Kim wrote: > > On Thu, Mar 30, 2017 at 12:40:32PM -0700, Tim Murray wrote: > > > As a result, I think there's still a need for relative priority > > > between mem

Re: [patch 06/20] cpufreq: Use cpuhp_setup_state_nocalls_locked()

On 15-04-17, 19:01, Thomas Gleixner wrote: > From: Sebastian Andrzej Siewior > > cpufreq holds get_online_cpus() while invoking cpuhp_setup_state_nocalls() > to make subsys_interface_register() and the registration of hotplug calls > atomic versus cpu hotplug. > >

Re: [patch 06/20] cpufreq: Use cpuhp_setup_state_nocalls_locked()

On 15-04-17, 19:01, Thomas Gleixner wrote: > From: Sebastian Andrzej Siewior > > cpufreq holds get_online_cpus() while invoking cpuhp_setup_state_nocalls() > to make subsys_interface_register() and the registration of hotplug calls > atomic versus cpu hotplug. > > cpuhp_setup_state_nocalls()

Re: [PATCH v3 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

On Thursday 13 April 2017 06:08 PM, Peter Zijlstra wrote: On Tue, Apr 11, 2017 at 07:21:05AM +0530, Madhavan Srinivasan wrote: From: Sukadev Bhattiprolu perf_mem_data_src is an union that is initialized via the ->val field and accessed via the bitmap fields. For

Re: [PATCH v3 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

On Thursday 13 April 2017 06:08 PM, Peter Zijlstra wrote: On Tue, Apr 11, 2017 at 07:21:05AM +0530, Madhavan Srinivasan wrote: From: Sukadev Bhattiprolu perf_mem_data_src is an union that is initialized via the ->val field and accessed via the bitmap fields. For this to work on big endian

Re: [PATCH v3 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

On Thursday 13 April 2017 06:53 PM, Michael Ellerman wrote: Peter Zijlstra writes: On Tue, Apr 11, 2017 at 07:21:05AM +0530, Madhavan Srinivasan wrote: From: Sukadev Bhattiprolu perf_mem_data_src is an union that is initialized via the

Re: [PATCH v3 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

On Thursday 13 April 2017 06:53 PM, Michael Ellerman wrote: Peter Zijlstra writes: On Tue, Apr 11, 2017 at 07:21:05AM +0530, Madhavan Srinivasan wrote: From: Sukadev Bhattiprolu perf_mem_data_src is an union that is initialized via the ->val field and accessed via the bitmap fields. For

Re: [PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash

Hi Cyrille, On Sun, 2017-04-16 at 19:18 +0200, Cyrille Pitchen wrote: > Le 13/04/2017 à 10:24, Cyrille Pitchen a écrit : > > Hi Guochun, > > > > Le 13/04/2017 à 04:40, Guochun Mao a écrit : > >> Hi Cyrille, > >> > >> On Wed, 2017-04-12 at 22:57 +0200, Cyrille Pitchen wrote: > >>> Hi Guochun, >

Re: [PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash

Hi Cyrille, On Sun, 2017-04-16 at 19:18 +0200, Cyrille Pitchen wrote: > Le 13/04/2017 à 10:24, Cyrille Pitchen a écrit : > > Hi Guochun, > > > > Le 13/04/2017 à 04:40, Guochun Mao a écrit : > >> Hi Cyrille, > >> > >> On Wed, 2017-04-12 at 22:57 +0200, Cyrille Pitchen wrote: > >>> Hi Guochun, >

Re: [virtio-dev] Re: [PATCH v9 2/5] virtio-balloon: VIRTIO_BALLOON_F_BALLOON_CHUNKS

On 04/15/2017 05:38 AM, Michael S. Tsirkin wrote: On Fri, Apr 14, 2017 at 04:37:52PM +0800, Wei Wang wrote: On 04/14/2017 12:34 AM, Michael S. Tsirkin wrote: On Thu, Apr 13, 2017 at 05:35:05PM +0800, Wei Wang wrote: So we don't need the bitmap to talk to host, it is just a data structure we

Re: [virtio-dev] Re: [PATCH v9 2/5] virtio-balloon: VIRTIO_BALLOON_F_BALLOON_CHUNKS

On 04/15/2017 05:38 AM, Michael S. Tsirkin wrote: On Fri, Apr 14, 2017 at 04:37:52PM +0800, Wei Wang wrote: On 04/14/2017 12:34 AM, Michael S. Tsirkin wrote: On Thu, Apr 13, 2017 at 05:35:05PM +0800, Wei Wang wrote: So we don't need the bitmap to talk to host, it is just a data structure we

Re: [PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

Hi Arnd, Could you please take this patch through arm-soc git if there are no further comments? (The three other patches in this series have been taken by Greg.) Thanks, Chunyan On 27 March 2017 at 15:32, Chunyan Zhang wrote: > From: Orson Zhai

Re: [PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

Hi Arnd, Could you please take this patch through arm-soc git if there are no further comments? (The three other patches in this series have been taken by Greg.) Thanks, Chunyan On 27 March 2017 at 15:32, Chunyan Zhang wrote: > From: Orson Zhai > > SC9860G is a 8 cores of A53 SoC with 4G LTE

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

Hi Tyler, On 2017/4/17 11:08, Xie XiuQi wrote: > Hi Tyler, > > Thanks for your comments and testing. > > On 2017/4/15 4:36, Baicar, Tyler wrote: >> On 3/30/2017 4:31 AM, Xie XiuQi wrote: >>> Add a new trace event for ARM processor error information, so that >>> the user will know what error

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

Hi Tyler, On 2017/4/17 11:08, Xie XiuQi wrote: > Hi Tyler, > > Thanks for your comments and testing. > > On 2017/4/15 4:36, Baicar, Tyler wrote: >> On 3/30/2017 4:31 AM, Xie XiuQi wrote: >>> Add a new trace event for ARM processor error information, so that >>> the user will know what error

[PATCH] usb: gadget: remove redundant self assignment

The assignment ret = ret is redundant and can be removed. Signed-off-by: Stefan Agner --- A very similar patch has been applied already last year, but there is a second such assignment... -- Stefan drivers/usb/gadget/udc/core.c | 4 +--- 1 file changed, 1 insertion(+), 3

[PATCH] usb: gadget: remove redundant self assignment

The assignment ret = ret is redundant and can be removed. Signed-off-by: Stefan Agner --- A very similar patch has been applied already last year, but there is a second such assignment... -- Stefan drivers/usb/gadget/udc/core.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

Hi Tyler, Thanks for your comments and testing. On 2017/4/15 4:36, Baicar, Tyler wrote: > On 3/30/2017 4:31 AM, Xie XiuQi wrote: >> Add a new trace event for ARM processor error information, so that >> the user will know what error occurred. With this information the >> user may take appropriate

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

Hi Tyler, Thanks for your comments and testing. On 2017/4/15 4:36, Baicar, Tyler wrote: > On 3/30/2017 4:31 AM, Xie XiuQi wrote: >> Add a new trace event for ARM processor error information, so that >> the user will know what error occurred. With this information the >> user may take appropriate

Re: [PATCH] acpica: trivial changes on comments

Re-to: linux-a...@vger.kernel.org On 04/17/2017 10:56 AM, Cao jin wrote: > Remove superfluous word; unify comments and function prototype. > > Signed-off-by: Cao jin > --- > drivers/acpi/acpica/tbfadt.c | 2 +- > drivers/acpi/acpica/tbutils.c | 4 ++-- > 2 files

Re: [PATCH] acpica: trivial changes on comments

Re-to: linux-a...@vger.kernel.org On 04/17/2017 10:56 AM, Cao jin wrote: > Remove superfluous word; unify comments and function prototype. > > Signed-off-by: Cao jin > --- > drivers/acpi/acpica/tbfadt.c | 2 +- > drivers/acpi/acpica/tbutils.c | 4 ++-- > 2 files changed, 3 insertions(+), 3

[PATCH] acpica: trivial changes on comments

Remove superfluous word; unify comments and function prototype. Signed-off-by: Cao jin --- drivers/acpi/acpica/tbfadt.c | 2 +- drivers/acpi/acpica/tbutils.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/acpica/tbfadt.c

[PATCH] acpica: trivial changes on comments

Remove superfluous word; unify comments and function prototype. Signed-off-by: Cao jin --- drivers/acpi/acpica/tbfadt.c | 2 +- drivers/acpi/acpica/tbutils.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c

[lkp-robot] [cpu/hotplug] 94380da276: INFO:possible_recursive_locking_detected

FYI, we noticed the following commit: commit: 94380da2765a391335c2326ba327e835c2e7aa03 ("cpu/hotplug: Convert hotplug locking to percpu rwsem") https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git WIP.hotplug in testcase: trinity with following parameters: runtime: 300s

[lkp-robot] [cpu/hotplug] 94380da276: INFO:possible_recursive_locking_detected

FYI, we noticed the following commit: commit: 94380da2765a391335c2326ba327e835c2e7aa03 ("cpu/hotplug: Convert hotplug locking to percpu rwsem") https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git WIP.hotplug in testcase: trinity with following parameters: runtime: 300s

[PATCH 2/4] ftrace: Add 'function-fork' trace option

The function-fork option is same as event-fork that it tracks task fork/exit and set the pid filter properly. This can be useful if user wants to trace selected tasks including their children only. Signed-off-by: Namhyung Kim --- kernel/trace/ftrace.c | 37

[PATCH 2/4] ftrace: Add 'function-fork' trace option

The function-fork option is same as event-fork that it tracks task fork/exit and set the pid filter properly. This can be useful if user wants to trace selected tasks including their children only. Signed-off-by: Namhyung Kim --- kernel/trace/ftrace.c | 37 +

[PATCH 0/4] ftrace: Add 'function-fork' trace option (v2)

Hello, This patchset add 'function-fork' option to function tracer which makes pid filter to be inherited like 'event-fork' does. During the test, I found a bug of pid filter on an instance directory. The patch 1 fixes it and maybe it should go to the stable tree. The function-fork option is

[PATCH 4/4] selftests: ftrace: Add a testcase for function PID filter

Like event pid filtering test, add function pid filtering test with the new "function-fork" option. It also tests it on an instance directory so that it can verify the bug related pid filtering on instances. Cc: Masami Hiramatsu Cc: Steven Rostedt Cc:

[PATCH 0/4] ftrace: Add 'function-fork' trace option (v2)

Hello, This patchset add 'function-fork' option to function tracer which makes pid filter to be inherited like 'event-fork' does. During the test, I found a bug of pid filter on an instance directory. The patch 1 fixes it and maybe it should go to the stable tree. The function-fork option is

[PATCH 4/4] selftests: ftrace: Add a testcase for function PID filter

Like event pid filtering test, add function pid filtering test with the new "function-fork" option. It also tests it on an instance directory so that it can verify the bug related pid filtering on instances. Cc: Masami Hiramatsu Cc: Steven Rostedt Cc: Shuah Khan Signed-off-by: Namhyung Kim

[PATCH 1/4] ftrace: Fix function pid filter on instances

When function tracer has a pid filter, it adds a probe to sched_switch to track if current task can be ignored. The probe checks the ftrace_ignore_pid from current tr to filter tasks. But it misses to delete the probe when removing an instance so that it can cause a crash due to the invalid tr

[PATCH 1/4] ftrace: Fix function pid filter on instances

When function tracer has a pid filter, it adds a probe to sched_switch to track if current task can be ignored. The probe checks the ftrace_ignore_pid from current tr to filter tasks. But it misses to delete the probe when removing an instance so that it can cause a crash due to the invalid tr

[PATCH 3/4] selftests: ftrace: Add -l/--logdir option

In my virtual machine setup, running ftracetest failed on creating LOG_DIR on a read-only filesystem. It'd be convenient to provide an option to specify a different directory as log directory. Acked-by: Masami Hiramatsu Cc: Steven Rostedt Cc: Shuah

[PATCH 3/4] selftests: ftrace: Add -l/--logdir option

In my virtual machine setup, running ftracetest failed on creating LOG_DIR on a read-only filesystem. It'd be convenient to provide an option to specify a different directory as log directory. Acked-by: Masami Hiramatsu Cc: Steven Rostedt Cc: Shuah Khan Signed-off-by: Namhyung Kim ---

Re: [PATCH v2 2/4] zram: implement deduplication in zram

On Mon, Apr 17, 2017 at 10:38:16AM +0900, Minchan Kim wrote: > Hi Joonsoo, > > I reviewed this patch and overall, looks great! Thanks. Thanks! > However, as you know, recently, zram had lots of clean up so > this patchset should be rebased on it massively. > Sorry for the inconvenience. No

Re: [PATCH v2 2/4] zram: implement deduplication in zram

On Mon, Apr 17, 2017 at 10:38:16AM +0900, Minchan Kim wrote: > Hi Joonsoo, > > I reviewed this patch and overall, looks great! Thanks. Thanks! > However, as you know, recently, zram had lots of clean up so > this patchset should be rebased on it massively. > Sorry for the inconvenience. No

Re: [PATCH 1/3] zram: fix operator precedence to get offset

Hi Sergey, On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote: > On (04/17/17 10:21), Sergey Senozhatsky wrote: > > > However, it should be *fixed* to prevent confusion in future > > or may be something like below? can save us some cycles. > > remove this calculation > > -

Re: [PATCH 1/3] zram: fix operator precedence to get offset

Hi Sergey, On Mon, Apr 17, 2017 at 10:54:29AM +0900, Sergey Senozhatsky wrote: > On (04/17/17 10:21), Sergey Senozhatsky wrote: > > > However, it should be *fixed* to prevent confusion in future > > or may be something like below? can save us some cycles. > > remove this calculation > > -

Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries

2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki : > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote: >> Compiling the DT file with W=1, DTC warns like follows: >> >> Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a >> unit name, but no reg property >>

Re: [PATCH V2] PM / OPP: Use - instead of @ for DT entries

2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki : > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote: >> Compiling the DT file with W=1, DTC warns like follows: >> >> Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a >> unit name, but no reg property >> >> Fix this by

Re: [PATCH] slab: avoid IPIs when creating kmem caches

On Sun, Apr 16, 2017 at 02:45:44PM -0700, Greg Thelen wrote: > Each slab kmem cache has per cpu array caches. The array caches are > created when the kmem_cache is created, either via kmem_cache_create() > or lazily when the first object is allocated in context of a kmem > enabled memcg. Array

Re: [PATCH] slab: avoid IPIs when creating kmem caches

On Sun, Apr 16, 2017 at 02:45:44PM -0700, Greg Thelen wrote: > Each slab kmem cache has per cpu array caches. The array caches are > created when the kmem_cache is created, either via kmem_cache_create() > or lazily when the first object is allocated in context of a kmem > enabled memcg. Array

Re: [PATCH v7 0/7] Introduce ZONE_CMA

On Thu, Apr 13, 2017 at 01:56:15PM +0200, Michal Hocko wrote: > On Wed 12-04-17 10:35:06, Joonsoo Kim wrote: > > On Tue, Apr 11, 2017 at 08:15:20PM +0200, Michal Hocko wrote: > > > Hi, > > > I didn't get to read though patches yet but the cover letter didn't > > > really help me to understand the

Re: [PATCH v7 0/7] Introduce ZONE_CMA

On Thu, Apr 13, 2017 at 01:56:15PM +0200, Michal Hocko wrote: > On Wed 12-04-17 10:35:06, Joonsoo Kim wrote: > > On Tue, Apr 11, 2017 at 08:15:20PM +0200, Michal Hocko wrote: > > > Hi, > > > I didn't get to read though patches yet but the cover letter didn't > > > really help me to understand the

Re: [kbuild-all] [tip:x86/cpu 8/12] arch/x86/kernel/cpu/intel_rdt.c:63: error: unknown field 'cache' specified in initializer

On Sat, Apr 15, 2017 at 07:40:34AM +0200, Thomas Gleixner wrote: On Sat, 15 Apr 2017, kbuild test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cpu head: 64e8ed3d4a6dcd6139a869a3e760e625cb0d3022 commit: 05b93417ce5b924c6652de19fdcc27439ab37c90 [8/12]

Re: [kbuild-all] [tip:x86/cpu 8/12] arch/x86/kernel/cpu/intel_rdt.c:63: error: unknown field 'cache' specified in initializer

On Sat, Apr 15, 2017 at 07:40:34AM +0200, Thomas Gleixner wrote: On Sat, 15 Apr 2017, kbuild test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cpu head: 64e8ed3d4a6dcd6139a869a3e760e625cb0d3022 commit: 05b93417ce5b924c6652de19fdcc27439ab37c90 [8/12]

Re: [PATCH 1/3] zram: fix operator precedence to get offset

On (04/17/17 10:21), Sergey Senozhatsky wrote: > > However, it should be *fixed* to prevent confusion in future or may be something like below? can save us some cycles. remove this calculation - offset = sector & (SECTORS_PER_PAGE - 1) << SECTOR_SHIFT; and pass 0 to zram_bvec_rw() -

Re: [PATCH 1/3] zram: fix operator precedence to get offset

On (04/17/17 10:21), Sergey Senozhatsky wrote: > > However, it should be *fixed* to prevent confusion in future or may be something like below? can save us some cycles. remove this calculation - offset = sector & (SECTORS_PER_PAGE - 1) << SECTOR_SHIFT; and pass 0 to zram_bvec_rw() -

Re: [PATCH 00/10] mac68k: Miscellaneous fixes, cleanup and modernization

On Sun, 16 Apr 2017, Geert Uytterhoeven wrote: > Hi Finn, > > On Sun, Apr 9, 2017 at 1:51 AM, Finn Thain > wrote: > > This series has various patches from several different people. Two > > printk modernization patches were originally from Geert Uytterhoeven > >

Re: [PATCH 00/10] mac68k: Miscellaneous fixes, cleanup and modernization

On Sun, 16 Apr 2017, Geert Uytterhoeven wrote: > Hi Finn, > > On Sun, Apr 9, 2017 at 1:51 AM, Finn Thain > wrote: > > This series has various patches from several different people. Two > > printk modernization patches were originally from Geert Uytterhoeven > > and three Nubus patches were

Re: [PATCH 2/3] zram: do not use copy_page with non-page alinged address

On (04/13/17 09:17), Minchan Kim wrote: > The copy_page is optimized memcpy for page-alinged address. > If it is used with non-page aligned address, it can corrupt memory which > means system corruption. With zram, it can happen with > > 1. 64K architecture > 2. partial IO > 3. slub debug > >

Re: [PATCH 2/3] zram: do not use copy_page with non-page alinged address

On (04/13/17 09:17), Minchan Kim wrote: > The copy_page is optimized memcpy for page-alinged address. > If it is used with non-page aligned address, it can corrupt memory which > means system corruption. With zram, it can happen with > > 1. 64K architecture > 2. partial IO > 3. slub debug > >

copy_page() on a kmalloc-ed page with DEBUG_SLAB enabled (was "zram: do not use copy_page with non-page alinged address")

Hello, I'll fork it into a separate thread and Cc more MM people. sorry for top-posting. Minchan reported that doing copy_page() on a kmalloc(PAGE_SIZE) page with DEBUG_SLAB enabled can cause a memory corruption (See below or lkml.kernel.org/r/1492042622-12074-2-git-send-email-minc...@kernel.org

copy_page() on a kmalloc-ed page with DEBUG_SLAB enabled (was "zram: do not use copy_page with non-page alinged address")

Hello, I'll fork it into a separate thread and Cc more MM people. sorry for top-posting. Minchan reported that doing copy_page() on a kmalloc(PAGE_SIZE) page with DEBUG_SLAB enabled can cause a memory corruption (See below or lkml.kernel.org/r/1492042622-12074-2-git-send-email-minc...@kernel.org

[PATCH v4 2/2] vfio/type1: Prune vfio_pin_page_external()

With vfio_lock_acct() testing the locked memory limit under mmap_sem, it's redundant to do it here for a single page. We can also reorder our tests such that we can avoid testing for reserved pages if we're not doing accounting, and test the process CAP_IPC_LOCK only if we are doing accounting.

[PATCH v4 2/2] vfio/type1: Prune vfio_pin_page_external()

With vfio_lock_acct() testing the locked memory limit under mmap_sem, it's redundant to do it here for a single page. We can also reorder our tests such that we can avoid testing for reserved pages if we're not doing accounting, and test the process CAP_IPC_LOCK only if we are doing accounting.

[PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

If the mmap_sem is contented then the vfio type1 IOMMU backend will defer locked page accounting updates to a workqueue task. This has a few problems and depending on which side the user tries to play, they might be over-penalized for unmaps that haven't yet been accounted or race the workqueue

[PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

If the mmap_sem is contented then the vfio type1 IOMMU backend will defer locked page accounting updates to a workqueue task. This has a few problems and depending on which side the user tries to play, they might be over-penalized for unmaps that haven't yet been accounted or race the workqueue

[PATCH v4 0/2] vfio/type1: Synchronous locked page accounting

v4: vfio_lock_acct() should not fail due to RLIMIT_MEMLOCK if task has CAP_IPC_LOCK capability. Introduced 2nd patch to remove redundancy from vfio_pin_page_external() and fix return value. Please re-review. Thanks! Alex --- Alex Williamson (2): vfio/type1: Remove locked page

[PATCH v4 0/2] vfio/type1: Synchronous locked page accounting

v4: vfio_lock_acct() should not fail due to RLIMIT_MEMLOCK if task has CAP_IPC_LOCK capability. Introduced 2nd patch to remove redundancy from vfio_pin_page_external() and fix return value. Please re-review. Thanks! Alex --- Alex Williamson (2): vfio/type1: Remove locked page

Re: [PATCH v2 2/4] zram: implement deduplication in zram

Hi Joonsoo, I reviewed this patch and overall, looks great! Thanks. However, as you know, recently, zram had lots of clean up so this patchset should be rebased on it massively. Sorry for the inconvenience. And there are some minor in below. I hope you handle them in next submit, please. On

Re: [PATCH v2 2/4] zram: implement deduplication in zram

Hi Joonsoo, I reviewed this patch and overall, looks great! Thanks. However, as you know, recently, zram had lots of clean up so this patchset should be rebased on it massively. Sorry for the inconvenience. And there are some minor in below. I hope you handle them in next submit, please. On

RE: [PATCH 1/2 v2] dt-bindings: qoriq-clock: Add coreclk

Hi Stephen and Michael, This patch set has been pending for more than two months since it was first sent. I have not received any response from you until now. Could you give some comments on it? Regards, Andy -Original Message- From: Andy Tang Sent: Wednesday, April 05, 2017 2:16 PM

RE: [PATCH 1/2 v2] dt-bindings: qoriq-clock: Add coreclk

Hi Stephen and Michael, This patch set has been pending for more than two months since it was first sent. I have not received any response from you until now. Could you give some comments on it? Regards, Andy -Original Message- From: Andy Tang Sent: Wednesday, April 05, 2017 2:16 PM

[PATCH 2/2] staging:skein: skein_base.h, skein_block.h: move macros into appropriate header files

Macros more related to BLK operations. Signed-off-by: Karim Eshapa --- drivers/staging/skein/skein_base.h | 28 drivers/staging/skein/skein_block.h | 28 2 files changed, 28 insertions(+), 28 deletions(-) diff

[PATCH 2/2] staging:skein: skein_base.h, skein_block.h: move macros into appropriate header files

Macros more related to BLK operations. Signed-off-by: Karim Eshapa --- drivers/staging/skein/skein_base.h | 28 drivers/staging/skein/skein_block.h | 28 2 files changed, 28 insertions(+), 28 deletions(-) diff --git

Re: [PATCH 1/3] zram: fix operator precedence to get offset

Hello, On (04/15/17 00:33), Minchan Kim wrote: > On Fri, Apr 14, 2017 at 02:07:47PM +0900, Sergey Senozhatsky wrote: > > On (04/13/17 09:17), Minchan Kim wrote: > > [..] > > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > > > index 9e2199060040..83c38a123242 100644

Re: [PATCH 1/3] zram: fix operator precedence to get offset

Hello, On (04/15/17 00:33), Minchan Kim wrote: > On Fri, Apr 14, 2017 at 02:07:47PM +0900, Sergey Senozhatsky wrote: > > On (04/13/17 09:17), Minchan Kim wrote: > > [..] > > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > > > index 9e2199060040..83c38a123242 100644

Re: [PATCH 1/3] zram: fix operator precedence to get offset

On (04/13/17 09:17), Minchan Kim wrote: > Date: Thu, 13 Apr 2017 09:17:00 +0900 > From: Minchan Kim > To: Andrew Morton > CC: linux-kernel@vger.kernel.org, Sergey Senozhatsky > , kernel-t...@lge.com, Minchan Kim >

Re: [PATCH 1/3] zram: fix operator precedence to get offset

On (04/13/17 09:17), Minchan Kim wrote: > Date: Thu, 13 Apr 2017 09:17:00 +0900 > From: Minchan Kim > To: Andrew Morton > CC: linux-kernel@vger.kernel.org, Sergey Senozhatsky > , kernel-t...@lge.com, Minchan Kim > , sta...@vger.kernel.org > Subject: [PATCH 1/3] zram: fix operator precedence to

  1   2   3   4   5   6   7   8   >