Re: [PATCH v2 10/30] Add x86-specific parity functions

在 2016年04月06日 18:53, Borislav Petkov 写道: On Wed, Apr 06, 2016 at 11:37:37AM +0100, One Thousand Gnomes wrote: Even that would still be wrong for the smaller parity values. The CPU supports 8bit parity directly going back to the 8086 so the implementation for 8bit and I think 16bit is still

Re: [PATCH v2 10/30] Add x86-specific parity functions

在 2016年04月07日 03:45, Andi Kleen 写道: zengzhao...@163.com writes: From: Zhaoxiu Zeng Use alternatives, lifted from arch_hweight Is there actually anything performance critical in the kernel that uses parity? FWIW the arch hweight custom calling convention is a problem

Re: [PATCH v2 10/30] Add x86-specific parity functions

在 2016年04月06日 18:53, Borislav Petkov 写道: On Wed, Apr 06, 2016 at 11:37:37AM +0100, One Thousand Gnomes wrote: Even that would still be wrong for the smaller parity values. The CPU supports 8bit parity directly going back to the 8086 so the implementation for 8bit and I think 16bit is still

Re: [PATCH v2 10/30] Add x86-specific parity functions

在 2016年04月07日 03:45, Andi Kleen 写道: zengzhao...@163.com writes: From: Zhaoxiu Zeng Use alternatives, lifted from arch_hweight Is there actually anything performance critical in the kernel that uses parity? FWIW the arch hweight custom calling convention is a problem for LTO because it

Re: [PATCH v2 08/30] Add sparc-specific parity functions

在 2016年04月07日 02:44, Sam Ravnborg 写道: Hi Zeng. Use runtime patching for sparc64, lifted from hweight No errors found in patch - but a few comments. In general patch looks good. Thanks. Sparc, powerpc, and x86 are all new to me. +++ b/arch/sparc/include/asm/bitops_64.h @@ -47,6 +47,24 @@

Re: [PATCH v2 09/30] Add tile-specific parity functions

在 2016年04月06日 21:27, Chris Metcalf 写道: On 4/6/2016 5:08 AM, zengzhao...@163.com wrote: From: Zhaoxiu Zeng Signed-off-by: Zhaoxiu Zeng --- arch/tile/include/asm/bitops.h | 26 ++ 1 file changed, 26 insertions(+) Since

Re: [PATCH v2 08/30] Add sparc-specific parity functions

在 2016年04月07日 02:44, Sam Ravnborg 写道: Hi Zeng. Use runtime patching for sparc64, lifted from hweight No errors found in patch - but a few comments. In general patch looks good. Thanks. Sparc, powerpc, and x86 are all new to me. +++ b/arch/sparc/include/asm/bitops_64.h @@ -47,6 +47,24 @@

Re: [PATCH v2 09/30] Add tile-specific parity functions

在 2016年04月06日 21:27, Chris Metcalf 写道: On 4/6/2016 5:08 AM, zengzhao...@163.com wrote: From: Zhaoxiu Zeng Signed-off-by: Zhaoxiu Zeng --- arch/tile/include/asm/bitops.h | 26 ++ 1 file changed, 26 insertions(+) Since all the code you are adding here is

Re: [PATCH v2 10/30] Add x86-specific parity functions

在 2016年04月06日 18:13, Borislav Petkov 写道: On Wed, Apr 06, 2016 at 05:14:45PM +0800, zengzhao...@163.com wrote: From: Zhaoxiu Zeng Use alternatives, lifted from arch_hweight Signed-off-by: Zhaoxiu Zeng --- arch/x86/include/asm/arch_hweight.h |

Re: [PATCH v2 10/30] Add x86-specific parity functions

在 2016年04月06日 18:13, Borislav Petkov 写道: On Wed, Apr 06, 2016 at 05:14:45PM +0800, zengzhao...@163.com wrote: From: Zhaoxiu Zeng Use alternatives, lifted from arch_hweight Signed-off-by: Zhaoxiu Zeng --- arch/x86/include/asm/arch_hweight.h | 5 ++ arch/x86/include/asm/arch_parity.h |

mmotm 2016-04-06-20-40 uploaded

The mm-of-the-moment snapshot 2016-04-06-20-40 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2016-04-06-20-40 uploaded

The mm-of-the-moment snapshot 2016-04-06-20-40 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

