[PATCH net 4/6] rxrpc: Once packet posted in data_ready, don't retry posting

Once a packet has been posted to a connection in the data_ready handler, we mustn't try reposting if we then find that the connection is dying as the refcount has been given over to the dying connection and the packet might no longer exist. Losing the packet isn't a problem as the peer will

[PATCH net 5/6] rxrpc: Fix a use-after-push in data_ready handler

Fix a use of a packet after it has been enqueued onto the packet processing queue in the data_ready handler. Once on a call's Rx queue, we mustn't touch it any more as it may be dequeued and freed by the call processor running on a work queue. Save the values we need before enqueuing. Without

[PATCH net 0/6] rxrpc: Miscellaneous fixes

to deal with. (*) Fix a missing skb free. --- The patches can be found here also: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes Tagged thusly: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-fixes-20160809

[PATCH net 2/6] rxrpc: Need to flag call as being released on connect failure

If rxrpc_new_client_call() fails to make a connection, the call record that it allocated needs to be marked as RXRPC_CALL_RELEASED before it is passed to rxrpc_put_call() to indicate that it no longer has any attachment to the AF_RXRPC socket. Without this, an assertion failure may occur at:

[PATCH net 1/6] rxrpc: fix uninitialized pointer dereference in debug code

From: Arnd Bergmann A newly added bugfix caused an uninitialized variable to be used for printing debug output. This is harmless as long as the debug setting is disabled, but otherwise leads to an immediate crash. gcc warns about this when -Wmaybe-uninitialized is enabled:

[PATCH net 0/6] rxrpc: Miscellaneous fixes

to deal with. (*) Fix a missing skb free. --- The patches can be found here also: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes Tagged thusly: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-fixes-20160809

[PATCH net 2/6] rxrpc: Need to flag call as being released on connect failure

If rxrpc_new_client_call() fails to make a connection, the call record that it allocated needs to be marked as RXRPC_CALL_RELEASED before it is passed to rxrpc_put_call() to indicate that it no longer has any attachment to the AF_RXRPC socket. Without this, an assertion failure may occur at:

[PATCH net 1/6] rxrpc: fix uninitialized pointer dereference in debug code

From: Arnd Bergmann A newly added bugfix caused an uninitialized variable to be used for printing debug output. This is harmless as long as the debug setting is disabled, but otherwise leads to an immediate crash. gcc warns about this when -Wmaybe-uninitialized is enabled:

[PATCH net 3/6] rxrpc: Don't access connection from call if pointer is NULL

The call state machine processor sets up the message parameters for a UDP message that it might need to transmit in advance on the basis that there's a very good chance it's going to have to transmit either an ACK or an ABORT. This requires it to look in the connection struct to retrieve some of

[PATCH net 3/6] rxrpc: Don't access connection from call if pointer is NULL

The call state machine processor sets up the message parameters for a UDP message that it might need to transmit in advance on the basis that there's a very good chance it's going to have to transmit either an ACK or an ABORT. This requires it to look in the connection struct to retrieve some of

Re: drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

On Tue, Aug 09, 2016 at 06:19:13PM +0200, Julia Lawall wrote: > Looks worth checking. I don't really have any idea what this is trying to tell me, sorry. > > julia > > -- Forwarded message -- > Date: Wed, 10 Aug 2016 00:17:07 +0800 > From: kbuild test robot

Re: drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

On Tue, Aug 09, 2016 at 06:19:13PM +0200, Julia Lawall wrote: > Looks worth checking. I don't really have any idea what this is trying to tell me, sorry. > > julia > > -- Forwarded message -- > Date: Wed, 10 Aug 2016 00:17:07 +0800 > From: kbuild test robot > To:

Re: [PATCH 1/2] of/irq: Mark interrupt controllers as populated before initialisation

On 09/08/16 15:18, Philipp Zabel wrote: > That way the init callback may clear the flag again, in case of drivers > split between early irq chip and a normal platform driver. > > Fixes: 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers as > populated") > Suggested-by: Rob Herring

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

