[PATCH 04/20] perf llvm: Extract helpers in llvm-utils.c

From: Wang Nan The following commits will use builtin clang to compile BPF scripts. llvm__get_kbuild_opts() and llvm__get_nr_cpus() are extracted to help building '-DKERNEL_VERSION_CODE' and '-D__NR_CPUS__' macros. Doing object dumping in bpf loader, so further builtin

[GIT PULL 00/20] perf/core improvements and fixes

/core (2016-12-02 10:08:03 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20161205 for you to fetch changes up to bec60e50af83741cde1786ab475d4bf472aed6f9: perf annotate: Show raw form for jump

[PATCH 04/20] perf llvm: Extract helpers in llvm-utils.c

From: Wang Nan The following commits will use builtin clang to compile BPF scripts. llvm__get_kbuild_opts() and llvm__get_nr_cpus() are extracted to help building '-DKERNEL_VERSION_CODE' and '-D__NR_CPUS__' macros. Doing object dumping in bpf loader, so further builtin clang compiling needn't

[GIT PULL 00/20] perf/core improvements and fixes

/core (2016-12-02 10:08:03 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20161205 for you to fetch changes up to bec60e50af83741cde1786ab475d4bf472aed6f9: perf annotate: Show raw form for jump

[PATCH 10/20] perf clang: Allow passing CFLAGS to builtin clang

From: Wang Nan Improve getModuleFromSource() API to accept a cflags list. This feature will be used to pass LINUX_VERSION_CODE and -I flags. Signed-off-by: Wang Nan Cc: Alexei Starovoitov Cc: He Kuang Cc: Jiri Olsa

[PATCH 10/20] perf clang: Allow passing CFLAGS to builtin clang

From: Wang Nan Improve getModuleFromSource() API to accept a cflags list. This feature will be used to pass LINUX_VERSION_CODE and -I flags. Signed-off-by: Wang Nan Cc: Alexei Starovoitov Cc: He Kuang Cc: Jiri Olsa Cc: Joe Stringer Cc: Zefan Li Cc: pi3or...@163.com Link:

[PATCH 12/20] perf clang: Support compile IR to BPF object and add testcase

From: Wang Nan getBPFObjectFromModule() is introduced to compile LLVM IR(Module) to BPF object. Add new testcase for it. Test result: $ ./buildperf/perf test -v clang 51: builtin clang support : 51.1: builtin clang compile C source to IR

[PATCH 12/20] perf clang: Support compile IR to BPF object and add testcase

From: Wang Nan getBPFObjectFromModule() is introduced to compile LLVM IR(Module) to BPF object. Add new testcase for it. Test result: $ ./buildperf/perf test -v clang 51: builtin clang support : 51.1: builtin clang compile C source to IR : ---

[PATCH 13/20] perf clang: Compile BPF script using builtin clang support

From: Wang Nan After this patch, perf utilizes builtin clang support to build BPF script, no longer depend on external clang, but fallbacking to it if for some reason the builtin compiling framework fails. Test: $ type clang -bash: type: clang: not found $ cat

[PATCH 02/20] tools build: Fix objtool build with clang

From: Peter Foley Clang doesn't support multiple arguments being passed to -Wp, so split them. Fixes this error: HOSTCC tools/objtool/fixdep.o cat: tools/objtool/.fixdep.o.d: No such file or directory Signed-off-by: Peter Foley Tested-by:

[PATCH 13/20] perf clang: Compile BPF script using builtin clang support

From: Wang Nan After this patch, perf utilizes builtin clang support to build BPF script, no longer depend on external clang, but fallbacking to it if for some reason the builtin compiling framework fails. Test: $ type clang -bash: type: clang: not found $ cat ~/.perfconfig $ echo

[PATCH 02/20] tools build: Fix objtool build with clang

From: Peter Foley Clang doesn't support multiple arguments being passed to -Wp, so split them. Fixes this error: HOSTCC tools/objtool/fixdep.o cat: tools/objtool/.fixdep.o.d: No such file or directory Signed-off-by: Peter Foley Tested-by: Arnaldo Carvalho de Melo Acked-by: Jiri Olsa

RE: [tpmdd-devel] [PATCH v2 2/3] tpm_crb: encapsulate crb_wait_for_reg_32

> CC linux-security-module > > On Sat, Dec 03, 2016 at 07:52:12PM +0200, Jarkko Sakkinen wrote: > > Encapsulated crb_wait_for_reg32() so that state changes in other CRB > > registers than TPM_CRB_CTRL_REQ_x can be waited. > > > > Signed-off-by: Jarkko Sakkinen >

RE: [tpmdd-devel] [PATCH v2 2/3] tpm_crb: encapsulate crb_wait_for_reg_32

> CC linux-security-module > > On Sat, Dec 03, 2016 at 07:52:12PM +0200, Jarkko Sakkinen wrote: > > Encapsulated crb_wait_for_reg32() so that state changes in other CRB > > registers than TPM_CRB_CTRL_REQ_x can be waited. > > > > Signed-off-by: Jarkko Sakkinen > > --- > >

[PATCH v3 2/4] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing"

This reverts commit ed68d7e9b9cfb64f3045ffbcb108df03c09a0f98. The patch wasn't quite correct -- there are non-Intel (and hence non-486) CPUs that we support that don't have CPUID. Since we no longer require CPUID for sync_core(), just revert the patch. I think the relevant CPUs are Geode and

[PATCH v3 2/4] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing"

This reverts commit ed68d7e9b9cfb64f3045ffbcb108df03c09a0f98. The patch wasn't quite correct -- there are non-Intel (and hence non-486) CPUs that we support that don't have CPUID. Since we no longer require CPUID for sync_core(), just revert the patch. I think the relevant CPUs are Geode and

[PATCH v3 0/4] CPUID-less CPU/sync_core fixes and improvements

*** PATCHES 1 and 2 MAY BE 4.9 MATERIAL *** Alan Cox pointed out that the 486 isn't the only supported CPU that doesn't have CPUID. Let's clean up the mess and make everything faster while we're at it. Patch 1 is intended to be an easy fix: it makes sync_core() work without CPUID on all 32-bit

Re: bio linked list corruption.

On 5 December 2016 at 21:35, Linus Torvalds wrote: > Note for Ingo and Peter: this patch has not been tested at all. But > Vegard did test an earlier patch of mine that just verified that yes, > the issue really was that wait queue entries remained on the wait >

[PATCH v3 0/4] CPUID-less CPU/sync_core fixes and improvements

*** PATCHES 1 and 2 MAY BE 4.9 MATERIAL *** Alan Cox pointed out that the 486 isn't the only supported CPU that doesn't have CPUID. Let's clean up the mess and make everything faster while we're at it. Patch 1 is intended to be an easy fix: it makes sync_core() work without CPUID on all 32-bit

Re: bio linked list corruption.

On 5 December 2016 at 21:35, Linus Torvalds wrote: > Note for Ingo and Peter: this patch has not been tested at all. But > Vegard did test an earlier patch of mine that just verified that yes, > the issue really was that wait queue entries remained on the wait > queue head just as we were about

[PATCH v3 3/4] x86/microcode/intel: Replace sync_core() with native_cpuid()

The Intel microcode driver is using sync_core() to mean "do CPUID with EAX=1". I want to rework sync_core(), but first the Intel microcode driver needs to stop depending on its current behavior. Reported-by: Henrique de Moraes Holschuh Acked-by: Borislav Petkov

[PATCH v3 1/4] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels

We support various non-Intel CPUs that don't have the CPUID instruction, so the M486 test was wrong. For now, fix it with a big hammer: handle missing CPUID on all 32-bit CPUs. Reported-by: One Thousand Gnomes Signed-off-by: Andy Lutomirski ---

[PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

Aside from being excessively slow, CPUID is problematic: Linux runs on a handful of CPUs that don't have CPUID. Use IRET-to-self instead. IRET-to-self works everywhere, so it makes testing easy. For reference, On my laptop, IRET-to-self is ~110ns, CPUID(eax=1, ecx=0) is ~83ns on native and very

[PATCH v3 3/4] x86/microcode/intel: Replace sync_core() with native_cpuid()

The Intel microcode driver is using sync_core() to mean "do CPUID with EAX=1". I want to rework sync_core(), but first the Intel microcode driver needs to stop depending on its current behavior. Reported-by: Henrique de Moraes Holschuh Acked-by: Borislav Petkov Signed-off-by: Andy Lutomirski

[PATCH v3 1/4] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels

We support various non-Intel CPUs that don't have the CPUID instruction, so the M486 test was wrong. For now, fix it with a big hammer: handle missing CPUID on all 32-bit CPUs. Reported-by: One Thousand Gnomes Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/processor.h | 2 +- 1 file

[PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

Aside from being excessively slow, CPUID is problematic: Linux runs on a handful of CPUs that don't have CPUID. Use IRET-to-self instead. IRET-to-self works everywhere, so it makes testing easy. For reference, On my laptop, IRET-to-self is ~110ns, CPUID(eax=1, ecx=0) is ~83ns on native and very

RE: [tpmdd-devel] [PATCH v2 1/3] tpm_crb: map locality registers

> > On Mon, Dec 05, 2016 at 12:07:51PM +, Winkler, Tomas wrote: > > > > --- > > > > drivers/char/tpm/tpm_crb.c | 96 > > > > ++ > > > > 1 file changed, 64 insertions(+), 32 deletions(-) > > > > > > > > diff --git a/drivers/char/tpm/tpm_crb.c > > >

RE: [tpmdd-devel] [PATCH v2 1/3] tpm_crb: map locality registers

> > On Mon, Dec 05, 2016 at 12:07:51PM +, Winkler, Tomas wrote: > > > > --- > > > > drivers/char/tpm/tpm_crb.c | 96 > > > > ++ > > > > 1 file changed, 64 insertions(+), 32 deletions(-) > > > > > > > > diff --git a/drivers/char/tpm/tpm_crb.c > > >

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

> If the parameters plausibly make it possible for root to modify the > kernel in interesting ways, then restricting them makes sense. My gut > sense is that parameters that allow the alteration of the base address > of memory mapped devices are clearly a problem in this respect, but port > io

Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver

On Mon 14 Nov 14:21 PST 2016, Stephen Boyd wrote: > On 11/11, Georgi Djakov wrote: > > On 11/03/2016 08:28 PM, Bjorn Andersson wrote: [..] > > >I'm in favour of us inventing a kicker API and it's found outside out > > >use cases as well (e.g. virtio/rpmsg). > > > > > I'd rather we did this

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

> If the parameters plausibly make it possible for root to modify the > kernel in interesting ways, then restricting them makes sense. My gut > sense is that parameters that allow the alteration of the base address > of memory mapped devices are clearly a problem in this respect, but port > io

Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver

On Mon 14 Nov 14:21 PST 2016, Stephen Boyd wrote: > On 11/11, Georgi Djakov wrote: > > On 11/03/2016 08:28 PM, Bjorn Andersson wrote: [..] > > >I'm in favour of us inventing a kicker API and it's found outside out > > >use cases as well (e.g. virtio/rpmsg). > > > > > I'd rather we did this

Re: [PATCH 5/5] docs: 00-INDEX: document directories/files with no docs

On Mon, 5 Dec 2016 09:41:45 -0200 Mauro Carvalho Chehab wrote: > There are a number of files/directories that don't contain > any documentation. They're related to ReST file conversion. > > As a matter of completeness, since Makefile is also documented > there, add an

Re: [PATCH 5/5] docs: 00-INDEX: document directories/files with no docs

On Mon, 5 Dec 2016 09:41:45 -0200 Mauro Carvalho Chehab wrote: > There are a number of files/directories that don't contain > any documentation. They're related to ReST file conversion. > > As a matter of completeness, since Makefile is also documented > there, add an entry for those files

Re: [PATCH v2 net-next v2 3/4] net: dsa: mv88e6xxx: add a soft reset operation

Hi Vivien On Mon, Dec 05, 2016 at 11:27:02AM -0500, Vivien Didelot wrote: > static const struct mv88e6xxx_ops mv88e6097_ops = { > @@ -3285,6 +3266,7 @@ static const struct mv88e6xxx_ops mv88e6097_ops = { > .g1_set_cpu_port = mv88e6095_g1_set_cpu_port, > .g1_set_egress_port =

Re: [PATCH v2 net-next v2 3/4] net: dsa: mv88e6xxx: add a soft reset operation

Hi Vivien On Mon, Dec 05, 2016 at 11:27:02AM -0500, Vivien Didelot wrote: > static const struct mv88e6xxx_ops mv88e6097_ops = { > @@ -3285,6 +3266,7 @@ static const struct mv88e6xxx_ops mv88e6097_ops = { > .g1_set_cpu_port = mv88e6095_g1_set_cpu_port, > .g1_set_egress_port =

Build error due to commit 8ab2ae655b ("default exported asm symbols to zero")

Hi Arnd, commit 8ab2ae655bf ("default exported asm symbols to zero") results in the following build error when building alpha:allmodconfig. arch/alpha/lib/callback_srm.S: Assembler messages: arch/alpha/lib/callback_srm.S:97: Warning: Tried to .set unrecognized mode

Build error due to commit 8ab2ae655b ("default exported asm symbols to zero")

Hi Arnd, commit 8ab2ae655bf ("default exported asm symbols to zero") results in the following build error when building alpha:allmodconfig. arch/alpha/lib/callback_srm.S: Assembler messages: arch/alpha/lib/callback_srm.S:97: Warning: Tried to .set unrecognized mode

Re: [PATCH 0/5] Update Documentation/00-INDEX

On Mon, 5 Dec 2016 09:41:40 -0200 Mauro Carvalho Chehab wrote: > So, in order to check it, I wrote a small script that compares the files > and directories at Documentation/ with the ones at 00-INDEX. > > Then, I synchronized the entries, making the script happy. > >

Re: [PATCH 0/5] Update Documentation/00-INDEX

On Mon, 5 Dec 2016 09:41:40 -0200 Mauro Carvalho Chehab wrote: > So, in order to check it, I wrote a small script that compares the files > and directories at Documentation/ with the ones at 00-INDEX. > > Then, I synchronized the entries, making the script happy. > > We might think on

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

On Fri, Dec 02, 2016 at 07:33:46PM -0500, Jon Masters wrote: > On 12/02/2016 06:39 PM, Bjorn Helgaas wrote: > > On Thu, Dec 01, 2016 at 11:08:23PM -0500, Jon Masters wrote: > > >> Let's see if I summarized this correctly... > >> > >> 1. The MMIO registers for the host bridge itself need to be

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

On Fri, Dec 02, 2016 at 07:33:46PM -0500, Jon Masters wrote: > On 12/02/2016 06:39 PM, Bjorn Helgaas wrote: > > On Thu, Dec 01, 2016 at 11:08:23PM -0500, Jon Masters wrote: > > >> Let's see if I summarized this correctly... > >> > >> 1. The MMIO registers for the host bridge itself need to be

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

On Fri, Dec 02, 2016 at 11:06:30PM -0800, Duc Dang wrote: > On Fri, Dec 2, 2016 at 3:39 PM, Bjorn Helgaas wrote: > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c > > index 8a177a1..a16fc8e 100644 > > --- a/arch/arm64/kernel/pci.c > > +++

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

On Fri, Dec 02, 2016 at 11:06:30PM -0800, Duc Dang wrote: > On Fri, Dec 2, 2016 at 3:39 PM, Bjorn Helgaas wrote: > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c > > index 8a177a1..a16fc8e 100644 > > --- a/arch/arm64/kernel/pci.c > > +++ b/arch/arm64/kernel/pci.c > > @@ -114,6

Re: [PATCH 1/2] Documentation/core-api/device_link: Add initial documentation

On Sun, 4 Dec 2016 13:10:04 +0100 Lukas Wunner wrote: > Document device links as introduced in v4.10 with commits: > 4bdb35506b89 ("driver core: Add a wrapper around >__device_release_driver()") > 9ed9895370ae ("driver core: Functional dependencies

Re: [PATCH 1/2] Documentation/core-api/device_link: Add initial documentation

On Sun, 4 Dec 2016 13:10:04 +0100 Lukas Wunner wrote: > Document device links as introduced in v4.10 with commits: > 4bdb35506b89 ("driver core: Add a wrapper around >__device_release_driver()") > 9ed9895370ae ("driver core: Functional dependencies tracking >

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

On Thu, 01 Dec 2016 16:02:26 + David Howells wrote: > Greg KH wrote: > > > Also, I think Alan's comment about it the last time it came up was more like > > a "look at all of the other ways you could do bad things to hardware!" > > comment,

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

On Thu, 01 Dec 2016 16:02:26 + David Howells wrote: > Greg KH wrote: > > > Also, I think Alan's comment about it the last time it came up was more like > > a "look at all of the other ways you could do bad things to hardware!" > > comment, not a "you need to also do this thing too!" type

Re: [PATCH v2] zswap: only use CPU notifier when HOTPLUG_CPU=y

On Fri, Dec 02, 2016 at 02:46:06PM +0100, Michal Hocko wrote: > On Wed 30-11-16 13:15:16, Yu Zhao wrote: > > __unregister_cpu_notifier() only removes registered notifier from its > > linked list when CPU hotplug is configured. If we free registered CPU > > notifier when HOTPLUG_CPU=n, we corrupt

Re: [PATCH v2] zswap: only use CPU notifier when HOTPLUG_CPU=y

On Fri, Dec 02, 2016 at 02:46:06PM +0100, Michal Hocko wrote: > On Wed 30-11-16 13:15:16, Yu Zhao wrote: > > __unregister_cpu_notifier() only removes registered notifier from its > > linked list when CPU hotplug is configured. If we free registered CPU > > notifier when HOTPLUG_CPU=n, we corrupt

Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/

O> > > Suggested-by: One Thousand Gnomes > > > > I know this is only a Suggested-by and not a Signed-off-by, but still I > > believe the Developer's Certificate of Origin applies, and it says: > > "using your real name (sorry, no pseudonyms or anonymous > >

Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/

O> > > Suggested-by: One Thousand Gnomes > > > > I know this is only a Suggested-by and not a Signed-off-by, but still I > > believe the Developer's Certificate of Origin applies, and it says: > > "using your real name (sorry, no pseudonyms or anonymous > > contributions.)" > > I asked him

[PATCH 1/1] vfio iommu type1: set size to PAGE_SIZE while looking for iova in dma list

In the functions of pin_pages/unpin_pages from mdev vendor driver, vfio_find_dma() should be called with size as PAGE_SIZE instead of 0. vfio_find_dma() searches for the range in dma_list. In vfio_dma_do_unmap(), vfio_find_dma() when used to look for start address of unmap->iova, size should be

[PATCH 1/1] vfio iommu type1: set size to PAGE_SIZE while looking for iova in dma list

In the functions of pin_pages/unpin_pages from mdev vendor driver, vfio_find_dma() should be called with size as PAGE_SIZE instead of 0. vfio_find_dma() searches for the range in dma_list. In vfio_dma_do_unmap(), vfio_find_dma() when used to look for start address of unmap->iova, size should be

Re: [PATCH v3 10/30] perf clang: Add builtin clang support ant test case

Em Mon, Dec 05, 2016 at 08:51:01AM -0800, Alexei Starovoitov escreveu: > On Fri, Dec 02, 2016 at 01:44:40PM -0200, Arnaldo Carvalho de Melo wrote: > > Em Sat, Nov 26, 2016 at 07:03:34AM +, Wang Nan escreveu: > > > Add basic clang support in clang.cpp and test__clang() testcase. The > > > first

Re: [PATCH v3 10/30] perf clang: Add builtin clang support ant test case

Em Mon, Dec 05, 2016 at 08:51:01AM -0800, Alexei Starovoitov escreveu: > On Fri, Dec 02, 2016 at 01:44:40PM -0200, Arnaldo Carvalho de Melo wrote: > > Em Sat, Nov 26, 2016 at 07:03:34AM +, Wang Nan escreveu: > > > Add basic clang support in clang.cpp and test__clang() testcase. The > > > first

Re: [PATCH v2 net-next v2 4/4] net: dsa: mv88e6xxx: add PPU operations

Hi Vivien, On Mon, Dec 05, 2016 at 11:27:03AM -0500, Vivien Didelot wrote: > @@ -3266,6 +3220,8 @@ static const struct mv88e6xxx_ops mv88e6097_ops = { > .g1_set_cpu_port = mv88e6095_g1_set_cpu_port, > .g1_set_egress_port = mv88e6095_g1_set_egress_port, > .mgmt_rsvd2cpu =

Re: [PATCH v2 net-next v2 4/4] net: dsa: mv88e6xxx: add PPU operations

Hi Vivien, On Mon, Dec 05, 2016 at 11:27:03AM -0500, Vivien Didelot wrote: > @@ -3266,6 +3220,8 @@ static const struct mv88e6xxx_ops mv88e6097_ops = { > .g1_set_cpu_port = mv88e6095_g1_set_cpu_port, > .g1_set_egress_port = mv88e6095_g1_set_egress_port, > .mgmt_rsvd2cpu =

[PATCH 1/1] vfio iommu type1: WARN_ON if notifier block is not unregistered

mdev vendor driver should unregister the iommu notifier since the vfio iommu can persist beyond the attachment of the mdev group. WARN_ON will show warning if vendor driver doesn't unregister the notifier and is forced to follow the implementations steps. Signed-off-by: Kirti Wankhede

[PATCH 1/1] vfio iommu type1: WARN_ON if notifier block is not unregistered

mdev vendor driver should unregister the iommu notifier since the vfio iommu can persist beyond the attachment of the mdev group. WARN_ON will show warning if vendor driver doesn't unregister the notifier and is forced to follow the implementations steps. Signed-off-by: Kirti Wankhede

Re: [PATCH 0/5] cpsw: add per channel shaper configuration

On Mon, Dec 05, 2016 at 02:33:40PM -0600, Grygorii Strashko wrote: > Hi Ivan, > > On 11/29/2016 09:00 AM, Ivan Khoronzhuk wrote: > > This series is intended to allow user to set rate for per channel > > shapers at cpdma level. This patchset doesn't have impact on performance. > > The rate can be

Re: [PATCH 0/5] cpsw: add per channel shaper configuration

On Mon, Dec 05, 2016 at 02:33:40PM -0600, Grygorii Strashko wrote: > Hi Ivan, > > On 11/29/2016 09:00 AM, Ivan Khoronzhuk wrote: > > This series is intended to allow user to set rate for per channel > > shapers at cpdma level. This patchset doesn't have impact on performance. > > The rate can be

Re: [PATCH 4/4] KVM: x86: allow hotplug of VCPU with APIC ID over 0xff

2016-12-05 19:00+0100, David Hildenbrand: > Am 05.12.2016 um 17:02 schrieb Radim Krčmář: >> 2016-12-05 15:37+0100, David Hildenbrand: >> > Am 02.12.2016 um 20:44 schrieb Radim Krčmář: >> > > LAPIC after reset is in xAPIC mode, which poses a problem for hotplug of >> > > VCPUs with high APIC ID,

Re: [PATCH 4/4] KVM: x86: allow hotplug of VCPU with APIC ID over 0xff

2016-12-05 19:00+0100, David Hildenbrand: > Am 05.12.2016 um 17:02 schrieb Radim Krčmář: >> 2016-12-05 15:37+0100, David Hildenbrand: >> > Am 02.12.2016 um 20:44 schrieb Radim Krčmář: >> > > LAPIC after reset is in xAPIC mode, which poses a problem for hotplug of >> > > VCPUs with high APIC ID,

Re: [PATCH] hotplug: make register and unregister notifier API symmetric

On Fri, Dec 02, 2016 at 04:19:36PM +0100, Michal Hocko wrote: > [Let's CC more people - the thread started > http://lkml.kernel.org/r/1480540516-6458-1-git-send-email-yuz...@google.com] > > On Fri 02-12-16 09:56:26, Dan Streetman wrote: > > On Fri, Dec 2, 2016 at 9:44 AM, Michal Hocko

Re: [PATCH] hotplug: make register and unregister notifier API symmetric

On Fri, Dec 02, 2016 at 04:19:36PM +0100, Michal Hocko wrote: > [Let's CC more people - the thread started > http://lkml.kernel.org/r/1480540516-6458-1-git-send-email-yuz...@google.com] > > On Fri 02-12-16 09:56:26, Dan Streetman wrote: > > On Fri, Dec 2, 2016 at 9:44 AM, Michal Hocko wrote: > >

Re: [PATCH 05/22] staging: lustre: lmv: remove nlink check in lmv_revalidate_slaves

On Fri, Dec 02, 2016 at 07:53:12PM -0500, James Simmons wrote: > From: wang di > > Remove nlink < 2 check in lmv_revalidate_slaves, because > after nlink reaches to LDISKFS_LINK_MAX (65000), the inode > nlink will be set to 1. > I don't understand how this changelog matches

Re: [PATCH 05/22] staging: lustre: lmv: remove nlink check in lmv_revalidate_slaves

On Fri, Dec 02, 2016 at 07:53:12PM -0500, James Simmons wrote: > From: wang di > > Remove nlink < 2 check in lmv_revalidate_slaves, because > after nlink reaches to LDISKFS_LINK_MAX (65000), the inode > nlink will be set to 1. > I don't understand how this changelog matches the patch... The

Re: [PATCH 04/22] staging: lustre: osc: handle osc eviction correctly

On Fri, Dec 02, 2016 at 07:53:11PM -0500, James Simmons wrote: > @@ -3183,8 +3182,10 @@ static int discard_cb(const struct lu_env *env, struct > cl_io *io, > /* page is top page. */ > info->oti_next_index = osc_index(ops) + 1; > if (cl_page_own(env, io, page) == 0) { > -

Re: [PATCH 04/22] staging: lustre: osc: handle osc eviction correctly

On Fri, Dec 02, 2016 at 07:53:11PM -0500, James Simmons wrote: > @@ -3183,8 +3182,10 @@ static int discard_cb(const struct lu_env *env, struct > cl_io *io, > /* page is top page. */ > info->oti_next_index = osc_index(ops) + 1; > if (cl_page_own(env, io, page) == 0) { > -

Re: [PATCH v3 20/28] staging: iio: tsl2583: don't assume an unsigned int is 32 bits

On Thu, Nov 10, 2016 at 04:25:56AM -0500, Brian Masney wrote: > in_illuminance_lux_table_store assumes that an unsigned int is 32 bits. It's a totally safe assumption. The only problem is that it's less readable than sizeof(). regards, dan carpenter

Re: [PATCH v3 20/28] staging: iio: tsl2583: don't assume an unsigned int is 32 bits

On Thu, Nov 10, 2016 at 04:25:56AM -0500, Brian Masney wrote: > in_illuminance_lux_table_store assumes that an unsigned int is 32 bits. It's a totally safe assumption. The only problem is that it's less readable than sizeof(). regards, dan carpenter

Re: [PATCH 5/6] staging: lustre: headers: Move functions out of lustre_idl.h

On Fri, Dec 02, 2016 at 02:40:49PM -0500, James Simmons wrote: > -/* If LDLM_ENQUEUE, 1 slot is already occupied, 1 is available. > - * Otherwise, 2 are available. > - */ > -#define ldlm_request_bufsize(count, type)\ > -({

Re: [PATCH 5/6] staging: lustre: headers: Move functions out of lustre_idl.h

On Fri, Dec 02, 2016 at 02:40:49PM -0500, James Simmons wrote: > -/* If LDLM_ENQUEUE, 1 slot is already occupied, 1 is available. > - * Otherwise, 2 are available. > - */ > -#define ldlm_request_bufsize(count, type)\ > -({

Re: [PATCH 12/19] staging: iio: isl29028: fix comparison between signed and unsigned integers

On Sat, Dec 03, 2016 at 09:19:36PM -0500, Brian Masney wrote: > Fixed warning found by make W=2 to reduce the amount of build noise: > > warning: comparison between signed and unsigned integer expressions > [-Wsign-compare] Ugh... Please don't do work arounds for nonsense warnings. W=2 is so

Re: [PATCH 12/19] staging: iio: isl29028: fix comparison between signed and unsigned integers

On Sat, Dec 03, 2016 at 09:19:36PM -0500, Brian Masney wrote: > Fixed warning found by make W=2 to reduce the amount of build noise: > > warning: comparison between signed and unsigned integer expressions > [-Wsign-compare] Ugh... Please don't do work arounds for nonsense warnings. W=2 is so

Re: [PATCH] xen-scsifront: Add a missing call to kfree

On Mon, Nov 21, 2016 at 07:01:36AM +0100, Juergen Gross wrote: > On 19/11/16 19:22, Quentin Lambert wrote: > > Most error branches following the call to kmalloc contain > > a call to kfree. This patch add these calls where they are > > missing. > > > > This issue was found with Hector. > > > >

Re: [PATCH] xen-scsifront: Add a missing call to kfree

On Mon, Nov 21, 2016 at 07:01:36AM +0100, Juergen Gross wrote: > On 19/11/16 19:22, Quentin Lambert wrote: > > Most error branches following the call to kmalloc contain > > a call to kfree. This patch add these calls where they are > > missing. > > > > This issue was found with Hector. > > > >

Re: [PATCH v3 4/9] bus: fsl-mc: dpio: add frame descriptor and scatter/gather APIs

On Fri, Dec 02, 2016 at 12:12:14PM +, Laurentiu Tudor wrote: > > +static inline bool dpaa2_sg_is_final(const struct dpaa2_sg_entry *sg) > > +{ > > + return !!(le16_to_cpu(sg->format_offset) >> SG_FINAL_FLAG_SHIFT); > > In other places in this file we don't use the '!!' to convert to bool.

Re: [PATCH v3 4/9] bus: fsl-mc: dpio: add frame descriptor and scatter/gather APIs

On Fri, Dec 02, 2016 at 12:12:14PM +, Laurentiu Tudor wrote: > > +static inline bool dpaa2_sg_is_final(const struct dpaa2_sg_entry *sg) > > +{ > > + return !!(le16_to_cpu(sg->format_offset) >> SG_FINAL_FLAG_SHIFT); > > In other places in this file we don't use the '!!' to convert to bool.

Re: [PATCH] staging: lustre: Fix a spatch warning due to an assignment from kernel to user space

On Fri, Dec 02, 2016 at 06:33:32PM +0100, Quentin Lambert wrote: > lnet_ipif_enumerate was assigning a pointer from kernel space to user > space. This patch uses copy_to_user to properly do that assignment. Put the exact warning message here. > > Signed-off-by: Quentin Lambert

Re: [PATCH] staging: lustre: Fix a spatch warning due to an assignment from kernel to user space

On Fri, Dec 02, 2016 at 06:33:32PM +0100, Quentin Lambert wrote: > lnet_ipif_enumerate was assigning a pointer from kernel space to user > space. This patch uses copy_to_user to properly do that assignment. Put the exact warning message here. > > Signed-off-by: Quentin Lambert > --- >

Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut wrote: > On 12/05/2016 05:10 AM, Masahiro Yamada wrote: >> Hi Marek, >> >> >> 2016-12-05 12:44 GMT+09:00 Marek Vasut : >>> On 12/05/2016 04:30 AM, Masahiro Yamada wrote: Hi Dinh,

Re: [PATCH] staging: dgnc: Fix lines longer than 80 characters

On Fri, Dec 02, 2016 at 08:13:49PM +0100, Fernando Apesteguia wrote: > For the first lines of the patch, I opted to create a small function > instead of breaking the the line in a weird way. These first ones are the nice. > @@ -2511,13 +2516,15 @@ static int dgnc_tty_ioctl(struct tty_struct

Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut wrote: > On 12/05/2016 05:10 AM, Masahiro Yamada wrote: >> Hi Marek, >> >> >> 2016-12-05 12:44 GMT+09:00 Marek Vasut : >>> On 12/05/2016 04:30 AM, Masahiro Yamada wrote: Hi Dinh, 2016-12-04 7:08 GMT+09:00 Dinh Nguyen : > Hi,

Re: [PATCH] staging: dgnc: Fix lines longer than 80 characters

On Fri, Dec 02, 2016 at 08:13:49PM +0100, Fernando Apesteguia wrote: > For the first lines of the patch, I opted to create a small function > instead of breaking the the line in a weird way. These first ones are the nice. > @@ -2511,13 +2516,15 @@ static int dgnc_tty_ioctl(struct tty_struct

Re: [PATCH 3/6] staging: lustre: obdclass: Create a header for obdo related functions

On Fri, Dec 02, 2016 at 02:40:47PM -0500, James Simmons wrote: > - __u32 local_flags = 0; > + u32 local_flags = 0; > - if (local_flags != 0) { > + if (local_flags) { Please avoid these unrelated white space changes. regards, dan carpenter

Re: [PATCH 3/6] staging: lustre: obdclass: Create a header for obdo related functions

On Fri, Dec 02, 2016 at 02:40:47PM -0500, James Simmons wrote: > - __u32 local_flags = 0; > + u32 local_flags = 0; > - if (local_flags != 0) { > + if (local_flags) { Please avoid these unrelated white space changes. regards, dan carpenter

Re: [PATCH] objtool: fix build

On Mon, Dec 05, 2016 at 01:41:37PM +0100, Jiri Slaby wrote: > 0x8d opcode was handled twice. Fixed. > > Signed-off-by: Jiri Slaby I applied the other patch to the objtool-dwarf branch, but this one doesn't apply (the branch already has the changes this patch is trying to make).

Re: [PATCH] objtool: fix build

On Mon, Dec 05, 2016 at 01:41:37PM +0100, Jiri Slaby wrote: > 0x8d opcode was handled twice. Fixed. > > Signed-off-by: Jiri Slaby I applied the other patch to the objtool-dwarf branch, but this one doesn't apply (the branch already has the changes this patch is trying to make). > --- >

Re: bio linked list corruption.

Adding the scheduler people to the participants list, and re-attaching the patch, because while this patch is internal to the VM code, the issue itself is not. There might well be other cases where somebody goes "wake_up_all()" will wake everybody up, so I can put the wait queue head on the

Re: [PATCH] ARM: dts: imx7d: fix LCDIF clock assignment

On 2016-12-04 23:06, Uwe Kleine-König wrote: > Hello Stefan, > > On Sun, Dec 04, 2016 at 05:26:58PM -0800, Stefan Agner wrote: >> Since this fixes a kernel freeze, is there a chance to get this still in >> 4.9? > > a Fixes:-Line would be nice then. Good point. Fixes: e8ed73f691bd ("ARM: dts:

Re: bio linked list corruption.

Adding the scheduler people to the participants list, and re-attaching the patch, because while this patch is internal to the VM code, the issue itself is not. There might well be other cases where somebody goes "wake_up_all()" will wake everybody up, so I can put the wait queue head on the

Re: [PATCH] ARM: dts: imx7d: fix LCDIF clock assignment

On 2016-12-04 23:06, Uwe Kleine-König wrote: > Hello Stefan, > > On Sun, Dec 04, 2016 at 05:26:58PM -0800, Stefan Agner wrote: >> Since this fixes a kernel freeze, is there a chance to get this still in >> 4.9? > > a Fixes:-Line would be nice then. Good point. Fixes: e8ed73f691bd ("ARM: dts:

Re: [PATCH] net: calxeda: xgmac: use new api ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 4 Dec 2016 23:37:53 +0100 > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH] net: calxeda: xgmac: use new api ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 4 Dec 2016 23:37:53 +0100 > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 0/5] cpsw: add per channel shaper configuration

Hi Ivan, On 11/29/2016 09:00 AM, Ivan Khoronzhuk wrote: > This series is intended to allow user to set rate for per channel > shapers at cpdma level. This patchset doesn't have impact on performance. > The rate can be set with: > > echo 100 > /sys/class/net/ethX/queues/tx-0/tx_maxrate > >

RE: [PATCH] drm/amdgpu: don't add files at control minor debugfs directory

> -Original Message- > From: Nicolai Stange [mailto:nicsta...@gmail.com] > Sent: Monday, December 05, 2016 3:30 PM > To: Daniel Vetter > Cc: Deucher, Alexander; Koenig, Christian; Michel Dänzer; linux- > ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; Nicolai Stange > Subject:

RE: [PATCH] drm/amdgpu: don't add files at control minor debugfs directory

> -Original Message- > From: Nicolai Stange [mailto:nicsta...@gmail.com] > Sent: Monday, December 05, 2016 3:30 PM > To: Daniel Vetter > Cc: Deucher, Alexander; Koenig, Christian; Michel Dänzer; linux- > ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; Nicolai Stange > Subject:

Re: [PATCH 0/5] cpsw: add per channel shaper configuration

Hi Ivan, On 11/29/2016 09:00 AM, Ivan Khoronzhuk wrote: > This series is intended to allow user to set rate for per channel > shapers at cpdma level. This patchset doesn't have impact on performance. > The rate can be set with: > > echo 100 > /sys/class/net/ethX/queues/tx-0/tx_maxrate > >

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