On Wed, 2016-04-06 at 20:00 -0400, Tejun Heo wrote: > Hello, Mike. > > On Sun, Mar 13, 2016 at 06:40:35PM +0100, Mike Galbraith wrote: > > On Sun, 2016-03-13 at 11:00 -0400, Tejun Heo wrote: > > > Let's say there is an application which wants to manage resource > > > distributions across its

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

On Wed, 2016-04-06 at 20:00 -0400, Tejun Heo wrote: > Hello, Mike. > > On Sun, Mar 13, 2016 at 06:40:35PM +0100, Mike Galbraith wrote: > > On Sun, 2016-03-13 at 11:00 -0400, Tejun Heo wrote: > > > Let's say there is an application which wants to manage resource > > > distributions across its

[PATCH] staging: rts5208: alignment to match open paranthesis

Fixes CHECK: Alignment should match open parenthesis Signed-off-by: Manav Batra --- drivers/staging/rts5208/ms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c index 3e75db7..0f0cd4a 100644

[PATCH] staging: rts5208: alignment to match open paranthesis

Fixes CHECK: Alignment should match open parenthesis Signed-off-by: Manav Batra --- drivers/staging/rts5208/ms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c index 3e75db7..0f0cd4a 100644 ---

Re: [PATCH] mmc: Remove some redundant debug prints

On 7 April 2016 at 09:40, Jaehoon Chung wrote: > On 04/06/2016 08:57 PM, Jisheng Zhang wrote: >> >> >> On Wed, 6 Apr 2016 19:38:30 +0800 Baolin Wang wrote: >> >>> This patch removes some redundant debug prints, since we have added some >>> tracepoints to help with

Re: [PATCH] mmc: Remove some redundant debug prints

On 7 April 2016 at 09:40, Jaehoon Chung wrote: > On 04/06/2016 08:57 PM, Jisheng Zhang wrote: >> >> >> On Wed, 6 Apr 2016 19:38:30 +0800 Baolin Wang wrote: >> >>> This patch removes some redundant debug prints, since we have added some >>> tracepoints to help with performance analysis of MMC

Re: [PATCH] mmc: Remove some redundant debug prints

On 6 April 2016 at 19:57, Jisheng Zhang wrote: > > > On Wed, 6 Apr 2016 19:38:30 +0800 Baolin Wang wrote: > >> This patch removes some redundant debug prints, since we have added some >> tracepoints to help with performance analysis of MMC subsystem. > > I think the debug

Re: [PATCH] mmc: Remove some redundant debug prints

On 6 April 2016 at 19:57, Jisheng Zhang wrote: > > > On Wed, 6 Apr 2016 19:38:30 +0800 Baolin Wang wrote: > >> This patch removes some redundant debug prints, since we have added some >> tracepoints to help with performance analysis of MMC subsystem. > > I think the debug prints you removed are

Re: [PATCH v9 2/4] gadget: Support for the usb charger framework

On Wed, Apr 06, 2016 at 04:58:03PM +0300, Felipe Balbi wrote: > > Hi, > > Jun Li writes: > >> >> >> > Since we already have get_charger_type callback at usb_charger > >> >> >> > structure, why we still need this API at usb_gadget_ops? > >> >> >> > >> >> >> In case some users

Re: [PATCH v9 2/4] gadget: Support for the usb charger framework

On Wed, Apr 06, 2016 at 04:58:03PM +0300, Felipe Balbi wrote: > > Hi, > > Jun Li writes: > >> >> >> > Since we already have get_charger_type callback at usb_charger > >> >> >> > structure, why we still need this API at usb_gadget_ops? > >> >> >> > >> >> >> In case some users want to get charger

Re: [PATCH 2/4] drivers/bus: make imx-weim.c explicitly non-modular

On Sun, Mar 27, 2016 at 05:10:56PM -0400, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > drivers/bus/Kconfig:config IMX_WEIM > drivers/bus/Kconfig:bool "Freescale EIM DRIVER > > ...meaning that it currently is not being built as a module by anyone.

Re: [PATCH 2/4] drivers/bus: make imx-weim.c explicitly non-modular

On Sun, Mar 27, 2016 at 05:10:56PM -0400, Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > drivers/bus/Kconfig:config IMX_WEIM > drivers/bus/Kconfig:bool "Freescale EIM DRIVER > > ...meaning that it currently is not being built as a module by anyone.

Re: [PATCH 12/31] huge tmpfs: extend get_user_pages_fast to shmem pmd

