Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff

On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote: > Thanks for the patch! I applied the patch on top of "locking/ww_mutex: > Add kselftests for ww_mutex stress", and find no "bad unlock balance > detected" but this warning. Attached is the new dmesg which is a bit > large due to lots

Re: [PATCH v2 1/3] coresight: bindings for debug module

On Tue, Feb 28, 2017 at 11:06:58PM +0800, Leo Yan wrote: > According to ARMv8 architecture reference manual (ARM DDI 0487A.k) > Chapter 'Part H: External debug', the CPU can integrate debug module > and it can support self-hosted debug and external debug. Especially > for supporting self-hosted

Re: [PATCH 6/9] mm: don't avoid high-priority reclaim on memcg limit reclaim

On Tue 28-02-17 16:40:04, Johannes Weiner wrote: > 246e87a93934 ("memcg: fix get_scan_count() for small targets") sought > to avoid high reclaim priorities for memcg by forcing it to scan a > minimum amount of pages when lru_pages >> priority yielded nothing. > This was done at a time when reclaim

Re: [PATCH 5/9] mm: don't avoid high-priority reclaim on unreclaimable nodes

On Tue 28-02-17 16:40:03, Johannes Weiner wrote: > 246e87a93934 ("memcg: fix get_scan_count() for small targets") sought > to avoid high reclaim priorities for kswapd by forcing it to scan a > minimum amount of pages when lru_pages >> priority yielded nothing. > > b95a2f2d486d ("mm: vmscan:

Re: [PATCH 6/9] mm: don't avoid high-priority reclaim on memcg limit reclaim

On Tue 28-02-17 16:40:04, Johannes Weiner wrote: > 246e87a93934 ("memcg: fix get_scan_count() for small targets") sought > to avoid high reclaim priorities for memcg by forcing it to scan a > minimum amount of pages when lru_pages >> priority yielded nothing. > This was done at a time when reclaim

Re: [PATCH 5/9] mm: don't avoid high-priority reclaim on unreclaimable nodes

On Tue 28-02-17 16:40:03, Johannes Weiner wrote: > 246e87a93934 ("memcg: fix get_scan_count() for small targets") sought > to avoid high reclaim priorities for kswapd by forcing it to scan a > minimum amount of pages when lru_pages >> priority yielded nothing. > > b95a2f2d486d ("mm: vmscan:

RE: [PATCH v1] perf vendor events: Add mapping for KnightsMill PMU events

On Wed, Mar 01, 2017 at 03:52 PM +0100, Arnaldo Carvalho de Melo wrote: > this is in my tree already, holidays in this part of the world made this not > go upstream yet, will soon :-) That is great, thanks. Karol

Re: [PATCH] sched: Optimize pick_next_task for idle_sched_class too

On Thu, 23 Feb 2017 20:45:06 +0530 Pavan Kondeti wrote: > Hi Peter, > > On Thu, Feb 23, 2017 at 7:24 PM, Peter Zijlstra wrote: > > On Thu, Feb 23, 2017 at 04:04:22PM +0530, Pavan Kondeti wrote: > >> Hi Peter, > >> > >> > diff --git

Re: [PATCH] mm, add_memory_resource: hold device_hotplug lock over mem_hotplug_{begin, done}

On Wed, Mar 1, 2017 at 4:51 AM, Heiko Carstens wrote: > On Tue, Feb 28, 2017 at 12:57:29PM +0100, Heiko Carstens wrote: >> On Mon, Feb 27, 2017 at 05:20:31PM +0100, Michal Hocko wrote: >> > [CC Rafael] >> > >> > I've got lost in the acpi indirection (again). I can see

RE: [PATCH v1] perf vendor events: Add mapping for KnightsMill PMU events

On Wed, Mar 01, 2017 at 03:52 PM +0100, Arnaldo Carvalho de Melo wrote: > this is in my tree already, holidays in this part of the world made this not > go upstream yet, will soon :-) That is great, thanks. Karol

Re: [PATCH] sched: Optimize pick_next_task for idle_sched_class too

On Thu, 23 Feb 2017 20:45:06 +0530 Pavan Kondeti wrote: > Hi Peter, > > On Thu, Feb 23, 2017 at 7:24 PM, Peter Zijlstra wrote: > > On Thu, Feb 23, 2017 at 04:04:22PM +0530, Pavan Kondeti wrote: > >> Hi Peter, > >> > >> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > >> > index

