Re: get_zone_device_page() in get_page() and page_cache_get_speculative()

On Tue, Apr 25, 2017 at 6:19 AM, Kirill A. Shutemov wrote: > On Mon, Apr 24, 2017 at 11:41:51AM -0700, Dan Williams wrote: >> On Mon, Apr 24, 2017 at 11:25 AM, Kirill A. Shutemov >> wrote: >> > On Mon, Apr 24, 2017 at 09:01:58PM +0300, Kirill A. Shutemov wrote: >> >> On Mon, Apr 24, 2017 at

Re: [PATCH] x86/mm/64: Fix crash in remove_pagetable()

On Tue, Apr 25, 2017 at 2:25 AM, Kirill A. Shutemov wrote: > remove_pagetable() does page walk using p*d_page_vaddr() plus cast. > It's not canonical approach -- we usually use p*d_offset() for that. > > It works fine as long as all page table levels are present. We broke the > invariant by

Re: [PATCH v3 10/20] fuse: set mapping error in writepage_locked when it fails

On Tue, 2017-04-25 at 13:19 +0200, Jan Kara wrote: > On Tue 25-04-17 06:35:13, Jeff Layton wrote: > > On Tue, 2017-04-25 at 10:17 +0200, Jan Kara wrote: > > > On Mon 24-04-17 13:14:36, Jeff Layton wrote: > > > > On Mon, 2017-04-24 at 18:04 +0200, Jan Kara wrote: > > > > > On Mon 24-04-17 09:22:49,

Re: [PATCH v3 10/20] fuse: set mapping error in writepage_locked when it fails

On Tue, 2017-04-25 at 13:19 +0200, Jan Kara wrote: > On Tue 25-04-17 06:35:13, Jeff Layton wrote: > > On Tue, 2017-04-25 at 10:17 +0200, Jan Kara wrote: > > > On Mon 24-04-17 13:14:36, Jeff Layton wrote: > > > > On Mon, 2017-04-24 at 18:04 +0200, Jan Kara wrote: > > > > > On Mon 24-04-17 09:22:49,

GPU hangs and X shot down with 4.11-rc6

Hi, I have just experienced X being shut down once with 4.11-rc2 and 2 times with 4.11-rc6 kernel. I do not remember seeing something like this before but it is quite possible I was just lucky to not trigger this issue before. It always happened while I was working on a presentation in

GPU hangs and X shot down with 4.11-rc6

Hi, I have just experienced X being shut down once with 4.11-rc2 and 2 times with 4.11-rc6 kernel. I do not remember seeing something like this before but it is quite possible I was just lucky to not trigger this issue before. It always happened while I was working on a presentation in

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

On 4/25/17 10:38 AM, Andrey Konovalov wrote: > I'll keep fuzzing in the meantime to make sure. > Maybe I'll be able to collect more reports or even another reproducer. start a new email thread for each stack trace. I'll write a debug patch for the trace you hit today.

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

On 4/25/17 10:38 AM, Andrey Konovalov wrote: > I'll keep fuzzing in the meantime to make sure. > Maybe I'll be able to collect more reports or even another reproducer. start a new email thread for each stack trace. I'll write a debug patch for the trace you hit today.

Re: [PATCH] x86/refcount: Implement fast refcount_t handling

On Tue, Apr 25, 2017 at 4:26 AM, PaX Team wrote: > INT_MAX threads would be needed when the leaking path is locked so > that it can only be exercised once and you'll need to get normal > (balanced) paths preempted just after the increment. if the leaking > path is lockless

Re: [PATCH] x86/refcount: Implement fast refcount_t handling

On Tue, Apr 25, 2017 at 4:26 AM, PaX Team wrote: > INT_MAX threads would be needed when the leaking path is locked so > that it can only be exercised once and you'll need to get normal > (balanced) paths preempted just after the increment. if the leaking > path is lockless (can be exercised in

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

On Tue, Apr 25, 2017 at 6:36 PM, Andrey Konovalov wrote: > On Tue, Apr 25, 2017 at 5:56 PM, David Ahern wrote: >> On 3/4/17 11:57 AM, Dmitry Vyukov wrote: >>> == >>> BUG: KASAN:

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

On Tue, Apr 25, 2017 at 6:36 PM, Andrey Konovalov wrote: > On Tue, Apr 25, 2017 at 5:56 PM, David Ahern wrote: >> On 3/4/17 11:57 AM, Dmitry Vyukov wrote: >>> == >>> BUG: KASAN: slab-out-of-bounds in rt6_dump_route+0x293/0x2f0 >>>

