[PATCH] KVM: hyperv: split lock to protect struct kvm_hv

Otherwise, there is an AB-BA deadlock between kvm->lock and vcpu->mutex. Reported-by: Dmitry Vyukov Signed-off-by: Paolo Bonzini --- Compile-tested only. Documentation/virtual/kvm/locking.txt | 2 ++ arch/x86/include/asm/kvm_host.h | 1

[PATCH] KVM: hyperv: split lock to protect struct kvm_hv

Otherwise, there is an AB-BA deadlock between kvm->lock and vcpu->mutex. Reported-by: Dmitry Vyukov Signed-off-by: Paolo Bonzini --- Compile-tested only. Documentation/virtual/kvm/locking.txt | 2 ++ arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/hyperv.c

Re: netlink: GPF in sock_sndtimeo

On Fri, Dec 9, 2016 at 8:13 PM, Cong Wang wrote: > On Fri, Dec 9, 2016 at 3:01 AM, Richard Guy Briggs wrote: >> On 2016-12-08 22:57, Cong Wang wrote: >>> On Thu, Dec 8, 2016 at 10:02 PM, Richard Guy Briggs wrote: >>> > I also tried to

Re: netlink: GPF in sock_sndtimeo

On Fri, Dec 9, 2016 at 8:13 PM, Cong Wang wrote: > On Fri, Dec 9, 2016 at 3:01 AM, Richard Guy Briggs wrote: >> On 2016-12-08 22:57, Cong Wang wrote: >>> On Thu, Dec 8, 2016 at 10:02 PM, Richard Guy Briggs wrote: >>> > I also tried to extend Cong Wang's idea to attempt to proactively respond

Re: [PATCH] f2fs: fix to determine start_cp_addr by sbi->cur_cp_pack

Hi Jaegeuk, Let me try to understand this, in some cases, we can write a checkpoint pack which has wrong cp_ver, like in 1st cp pack which has even version number or 2nd cp pack which has odd version number, so if we load that kind of cp pack during fill_super, we may load wrong summary data from

Re: [PATCH] f2fs: fix to determine start_cp_addr by sbi->cur_cp_pack

Hi Jaegeuk, Let me try to understand this, in some cases, we can write a checkpoint pack which has wrong cp_ver, like in 1st cp pack which has even version number or 2nd cp pack which has odd version number, so if we load that kind of cp pack during fill_super, we may load wrong summary data from

Re: [PATCH] driver core: flush async calls before testing driver removal

On Sat, Dec 10, 2016 at 02:15:19AM +0200, Vladimir Zapolskiy wrote: > If CONFIG_DEBUG_TEST_DRIVER_REMOVE option is enabled a number of false > positives are reported for ATA controller drivers, because ATA port > probes are done asynchronously, and the same problem may also touch > other

Re: [PATCH] driver core: flush async calls before testing driver removal

On Sat, Dec 10, 2016 at 02:15:19AM +0200, Vladimir Zapolskiy wrote: > If CONFIG_DEBUG_TEST_DRIVER_REMOVE option is enabled a number of false > positives are reported for ATA controller drivers, because ATA port > probes are done asynchronously, and the same problem may also touch > other

Re: [regression ?] kbuild: fix building bzImage with CONFIG_TRIM_UNUSED_KSYMS enabled

On (12/09/16 13:07), Nicolas Pitre wrote: [..] > > build: > > make -j4 > build_log 2>&1 > > > > package: > > make -j4 INSTALL_MOD_PATH="${pkgdir}" modules_install >> build_log 2>&1 > > Weird. it is. sorry for long reply, it took me some time to track it down. turned out, the script also does

Re: [regression ?] kbuild: fix building bzImage with CONFIG_TRIM_UNUSED_KSYMS enabled

On (12/09/16 13:07), Nicolas Pitre wrote: [..] > > build: > > make -j4 > build_log 2>&1 > > > > package: > > make -j4 INSTALL_MOD_PATH="${pkgdir}" modules_install >> build_log 2>&1 > > Weird. it is. sorry for long reply, it took me some time to track it down. turned out, the script also does

[RFC PATCH] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT

From: zhong jiang I think that CONT_PTE_SHIFT is more reasonable even if they are some value. and the patch is not any functional change. Signed-off-by: zhong jiang --- arch/arm64/mm/hugetlbpage.c | 2 +- 1 file changed, 1 insertion(+), 1

[RFC PATCH] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT

From: zhong jiang I think that CONT_PTE_SHIFT is more reasonable even if they are some value. and the patch is not any functional change. Signed-off-by: zhong jiang --- arch/arm64/mm/hugetlbpage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/mm/hugetlbpage.c