Re: [PATCH] mm, add_memory_resource: hold device_hotplug lock over mem_hotplug_{begin, done}

On Wed, Mar 1, 2017 at 4:51 AM, Heiko Carstens wrote: > On Tue, Feb 28, 2017 at 12:57:29PM +0100, Heiko Carstens wrote: >> On Mon, Feb 27, 2017 at 05:20:31PM +0100, Michal Hocko wrote: >> > [CC Rafael] >> > >> > I've got lost in the acpi indirection (again). I can see >> > acpi_device_hotplug

[PATCH] PCI: iproc: Add PCI_DOMAIN dependency to PCI Kconfig

From: Jon Mason 2+ PCI devices fail to be discovered due to each bus having the same PCI domain. This is because the domain defined in the device tree file is not being added due to PCI_DOMAIN not being enabled. So, every PCI bus has a domain of zero. When PCI_DOMAIN is

Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support

On Wed, Mar 01, 2017 at 03:21:24PM +0100, Cyrille Pitchen wrote: > Besides, some SPI controller drivers may already use their own bounce > buffer for other reasons. Then for those controllers, it would be one > more copy. They probably shouldn't, there's a lot of legacy drivers that do all sorts

[PATCH] PCI: iproc: Add PCI_DOMAIN dependency to PCI Kconfig

From: Jon Mason 2+ PCI devices fail to be discovered due to each bus having the same PCI domain. This is because the domain defined in the device tree file is not being added due to PCI_DOMAIN not being enabled. So, every PCI bus has a domain of zero. When PCI_DOMAIN is selected by the

Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support

On Wed, Mar 01, 2017 at 03:21:24PM +0100, Cyrille Pitchen wrote: > Besides, some SPI controller drivers may already use their own bounce > buffer for other reasons. Then for those controllers, it would be one > more copy. They probably shouldn't, there's a lot of legacy drivers that do all sorts

Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff

On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote: > Thanks for the patch! I applied the patch on top of "locking/ww_mutex: > Add kselftests for ww_mutex stress", and find no "bad unlock balance > detected" but this warning. Attached is the new dmesg which is a bit > large due to lots

Re: [locking/ww_mutex] 2a0c112828 WARNING: CPU: 0 PID: 18 at kernel/locking/mutex.c:305 __ww_mutex_wakeup_for_backoff

On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote: > Thanks for the patch! I applied the patch on top of "locking/ww_mutex: > Add kselftests for ww_mutex stress", and find no "bad unlock balance > detected" but this warning. Attached is the new dmesg which is a bit > large due to lots

Re: [PATCH v2 2/3] perf annotate: Introduce the new source code view

Hi, Peter On 03/02/2017 12:07 AM, Peter Zijlstra wrote: On Wed, Mar 01, 2017 at 11:56:39PM +0900, Namhyung Kim wrote: It's a kind of user experience issue. We provide the asm-only and asm+source annotation, and I think it'd be nice to add source-only option. And I remember that it was

Re: [PATCH v2 2/3] perf annotate: Introduce the new source code view

Hi, Peter On 03/02/2017 12:07 AM, Peter Zijlstra wrote: On Wed, Mar 01, 2017 at 11:56:39PM +0900, Namhyung Kim wrote: It's a kind of user experience issue. We provide the asm-only and asm+source annotation, and I think it'd be nice to add source-only option. And I remember that it was

[PATCH] Bluetooth: fix assignments on error variable err

From: Colin Ian King Variable err is being initialized to zero and then later being set to the error return from the call to hci_req_run_skb; hence we can remove the redundant initialization to zero. Also on two occassions err is not being set from the error return

[PATCH] Bluetooth: fix assignments on error variable err

From: Colin Ian King Variable err is being initialized to zero and then later being set to the error return from the call to hci_req_run_skb; hence we can remove the redundant initialization to zero. Also on two occassions err is not being set from the error return from the call to

Re: [PATCH 8/9] Revert "mm, vmscan: account for skipped pages as a partial scan"

On Tue 28-02-17 16:40:06, Johannes Weiner wrote: > This reverts commit d7f05528eedb047efe2288cff777676b028747b6. > > Now that reclaimability of a node is no longer based on the ratio > between pages scanned and theoretically reclaimable pages, we can > remove accounting tricks for pages skipped

Re: [PATCH 8/9] Revert "mm, vmscan: account for skipped pages as a partial scan"

