Re: [PATCH v3 0/8] try to reduce fragmenting fallbacks

On Wed, Mar 08, 2017 at 08:17:39PM +0100, Vlastimil Babka wrote: > On 8.3.2017 17:46, Johannes Weiner wrote: > > Is there any other data you would like me to gather? > > If you can enable the extfrag tracepoint, it would be nice to have graphs of > how > unmovable allocations falling back to

Re: [PATCH v3 0/8] try to reduce fragmenting fallbacks

On Wed, Mar 08, 2017 at 08:17:39PM +0100, Vlastimil Babka wrote: > On 8.3.2017 17:46, Johannes Weiner wrote: > > Is there any other data you would like me to gather? > > If you can enable the extfrag tracepoint, it would be nice to have graphs of > how > unmovable allocations falling back to

[net-next PATCH 5/5] epoll: Add busy poll support to epoll with socket fds.

From: Sridhar Samudrala This patch adds busy poll support to epoll if all the sockets attached to an epoll fd receive packets from the same receive queue(NAPI ID). NAPI ID is maintained per epoll and is set from sk when the first event is received for a socket with a

[net-next PATCH 5/5] epoll: Add busy poll support to epoll with socket fds.

From: Sridhar Samudrala This patch adds busy poll support to epoll if all the sockets attached to an epoll fd receive packets from the same receive queue(NAPI ID). NAPI ID is maintained per epoll and is set from sk when the first event is received for a socket with a non-zero NAPI ID. It is

[net-next PATCH 4/5] net: Commonize busy polling code to focus on napi_id instead of socket

From: Sridhar Samudrala Move the core functionality in sk_busy_loop() to napi_busy_loop() and make it independent of sk. This enables re-using this function in epoll busy loop implementation. Signed-off-by: Sridhar Samudrala

[net-next PATCH 3/5] net: Introduce SO_INCOMING_NAPI_ID

From: Sridhar Samudrala This socket option returns the napi id associated with the queue on which the last frame is received. This information can be used by the apps to split the incoming flows among the threads based on the Rx queue on which they are received.

[net-next PATCH 3/5] net: Introduce SO_INCOMING_NAPI_ID

From: Sridhar Samudrala This socket option returns the napi id associated with the queue on which the last frame is received. This information can be used by the apps to split the incoming flows among the threads based on the Rx queue on which they are received. Signed-off-by: Sridhar Samudrala

[net-next PATCH 4/5] net: Commonize busy polling code to focus on napi_id instead of socket

From: Sridhar Samudrala Move the core functionality in sk_busy_loop() to napi_busy_loop() and make it independent of sk. This enables re-using this function in epoll busy loop implementation. Signed-off-by: Sridhar Samudrala Signed-off-by: Alexander Duyck --- include/net/busy_poll.h |9