On Tue, Aug 9, 2016 at 9:03 AM, Joerg Roedel wrote: > On Tue, Aug 09, 2016 at 09:00:04AM -0700, Thomas Garnier wrote: >> On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier wrote: >> > Initialize KASLR memory randomization after max_pfn is initialized. Also >> >

Re: [PATCH 1/2] of/irq: Mark interrupt controllers as populated before initialisation

On 09/08/16 15:18, Philipp Zabel wrote: > That way the init callback may clear the flag again, in case of drivers > split between early irq chip and a normal platform driver. > > Fixes: 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers as > populated") > Suggested-by: Rob Herring >

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

On Tue, Aug 9, 2016 at 9:03 AM, Joerg Roedel wrote: > On Tue, Aug 09, 2016 at 09:00:04AM -0700, Thomas Garnier wrote: >> On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier wrote: >> > Initialize KASLR memory randomization after max_pfn is initialized. Also >> > ensure the size is rounded up. Could

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

On Tue, Aug 09, 2016 at 12:05:43PM -0400, robert.f...@collabora.com wrote: > From: Sonny Rao > > This is based on earlier work by Thiago Goncales. It implements a new > per process proc file which summarizes the contents of the smaps file > but doesn't display any

Re: [PACTH v1] mm, proc: Implement /proc//totmaps

On Tue, Aug 09, 2016 at 12:05:43PM -0400, robert.f...@collabora.com wrote: > From: Sonny Rao > > This is based on earlier work by Thiago Goncales. It implements a new > per process proc file which summarizes the contents of the smaps file > but doesn't display any addresses. It gives more

Re: [PATCH] thp: move shmem_huge_enabled() outside of SYSFS ifdef

On Tue, Aug 09, 2016 at 02:36:02PM +0200, Arnd Bergmann wrote: > The newly introduced shmem_huge_enabled() function has two definitions, > but neither of them is visible if CONFIG_SYSFS is disabled, leading > to a build error: > > mm/khugepaged.o: In function `khugepaged': >

Re: [PATCH] rmap: Fix compound check logic in page_remove_file_rmap

On Tue, Aug 09, 2016 at 01:34:35PM +0100, Steve Capper wrote: > In page_remove_file_rmap(.) we have the following check: > VM_BUG_ON_PAGE(compound && !PageTransHuge(page), page); > > This is meant to check for either HugeTLB pages or THP when a compound > page is passed in. > > Unfortunately,

Re: [PATCH] thp: move shmem_huge_enabled() outside of SYSFS ifdef

On Tue, Aug 09, 2016 at 02:36:02PM +0200, Arnd Bergmann wrote: > The newly introduced shmem_huge_enabled() function has two definitions, > but neither of them is visible if CONFIG_SYSFS is disabled, leading > to a build error: > > mm/khugepaged.o: In function `khugepaged': >

Re: [PATCH] rmap: Fix compound check logic in page_remove_file_rmap

On Tue, Aug 09, 2016 at 01:34:35PM +0100, Steve Capper wrote: > In page_remove_file_rmap(.) we have the following check: > VM_BUG_ON_PAGE(compound && !PageTransHuge(page), page); > > This is meant to check for either HugeTLB pages or THP when a compound > page is passed in. > > Unfortunately,

[PATCH] NFC: pn533: constify pn533_phy_ops structures

The pn533_phy_ops are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/nfc/pn533/i2c.c |2 +- drivers/nfc/pn533/pn533.c |2 +- drivers/nfc/pn533/pn533.h |4 ++-- drivers/nfc/pn533/usb.c |

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Tue, Aug 9, 2016 at 9:18 AM, Rafael J. Wysocki wrote: > On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina wrote: >> On Tue, 9 Aug 2016, Thomas Garnier wrote: >> >>> >> Okay, I did one-by-one reverts, and the one above, i.e. >>> >> >>> >> commit

[PATCH] NFC: pn533: constify pn533_phy_ops structures

The pn533_phy_ops are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/nfc/pn533/i2c.c |2 +- drivers/nfc/pn533/pn533.c |2 +- drivers/nfc/pn533/pn533.h |4 ++-- drivers/nfc/pn533/usb.c |2 +- 4 files

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Tue, Aug 9, 2016 at 9:18 AM, Rafael J. Wysocki wrote: > On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina wrote: >> On Tue, 9 Aug 2016, Thomas Garnier wrote: >> >>> >> Okay, I did one-by-one reverts, and the one above, i.e. >>> >> >>> >> commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd >>> >>