[PATCH 1/1 linux-next] xfs: remove unnecessary return

Commit f7a136aee3c1 ("xfs: several xattr functions can be void") updated 2 end of function return 0 to return in void functions. Remove it. Signed-off-by: Fabian Frederick --- fs/xfs/xfs_attr_list.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/xfs/xfs_attr_list.c

[PATCH 1/1 linux-next] xfs: remove unnecessary return

Commit f7a136aee3c1 ("xfs: several xattr functions can be void") updated 2 end of function return 0 to return in void functions. Remove it. Signed-off-by: Fabian Frederick --- fs/xfs/xfs_attr_list.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/xfs/xfs_attr_list.c

Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Sat, Dec 10, 2016 at 01:37:12PM +0800, Herbert Xu wrote: > On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > > > Herbert, how hard would it be to teach the crypto code to use a more > > sensible data structure than scatterlist and to use coccinelle fix > > this stuff for

Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Sat, Dec 10, 2016 at 01:37:12PM +0800, Herbert Xu wrote: > On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > > > Herbert, how hard would it be to teach the crypto code to use a more > > sensible data structure than scatterlist and to use coccinelle fix > > this stuff for

Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Sat, Dec 10, 2016 at 01:32:08PM +0800, Herbert Xu wrote: > On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > > > > The following crypto drivers initialize a scatterlist to point into an > > > ablkcipher_request, which may have been allocated on the stack with > > >

Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Sat, Dec 10, 2016 at 01:32:08PM +0800, Herbert Xu wrote: > On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > > > > The following crypto drivers initialize a scatterlist to point into an > > > ablkcipher_request, which may have been allocated on the stack with > > >

Crypto Fixes for 4.9

Hi Linus: This push fixes the following issues: - Fix pointer size when caam is used with AArch64 boot loader on AArch32 kernel. - Fix ahash state corruption in marvell driver. - Fix buggy algif_aed tag handling. - Prevent mcryptd from being used with incompatible algorithms which can cause

Crypto Fixes for 4.9

Hi Linus: This push fixes the following issues: - Fix pointer size when caam is used with AArch64 boot loader on AArch32 kernel. - Fix ahash state corruption in marvell driver. - Fix buggy algif_aed tag handling. - Prevent mcryptd from being used with incompatible algorithms which can cause

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > The following crypto drivers initialize a scatterlist to point into an > > ahash_request, which may have been allocated on the stack with > > AHASH_REQUEST_ON_STACK(): > > > > drivers/crypto/bfin_crc.c:351 > >

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > The following crypto drivers initialize a scatterlist to point into an > > ahash_request, which may have been allocated on the stack with > > AHASH_REQUEST_ON_STACK(): > > > > drivers/crypto/bfin_crc.c:351 > >

Re: [PATCH] scsi/qla2xxx: label endian-ness for many fields

On Fri, 2016-12-09 at 22:45 +0200, Michael S. Tsirkin wrote: > This adds endian-ness labels for lots of qla structs. > Doing this cuts down number of sparse warnings from ~1700 to ~1400. > Will help find and resolve some of real issues down the road. > > Signed-off-by: Michael S. Tsirkin

Re: [PATCH] scsi/qla2xxx: label endian-ness for many fields

On Fri, 2016-12-09 at 22:45 +0200, Michael S. Tsirkin wrote: > This adds endian-ness labels for lots of qla structs. > Doing this cuts down number of sparse warnings from ~1700 to ~1400. > Will help find and resolve some of real issues down the road. > > Signed-off-by: Michael S. Tsirkin > >

Re: [PATCH v3 00/15] livepatch: hybrid consistency model

On Thu, 2016-12-08 at 12:08 -0600, Josh Poimboeuf wrote: > Dusting the cobwebs off the consistency model again.  This is based on > linux-next/master. >  > v1 was posted on 2015-02-09: >  >   https://lkml.kernel.org/r/cover.1423499826.git.jpoim...@redhat.com >  > v2 was posted on 2016-04-28: >  >  

Re: [PATCH v3 00/15] livepatch: hybrid consistency model

On Thu, 2016-12-08 at 12:08 -0600, Josh Poimboeuf wrote: > Dusting the cobwebs off the consistency model again.  This is based on > linux-next/master. >  > v1 was posted on 2015-02-09: >  >   https://lkml.kernel.org/r/cover.1423499826.git.jpoim...@redhat.com >  > v2 was posted on 2016-04-28: >  >  

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > Herbert, how hard would it be to teach the crypto code to use a more > sensible data structure than scatterlist and to use coccinelle fix > this stuff for real? First of all we already have a sync non-SG hash interface, it's

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > Herbert, how hard would it be to teach the crypto code to use a more > sensible data structure than scatterlist and to use coccinelle fix > this stuff for real? First of all we already have a sync non-SG hash interface, it's