[net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

From: Sridhar Samudrala Fix sk_mark_napi_id() and sk_mark_napi_id_once() to set sk_napi_id only if skb->napi_id is a valid value. This happens in loopback paths where skb->napi_id is not updated in rx path and holds sender_cpu that is set in xmit path.

[net-next PATCH 0/5] Add busy poll support for epoll under certain circumstances

This patch series is meant to add busy polling support to epoll when all of the sockets on a given epoll are either local or are being sourced by the same NAPI ID. In order to support this the first two patches clean up a few issues we found with the NAPI ID tracking and infrastructure. In the

[net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

From: Sridhar Samudrala Fix sk_mark_napi_id() and sk_mark_napi_id_once() to set sk_napi_id only if skb->napi_id is a valid value. This happens in loopback paths where skb->napi_id is not updated in rx path and holds sender_cpu that is set in xmit path. Signed-off-by: Sridhar Samudrala

[net-next PATCH 0/5] Add busy poll support for epoll under certain circumstances

This patch series is meant to add busy polling support to epoll when all of the sockets on a given epoll are either local or are being sourced by the same NAPI ID. In order to support this the first two patches clean up a few issues we found with the NAPI ID tracking and infrastructure. In the

Re: [PATCH v4 0/7] mmc: bcm2835: Add new driver for the sdhost controller

Gerd Hoffmann writes: > Hi, > > Next version if the bcm2835 sdhost patch series. Still waiting for the subsystem maintainer to merge the driver before merging the platform side. signature.asc Description: PGP signature

Re: [PATCH v4 0/7] mmc: bcm2835: Add new driver for the sdhost controller

Gerd Hoffmann writes: > Hi, > > Next version if the bcm2835 sdhost patch series. Still waiting for the subsystem maintainer to merge the driver before merging the platform side. signature.asc Description: PGP signature

Re: [PATCH v4 0/5] ARM: K2G: Add support for TI-SCI Generic PM Domains

Santosh, On 03/12/2017 12:02 PM, Rafael J. Wysocki wrote: > On Tuesday, March 07, 2017 04:22:29 AM Dave Gerlach wrote: >> Hi, >> This is v4 of the series to add support for TI-SCI Generic PM Domains. >> Previous versions can be found here: >> >> v3:

Re: [PATCH v4 0/5] ARM: K2G: Add support for TI-SCI Generic PM Domains

Santosh, On 03/12/2017 12:02 PM, Rafael J. Wysocki wrote: > On Tuesday, March 07, 2017 04:22:29 AM Dave Gerlach wrote: >> Hi, >> This is v4 of the series to add support for TI-SCI Generic PM Domains. >> Previous versions can be found here: >> >> v3:

Re: [PATCH v2 net-next 4/5] sunvnet: count multicast packets

From: David Laight Date: Thu, 16 Mar 2017 12:12:06 + > From: Shannon Nelson >> Sent: 16 March 2017 00:18 >> To: David Laight; net...@vger.kernel.org; da...@davemloft.net >> On 3/15/2017 1:50 AM, David Laight wrote: >> > From: Shannon Nelson >> >> Sent: 14 March 2017

Re: [PATCH v2 net-next 4/5] sunvnet: count multicast packets

From: David Laight Date: Thu, 16 Mar 2017 12:12:06 + > From: Shannon Nelson >> Sent: 16 March 2017 00:18 >> To: David Laight; net...@vger.kernel.org; da...@davemloft.net >> On 3/15/2017 1:50 AM, David Laight wrote: >> > From: Shannon Nelson >> >> Sent: 14 March 2017 17:25 >> > ... >> >> + if

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

Let's take a step back and try to figure out how is mwait called. How about dumping code of VCPUs around mwait? gdb disa command will do this. -- MST

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

Let's take a step back and try to figure out how is mwait called. How about dumping code of VCPUs around mwait? gdb disa command will do this. -- MST

[PATCH 4/9] net, ipv6: convert ifmcaddr6.mca_refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 4/9] net, ipv6: convert ifmcaddr6.mca_refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by: Hans Liljestrand

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Fri, Mar 10, 2017 at 04:41:56PM -0600, Brijesh Singh wrote: > I can take a look at fixing those warning. In my initial attempt was to create > a new function to clear encryption bit but it ended up looking very similar to > __change_page_attr_set_clr() hence decided to extend the exiting

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On Fri, Mar 10, 2017 at 04:41:56PM -0600, Brijesh Singh wrote: > I can take a look at fixing those warning. In my initial attempt was to create > a new function to clear encryption bit but it ended up looking very similar to > __change_page_attr_set_clr() hence decided to extend the exiting

[PATCH v5 3/5] dt-bindings: Add TI SCI PM Domains

Add a generic power domain implementation, TI SCI PM Domains, that will hook into the genpd framework and allow the TI SCI protocol to control device power states. Also, provide macros representing each device index as understood by TI SCI to be used in the device node power-domain references.

[PATCH v5 3/5] dt-bindings: Add TI SCI PM Domains

Add a generic power domain implementation, TI SCI PM Domains, that will hook into the genpd framework and allow the TI SCI protocol to control device power states. Also, provide macros representing each device index as understood by TI SCI to be used in the device node power-domain references.

[PATCH 6/9] net, ipv6: convert xfrm6_tunnel_spi.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 6/9] net, ipv6: convert xfrm6_tunnel_spi.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by: Hans Liljestrand

