Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support

On Mon 03-10-16 15:05:57, Ross Zwisler wrote: > > > @@ -623,22 +672,30 @@ static void *dax_insert_mapping_entry(struct > > > address_space *mapping, > > > error = radix_tree_preload(vmf->gfp_mask & ~__GFP_HIGHMEM); > > > if (error) > > > return

Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support

On Mon 03-10-16 15:05:57, Ross Zwisler wrote: > > > @@ -623,22 +672,30 @@ static void *dax_insert_mapping_entry(struct > > > address_space *mapping, > > > error = radix_tree_preload(vmf->gfp_mask & ~__GFP_HIGHMEM); > > > if (error) > > > return

[PATCH v2] phy: micrel.c: Enable ksz9031 energy-detect power-down mode

Set bit 0 in register 1C.23 to enable the EDPD feature of the KSZ9031 PHY. This reduces power consumption when the link is down. Signed-off-by: Mike Looijmans --- v2: Unconditionally enable EDPD mode drivers/net/phy/micrel.c | 21 + 1 file changed,

[PATCH v2] phy: micrel.c: Enable ksz9031 energy-detect power-down mode

Set bit 0 in register 1C.23 to enable the EDPD feature of the KSZ9031 PHY. This reduces power consumption when the link is down. Signed-off-by: Mike Looijmans --- v2: Unconditionally enable EDPD mode drivers/net/phy/micrel.c | 21 + 1 file changed, 21 insertions(+) diff

[GIT PULL] EDAC queue for 4.9

Hi Linus, a lot of movement in the EDAC tree this time around, coarse changelog below. Please pull, thanks. --- The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at:

[GIT PULL] EDAC queue for 4.9

Hi Linus, a lot of movement in the EDAC tree this time around, coarse changelog below. Please pull, thanks. --- The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at:

[PATCH 09/12] scsi/ncr5380: Pass hostdata pointer to register polling routines

Pass a NCR5380_hostdata struct pointer to the board-specific routines instead of a Scsi_Host struct pointer. This reduces pointer chasing in the PIO and PDMA fast paths. The old way was a mistake because it is slow and the board-specific code is not concerned with the mid-layer. Signed-off-by:

[PATCH 07/12] scsi/ncr5380: Store IO ports and addresses in host private data

The various 5380 drivers inconsistently store register pointers either in the Scsi_Host struct "legacy crap" area or in special, board-specific members of the NCR5380_hostdata struct. Uniform use of the latter struct makes for simpler and faster code (see the following patches) and helps to reduce

[PATCH 05/12] scsi/ncr5380: Increase register polling limit

If NCR5380_poll_politely() is called under irq lock, the polling time limit is clamped to avoid a spike in interrupt latency. When not under irq lock, the same polling time limit acts as the worst case delay between schedule() calls. During PDMA (under irq lock) I've found that the 10 ms time

[PATCH 06/12] scsi/ncr5380: Improve hostdata struct member alignment and cache-ability

Re-order struct members so that hot data lies at the beginning of the struct and cold data at the end. Improve the comments while we're here. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.h | 40 1 file changed, 20

[PATCH 05/12] scsi/ncr5380: Increase register polling limit

If NCR5380_poll_politely() is called under irq lock, the polling time limit is clamped to avoid a spike in interrupt latency. When not under irq lock, the same polling time limit acts as the worst case delay between schedule() calls. During PDMA (under irq lock) I've found that the 10 ms time

[PATCH 06/12] scsi/ncr5380: Improve hostdata struct member alignment and cache-ability

Re-order struct members so that hot data lies at the beginning of the struct and cold data at the end. Improve the comments while we're here. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.h | 40 1 file changed, 20 insertions(+), 20 deletions(-)

[PATCH 09/12] scsi/ncr5380: Pass hostdata pointer to register polling routines

Pass a NCR5380_hostdata struct pointer to the board-specific routines instead of a Scsi_Host struct pointer. This reduces pointer chasing in the PIO and PDMA fast paths. The old way was a mistake because it is slow and the board-specific code is not concerned with the mid-layer. Signed-off-by:

[PATCH 07/12] scsi/ncr5380: Store IO ports and addresses in host private data

The various 5380 drivers inconsistently store register pointers either in the Scsi_Host struct "legacy crap" area or in special, board-specific members of the NCR5380_hostdata struct. Uniform use of the latter struct makes for simpler and faster code (see the following patches) and helps to reduce

[PATCH 02/12] scsi/cumana_1: Remove unused cumanascsi_setup() function

Signed-off-by: Finn Thain --- drivers/scsi/arm/cumana_1.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/scsi/arm/cumana_1.c b/drivers/scsi/arm/cumana_1.c index 8e9cfe8..f616756 100644 --- a/drivers/scsi/arm/cumana_1.c +++ b/drivers/scsi/arm/cumana_1.c

[PATCH 00/12] Fixes, cleanup and g_NCR5380_mmio/g_NCR5380 merger

This patch series has fixes for compatibility, reliability and performance issues and some cleanup. It also includes a new version of Ondrej Zary's patch that merges g_NCR5380_mmio into g_NCR5380. I've tested this patch series on a Powerbook 180. If someone would test some of the other platforms

[PATCH 08/12] scsi/ncr5380: Use correct types for device register accessors

For timeout values adopt unsigned long, which is the type of jiffies etc. For chip register values and bit masks pass u8, which is the return type of readb, inb etc. For device register offsets adopt unsigned int, as it is suitable for adding to base addresses. Pass the NCR5380_hostdata pointer

[PATCH 11/12] scsi/ncr5380: Use correct types for DMA routines

Apply prototypes to get consistent function signatures for the DMA functions implemented in the board-specific drivers. To avoid using macros to alter actual parameters, some of those functions are reworked slightly. This is a step toward the goal of passing the board-specific routines to the

[PATCH 08/12] scsi/ncr5380: Use correct types for device register accessors

For timeout values adopt unsigned long, which is the type of jiffies etc. For chip register values and bit masks pass u8, which is the return type of readb, inb etc. For device register offsets adopt unsigned int, as it is suitable for adding to base addresses. Pass the NCR5380_hostdata pointer

[PATCH 11/12] scsi/ncr5380: Use correct types for DMA routines

Apply prototypes to get consistent function signatures for the DMA functions implemented in the board-specific drivers. To avoid using macros to alter actual parameters, some of those functions are reworked slightly. This is a step toward the goal of passing the board-specific routines to the

[PATCH 02/12] scsi/cumana_1: Remove unused cumanascsi_setup() function

Signed-off-by: Finn Thain --- drivers/scsi/arm/cumana_1.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/scsi/arm/cumana_1.c b/drivers/scsi/arm/cumana_1.c index 8e9cfe8..f616756 100644 --- a/drivers/scsi/arm/cumana_1.c +++ b/drivers/scsi/arm/cumana_1.c @@ -33,10 +33,6 @@

[PATCH 00/12] Fixes, cleanup and g_NCR5380_mmio/g_NCR5380 merger

This patch series has fixes for compatibility, reliability and performance issues and some cleanup. It also includes a new version of Ondrej Zary's patch that merges g_NCR5380_mmio into g_NCR5380. I've tested this patch series on a Powerbook 180. If someone would test some of the other platforms

[PATCH 10/12] scsi/ncr5380: Expedite register polling

Avoid the call to NCR5380_poll_politely2() when possible. The call is easily short-circuited on the PIO fast path, using the inline wrapper. This requires that the NCR5380_read macro be made available before any #include "NCR5380.h" so a few declarations have to be moved too. Signed-off-by: Finn

[PATCH 12/12] scsi/ncr5380: Suppress unhelpful "interrupt without IRQ bit" message

If a NCR5380 host instance ends up on a shared interrupt line then this printk will be a problem. It is already a problem on some Mac models: when testing mac_scsi on a PowerBook 180 I found that PDMA transfers (but not PIO transfers) cause the message to be logged. These spurious interrupts

[PATCH 12/12] scsi/ncr5380: Suppress unhelpful "interrupt without IRQ bit" message

If a NCR5380 host instance ends up on a shared interrupt line then this printk will be a problem. It is already a problem on some Mac models: when testing mac_scsi on a PowerBook 180 I found that PDMA transfers (but not PIO transfers) cause the message to be logged. These spurious interrupts

[PATCH 10/12] scsi/ncr5380: Expedite register polling

Avoid the call to NCR5380_poll_politely2() when possible. The call is easily short-circuited on the PIO fast path, using the inline wrapper. This requires that the NCR5380_read macro be made available before any #include "NCR5380.h" so a few declarations have to be moved too. Signed-off-by: Finn

[PATCH 03/12] scsi/atari_scsi: Make device register accessors re-enterant

This patch fixes an old bug: accesses to device registers from the interrupt handler (after reselection, DMA completion etc.) could mess up a device register access elsewhere, if the latter takes place outside of an irq lock (during selection etc.). Signed-off-by: Finn Thain

[PATCH 03/12] scsi/atari_scsi: Make device register accessors re-enterant

This patch fixes an old bug: accesses to device registers from the interrupt handler (after reselection, DMA completion etc.) could mess up a device register access elsewhere, if the latter takes place outside of an irq lock (during selection etc.). Signed-off-by: Finn Thain ---

[PATCH 04/12] scsi/ncr5380: Simplify register polling limit

When polling a device register under irq lock the polling loop terminates after a given number of jiffies. Make this timeout independent of the HZ setting. All 5380 drivers benefit from this patch, which optimizes the PIO fast path, because they all use PIO transfers (for phases other than DATA

[PATCH 01/12] scsi/g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio drivers

From: Ondrej Zary Merge the port-mapped IO and memory-mapped IO support (with the help of ioport_map) into the g_NCR5380 module and delete g_NCR5380_mmio. Signed-off-by: Ondrej Zary Signed-off-by: Finn Thain

[PATCH 01/12] scsi/g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio drivers

From: Ondrej Zary Merge the port-mapped IO and memory-mapped IO support (with the help of ioport_map) into the g_NCR5380 module and delete g_NCR5380_mmio. Signed-off-by: Ondrej Zary Signed-off-by: Finn Thain --- MAINTAINERS | 1 - drivers/scsi/Kconfig | 32

[PATCH 04/12] scsi/ncr5380: Simplify register polling limit

When polling a device register under irq lock the polling loop terminates after a given number of jiffies. Make this timeout independent of the HZ setting. All 5380 drivers benefit from this patch, which optimizes the PIO fast path, because they all use PIO transfers (for phases other than DATA

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

On Mon, Oct 03, 2016 at 03:48:36PM +0300, Jarkko Sakkinen wrote: > On Mon, Oct 03, 2016 at 07:05:48AM +, Winkler, Tomas wrote: > > > > > On Sun, Oct 02, 2016 at 01:24:55PM +0300, Jarkko Sakkinen wrote: > > > > On Sun, Oct 02, 2016 at 01:17:55PM +0300, Jarkko Sakkinen wrote: > > > > > On Sun,

Dearest Chosen One

Dearest Chosen One With Due Respect And Humanity,I was compelled to write to you under a humanitarian ground. My name is Mrs Amina Mohammed, My Husband was a director in a trading company here in Cote D Ivoire.We were married for 36 years without a child. He died after Cardiac Arteries

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

On Mon, Oct 03, 2016 at 03:48:36PM +0300, Jarkko Sakkinen wrote: > On Mon, Oct 03, 2016 at 07:05:48AM +, Winkler, Tomas wrote: > > > > > On Sun, Oct 02, 2016 at 01:24:55PM +0300, Jarkko Sakkinen wrote: > > > > On Sun, Oct 02, 2016 at 01:17:55PM +0300, Jarkko Sakkinen wrote: > > > > > On Sun,

Dearest Chosen One

Dearest Chosen One With Due Respect And Humanity,I was compelled to write to you under a humanitarian ground. My name is Mrs Amina Mohammed, My Husband was a director in a trading company here in Cote D Ivoire.We were married for 36 years without a child. He died after Cardiac Arteries

Re: [PATCH -resend 6/6] frv, mn10300, s390, sh: remove empty vga.h

On Mon, 3 Oct 2016 11:07:36 +0200 Jiri Slaby wrote: > Provided the architectures do not need any special handling (they seem > not to support vga at all, actually), there is no need to have an > empty vga.h. Let them refer to the generic one instead. > > Signed-off-by: Jiri

Re: [PATCH -resend 6/6] frv, mn10300, s390, sh: remove empty vga.h

On Mon, 3 Oct 2016 11:07:36 +0200 Jiri Slaby wrote: > Provided the architectures do not need any special handling (they seem > not to support vga at all, actually), there is no need to have an > empty vga.h. Let them refer to the generic one instead. > > Signed-off-by: Jiri Slaby > Cc: David

[PATCH 1/2 v3] pci-hyperv: properly handle pci bus remove

From: Long Li hv_pci_devices_present is called in hv_pci_remove when we remove a PCI device from host (e.g. by disabling SRIOV on a device). In hv_pci_remove, the bus is already removed before the call, so we don't need to rescan the bus in the workqueue scheduled from

[PATCH 1/2 v3] pci-hyperv: properly handle pci bus remove

From: Long Li hv_pci_devices_present is called in hv_pci_remove when we remove a PCI device from host (e.g. by disabling SRIOV on a device). In hv_pci_remove, the bus is already removed before the call, so we don't need to rescan the bus in the workqueue scheduled from hv_pci_devices_present.

[PATCH 2/2 v3] pci-hyperv: lock pci bus on device eject

From: Long Li A PCI_EJECT message can arrive at the same time we are calling pci_scan_child_bus in the workqueue for the previous PCI_BUS_RELATIONS message or in create_root_hv_pci_bus(), in this case we could potentailly modify the bus from multiple places. Properly

[PATCH 2/2 v3] pci-hyperv: lock pci bus on device eject

From: Long Li A PCI_EJECT message can arrive at the same time we are calling pci_scan_child_bus in the workqueue for the previous PCI_BUS_RELATIONS message or in create_root_hv_pci_bus(), in this case we could potentailly modify the bus from multiple places. Properly lock the bus access.

Re: [PATCH 14/15] staging: wlang-ng: fix line style warnings in prism2sta.c

El 2016年10月03日 a las 20:18, Joe Perches escribió: On Mon, 2016-10-03 at 20:12 +0200, Sergio Paracuellos wrote: El 2016年10月03日 a las 18:16, Joe Perches escribió: Perhaps better as hw->scanresults = kmemdup(inf, sizeof(*inf), GFP_ATOMIC); I agree. But because all the code is full of

Re: [PATCH 14/15] staging: wlang-ng: fix line style warnings in prism2sta.c

El 2016年10月03日 a las 20:18, Joe Perches escribió: On Mon, 2016-10-03 at 20:12 +0200, Sergio Paracuellos wrote: El 2016年10月03日 a las 18:16, Joe Perches escribió: Perhaps better as hw->scanresults = kmemdup(inf, sizeof(*inf), GFP_ATOMIC); I agree. But because all the code is full of

Re: [PATCH 2/3] zram: support page-based parallel write

Hello, Cc Jens and block-dev, I'll outline the commit message for Jens and blockdev people, may be someone will have some thoughts/ideas/opinions: > On (09/22/16 15:42), Minchan Kim wrote: : zram supports stream-based parallel compression. IOW, it can support : parallel compression on SMP

Re: [PATCH 2/3] zram: support page-based parallel write

Hello, Cc Jens and block-dev, I'll outline the commit message for Jens and blockdev people, may be someone will have some thoughts/ideas/opinions: > On (09/22/16 15:42), Minchan Kim wrote: : zram supports stream-based parallel compression. IOW, it can support : parallel compression on SMP

[PATCH 1/2] cgroup: Add generic cgroup subsystem permission checks

From: Colin Cross Rather than using explicit euid == 0 checks when trying to move tasks into a cgroup, move permission checks into each specific cgroup subsystem. If a subsystem does not specify a 'allow_attach' handler, then we fall back to doing the checks the old way.

[PATCH 1/2] cgroup: Add generic cgroup subsystem permission checks

From: Colin Cross Rather than using explicit euid == 0 checks when trying to move tasks into a cgroup, move permission checks into each specific cgroup subsystem. If a subsystem does not specify a 'allow_attach' handler, then we fall back to doing the checks the old way. This patch adds a

[PATCH 2/2] cgroup: Add a allow_attach policy for Android

From: Rom Lemarchand If CONFIG_CGROUP_NICE_ATTACH is enabled, this implements an allow_attach policy for Android, which allows any process with CAP_SYS_NICE to move tasks across cpuset and cpuctrl cgroups. This includes folded down fixes from: Dmitry Shmidt

[RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

As a heads up, this is just a first RFC and not a submission. I wanted to send this out again, as the last time I submitted this (https://marc.info/?l=linux-kernel=143217972215192=2) the discussion got out into the separate issue of how Android at one time abused memcg (but I believe now memcg is

[PATCH 2/2] cgroup: Add a allow_attach policy for Android

From: Rom Lemarchand If CONFIG_CGROUP_NICE_ATTACH is enabled, this implements an allow_attach policy for Android, which allows any process with CAP_SYS_NICE to move tasks across cpuset and cpuctrl cgroups. This includes folded down fixes from: Dmitry Shmidt Riley Andrews Amit Pundir

[RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

As a heads up, this is just a first RFC and not a submission. I wanted to send this out again, as the last time I submitted this (https://marc.info/?l=linux-kernel=143217972215192=2) the discussion got out into the separate issue of how Android at one time abused memcg (but I believe now memcg is

Re: [PATCH v1 1/2] ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid

Hello Stefan, On 16-10-03 11:05:59, Stefan Agner wrote: > On 2016-10-03 05:50, Sanchayan Maity wrote: > > Enable DMA for DSPI on Vybrid. > > Hm, we have that in 4.4 already, is that meant for 4.1? Sorry?! I send this out for mainline and the patch series is based on top of shawn's for-next

Re: [PATCH v1 1/2] ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid

Hello Stefan, On 16-10-03 11:05:59, Stefan Agner wrote: > On 2016-10-03 05:50, Sanchayan Maity wrote: > > Enable DMA for DSPI on Vybrid. > > Hm, we have that in 4.4 already, is that meant for 4.1? Sorry?! I send this out for mainline and the patch series is based on top of shawn's for-next

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

CC Michal. It looks like a microblaze specific error. I'll blacklist this old error on microblaze if there are no good solutions. Sorry for the noise! On Fri, Sep 23, 2016 at 05:11:32PM -0400, Nicolas Pitre wrote: On Thu, 22 Sep 2016, kbuild test robot wrote: Hi Nicolas, FYI, the

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

CC Michal. It looks like a microblaze specific error. I'll blacklist this old error on microblaze if there are no good solutions. Sorry for the noise! On Fri, Sep 23, 2016 at 05:11:32PM -0400, Nicolas Pitre wrote: On Thu, 22 Sep 2016, kbuild test robot wrote: Hi Nicolas, FYI, the

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

Peter Zijlstra writes: > On Mon, Oct 03, 2016 at 03:29:32PM +0200, Jiri Olsa wrote: >> On Fri, Sep 23, 2016 at 06:37:47PM +0200, Peter Zijlstra wrote: >> > On Wed, Sep 21, 2016 at 03:55:34PM +0200, Jiri Olsa wrote: >> > > stack backtrace: >> > > CPU: 9 PID: 2998 Comm:

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

Peter Zijlstra writes: > On Mon, Oct 03, 2016 at 03:29:32PM +0200, Jiri Olsa wrote: >> On Fri, Sep 23, 2016 at 06:37:47PM +0200, Peter Zijlstra wrote: >> > On Wed, Sep 21, 2016 at 03:55:34PM +0200, Jiri Olsa wrote: >> > > stack backtrace: >> > > CPU: 9 PID: 2998 Comm: ls Tainted: GW

Re: [PATCH 05/12] ASoC: sun4i-codec: Add support for A31 playback through headphone output

On Mon, Oct 3, 2016 at 7:47 PM, Maxime Ripard wrote: > Hi, > > On Mon, Oct 03, 2016 at 07:07:57PM +0800, Chen-Yu Tsai wrote: >> The A31 has a similar codec to the A10/A20. The PCM parts are very >> similar, with just different register offsets. The analog paths

Re: [PATCH 05/12] ASoC: sun4i-codec: Add support for A31 playback through headphone output

On Mon, Oct 3, 2016 at 7:47 PM, Maxime Ripard wrote: > Hi, > > On Mon, Oct 03, 2016 at 07:07:57PM +0800, Chen-Yu Tsai wrote: >> The A31 has a similar codec to the A10/A20. The PCM parts are very >> similar, with just different register offsets. The analog paths are >> very different. There are

Re: linux-next: Tree for Oct 4

Hi all, On Tue, 4 Oct 2016 14:56:49 +1100 Stephen Rothwell <s...@canb.auug.org.au> wrote: > > There will be no linux-next release on Friday. > > Changes since 20161003: I forgot to say: Please do *not* add any v4.10 material to your linux-next included trees until v4.9-rc1

Re: linux-next: Tree for Oct 4

Hi all, On Tue, 4 Oct 2016 14:56:49 +1100 Stephen Rothwell wrote: > > There will be no linux-next release on Friday. > > Changes since 20161003: I forgot to say: Please do *not* add any v4.10 material to your linux-next included trees until v4.9-rc1 has been released i.e. the

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Mon, Oct 3, 2016 at 9:07 PM, Andrew Morton wrote: > > Well, it's a VM_BUG_ON and few people run with CONFIG_DEBUG_VM. Ehh. If by "few people" you mean "pretty much everybody", you'd be right, but your choice of wording would be somewhat misleading, wouldn't you say?

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Mon, Oct 3, 2016 at 9:07 PM, Andrew Morton wrote: > > Well, it's a VM_BUG_ON and few people run with CONFIG_DEBUG_VM. Ehh. If by "few people" you mean "pretty much everybody", you'd be right, but your choice of wording would be somewhat misleading, wouldn't you say? Hint: here's a line from

[PATCHv1] hwmon: adm9240: handle temperature readings below 0

Unlike the temperature thresholds the temperature data is a 9-bit signed value. This allows and additional 0.5 degrees of precision on the reading but means we can't rely on sign-extension to handle negative values. Signed-off-by: Chris Packham ---

[PATCHv1] hwmon: adm9240: handle temperature readings below 0

Unlike the temperature thresholds the temperature data is a 9-bit signed value. This allows and additional 0.5 degrees of precision on the reading but means we can't rely on sign-extension to handle negative values. Signed-off-by: Chris Packham --- drivers/hwmon/adm9240.c | 19

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

Jiri Olsa writes: > The trinity syscall fuzzer triggered following WARN on powerpc: > WARNING: CPU: 9 PID: 2998 at arch/powerpc/kernel/hw_breakpoint.c:278 > ... > NIP [c093aedc] .hw_breakpoint_handler+0x28c/0x2b0 > LR [c093aed8]

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

Jiri Olsa writes: > The trinity syscall fuzzer triggered following WARN on powerpc: > WARNING: CPU: 9 PID: 2998 at arch/powerpc/kernel/hw_breakpoint.c:278 > ... > NIP [c093aedc] .hw_breakpoint_handler+0x28c/0x2b0 > LR [c093aed8] .hw_breakpoint_handler+0x288/0x2b0 > Call

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Mon, 3 Oct 2016 21:00:55 -0700 Linus Torvalds wrote: > In particular, I just got this > > kernel BUG at ./include/linux/swap.h:276 Well, it's a VM_BUG_ON and few people run with CONFIG_DEBUG_VM. But a) something's clearly wrong and b) points taken.

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Mon, 3 Oct 2016 21:00:55 -0700 Linus Torvalds wrote: > In particular, I just got this > > kernel BUG at ./include/linux/swap.h:276 Well, it's a VM_BUG_ON and few people run with CONFIG_DEBUG_VM. But a) something's clearly wrong and b) points taken.

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

As I stated before, I can't reproduce this. Please check your toolchain. It apparently throws segmentation faults. On Sun, 2 Oct 2016, kbuild test robot wrote: > Hi Nicolas, > > FYI, the error/warning still remains. > > tree:

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

As I stated before, I can't reproduce this. Please check your toolchain. It apparently throws segmentation faults. On Sun, 2 Oct 2016, kbuild test robot wrote: > Hi Nicolas, > > FYI, the error/warning still remains. > > tree:

BUG_ON() in workingset_node_shadows_dec() triggers

I'm really sorry I applied that last series from Andrew just before doing the 4.8 release, because they cause problems, and now it is in 4.8 (and that buggy crap is marked for stable too). In particular, I just got this kernel BUG at ./include/linux/swap.h:276 and the end result was a dead

BUG_ON() in workingset_node_shadows_dec() triggers

I'm really sorry I applied that last series from Andrew just before doing the 4.8 release, because they cause problems, and now it is in 4.8 (and that buggy crap is marked for stable too). In particular, I just got this kernel BUG at ./include/linux/swap.h:276 and the end result was a dead

linux-next: Tree for Oct 4

Hi all, There will be no linux-next release on Friday. Changes since 20161003: Non-merge commits (relative to Linus' tree): 12964 9515 files changed, 516789 insertions(+), 294462 deletions(-) I have created today's

linux-next: Tree for Oct 4

Hi all, There will be no linux-next release on Friday. Changes since 20161003: Non-merge commits (relative to Linus' tree): 12964 9515 files changed, 516789 insertions(+), 294462 deletions(-) I have created today's

[GIT PULL] regmap updates for v4.9

The following changes since commit c8d2bc9bc39ebea8437fd974fdbc21847bb897a3: Linux 4.8 (2016-10-02 16:24:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git tags/regmap-v4.9 for you to fetch changes up to

[GIT PULL] regmap updates for v4.9

The following changes since commit c8d2bc9bc39ebea8437fd974fdbc21847bb897a3: Linux 4.8 (2016-10-02 16:24:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git tags/regmap-v4.9 for you to fetch changes up to

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

On 10/3/16, Jeffrey Merkey wrote: > On 10/3/16, Joe Perches wrote: >> >> On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote: >>> Hi Joe, >> >> Hi Stephen. >> >>> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches wrote: >>> > >>> > On

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

On 10/3/16, Jeffrey Merkey wrote: > On 10/3/16, Joe Perches wrote: >> >> On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote: >>> Hi Joe, >> >> Hi Stephen. >> >>> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches wrote: >>> > >>> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote: >>>

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

Hi James, Please see inline, thanks for the reply: On Sat, 1 Oct 2016, James Chapman wrote: > On 30/09/16 03:39, R. Parameswaran wrote: > > > >>> + /* Adjust MTU, factor overhead - underlay L3 hdr, overlay L2 hdr*/ > >>> + if (tunnel->sock->sk_family == AF_INET) > >>> + overhead +=

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

Hi James, Please see inline, thanks for the reply: On Sat, 1 Oct 2016, James Chapman wrote: > On 30/09/16 03:39, R. Parameswaran wrote: > > > >>> + /* Adjust MTU, factor overhead - underlay L3 hdr, overlay L2 hdr*/ > >>> + if (tunnel->sock->sk_family == AF_INET) > >>> + overhead +=

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Mon, Oct 3, 2016 at 7:47 PM, Rik van Riel wrote: > On Mon, 2016-10-03 at 19:09 -0700, Andy Lutomirski wrote: > >> > Having two separate status booleans for "registers valid" >> > and "memory valid" may make more sense. >> >> I have no problem with the concept of "owner_ctx",

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Mon, Oct 3, 2016 at 7:47 PM, Rik van Riel wrote: > On Mon, 2016-10-03 at 19:09 -0700, Andy Lutomirski wrote: > >> > Having two separate status booleans for "registers valid" >> > and "memory valid" may make more sense. >> >> I have no problem with the concept of "owner_ctx", and I think it's a

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Oct 3, 2016 7:11 PM, "Rik van Riel" wrote: > > On Mon, 2016-10-03 at 14:36 -0700, Andy Lutomirski wrote: > > > > Anything else that tries to read task xstate from memory, i.e. MPX > > and > > PKRU. (Although if we switch to eager-switched PKRU, then PKRU stops > > mattering

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Oct 3, 2016 7:11 PM, "Rik van Riel" wrote: > > On Mon, 2016-10-03 at 14:36 -0700, Andy Lutomirski wrote: > > > > Anything else that tries to read task xstate from memory, i.e. MPX > > and > > PKRU. (Although if we switch to eager-switched PKRU, then PKRU stops > > mattering for this purpose.)

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

On 10/3/16, Joe Perches wrote: > > On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote: >> Hi Joe, > > Hi Stephen. > >> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches wrote: >> > >> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote: >> > > The

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

On 10/3/16, Joe Perches wrote: > > On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote: >> Hi Joe, > > Hi Stephen. > >> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches wrote: >> > >> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote: >> > > The following changes since commit >> > >

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Mon, 2016-10-03 at 19:09 -0700, Andy Lutomirski wrote: > > Having two separate status booleans for "registers valid" > > and "memory valid" may make more sense. > > I have no problem with the concept of "owner_ctx", and I think it's a > perfectly reasonable data structure.  My problem with it

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Mon, 2016-10-03 at 19:09 -0700, Andy Lutomirski wrote: > > Having two separate status booleans for "registers valid" > > and "memory valid" may make more sense. > > I have no problem with the concept of "owner_ctx", and I think it's a > perfectly reasonable data structure.  My problem with it

[PATCH 09/22] perf tools: Support CPU id matching for x86 v2

From: Andi Kleen Implement the code to match CPU types to mapfile types for x86 based on CPUID. This extends an existing similar function, but changes it to use the x86 mapfile cpu description. This allows to resolve event lists generated by jevents. Signed-off-by: Andi

Re: [PATCH 2/4] regulator: Enable compile testing for Maxim and Samsung PMIC drivers

On Sun, Oct 02, 2016 at 10:58:15PM +0200, Krzysztof Kozlowski wrote: > Most of Maxim and Samsung PMIC/MUIC regulator drivers can be compile > tested to increase build coverage. All these drivers already just depend on the MFDs which don't have any weird architecture dependencies - the main goal

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote: > Hi Joe, Hi Stephen. > On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches wrote: > > > > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote: > > > The following changes since commit > > >

[PATCH 09/22] perf tools: Support CPU id matching for x86 v2

From: Andi Kleen Implement the code to match CPU types to mapfile types for x86 based on CPUID. This extends an existing similar function, but changes it to use the x86 mapfile cpu description. This allows to resolve event lists generated by jevents. Signed-off-by: Andi Kleen Signed-off-by:

Re: [PATCH 2/4] regulator: Enable compile testing for Maxim and Samsung PMIC drivers

On Sun, Oct 02, 2016 at 10:58:15PM +0200, Krzysztof Kozlowski wrote: > Most of Maxim and Samsung PMIC/MUIC regulator drivers can be compile > tested to increase build coverage. All these drivers already just depend on the MFDs which don't have any weird architecture dependencies - the main goal

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote: > Hi Joe, Hi Stephen. > On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches wrote: > > > > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote: > > > The following changes since commit > > > c8d2bc9bc39ebea8437fd974fdbc21847bb897a3: >

[PATCH 17/22] perf list jevents: Add support for event list topics

From: Andi Kleen Add support to group the output of perf list by the Topic field in the JSON file. Example output: % perf list ... Cache: l1d.replacement [L1D data line replacements] l1d_pend_miss.pending [L1D miss oustandings duration in cycles]

[PATCH 07/22] perf pmu: Use pmu_events table to create aliases

From: Sukadev Bhattiprolu At run time (when 'perf' is starting up), locate the specific table of PMU events that corresponds to the current CPU. Using that table, create aliases for the each of the PMU events in the CPU. The use these aliases to parse the user

[PATCH 10/22] perf jevents: Handle header line in mapfile

From: Andi Kleen To work with existing mapfiles, assume that the first line in 'mapfile.csv' is a header line and skip over it. Signed-off-by: Sukadev Bhattiprolu Acked-by: Ingo Molnar Acked-by: Jiri Olsa

[PATCH 17/22] perf list jevents: Add support for event list topics

From: Andi Kleen Add support to group the output of perf list by the Topic field in the JSON file. Example output: % perf list ... Cache: l1d.replacement [L1D data line replacements] l1d_pend_miss.pending [L1D miss oustandings duration in cycles]

  1   2   3   4   5   6   7   8   9   10   >