Re: [PATCH v2 2/2] libnvdimm, region: sysfs trigger for nvdimm_flush()

On Tue, Apr 25, 2017 at 9:37 AM, Ross Zwisler wrote: > On Mon, Apr 24, 2017 at 04:50:01PM -0700, Dan Williams wrote: >> The nvdimm_flush() mechanism helps to reduce the impact of an ADR >> (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing >>

Re: [PATCH v2 2/2] libnvdimm, region: sysfs trigger for nvdimm_flush()

On Tue, Apr 25, 2017 at 9:37 AM, Ross Zwisler wrote: > On Mon, Apr 24, 2017 at 04:50:01PM -0700, Dan Williams wrote: >> The nvdimm_flush() mechanism helps to reduce the impact of an ADR >> (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing >> platform WPQ

Re: [PATCH v2] net/packet: initialize val in packet_getsockopt()

On Tue, Apr 25, 2017 at 6:32 PM, David Miller wrote: > From: Alexander Potapenko > Date: Tue, 25 Apr 2017 18:27:04 +0200 > >> On Tue, Apr 25, 2017 at 5:44 PM, David Miller wrote: >>> From: Alexander Potapenko >>>

Re: [PATCH v2] net/packet: initialize val in packet_getsockopt()

On Tue, Apr 25, 2017 at 6:32 PM, David Miller wrote: > From: Alexander Potapenko > Date: Tue, 25 Apr 2017 18:27:04 +0200 > >> On Tue, Apr 25, 2017 at 5:44 PM, David Miller wrote: >>> From: Alexander Potapenko >>> Date: Mon, 24 Apr 2017 14:59:14 +0200 >>> In the case getsockopt() is called

Re: [PATCH v2 2/2] libnvdimm, region: sysfs trigger for nvdimm_flush()

On Mon, Apr 24, 2017 at 04:50:01PM -0700, Dan Williams wrote: > The nvdimm_flush() mechanism helps to reduce the impact of an ADR > (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing > platform WPQ (write-pending-queue) buffers when power is removed. The > nvdimm_flush()

Re: [PATCH v2 2/2] libnvdimm, region: sysfs trigger for nvdimm_flush()

On Mon, Apr 24, 2017 at 04:50:01PM -0700, Dan Williams wrote: > The nvdimm_flush() mechanism helps to reduce the impact of an ADR > (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing > platform WPQ (write-pending-queue) buffers when power is removed. The > nvdimm_flush()

Re: [PATCH v8 1/3] backlight arcxcnn add arc to vendor prefix

On Monday, April 24, 2017 1:56 PM, Olimpiu Dejeu wrote: > > On Mon, April 24, 2017 11:10 AM, Rob Herring < r...@kernel.org> wrote: > > > On Wed, Mar 15, 2017 at 2:45 PM, Olimpiu Dejeu > wrote: > >> backlight: Add arc to vendor prefixes > >> Signed-off-by: Olimpiu Dejeu

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

On Tue, Apr 25, 2017 at 5:56 PM, David Ahern wrote: > On 3/4/17 11:57 AM, Dmitry Vyukov wrote: >> == >> BUG: KASAN: slab-out-of-bounds in rt6_dump_route+0x293/0x2f0 >> net/ipv6/route.c:3551 at addr

Re: [PATCH v8 1/3] backlight arcxcnn add arc to vendor prefix

On Monday, April 24, 2017 1:56 PM, Olimpiu Dejeu wrote: > > On Mon, April 24, 2017 11:10 AM, Rob Herring < r...@kernel.org> wrote: > > > On Wed, Mar 15, 2017 at 2:45 PM, Olimpiu Dejeu > wrote: > >> backlight: Add arc to vendor prefixes > >> Signed-off-by: Olimpiu Dejeu > >> --- > >> v8: > >> -

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

On Tue, Apr 25, 2017 at 5:56 PM, David Ahern wrote: > On 3/4/17 11:57 AM, Dmitry Vyukov wrote: >> == >> BUG: KASAN: slab-out-of-bounds in rt6_dump_route+0x293/0x2f0 >> net/ipv6/route.c:3551 at addr 88007e523694 >> Read of size 4

Re: [PATCH] x86/refcount: Implement fast refcount_t handling

On Tue, Apr 25, 2017 at 4:26 AM, PaX Team wrote: > On 25 Apr 2017 at 0:01, Peter Zijlstra wrote: >> How is the below not useful fodder for an exploit? It might be a less >> common bug, and perhaps a bit more fiddly to make work, but afaict its >> still a full use-after-free

Re: [PATCH] x86/refcount: Implement fast refcount_t handling

On Tue, Apr 25, 2017 at 4:26 AM, PaX Team wrote: > On 25 Apr 2017 at 0:01, Peter Zijlstra wrote: >> How is the below not useful fodder for an exploit? It might be a less >> common bug, and perhaps a bit more fiddly to make work, but afaict its >> still a full use-after-free and therefore useful.

Re: [PATCH] macsec: dynamically allocate space for sglist

2017-04-25, 17:23:00 +0200, Jason A. Donenfeld wrote: > We call skb_cow_data, which is good anyway to ensure we can actually > modify the skb as such (another error from prior). Now that we have the > number of fragments required, we can safely allocate exactly that amount > of memory. > >

RE: [PATCH] kallsyms: optimize kallsyms_lookup_name() for a few cases

From: Naveen N. Rao > Sent: 25 April 2017 17:18 > 1. Fail early for invalid/zero length symbols. > 2. Detect names of the form and skip checking for kernel > symbols in that case. > > Signed-off-by: Naveen N. Rao > --- > Masami, Michael, > I have added two very

Re: [PATCH] macsec: dynamically allocate space for sglist

2017-04-25, 17:23:00 +0200, Jason A. Donenfeld wrote: > We call skb_cow_data, which is good anyway to ensure we can actually > modify the skb as such (another error from prior). Now that we have the > number of fragments required, we can safely allocate exactly that amount > of memory. > >

RE: [PATCH] kallsyms: optimize kallsyms_lookup_name() for a few cases

From: Naveen N. Rao > Sent: 25 April 2017 17:18 > 1. Fail early for invalid/zero length symbols. > 2. Detect names of the form and skip checking for kernel > symbols in that case. > > Signed-off-by: Naveen N. Rao > --- > Masami, Michael, > I have added two very simple checks here, which I felt

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

On Tue, 2017-04-25 at 16:55 +0200, Peter Rosin wrote: > On 2017-04-25 16:16, Peter Rosin wrote: > > On 2017-04-24 16:59, Philipp Zabel wrote: > >> On Mon, 2017-04-24 at 16:36 +0200, Peter Rosin wrote: > >> [...] > How about an atomic use_count on the mux_control, a bool shared that is >

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

On Tue, 2017-04-25 at 16:55 +0200, Peter Rosin wrote: > On 2017-04-25 16:16, Peter Rosin wrote: > > On 2017-04-24 16:59, Philipp Zabel wrote: > >> On Mon, 2017-04-24 at 16:36 +0200, Peter Rosin wrote: > >> [...] > How about an atomic use_count on the mux_control, a bool shared that is >

Re: [PATCH v2] net/packet: initialize val in packet_getsockopt()

From: Alexander Potapenko Date: Tue, 25 Apr 2017 18:27:04 +0200 > On Tue, Apr 25, 2017 at 5:44 PM, David Miller wrote: >> From: Alexander Potapenko >> Date: Mon, 24 Apr 2017 14:59:14 +0200 >> >>> In the case getsockopt() is called with

Re: [PATCH v2] net/packet: initialize val in packet_getsockopt()

From: Alexander Potapenko Date: Tue, 25 Apr 2017 18:27:04 +0200 > On Tue, Apr 25, 2017 at 5:44 PM, David Miller wrote: >> From: Alexander Potapenko >> Date: Mon, 24 Apr 2017 14:59:14 +0200 >> >>> In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 >>> |val| remains

Re: [PATCH 0/2] DS1374 Watchdog fixes

On 25/04/2017 at 09:17:43 -0700, Guenter Roeck wrote: > On Tue, Apr 25, 2017 at 07:55:28AM -0700, Moritz Fischer wrote: > > Hi Guenter, > > > > On Mon, Apr 24, 2017 at 10:03 PM, Guenter Roeck wrote: > > > On 04/24/2017 03:05 PM, Moritz Fischer wrote: > > > > >> I'm very

Re: [PATCH 0/2] DS1374 Watchdog fixes

On 25/04/2017 at 09:17:43 -0700, Guenter Roeck wrote: > On Tue, Apr 25, 2017 at 07:55:28AM -0700, Moritz Fischer wrote: > > Hi Guenter, > > > > On Mon, Apr 24, 2017 at 10:03 PM, Guenter Roeck wrote: > > > On 04/24/2017 03:05 PM, Moritz Fischer wrote: > > > > >> I'm very unhappy with the

Re: [PATCH] Fix returns of some CLK API calls, if !CONFIG_HAVE_CLOCK

On Tue, Apr 25, 2017 at 02:30:07PM +0200, Thomas Bogendoerfer wrote: > If CONFIG_HAVE_CLOCK is not set, return values of clk_get(), > devm_clk_get(), devm_get_clk_from_child(), clk_get_parent() > and clk_get_sys() are wrong. According to spec these functions > should either return a pointer to a

Re: [PATCH] Fix returns of some CLK API calls, if !CONFIG_HAVE_CLOCK

On Tue, Apr 25, 2017 at 02:30:07PM +0200, Thomas Bogendoerfer wrote: > If CONFIG_HAVE_CLOCK is not set, return values of clk_get(), > devm_clk_get(), devm_get_clk_from_child(), clk_get_parent() > and clk_get_sys() are wrong. According to spec these functions > should either return a pointer to a

Re: [PATCH v4 net-next] mdio_bus: Issue GPIO RESET to PHYs.

On 04/25/2017 09:22 AM, Lars-Peter Clausen wrote: > On 04/24/2017 11:04 AM, Roger Quadros wrote: >> On 24/04/17 02:35, Andrew Lunn wrote: >>> On Fri, Apr 21, 2017 at 03:31:09PM +0200, Lars-Peter Clausen wrote: On 04/21/2017 03:15 PM, Roger Quadros wrote: > diff --git

Re: [PATCH v4 net-next] mdio_bus: Issue GPIO RESET to PHYs.

On 04/25/2017 09:22 AM, Lars-Peter Clausen wrote: > On 04/24/2017 11:04 AM, Roger Quadros wrote: >> On 24/04/17 02:35, Andrew Lunn wrote: >>> On Fri, Apr 21, 2017 at 03:31:09PM +0200, Lars-Peter Clausen wrote: On 04/21/2017 03:15 PM, Roger Quadros wrote: > diff --git

Re: [PATCH V15 04/11] efi: parse ARM processor error

On Tue, Apr 25, 2017 at 10:05:31AM -0600, Baicar, Tyler wrote: > That seems like something that should be done outside of these patches (if > added to the kernel at all). The decoding for this information would all be > vendor specific, so I'm not sure if we want to pollute the EFI code with >

Re: [PATCH V15 04/11] efi: parse ARM processor error

On Tue, Apr 25, 2017 at 10:05:31AM -0600, Baicar, Tyler wrote: > That seems like something that should be done outside of these patches (if > added to the kernel at all). The decoding for this information would all be > vendor specific, so I'm not sure if we want to pollute the EFI code with >

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2

On Tue, Apr 25, 2017 at 12:22 PM, Christian König wrote: > Am 25.04.2017 um 17:14 schrieb Alex Deucher: >> >> On Tue, Apr 25, 2017 at 11:09 AM, Christian König >> wrote: >>> >>> Am 25.04.2017 um 16:34 schrieb Alex Deucher: On Tue, Apr

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2

On Tue, Apr 25, 2017 at 12:22 PM, Christian König wrote: > Am 25.04.2017 um 17:14 schrieb Alex Deucher: >> >> On Tue, Apr 25, 2017 at 11:09 AM, Christian König >> wrote: >>> >>> Am 25.04.2017 um 16:34 schrieb Alex Deucher: On Tue, Apr 25, 2017 at 9:19 AM, Christian König wrote:

[PATCH 5/5] usefaultfd.2: add brief description of "non-cooperative" mode

Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 14 ++ 1 file changed, 14 insertions(+) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index dc37319..291dd10 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -89,6 +89,20 @@ them using

[PATCH 2/5] ioctl_userfaultfd.2: describe memory types that can be used from 4.11

Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 66fbfdc..78abc4d 100644 --- a/man2/ioctl_userfaultfd.2 +++

[PATCH 5/5] usefaultfd.2: add brief description of "non-cooperative" mode

Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 14 ++ 1 file changed, 14 insertions(+) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index dc37319..291dd10 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -89,6 +89,20 @@ them using the operations described

[PATCH 2/5] ioctl_userfaultfd.2: describe memory types that can be used from 4.11

Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 66fbfdc..78abc4d 100644 --- a/man2/ioctl_userfaultfd.2 +++ b/man2/ioctl_userfaultfd.2 @@ -169,11 +169,15

[PATCH 4/5] userfaultfd.2: add Linux container migration use-case to NOTES

Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index c89484f..dc37319 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -279,7 +279,8 @@ signal

[PATCH 4/5] userfaultfd.2: add Linux container migration use-case to NOTES

Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index c89484f..dc37319 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -279,7 +279,8 @@ signal and It can also be used to

[PATCH 1/5] userfaultfd.2: describe memory types that can be used from 4.11

Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index 1603c20..c89484f 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -130,8 +130,12 @@

[PATCH 1/5] userfaultfd.2: describe memory types that can be used from 4.11

Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index 1603c20..c89484f 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -130,8 +130,12 @@ Details of the various

[PATCH 3/5] ioctl_userfaultfd.2: update UFFDIO_API description

Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 38 -- 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 78abc4d..dade631 100644 ---

[PATCH 3/5] ioctl_userfaultfd.2: update UFFDIO_API description

Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 38 -- 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 78abc4d..dade631 100644 --- a/man2/ioctl_userfaultfd.2 +++

[PATCH] x86/tboot: add an option to disable iommu force on

IOMMU harms performance signficantly when we run very fast networking workloads. It's 40GB networking doing XDP test. Software overhead is almost unaware, but it's the IOTLB miss (based on our analysis) which kills the performance. We observed the same performance issue even with software

[PATCH] x86/tboot: add an option to disable iommu force on

IOMMU harms performance signficantly when we run very fast networking workloads. It's 40GB networking doing XDP test. Software overhead is almost unaware, but it's the IOTLB miss (based on our analysis) which kills the performance. We observed the same performance issue even with software

[PATCH 0/5] {ioctl_}userfaultfd.2: initial updates for 4.11

Hello Michael, These patches are some kind of brief highlights of the changes to the userfaultfd pages. The changes to userfaultfd functionality are also described at update to Documentation/vm/userfaultfd.txt [1]. In general, there were three major additions: * hugetlbfs support * shmem support

[PATCH 0/5] {ioctl_}userfaultfd.2: initial updates for 4.11

Hello Michael, These patches are some kind of brief highlights of the changes to the userfaultfd pages. The changes to userfaultfd functionality are also described at update to Documentation/vm/userfaultfd.txt [1]. In general, there were three major additions: * hugetlbfs support * shmem support

Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree

On Tue, Apr 25, 2017 at 09:24:34AM -0700, Ryan Lee wrote: > I was not able to see any activities about MAX98927 driver after previous > mail. > Is there anything wrong with this driver? Please don't top post, reply in line with needed context. This allows readers to readily follow the flow of

Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree

On Tue, Apr 25, 2017 at 09:24:34AM -0700, Ryan Lee wrote: > I was not able to see any activities about MAX98927 driver after previous > mail. > Is there anything wrong with this driver? Please don't top post, reply in line with needed context. This allows readers to readily follow the flow of

Re: [PATCH v2 15/18] dt-bindings: sound: Add bindings for Cirrus Logic Madera codecs

On Tue, 2017-04-25 at 16:52 +0100, Mark Brown wrote: > On Mon, Apr 24, 2017 at 05:08:41PM +0100, Richard Fitzgerald wrote: > > The Cirrus Logic Madera codecs are a family of related codecs with > > extensive digital and analogue I/O, digital mixing and routing, > > signal processing and

Re: [PATCH v2 15/18] dt-bindings: sound: Add bindings for Cirrus Logic Madera codecs

On Tue, 2017-04-25 at 16:52 +0100, Mark Brown wrote: > On Mon, Apr 24, 2017 at 05:08:41PM +0100, Richard Fitzgerald wrote: > > The Cirrus Logic Madera codecs are a family of related codecs with > > extensive digital and analogue I/O, digital mixing and routing, > > signal processing and

Re: [PATCH 20/22] tools arch: Sync arch/x86/lib/memcpy_64.S with the kernel

On Tue, 2017-04-25 at 16:18 +, Luck, Tony wrote: > > > If we are going to have all these copies of kernel files below > > > "tools/...", perhaps checkpatch could warn people touching one > > > that the other needs the same update? > > > > How would checkpatch know tools hasn't already updated

Re: [PATCH 20/22] tools arch: Sync arch/x86/lib/memcpy_64.S with the kernel

On Tue, 2017-04-25 at 16:18 +, Luck, Tony wrote: > > > If we are going to have all these copies of kernel files below > > > "tools/...", perhaps checkpatch could warn people touching one > > > that the other needs the same update? > > > > How would checkpatch know tools hasn't already updated

Re: [PATCH v2] net/packet: initialize val in packet_getsockopt()

On Tue, Apr 25, 2017 at 5:44 PM, David Miller wrote: > From: Alexander Potapenko > Date: Mon, 24 Apr 2017 14:59:14 +0200 > >> In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 >> |val| remains uninitialized and the syscall may behave

Re: [PATCH v2] net/packet: initialize val in packet_getsockopt()

On Tue, Apr 25, 2017 at 5:44 PM, David Miller wrote: > From: Alexander Potapenko > Date: Mon, 24 Apr 2017 14:59:14 +0200 > >> In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 >> |val| remains uninitialized and the syscall may behave differently >> depending on its value. This

Re: [PATCH 4/4] sched/topology: the group balance cpu must be a cpu where the group is installed

On Tue, Apr 25, 2017 at 12:56:23PM -0300, Lauro Venancio wrote: > > Another thing I've been thinking about; I think we can do away with the > > kzalloc() in build_group_from_child_sched_domain() and use the sdd->sg > > storage. > I considered this too. I decided to do not change this because I

Re: [PATCH 4/4] sched/topology: the group balance cpu must be a cpu where the group is installed

On Tue, Apr 25, 2017 at 12:56:23PM -0300, Lauro Venancio wrote: > > Another thing I've been thinking about; I think we can do away with the > > kzalloc() in build_group_from_child_sched_domain() and use the sdd->sg > > storage. > I considered this too. I decided to do not change this because I

Re: [PATCH] ACPI / GED: use late init to allow other drivers init

On 4/25/2017 7:03 AM, Rafael J. Wysocki wrote: >> Are you talking about init vs. probe in general? > Yes. > > Generally speaking, if the initialization of built-in code depends on > a loadable module to be present, it has to explicitly wait for that > module to advertise itself, this way or

Re: [PATCH] ACPI / GED: use late init to allow other drivers init

On 4/25/2017 7:03 AM, Rafael J. Wysocki wrote: >> Are you talking about init vs. probe in general? > Yes. > > Generally speaking, if the initialization of built-in code depends on > a loadable module to be present, it has to explicitly wait for that > module to advertise itself, this way or

Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree

I was not able to see any activities about MAX98927 driver after previous mail. Is there anything wrong with this driver? On Thu, Apr 6, 2017 at 11:55 AM, Mark Brown wrote: > The patch > >ASoC: Add support for Maxim Integrated MAX98927 Amplifier > > has been applied to

Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree

I was not able to see any activities about MAX98927 driver after previous mail. Is there anything wrong with this driver? On Thu, Apr 6, 2017 at 11:55 AM, Mark Brown wrote: > The patch > >ASoC: Add support for Maxim Integrated MAX98927 Amplifier > > has been applied to the asoc tree at > >

Re: [PATCH] ACPI / GED: use late init to allow other drivers init

On 4/25/2017 3:01 AM, Lukas Wunner wrote: > On Sat, Apr 22, 2017 at 12:48 AM, Sinan Kaya wrote: >> On 4/21/2017 6:43 PM, Rafael J. Wysocki wrote: >>> +late_initcall(ged_init); >>> Does this fix the problem? >>> >>> What about if the module in question is loaded after running

Re: [PATCH] ACPI / GED: use late init to allow other drivers init

On 4/25/2017 3:01 AM, Lukas Wunner wrote: > On Sat, Apr 22, 2017 at 12:48 AM, Sinan Kaya wrote: >> On 4/21/2017 6:43 PM, Rafael J. Wysocki wrote: >>> +late_initcall(ged_init); >>> Does this fix the problem? >>> >>> What about if the module in question is loaded after running >>> late_initcalls?

Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

On Tue, Apr 25, 2017 at 06:15:23PM +0200, Denys Vlasenko wrote: > On 04/25/2017 06:06 PM, Borislav Petkov wrote: > > Pls no. Not every MSR for every family. Only the 4 which are actually > > being used. We can't hold in here the full 32-bit MSR space. > > The replacement of four define names is

Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

On Tue, Apr 25, 2017 at 06:15:23PM +0200, Denys Vlasenko wrote: > On 04/25/2017 06:06 PM, Borislav Petkov wrote: > > Pls no. Not every MSR for every family. Only the 4 which are actually > > being used. We can't hold in here the full 32-bit MSR space. > > The replacement of four define names is

Re: Network cooling device and how to control NIC speed on thermal condition

Hello, On 04/25/2017 01:36 AM, Waldemar Rymarkiewicz wrote: > Hi, > > I am not much aware of linux networking architecture so I'd like to > ask first before will start to dig into the code. Appreciate any > feedback. > > I am looking on Linux thermal framework and on how to cool down the >

Re: Network cooling device and how to control NIC speed on thermal condition

Hello, On 04/25/2017 01:36 AM, Waldemar Rymarkiewicz wrote: > Hi, > > I am not much aware of linux networking architecture so I'd like to > ask first before will start to dig into the code. Appreciate any > feedback. > > I am looking on Linux thermal framework and on how to cool down the >

Re: [PATCH v4 net-next] mdio_bus: Issue GPIO RESET to PHYs.

On 04/24/2017 11:04 AM, Roger Quadros wrote: > On 24/04/17 02:35, Andrew Lunn wrote: >> On Fri, Apr 21, 2017 at 03:31:09PM +0200, Lars-Peter Clausen wrote: >>> On 04/21/2017 03:15 PM, Roger Quadros wrote: diff --git a/Documentation/devicetree/bindings/net/mdio.txt

Re: [PATCH v4 net-next] mdio_bus: Issue GPIO RESET to PHYs.

On 04/24/2017 11:04 AM, Roger Quadros wrote: > On 24/04/17 02:35, Andrew Lunn wrote: >> On Fri, Apr 21, 2017 at 03:31:09PM +0200, Lars-Peter Clausen wrote: >>> On 04/21/2017 03:15 PM, Roger Quadros wrote: diff --git a/Documentation/devicetree/bindings/net/mdio.txt

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2

Am 25.04.2017 um 17:14 schrieb Alex Deucher: On Tue, Apr 25, 2017 at 11:09 AM, Christian König wrote: Am 25.04.2017 um 16:34 schrieb Alex Deucher: On Tue, Apr 25, 2017 at 9:19 AM, Christian König wrote: From: Christian König

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2

Am 25.04.2017 um 17:14 schrieb Alex Deucher: On Tue, Apr 25, 2017 at 11:09 AM, Christian König wrote: Am 25.04.2017 um 16:34 schrieb Alex Deucher: On Tue, Apr 25, 2017 at 9:19 AM, Christian König wrote: From: Christian König Try to resize BAR0 to let CPU access all of VRAM. v2: rebased,

Re: [PATCH v4 00/21] PCI: fix config space memory mappings

On Tuesday, April 25, 2017 2:41 AM, Jon Masters wrote: > > On 04/19/2017 12:48 PM, Lorenzo Pieralisi wrote: > > > On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI > > configuration non-posted write transactions requirement, because it > > provides a memory mapping that

Re: [PATCH v4 00/21] PCI: fix config space memory mappings

On Tuesday, April 25, 2017 2:41 AM, Jon Masters wrote: > > On 04/19/2017 12:48 PM, Lorenzo Pieralisi wrote: > > > On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI > > configuration non-posted write transactions requirement, because it > > provides a memory mapping that

[PATCH] kallsyms: optimize kallsyms_lookup_name() for a few cases

1. Fail early for invalid/zero length symbols. 2. Detect names of the form and skip checking for kernel symbols in that case. Signed-off-by: Naveen N. Rao --- Masami, Michael, I have added two very simple checks here, which I felt is good to have, rather than

[PATCH] kallsyms: optimize kallsyms_lookup_name() for a few cases

1. Fail early for invalid/zero length symbols. 2. Detect names of the form and skip checking for kernel symbols in that case. Signed-off-by: Naveen N. Rao --- Masami, Michael, I have added two very simple checks here, which I felt is good to have, rather than the elaborate checks in the

RE: [PATCH 20/22] tools arch: Sync arch/x86/lib/memcpy_64.S with the kernel

>> If we are going to have all these copies of kernel files below >> "tools/...", perhaps checkpatch could warn people touching one >> that the other needs the same update? > > How would checkpatch know tools hasn't already updated the other? If checkpatch had a list of all the tools copies, it

RE: [PATCH 20/22] tools arch: Sync arch/x86/lib/memcpy_64.S with the kernel

>> If we are going to have all these copies of kernel files below >> "tools/...", perhaps checkpatch could warn people touching one >> that the other needs the same update? > > How would checkpatch know tools hasn't already updated the other? If checkpatch had a list of all the tools copies, it

Re: [PATCH 0/2] DS1374 Watchdog fixes

On Tue, Apr 25, 2017 at 07:55:28AM -0700, Moritz Fischer wrote: > Hi Guenter, > > On Mon, Apr 24, 2017 at 10:03 PM, Guenter Roeck wrote: > > On 04/24/2017 03:05 PM, Moritz Fischer wrote: > > >> I'm very unhappy with the CONFIG_DRV_RTC_DS1374_WDT way of enabling > >> the

Re: [PATCH 0/2] DS1374 Watchdog fixes

On Tue, Apr 25, 2017 at 07:55:28AM -0700, Moritz Fischer wrote: > Hi Guenter, > > On Mon, Apr 24, 2017 at 10:03 PM, Guenter Roeck wrote: > > On 04/24/2017 03:05 PM, Moritz Fischer wrote: > > >> I'm very unhappy with the CONFIG_DRV_RTC_DS1374_WDT way of enabling > >> the watchdog behavior and

Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

On 04/25/2017 06:06 PM, Borislav Petkov wrote: Pls no. Not every MSR for every family. Only the 4 which are actually being used. We can't hold in here the full 32-bit MSR space. The replacement of four define names is not the purpose of the proposed patch. The patch was prompted by the

Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

On 04/25/2017 06:06 PM, Borislav Petkov wrote: Pls no. Not every MSR for every family. Only the 4 which are actually being used. We can't hold in here the full 32-bit MSR space. The replacement of four define names is not the purpose of the proposed patch. The patch was prompted by the

[PATCH -next] auxdisplay: Convert list_for_each to entry variant

From: Wei Yongjun convert list_for_each() to list_for_each_entry() where applicable. Signed-off-by: Wei Yongjun --- drivers/auxdisplay/panel.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/auxdisplay/panel.c

[PATCH -next] auxdisplay: Convert list_for_each to entry variant

From: Wei Yongjun convert list_for_each() to list_for_each_entry() where applicable. Signed-off-by: Wei Yongjun --- drivers/auxdisplay/panel.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/auxdisplay/panel.c b/drivers/auxdisplay/panel.c index e0c014c..7a8b8fb

[PATCH -next] irqchip/qcom: Use builtin_platform_driver to simplify the code

From: Wei Yongjun Use the builtin_platform_driver() macro to make the code simpler. Signed-off-by: Wei Yongjun --- drivers/irqchip/qcom-irq-combiner.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git

[PATCH -next] irqchip/qcom: Use builtin_platform_driver to simplify the code

From: Wei Yongjun Use the builtin_platform_driver() macro to make the code simpler. Signed-off-by: Wei Yongjun --- drivers/irqchip/qcom-irq-combiner.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/irqchip/qcom-irq-combiner.c

Re: [PATCH] iio: adc: Add support for TI ADC1x8s102

On 2017-04-25 15:47, Jan Kiszka wrote: > On 2017-04-25 14:30, Mika Westerberg wrote: >> On Tue, Apr 25, 2017 at 02:17:23PM +0200, Jan Kiszka wrote: >>> I'm not ACPI guru: How do we come from a SSDT to information that is >>> carried in the DSDT so far? How can we overload wrong information in the

Re: [PATCH] iio: adc: Add support for TI ADC1x8s102

On 2017-04-25 15:47, Jan Kiszka wrote: > On 2017-04-25 14:30, Mika Westerberg wrote: >> On Tue, Apr 25, 2017 at 02:17:23PM +0200, Jan Kiszka wrote: >>> I'm not ACPI guru: How do we come from a SSDT to information that is >>> carried in the DSDT so far? How can we overload wrong information in the

Re: [patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem

Hi, This series appears to break boot on some arm64 platforms, seen with next-20170424. More info below. On Tue, Apr 18, 2017 at 07:04:42PM +0200, Thomas Gleixner wrote: > get_online_cpus() is used in hot pathes in mainline and even more so in > RT. That can show up badly under certain

Re: [patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem

Hi, This series appears to break boot on some arm64 platforms, seen with next-20170424. More info below. On Tue, Apr 18, 2017 at 07:04:42PM +0200, Thomas Gleixner wrote: > get_online_cpus() is used in hot pathes in mainline and even more so in > RT. That can show up badly under certain

Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them

On Tue, Apr 25, 2017 at 05:27:04PM +0200, Denys Vlasenko wrote: > MSRs in 0xC001102x range (and a few close to this range) > allow to modify some internal actions of the pipeline. > > (There is one non-debug MSR in this range, introduced in Fam15h: > MSR 0xC0011027 Address Mask For DR0

Re: [for-next][PATCH 0/5] selftests: ftrace: Tracing updates to allow instance testing

On Tue, 25 Apr 2017 09:24:40 -0400 Steven Rostedt wrote: > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git > for-next > > Head SHA1: d6322f6cc483bd512efd3360fa76d0286a5b528b > > > Steven Rostedt (VMware) (5): > selftests: ftrace: Allow some

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