On Tue 28-02-17 16:40:06, Johannes Weiner wrote: > This reverts commit d7f05528eedb047efe2288cff777676b028747b6. > > Now that reclaimability of a node is no longer based on the ratio > between pages scanned and theoretically reclaimable pages, we can > remove accounting tricks for pages skipped

Dell Inspiron 5558/0VNM2T and suspend/resume problem with r8169

My machine (a Dell Inspiron 5558 laptop) fails to resume from suspend unless I rmmod r8169 first. Another workaround is to do this before suspend: echo 0 > /sys/power/pm_async I've been reproducing the freeze like this: $ i3lock && systemctl suspend I would have to repeat this at least 5

Dell Inspiron 5558/0VNM2T and suspend/resume problem with r8169

My machine (a Dell Inspiron 5558 laptop) fails to resume from suspend unless I rmmod r8169 first. Another workaround is to do this before suspend: echo 0 > /sys/power/pm_async I've been reproducing the freeze like this: $ i3lock && systemctl suspend I would have to repeat this at least 5

Re: Poll CQ syncing problem

On 3/1/2017 4:51 PM, Christoph Hellwig wrote: > On Wed, Mar 01, 2017 at 04:30:26PM +0200, Noa Osherovich wrote: >> Analysis: >> Since ib_comp_wq isn't single threaded, two works can run in parallel for >> the same CQ, >> executing __ib_process_cq. > They shouldn't. Each CQ has a single

Re: Poll CQ syncing problem

On 3/1/2017 4:51 PM, Christoph Hellwig wrote: > On Wed, Mar 01, 2017 at 04:30:26PM +0200, Noa Osherovich wrote: >> Analysis: >> Since ib_comp_wq isn't single threaded, two works can run in parallel for >> the same CQ, >> executing __ib_process_cq. > They shouldn't. Each CQ has a single

Re: [PATCH 3/9] mm: remove seemingly spurious reclaimability check from laptop_mode gating

On Tue 28-02-17 16:40:01, Johannes Weiner wrote: > 1d82de618ddd ("mm, vmscan: make kswapd reclaim in terms of nodes") > allowed laptop_mode=1 to start writing not just when the priority > drops to DEF_PRIORITY - 2 but also when the node is unreclaimable. > That appears to be a spurious change in

Re: [PATCH v3] btrfs: remove btrfs_err_str function from uapi/linux/btrfs.h

On Wed, Mar 01, 2017 at 02:12:50AM +0300, Dmitry V. Levin wrote: > btrfs_err_str function is not called from anywhere and is replicated > in the userspace headers for btrfs-progs. > > It's removal also fixes the following linux/btrfs.h userspace > compilation error: > >

Re: [PATCH 9/9] mm: remove unnecessary back-off function when retrying page reclaim

On Tue 28-02-17 16:40:07, Johannes Weiner wrote: > The backoff mechanism is not needed. If we have MAX_RECLAIM_RETRIES > loops without progress, we'll OOM anyway; backing off might cut one or > two iterations off that in the rare OOM case. If we have intermittent > success reclaiming a few pages,

Re: [PATCH 3/9] mm: remove seemingly spurious reclaimability check from laptop_mode gating

On Tue 28-02-17 16:40:01, Johannes Weiner wrote: > 1d82de618ddd ("mm, vmscan: make kswapd reclaim in terms of nodes") > allowed laptop_mode=1 to start writing not just when the priority > drops to DEF_PRIORITY - 2 but also when the node is unreclaimable. > That appears to be a spurious change in

Re: [PATCH v3] btrfs: remove btrfs_err_str function from uapi/linux/btrfs.h

On Wed, Mar 01, 2017 at 02:12:50AM +0300, Dmitry V. Levin wrote: > btrfs_err_str function is not called from anywhere and is replicated > in the userspace headers for btrfs-progs. > > It's removal also fixes the following linux/btrfs.h userspace > compilation error: > >

Re: [PATCH 9/9] mm: remove unnecessary back-off function when retrying page reclaim

On Tue 28-02-17 16:40:07, Johannes Weiner wrote: > The backoff mechanism is not needed. If we have MAX_RECLAIM_RETRIES > loops without progress, we'll OOM anyway; backing off might cut one or > two iterations off that in the rare OOM case. If we have intermittent > success reclaiming a few pages,

Re: [PATCH v2 3/3] media: dt-bindings: vpif: new optional property