Re: [PACTH v4 1/2] usb: xhci: plat: Enable runtime PM

Hi Robert, [auto build test WARNING on usb/usb-testing] [also build test WARNING on v4.8-rc1 next-20160809] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/robert-foss-collabora-com/usb-xhci

Re: [PACTH v4 1/2] usb: xhci: plat: Enable runtime PM

Hi Robert, [auto build test WARNING on usb/usb-testing] [also build test WARNING on v4.8-rc1 next-20160809] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/robert-foss-collabora-com/usb-xhci

Re: [PATCHv4 0/2] USB Type-C Connector class

On Tue, Aug 09, 2016 at 04:01:53PM +0200, Greg KH wrote: > On Wed, Jun 29, 2016 at 04:38:36PM +0300, Heikki Krogerus wrote: > > Hi, > > > > The USB Type-C class is meant to provide unified interface to the > > userspace to present the USB Type-C ports in a system. > > > > Changes since v3: > > -

Re: [PATCHv4 0/2] USB Type-C Connector class

On Tue, Aug 09, 2016 at 04:01:53PM +0200, Greg KH wrote: > On Wed, Jun 29, 2016 at 04:38:36PM +0300, Heikki Krogerus wrote: > > Hi, > > > > The USB Type-C class is meant to provide unified interface to the > > userspace to present the USB Type-C ports in a system. > > > > Changes since v3: > > -

Re: [PATCH 6/8] arm64: Introduce raw_{d,i}cache_line_size

Hi Suzuki, Sorry this fell through the cracks... On 08/07/16 12:37, Suzuki K Poulose wrote: > On systems with mismatched i/d cache min line sizes, we need to use > the smallest size possible across all CPUs. This will be done by fetching > the system wide safe value from CPU feature

Re: [PATCH 6/8] arm64: Introduce raw_{d,i}cache_line_size

Hi Suzuki, Sorry this fell through the cracks... On 08/07/16 12:37, Suzuki K Poulose wrote: > On systems with mismatched i/d cache min line sizes, we need to use > the smallest size possible across all CPUs. This will be done by fetching > the system wide safe value from CPU feature

Re: [PATCH v3] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

On Tue, 9 Aug 2016, Chris Wilson wrote: > With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a > kmem_cache_node is destroyed the call_rcu() may trigger a slab > allocation to fill the debug object pool (__debug_object_init:fill_pool). > Everywhere but during kmem_cache_destroy(),

Re: [PATCH v3] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

On Tue, 9 Aug 2016, Chris Wilson wrote: > With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a > kmem_cache_node is destroyed the call_rcu() may trigger a slab > allocation to fill the debug object pool (__debug_object_init:fill_pool). > Everywhere but during kmem_cache_destroy(),

[PATCH] [media] mtk-vcodec: constify venc_common_if structures

The venc_common_if structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h|2 +- drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c |6

[PATCH] [media] mtk-vcodec: constify venc_common_if structures

The venc_common_if structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h|2 +- drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c |6 +++---

drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

Looks worth checking. julia -- Forwarded message -- Date: Wed, 10 Aug 2016 00:17:07 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: drivers/spi/spi.c:1160:3-9: preceding lock on line 1153 CC:

drivers/spi/spi.c:1160:3-9: preceding lock on line 1153

Looks worth checking. julia -- Forwarded message -- Date: Wed, 10 Aug 2016 00:17:07 +0800 From: kbuild test robot To: kbu...@01.org Cc: Julia Lawall Subject: drivers/spi/spi.c:1160:3-9: preceding lock on line 1153 CC: kbuild-...@01.org CC: linux-kernel@vger.kernel.org TO: Mark

Re: [PATCH 4.6 00/96] 4.6.6-stable review

