Re: [PATCH v3 1/9] ASoC: rt5514: Switch to snd_soc_register_codec

On Thu, Aug 17, 2017 at 12:44:09PM +0800, Jeffy Chen wrote: > Currently we are using devm_snd_soc_register_component, which would > use legacy dai name. > Switch to snd_soc_register_codec to use dai driver name. This is the wrong direction to be going in, we are trying to move all drivers to use

Re: [PATCH v3 1/9] ASoC: rt5514: Switch to snd_soc_register_codec

On Thu, Aug 17, 2017 at 12:44:09PM +0800, Jeffy Chen wrote: > Currently we are using devm_snd_soc_register_component, which would > use legacy dai name. > Switch to snd_soc_register_codec to use dai driver name. This is the wrong direction to be going in, we are trying to move all drivers to use

Re: [PATCH v2] bpf: Update sysctl documentation to list all supported architectures

From: Michael Ellerman Date: Thu, 17 Aug 2017 20:30:39 +1000 > The sysctl documentation states that the JIT is only available on > x86_64, which is no longer correct. > > Update the list, and break it out to indicate which architectures > support the cBPF JIT (via

Re: [PATCH v2] bpf: Update sysctl documentation to list all supported architectures

From: Michael Ellerman Date: Thu, 17 Aug 2017 20:30:39 +1000 > The sysctl documentation states that the JIT is only available on > x86_64, which is no longer correct. > > Update the list, and break it out to indicate which architectures > support the cBPF JIT (via HAVE_CBPF_JIT) or the eBPF JIT

Re: [PATCH][net-next] net: hns3: ensure media_type is unitialized

From: Colin King Date: Thu, 17 Aug 2017 10:01:07 +0100 > From: Colin Ian King > > Media type is only set if h->ae_algo->ops->get_media_type is called > so there is a possibility that media_type is uninitialized when it is > used a switch

Re: [PATCH][net-next] net: hns3: ensure media_type is unitialized

From: Colin King Date: Thu, 17 Aug 2017 10:01:07 +0100 > From: Colin Ian King > > Media type is only set if h->ae_algo->ops->get_media_type is called > so there is a possibility that media_type is uninitialized when it is > used a switch statement. Fix this by initializing media_type to >

Re: [PATCH] liquidio: fix spelling mistake: "interuupt" -> "interrupt"

From: Colin King Date: Thu, 17 Aug 2017 09:19:30 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in dev_info message > > Signed-off-by: Colin Ian King Applied to net-next.

Re: [PATCH] liquidio: fix spelling mistake: "interuupt" -> "interrupt"

From: Colin King Date: Thu, 17 Aug 2017 09:19:30 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in dev_info message > > Signed-off-by: Colin Ian King Applied to net-next.

Re: [PATCH] staging: vboxvideo: make drm_fb_helper_funcs const

On Thu, Aug 17, 2017 at 10:33 PM, Greg KH wrote: > On Tue, Aug 08, 2017 at 09:15:42PM +0530, Bhumika Goyal wrote: >> Make the structure const as it is only passed to the function >> drm_fb_helper_prepare and the corresponding argument is of type >> const. >> Done using

Re: [PATCH] staging: vboxvideo: make drm_fb_helper_funcs const

On Thu, Aug 17, 2017 at 10:33 PM, Greg KH wrote: > On Tue, Aug 08, 2017 at 09:15:42PM +0530, Bhumika Goyal wrote: >> Make the structure const as it is only passed to the function >> drm_fb_helper_prepare and the corresponding argument is of type >> const. >> Done using Coccinelle. >> >>

Re: [PATCH 2/2] perf, tools: Avoid segfault on alias parse error

> So it will _not_ set to null a member that it doesn't have, i.e. the > minimal fix is to just have the hunks below, making sure that the error > field is present in both structs. No need to set > parse_event_terms->error to anything, it will be set to null since other > fields are set to

Re: [PATCH 2/2] perf, tools: Avoid segfault on alias parse error

> So it will _not_ set to null a member that it doesn't have, i.e. the > minimal fix is to just have the hunks below, making sure that the error > field is present in both structs. No need to set > parse_event_terms->error to anything, it will be set to null since other > fields are set to

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

From: Dexuan Cui Date: Thu, 17 Aug 2017 08:00:29 + > @@ -73,6 +74,10 @@ struct vmci_transport_recv_pkt_info { > struct vmci_transport_packet pkt; > }; > > +static bool skip_hypervisor_check; > +module_param(skip_hypervisor_check, bool, 0444); >

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

From: Dexuan Cui Date: Thu, 17 Aug 2017 08:00:29 + > @@ -73,6 +74,10 @@ struct vmci_transport_recv_pkt_info { > struct vmci_transport_packet pkt; > }; > > +static bool skip_hypervisor_check; > +module_param(skip_hypervisor_check, bool, 0444); > +MODULE_PARM_DESC(hot_add, "If set,

Re: [PATCH 07/10] cpufreq: dt: Add support for some new Allwinner SoCs

On Tue, Aug 15, 2017 at 8:39 PM, Chen-Yu Tsai wrote: > On Tue, Aug 15, 2017 at 8:25 PM, Rafael J. Wysocki wrote: >> On Tuesday, August 15, 2017 7:42:19 AM CEST Chen-Yu Tsai wrote: >>> On Mon, Jul 24, 2017 at 7:46 PM, Rafael J. Wysocki >>>

Re: [PATCH 07/10] cpufreq: dt: Add support for some new Allwinner SoCs

On Tue, Aug 15, 2017 at 8:39 PM, Chen-Yu Tsai wrote: > On Tue, Aug 15, 2017 at 8:25 PM, Rafael J. Wysocki wrote: >> On Tuesday, August 15, 2017 7:42:19 AM CEST Chen-Yu Tsai wrote: >>> On Mon, Jul 24, 2017 at 7:46 PM, Rafael J. Wysocki >>> wrote: >>> > On Monday, July 24, 2017 02:23:49 PM

Re: [PATCH] staging: vboxvideo: make drm_fb_helper_funcs const

On Tue, Aug 08, 2017 at 09:15:42PM +0530, Bhumika Goyal wrote: > Make the structure const as it is only passed to the function > drm_fb_helper_prepare and the corresponding argument is of type > const. > Done using Coccinelle. > > Signed-off-by: Bhumika Goyal > --- >

Re: [PATCH] staging: vboxvideo: make drm_fb_helper_funcs const

On Tue, Aug 08, 2017 at 09:15:42PM +0530, Bhumika Goyal wrote: > Make the structure const as it is only passed to the function > drm_fb_helper_prepare and the corresponding argument is of type > const. > Done using Coccinelle. > > Signed-off-by: Bhumika Goyal > --- >

Re: [PATCH 2/2] perf, tools: Avoid segfault on alias parse error

On Thu, Aug 17, 2017 at 01:25:39PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Aug 17, 2017 at 08:34:22AM -0700, Andi Kleen escreveu: > > > Humm, but don't we have that checked? > > > > At least not in the case of the segfault below. > > Again: > > tools/perf/util/parse-events.c > > 2523

Re: [PATCH 2/2] perf, tools: Avoid segfault on alias parse error

On Thu, Aug 17, 2017 at 01:25:39PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Aug 17, 2017 at 08:34:22AM -0700, Andi Kleen escreveu: > > > Humm, but don't we have that checked? > > > > At least not in the case of the segfault below. > > Again: > > tools/perf/util/parse-events.c > > 2523

Re: [PATCH 2/2] cpufreq: dt-platdev: Drop few entries from whitelist

On Wed, Aug 16, 2017 at 7:24 PM, Viresh Kumar wrote: > On 16-08-17, 16:53, Chen-Yu Tsai wrote: >> On Wed, Aug 16, 2017 at 1:37 PM, Viresh Kumar >> wrote: >> > Drop few ARM (32 and 64 bit) platforms from the whitelist which always >> > use

Re: [PATCH 2/2] cpufreq: dt-platdev: Drop few entries from whitelist

On Wed, Aug 16, 2017 at 7:24 PM, Viresh Kumar wrote: > On 16-08-17, 16:53, Chen-Yu Tsai wrote: >> On Wed, Aug 16, 2017 at 1:37 PM, Viresh Kumar >> wrote: >> > Drop few ARM (32 and 64 bit) platforms from the whitelist which always >> > use "operating-points-v2" property from their DT. They

Re: [PATCH] PCI: Allow PCI express root ports to find themselves

ributes to avoid Chelsio T5 > Completion erratum") > Signed-off-by: Thierry Reding <tred...@nvidia.com> Acked-by: Bjorn Helgaas <bhelg...@google.com> I *think* this should work for everybody, but I can't test it personally. > --- > This applies on top of and was tes

Re: [PATCH] PCI: Allow PCI express root ports to find themselves

T5 > Completion erratum") > Signed-off-by: Thierry Reding Acked-by: Bjorn Helgaas I *think* this should work for everybody, but I can't test it personally. > --- > This applies on top of and was tested on next-20170817. > > Michael, it'd be great if you could test this one

Re: [tip:x86/build 2/2] kernel/bounds.c:1: error: -mpreferred-stack-boundary=3 is not between 4 and 12

El Thu, Aug 17, 2017 at 10:13:20PM +0800 kbuild test robot ha dit: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/build > head: 8f91869766c00622b2eaa8ee567db4f333b78c1a > commit: 8f91869766c00622b2eaa8ee567db4f333b78c1a [2/2] x86/build: Fix stack > alignment for

Re: [tip:x86/build 2/2] kernel/bounds.c:1: error: -mpreferred-stack-boundary=3 is not between 4 and 12

El Thu, Aug 17, 2017 at 10:13:20PM +0800 kbuild test robot ha dit: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/build > head: 8f91869766c00622b2eaa8ee567db4f333b78c1a > commit: 8f91869766c00622b2eaa8ee567db4f333b78c1a [2/2] x86/build: Fix stack > alignment for

Re: [PATCH] iommu: Avoid NULL group dereference

On 17/08/17 16:41, Joerg Roedel wrote: > On Thu, Aug 17, 2017 at 11:40:08AM +0100, Robin Murphy wrote: >> The recently-removed FIXME in iommu_get_domain_for_dev() turns out to >> have been a little misleading, since that check is still worthwhile even >> when groups *are* universal. We have a few

Re: [PATCH] iommu: Avoid NULL group dereference

On 17/08/17 16:41, Joerg Roedel wrote: > On Thu, Aug 17, 2017 at 11:40:08AM +0100, Robin Murphy wrote: >> The recently-removed FIXME in iommu_get_domain_for_dev() turns out to >> have been a little misleading, since that check is still worthwhile even >> when groups *are* universal. We have a few

Re: [PATCH v2 1/2] wireless: move prism54 out to staging

On Mon, Aug 07, 2017 at 03:30:10PM -0700, Luis R. Rodriguez wrote: > prism54 is deprecated in favor of the p54pci device driver. Although > only *one soul* had reported issues with it long ago Linux most Linux > distributions these days just disable the device driver given the > conflicts with the

Re: [PATCH v2 1/2] wireless: move prism54 out to staging

On Mon, Aug 07, 2017 at 03:30:10PM -0700, Luis R. Rodriguez wrote: > prism54 is deprecated in favor of the p54pci device driver. Although > only *one soul* had reported issues with it long ago Linux most Linux > distributions these days just disable the device driver given the > conflicts with the

Re: [PATCH RFC 2/2] KVM: RCU protected dynamic vcpus array

On 17/08/2017 18:50, Radim Krčmář wrote: > 2017-08-17 13:14+0200, David Hildenbrand: >>> atomic_set(>online_vcpus, 0); >>> mutex_unlock(>lock); >>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h >>> index c8df733eed41..eb9fb5b493ac 100644 >>> ---

Re: [PATCH RFC 2/2] KVM: RCU protected dynamic vcpus array

On 17/08/2017 18:50, Radim Krčmář wrote: > 2017-08-17 13:14+0200, David Hildenbrand: >>> atomic_set(>online_vcpus, 0); >>> mutex_unlock(>lock); >>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h >>> index c8df733eed41..eb9fb5b493ac 100644 >>> ---

Re: warning: objtool: ...: call without frame pointer save/setup; return with modified stack frame

On Thu, Aug 17, 2017 at 04:09:58PM +0300, Meelis Roos wrote: > Today I coticed the following objtool warnings when compiling > 4.13-rc5+git for my Atom 330 PC: > > call without frame pointer save/setup > return with modified stack frame > > Examples (there is a lot more of them in practice): >

Re: warning: objtool: ...: call without frame pointer save/setup; return with modified stack frame

On Thu, Aug 17, 2017 at 04:09:58PM +0300, Meelis Roos wrote: > Today I coticed the following objtool warnings when compiling > 4.13-rc5+git for my Atom 330 PC: > > call without frame pointer save/setup > return with modified stack frame > > Examples (there is a lot more of them in practice): >

Re: [PATCH 02/13] iommu: Introduce Interface for IOMMU TLB Flushing

Hi Will, On Thu, Aug 17, 2017 at 05:32:35PM +0100, Will Deacon wrote: > I really like the idea of this, but I have a couple of questions and > comments below. Great, this together with the common iova-flush it should make it possible to solve the performance problems of the dma-iommu code. > >

Re: [PATCH 02/13] iommu: Introduce Interface for IOMMU TLB Flushing

Hi Will, On Thu, Aug 17, 2017 at 05:32:35PM +0100, Will Deacon wrote: > I really like the idea of this, but I have a couple of questions and > comments below. Great, this together with the common iova-flush it should make it possible to solve the performance problems of the dma-iommu code. > >

Re: [PATCH RFC 2/2] KVM: RCU protected dynamic vcpus array

2017-08-17 13:14+0200, David Hildenbrand: > > atomic_set(>online_vcpus, 0); > > mutex_unlock(>lock); > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > index c8df733eed41..eb9fb5b493ac 100644 > > --- a/include/linux/kvm_host.h > > +++ b/include/linux/kvm_host.h > > @@

Re: [PATCH RFC 2/2] KVM: RCU protected dynamic vcpus array

2017-08-17 13:14+0200, David Hildenbrand: > > atomic_set(>online_vcpus, 0); > > mutex_unlock(>lock); > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > index c8df733eed41..eb9fb5b493ac 100644 > > --- a/include/linux/kvm_host.h > > +++ b/include/linux/kvm_host.h > > @@

Re: [patch-rt] hotplug, hrtimer: Migrate expired/deferred timers during cpu offline

On 2017-08-14 09:59:48 [+0200], Mike Galbraith wrote: > On Fri, 2017-08-11 at 10:15 +0200, Mike Galbraith wrote: > > On Fri, 2017-08-11 at 09:55 +0200, Mike Galbraith wrote: > > > The below fixes the list debug explosion up. > > > > > > If we do not migrate expired/deferred timers during cpu

Re: [patch-rt] hotplug, hrtimer: Migrate expired/deferred timers during cpu offline

On 2017-08-14 09:59:48 [+0200], Mike Galbraith wrote: > On Fri, 2017-08-11 at 10:15 +0200, Mike Galbraith wrote: > > On Fri, 2017-08-11 at 09:55 +0200, Mike Galbraith wrote: > > > The below fixes the list debug explosion up. > > > > > > If we do not migrate expired/deferred timers during cpu

Re: [PATCH 4.4 018/101] netfilter: synproxy: fix conntrackd interaction

On Thu, Aug 17, 2017 at 07:57:07AM +0200, Stefan Bader wrote: > On 03.07.2017 15:34, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > We found that pulling below patch into stable trees without also pulling > > commit

Re: [PATCH 4.4 018/101] netfilter: synproxy: fix conntrackd interaction

On Thu, Aug 17, 2017 at 07:57:07AM +0200, Stefan Bader wrote: > On 03.07.2017 15:34, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > We found that pulling below patch into stable trees without also pulling > > commit

Re: [PATCH 2/2] perf, tools: Avoid segfault on alias parse error

Em Thu, Aug 17, 2017 at 12:28:16PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Aug 16, 2017 at 03:02:01PM -0700, Andi Kleen escreveu: > > +++ b/tools/perf/util/parse-events.h > > @@ -108,15 +108,17 @@ struct parse_events_error { > > char *help; /* optional help string */ > > }; >

Re: [PATCH 2/2] perf, tools: Avoid segfault on alias parse error

Em Thu, Aug 17, 2017 at 12:28:16PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Aug 16, 2017 at 03:02:01PM -0700, Andi Kleen escreveu: > > +++ b/tools/perf/util/parse-events.h > > @@ -108,15 +108,17 @@ struct parse_events_error { > > char *help; /* optional help string */ > > }; >

[PATCH 3/3] KVM: x86: fix use of L1 MMIO areas in nested guests

There is currently some confusion between nested and L1 GPAs. The assignment to "direct" in kvm_mmu_page_fault tries to fix that, but it is not enough. What this patch does is fence off the MMIO cache completely when using shadow nested page tables, since we have neither a GVA nor an L1 GPA to

[PATCH 3/3] KVM: x86: fix use of L1 MMIO areas in nested guests

There is currently some confusion between nested and L1 GPAs. The assignment to "direct" in kvm_mmu_page_fault tries to fix that, but it is not enough. What this patch does is fence off the MMIO cache completely when using shadow nested page tables, since we have neither a GVA nor an L1 GPA to

[PATCH 2/3] KVM: x86: Avoid guest page table walk when gpa_available is set

From: Brijesh Singh When a guest causes a page fault which requires emulation, the vcpu->arch.gpa_available flag is set to indicate that cr2 contains a valid GPA. Currently, emulator_read_write_onepage() makes use of gpa_available flag to avoid a guest page walk for a

[PATCH 2/3] KVM: x86: Avoid guest page table walk when gpa_available is set

From: Brijesh Singh When a guest causes a page fault which requires emulation, the vcpu->arch.gpa_available flag is set to indicate that cr2 contains a valid GPA. Currently, emulator_read_write_onepage() makes use of gpa_available flag to avoid a guest page walk for a known MMIO regions. Lets

[PATCH v2 0/3] KVM: MMU: pending MMU and nEPT patches

v2 has all the suggestions from David. Paolo Brijesh Singh (1): KVM: x86: Avoid guest page table walk when gpa_available is set Paolo Bonzini (3): KVM: x86: simplify ept_misconfig KVM: x86: fix use of L1 MMIO areas in nested guests KVM: x86: fix PML in nested guests

[PATCH v2 0/3] KVM: MMU: pending MMU and nEPT patches

v2 has all the suggestions from David. Paolo Brijesh Singh (1): KVM: x86: Avoid guest page table walk when gpa_available is set Paolo Bonzini (3): KVM: x86: simplify ept_misconfig KVM: x86: fix use of L1 MMIO areas in nested guests KVM: x86: fix PML in nested guests

[PATCH 1/3] KVM: x86: simplify ept_misconfig

Calling handle_mmio_page_fault() has been unnecessary since commit e9ee956e311d ("KVM: x86: MMU: Move handle_mmio_page_fault() call to kvm_mmu_page_fault()", 2016-02-22). handle_mmio_page_fault() can now be made static. Signed-off-by: Paolo Bonzini --- v1->v2: make

[PATCH 1/3] KVM: x86: simplify ept_misconfig

Calling handle_mmio_page_fault() has been unnecessary since commit e9ee956e311d ("KVM: x86: MMU: Move handle_mmio_page_fault() call to kvm_mmu_page_fault()", 2016-02-22). handle_mmio_page_fault() can now be made static. Signed-off-by: Paolo Bonzini --- v1->v2: make the function static.

Re: [RFC v2 2/4] iommu/arm-smmu-v3: Add tlbi_on_map option

On Fri, Aug 11, 2017 at 03:45:28PM +0200, Eric Auger wrote: > When running a virtual SMMU on a guest we sometimes need to trap > all changes to the translation structures. This is especially useful > to integrate with VFIO. This patch adds a new option that forces > the

Re: [RFC v2 2/4] iommu/arm-smmu-v3: Add tlbi_on_map option

On Fri, Aug 11, 2017 at 03:45:28PM +0200, Eric Auger wrote: > When running a virtual SMMU on a guest we sometimes need to trap > all changes to the translation structures. This is especially useful > to integrate with VFIO. This patch adds a new option that forces > the

Re: [PATCH 02/13] iommu: Introduce Interface for IOMMU TLB Flushing

Hi Joerg, I really like the idea of this, but I have a couple of questions and comments below. On Thu, Aug 17, 2017 at 02:56:25PM +0200, Joerg Roedel wrote: > From: Joerg Roedel > > With the current IOMMU-API the hardware TLBs have to be > flushed in every iommu_map(),

Re: [PATCH 02/13] iommu: Introduce Interface for IOMMU TLB Flushing

Hi Joerg, I really like the idea of this, but I have a couple of questions and comments below. On Thu, Aug 17, 2017 at 02:56:25PM +0200, Joerg Roedel wrote: > From: Joerg Roedel > > With the current IOMMU-API the hardware TLBs have to be > flushed in every iommu_map(), iommu_map_sg(), and >

Re: [PATCH][i2c-next] i2c-cht-wc: make cht_wc_i2c_adap_driver static

On Wed, Aug 16, 2017 at 10:16:59AM +0100, Colin King wrote: > From: Colin Ian King > > The structure cht_wc_i2c_adap_driver is local to the source > and does not need to be in global scope, so make it static. > > Cleans up sparse warning: > symbol

Re: [PATCH][i2c-next] i2c-cht-wc: make cht_wc_i2c_adap_driver static

On Wed, Aug 16, 2017 at 10:16:59AM +0100, Colin King wrote: > From: Colin Ian King > > The structure cht_wc_i2c_adap_driver is local to the source > and does not need to be in global scope, so make it static. > > Cleans up sparse warning: > symbol 'cht_wc_i2c_adap_driver' was not declared.

Re: [PATCH v4] livepatch: introduce shadow variable API

On Thu, Aug 17, 2017 at 12:01:33PM -0400, Joe Lawrence wrote: > Without a good real-world example, you've convinced me that > klp_shadow_update_or_attach() could be dropped. I think this will also > simplify the requirements of a shared __klp_shadow_get_or_attach() like > you sketched out

Re: [PATCH v4] livepatch: introduce shadow variable API

On Thu, Aug 17, 2017 at 12:01:33PM -0400, Joe Lawrence wrote: > Without a good real-world example, you've convinced me that > klp_shadow_update_or_attach() could be dropped. I think this will also > simplify the requirements of a shared __klp_shadow_get_or_attach() like > you sketched out

[RFC] memory allocations in genalloc

Foreword: If I should direct this message to someone else, please let me know. I couldn't get a clear idea, by looking at both MAINTAINERS and git blame. Hi, I'm currently trying to convert the SE Linux policy db into using a protectable memory allocator (pmalloc) that I have developed.

[RFC] memory allocations in genalloc

Foreword: If I should direct this message to someone else, please let me know. I couldn't get a clear idea, by looking at both MAINTAINERS and git blame. Hi, I'm currently trying to convert the SE Linux policy db into using a protectable memory allocator (pmalloc) that I have developed.

Re: [PATCH] staging: lustre: fix structure size for ARM OABI

On Wed, Aug 16, 2017 at 05:44:15PM +0300, Cihangir Akturk wrote: > When building the kernel for the ARM architecture without setting > CONFIG_AEABI, size of struct lov_user_md_v3 and struct lov_mds_md_v3 > differs, due to different alignment requirements of OABI and EABI. > > Marking the

Re: [PATCH] staging: lustre: fix structure size for ARM OABI

On Wed, Aug 16, 2017 at 05:44:15PM +0300, Cihangir Akturk wrote: > When building the kernel for the ARM architecture without setting > CONFIG_AEABI, size of struct lov_user_md_v3 and struct lov_mds_md_v3 > differs, due to different alignment requirements of OABI and EABI. > > Marking the

Re: [PATCH 2/2] perf, tools: Avoid segfault on alias parse error

Em Thu, Aug 17, 2017 at 08:34:22AM -0700, Andi Kleen escreveu: > > Humm, but don't we have that checked? > > At least not in the case of the segfault below. Again: tools/perf/util/parse-events.c 2523 void parse_events_evlist_error(struct parse_events_evlist *data, 2524

Re: [PATCH 2/2] perf, tools: Avoid segfault on alias parse error

Em Thu, Aug 17, 2017 at 08:34:22AM -0700, Andi Kleen escreveu: > > Humm, but don't we have that checked? > > At least not in the case of the segfault below. Again: tools/perf/util/parse-events.c 2523 void parse_events_evlist_error(struct parse_events_evlist *data, 2524

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Thu, Aug 17, 2017 at 9:17 AM, Liang, Kan wrote: > > We tried both 12 and 16 bit table and that didn't make a difference. > The long wake ups are mostly on the same page when we do instrumentation Ok. > Here is the wake_up_page_bit call stack when the workaround is

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Thu, Aug 17, 2017 at 9:17 AM, Liang, Kan wrote: > > We tried both 12 and 16 bit table and that didn't make a difference. > The long wake ups are mostly on the same page when we do instrumentation Ok. > Here is the wake_up_page_bit call stack when the workaround is running, which > is

Re: [PATCH v2] blktrace: Fix potentail deadlock between delete & sysfs ops

On 08/17/2017 09:34 AM, Steven Rostedt wrote: > On Wed, 16 Aug 2017 16:40:40 -0400 > Waiman Long wrote: > >> The lockdep code had reported the following unsafe locking scenario: >> >>CPU0CPU1 >> >>

Re: [PATCH v2] blktrace: Fix potentail deadlock between delete & sysfs ops

On 08/17/2017 09:34 AM, Steven Rostedt wrote: > On Wed, 16 Aug 2017 16:40:40 -0400 > Waiman Long wrote: > >> The lockdep code had reported the following unsafe locking scenario: >> >>CPU0CPU1 >> >> lock(s_active#228); >>

Re: [PATCH v2 2/3] i2c: davinci: Add PM Runtime Support

On Wed, Aug 16, 2017 at 05:17:14PM -0500, Franklin S Cooper Jr wrote: > 66AK2G has I2C instances that are not apart of the ALWAYS_ON power domain > like other Keystone 2 SoCs and OMAPL138. Therefore, pm_runtime > is required to insure the power domain used by the specific I2C instance is >

Re: [PATCH v2 2/3] i2c: davinci: Add PM Runtime Support

On Wed, Aug 16, 2017 at 05:17:14PM -0500, Franklin S Cooper Jr wrote: > 66AK2G has I2C instances that are not apart of the ALWAYS_ON power domain > like other Keystone 2 SoCs and OMAPL138. Therefore, pm_runtime > is required to insure the power domain used by the specific I2C instance is >

Re: [PATCH v2 01/14] staging: lustre: llite: Remove filtering of seclabel xattr

On Mon, Aug 14, 2017 at 12:20:51PM -0400, James Simmons wrote: > From: Robin Humble > > The security.capability xattr is used to implement File > Capabilities in recent Linux versions. Capabilities are a > fine grained approach to granting executables elevated >

Re: [PATCH v2 01/14] staging: lustre: llite: Remove filtering of seclabel xattr

On Mon, Aug 14, 2017 at 12:20:51PM -0400, James Simmons wrote: > From: Robin Humble > > The security.capability xattr is used to implement File > Capabilities in recent Linux versions. Capabilities are a > fine grained approach to granting executables elevated > privileges. eg. /bin/ping can

Re: [PATCH 00/64] staging: lustre: uapi: normalize the lustre headers

On Mon, Aug 14, 2017 at 11:46:28AM -0400, James Simmons wrote: > The headers for lustre/LNet for a long time lacked a clean separation in > its internal headers which resulted in kernel specific data structures > being exposed in user land code. This work unravels this mess and creates > a clear

Re: [PATCH 00/64] staging: lustre: uapi: normalize the lustre headers

On Mon, Aug 14, 2017 at 11:46:28AM -0400, James Simmons wrote: > The headers for lustre/LNet for a long time lacked a clean separation in > its internal headers which resulted in kernel specific data structures > being exposed in user land code. This work unravels this mess and creates > a clear

RE: [PATCH 1/2] sched/wait: Break up long wake list walk

> On Mon, Aug 14, 2017 at 5:52 PM, Tim Chen > wrote: > > We encountered workloads that have very long wake up list on large > > systems. A waker takes a long time to traverse the entire wake list > > and execute all the wake functions. > > > > We saw page wait list

RE: [PATCH 1/2] sched/wait: Break up long wake list walk

> On Mon, Aug 14, 2017 at 5:52 PM, Tim Chen > wrote: > > We encountered workloads that have very long wake up list on large > > systems. A waker takes a long time to traverse the entire wake list > > and execute all the wake functions. > > > > We saw page wait list that are up to 3700+ entries

Re: [GIT PULL 2/2] bcm2835-soc-next-2017-08-15

Florian Fainelli writes: > On 08/15/2017 11:03 AM, Eric Anholt wrote: >> The following changes since commit f29c256853b7412961d3ee80ca525bd2530573db: >> >> ARM: dts: bcm283x: Add 32-bit enable method for SMP (2017-08-14 20:09:44 >> +0200) >> >> are available in the git

Re: [GIT PULL 2/2] bcm2835-soc-next-2017-08-15

Florian Fainelli writes: > On 08/15/2017 11:03 AM, Eric Anholt wrote: >> The following changes since commit f29c256853b7412961d3ee80ca525bd2530573db: >> >> ARM: dts: bcm283x: Add 32-bit enable method for SMP (2017-08-14 20:09:44 >> +0200) >> >> are available in the git repository at: >> >>

[PATCH] xen/events: events_fifo: Don't use {get,put}_cpu() in xen_evtchn_fifo_init()

When booting Linux as Xen guest with CONFIG_DEBUG_ATOMIC, the following splat appears: [0.002323] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes) [0.019717] ASID allocator initialised with 65536 entries [0.020019] xen:grant_table: Grant tables using version 1 layout [

[PATCH] xen/events: events_fifo: Don't use {get,put}_cpu() in xen_evtchn_fifo_init()

When booting Linux as Xen guest with CONFIG_DEBUG_ATOMIC, the following splat appears: [0.002323] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes) [0.019717] ASID allocator initialised with 65536 entries [0.020019] xen:grant_table: Grant tables using version 1 layout [

[PATCH] xen/events: events_fifo: Don't use {get,put}_cpu() in xen_evtchn_fifo_init()

When booting Linux as Xen guest with CONFIG_DEBUG_ATOMIC, the following splat appears: [0.002323] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes) [0.019717] ASID allocator initialised with 65536 entries [0.020019] xen:grant_table: Grant tables using version 1 layout [

[PATCH] xen/events: events_fifo: Don't use {get,put}_cpu() in xen_evtchn_fifo_init()

When booting Linux as Xen guest with CONFIG_DEBUG_ATOMIC, the following splat appears: [0.002323] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes) [0.019717] ASID allocator initialised with 65536 entries [0.020019] xen:grant_table: Grant tables using version 1 layout [

[tip:locking/core 37/41] drivers/block//drbd/drbd_receiver.c:1159:1: warning: the frame size of 1072 bytes is larger than 1024 bytes

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core head: e26f34a407aec9c65bce2bc0c838fabe4f051fc6 commit: d0541b0fa64b36665d6261079974a26943c75009 [37/41] locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE part of CONFIG_PROVE_LOCKING config: s390-default_defconfig

[tip:locking/core 37/41] drivers/block//drbd/drbd_receiver.c:1159:1: warning: the frame size of 1072 bytes is larger than 1024 bytes

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core head: e26f34a407aec9c65bce2bc0c838fabe4f051fc6 commit: d0541b0fa64b36665d6261079974a26943c75009 [37/41] locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE part of CONFIG_PROVE_LOCKING config: s390-default_defconfig

Re: [PATCH v7] serio: PS/2 gpio bit banging driver for serio bus

Hi Bob, thanks for reviewing. On 2017-08-17 17:43, Rob Herring wrote: On Fri, Aug 11, 2017 at 03:17:36PM +0200, Danilo Krummrich wrote: This driver provides PS/2 serio bus support by implementing bit banging with the GPIO API. The GPIO pins, data and clock, can be configured with a node in

Re: [PATCH v7] serio: PS/2 gpio bit banging driver for serio bus

Hi Bob, thanks for reviewing. On 2017-08-17 17:43, Rob Herring wrote: On Fri, Aug 11, 2017 at 03:17:36PM +0200, Danilo Krummrich wrote: This driver provides PS/2 serio bus support by implementing bit banging with the GPIO API. The GPIO pins, data and clock, can be configured with a node in

Re: [RFC PATCH 5/7] dt-bindings: ti-omap-hsmmc: Document new compatible for sdhci omap

* Kishon Vijay Abraham I [170816 22:44]: > Hi Tony, > > On Thursday 10 August 2017 03:42 AM, Tony Lindgren wrote: > > * Kishon Vijay Abraham I [170807 09:03]: > >> Document the new compatible string "ti,dra7-sdhci" to be used for > >> MMC controllers in DRA7 and

Re: [RFC PATCH 5/7] dt-bindings: ti-omap-hsmmc: Document new compatible for sdhci omap

* Kishon Vijay Abraham I [170816 22:44]: > Hi Tony, > > On Thursday 10 August 2017 03:42 AM, Tony Lindgren wrote: > > * Kishon Vijay Abraham I [170807 09:03]: > >> Document the new compatible string "ti,dra7-sdhci" to be used for > >> MMC controllers in DRA7 and DRA72 SoCs. > > > > I wonder if

Re: smp-induced oops/NULL pointer dereference in mpt3sas, from kernel >= 4.11

On Thu, 2017-08-17 at 15:18 +0530, Chaitra Basappa wrote: > We analyzed this issue and could figure out it is not because of driver, > its because the "sense" field of the 'struct scsi_request' is not being > populated properly from the upper layer. > And this "sense" member is being referenced in

Re: smp-induced oops/NULL pointer dereference in mpt3sas, from kernel >= 4.11

On Thu, 2017-08-17 at 15:18 +0530, Chaitra Basappa wrote: > We analyzed this issue and could figure out it is not because of driver, > its because the "sense" field of the 'struct scsi_request' is not being > populated properly from the upper layer. > And this "sense" member is being referenced in

Re: [PATCH v4] livepatch: introduce shadow variable API

On 08/17/2017 10:05 AM, Petr Mladek wrote: > On Mon 2017-08-14 16:02:43, Joe Lawrence wrote: >> Add exported API for livepatch modules: >> >> klp_shadow_get() >> klp_shadow_attach() >> klp_shadow_get_or_attach() >> klp_shadow_update_or_attach() >> klp_shadow_detach() >>

Re: [PATCH v4] livepatch: introduce shadow variable API

On 08/17/2017 10:05 AM, Petr Mladek wrote: > On Mon 2017-08-14 16:02:43, Joe Lawrence wrote: >> Add exported API for livepatch modules: >> >> klp_shadow_get() >> klp_shadow_attach() >> klp_shadow_get_or_attach() >> klp_shadow_update_or_attach() >> klp_shadow_detach() >>

Re: [PATCH v5 6/6] perf: ARM DynamIQ Shared Unit PMU support

On Thu, Aug 17, 2017 at 03:52:24PM +0100, Suzuki K Poulose wrote: > On 16/08/17 15:10, Mark Rutland wrote: > >On Tue, Aug 08, 2017 at 12:37:26PM +0100, Suzuki K Poulose wrote: > >>+static struct attribute *dsu_pmu_event_attrs[] = { > >>+ DSU_EVENT_ATTR(cycles, 0x11), > >>+

Re: [PATCH v5 6/6] perf: ARM DynamIQ Shared Unit PMU support

On Thu, Aug 17, 2017 at 03:52:24PM +0100, Suzuki K Poulose wrote: > On 16/08/17 15:10, Mark Rutland wrote: > >On Tue, Aug 08, 2017 at 12:37:26PM +0100, Suzuki K Poulose wrote: > >>+static struct attribute *dsu_pmu_event_attrs[] = { > >>+ DSU_EVENT_ATTR(cycles, 0x11), > >>+

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

On Wed, 2017-08-16 at 18:18 -0500, Brian King wrote: > On 08/16/2017 12:21 PM, Bart Van Assche wrote: > > On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote: > > > As of next-20170809, linux-next on powerpc boot hung with below trace > > > message. > > > > > > [ ... ] > > > > > > A bisection

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

On Wed, 2017-08-16 at 18:18 -0500, Brian King wrote: > On 08/16/2017 12:21 PM, Bart Van Assche wrote: > > On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote: > > > As of next-20170809, linux-next on powerpc boot hung with below trace > > > message. > > > > > > [ ... ] > > > > > > A bisection

Re: [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

On Thu, Aug 17, 2017 at 3:35 AM, Will Deacon wrote: > On Tue, Aug 15, 2017 at 11:35:41PM +0100, Mark Rutland wrote: >> On Wed, Aug 16, 2017 at 09:14:41AM -0700, Andy Lutomirski wrote: >> > On Wed, Aug 16, 2017 at 5:57 AM, Matt Fleming >> > wrote:

Re: [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

On Thu, Aug 17, 2017 at 3:35 AM, Will Deacon wrote: > On Tue, Aug 15, 2017 at 11:35:41PM +0100, Mark Rutland wrote: >> On Wed, Aug 16, 2017 at 09:14:41AM -0700, Andy Lutomirski wrote: >> > On Wed, Aug 16, 2017 at 5:57 AM, Matt Fleming >> > wrote: >> > > On Wed, 16 Aug, at 12:03:22PM, Mark

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