Re: [PATCH 7/7] hwrng: core: Remove two unused include

Hi Corentin, [auto build test ERROR on char-misc/char-misc-testing] [also build test ERROR on v4.9-rc8 next-20161209] [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/Corentin-Labbe/hwrng-core-do

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > > The following crypto drivers initialize a scatterlist to point into an > > ablkcipher_request, which may have been allocated on the stack with > > SKCIPHER_REQUEST_ON_STACK(): > > > >

Re: [PATCH 7/7] hwrng: core: Remove two unused include

Hi Corentin, [auto build test ERROR on char-misc/char-misc-testing] [also build test ERROR on v4.9-rc8 next-20161209] [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/Corentin-Labbe/hwrng-core-do

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > > The following crypto drivers initialize a scatterlist to point into an > > ablkcipher_request, which may have been allocated on the stack with > > SKCIPHER_REQUEST_ON_STACK(): > > > >

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote: > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by > default on x86_64. This has been exposing a number of problems in which > on-stack buffers are being passed into the crypto API, which to

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote: > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by > default on x86_64. This has been exposing a number of problems in which > on-stack buffers are being passed into the crypto API, which to support crypto >

Re: [bug report] perf jit: add source line info support

On Fri, Dec 9, 2016 at 9:16 PM, Stephane Eranian wrote: > Hi Dan, > > On Wed, Nov 30, 2016 at 10:48 AM, Dan Carpenter > wrote: >> Hello Stephane Eranian, >> >> The patch 598b7c6919c7: "perf jit: add source line info support" from >> Nov 30, 2015,

Re: [bug report] perf jit: add source line info support

On Fri, Dec 9, 2016 at 9:16 PM, Stephane Eranian wrote: > Hi Dan, > > On Wed, Nov 30, 2016 at 10:48 AM, Dan Carpenter > wrote: >> Hello Stephane Eranian, >> >> The patch 598b7c6919c7: "perf jit: add source line info support" from >> Nov 30, 2015, leads to the following static checker warning: >>

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 10.12.2016 um 02:55 schrieb Roland Scheidegger: > Am 09.12.2016 um 23:59 schrieb Thomas Gleixner: >> On Fri, 9 Dec 2016, Roland Scheidegger wrote: >> >> Cc'ed someone from Dell. >> >>> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner: Can you add the patch below to gather more information?

Re: [PATCH] Add +~800M crashkernel explaination

On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote: > On 12/09/16 at 05:22pm, Robert LeBlanc wrote: >> When trying to configure crashkernel greater than about 800 MB, the >> kernel fails to allocate memory on x86 and x86_64. This is due to an >> undocumented limit that the

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 10.12.2016 um 02:55 schrieb Roland Scheidegger: > Am 09.12.2016 um 23:59 schrieb Thomas Gleixner: >> On Fri, 9 Dec 2016, Roland Scheidegger wrote: >> >> Cc'ed someone from Dell. >> >>> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner: Can you add the patch below to gather more information?

Re: [PATCH] Add +~800M crashkernel explaination

On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote: > On 12/09/16 at 05:22pm, Robert LeBlanc wrote: >> When trying to configure crashkernel greater than about 800 MB, the >> kernel fails to allocate memory on x86 and x86_64. This is due to an >> undocumented limit that the crashkernel and other low

Re: [PATCH 1/1] arm64: mm: add config options for page table configuration

Hi Will, On 16-12-09 02:57 AM, Will Deacon wrote: On Thu, Dec 08, 2016 at 11:33:39AM -0800, Scott Branden wrote: Since I currently have your attention: I do think there is fundamental bug in the ARM64 mm implementation. If you look at /sys/devices/system/memory it only shows the last memoryX

Re: [PATCH 1/1] arm64: mm: add config options for page table configuration

Hi Will, On 16-12-09 02:57 AM, Will Deacon wrote: On Thu, Dec 08, 2016 at 11:33:39AM -0800, Scott Branden wrote: Since I currently have your attention: I do think there is fundamental bug in the ARM64 mm implementation. If you look at /sys/devices/system/memory it only shows the last memoryX

Re: [bug report] perf jit: add source line info support

Hi Dan, On Wed, Nov 30, 2016 at 10:48 AM, Dan Carpenter wrote: > Hello Stephane Eranian, > > The patch 598b7c6919c7: "perf jit: add source line info support" from > Nov 30, 2015, leads to the following static checker warning: > >

Re: [bug report] perf jit: add source line info support

Hi Dan, On Wed, Nov 30, 2016 at 10:48 AM, Dan Carpenter wrote: > Hello Stephane Eranian, > > The patch 598b7c6919c7: "perf jit: add source line info support" from > Nov 30, 2015, leads to the following static checker warning: > > ./tools/perf/util/genelf_debug.c:211 emit_signed_LEB128()

perf/jit doesn't cope well with mprotect() to jit containing pages

00 0 0]: ---p //anon postgres 4107 595444.868140: PERF_RECORD_MMAP2 4107/4107: [0x7efd3866e000(0x45) @ 0x40 fd:02 33434534 1]: --xs /home/andres/.debug/jit/llvm-IR-jit-20161209.XXfN0K3O/jitted-4107-1.so postgres 4107 595444.884090: PERF_RECORD_MMAP2 4107/4107: [0x7efd3866c000(0x3000) @ 0x

perf/jit doesn't cope well with mprotect() to jit containing pages

00 0 0]: ---p //anon postgres 4107 595444.868140: PERF_RECORD_MMAP2 4107/4107: [0x7efd3866e000(0x45) @ 0x40 fd:02 33434534 1]: --xs /home/andres/.debug/jit/llvm-IR-jit-20161209.XXfN0K3O/jitted-4107-1.so postgres 4107 595444.884090: PERF_RECORD_MMAP2 4107/4107: [0x7efd3866c000(0x3000) @ 0x