On Wed, 6 Apr 2016, Ingo Molnar wrote: > * Hugh Dickins wrote: > > > --- > > Cc'ed to arch maintainers as an FYI: this patch is not expected to > > go into the tree in the next few weeks, and depends upon a PageTeam > > definition not yet available outside this huge tmpfs

Re: [PATCH 12/31] huge tmpfs: extend get_user_pages_fast to shmem pmd

On Wed, 6 Apr 2016, Ingo Molnar wrote: > * Hugh Dickins wrote: > > > --- > > Cc'ed to arch maintainers as an FYI: this patch is not expected to > > go into the tree in the next few weeks, and depends upon a PageTeam > > definition not yet available outside this huge tmpfs patchset. > > Please

[PATCH V5 3/4] coresight-stm: Bindings for System Trace Macrocell

From: Mathieu Poirier The System Trace Macrocell (STM) is an IP block falling under the CoreSight umbrella. It's main purpose it so expose stimulus channels to any system component for the purpose of information logging. Bindings for this IP block adds a couple of

[PATCH V5 4/4] coresight-stm: adding driver for CoreSight STM component

From: Pratik Patel This driver adds support for the STM CoreSight IP block, allowing any system compoment (HW or SW) to log and aggregate messages via a single entity. The CoreSight STM exposes an application defined number of channels called stimulus port.

[PATCH V5 3/4] coresight-stm: Bindings for System Trace Macrocell

From: Mathieu Poirier The System Trace Macrocell (STM) is an IP block falling under the CoreSight umbrella. It's main purpose it so expose stimulus channels to any system component for the purpose of information logging. Bindings for this IP block adds a couple of items to the current

[PATCH V5 4/4] coresight-stm: adding driver for CoreSight STM component

From: Pratik Patel This driver adds support for the STM CoreSight IP block, allowing any system compoment (HW or SW) to log and aggregate messages via a single entity. The CoreSight STM exposes an application defined number of channels called stimulus port. Configuration is done using entries

[PATCH V5 2/4] coresight: adding path for STM device

From: Mathieu Poirier >From a core framework point of view an STM device is a source that is treated the same way as any other tracers. Unlike tracers though STM devices are not associated with a CPU. As such it doesn't make sense to associate the path from an STM

[PATCH V5 1/4] stm class: Support devices that override software assigned masters

From: Alexander Shishkin Some STM devices adjust software assigned master numbers depending on the trace source and its runtime state and whatnot. This patch adds a sysfs attribute to inform the trace-side software that master numbers assigned to software

[PATCH V5 2/4] coresight: adding path for STM device

From: Mathieu Poirier >From a core framework point of view an STM device is a source that is treated the same way as any other tracers. Unlike tracers though STM devices are not associated with a CPU. As such it doesn't make sense to associate the path from an STM device to its sink with a

[PATCH V5 1/4] stm class: Support devices that override software assigned masters

From: Alexander Shishkin Some STM devices adjust software assigned master numbers depending on the trace source and its runtime state and whatnot. This patch adds a sysfs attribute to inform the trace-side software that master numbers assigned to software sources will not match those in the STP

[PATCH V5 0/4] Introduce CoreSight STM support

This patchset adds support for the CoreSight STM IP block. Changes from V4: - Rebased the whole patch set onto [4] (v4.6-rc1). - Made a few minor modifications according to the code changes since v4.5. - Replaced the original 1/4 with a new patch the Alex provided. - Another new patch 2/4 in

[PATCH V5 0/4] Introduce CoreSight STM support

This patchset adds support for the CoreSight STM IP block. Changes from V4: - Rebased the whole patch set onto [4] (v4.6-rc1). - Made a few minor modifications according to the code changes since v4.5. - Replaced the original 1/4 with a new patch the Alex provided. - Another new patch 2/4 in

[PATCH] Documentation: clk: update file names containing referenced structures

Commit 'b09d6d991' removes include/linux/clk-private.h and re-arranges the clock related structures contained in it in different files. The documentation has not been updated accordingly, thus it wasn't anymore consistent. Place the structures referenced by Documentation/clk.txt in the correct

[PATCH] Documentation: clk: update file names containing referenced structures

Commit 'b09d6d991' removes include/linux/clk-private.h and re-arranges the clock related structures contained in it in different files. The documentation has not been updated accordingly, thus it wasn't anymore consistent. Place the structures referenced by Documentation/clk.txt in the correct

[lkp] [ipv6] 29405a159b: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97