[PATCH 3/9] net, ipv6: convert inet6_ifaddr.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 0/9] net, ipv4, ipv6 refcounter conversions

This series, for ipv4/ipv6 components, replaces atomic_t reference counters with the new refcount_t type and API (see include/linux/refcount.h). By doing this we prevent intentional or accidental underflows or overflows that can led to use-after-free vulnerabilities. The patches are fully

[PATCH 2/9] net, ipv6: convert inet6_dev.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 3/9] net, ipv6: convert inet6_ifaddr.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by: Hans Liljestrand

[PATCH 0/9] net, ipv4, ipv6 refcounter conversions

This series, for ipv4/ipv6 components, replaces atomic_t reference counters with the new refcount_t type and API (see include/linux/refcount.h). By doing this we prevent intentional or accidental underflows or overflows that can led to use-after-free vulnerabilities. The patches are fully

[PATCH 2/9] net, ipv6: convert inet6_dev.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by: Hans Liljestrand

Re: [PATCH v15 6/9] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

On Thu, Mar 16, 2017 at 7:30 AM, Kyle Huey wrote: > On Thu, Mar 16, 2017 at 4:09 AM, Michael Ellerman wrote: >> >> Presumably he's done: >> >> $ git config diff.context 8 > > Indeed. In my case it dates back to my days hacking on Firefox, which > wants 8

[PATCH 5/9] net, ipv6: convert ifacaddr6.aca_refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

Re: [PATCH v15 6/9] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

On Thu, Mar 16, 2017 at 7:30 AM, Kyle Huey wrote: > On Thu, Mar 16, 2017 at 4:09 AM, Michael Ellerman wrote: >> >> Presumably he's done: >> >> $ git config diff.context 8 > > Indeed. In my case it dates back to my days hacking on Firefox, which > wants 8 lines of context for patches. I'll

[PATCH 5/9] net, ipv6: convert ifacaddr6.aca_refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by: Hans Liljestrand

Re: [RESEND PATCH 1/2] auxdisplay: img-ascii-lcd: Add a sentinel entry to OF device ID table

On Fri, Mar 10, 2017 at 10:22 AM, Dmitry Torokhov wrote: > > On Fri, Mar 10, 2017 at 10:33:06AM -0300, Javier Martinez Canillas wrote: > > The OF device ID table doesn't have a sentinel NULL entry and so it > > causes the following error: > > > > FATAL:

Re: [RESEND PATCH 1/2] auxdisplay: img-ascii-lcd: Add a sentinel entry to OF device ID table

On Fri, Mar 10, 2017 at 10:22 AM, Dmitry Torokhov wrote: > > On Fri, Mar 10, 2017 at 10:33:06AM -0300, Javier Martinez Canillas wrote: > > The OF device ID table doesn't have a sentinel NULL entry and so it > > causes the following error: > > > > FATAL: drivers/auxdisplay/img-ascii-lcd: struct

[PATCH 8/9] net, ipv4: convert cipso_v4_doi.refcount from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 8/9] net, ipv4: convert cipso_v4_doi.refcount from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by: Hans Liljestrand

[PATCH 9/9] net, ipv4: convert fib_info.fib_clntref from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 9/9] net, ipv4: convert fib_info.fib_clntref from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by: Hans Liljestrand

[PATCH 7/9] net, ipv6: convert ip6addrlbl_entry.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 7/9] net, ipv6: convert ip6addrlbl_entry.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by: Hans Liljestrand

[PATCH 1/9] net, ipv6: convert ipv6_txoptions.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 1/9] net, ipv6: convert ipv6_txoptions.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by: Hans Liljestrand

Re: [PATCH v2] ARM: zynq: Add #io-channel-cells to (x)adc node for iio-hwmon