[GIT] Networking

1) Limit the number of can filters to avoid > MAX_ORDER allocations. Fix from Marc Kleine-Budde. 2) Limit GSO max size in netvsc driver to avoid problems with NVGRE configurations. From Stephen Hemminger. 3) Return proper error when memory allocation fails in ser_gigaset_init(), from

[GIT] Networking

1) Limit the number of can filters to avoid > MAX_ORDER allocations. Fix from Marc Kleine-Budde. 2) Limit GSO max size in netvsc driver to avoid problems with NVGRE configurations. From Stephen Hemminger. 3) Return proper error when memory allocation fails in ser_gigaset_init(), from

Re: [PATCH 1/1] of: of_reserved_mem: Ensure cma reserved region not cross the low/high memory

2016-11-23 19:37 GMT+08:00 Jason Liu : > Need ensure the cma reserved region not cross the low/high memory boundary > when using the dynamic allocation methond through device-tree, otherwise, > kernel will fail to boot up when cma reserved region cross how/high mem. > >

Re: [PATCH 1/1] of: of_reserved_mem: Ensure cma reserved region not cross the low/high memory

2016-11-23 19:37 GMT+08:00 Jason Liu : > Need ensure the cma reserved region not cross the low/high memory boundary > when using the dynamic allocation methond through device-tree, otherwise, > kernel will fail to boot up when cma reserved region cross how/high mem. > > Signed-off-by: Jason Liu >

Re: [RFC 0/5] rcu: Introduce leaf_node_for_each_mask_possible_cpu() and its friend

On Sat, Dec 10, 2016 at 08:45:38AM +0800, Boqun Feng wrote: > On Fri, Dec 09, 2016 at 03:49:45PM -0800, Paul E. McKenney wrote: > > On Fri, Dec 09, 2016 at 04:48:22PM +0800, Boqun Feng wrote: > > > Hi Paul, > > > > > > While reading the discussion at: > > > > > >

Re: [RFC 0/5] rcu: Introduce leaf_node_for_each_mask_possible_cpu() and its friend

On Sat, Dec 10, 2016 at 08:45:38AM +0800, Boqun Feng wrote: > On Fri, Dec 09, 2016 at 03:49:45PM -0800, Paul E. McKenney wrote: > > On Fri, Dec 09, 2016 at 04:48:22PM +0800, Boqun Feng wrote: > > > Hi Paul, > > > > > > While reading the discussion at: > > > > > >

Re: netlink: GPF in sock_sndtimeo

On Fri, Dec 9, 2016 at 3:01 AM, Richard Guy Briggs wrote: > On 2016-12-08 22:57, Cong Wang wrote: >> On Thu, Dec 8, 2016 at 10:02 PM, Richard Guy Briggs wrote: >> > I also tried to extend Cong Wang's idea to attempt to proactively respond >> > to a >> >