FYI, we noticed below warning "BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97" showed on https://github.com/0day-ci/linux Bastien-Philbert/ipv6-icmp-Add-protection-from-concurrent-users-in-the-function-icmpv6_echo_reply/20160406-053

[lkp] [ipv6] 29405a159b: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97

FYI, we noticed below warning "BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97" showed on https://github.com/0day-ci/linux Bastien-Philbert/ipv6-icmp-Add-protection-from-concurrent-users-in-the-function-icmpv6_echo_reply/20160406-053

Re: [PATCH v9 1/4] gadget: Introduce the usb charger framework

On Wed, Apr 06, 2016 at 01:25:06PM +0300, Felipe Balbi wrote: > > Hi, > > Peter Chen writes: > > On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote: > >> Peter Chen writes: > >> > On Wed, Apr 06, 2016 at 10:38:23AM +0300, Felipe Balbi

Re: [PATCH v9 1/4] gadget: Introduce the usb charger framework

On Wed, Apr 06, 2016 at 01:25:06PM +0300, Felipe Balbi wrote: > > Hi, > > Peter Chen writes: > > On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote: > >> Peter Chen writes: > >> > On Wed, Apr 06, 2016 at 10:38:23AM +0300, Felipe Balbi wrote: > >> >> Peter Chen writes: > >> >> > On

RE: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs

Hi, > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Octavian Purdila > Subject: Re: [RFC PATCH 10/10] acpi: add support for loading SSDTs via > configfs > > On Wed, Apr 6, 2016 at 9:05 AM, Zheng, Lv wrote: > > >> It is

RE: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs

Hi, > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Octavian Purdila > Subject: Re: [RFC PATCH 10/10] acpi: add support for loading SSDTs via > configfs > > On Wed, Apr 6, 2016 at 9:05 AM, Zheng, Lv wrote: > > >> It is hard to create new

Re: [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()

Hi Gabriele, On Wed, 6 Apr 2016 14:50:29 + Gabriele Paoloni wrote: > Hi, sorry to be late on this > > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > > ow...@vger.kernel.org] On Behalf Of Jisheng Zhang > > Sent: 16 March 2016 11:41 > > To:

Re: [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()

Hi Gabriele, On Wed, 6 Apr 2016 14:50:29 + Gabriele Paoloni wrote: > Hi, sorry to be late on this > > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > > ow...@vger.kernel.org] On Behalf Of Jisheng Zhang > > Sent: 16 March 2016 11:41 > > To:

Re: [lkp] [mm] 6f25a14a70: will-it-scale.scalability -4.0% regression

On 2016/4/7 9:06, kernel test robot wrote: > FYI, we noticed that will-it-scale.scalability -4.0% regression on > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > commit 6f25a14a7053b69917e2ebea0d31dd444cd31fd5 ("mm: fix invalid node in > alloc_migrate_target()") >

Re: [lkp] [mm] 6f25a14a70: will-it-scale.scalability -4.0% regression

On 2016/4/7 9:06, kernel test robot wrote: > FYI, we noticed that will-it-scale.scalability -4.0% regression on > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > commit 6f25a14a7053b69917e2ebea0d31dd444cd31fd5 ("mm: fix invalid node in > alloc_migrate_target()") >

Re: [PATCH v3 02/16] mm/compaction: support non-lru movable page migration

On Mon, Apr 04, 2016 at 03:24:34PM +0200, Vlastimil Babka wrote: > On 04/04/2016 07:12 AM, Minchan Kim wrote: > >On Fri, Apr 01, 2016 at 11:29:14PM +0200, Vlastimil Babka wrote: > >>Might have been better as a separate migration patch and then a > >>compaction patch. It's prefixed mm/compaction,

Re: [PATCH v3 02/16] mm/compaction: support non-lru movable page migration

On Mon, Apr 04, 2016 at 03:24:34PM +0200, Vlastimil Babka wrote: > On 04/04/2016 07:12 AM, Minchan Kim wrote: > >On Fri, Apr 01, 2016 at 11:29:14PM +0200, Vlastimil Babka wrote: > >>Might have been better as a separate migration patch and then a > >>compaction patch. It's prefixed mm/compaction,

Re: [RESEND PATCH v9] mtd: spi-nor: add hisilicon spi-nor flash controller driver

On 04/07/2016 04:10 AM, Jiancheng Xue wrote: > Hi Brian, >Thank you very much for your comments. I'll fix these issues in next > version. > In addition, for easy understanding I'd like to rewrite hisi_spi_nor_write and > hisi_spi_nor_read. Your comments on these modifications will be highly