On Tue, Aug 09, 2016 at 10:37:31AM +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 09, 2016 at 09:33:26AM +0100, Paul Burton wrote: > > On 09/08/16 09:24, Greg Kroah-Hartman wrote: > > > On Mon, Aug 08, 2016 at 10:03:39PM -0700, Guenter Roeck wrote: > > > > On 08/08/2016 12:10 PM, Greg

Re: [PATCH 4.6 00/96] 4.6.6-stable review

On Tue, Aug 09, 2016 at 10:37:31AM +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 09, 2016 at 09:33:26AM +0100, Paul Burton wrote: > > On 09/08/16 09:24, Greg Kroah-Hartman wrote: > > > On Mon, Aug 08, 2016 at 10:03:39PM -0700, Guenter Roeck wrote: > > > > On 08/08/2016 12:10 PM, Greg

RE: [v11,3/3] Bluetooth: hci_uart: Support firmware download for Marvell

Hi Loic, > -Original Message- > From: Loic Poulain [mailto:loic.poul...@intel.com] > Sent: Thursday, June 30, 2016 4:24 PM > To: Amitkumar Karwar; Jeffy Chen; linux-blueto...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Cathy Luo; Marcel > Holtmann > Subject: Re:

RE: [v11,3/3] Bluetooth: hci_uart: Support firmware download for Marvell

Hi Loic, > -Original Message- > From: Loic Poulain [mailto:loic.poul...@intel.com] > Sent: Thursday, June 30, 2016 4:24 PM > To: Amitkumar Karwar; Jeffy Chen; linux-blueto...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Cathy Luo; Marcel > Holtmann > Subject: Re:

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina wrote: > On Tue, 9 Aug 2016, Thomas Garnier wrote: > >> >> Okay, I did one-by-one reverts, and the one above, i.e. >> >> >> >> commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd >> >> Author: Thomas Garnier

[RFC] mm: Don't use radix tree writeback tags for pages in swap cache

From: Huang Ying File pages uses a set of radix tags (DIRTY, TOWRITE, WRITEBACK) to accelerate finding the pages with the specific tag in the the radix tree during writing back an inode. But for anonymous pages in swap cache, there are no inode based writeback. So there

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Tue, Aug 9, 2016 at 5:05 PM, Jiri Kosina wrote: > On Tue, 9 Aug 2016, Thomas Garnier wrote: > >> >> Okay, I did one-by-one reverts, and the one above, i.e. >> >> >> >> commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd >> >> Author: Thomas Garnier >> >> Date: Tue Jun 21

[RFC] mm: Don't use radix tree writeback tags for pages in swap cache

From: Huang Ying File pages uses a set of radix tags (DIRTY, TOWRITE, WRITEBACK) to accelerate finding the pages with the specific tag in the the radix tree during writing back an inode. But for anonymous pages in swap cache, there are no inode based writeback. So there is no need to find the

Re: linux-next: please clean up the samsung-krzk tree