Re: netlink: GPF in sock_sndtimeo

On Fri, Dec 9, 2016 at 3:01 AM, Richard Guy Briggs wrote: > On 2016-12-08 22:57, Cong Wang wrote: >> On Thu, Dec 8, 2016 at 10:02 PM, Richard Guy Briggs wrote: >> > I also tried to extend Cong Wang's idea to attempt to proactively respond >> > to a >> > NETLINK_URELEASE on the audit_sock and

[PATCH] llist: Clarify comments about when locking is needed

llist.h comments are a bit confusing about when locking is needed versus when it isn't. Clarify these comments a bit more and be a bit more descriptive about why locking is needed for llist_del_first. Cc: Huang Ying Cc: Ingo Molnar Cc: Will Deacon

[PATCH] llist: Clarify comments about when locking is needed

llist.h comments are a bit confusing about when locking is needed versus when it isn't. Clarify these comments a bit more and be a bit more descriptive about why locking is needed for llist_del_first. Cc: Huang Ying Cc: Ingo Molnar Cc: Will Deacon Cc: Paul McKenney Cc: Mathieu Desnoyers

Re: [PATCH] net: mlx5: Fix Kconfig help text

From: Christopher Covington Date: Fri, 9 Dec 2016 16:53:05 -0500 > Since the following commit, Infiniband and Ethernet have not been > mutually exclusive. > > Fixes: 4aa17b28 mlx5: Enable mutual support for IB and Ethernet > > Signed-off-by: Christopher Covington

Re: [PATCH] net: mlx5: Fix Kconfig help text

From: Christopher Covington Date: Fri, 9 Dec 2016 16:53:05 -0500 > Since the following commit, Infiniband and Ethernet have not been > mutually exclusive. > > Fixes: 4aa17b28 mlx5: Enable mutual support for IB and Ethernet > > Signed-off-by: Christopher Covington Applied.

Re: [PATCH net-next] net: macb: Added PCI wrapper for Platform Driver.

From: Bartosz Folta Date: Fri, 9 Dec 2016 10:05:46 + > There are hardware PCI implementations of Cadence GEM network controller. > This patch will allow to use such hardware with reuse of existing Platform > Driver. Please properly format your commit message text to 80

Re: [PATCH net-next] net: macb: Added PCI wrapper for Platform Driver.

From: Bartosz Folta Date: Fri, 9 Dec 2016 10:05:46 + > There are hardware PCI implementations of Cadence GEM network controller. > This patch will allow to use such hardware with reuse of existing Platform > Driver. Please properly format your commit message text to 80 columns. > >

Re: [PATCH] x86/smpboot: Make logical package management more robust

On 12/09/2016 06:00 PM, Thomas Gleixner wrote: On Fri, 9 Dec 2016, Boris Ostrovsky wrote: On 12/09/2016 05:06 PM, Thomas Gleixner wrote: On Thu, 8 Dec 2016, Thomas Gleixner wrote: Boris, can you please verify if that makes the topology_update_package_map() call which you placed into the Xen

Re: [PATCH] x86/smpboot: Make logical package management more robust

On 12/09/2016 06:00 PM, Thomas Gleixner wrote: On Fri, 9 Dec 2016, Boris Ostrovsky wrote: On 12/09/2016 05:06 PM, Thomas Gleixner wrote: On Thu, 8 Dec 2016, Thomas Gleixner wrote: Boris, can you please verify if that makes the topology_update_package_map() call which you placed into the Xen

Re: [PATCH] x86/smpboot: Make logical package management more robust

On 12/09/2016 06:02 PM, Boris Ostrovsky wrote: On 12/09/2016 05:06 PM, Thomas Gleixner wrote: On Thu, 8 Dec 2016, Thomas Gleixner wrote: Boris, can you please verify if that makes the topology_update_package_map() call which you placed into the Xen cpu starting code obsolete ? Will do. I

Re: [PATCH] x86/smpboot: Make logical package management more robust

On 12/09/2016 06:02 PM, Boris Ostrovsky wrote: On 12/09/2016 05:06 PM, Thomas Gleixner wrote: On Thu, 8 Dec 2016, Thomas Gleixner wrote: Boris, can you please verify if that makes the topology_update_package_map() call which you placed into the Xen cpu starting code obsolete ? Will do. I

Re: [RFC][PATCHv5 3/7] printk: introduce per-cpu safe_print seq buffer