Re: [RESEND PATCH v9] mtd: spi-nor: add hisilicon spi-nor flash controller driver

On 04/07/2016 04:10 AM, Jiancheng Xue wrote: > Hi Brian, >Thank you very much for your comments. I'll fix these issues in next > version. > In addition, for easy understanding I'd like to rewrite hisi_spi_nor_write and > hisi_spi_nor_read. Your comments on these modifications will be highly

Re: [PATCH v3 03/16] mm: add non-lru movable page support document

On Mon, Apr 04, 2016 at 03:09:22PM +0200, Vlastimil Babka wrote: > On 04/04/2016 04:25 AM, Minchan Kim wrote: > >> > >>Ah, I see, so it's designed with page lock to handle the concurrent > >>isolations etc. > >> > >>In http://marc.info/?l=linux-mm=143816716511904=2 Mel has warned > >>about doing

Re: [PATCH v3 03/16] mm: add non-lru movable page support document

On Mon, Apr 04, 2016 at 03:09:22PM +0200, Vlastimil Babka wrote: > On 04/04/2016 04:25 AM, Minchan Kim wrote: > >> > >>Ah, I see, so it's designed with page lock to handle the concurrent > >>isolations etc. > >> > >>In http://marc.info/?l=linux-mm=143816716511904=2 Mel has warned > >>about doing

Re: Boot failure when using NFS on OMAP based evms

On Wed, Apr 6, 2016 at 7:12 PM, Franklin S Cooper Jr. wrote: > Hi All, > > Currently linux-next is failing to boot via NFS on my AM335x GP evm, > AM437x GP evm and Beagle X15. I bisected the problem down to the commit > "udp: remove headers from UDP packets before queueing". > > I

Re: Boot failure when using NFS on OMAP based evms

On Wed, Apr 6, 2016 at 7:12 PM, Franklin S Cooper Jr. wrote: > Hi All, > > Currently linux-next is failing to boot via NFS on my AM335x GP evm, > AM437x GP evm and Beagle X15. I bisected the problem down to the commit > "udp: remove headers from UDP packets before queueing". > > I had to revert

[PATCH] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

Galileo Gen2 board uses the PCAL9535 as the GPIO expansion, it is different from PCA9535 and includes interrupt mask/status registers, The current driver does not support the interrupt registers configuration, it causes some gpio pins cannot trigger interrupt events, this patch fix this issue. The

[PATCH] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

Galileo Gen2 board uses the PCAL9535 as the GPIO expansion, it is different from PCA9535 and includes interrupt mask/status registers, The current driver does not support the interrupt registers configuration, it causes some gpio pins cannot trigger interrupt events, this patch fix this issue. The

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, Apr 7, 2016 at 9:56 AM, Eric Wheeler wrote: > On Thu, 7 Apr 2016, Ming Lei wrote: > >> On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler >> wrote: >> > On Wed, 6 Apr 2016, Ming Lei wrote: >> > >> >> After arbitrary bio size is supported,

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, Apr 7, 2016 at 9:56 AM, Eric Wheeler wrote: > On Thu, 7 Apr 2016, Ming Lei wrote: > >> On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler >> wrote: >> > On Wed, 6 Apr 2016, Ming Lei wrote: >> > >> >> After arbitrary bio size is supported, the incoming bio may >> >> be very big. We have to

Re: [RESEND PATCH v9] mtd: spi-nor: add hisilicon spi-nor flash controller driver

