[PATCH 1/2] trace-cmd: Introduce tracecmd_peek_next_data()

The tracecmd_peek_next_data() is similar to tracecmd_read_next_data() but it doesn't consume the record. Signed-off-by: Namhyung Kim --- trace-cmd.h | 3 +++ trace-input.c | 43 +++ 2 files changed, 46 insertions(+) diff --git

[PATCH 1/2] trace-cmd: Introduce tracecmd_peek_next_data()

The tracecmd_peek_next_data() is similar to tracecmd_read_next_data() but it doesn't consume the record. Signed-off-by: Namhyung Kim --- trace-cmd.h | 3 +++ trace-input.c | 43 +++ 2 files changed, 46 insertions(+) diff --git a/trace-cmd.h

[PATCH 2/2] trace-cmd: Use tracecmd_peek_next_data() in fgraph_ent_handler

When a task was migrated to other cpu in the middle of a function, the fgraph_exit record will be in a different cpu than the enter record. But currently fgraph_ent_handler() only peeks at the same cpu so it could read an incorrect record. For example, please see following raw records:

[PATCH 2/2] trace-cmd: Use tracecmd_peek_next_data() in fgraph_ent_handler

When a task was migrated to other cpu in the middle of a function, the fgraph_exit record will be in a different cpu than the enter record. But currently fgraph_ent_handler() only peeks at the same cpu so it could read an incorrect record. For example, please see following raw records:

Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

On 07.07.2016 16:43, Christian König wrote: > Am 07.07.2016 um 05:32 schrieb Michel Dänzer: >> On 06.07.2016 22:45, Tejun Heo wrote: >>> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote: >>> Not being very familiar with the workqueue APIs, I'll describe how it's supposed to

Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

On 07.07.2016 16:43, Christian König wrote: > Am 07.07.2016 um 05:32 schrieb Michel Dänzer: >> On 06.07.2016 22:45, Tejun Heo wrote: >>> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote: >>> Not being very familiar with the workqueue APIs, I'll describe how it's supposed to

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote: > On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) wrote: > > On 7 July 2016 at 17:01, James Bottomley > > wrote: > [Serge already answered the parenting issue] > > > On Thu,

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote: > On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) wrote: > > On 7 July 2016 at 17:01, James Bottomley > > wrote: > [Serge already answered the parenting issue] > > > On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn

Re: [PATCH v12 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

On Fri, Jul 01, 2016 at 05:07:05PM +0530, Kedareswara rao Appana wrote: > Device-tree binding documentation for Xilinx zynqmp dma engine > used in Zynq UltraScale+ MPSoC. And I missed the cleanup part, so both applied now -- ~Vinod

Re: [PATCH v12 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

On Fri, Jul 01, 2016 at 05:07:05PM +0530, Kedareswara rao Appana wrote: > Device-tree binding documentation for Xilinx zynqmp dma engine > used in Zynq UltraScale+ MPSoC. And I missed the cleanup part, so both applied now -- ~Vinod

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, Jul 7, 2016 at 10:41 PM, Andrei Vagin wrote: > On Thu, Jul 7, 2016 at 8:26 PM, James Bottomley > wrote: >> On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote: >>> On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote: >>>

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, Jul 7, 2016 at 10:41 PM, Andrei Vagin wrote: > On Thu, Jul 7, 2016 at 8:26 PM, James Bottomley > wrote: >> On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote: >>> On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote: >>> > On Thu, Jul 07, 2016 at 12:17:35PM -0700, James

Re: [PATCH v12 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

On Fri, Jul 01, 2016 at 05:07:06PM +0530, Kedareswara rao Appana wrote: > +static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev, > +struct platform_device *pdev) > +{ > + struct zynqmp_dma_chan *chan; > + struct resource *res; > + struct device_node

Re: [PATCH v12 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

On Fri, Jul 01, 2016 at 05:07:06PM +0530, Kedareswara rao Appana wrote: > +static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev, > +struct platform_device *pdev) > +{ > + struct zynqmp_dma_chan *chan; > + struct resource *res; > + struct device_node

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, Jul 7, 2016 at 8:26 PM, James Bottomley wrote: > On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote: >> On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote: >> > On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote: >> > > On

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, Jul 7, 2016 at 8:26 PM, James Bottomley wrote: > On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote: >> On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote: >> > On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote: >> > > On Thu, 2016-07-07 at 20:21 +0200, Michael

Re: [v4] powerpc: Export thread_struct.used_vr/used_vsr to user space

On Thu, Jul 07, 2016 at 11:21:18PM +1000, Benjamin Herrenschmidt wrote: > I think the right fix is that if a restore_sigcontext() has the MSR bits set, > it should set the corresponding used_* flag. > > Or is there a reason why that won't work ? That sounds reaonable to me. I will prepare a

Re: [v4] powerpc: Export thread_struct.used_vr/used_vsr to user space

On Thu, Jul 07, 2016 at 11:21:18PM +1000, Benjamin Herrenschmidt wrote: > I think the right fix is that if a restore_sigcontext() has the MSR bits set, > it should set the corresponding used_* flag. > > Or is there a reason why that won't work ? That sounds reaonable to me. I will prepare a

Re: Introspecting userns relationships to other namespaces?

On Thu, Jul 07, 2016 at 08:26:47PM -0700, James Bottomley wrote: > On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote: > > On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote: > > > I think we can show all required information in fdinfo. We open > > > a namespaces file (/proc/pid/ns/N)

Re: Introspecting userns relationships to other namespaces?

On Thu, Jul 07, 2016 at 08:26:47PM -0700, James Bottomley wrote: > On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote: > > On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote: > > > I think we can show all required information in fdinfo. We open > > > a namespaces file (/proc/pid/ns/N)

Re: [PATCH 0/4] regulator: tps65917/palmas: Cleanups and bugfixes

On Friday 20 May 2016 11:46 AM, Laxman Dewangan wrote: On Friday 20 May 2016 10:01 AM, Keerthy wrote: + Lee Jones On Saturday 07 May 2016 12:31 AM, Nishanth Menon wrote: On 05/06/2016 12:14 PM, Mark Brown wrote: On Fri, May 06, 2016 at 12:44:23PM +0530, Laxman Dewangan wrote: When you

Re: [PATCH 0/4] regulator: tps65917/palmas: Cleanups and bugfixes

On Friday 20 May 2016 11:46 AM, Laxman Dewangan wrote: On Friday 20 May 2016 10:01 AM, Keerthy wrote: + Lee Jones On Saturday 07 May 2016 12:31 AM, Nishanth Menon wrote: On 05/06/2016 12:14 PM, Mark Brown wrote: On Fri, May 06, 2016 at 12:44:23PM +0530, Laxman Dewangan wrote: When you

Re: [PATCH 0/2] Fix issue with alternatives/paravirt patches

On Tue, Jul 05, 2016 at 10:34:58PM -0400, Jessica Yu wrote: > Hi, > > A few months ago, Chris Arges reported a bug involving alternatives/paravirt > patching that was discussed here [1] and here [2]. To briefly summarize the > bug, patch modules that contained .altinstructions or

Re: [PATCH 0/2] Fix issue with alternatives/paravirt patches

On Tue, Jul 05, 2016 at 10:34:58PM -0400, Jessica Yu wrote: > Hi, > > A few months ago, Chris Arges reported a bug involving alternatives/paravirt > patching that was discussed here [1] and here [2]. To briefly summarize the > bug, patch modules that contained .altinstructions or

Re: [PATCH v2 0/5] dmaengine: vdma: AXI DMAS Enhancments

On Fri, Jun 24, 2016 at 10:51:21AM +0530, Kedareswara rao Appana wrote: > This patch series does the following thing. > ---> Add support for AXI DMA Multi-channel DMA mode. > ---> Delete AXI DMA binding doc. > ---> Rename the driver and update config options. Applied after changing the patch tags

Re: [PATCH v2 0/5] dmaengine: vdma: AXI DMAS Enhancments

On Fri, Jun 24, 2016 at 10:51:21AM +0530, Kedareswara rao Appana wrote: > This patch series does the following thing. > ---> Add support for AXI DMA Multi-channel DMA mode. > ---> Delete AXI DMA binding doc. > ---> Rename the driver and update config options. Applied after changing the patch tags

[git pull] drm fixes

Hi Linus, One nouveau fix, and a few AMD Polaris fixes and some Allwinner fixes. I've got some vmware fixes that I might send separate over the weekend, they fix some black screens, but I'm still debating them. Dave. The following changes since commit

[git pull] drm fixes

Hi Linus, One nouveau fix, and a few AMD Polaris fixes and some Allwinner fixes. I've got some vmware fixes that I might send separate over the weekend, they fix some black screens, but I'm still debating them. Dave. The following changes since commit

Re: [PATCH v3 3/4] perf annotate: add powerpc support

Hi Michael, On Wednesday 06 July 2016 03:38 PM, Michael Ellerman wrote: Ravi Bangoria writes: On Thursday 30 June 2016 11:51 AM, Michael Ellerman wrote: On Thu, 2016-06-30 at 11:44 +0530, Ravi Bangoria wrote: diff --git a/tools/perf/util/annotate.c

Re: [PATCH v3 3/4] perf annotate: add powerpc support

Hi Michael, On Wednesday 06 July 2016 03:38 PM, Michael Ellerman wrote: Ravi Bangoria writes: On Thursday 30 June 2016 11:51 AM, Michael Ellerman wrote: On Thu, 2016-06-30 at 11:44 +0530, Ravi Bangoria wrote: diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c index

Re: [PATCH v2] kexec: Fix kdump failure with notsc

Hi , Eric Thanks for your comments firstly. On Thu, 2016-07-07 at 12:55 -0500, Eric W. Biederman wrote: > Wei Jiangang writes: > > > If we specify the 'notsc' boot parameter for the dump-capture kernel, > > and then trigger a crash(panic) by using "ALT-SysRq-c" or

Re: [PATCH v2] kexec: Fix kdump failure with notsc

Hi , Eric Thanks for your comments firstly. On Thu, 2016-07-07 at 12:55 -0500, Eric W. Biederman wrote: > Wei Jiangang writes: > > > If we specify the 'notsc' boot parameter for the dump-capture kernel, > > and then trigger a crash(panic) by using "ALT-SysRq-c" or "echo c > > >

[PATCH v4 2/3] perf annotate: Enable cross arch annotate

Change current data structures and function to enable cross arch annotate. Current implementation does not contain logic of record on one arch and annotating on other. This remote annotate is partially possible with current implementation for x86 (or may be arm as well) only. But, to make remote

[PATCH v4 3/3] perf annotate: add powerpc support

From: Naveen N. Rao Powerpc has long list of branch instructions and hardcoding them in table appears to be error-prone. So, add new function to find instruction instead of creating table. This function dynamically create table(list of 'struct ins'), and instead

[PATCH v4 3/3] perf annotate: add powerpc support

From: Naveen N. Rao Powerpc has long list of branch instructions and hardcoding them in table appears to be error-prone. So, add new function to find instruction instead of creating table. This function dynamically create table(list of 'struct ins'), and instead of creating object every time,

[PATCH v4 2/3] perf annotate: Enable cross arch annotate

Change current data structures and function to enable cross arch annotate. Current implementation does not contain logic of record on one arch and annotating on other. This remote annotate is partially possible with current implementation for x86 (or may be arm as well) only. But, to make remote

[PATCH v4 1/3] perf: Define macro for normalized arch names

Define macro for each normalized arch name and use them instead of using arch name as string Signed-off-by: Ravi Bangoria --- Changes in v4: - Moved position of patch tools/perf/arch/common.c | 36 ++--

[PATCH v4 0/3] perf annotate: Enable cross arch annotate

Perf can currently only support code navigation (branches and calls) in annotate when run on the same architecture where perf.data was recorded. But cross arch annotate is not supported. This patchset enables cross arch annotate. Currently I've used x86 and arm instructions which are already

[PATCH v4 1/3] perf: Define macro for normalized arch names

Define macro for each normalized arch name and use them instead of using arch name as string Signed-off-by: Ravi Bangoria --- Changes in v4: - Moved position of patch tools/perf/arch/common.c | 36 ++-- tools/perf/arch/common.h | 11

[PATCH v4 0/3] perf annotate: Enable cross arch annotate

Perf can currently only support code navigation (branches and calls) in annotate when run on the same architecture where perf.data was recorded. But cross arch annotate is not supported. This patchset enables cross arch annotate. Currently I've used x86 and arm instructions which are already

Re: [PATCH 1/2] HID: logitech-hidpp: add battery support for HID++ 2.0 devices

On Fri, Jul 08, 2016 at 01:21:08AM +0200, Bastien Nocera wrote: > On Wed, 2016-06-29 at 19:28 +1000, Peter Hutterer wrote: > > If the 0x1000 Unified Battery Level Status feature exists, expose the > > battery > > level. > > > > The main drawback is that while a device is plugged in its battery >

Re: [PATCH 1/2] HID: logitech-hidpp: add battery support for HID++ 2.0 devices

On Fri, Jul 08, 2016 at 01:21:08AM +0200, Bastien Nocera wrote: > On Wed, 2016-06-29 at 19:28 +1000, Peter Hutterer wrote: > > If the 0x1000 Unified Battery Level Status feature exists, expose the > > battery > > level. > > > > The main drawback is that while a device is plugged in its battery >

Re: linux-next: please clean up the lightnvm tree

On 07/08/2016 06:22 AM, Stephen Rothwell wrote: Hi Matias, I noticed that the commits in the lightnvm tree have been applied to the block tree as a series of patches (i.e. effectively rebased). Could you please remove all the duplicate patches from the lightnvm tree (which I think is the whole

Re: linux-next: please clean up the lightnvm tree

On 07/08/2016 06:22 AM, Stephen Rothwell wrote: Hi Matias, I noticed that the commits in the lightnvm tree have been applied to the block tree as a series of patches (i.e. effectively rebased). Could you please remove all the duplicate patches from the lightnvm tree (which I think is the whole

Re: [PATCH v7 07/11] powerpc/powernv: Add platform support for stop instruction

> > > > > > @@ -439,7 +540,18 @@ timebase_resync: > > >    */ > > >   bne cr4,clear_lock > > >   > > > - /* Restore per core state */ > > > + /* > > > +  * First thread in the core to wake up and its waking up > > > with > > > +  * complete hypervisor state loss. Restore per core > > >

Re: [PATCH v7 07/11] powerpc/powernv: Add platform support for stop instruction

> > > > > > @@ -439,7 +540,18 @@ timebase_resync: > > >    */ > > >   bne cr4,clear_lock > > >   > > > - /* Restore per core state */ > > > + /* > > > +  * First thread in the core to wake up and its waking up > > > with > > > +  * complete hypervisor state loss. Restore per core > > >

linux-next: please clean up the lightnvm tree

Hi Matias, I noticed that the commits in the lightnvm tree have been applied to the block tree as a series of patches (i.e. effectively rebased). Could you please remove all the duplicate patches from the lightnvm tree (which I think is the whole tree, curretly) before they start causing merge

linux-next: please clean up the lightnvm tree

Hi Matias, I noticed that the commits in the lightnvm tree have been applied to the block tree as a series of patches (i.e. effectively rebased). Could you please remove all the duplicate patches from the lightnvm tree (which I think is the whole tree, curretly) before they start causing merge

Re: [PATCH v7 07/11] powerpc/powernv: Add platform support for stop instruction

On 07/08/2016 07:50 AM, Michael Neuling wrote: > >> diff --git a/arch/powerpc/include/asm/cpuidle.h >> b/arch/powerpc/include/asm/cpuidle.h >> index d2f99ca..3d7fc06 100644 >> --- a/arch/powerpc/include/asm/cpuidle.h >> +++ b/arch/powerpc/include/asm/cpuidle.h >> @@ -13,6 +13,8 @@ >> #ifndef

Re: [PATCH v7 07/11] powerpc/powernv: Add platform support for stop instruction

On 07/08/2016 07:50 AM, Michael Neuling wrote: > >> diff --git a/arch/powerpc/include/asm/cpuidle.h >> b/arch/powerpc/include/asm/cpuidle.h >> index d2f99ca..3d7fc06 100644 >> --- a/arch/powerpc/include/asm/cpuidle.h >> +++ b/arch/powerpc/include/asm/cpuidle.h >> @@ -13,6 +13,8 @@ >> #ifndef

Re: perf bpf examples

On 2016/7/8 1:58, Brendan Gregg wrote: On Thu, Jul 7, 2016 at 10:54 AM, Brendan Gregg wrote: On Wed, Jul 6, 2016 at 6:49 PM, Wangnan (F) wrote: On 2016/7/7 4:29, Brendan Gregg wrote: G'Day, Are perf bpf examples shared anywhere? I've seen

Re: perf bpf examples

On 2016/7/8 1:58, Brendan Gregg wrote: On Thu, Jul 7, 2016 at 10:54 AM, Brendan Gregg wrote: On Wed, Jul 6, 2016 at 6:49 PM, Wangnan (F) wrote: On 2016/7/7 4:29, Brendan Gregg wrote: G'Day, Are perf bpf examples shared anywhere? I've seen many posted to lkml (by Wang Nan), but don't

Re: linux-next: manual merge of the block tree with Linus' tree

Hi all, On Fri, 8 Jul 2016 13:07:50 +1000 Stephen Rothwell wrote: > > + * Get the bios in the request so we can re-queue them. > + */ > - if (shadow[j].request->cmd_flags & > -

Re: linux-next: manual merge of the block tree with Linus' tree

Hi all, On Fri, 8 Jul 2016 13:07:50 +1000 Stephen Rothwell wrote: > > + * Get the bios in the request so we can re-queue them. > + */ > - if (shadow[j].request->cmd_flags & > - (REQ_FLUSH | REQ_FUA

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/volumes.h between commit: 26112f7f4726 ("btrfs: take an fs_info parameter directly when the root is not used otherwise") from the btrfs-kdave tree and commit: 81a75f6781de ("btrfs: use bio fields for op

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/volumes.h between commit: 26112f7f4726 ("btrfs: take an fs_info parameter directly when the root is not used otherwise") from the btrfs-kdave tree and commit: 81a75f6781de ("btrfs: use bio fields for op

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/volumes.c between commit: 26112f7f4726 ("btrfs: take an fs_info parameter directly when the root is not used otherwise") from the btrfs-kdave tree and commit: 4e49ea4a3d27 ("block/fs/drivers: remove rw

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/volumes.c between commit: 26112f7f4726 ("btrfs: take an fs_info parameter directly when the root is not used otherwise") from the btrfs-kdave tree and commit: 4e49ea4a3d27 ("block/fs/drivers: remove rw

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/inode.c between commit: b286384aac32 ("btrfs: root->fs_info cleanup, add fs_info convenience variables") 26112f7f4726 ("btrfs: take an fs_info parameter directly when the root is not used otherwise")

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/inode.c between commit: b286384aac32 ("btrfs: root->fs_info cleanup, add fs_info convenience variables") 26112f7f4726 ("btrfs: take an fs_info parameter directly when the root is not used otherwise")

Re: [PATCH 4.4 00/32] 4.4.15-stable review

On 07/06/2016 07:19 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.15 release. > There are 32 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/32] 4.4.15-stable review

On 07/06/2016 07:19 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.15 release. > There are 32 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.6 00/31] 4.6.4-stable review

On 07/06/2016 07:18 PM, Greg Kroah-Hartman wrote: > --- > Note, I'm on vacation this week, so I only took a few "easy" patches for > the stable trees, due to me not having much time to debug anything here, > and because, well, I'm on vacation and supposed to be ignoring

Re: [PATCH 4.6 00/31] 4.6.4-stable review

On 07/06/2016 07:18 PM, Greg Kroah-Hartman wrote: > --- > Note, I'm on vacation this week, so I only took a few "easy" patches for > the stable trees, due to me not having much time to debug anything here, > and because, well, I'm on vacation and supposed to be ignoring

RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms

Hi Arnd, > -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Thursday, July 07, 2016 4:30 PM > To: Yangbo Lu > Cc: Scott Wood; linuxppc-...@lists.ozlabs.org; Mark Rutland; Ulf Hansson; > linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux- >

RE: [PATCH 2/4] soc: fsl: add GUTS driver for QorIQ platforms

Hi Arnd, > -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Thursday, July 07, 2016 4:30 PM > To: Yangbo Lu > Cc: Scott Wood; linuxppc-...@lists.ozlabs.org; Mark Rutland; Ulf Hansson; > linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; linux- >

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/7/7 23:37, Catalin Marinas wrote: > On Thu, Jul 07, 2016 at 08:09:04PM +0800, Zhen Lei wrote: >> At present, PG_dcache_clean is only cleared when the related huge page >> is about to be freed. But sometimes, there maybe a process is in charge >> to copy binary codes into a shared memory,

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/7/7 23:37, Catalin Marinas wrote: > On Thu, Jul 07, 2016 at 08:09:04PM +0800, Zhen Lei wrote: >> At present, PG_dcache_clean is only cleared when the related huge page >> is about to be freed. But sometimes, there maybe a process is in charge >> to copy binary codes into a shared memory,

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote: > On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote: > > On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) wrote: > > > On 7 July 2016 at 17:01, James Bottomley > > >

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote: > On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote: > > On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) wrote: > > > On 7 July 2016 at 17:01, James Bottomley > > > wrote: > > [Serge already answered the

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/extent-tree.c between commit: b286384aac32 ("btrfs: root->fs_info cleanup, add fs_info convenience variables") [again, no commiter Signed-off-by] from the btrfs-kdave tree and commit: b3d3fa519905 ("btrfs:

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/extent-tree.c between commit: b286384aac32 ("btrfs: root->fs_info cleanup, add fs_info convenience variables") [again, no commiter Signed-off-by] from the btrfs-kdave tree and commit: b3d3fa519905 ("btrfs:

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/disk-io.c between commit: b286384aac32 ("btrfs: root->fs_info cleanup, add fs_info convenience variables") 26112f7f4726 ("btrfs: take an fs_info parameter directly when the root is not used otherwise")

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/disk-io.c between commit: b286384aac32 ("btrfs: root->fs_info cleanup, add fs_info convenience variables") 26112f7f4726 ("btrfs: take an fs_info parameter directly when the root is not used otherwise")

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote: > On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote: > > On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote: > > > On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) > > > wrote: > > > > On 7 July 2016 at

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote: > On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote: > > On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote: > > > On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) > > > wrote: > > > > On 7 July 2016 at

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/compression.c between commit: 26112f7f4726 ("btrfs: take an fs_info parameter directly when the root is not used otherwise") [This commit has no Signed-off-by from its committer :-(] d42b410c1511 ("Btrfs:

linux-next: manual merge of the block tree with the btrfs-kdave tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/btrfs/compression.c between commit: 26112f7f4726 ("btrfs: take an fs_info parameter directly when the root is not used otherwise") [This commit has no Signed-off-by from its committer :-(] d42b410c1511 ("Btrfs:

Re: [PATCH v2] clkdev: add devm_of_clk_get()

Hi Michael Thank you for your feedback > > struct clk *clk_get(struct device *dev, const char *con_id) > > { > > ... > > if (dev) { > > clk = __of_clk_get_by_name(dev->of_node, dev_id, con_id); > > > >

Re: [PATCH v2] clkdev: add devm_of_clk_get()

Hi Michael Thank you for your feedback > > struct clk *clk_get(struct device *dev, const char *con_id) > > { > > ... > > if (dev) { > > clk = __of_clk_get_by_name(dev->of_node, dev_id, con_id); > > > >

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, 2016-07-07 at 19:16 -0700, Andrew Vagin wrote: > On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote: > > On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) > > wrote: > > > On 7 July 2016 at 17:01, James Bottomley > > >

Re: [CRIU] Introspecting userns relationships to other namespaces?

On Thu, 2016-07-07 at 19:16 -0700, Andrew Vagin wrote: > On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote: > > On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) > > wrote: > > > On 7 July 2016 at 17:01, James Bottomley > > > wrote: > > [Serge already answered the

Re: [PATCH v3] f2fs: fix to avoid data update racing between GC and DIO

Hi Chao, Could you take a look at this in xfstests/generic/013? [ 502.480850] == [ 502.480864] [ INFO: possible circular locking dependency detected ] [ 502.480877] 4.7.0-rc1+ #124 Tainted: G OE [ 502.480886]

Re: [PATCH v3] f2fs: fix to avoid data update racing between GC and DIO

Hi Chao, Could you take a look at this in xfstests/generic/013? [ 502.480850] == [ 502.480864] [ INFO: possible circular locking dependency detected ] [ 502.480877] 4.7.0-rc1+ #124 Tainted: G OE [ 502.480886]

RE: [PATCH v2 0/3] Cache id

> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Thursday, July 07, 2016 9:21 AM > On Wed, Jul 06, 2016 at 03:07:15PM -0700, Fenghua Yu wrote: > > From: Fenghua Yu > > > > This patch set introduces cache id to identify a cache in platform. It > > can be useful in such

RE: [PATCH v2 0/3] Cache id

> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Thursday, July 07, 2016 9:21 AM > On Wed, Jul 06, 2016 at 03:07:15PM -0700, Fenghua Yu wrote: > > From: Fenghua Yu > > > > This patch set introduces cache id to identify a cache in platform. It > > can be useful in such areas as Cach

linux-next: manual merge of the block tree with Linus' tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: drivers/block/xen-blkfront.c between commit: 7b427a59538a ("xen-blkfront: save uncompleted reqs in blkfront_resume()") from Linus' tree and commit: c2df40dfb8c0 ("drivers: use req op accessor") 3a5e02ced11e

linux-next: manual merge of the block tree with Linus' tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: drivers/block/xen-blkfront.c between commit: 7b427a59538a ("xen-blkfront: save uncompleted reqs in blkfront_resume()") from Linus' tree and commit: c2df40dfb8c0 ("drivers: use req op accessor") 3a5e02ced11e

Re: [PATCH v11 00/22] Add HiSilicon RoCE driver

在 2016/7/2 17:39, Lijun Ou 写道: > The HiSilicon Network Substem is a long term evolution IP which is > supposed to be used in HiSilicon ICT SoCs. HNS (HiSilicon Network > Sybsystem) also has a hardware support of performing RDMA with > RoCEE. > The driver for HiSilicon RoCEE(RoCE Engine) is a

Re: [PATCH v11 00/22] Add HiSilicon RoCE driver

在 2016/7/2 17:39, Lijun Ou 写道: > The HiSilicon Network Substem is a long term evolution IP which is > supposed to be used in HiSilicon ICT SoCs. HNS (HiSilicon Network > Sybsystem) also has a hardware support of performing RDMA with > RoCEE. > The driver for HiSilicon RoCEE(RoCE Engine) is a

Re: [PATCH v7 00/11] powerpc/powernv/cpuidle: Add support for POWER ISA v3 idle states

Except for the issue with patch 7 I've already commented on the rest of this series is good with me.  FWIW: Acked-by: Michael Neuling Thanks. On Fri, 2016-07-08 at 02:17 +0530, Shreyas B. Prabhu wrote: > POWER ISA v3 defines a new idle processor core mechanism. In summary, >

Re: [PATCH v7 00/11] powerpc/powernv/cpuidle: Add support for POWER ISA v3 idle states

Except for the issue with patch 7 I've already commented on the rest of this series is good with me.  FWIW: Acked-by: Michael Neuling Thanks. On Fri, 2016-07-08 at 02:17 +0530, Shreyas B. Prabhu wrote: > POWER ISA v3 defines a new idle processor core mechanism. In summary, >  a) new

Re: [PATCH v7 09/11] cpuidle/powernv: cleanup powernv_add_idle_states

>   /* > @@ -230,7 +238,7 @@ static int powernv_add_idle_states(void) >   strcpy(powernv_states[nr_idle_states].desc, > "FastSleep"); >   powernv_states[nr_idle_states].flags = > CPUIDLE_FLAG_TIMER_STOP; >  

Re: [PATCH v7 09/11] cpuidle/powernv: cleanup powernv_add_idle_states

>   /* > @@ -230,7 +238,7 @@ static int powernv_add_idle_states(void) >   strcpy(powernv_states[nr_idle_states].desc, > "FastSleep"); >   powernv_states[nr_idle_states].flags = > CPUIDLE_FLAG_TIMER_STOP; >  

Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

On Thu, Jul 07, 2016 at 11:17:01AM +0100, Mel Gorman wrote: > On Thu, Jul 07, 2016 at 10:20:39AM +0900, Joonsoo Kim wrote: > > > @@ -3249,9 +3249,19 @@ static void kswapd_try_to_sleep(pg_data_t *pgdat, > > > int order, > > > > > > prepare_to_wait(>kswapd_wait, , TASK_INTERRUPTIBLE); > > > >

Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

On Thu, Jul 07, 2016 at 11:17:01AM +0100, Mel Gorman wrote: > On Thu, Jul 07, 2016 at 10:20:39AM +0900, Joonsoo Kim wrote: > > > @@ -3249,9 +3249,19 @@ static void kswapd_try_to_sleep(pg_data_t *pgdat, > > > int order, > > > > > > prepare_to_wait(>kswapd_wait, , TASK_INTERRUPTIBLE); > > > >

Re: [PATCH v3 3/4] drm/bridge: analogix_dp: add the PSR function support

On 07/08/2016 10:26 AM, Yakir Yang wrote: Sean, Thanks for your review. On 07/02/2016 03:46 AM, Sean Paul wrote: On Fri, Jul 1, 2016 at 5:19 AM, Yakir Yang wrote: The full name of PSR is Panel Self Refresh, panel device could refresh itself with the hardware

RE: [PATCH v2] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

On Thu, Jul 07, 2016 at 10:25PM , Jason Cooper wrote: > -Original Message- > From: Jason Cooper [mailto:ja...@lakedaemon.net] > Sent: Thursday, July 07, 2016 10:25 PM > To: Qiang Zhao > Cc: o...@buserror.net; t...@linutronix.de;

Re: [PATCH v3 3/4] drm/bridge: analogix_dp: add the PSR function support

On 07/08/2016 10:26 AM, Yakir Yang wrote: Sean, Thanks for your review. On 07/02/2016 03:46 AM, Sean Paul wrote: On Fri, Jul 1, 2016 at 5:19 AM, Yakir Yang wrote: The full name of PSR is Panel Self Refresh, panel device could refresh itself with the hardware framebuffer in panel, this

RE: [PATCH v2] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

On Thu, Jul 07, 2016 at 10:25PM , Jason Cooper wrote: > -Original Message- > From: Jason Cooper [mailto:ja...@lakedaemon.net] > Sent: Thursday, July 07, 2016 10:25 PM > To: Qiang Zhao > Cc: o...@buserror.net; t...@linutronix.de; marc.zyng...@arm.com; linuxppc- > d...@lists.ozlabs.org;

  1   2   3   4   5   6   7   8   9   10   >