On 16.3.2017 17:51, Lars-Peter Clausen wrote: > On 03/16/2017 05:45 PM, Michal Simek wrote: >> On 16.3.2017 17:39, Moritz Fischer wrote: >>> On Thu, Mar 16, 2017 at 9:16 AM, Michal Simek >>> wrote: Hi, On 8.3.2017 21:11, Moritz Fischer wrote: > Fix

Re: [PATCH v2] ARM: zynq: Add #io-channel-cells to (x)adc node for iio-hwmon

On 16.3.2017 17:51, Lars-Peter Clausen wrote: > On 03/16/2017 05:45 PM, Michal Simek wrote: >> On 16.3.2017 17:39, Moritz Fischer wrote: >>> On Thu, Mar 16, 2017 at 9:16 AM, Michal Simek >>> wrote: Hi, On 8.3.2017 21:11, Moritz Fischer wrote: > Fix > > OF: /iio_hwmon:

Re: [PATCH v2 1/1] mm: zswap - Add crypto acomp/scomp framework support

On Thu, Mar 16, 2017 at 12:33 PM, Herbert Xu wrote: > On Wed, Mar 08, 2017 at 12:38:40PM -0500, Dan Streetman wrote: >> >> >> setting the ASYNC bit makes it synchronous? that seems backwards...? > > You set the ASYNC bit in the mask and leave it clear in the type. >

Re: [PATCH v2 1/1] mm: zswap - Add crypto acomp/scomp framework support

On Thu, Mar 16, 2017 at 12:33 PM, Herbert Xu wrote: > On Wed, Mar 08, 2017 at 12:38:40PM -0500, Dan Streetman wrote: >> >> >> setting the ASYNC bit makes it synchronous? that seems backwards...? > > You set the ASYNC bit in the mask and leave it clear in the type. > That way only algorithms with

[PATCH v2 2/3] kvm: arm/arm64: Take mmap_sem in kvm_arch_prepare_memory_region

From: Marc Zyngier We don't hold the mmap_sem while searching for VMAs (via find_vma), in kvm_arch_prepare_memory_region, which can end up in expected failures. Fixes: commit 8eef91239e57 ("arm/arm64: KVM: map MMIO regions at creation time") Cc: Ard Biesheuvel

[PATCH v2 2/3] kvm: arm/arm64: Take mmap_sem in kvm_arch_prepare_memory_region

From: Marc Zyngier We don't hold the mmap_sem while searching for VMAs (via find_vma), in kvm_arch_prepare_memory_region, which can end up in expected failures. Fixes: commit 8eef91239e57 ("arm/arm64: KVM: map MMIO regions at creation time") Cc: Ard Biesheuvel Cc: Eric Auger Cc:

Re: [PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

On Thu, Mar 16, 2017 at 11:09 AM, Steven Rostedt wrote: > + > + /* Since we don't care about cs, move flags there to simplify return > */ > + movl14*4(%esp), %eax > + movl%eax, 13*4(%esp) > + > + /* Move return ip back to its original location

Re: [PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

On Thu, Mar 16, 2017 at 11:09 AM, Steven Rostedt wrote: > + > + /* Since we don't care about cs, move flags there to simplify return > */ > + movl14*4(%esp), %eax > + movl%eax, 13*4(%esp) > + > + /* Move return ip back to its original location */ > + movl

[PATCH v2 3/3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling unmap_stage2_range() on the entire memory range for the guest. This could cause problems with other callers (e.g, munmap on a memslot) trying to unmap a range. And since we have to unmap the entire Guest memory range holding a

[PATCH v2 3/3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling unmap_stage2_range() on the entire memory range for the guest. This could cause problems with other callers (e.g, munmap on a memslot) trying to unmap a range. And since we have to unmap the entire Guest memory range holding a

[PATCH v2 0/3] kvm: arm/arm64: Fixes for use after free problems

This series contains potential fixes for problems reported by [0] & [1]. [0] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492944.html [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492943.html Changes since V1: - Yield the kvm->mmu_lock if necessary in

[PATCH v2 0/3] kvm: arm/arm64: Fixes for use after free problems

This series contains potential fixes for problems reported by [0] & [1]. [0] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492944.html [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492943.html Changes since V1: - Yield the kvm->mmu_lock if necessary in

[PATCH v2 1/3] kvm: arm/arm64: Take mmap_sem in stage2_unmap_vm

From: Marc Zyngier We don't hold the mmap_sem while searching for the VMAs when we try to unmap each memslot for a VM. Fix this properly to avoid unexpected results. Fixes: commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm") Cc: sta...@vger.kernel.org #

[PATCH v2 1/3] kvm: arm/arm64: Take mmap_sem in stage2_unmap_vm

From: Marc Zyngier We don't hold the mmap_sem while searching for the VMAs when we try to unmap each memslot for a VM. Fix this properly to avoid unexpected results. Fixes: commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm") Cc: sta...@vger.kernel.org # v3.19+ Reviewed-by:

Re: [RFC PATCH v2 26/32] kvm: svm: Add support for SEV LAUNCH_UPDATE_DATA command

On 03/16/2017 05:48 AM, Paolo Bonzini wrote: On 02/03/2017 16:17, Brijesh Singh wrote: +static struct page **sev_pin_memory(unsigned long uaddr, unsigned long ulen, + unsigned long *n) +{ + struct page **pages; + int first, last; + unsigned

Re: [RFC PATCH v2 26/32] kvm: svm: Add support for SEV LAUNCH_UPDATE_DATA command

On 03/16/2017 05:48 AM, Paolo Bonzini wrote: On 02/03/2017 16:17, Brijesh Singh wrote: +static struct page **sev_pin_memory(unsigned long uaddr, unsigned long ulen, + unsigned long *n) +{ + struct page **pages; + int first, last; + unsigned

Re: [RFC PATCH v2 32/32] x86: kvm: Pin the guest memory when SEV is active

On 03/16/2017 05:38 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: The SEV memory encryption engine uses a tweak such that two identical plaintexts at different location will have a different ciphertexts. So swapping or moving ciphertexts of two pages will not result in

Re: [RFC PATCH v2 32/32] x86: kvm: Pin the guest memory when SEV is active

On 03/16/2017 05:38 AM, Paolo Bonzini wrote: On 02/03/2017 16:18, Brijesh Singh wrote: The SEV memory encryption engine uses a tweak such that two identical plaintexts at different location will have a different ciphertexts. So swapping or moving ciphertexts of two pages will not result in

Re: [PATCH] isdn: hardware: mISDN: Remove reference to CONFIG_8xx

From: Christophe Leroy Date: Thu, 16 Mar 2017 10:18:02 +0100 (CET) > CONFIG_8xx is deprecated and should soon be removed in favor > of CONFIG_PPC_8xx. > Anyway, hfc_multi_8xx.h only uses 8xx I/O ports which are > linked to the CPM1 communication processor included in the

Re: [PATCH] isdn: hardware: mISDN: Remove reference to CONFIG_8xx

From: Christophe Leroy Date: Thu, 16 Mar 2017 10:18:02 +0100 (CET) > CONFIG_8xx is deprecated and should soon be removed in favor > of CONFIG_PPC_8xx. > Anyway, hfc_multi_8xx.h only uses 8xx I/O ports which are > linked to the CPM1 communication processor included in the 8xx > rather than the

Re: [PATCH] net: ethernet: fs_enet: Remove useless includes

From: Christophe Leroy Date: Thu, 16 Mar 2017 10:18:04 +0100 (CET) > CONFIG_8xx is being deprecated. Since the includes dependent on > CONFIG_8xx are useless, just drop them. > > Signed-off-by: Christophe Leroy Applied.

Re: [PATCH] net: ethernet: fs_enet: Remove useless includes

From: Christophe Leroy Date: Thu, 16 Mar 2017 10:18:04 +0100 (CET) > CONFIG_8xx is being deprecated. Since the includes dependent on > CONFIG_8xx are useless, just drop them. > > Signed-off-by: Christophe Leroy Applied.

Re: [PATCH v1 1/1] platform/x86: intel_pmc_ipc: fix io mem mapping size

On Thu, Mar 16, 2017 at 06:05:39PM +0200, Andy Shevchenko wrote: > On Thu, Mar 16, 2017 at 4:52 PM, Rajneesh Bhardwaj > wrote: > > On Wed, Mar 15, 2017 at 08:32:53PM -0700, Kuppuswamy Sathyanarayanan wrote: > >> Mapping entire GCR mem region in this driver creates >

Re: perf: massive perf_event slowdown between 4.9 and 4.11-rc

On Thu, Mar 16, 2017 at 11:54:58AM -0400, Vince Weaver wrote: > Hello > > My student actually noticed this before I did, I was hoping it was some > sort of error in her data. > > Anyway all perf_event functionality (especially reads) has become about > 20x slower, at least on Intel machines

Re: [PATCH v1 1/1] platform/x86: intel_pmc_ipc: fix io mem mapping size

On Thu, Mar 16, 2017 at 06:05:39PM +0200, Andy Shevchenko wrote: > On Thu, Mar 16, 2017 at 4:52 PM, Rajneesh Bhardwaj > wrote: > > On Wed, Mar 15, 2017 at 08:32:53PM -0700, Kuppuswamy Sathyanarayanan wrote: > >> Mapping entire GCR mem region in this driver creates > >> mem region request conflict

Re: perf: massive perf_event slowdown between 4.9 and 4.11-rc

On Thu, Mar 16, 2017 at 11:54:58AM -0400, Vince Weaver wrote: > Hello > > My student actually noticed this before I did, I was hoping it was some > sort of error in her data. > > Anyway all perf_event functionality (especially reads) has become about > 20x slower, at least on Intel machines

Re: [PATCH v2 2/3] drm/vc4: Add HDMI audio support

Eric Anholt writes: > The HDMI encoder IP embeds all needed blocks to output audio, with a > custom DAI called MAI moving audio between the two parts of the HDMI > core. This driver now exposes a sound card to let users stream audio > to their display. > > Using the hdmi-codec

Re: [PATCH v2 2/3] drm/vc4: Add HDMI audio support

Eric Anholt writes: > The HDMI encoder IP embeds all needed blocks to output audio, with a > custom DAI called MAI moving audio between the two parts of the HDMI > core. This driver now exposes a sound card to let users stream audio > to their display. > > Using the hdmi-codec driver has been

Re: [PATCH v4 4/7] xen/9pfs: connect to the backend

On Thu, 16 Mar 2017, Juergen Gross wrote: > On 15/03/17 20:23, Stefano Stabellini wrote: > > Implement functions to handle the xenbus handshake. Upon connection, > > allocate the rings according to the protocol specification. > > > > Initialize a work_struct and a wait_queue. The work_struct will

Re: [PATCH v4 4/7] xen/9pfs: connect to the backend

On Thu, 16 Mar 2017, Juergen Gross wrote: > On 15/03/17 20:23, Stefano Stabellini wrote: > > Implement functions to handle the xenbus handshake. Upon connection, > > allocate the rings according to the protocol specification. > > > > Initialize a work_struct and a wait_queue. The work_struct will

Re: 'perf test tsc' failing, bisected to "sched/clock: Provide better clock continuity"

On Thu, Mar 16, 2017 at 03:53:11PM +0100, Peter Zijlstra wrote: > On Thu, Mar 16, 2017 at 11:01:03AM -0300, Arnaldo Carvalho de Melo wrote: > > Hi, this entry is failing for a while: > > > > [root@jouet ~]# perf test -v tsc > > 55: Convert perf time to TSC : > > --- start --- >

Re: 'perf test tsc' failing, bisected to "sched/clock: Provide better clock continuity"

On Thu, Mar 16, 2017 at 03:53:11PM +0100, Peter Zijlstra wrote: > On Thu, Mar 16, 2017 at 11:01:03AM -0300, Arnaldo Carvalho de Melo wrote: > > Hi, this entry is failing for a while: > > > > [root@jouet ~]# perf test -v tsc > > 55: Convert perf time to TSC : > > --- start --- >

[PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

[ I'll wait to post the full v3 series in case there is more comments ] From: "Steven Rostedt (VMware)" When ftrace_regs_caller was created, it was designed to preserve flags as much as possible as it needed to act just like a breakpoint triggered on the same location. But

[PATCH 4/5 v3] ftrace/x86_32: Clean up ftrace_regs_caller

[ I'll wait to post the full v3 series in case there is more comments ] From: "Steven Rostedt (VMware)" When ftrace_regs_caller was created, it was designed to preserve flags as much as possible as it needed to act just like a breakpoint triggered on the same location. But the design is over

Re: [PATCH] perf: fix symbols__fixup_end heuristic for corner cases

On Wed, Mar 15, 2017 at 10:53:37PM +0100, Daniel Borkmann wrote: > The current symbols__fixup_end() heuristic for the last entry in the > rb tree is suboptimal as it leads to not being able to recognize the > symbol in the call graph in a couple of corner cases, for example: > > i) If the symbol

Re: [PATCH] perf: fix symbols__fixup_end heuristic for corner cases

On Wed, Mar 15, 2017 at 10:53:37PM +0100, Daniel Borkmann wrote: > The current symbols__fixup_end() heuristic for the last entry in the > rb tree is suboptimal as it leads to not being able to recognize the > symbol in the call graph in a couple of corner cases, for example: > > i) If the symbol

[locking/lockdep] 383776fa75: INFO: trying to register non-static key.

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core commit 383776fa7527745224446337f2dcfb0f0d1b8b56 Author: Thomas Gleixner AuthorDate: Mon Feb 27 15:37:36 2017

[locking/lockdep] 383776fa75: INFO: trying to register non-static key.

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core commit 383776fa7527745224446337f2dcfb0f0d1b8b56 Author: Thomas Gleixner AuthorDate: Mon Feb 27 15:37:36 2017 +0100 Commit: Ingo

Re: [PATCH v3 4/7] xen/9pfs: connect to the backend

On Thu, 16 Mar 2017, Juergen Gross wrote: > On 15/03/17 19:44, Stefano Stabellini wrote: > > On Wed, 15 Mar 2017, Juergen Gross wrote: > >> On 14/03/17 22:22, Stefano Stabellini wrote: > >>> Hi Juergen, > >>> > >>> thank you for the review! > >>> > >>> On Tue, 14 Mar 2017, Juergen Gross wrote: >

Re: [PATCH v3 4/7] xen/9pfs: connect to the backend

On Thu, 16 Mar 2017, Juergen Gross wrote: > On 15/03/17 19:44, Stefano Stabellini wrote: > > On Wed, 15 Mar 2017, Juergen Gross wrote: > >> On 14/03/17 22:22, Stefano Stabellini wrote: > >>> Hi Juergen, > >>> > >>> thank you for the review! > >>> > >>> On Tue, 14 Mar 2017, Juergen Gross wrote: >

Re: [PATCH 0/7] Switch x86 to generic get_user_pages_fast() implementation

On Thu, Mar 16, 2017 at 8:26 AM, Kirill A. Shutemov wrote: > > The patcheset generalize mm/gup.c implementation of get_user_pages_fast() > to be usable for x86 and switches x86 over. Thanks for doing this, it looks good and removes more lines than it adds. And

Re: [PATCH 0/7] Switch x86 to generic get_user_pages_fast() implementation

On Thu, Mar 16, 2017 at 8:26 AM, Kirill A. Shutemov wrote: > > The patcheset generalize mm/gup.c implementation of get_user_pages_fast() > to be usable for x86 and switches x86 over. Thanks for doing this, it looks good and removes more lines than it adds. And despite removing lines, it should

Re: [PATCH 1/2] mmc: sdhci: Add support for setting parent clock

On 16/03/17 10:32, Jon Hunter wrote: > It is common for SD/MMC host controllers to set the parent clock that > drives the SD/MMC interface in order to support various operating > speeds. Typically, this is performed by calling common clock framework > APIs such as clk_set_rate(). The problem is

Re: [PATCH 1/2] mmc: sdhci: Add support for setting parent clock

On 16/03/17 10:32, Jon Hunter wrote: > It is common for SD/MMC host controllers to set the parent clock that > drives the SD/MMC interface in order to support various operating > speeds. Typically, this is performed by calling common clock framework > APIs such as clk_set_rate(). The problem is

RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

> On Tue, 2017-03-14 at 12:29 +, Reshetova, Elena wrote: > > > Elena Reshetova writes: > > > > > > > refcount_t type and corresponding API should be > > > > used instead of atomic_t when the variable is used as > > > > a reference counter. This allows to avoid

RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

> On Tue, 2017-03-14 at 12:29 +, Reshetova, Elena wrote: > > > Elena Reshetova writes: > > > > > > > refcount_t type and corresponding API should be > > > > used instead of atomic_t when the variable is used as > > > > a reference counter. This allows to avoid accidental > > > > refcounter

Re: perf: massive perf_event slowdown between 4.9 and 4.11-rc

On Thu, 16 Mar 2017, Vince Weaver wrote: > Anyway all perf_event functionality (especially reads) has become about > 20x slower, at least on Intel machines (haswell and skylake are the only > ones I've tested) sometime between 4.9 and 4.11-rc False alarm, I forgot I had debugging (KASAN, etc)

Re: perf: massive perf_event slowdown between 4.9 and 4.11-rc

On Thu, 16 Mar 2017, Vince Weaver wrote: > Anyway all perf_event functionality (especially reads) has become about > 20x slower, at least on Intel machines (haswell and skylake are the only > ones I've tested) sometime between 4.9 and 4.11-rc False alarm, I forgot I had debugging (KASAN, etc)

Re: [PATCH v2] firmware/Makefile: force recompilation if makefile changes

On Thu, Mar 16, 2017 at 10:43 AM, Masahiro Yamada wrote: > Hi Luis, > > 2017-03-15 9:53 GMT+09:00 Luis R. Rodriguez : >> On Sat, Mar 11, 2017 at 02:37:02PM +0900, Masahiro Yamada wrote: >>> Hi Luis, >>> >>> >>> 2017-01-24 0:07 GMT+09:00 Luis R.

Re: [PATCH v2] firmware/Makefile: force recompilation if makefile changes

On Thu, Mar 16, 2017 at 10:43 AM, Masahiro Yamada wrote: > Hi Luis, > > 2017-03-15 9:53 GMT+09:00 Luis R. Rodriguez : >> On Sat, Mar 11, 2017 at 02:37:02PM +0900, Masahiro Yamada wrote: >>> Hi Luis, >>> >>> >>> 2017-01-24 0:07 GMT+09:00 Luis R. Rodriguez : >>> > If you modify the target asm we

Re: [PATCH v2] ARM: zynq: Add #io-channel-cells to (x)adc node for iio-hwmon

Hi Lars, On Thu, Mar 16, 2017 at 9:51 AM, Lars-Peter Clausen wrote: > On 03/16/2017 05:45 PM, Michal Simek wrote: >> On 16.3.2017 17:39, Moritz Fischer wrote: >>> On Thu, Mar 16, 2017 at 9:16 AM, Michal Simek >>> wrote: Hi, On 8.3.2017

Re: [PATCH v2] ARM: zynq: Add #io-channel-cells to (x)adc node for iio-hwmon

Hi Lars, On Thu, Mar 16, 2017 at 9:51 AM, Lars-Peter Clausen wrote: > On 03/16/2017 05:45 PM, Michal Simek wrote: >> On 16.3.2017 17:39, Moritz Fischer wrote: >>> On Thu, Mar 16, 2017 at 9:16 AM, Michal Simek >>> wrote: Hi, On 8.3.2017 21:11, Moritz Fischer wrote: > Fix

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