Hi Brian, Thank you very much for your comments. I'll fix these issues in next version. In addition, for easy understanding I'd like to rewrite hisi_spi_nor_write and hisi_spi_nor_read. Your comments on these modifications will be highly appreciated. static int hisi_spi_nor_read(struct

Re: [RESEND PATCH v9] mtd: spi-nor: add hisilicon spi-nor flash controller driver

Hi Brian, Thank you very much for your comments. I'll fix these issues in next version. In addition, for easy understanding I'd like to rewrite hisi_spi_nor_write and hisi_spi_nor_read. Your comments on these modifications will be highly appreciated. static int hisi_spi_nor_read(struct

Re: [PULL] lkdtm update (4.6-rc3)

On Wed, Apr 06, 2016 at 04:26:33PM -0700, Kees Cook wrote: > Hi Greg, > > Please pull these lkdtm changes for 4.6-rc3. (BTW, should I send these > lkdtm pulls to you, or to Linus?) I can take them, not a problem. Or you send send me patches if that's easier. > The following changes since

Re: [PULL] lkdtm update (4.6-rc3)

On Wed, Apr 06, 2016 at 04:26:33PM -0700, Kees Cook wrote: > Hi Greg, > > Please pull these lkdtm changes for 4.6-rc3. (BTW, should I send these > lkdtm pulls to you, or to Linus?) I can take them, not a problem. Or you send send me patches if that's easier. > The following changes since

Re: [PATCH] kvm: x86: make lapic hrtimer pinned

On 2016/4/5 23:54, Radim Krčmář wrote: 2016-04-05 14:18+0800, Yang Zhang: On 2016/4/5 5:00, Rik van Riel wrote: Given that delivering a timer to a guest seems to involve trapping from the guest to the host, anyway, I don't see a downside to your patch. If that is ever changed (eg. allowing

Re: [PATCH] kvm: x86: make lapic hrtimer pinned

On 2016/4/5 23:54, Radim Krčmář wrote: 2016-04-05 14:18+0800, Yang Zhang: On 2016/4/5 5:00, Rik van Riel wrote: Given that delivering a timer to a guest seems to involve trapping from the guest to the host, anyway, I don't see a downside to your patch. If that is ever changed (eg. allowing

Re: [PATCH 23/31] huge tmpfs recovery: framework for reconstituting huge pages

On Wed, 6 Apr 2016, Mika Penttila wrote: > On 04/06/2016 12:53 AM, Hugh Dickins wrote: > > +static void shmem_recovery_work(struct work_struct *work) ... > > + > > + if (head) { > > + /* We are resuming work from a previous partial recovery */ > > + if (PageTeam(page)) > > +

Re: [PATCH 23/31] huge tmpfs recovery: framework for reconstituting huge pages

On Wed, 6 Apr 2016, Mika Penttila wrote: > On 04/06/2016 12:53 AM, Hugh Dickins wrote: > > +static void shmem_recovery_work(struct work_struct *work) ... > > + > > + if (head) { > > + /* We are resuming work from a previous partial recovery */ > > + if (PageTeam(page)) > > +

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, 7 Apr 2016, Ming Lei wrote: > On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler > wrote: > > On Wed, 6 Apr 2016, Ming Lei wrote: > > > >> After arbitrary bio size is supported, the incoming bio may > >> be very big. We have to split the bio into small bios so that

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, 7 Apr 2016, Ming Lei wrote: > On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler > wrote: > > On Wed, 6 Apr 2016, Ming Lei wrote: > > > >> After arbitrary bio size is supported, the incoming bio may > >> be very big. We have to split the bio into small bios so that > >> each holds at most

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler wrote: > On Wed, 6 Apr 2016, Ming Lei wrote: > >> After arbitrary bio size is supported, the incoming bio may >> be very big. We have to split the bio into small bios so that >> each holds at most BIO_MAX_PAGES bvecs for

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler wrote: > On Wed, 6 Apr 2016, Ming Lei wrote: > >> After arbitrary bio size is supported, the incoming bio may >> be very big. We have to split the bio into small bios so that >> each holds at most BIO_MAX_PAGES bvecs for safety reason, such >> as

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Wed, 6 Apr 2016, Ming Lei wrote: > On Wed, Apr 6, 2016 at 1:44 AM, Ming Lei wrote: > > After arbitrary bio size is supported, the incoming bio may > > be very big. We have to split the bio into small bios so that > > each holds at most BIO_MAX_PAGES bvecs for safety

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Wed, 6 Apr 2016, Ming Lei wrote: > On Wed, Apr 6, 2016 at 1:44 AM, Ming Lei wrote: > > After arbitrary bio size is supported, the incoming bio may > > be very big. We have to split the bio into small bios so that > > each holds at most BIO_MAX_PAGES bvecs for safety reason, such > > as

[PATCH v2 net-next 01/10] perf: optimize perf_fetch_caller_regs

avoid memset in perf_fetch_caller_regs, since it's the critical path of all tracepoints. It's called from perf_sw_event_sched, perf_event_task_sched_in and all of perf_trace_##call with this_cpu_ptr(&__perf_regs[..]) which are zero initialized by perpcu init logic and subsequent call to

[PATCH v2 net-next 01/10] perf: optimize perf_fetch_caller_regs

avoid memset in perf_fetch_caller_regs, since it's the critical path of all tracepoints. It's called from perf_sw_event_sched, perf_event_task_sched_in and all of perf_trace_##call with this_cpu_ptr(&__perf_regs[..]) which are zero initialized by perpcu init logic and subsequent call to

[PATCH v2 net-next 04/10] perf, bpf: allow bpf programs attach to tracepoints

introduce BPF_PROG_TYPE_TRACEPOINT program type and allow it to be attached to the perf tracepoint handler, which will copy the arguments into the per-cpu buffer and pass it to the bpf program as its first argument. The layout of the fields can be discovered by doing 'cat

[PATCH v2 net-next 04/10] perf, bpf: allow bpf programs attach to tracepoints

introduce BPF_PROG_TYPE_TRACEPOINT program type and allow it to be attached to the perf tracepoint handler, which will copy the arguments into the per-cpu buffer and pass it to the bpf program as its first argument. The layout of the fields can be discovered by doing 'cat

[PATCH v2 net-next 00/10] allow bpf attach to tracepoints

Hi Steven, Peter, v1->v2: addressed Peter's comments: - fixed wording in patch 1, added ack - refactored 2nd patch into 3: 2/10 remove unused __perf_addr macro which frees up an argument in perf_trace_buf_submit 3/10 split perf_trace_buf_prepare into alloc and update parts, so that bpf programs

[PATCH v2 net-next 02/10] perf: remove unused __addr variable

now all calls to perf_trace_buf_submit() pass 0 as 4th argument which will be repurposed in the next patch which will change the meaning of 1st arg of perf_tp_event() to event_type Signed-off-by: Alexei Starovoitov --- include/trace/perf.h | 7 ++-

[PATCH v2 net-next 00/10] allow bpf attach to tracepoints

Hi Steven, Peter, v1->v2: addressed Peter's comments: - fixed wording in patch 1, added ack - refactored 2nd patch into 3: 2/10 remove unused __perf_addr macro which frees up an argument in perf_trace_buf_submit 3/10 split perf_trace_buf_prepare into alloc and update parts, so that bpf programs

[PATCH v2 net-next 02/10] perf: remove unused __addr variable

now all calls to perf_trace_buf_submit() pass 0 as 4th argument which will be repurposed in the next patch which will change the meaning of 1st arg of perf_tp_event() to event_type Signed-off-by: Alexei Starovoitov --- include/trace/perf.h | 7 ++- include/trace/trace_events.h | 3

[PATCH v2 net-next 03/10] perf: split perf_trace_buf_prepare into alloc and update parts

split allows to move expensive update of 'struct trace_entry' to later phase. Repurpose unused 1st argument of perf_tp_event() to indicate event type. While splitting use temp variable 'rctx' instead of '*rctx' to avoid unnecessary loads done by the compiler due to -fno-strict-aliasing

[PATCH v2 net-next 08/10] samples/bpf: add tracepoint support to bpf loader

Recognize "tracepoint/" section name prefix and attach the program to that tracepoint. Signed-off-by: Alexei Starovoitov --- samples/bpf/bpf_load.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/samples/bpf/bpf_load.c

[PATCH v2 net-next 10/10] samples/bpf: add tracepoint vs kprobe performance tests

the first microbenchmark does fd=open("/proc/self/comm"); for() { write(fd, "test"); } and on 4 cpus in parallel: writes per sec base (no tracepoints, no kprobes) 930k with kprobe at __set_task_comm() 420k with tracepoint at task:task_rename

[PATCH v2 net-next 06/10] bpf: support bpf_get_stackid() and bpf_perf_event_output() in tracepoint programs

needs two wrapper functions to fetch 'struct pt_regs *' to convert tracepoint bpf context into kprobe bpf context to reuse existing helper functions Signed-off-by: Alexei Starovoitov --- include/linux/bpf.h | 1 + kernel/bpf/stackmap.c| 2 +- kernel/trace/bpf_trace.c

[PATCH v2 net-next 03/10] perf: split perf_trace_buf_prepare into alloc and update parts

split allows to move expensive update of 'struct trace_entry' to later phase. Repurpose unused 1st argument of perf_tp_event() to indicate event type. While splitting use temp variable 'rctx' instead of '*rctx' to avoid unnecessary loads done by the compiler due to -fno-strict-aliasing

[PATCH v2 net-next 08/10] samples/bpf: add tracepoint support to bpf loader

Recognize "tracepoint/" section name prefix and attach the program to that tracepoint. Signed-off-by: Alexei Starovoitov --- samples/bpf/bpf_load.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c

[PATCH v2 net-next 10/10] samples/bpf: add tracepoint vs kprobe performance tests

the first microbenchmark does fd=open("/proc/self/comm"); for() { write(fd, "test"); } and on 4 cpus in parallel: writes per sec base (no tracepoints, no kprobes) 930k with kprobe at __set_task_comm() 420k with tracepoint at task:task_rename

[PATCH v2 net-next 06/10] bpf: support bpf_get_stackid() and bpf_perf_event_output() in tracepoint programs

needs two wrapper functions to fetch 'struct pt_regs *' to convert tracepoint bpf context into kprobe bpf context to reuse existing helper functions Signed-off-by: Alexei Starovoitov --- include/linux/bpf.h | 1 + kernel/bpf/stackmap.c| 2 +- kernel/trace/bpf_trace.c | 42

[PATCH v2 net-next 07/10] bpf: sanitize bpf tracepoint access

during bpf program loading remember the last byte of ctx access and at the time of attaching the program to tracepoint check that the program doesn't access bytes beyond defined in tracepoint fields This also disallows access to __dynamic_array fields, but can be relaxed in the future.

[PATCH v2 net-next 07/10] bpf: sanitize bpf tracepoint access

during bpf program loading remember the last byte of ctx access and at the time of attaching the program to tracepoint check that the program doesn't access bytes beyond defined in tracepoint fields This also disallows access to __dynamic_array fields, but can be relaxed in the future.

[PATCH v2 net-next 09/10] samples/bpf: tracepoint example

modify offwaketime to work with sched/sched_switch tracepoint instead of kprobe into finish_task_switch Signed-off-by: Alexei Starovoitov --- samples/bpf/offwaketime_kern.c | 26 ++ 1 file changed, 22 insertions(+), 4 deletions(-) diff --git

[PATCH v2 net-next 09/10] samples/bpf: tracepoint example

modify offwaketime to work with sched/sched_switch tracepoint instead of kprobe into finish_task_switch Signed-off-by: Alexei Starovoitov --- samples/bpf/offwaketime_kern.c | 26 ++ 1 file changed, 22 insertions(+), 4 deletions(-) diff --git

[PATCH v2 net-next 05/10] bpf: register BPF_PROG_TYPE_TRACEPOINT program type

register tracepoint bpf program type and let it call the same set of helper functions as BPF_PROG_TYPE_KPROBE Signed-off-by: Alexei Starovoitov --- kernel/trace/bpf_trace.c | 45 +++-- 1 file changed, 43 insertions(+), 2 deletions(-)

[PATCH v2 net-next 05/10] bpf: register BPF_PROG_TYPE_TRACEPOINT program type

register tracepoint bpf program type and let it call the same set of helper functions as BPF_PROG_TYPE_KPROBE Signed-off-by: Alexei Starovoitov --- kernel/trace/bpf_trace.c | 45 +++-- 1 file changed, 43 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] mmc: Remove some redundant debug prints

On 04/06/2016 08:57 PM, Jisheng Zhang wrote: > > > On Wed, 6 Apr 2016 19:38:30 +0800 Baolin Wang wrote: > >> This patch removes some redundant debug prints, since we have added some >> tracepoints to help with performance analysis of MMC subsystem. > > I think the debug prints you removed are

Re: [PATCH] mmc: Remove some redundant debug prints

On 04/06/2016 08:57 PM, Jisheng Zhang wrote: > > > On Wed, 6 Apr 2016 19:38:30 +0800 Baolin Wang wrote: > >> This patch removes some redundant debug prints, since we have added some >> tracepoints to help with performance analysis of MMC subsystem. > > I think the debug prints you removed are

Re: [PATCH v10 00/17] Add ACPI support for Xen Dom0 on ARM64

Hi Julien, On 2016/4/6 19:32, Julien Grall wrote: > Hi Shannon, > > On 01/04/2016 16:48, Shannon Zhao wrote: >> This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen >> ACPI on ARM64 design document could be found from [1]. >> >> This patch set adds a new FDT node "uefi" under

Re: [PATCH v10 00/17] Add ACPI support for Xen Dom0 on ARM64

Hi Julien, On 2016/4/6 19:32, Julien Grall wrote: > Hi Shannon, > > On 01/04/2016 16:48, Shannon Zhao wrote: >> This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen >> ACPI on ARM64 design document could be found from [1]. >> >> This patch set adds a new FDT node "uefi" under

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