On (12/09/16 17:46), Petr Mladek wrote: > > -/* > > - * Safe printk() for NMI context. It uses a per-CPU buffer to > > - * store the message. NMIs are not nested, so there is always only > > - * one writer running. But the buffer might get flushed from another > > - * CPU, so we need to be

Re: [RFC][PATCHv5 3/7] printk: introduce per-cpu safe_print seq buffer

On (12/09/16 17:46), Petr Mladek wrote: > > -/* > > - * Safe printk() for NMI context. It uses a per-CPU buffer to > > - * store the message. NMIs are not nested, so there is always only > > - * one writer running. But the buffer might get flushed from another > > - * CPU, so we need to be

[PATCH] drm/bridge: analogix_dp: set the DPCD600 during disabling the psr

Look likes, the BOE panel FW didn't ack the DPCD600 signal from the host device, that will cause the panel hang on the startup display. The root cause we use the fast link mode during enter and exit the psr, this issue is gone if switching the fast link to main link mode. Signed-off-by: Caesar

[PATCH] drm/bridge: analogix_dp: set the DPCD600 during disabling the psr

Look likes, the BOE panel FW didn't ack the DPCD600 signal from the host device, that will cause the panel hang on the startup display. The root cause we use the fast link mode during enter and exit the psr, this issue is gone if switching the fast link to main link mode. Signed-off-by: Caesar

Re: [PATCH] Add +~800M crashkernel explaination

On 12/09/16 at 05:22pm, Robert LeBlanc wrote: > When trying to configure crashkernel greater than about 800 MB, the > kernel fails to allocate memory on x86 and x86_64. This is due to an > undocumented limit that the crashkernel and other low memory items must > be allocated below 896 MB unless

Re: [PATCH] Add +~800M crashkernel explaination

On 12/09/16 at 05:22pm, Robert LeBlanc wrote: > When trying to configure crashkernel greater than about 800 MB, the > kernel fails to allocate memory on x86 and x86_64. This is due to an > undocumented limit that the crashkernel and other low memory items must > be allocated below 896 MB unless

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

Hi, On 09.12.2016 12:21, Pavel Machek wrote: > On Fri 2016-12-09 00:19:43, Francois Romieu wrote: >> Lino Sanfilippo : >> [...] >> > OTOH Pavel said that he actually could produce a deadlock. Now I wonder if >> > this is caused by that locking scheme (in a way I have not

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

Hi, On 09.12.2016 12:21, Pavel Machek wrote: > On Fri 2016-12-09 00:19:43, Francois Romieu wrote: >> Lino Sanfilippo : >> [...] >> > OTOH Pavel said that he actually could produce a deadlock. Now I wonder if >> > this is caused by that locking scheme (in a way I have not figured out yet) >> > or

Re: [PATCH net-next 1/2] net: phy: add extension of phy-mode for XLGMII

On 2016/12/10 0:39, Andrew Lunn wrote: > On Fri, Dec 09, 2016 at 01:19:07PM +0800, Jie Deng wrote: >> >> On 2016/12/9 6:15, Florian Fainelli wrote: >>> On 12/06/2016 07:57 PM, Jie Deng wrote: This patch adds phy-mode support for Synopsys XLGMAC >>> The functional changes look good, but I

Re: [PATCH net-next 1/2] net: phy: add extension of phy-mode for XLGMII

On 2016/12/10 0:39, Andrew Lunn wrote: > On Fri, Dec 09, 2016 at 01:19:07PM +0800, Jie Deng wrote: >> >> On 2016/12/9 6:15, Florian Fainelli wrote: >>> On 12/06/2016 07:57 PM, Jie Deng wrote: This patch adds phy-mode support for Synopsys XLGMAC >>> The functional changes look good, but I

Re: [PATCH v2 2/2] staging: iio: ad7606: move out of staging

Hi Eva, [auto build test WARNING on iio/togreg] [also build test WARNING on next-20161209] [cannot apply to v4.9-rc8] [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/Eva-Rachel-Retuya/staging

Re: [PATCH v2 2/2] staging: iio: ad7606: move out of staging

Hi Eva, [auto build test WARNING on iio/togreg] [also build test WARNING on next-20161209] [cannot apply to v4.9-rc8] [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/Eva-Rachel-Retuya/staging

Re: [PATCH] Input: i8042-x86ia64io.h - Comment else/endif of CONFIG_PNP

On Fri, Dec 09, 2016 at 09:55:09PM -0200, Marcos Paulo de Souza wrote: > As this define check if huge, this makes easier to read the code. > > Signed-off-by: Marcos Paulo de Souza Applied, thank you. > --- > While reviewing patches from Dmitry about presence of

Re: [PATCH] Input: i8042-x86ia64io.h - Comment else/endif of CONFIG_PNP

On Fri, Dec 09, 2016 at 09:55:09PM -0200, Marcos Paulo de Souza wrote: > As this define check if huge, this makes easier to read the code. > > Signed-off-by: Marcos Paulo de Souza Applied, thank you. > --- > While reviewing patches from Dmitry about presence of 8042, it makes it > much

Re: [PATCH] driver core: flush async calls before testing driver removal

On Fri, Dec 9, 2016 at 4:15 PM, Vladimir Zapolskiy wrote: > If CONFIG_DEBUG_TEST_DRIVER_REMOVE option is enabled a number of false > positives are reported for ATA controller drivers, because ATA port > probes are done asynchronously, and the same problem may also touch > other

Re: [PATCH] driver core: flush async calls before testing driver removal

On Fri, Dec 9, 2016 at 4:15 PM, Vladimir Zapolskiy wrote: > If CONFIG_DEBUG_TEST_DRIVER_REMOVE option is enabled a number of false > positives are reported for ATA controller drivers, because ATA port > probes are done asynchronously, and the same problem may also touch > other asynchronously

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 09.12.2016 um 23:59 schrieb Thomas Gleixner: > On Fri, 9 Dec 2016, Roland Scheidegger wrote: > > Cc'ed someone from Dell. > >> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner: >>> Can you add the patch below to gather more information? There is a hunk in >>> there with an '#if 0' which sets

Re: [PATCH] x86/tsc: RFC: re-synchronize TSCs to boot cpu TSC

Am 09.12.2016 um 23:59 schrieb Thomas Gleixner: > On Fri, 9 Dec 2016, Roland Scheidegger wrote: > > Cc'ed someone from Dell. > >> Am 09.12.2016 um 18:33 schrieb Thomas Gleixner: >>> Can you add the patch below to gather more information? There is a hunk in >>> there with an '#if 0' which sets

Re: [PATCH 4/5] 9p: introduce async read requests

On Thu, Dec 08, 2016 at 12:59:05PM -0800, Stefano Stabellini wrote: > + } else { > + req = p9_client_get_req(clnt, P9_TREAD, "dqd", > fid->fid, offset, rsize); > + if (IS_ERR(req)) { > + *err = PTR_ERR(req); > +

Re: [PATCH 4/5] 9p: introduce async read requests

On Thu, Dec 08, 2016 at 12:59:05PM -0800, Stefano Stabellini wrote: > + } else { > + req = p9_client_get_req(clnt, P9_TREAD, "dqd", > fid->fid, offset, rsize); > + if (IS_ERR(req)) { > + *err = PTR_ERR(req); > +

Re: [PATCH 09/10] s390/cputime: delayed accounting of system time

On Tue, Dec 06, 2016 at 03:32:22AM +0100, Frederic Weisbecker wrote: > From: Martin Schwidefsky > > The account_system_time() function is called with a cputime that > occurred while running in the kernel. The function detects which > context the CPU is currently running

Re: [PATCH 09/10] s390/cputime: delayed accounting of system time

On Tue, Dec 06, 2016 at 03:32:22AM +0100, Frederic Weisbecker wrote: > From: Martin Schwidefsky > > The account_system_time() function is called with a cputime that > occurred while running in the kernel. The function detects which > context the CPU is currently running in and accounts the time

Re: [PATCH 0/2] Determine kernel text mapping size at runtime for x86_64

On 12/08/16 at 02:00pm, Dave Anderson wrote: > > > - Original Message - > > On Wed, Dec 7, 2016 at 11:56 PM, Baoquan He wrote: > > > Dave Anderson ever told in Crash utility he makes judgement whether it's > > > a kaslr kernel by size of KERNEL_IMAGE_SIZE. As long as

Re: [PATCH 0/2] Determine kernel text mapping size at runtime for x86_64

On 12/08/16 at 02:00pm, Dave Anderson wrote: > > > - Original Message - > > On Wed, Dec 7, 2016 at 11:56 PM, Baoquan He wrote: > > > Dave Anderson ever told in Crash utility he makes judgement whether it's > > > a kaslr kernel by size of KERNEL_IMAGE_SIZE. As long as it's 1G, it's > > >

Re: [PATCH 7/7] hwrng: core: Remove two unused include

Hi Corentin, [auto build test ERROR on char-misc/char-misc-testing] [also build test ERROR on v4.9-rc8 next-20161209] [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/Corentin-Labbe/hwrng-core-do

Re: [PATCH 7/7] hwrng: core: Remove two unused include

Hi Corentin, [auto build test ERROR on char-misc/char-misc-testing] [also build test ERROR on v4.9-rc8 next-20161209] [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/Corentin-Labbe/hwrng-core-do

[PATCH] jump label: pass kbuild_cflags when checking for asm goto support

Some versions of ARM GCC compiler such as Android toolchain throws in a '-fpic' flag by default. This causes the gcc-goto check script to fail although some config would have '-fno-pic' flag in the KBUILD_CFLAGS. This patch passes the KBUILD_CFLAGS to the check script so that the script does not

[PATCH] jump label: pass kbuild_cflags when checking for asm goto support

Some versions of ARM GCC compiler such as Android toolchain throws in a '-fpic' flag by default. This causes the gcc-goto check script to fail although some config would have '-fno-pic' flag in the KBUILD_CFLAGS. This patch passes the KBUILD_CFLAGS to the check script so that the script does not

Re: [RFC 0/5] rcu: Introduce leaf_node_for_each_mask_possible_cpu() and its friend

On Fri, Dec 09, 2016 at 03:49:45PM -0800, Paul E. McKenney wrote: > On Fri, Dec 09, 2016 at 04:48:22PM +0800, Boqun Feng wrote: > > Hi Paul, > > > > While reading the discussion at: > > > > https://marc.info/?l=linux-kernel=148044253400769 > > This discussion was for stalls specifically, rather

Re: [RFC 0/5] rcu: Introduce leaf_node_for_each_mask_possible_cpu() and its friend

On Fri, Dec 09, 2016 at 03:49:45PM -0800, Paul E. McKenney wrote: > On Fri, Dec 09, 2016 at 04:48:22PM +0800, Boqun Feng wrote: > > Hi Paul, > > > > While reading the discussion at: > > > > https://marc.info/?l=linux-kernel=148044253400769 > > This discussion was for stalls specifically, rather

Re: [PATCH 01/22] m68k/atari: Modernize printing of kernel messages

Hi Geert, Am 09.12.2016 um 01:22 schrieb Geert Uytterhoeven: > On Wed, Dec 7, 2016 at 11:36 PM, Finn Thain > wrote: >> On Wed, 7 Dec 2016, Geert Uytterhoeven wrote: >>> - Convert from printk() to pr_*(), >>> - Add missing continuations, to fix user-visible

Re: [PATCH 01/22] m68k/atari: Modernize printing of kernel messages

Hi Geert, Am 09.12.2016 um 01:22 schrieb Geert Uytterhoeven: > On Wed, Dec 7, 2016 at 11:36 PM, Finn Thain > wrote: >> On Wed, 7 Dec 2016, Geert Uytterhoeven wrote: >>> - Convert from printk() to pr_*(), >>> - Add missing continuations, to fix user-visible breakage, >>> - Drop useless

Re: [PATCH] PCI: pciehp: Optimize PCIe root resume time

[+cc Yinghai, author of 2f5d8e4ff947] On Fri, Dec 09, 2016 at 02:43:26PM -0800, Vaibhav Shankar wrote: > On Apollolake platforms, PCIe rootport takes a long time to resume > from S3. With 100ms delay before read pci conf, rootport takes > ~200ms during resume. > > commit 2f5d8e4ff947 ("PCI:

Re: [PATCH] PCI: pciehp: Optimize PCIe root resume time

[+cc Yinghai, author of 2f5d8e4ff947] On Fri, Dec 09, 2016 at 02:43:26PM -0800, Vaibhav Shankar wrote: > On Apollolake platforms, PCIe rootport takes a long time to resume > from S3. With 100ms delay before read pci conf, rootport takes > ~200ms during resume. > > commit 2f5d8e4ff947 ("PCI:

Should xhci_irq() call usb_hc_died()?

Hi Mathias, ehci_irq(), ohci_irq(), fotg210_irq(), and oxu210_hcd_irq() contain code equivalent to this: status = ehci_readl(...); if (status == ~(u32) 0) { ... usb_hc_died(hcd); ... return IRQ_HANDLED; } xhci_irq() has a similar check, but does not call usb_hc_died():

Should xhci_irq() call usb_hc_died()?

Hi Mathias, ehci_irq(), ohci_irq(), fotg210_irq(), and oxu210_hcd_irq() contain code equivalent to this: status = ehci_readl(...); if (status == ~(u32) 0) { ... usb_hc_died(hcd); ... return IRQ_HANDLED; } xhci_irq() has a similar check, but does not call usb_hc_died():

  1   2   3   4   5   6   7   8   9   10   >