On Tuesday 28 February 2017 07:56 PM, Rob Herring wrote: > On Mon, Feb 27, 2017 at 11:36 PM, Sekhar Nori wrote: >> On Tuesday 28 February 2017 04:22 AM, Rob Herring wrote: >>> On Wed, Feb 22, 2017 at 02:43:47PM +0100, Bartosz Golaszewski wrote: Add an optional property -

Re: [PATCH v2 3/3] media: dt-bindings: vpif: new optional property

On Tuesday 28 February 2017 07:56 PM, Rob Herring wrote: > On Mon, Feb 27, 2017 at 11:36 PM, Sekhar Nori wrote: >> On Tuesday 28 February 2017 04:22 AM, Rob Herring wrote: >>> On Wed, Feb 22, 2017 at 02:43:47PM +0100, Bartosz Golaszewski wrote: Add an optional property - enable-gpios - which

[PATCH v2 2/2] dts: arm64: add LS1046A DPAA support

Signed-off-by: Madalin Bucur --- arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi | 45 +++ arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 2 + arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 62

[PATCH v2 2/2] dts: arm64: add LS1046A DPAA support

Signed-off-by: Madalin Bucur --- arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi | 45 +++ arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 2 + arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 62 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |

Re: net/dccp: dccp_create_openreq_child freed held lock

Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu: > Hello, > > I've got the following report while running syzkaller fuzzer on > 86292b33d4b79ee03e2f43ea0381ef85f077c760: > > > It seems that dccp_create_openreq_child needs to unlock the sock if > dccp_feat_activate_values fails.

Re: net/dccp: dccp_create_openreq_child freed held lock

Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu: > Hello, > > I've got the following report while running syzkaller fuzzer on > 86292b33d4b79ee03e2f43ea0381ef85f077c760: > > > It seems that dccp_create_openreq_child needs to unlock the sock if > dccp_feat_activate_values fails.

Re: [PATCH 7/9] mm: delete NR_PAGES_SCANNED and pgdat_reclaimable()

On Tue 28-02-17 16:40:05, Johannes Weiner wrote: > NR_PAGES_SCANNED counts number of pages scanned since the last page > free event in the allocator. This was used primarily to measure the > reclaimability of zones and nodes, and determine when reclaim should > give up on them. In that role, it

Re: [PATCH 7/9] mm: delete NR_PAGES_SCANNED and pgdat_reclaimable()

On Tue 28-02-17 16:40:05, Johannes Weiner wrote: > NR_PAGES_SCANNED counts number of pages scanned since the last page > free event in the allocator. This was used primarily to measure the > reclaimability of zones and nodes, and determine when reclaim should > give up on them. In that role, it

Re: [PATCH 3/5] x86/intel_rdt: Fail early on a resource with incorrect domains

On Fri, 17 Feb 2017, Vikas Shivappa wrote: > When a schemata file is changed, user enters control values for all > domains and all resources in the below format (Consider L3 and L2 > resources): > > L3:=;=;... > L2:=;=;... > > Return error as soon as we detect a resource not entering all domain

Re: [PATCH 3/5] x86/intel_rdt: Fail early on a resource with incorrect domains

On Fri, 17 Feb 2017, Vikas Shivappa wrote: > When a schemata file is changed, user enters control values for all > domains and all resources in the below format (Consider L3 and L2 > resources): > > L3:=;=;... > L2:=;=;... > > Return error as soon as we detect a resource not entering all domain

Re: [PATCH 2/4] MIPS: microMIPS: Fix decoding of addiusp instruction

Hi Maciej, On 28/02/17 22:04, Maciej W. Rozycki wrote: On Tue, 28 Feb 2017, Matt Redfearn wrote: diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c index 5b1e932ae973..6ba5b775579c 100644 --- a/arch/mips/kernel/process.c +++ b/arch/mips/kernel/process.c @@ -386,8 +386,9 @@

Re: [PATCH 2/4] MIPS: microMIPS: Fix decoding of addiusp instruction

Hi Maciej, On 28/02/17 22:04, Maciej W. Rozycki wrote: On Tue, 28 Feb 2017, Matt Redfearn wrote: diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c index 5b1e932ae973..6ba5b775579c 100644 --- a/arch/mips/kernel/process.c +++ b/arch/mips/kernel/process.c @@ -386,8 +386,9 @@

Re: net/dccp: dccp_create_openreq_child freed held lock

Em Wed, Mar 01, 2017 at 12:35:10PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu: > > Hello, > > > > I've got the following report while running syzkaller fuzzer on > > 86292b33d4b79ee03e2f43ea0381ef85f077c760: > > > > > > It seems