On Tue, Aug 09, 2016 at 09:55:05AM +1000, Stephen Rothwell wrote: > Hi Krzysztof, > > The samsung-krzk tree > (git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git#for-next) > contains just these: > > 253256f64294 Merge branch 'next/soc' into for-next > b148ebe425aa Merge branch

Re: linux-next: please clean up the samsung-krzk tree

On Tue, Aug 09, 2016 at 09:55:05AM +1000, Stephen Rothwell wrote: > Hi Krzysztof, > > The samsung-krzk tree > (git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git#for-next) > contains just these: > > 253256f64294 Merge branch 'next/soc' into for-next > b148ebe425aa Merge branch

Re: [PATCH] i2c: don't print error when adding adapter fails

Hi Wolfram, On 8/9/2016 4:36 AM, Wolfram Sang wrote: The core will do this for us now. Signed-off-by: Wolfram Sang [...] diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c index 19c843828fe2ca..8e3477f9297eda 100644 ---

Re: [PATCH] i2c: don't print error when adding adapter fails

Hi Wolfram, On 8/9/2016 4:36 AM, Wolfram Sang wrote: The core will do this for us now. Signed-off-by: Wolfram Sang [...] diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c index 19c843828fe2ca..8e3477f9297eda 100644 ---

Re: [PATCH v13 00/16] PCI: Fixup for 64bit resource with sparc

On Mon, Aug 8, 2016 at 12:49 PM, Bjorn Helgaas wrote: > On Fri, Jun 17, 2016 at 07:24:45PM -0700, Yinghai Lu wrote: > > Can you update these to apply to v4.8-rc1, and we can keep chipping > away at these? sure. will send rebased version shortly. Thanks Yinghai

Re: [PATCH v13 00/16] PCI: Fixup for 64bit resource with sparc

On Mon, Aug 8, 2016 at 12:49 PM, Bjorn Helgaas wrote: > On Fri, Jun 17, 2016 at 07:24:45PM -0700, Yinghai Lu wrote: > > Can you update these to apply to v4.8-rc1, and we can keep chipping > away at these? sure. will send rebased version shortly. Thanks Yinghai

Re: [PATCH 4.4 00/68] 4.4.17-stable review

On Tue, Aug 09, 2016 at 10:21:33AM +0200, Greg Kroah-Hartman wrote: > On Mon, Aug 08, 2016 at 09:22:24PM -0700, Guenter Roeck wrote: > > On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.4.17 release. > > > There are 68 patches in this

Re: [PATCH 4.4 00/68] 4.4.17-stable review

On Tue, Aug 09, 2016 at 10:21:33AM +0200, Greg Kroah-Hartman wrote: > On Mon, Aug 08, 2016 at 09:22:24PM -0700, Guenter Roeck wrote: > > On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.4.17 release. > > > There are 68 patches in this

Re: [RFC PATCH v7 1/7] Restartable sequences system call

On Wed, Aug 03, 2016 at 10:03:32PM -0700, Andy Lutomirski wrote: > On Wed, Aug 3, 2016 at 9:27 PM, Boqun Feng wrote: > > On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote: > >> On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra > >> wrote: >

Re: [RFC PATCH v7 1/7] Restartable sequences system call

On Wed, Aug 03, 2016 at 10:03:32PM -0700, Andy Lutomirski wrote: > On Wed, Aug 3, 2016 at 9:27 PM, Boqun Feng wrote: > > On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote: > >> On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra > >> wrote: > >> > On Tue, Jul 26, 2016 at 03:02:19AM

Re: "Failed to create /dev/root: -14" after commit e6978e4bf1 ("ARM: save and reset the address limit when entering an exception")

On Tue, Aug 09, 2016 at 05:06:51PM +0200, Gregory CLEMENT wrote: > Hi Russell King, > > On jeu., août 04 2016, Russell King - ARM Linux > wrote: > > > On Wed, Aug 03, 2016 at 08:07:02AM -0700, Guenter Roeck wrote: > >> On 08/03/2016 01:38 AM, Russell King - ARM Linux

Re: "Failed to create /dev/root: -14" after commit e6978e4bf1 ("ARM: save and reset the address limit when entering an exception")

On Tue, Aug 09, 2016 at 05:06:51PM +0200, Gregory CLEMENT wrote: > Hi Russell King, > > On jeu., août 04 2016, Russell King - ARM Linux > wrote: > > > On Wed, Aug 03, 2016 at 08:07:02AM -0700, Guenter Roeck wrote: > >> On 08/03/2016 01:38 AM, Russell King - ARM Linux wrote: > >> >On Tue, Aug

[PATCH v3] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a kmem_cache_node is destroyed the call_rcu() may trigger a slab allocation to fill the debug object pool (__debug_object_init:fill_pool). Everywhere but during kmem_cache_destroy(), discard_slab() is performed outside of the

Re: rtc regression [463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h")]

On Tuesday, August 9, 2016 6:56:49 PM CEST Ville Syrjälä wrote: > Hi, > > commit 463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h") > broke rtc for me. Neither hwclock or rtcwake work anymore. This is just > a very standard x86-64 IVB box, and it was reported that machines in > our

[PATCH v3] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a kmem_cache_node is destroyed the call_rcu() may trigger a slab allocation to fill the debug object pool (__debug_object_init:fill_pool). Everywhere but during kmem_cache_destroy(), discard_slab() is performed outside of the

Re: rtc regression [463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h")]

On Tuesday, August 9, 2016 6:56:49 PM CEST Ville Syrjälä wrote: > Hi, > > commit 463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h") > broke rtc for me. Neither hwclock or rtcwake work anymore. This is just > a very standard x86-64 IVB box, and it was reported that machines in > our

Re: tty/serial/8250: use mctrl_gpio helpers - Causes problems on ACPI systems

+Peter On Tue, 2016-08-09 at 16:02 +0300, Mika Westerberg wrote: > Hi, > > I noticed that with v4.8-rc1 serial console of some of our Broxton > systems does not work properly anymore. I'm able to see output but > input > does not work. > > I bisected it down to commit

Re: tty/serial/8250: use mctrl_gpio helpers - Causes problems on ACPI systems

+Peter On Tue, 2016-08-09 at 16:02 +0300, Mika Westerberg wrote: > Hi, > > I noticed that with v4.8-rc1 serial console of some of our Broxton > systems does not work properly anymore. I'm able to see output but > input > does not work. > > I bisected it down to commit

[PACTH v1] mm, proc: Implement /proc//totmaps

From: Sonny Rao This is based on earlier work by Thiago Goncales. It implements a new per process proc file which summarizes the contents of the smaps file but doesn't display any addresses. It gives more detailed information than statm like the PSS (proprotional set

[PACTH v1] mm, proc: Implement /proc//totmaps

From: Sonny Rao This is based on earlier work by Thiago Goncales. It implements a new per process proc file which summarizes the contents of the smaps file but doesn't display any addresses. It gives more detailed information than statm like the PSS (proprotional set size). It differs from the

[PATCH 01/11] perf script: Add 'bpf-output' field to usage message

From: Brendan Gregg This adds the 'bpf-output' field to the perf script usage message, and docs. Signed-off-by: Brendan Gregg Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Peter Zijlstra

[PATCH 09/11] tools: Sync cpufeatures headers with the kernel

From: Arnaldo Carvalho de Melo Due to: 1e61f78baf89 ("x86/cpufeature: Make sure DISABLED/REQUIRED macros are updated") No changes to tools using those headers (tools/arch/x86/lib/mem{set,cpu}_64.S) seems necessary. Detected by the tools build header drift checker: $

[PATCH 03/11] perf probe: Adjust map->reloc offset when finding kernel symbol from map

From: Masami Hiramatsu Adjust map->reloc offset for the unmapped address when finding alternative symbol address from map, because KASLR can relocate the kernel symbol address. The same adjustment has been done when finding appropriate kernel symbol address from map

[PATCH 01/11] perf script: Add 'bpf-output' field to usage message

From: Brendan Gregg This adds the 'bpf-output' field to the perf script usage message, and docs. Signed-off-by: Brendan Gregg Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Peter Zijlstra Cc: Wang Nan Link: http://lkml.kernel.org/r/1470192469-11910-4-git-send-email-bgr...@netflix.com

[PATCH 09/11] tools: Sync cpufeatures headers with the kernel

From: Arnaldo Carvalho de Melo Due to: 1e61f78baf89 ("x86/cpufeature: Make sure DISABLED/REQUIRED macros are updated") No changes to tools using those headers (tools/arch/x86/lib/mem{set,cpu}_64.S) seems necessary. Detected by the tools build header drift checker: $ make -C tools/perf

[PATCH 03/11] perf probe: Adjust map->reloc offset when finding kernel symbol from map

From: Masami Hiramatsu Adjust map->reloc offset for the unmapped address when finding alternative symbol address from map, because KASLR can relocate the kernel symbol address. The same adjustment has been done when finding appropriate kernel symbol address from map which was introduced by

[PATCH 08/11] toops: Sync tools/include/uapi/linux/bpf.h with the kernel

From: Arnaldo Carvalho de Melo The way we're using kernel headers in tools/ now, with a copy that is made to the same path prefixed by "tools/" plus checking if that copy got stale, i.e. if the kernel counterpart changed, helps in keeping track with new features that may be

[PATCH 11/11] perf probe ppc64le: Fix probe location when using DWARF

From: Ravi Bangoria Powerpc has Global Entry Point and Local Entry Point for functions. LEP catches call from both the GEP and the LEP. Symbol table of ELF contains GEP and Offset from which we can calculate LEP, but debuginfo does not have LEP info.

[PATCH 10/11] perf probe: Add function to post process kernel trace events

From: Ravi Bangoria Instead of inline code, introduce function to post process kernel probe trace events. Signed-off-by: Ravi Bangoria Acked-by: Masami Hiramatsu Cc: Alexander Shishkin

[PATCH 02/11] perf hists: Trim libtraceevent trace_seq buffers

From: Arnaldo Carvalho de Melo When we use libtraceevent to format trace event fields into printable strings to use in hist entries it is important to trim it from the default 4 KiB it starts with to what is really used, to reduce the memory footprint, so use realloc(seq.buffer,

[PATCH 05/11] perf stat: Avoid skew when reading events

From: Mark Rutland When we don't have a tracee (i.e. we're attaching to a task or CPU), counters can still be running after our workload finishes, and can still be running as we read their values. As we read events one-by-one, there can be arbitrary skew between values of

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

On Tue, Aug 09, 2016 at 09:00:04AM -0700, Thomas Garnier wrote: > On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier wrote: > > Initialize KASLR memory randomization after max_pfn is initialized. Also > > ensure the size is rounded up. Could have create problems on machines > >

[PATCH 11/11] perf probe ppc64le: Fix probe location when using DWARF

From: Ravi Bangoria Powerpc has Global Entry Point and Local Entry Point for functions. LEP catches call from both the GEP and the LEP. Symbol table of ELF contains GEP and Offset from which we can calculate LEP, but debuginfo does not have LEP info. Currently, perf prioritize symbol table

[PATCH 10/11] perf probe: Add function to post process kernel trace events

From: Ravi Bangoria Instead of inline code, introduce function to post process kernel probe trace events. Signed-off-by: Ravi Bangoria Acked-by: Masami Hiramatsu Cc: Alexander Shishkin Cc: Ananth N Mavinakayanahalli Cc: Balbir Singh Cc: Namhyung Kim Cc: Naveen N. Rao Cc: Peter Zijlstra

[PATCH 02/11] perf hists: Trim libtraceevent trace_seq buffers

From: Arnaldo Carvalho de Melo When we use libtraceevent to format trace event fields into printable strings to use in hist entries it is important to trim it from the default 4 KiB it starts with to what is really used, to reduce the memory footprint, so use realloc(seq.buffer, seq.len + 1)

[PATCH 05/11] perf stat: Avoid skew when reading events

From: Mark Rutland When we don't have a tracee (i.e. we're attaching to a task or CPU), counters can still be running after our workload finishes, and can still be running as we read their values. As we read events one-by-one, there can be arbitrary skew between values of events, even within a

Re: [PATCH v1 1/2] x86/KASLR: Fix physical memory calculation on KASLR memory randomization

On Tue, Aug 09, 2016 at 09:00:04AM -0700, Thomas Garnier wrote: > On Mon, Aug 8, 2016 at 11:40 AM, Thomas Garnier wrote: > > Initialize KASLR memory randomization after max_pfn is initialized. Also > > ensure the size is rounded up. Could have create problems on machines > > with more than 1Tb of

[PATCH 08/11] toops: Sync tools/include/uapi/linux/bpf.h with the kernel

From: Arnaldo Carvalho de Melo The way we're using kernel headers in tools/ now, with a copy that is made to the same path prefixed by "tools/" plus checking if that copy got stale, i.e. if the kernel counterpart changed, helps in keeping track with new features that may be useful for tools to

[PATCH 07/11] tools: Sync cpufeatures.h and vmx.h with the kernel

From: Arnaldo Carvalho de Melo There were changes related to the deprecation of the "pcommit" instruction: fd1d961dd681 ("x86/insn: remove pcommit") dfa169bbee00 ("Revert "KVM: x86: add pcommit support"") No need to update anything in the tools, as "pcommit" wasn't being

[PATCH 07/11] tools: Sync cpufeatures.h and vmx.h with the kernel

From: Arnaldo Carvalho de Melo There were changes related to the deprecation of the "pcommit" instruction: fd1d961dd681 ("x86/insn: remove pcommit") dfa169bbee00 ("Revert "KVM: x86: add pcommit support"") No need to update anything in the tools, as "pcommit" wasn't being listed on the

Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support

[Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support] On 08/08/2016 (Mon 13:44) Moritz Fischer wrote: > Hi Alan, > > On Mon, Aug 8, 2016 at 12:18 PM, atull wrote: > > >> Please don't use module.h in drivers controlled by a bool > >> Kconfig setting. > >>

Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support

[Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support] On 08/08/2016 (Mon 13:44) Moritz Fischer wrote: > Hi Alan, > > On Mon, Aug 8, 2016 at 12:18 PM, atull wrote: > > >> Please don't use module.h in drivers controlled by a bool > >> Kconfig setting. > >> > >> THanks, > >> Paul. > >>

[PATCH 06/11] perf probe: Support signedness casting

From: Naohiro Aota The 'perf probe' tool detects a variable's type and use the detected type to add a new probe. Then, kprobes prints its variable in hexadecimal format if the variable is unsigned and prints in decimal if it is signed. We sometimes want to see unsigned

[GIT PULL 00/11] perf/urgent fixes

/linux into perf/urgent (2016-08-04 11:02:38 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-20160809 for you to fetch changes up to 99e608b5954c9e1ebadbf9660b74697d9dfd9f20: perf probe ppc64le: Fix probe

[PATCH 06/11] perf probe: Support signedness casting

From: Naohiro Aota The 'perf probe' tool detects a variable's type and use the detected type to add a new probe. Then, kprobes prints its variable in hexadecimal format if the variable is unsigned and prints in decimal if it is signed. We sometimes want to see unsigned variable in decimal

[GIT PULL 00/11] perf/urgent fixes

/linux into perf/urgent (2016-08-04 11:02:38 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-20160809 for you to fetch changes up to 99e608b5954c9e1ebadbf9660b74697d9dfd9f20: perf probe ppc64le: Fix probe

[PATCH 04/11] perf probe: Fix module name matching

From: Konstantin Khlebnikov If module is "module" then dso->short_name is "[module]". Substring comparing is't enough: "raid10" matches to "[raid1]". This patch also checks terminating zero in module name. Signed-off-by: Konstantin Khlebnikov

[PATCH 04/11] perf probe: Fix module name matching

From: Konstantin Khlebnikov If module is "module" then dso->short_name is "[module]". Substring comparing is't enough: "raid10" matches to "[raid1]". This patch also checks terminating zero in module name. Signed-off-by: Konstantin Khlebnikov Acked-by: Masami Hiramatsu Link:

Re: [Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

On 09/08/16 03:59, Dave Airlie wrote: On 8 August 2016 at 19:40, Daniel Vetter wrote: On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote: Hello there, Recent versions of gcc say this: include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ requires 37

Re: [Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

On 09/08/16 03:59, Dave Airlie wrote: On 8 August 2016 at 19:40, Daniel Vetter wrote: On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote: Hello there, Recent versions of gcc say this: include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’ requires 37 bits to represent,

[PATCH] dm9000: Fix irq trigger type setup on non-dt platforms

Commit b5a099c67a1c36b "net: ethernet: davicom: fix devicetree irq resource" causes an interrupt storm after the ethernet interface is activated on S3C24XX platform (ARM non-dt), due to the interrupt trigger type not being set properly. It seems, after adding parsing of IRQ flags in commit

[PATCH] dm9000: Fix irq trigger type setup on non-dt platforms

Commit b5a099c67a1c36b "net: ethernet: davicom: fix devicetree irq resource" causes an interrupt storm after the ethernet interface is activated on S3C24XX platform (ARM non-dt), due to the interrupt trigger type not being set properly. It seems, after adding parsing of IRQ flags in commit

[PATCH] fmc: constify fmc_operations structure

The fmc_operations structure is never modified, so declare is as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/fmc/fmc-fakedev.c |2 +- include/linux/fmc.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff

[PATCH] fmc: constify fmc_operations structure

The fmc_operations structure is never modified, so declare is as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/fmc/fmc-fakedev.c |2 +- include/linux/fmc.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

<    4   5   6   7   8   9   10   11   12   13   >