Re: net/dccp: dccp_create_openreq_child freed held lock

Em Wed, Mar 01, 2017 at 12:35:10PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Mar 01, 2017 at 10:38:54AM +0100, Dmitry Vyukov escreveu: > > Hello, > > > > I've got the following report while running syzkaller fuzzer on > > 86292b33d4b79ee03e2f43ea0381ef85f077c760: > > > > > > It seems

[PATCH] Update VMX and NX crypto driver maintainers

Signed-off-by: Paulo Flabiano Smorigo --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 846f97a..2772c82 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6188,7 +6188,6 @@ S:Maintained F: arch/ia64/

[PATCH] Update VMX and NX crypto driver maintainers

Signed-off-by: Paulo Flabiano Smorigo --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 846f97a..2772c82 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6188,7 +6188,6 @@ S:Maintained F: arch/ia64/ IBM Power VMX Cryptographic

Re: Bug fix for uid/gid in jffs2

On Wed, 2017-03-01 at 16:44 +0800, yangshukui wrote: > > @@ -146,8 +146,8 @@ struct jffs2_raw_inode >   jint32_t ino;    /* Inode number.  */ >   jint32_t version;    /* Version number.  */ >   jmode_t mode;   /* The file's type or mode.  */ > -    jint16_t uid;    /* The

Re: Bug fix for uid/gid in jffs2

On Wed, 2017-03-01 at 16:44 +0800, yangshukui wrote: > > @@ -146,8 +146,8 @@ struct jffs2_raw_inode >   jint32_t ino;    /* Inode number.  */ >   jint32_t version;    /* Version number.  */ >   jmode_t mode;   /* The file's type or mode.  */ > -    jint16_t uid;    /* The

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

+kexec list On 2/28/2017 4:35 AM, Borislav Petkov wrote: On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote: Provide support so that kexec can be used to boot a kernel when SME is enabled. Support is needed to allocate pages for kexec without encryption. This is needed in order to

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

+kexec list On 2/28/2017 4:35 AM, Borislav Petkov wrote: On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote: Provide support so that kexec can be used to boot a kernel when SME is enabled. Support is needed to allocate pages for kexec without encryption. This is needed in order to

Re: [PATCH 0/2] key payload access with just rcu_read_lock()

- Original Message - > From: "David Howells" > To: "Jan Stancek" > Cc: dhowe...@redhat.com, linux-kernel@vger.kernel.org, > linux-...@vger.kernel.org, bcodd...@redhat.com, > asav...@redhat.com > Sent: Wednesday, 1 March, 2017 10:40:13 AM >

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 02:04 PM, Milan Broz wrote: > On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote: > ... > >> I can certainly understand if you don't wont to take the patch until >> we have results with >> dm-crypt itself but the difference between 8 separate invocation of >> the engine for 512 >>

[PATCH 28/44] tools/power turbostat: fix decoding for GLM, DNV, SKX turbo-ratio limits

From: Len Brown Newer processors do not hard-code the the number of cpus in each bin to {1, 2, 3, 4, 5, 6, 7, 8} Rather, they can specify any number of CPUS in each of the 8 bins: eg. ... 37 * 100.0 = 3600.0 MHz max turbo 4 active cores 38 * 100.0 = 3700.0 MHz max turbo 3

Re: [PATCH 0/2] key payload access with just rcu_read_lock()

- Original Message - > From: "David Howells" > To: "Jan Stancek" > Cc: dhowe...@redhat.com, linux-kernel@vger.kernel.org, > linux-...@vger.kernel.org, bcodd...@redhat.com, > asav...@redhat.com > Sent: Wednesday, 1 March, 2017 10:40:13 AM > Subject: Re: [PATCH 0/2] key payload access

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 02:04 PM, Milan Broz wrote: > On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote: > ... > >> I can certainly understand if you don't wont to take the patch until >> we have results with >> dm-crypt itself but the difference between 8 separate invocation of >> the engine for 512 >>

[PATCH 28/44] tools/power turbostat: fix decoding for GLM, DNV, SKX turbo-ratio limits

From: Len Brown Newer processors do not hard-code the the number of cpus in each bin to {1, 2, 3, 4, 5, 6, 7, 8} Rather, they can specify any number of CPUS in each of the 8 bins: eg. ... 37 * 100.0 = 3600.0 MHz max turbo 4 active cores 38 * 100.0 = 3700.0 MHz max turbo 3 active cores 39 *

Re: [PATCH v2 2/3] perf annotate: Introduce the new source code view

On Wed, Mar 01, 2017 at 11:56:39PM +0900, Namhyung Kim wrote: > It's a kind of user experience issue. We provide the asm-only and > asm+source annotation, and I think it'd be nice to add source-only > option. And I remember that it was requested some time ago.. Thing is, an optimizing compiler

Re: [PATCH v2 2/3] perf annotate: Introduce the new source code view

On Wed, Mar 01, 2017 at 11:56:39PM +0900, Namhyung Kim wrote: > It's a kind of user experience issue. We provide the asm-only and > asm+source annotation, and I think it'd be nice to add source-only > option. And I remember that it was requested some time ago.. Thing is, an optimizing compiler

[PATCH] usb: gadget: f_fs: simplify ffs_dev name handling

Currently ffs_dev::name can be either allocated by the client of the ffs_dev structure or by the f_fs.c core itself. The former is used by g_ffs while the latter happens with configfs. Historically, g_ffs did not need to allocate separate buffer for the name so what is now f_fs.c core never

[PATCH] usb: gadget: f_fs: simplify ffs_dev name handling

Currently ffs_dev::name can be either allocated by the client of the ffs_dev structure or by the f_fs.c core itself. The former is used by g_ffs while the latter happens with configfs. Historically, g_ffs did not need to allocate separate buffer for the name so what is now f_fs.c core never

[PATCH v2 0/5] MIPS: Further microMIPS stack unwinding fixes

4.11 includes a bunch of stack unwinding fixes for microMIPS, but some of those fixes require additional fixup, provided by this series. These patches have been tested on qemu M14Kc micromips and tested for regression on ci40, Boston, Octeon III & malta. This series is based on

[PATCH v2 0/5] MIPS: Further microMIPS stack unwinding fixes

4.11 includes a bunch of stack unwinding fixes for microMIPS, but some of those fixes require additional fixup, provided by this series. These patches have been tested on qemu M14Kc micromips and tested for regression on ci40, Boston, Octeon III & malta. This series is based on

[PATCH v2] tpm: Apply a sane minimum adapterlimit value for retransmission.

From: Bryan Freed When the I2C Infineon part is attached to an I2C adapter that imposes a size limitation, large requests will fail with -EOPNOTSUPP. Retry them with a sane minimum size without re-issuing the 0x05 command as this appears to occasionally put the TPM in a bad

[PATCH v2] tpm: Apply a sane minimum adapterlimit value for retransmission.

From: Bryan Freed When the I2C Infineon part is attached to an I2C adapter that imposes a size limitation, large requests will fail with -EOPNOTSUPP. Retry them with a sane minimum size without re-issuing the 0x05 command as this appears to occasionally put the TPM in a bad state.

[PATCH v2 1/2] dts: arm64: add LS1043A DPAA support

Signed-off-by: Madalin Bucur --- arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi | 41 +++ arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 2 + arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 75

[PATCH v2 1/2] dts: arm64: add LS1043A DPAA support

Signed-off-by: Madalin Bucur --- arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi | 41 +++ arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 2 + arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 75 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 73

[PATCH v2 0/2] dts: arm64: add DPAA 1 support for ARM based SoCs

Add DPAA 1 nodes for LS1043A/LS1046A and networking support for RDB and QDS boards with these SoCs. changes from v1: addressed comment from Rob Herring on using SPDX license identifiers Madalin Bucur (2): dts: arm64: add LS1043A DPAA support dts: arm64: add LS1046A DPAA

[PATCH v2 0/2] dts: arm64: add DPAA 1 support for ARM based SoCs

Add DPAA 1 nodes for LS1043A/LS1046A and networking support for RDB and QDS boards with these SoCs. changes from v1: addressed comment from Rob Herring on using SPDX license identifiers Madalin Bucur (2): dts: arm64: add LS1043A DPAA support dts: arm64: add LS1046A DPAA

Re: [PATCH 5/8] x86/intel_rdt: info file support for MBA prepare

On Fri, 17 Feb 2017, Vikas Shivappa wrote: > As a preparatory patch to MBA info file setup, generalize the info file > setup to have the option to choose between different set of files. > Although multiple cache resources have same info files, Memory resources > have different set of info files.

Re: [PATCH 5/8] x86/intel_rdt: info file support for MBA prepare

On Fri, 17 Feb 2017, Vikas Shivappa wrote: > As a preparatory patch to MBA info file setup, generalize the info file > setup to have the option to choose between different set of files. > Although multiple cache resources have same info files, Memory resources > have different set of info files.

[PATCH v2 3/5] MIPS: Refactor handling of stack pointer in get_frame_info

Commit 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.") added handling of microMIPS instructions to manipulate the stack pointer. The code that was added violates code style rules with long lines caused by lots of nested conditionals. The added code interprets (inline) any known

[PATCH v2 1/5] MIPS: Handle non word sized instructions when examining frame

Commit b6c7a324df37 ("MIPS: Fix get_frame_info() handling of microMIPS function size") goes some way to fixing get_frame_info() to iterate over microMIPS instuctions, but increments the instruction pointer using a postincrement of the instruction pointer, which is of union mips_instruction type.

[PATCH v2 3/5] MIPS: Refactor handling of stack pointer in get_frame_info

Commit 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.") added handling of microMIPS instructions to manipulate the stack pointer. The code that was added violates code style rules with long lines caused by lots of nested conditionals. The added code interprets (inline) any known

[PATCH v2 1/5] MIPS: Handle non word sized instructions when examining frame

Commit b6c7a324df37 ("MIPS: Fix get_frame_info() handling of microMIPS function size") goes some way to fixing get_frame_info() to iterate over microMIPS instuctions, but increments the instruction pointer using a postincrement of the instruction pointer, which is of union mips_instruction type.

[PATCH v2 2/5] MIPS: microMIPS: Fix decoding of addiusp instruction

Commit 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.") added handling of microMIPS instructions to manipulate the stack pointer. Unfortunately the decoding of the addiusp instruction was incorrect, and performed a left shift by 2 bits to the raw immediate, rather than decoding the

[PATCH v2 2/5] MIPS: microMIPS: Fix decoding of addiusp instruction

Commit 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.") added handling of microMIPS instructions to manipulate the stack pointer. Unfortunately the decoding of the addiusp instruction was incorrect, and performed a left shift by 2 bits to the raw immediate, rather than decoding the

[PATCH v2 4/5] MIPS: Stacktrace: Fix __usermode() of uninitialised regs

Commit 81a76d7119f6 ("MIPS: Avoid using unwind_stack() with usermode") added a check if the passed regs are from user mode, and perform a raw backtrace if so. When WARN() is invoked, __dump_stack calls show_stack() with NULL task and stack pointers. This leads show_stack to create a pt_regs struct

[PATCH v2 4/5] MIPS: Stacktrace: Fix __usermode() of uninitialised regs

Commit 81a76d7119f6 ("MIPS: Avoid using unwind_stack() with usermode") added a check if the passed regs are from user mode, and perform a raw backtrace if so. When WARN() is invoked, __dump_stack calls show_stack() with NULL task and stack pointers. This leads show_stack to create a pt_regs struct

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Wed, Mar 1, 2017 at 3:40 PM, Josh Poimboeuf wrote: > On Wed, Mar 01, 2017 at 10:45:03AM +0100, Arnd Bergmann wrote: >> Actually, something must have changed in gcc since last month, I also >> just got a report in another file: >> >> drivers/i2c/busses/i2c-img-scb.o:

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Wed, Mar 1, 2017 at 3:40 PM, Josh Poimboeuf wrote: > On Wed, Mar 01, 2017 at 10:45:03AM +0100, Arnd Bergmann wrote: >> Actually, something must have changed in gcc since last month, I also >> just got a report in another file: >> >> drivers/i2c/busses/i2c-img-scb.o: warning: objtool:

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Wed, Mar 01, 2017 at 10:34:42AM +0100, Arnd Bergmann wrote: > On Tue, Oct 11, 2016 at 10:38 PM, Arnd Bergmann wrote: > > On Tuesday, October 11, 2016 10:51:46 AM CEST Josh Poimboeuf wrote: > >> > >> 3) 0xFC244C03-config: > >> drivers/scsi/fnic/fnic_main.o: warning: objtool:

[PATCH v3] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

The original patch makes the condition always true, so it is wrong. It masks (but not fixes) the bug described in the commit message but introduces a regression (no console is selected by SPCR) in regular (no 'console=ttyAMA') case. s/||/&&/ would not fix the problem as the root cause was

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Wed, Mar 01, 2017 at 10:34:42AM +0100, Arnd Bergmann wrote: > On Tue, Oct 11, 2016 at 10:38 PM, Arnd Bergmann wrote: > > On Tuesday, October 11, 2016 10:51:46 AM CEST Josh Poimboeuf wrote: > >> > >> 3) 0xFC244C03-config: > >> drivers/scsi/fnic/fnic_main.o: warning: objtool: fnic_log_q_error()

[PATCH v3] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

The original patch makes the condition always true, so it is wrong. It masks (but not fixes) the bug described in the commit message but introduces a regression (no console is selected by SPCR) in regular (no 'console=ttyAMA') case. s/||/&&/ would not fix the problem as the root cause was

Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit : > On 01.03.2017 12:51, Thibault Saunier wrote: > > It is required by the standard that the field order is set by the > > driver, default to NONE in case any is provided, but we can > > basically > > accept any value provided by the

Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit : > On 01.03.2017 12:51, Thibault Saunier wrote: > > It is required by the standard that the field order is set by the > > driver, default to NONE in case any is provided, but we can > > basically > > accept any value provided by the

Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit : > - on output side you have encoded bytestream - you cannot say about > interlacing in such case, so the only valid value is NONE, > - on capture side you have decoded frames, and in this case it > depends > on the device and driver

Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g_fmt

Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit : > - on output side you have encoded bytestream - you cannot say about > interlacing in such case, so the only valid value is NONE, > - on capture side you have decoded frames, and in this case it > depends > on the device and driver

Re: [patch 0/3] KVM CPU frequency change hypercalls

On Wed, Mar 01, 2017 at 03:21:32PM +0100, Paolo Bonzini wrote: > > > On 28/02/2017 03:45, Marcelo Tosatti wrote: > > On Fri, Feb 24, 2017 at 04:34:52PM +0100, Paolo Bonzini wrote: > >> > >> > >> On 24/02/2017 14:04, Marcelo Tosatti wrote: > >>> Whats the current usecase, or forseeable future

Re: [patch 0/3] KVM CPU frequency change hypercalls

On Wed, Mar 01, 2017 at 03:21:32PM +0100, Paolo Bonzini wrote: > > > On 28/02/2017 03:45, Marcelo Tosatti wrote: > > On Fri, Feb 24, 2017 at 04:34:52PM +0100, Paolo Bonzini wrote: > >> > >> > >> On 24/02/2017 14:04, Marcelo Tosatti wrote: > >>> Whats the current usecase, or forseeable future

Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Wed, 1 Mar 2017, Ajay Kaher wrote: > > On Mon, 22 Feb 2017, Ajay Kaher wrote: > >  > >> On Mon, 20 Feb 2017, Ajay Kaher wrote: > >>  > >>> Alan, as per my understanding I have shifted the lock from > >>> release_usb_class() to destroy_usb_class() in patch v3.  > >>> If it is not right, please 

Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Wed, 1 Mar 2017, Ajay Kaher wrote: > > On Mon, 22 Feb 2017, Ajay Kaher wrote: > >  > >> On Mon, 20 Feb 2017, Ajay Kaher wrote: > >>  > >>> Alan, as per my understanding I have shifted the lock from > >>> release_usb_class() to destroy_usb_class() in patch v3.  > >>> If it is not right, please 

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Wed, Mar 1, 2017 at 3:31 PM, Josh Poimboeuf wrote: > On Wed, Mar 01, 2017 at 10:34:42AM +0100, Arnd Bergmann wrote: >> On Tue, Oct 11, 2016 at 10:38 PM, Arnd Bergmann wrote: >> > On Tuesday, October 11, 2016 10:51:46 AM CEST Josh Poimboeuf wrote: >> >> >>

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Wed, Mar 1, 2017 at 3:31 PM, Josh Poimboeuf wrote: > On Wed, Mar 01, 2017 at 10:34:42AM +0100, Arnd Bergmann wrote: >> On Tue, Oct 11, 2016 at 10:38 PM, Arnd Bergmann wrote: >> > On Tuesday, October 11, 2016 10:51:46 AM CEST Josh Poimboeuf wrote: >> >> >> >> 3) 0xFC244C03-config: >> >>

Re: net/ipv4: inconsistent lock state in tcp_conn_request/inet_ehash_insert

On Wed, Mar 1, 2017 at 6:59 AM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26). SInce I probably added this bug, I will send a fix shortly,

Re: net/ipv4: inconsistent lock state in tcp_conn_request/inet_ehash_insert

On Wed, Mar 1, 2017 at 6:59 AM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26). SInce I probably added this bug, I will send a fix shortly, thanks for the report.

<    6   7   8   9   10   11   12   13   14   15   >