[PATCH] netfilter: fix nf_tables filter chain type build

From: Randy Dunlap Fix build errors due to a missing Kconfig dependency term. Fixes these build errors: net/ipv6/netfilter/nft_chain_nat_ipv6.o: In function `nft_nat_do_chain': net/ipv6/netfilter/nft_chain_nat_ipv6.c:37: undefined reference to `nft_do_chain'

[PATCH] netfilter: fix nf_tables filter chain type build

From: Randy Dunlap Fix build errors due to a missing Kconfig dependency term. Fixes these build errors: net/ipv6/netfilter/nft_chain_nat_ipv6.o: In function `nft_nat_do_chain': net/ipv6/netfilter/nft_chain_nat_ipv6.c:37: undefined reference to `nft_do_chain'

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

David Rientjes wrote: > How have you tested this? > > I'm wondering why you do not see oom killing of many processes if the > victim is a very large process that takes a long time to free memory in > exit_mmap() as I do because the oom reaper gives up trying to acquire > mm->mmap_sem and just

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap

David Rientjes wrote: > How have you tested this? > > I'm wondering why you do not see oom killing of many processes if the > victim is a very large process that takes a long time to free memory in > exit_mmap() as I do because the oom reaper gives up trying to acquire > mm->mmap_sem and just

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

On Fri, 20 Apr 2018, Michal Hocko wrote: > > The solution is certainly not to hold > > down_write(>mmap_sem) during munlock_vma_pages_all() instead. > > Why not? This is what we do for normal paths. exit path just tries to be > clever because it knows that it doesn't have to lock because there

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

On Fri, 20 Apr 2018, Michal Hocko wrote: > > The solution is certainly not to hold > > down_write(>mmap_sem) during munlock_vma_pages_all() instead. > > Why not? This is what we do for normal paths. exit path just tries to be > clever because it knows that it doesn't have to lock because there

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

On Fri, 20 Apr 2018, Michal Hocko wrote: > diff --git a/mm/mmap.c b/mm/mmap.c > index faf85699f1a1..216efa6d9f61 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -3004,10 +3004,21 @@ void exit_mmap(struct mm_struct *mm) > struct mmu_gather tlb; > struct vm_area_struct *vma; >

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

On Fri, 20 Apr 2018, Michal Hocko wrote: > diff --git a/mm/mmap.c b/mm/mmap.c > index faf85699f1a1..216efa6d9f61 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -3004,10 +3004,21 @@ void exit_mmap(struct mm_struct *mm) > struct mmu_gather tlb; > struct vm_area_struct *vma; >

Re: [PATCH RFC 2/8] mm: introduce PG_offline

On Sat, Apr 21, 2018 at 06:52:18PM +0200, Vlastimil Babka wrote: > On 04/13/2018 07:11 PM, Matthew Wilcox wrote: > > On Fri, Apr 13, 2018 at 03:16:26PM +0200, David Hildenbrand wrote: > >> online_pages()/offline_pages() theoretically allows us to work on > >> sub-section sizes. This is especially

Re: [PATCH RFC 2/8] mm: introduce PG_offline

On Sat, Apr 21, 2018 at 06:52:18PM +0200, Vlastimil Babka wrote: > On 04/13/2018 07:11 PM, Matthew Wilcox wrote: > > On Fri, Apr 13, 2018 at 03:16:26PM +0200, David Hildenbrand wrote: > >> online_pages()/offline_pages() theoretically allows us to work on > >> sub-section sizes. This is especially

Re: [PATCH 03/11] fs: add frozen sb state helpers

On Thu, Nov 30, 2017 at 06:13:10PM +0100, Jan Kara wrote: > On Wed 29-11-17 15:23:48, Luis R. Rodriguez wrote: > > The question of whether or not a superblock is frozen needs to be > > augmented in the future to account for differences between a user > > initiated freeze and a kernel initiated

Re: [PATCH 03/11] fs: add frozen sb state helpers

On Thu, Nov 30, 2017 at 06:13:10PM +0100, Jan Kara wrote: > On Wed 29-11-17 15:23:48, Luis R. Rodriguez wrote: > > The question of whether or not a superblock is frozen needs to be > > augmented in the future to account for differences between a user > > initiated freeze and a kernel initiated

Re: [PATCH 2/2] rtmutex: Reduce top-waiter blocking on a lock

On Fri, 20 Apr 2018, Mike Galbraith wrote: On Fri, 2018-04-20 at 17:50 +0200, Peter Zijlstra wrote: Is this similar to what we have in RT (which, IIRC, has an optimistic spinning implementation as well)? For the RT spinlock replacement, the top waiter can spin. Yeah and the difference with

Re: [PATCH 2/2] rtmutex: Reduce top-waiter blocking on a lock

On Fri, 20 Apr 2018, Mike Galbraith wrote: On Fri, 2018-04-20 at 17:50 +0200, Peter Zijlstra wrote: Is this similar to what we have in RT (which, IIRC, has an optimistic spinning implementation as well)? For the RT spinlock replacement, the top waiter can spin. Yeah and the difference with

Experiencing freezes with kernel 4.16.3 on a desktop with E5500 CPU (bisect included)

Hi, I'm currently experiencing freezes after resuming from suspend when using various applications on my desktop. For example, when using Firefox and switching between tabs the screen would freeze, allowing me to only move the mouse pointer but focusing the mouse pointer on a application won't

Experiencing freezes with kernel 4.16.3 on a desktop with E5500 CPU (bisect included)

Hi, I'm currently experiencing freezes after resuming from suspend when using various applications on my desktop. For example, when using Firefox and switching between tabs the screen would freeze, allowing me to only move the mouse pointer but focusing the mouse pointer on a application won't

Re: INFO: rcu detected stall in __process_echoes

On 2018/03/28 16:01, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 3eb2ce825ea1ad89d20f7a3b5780df850e4be274 (Sun Mar 25 22:44:30 2018 +) > Linux 4.16-rc7 > syzbot dashboard link: > https://syzkaller.appspot.com/bug?extid=108696293d7a21ab688f > > So far this

Re: INFO: rcu detected stall in __process_echoes

On 2018/03/28 16:01, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 3eb2ce825ea1ad89d20f7a3b5780df850e4be274 (Sun Mar 25 22:44:30 2018 +) > Linux 4.16-rc7 > syzbot dashboard link: > https://syzkaller.appspot.com/bug?extid=108696293d7a21ab688f > > So far this

Re: [PATCH 03/11] fs: add frozen sb state helpers

On Sun, Apr 22, 2018 at 01:53:23AM +0200, Jan Kara wrote: > On Fri 20-04-18 11:49:32, Luis R. Rodriguez wrote: > > On Tue, Apr 17, 2018 at 05:59:36PM -0700, Luis R. Rodriguez wrote: > > > On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote: > > > > Hello, > > > > > > > > I think I owe you a

Re: [PATCH 03/11] fs: add frozen sb state helpers

On Sun, Apr 22, 2018 at 01:53:23AM +0200, Jan Kara wrote: > On Fri 20-04-18 11:49:32, Luis R. Rodriguez wrote: > > On Tue, Apr 17, 2018 at 05:59:36PM -0700, Luis R. Rodriguez wrote: > > > On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote: > > > > Hello, > > > > > > > > I think I owe you a

Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV

On Sat, Apr 21, 2018 at 1:34 PM, Bjorn Helgaas wrote: > On Fri, Apr 20, 2018 at 12:28:08PM -0400, Alexander Duyck wrote: >> This series is meant to add support for SR-IOV on devices when the VFs are >> not managed by the kernel. Examples of recent patches attempting to do this

Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV

On Sat, Apr 21, 2018 at 1:34 PM, Bjorn Helgaas wrote: > On Fri, Apr 20, 2018 at 12:28:08PM -0400, Alexander Duyck wrote: >> This series is meant to add support for SR-IOV on devices when the VFs are >> not managed by the kernel. Examples of recent patches attempting to do this >> include: >>

[GIT PULL] libnvdimm fixes for 4.17-rc2

Hi Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive, a regression fix, new unit test infrastructure and a build fix. * The regression fix addresses support for the new NVDIMM label storage area access commands (_LSI, _LSR, and

[GIT PULL] libnvdimm fixes for 4.17-rc2

Hi Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive, a regression fix, new unit test infrastructure and a build fix. * The regression fix addresses support for the new NVDIMM label storage area access commands (_LSI, _LSR, and

Re: [PATCH v3] fs: dax: Adding new return type vm_fault_t

On Sat, Apr 21, 2018 at 2:54 PM, Souptick Joarder wrote: > On Sun, Apr 22, 2018 at 3:04 AM, Matthew Wilcox wrote: >> On Sun, Apr 22, 2018 at 02:35:29AM +0530, Souptick Joarder wrote: >>> Use new return type vm_fault_t for fault handler. For >>> now,

Re: [PATCH v3] fs: dax: Adding new return type vm_fault_t

On Sat, Apr 21, 2018 at 2:54 PM, Souptick Joarder wrote: > On Sun, Apr 22, 2018 at 3:04 AM, Matthew Wilcox wrote: >> On Sun, Apr 22, 2018 at 02:35:29AM +0530, Souptick Joarder wrote: >>> Use new return type vm_fault_t for fault handler. For >>> now, this is just documenting that the function

[PATCH] rpmsg: Correct support for MODULE_DEVICE_TABLE()

Due to missing a missing entry in file2alias.c MODULE_DEVICE_TABLE() are not generating the proper module aliases. Add the needed entry here. Reported-by: Suman Anna Signed-off-by: Andrew F. Davis --- scripts/mod/devicetable-offsets.c | 3 +++

[PATCH] rpmsg: Correct support for MODULE_DEVICE_TABLE()

Due to missing a missing entry in file2alias.c MODULE_DEVICE_TABLE() are not generating the proper module aliases. Add the needed entry here. Reported-by: Suman Anna Signed-off-by: Andrew F. Davis --- scripts/mod/devicetable-offsets.c | 3 +++ scripts/mod/file2alias.c | 11

Re: [PATCH 03/11] fs: add frozen sb state helpers

On Fri 20-04-18 11:49:32, Luis R. Rodriguez wrote: > On Tue, Apr 17, 2018 at 05:59:36PM -0700, Luis R. Rodriguez wrote: > > On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote: > > > Hello, > > > > > > I think I owe you a reply here... Sorry that it took so long. > > > > Took me just as

Re: [PATCH 03/11] fs: add frozen sb state helpers

On Fri 20-04-18 11:49:32, Luis R. Rodriguez wrote: > On Tue, Apr 17, 2018 at 05:59:36PM -0700, Luis R. Rodriguez wrote: > > On Thu, Dec 21, 2017 at 12:03:29PM +0100, Jan Kara wrote: > > > Hello, > > > > > > I think I owe you a reply here... Sorry that it took so long. > > > > Took me just as

Re: [PATCH] memcg: writeback: use memcg->cgwb_list directly

On Sat 21-04-18 21:29:41, Wang Long wrote: > Signed-off-by: Wang Long Yeah, looks good. I guess it was originally intended to avoid compilation errors if CONFIG_CGROUP_WRITEBACK was disabled. But it doesn't seem likely we'll ever need that list outside of code under

Re: [PATCH] memcg: writeback: use memcg->cgwb_list directly

On Sat 21-04-18 21:29:41, Wang Long wrote: > Signed-off-by: Wang Long Yeah, looks good. I guess it was originally intended to avoid compilation errors if CONFIG_CGROUP_WRITEBACK was disabled. But it doesn't seem likely we'll ever need that list outside of code under CONFIG_CGROUP_WRITEBACK. So

Re: [PATCH v2] ext4: handle errors on ext4_commit_super

On Thu 19-04-18 08:59:57, Jaegeuk Kim wrote: > When remounting ext4 from ro to rw, currently it allows its transition, > even if ext4_commit_super() returns EIO. Even worse thing is, after that, > fs/buffer complains buffer dirty bits like: > > Call trace: > [] mark_buffer_dirty+0x184/0x1a4 >

Re: [PATCH v2] ext4: handle errors on ext4_commit_super

On Thu 19-04-18 08:59:57, Jaegeuk Kim wrote: > When remounting ext4 from ro to rw, currently it allows its transition, > even if ext4_commit_super() returns EIO. Even worse thing is, after that, > fs/buffer complains buffer dirty bits like: > > Call trace: > [] mark_buffer_dirty+0x184/0x1a4 >

Re: [PATCH] SLUB: Do not fallback to mininum order if __GFP_NORETRY is set

On 04/20/2018 04:53 PM, Christopher Lameter wrote: > On Thu, 19 Apr 2018, Michal Hocko wrote: > >> Overriding __GFP_NORETRY is just a bad idea. It will make the semantic >> of the flag just more confusing. Note there are users who use >> __GFP_NORETRY as a way to suppress heavy memory pressure

Re: [PATCH] SLUB: Do not fallback to mininum order if __GFP_NORETRY is set

On 04/20/2018 04:53 PM, Christopher Lameter wrote: > On Thu, 19 Apr 2018, Michal Hocko wrote: > >> Overriding __GFP_NORETRY is just a bad idea. It will make the semantic >> of the flag just more confusing. Note there are users who use >> __GFP_NORETRY as a way to suppress heavy memory pressure

Re: [PATCH RFC 2/8] mm: introduce PG_offline

On 04/13/2018 07:11 PM, Matthew Wilcox wrote: > On Fri, Apr 13, 2018 at 03:16:26PM +0200, David Hildenbrand wrote: >> online_pages()/offline_pages() theoretically allows us to work on >> sub-section sizes. This is especially relevant in the context of >> virtualization. It e.g. allows us to

Re: [PATCH RFC 2/8] mm: introduce PG_offline

On 04/13/2018 07:11 PM, Matthew Wilcox wrote: > On Fri, Apr 13, 2018 at 03:16:26PM +0200, David Hildenbrand wrote: >> online_pages()/offline_pages() theoretically allows us to work on >> sub-section sizes. This is especially relevant in the context of >> virtualization. It e.g. allows us to

[PATCH 2/3] mm: add find_alloc_contig_pages() interface

On 04/17/2018 04:09 AM, Mike Kravetz wrote: > find_alloc_contig_pages() is a new interface that attempts to locate > and allocate a contiguous range of pages. It is provided as a more > convenient interface than alloc_contig_range() which is currently > used by CMA and gigantic huge pages. > >

[PATCH 2/3] mm: add find_alloc_contig_pages() interface

On 04/17/2018 04:09 AM, Mike Kravetz wrote: > find_alloc_contig_pages() is a new interface that attempts to locate > and allocate a contiguous range of pages. It is provided as a more > convenient interface than alloc_contig_range() which is currently > used by CMA and gigantic huge pages. > >

[PATCH] power: supply: bq27xxx: Add support for BQ27426

This device is software similar to the BQ27426 except it has different data memory offsets. Add support here. Signed-off-by: Andrew F. Davis --- .../devicetree/bindings/power/supply/bq27xxx.txt | 1 + drivers/power/supply/bq27xxx_battery.c | 9 +

[PATCH] power: supply: bq27xxx: Add support for BQ27426

This device is software similar to the BQ27426 except it has different data memory offsets. Add support here. Signed-off-by: Andrew F. Davis --- .../devicetree/bindings/power/supply/bq27xxx.txt | 1 + drivers/power/supply/bq27xxx_battery.c | 9 +

Re: [PATCH] Enable the clock before calling clk_get_rate().

+Jonas, On 04/19/2018 06:03 AM, Stefan Potyra wrote: > Found by Linux Driver Verification project (linuxtesting.org). Please use a commit subject which matches what was used before: git log --no-merges --oneline drivers/spi/spi-bcm63xx-hsspi.c 378da4a65f3a spi/bcm63xx-hspi: fix error return

Re: [PATCH] Enable the clock before calling clk_get_rate().

+Jonas, On 04/19/2018 06:03 AM, Stefan Potyra wrote: > Found by Linux Driver Verification project (linuxtesting.org). Please use a commit subject which matches what was used before: git log --no-merges --oneline drivers/spi/spi-bcm63xx-hsspi.c 378da4a65f3a spi/bcm63xx-hspi: fix error return

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On 21 April 2018 at 11:22, Botello Ortega, Luis wrote: > Hi all: > > We tested GLK DMC 1.04 FW in last week of September 2017, using the latest > drm-tip version for that time (4.14.0-rc2) and according to our results we > could declare this FW as acceptable and

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On 21 April 2018 at 11:22, Botello Ortega, Luis wrote: > Hi all: > > We tested GLK DMC 1.04 FW in last week of September 2017, using the latest > drm-tip version for that time (4.14.0-rc2) and according to our results we > could declare this FW as acceptable and healthy to be used with kernel

Re: [PATCH v3 4/7] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes

On 2018-04-21 18:19, Boris Brezillon wrote: > On Thu, 19 Apr 2018 18:27:48 +0200 > Peter Rosin wrote: > >> This beats the heuristic that the connector is involved in what format >> should be output for cases where this fails. >> >> E.g. if there is a bridge that changes format

Re: [PATCH v3 4/7] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes

On 2018-04-21 18:19, Boris Brezillon wrote: > On Thu, 19 Apr 2018 18:27:48 +0200 > Peter Rosin wrote: > >> This beats the heuristic that the connector is involved in what format >> should be output for cases where this fails. >> >> E.g. if there is a bridge that changes format between the

Re: [PATCH 22/22] parisc: use generic dma_noncoherent_ops

On Sat, 2018-04-21 at 19:43 +0200, Helge Deller wrote: > On 20.04.2018 10:03, Christoph Hellwig wrote: > > Switch to the generic noncoherent direct mapping implementation. > > > > Parisc previously had two different non-coherent dma ops > > implementation that just different in the way coherent

Re: [PATCH 22/22] parisc: use generic dma_noncoherent_ops

On Sat, 2018-04-21 at 19:43 +0200, Helge Deller wrote: > On 20.04.2018 10:03, Christoph Hellwig wrote: > > Switch to the generic noncoherent direct mapping implementation. > > > > Parisc previously had two different non-coherent dma ops > > implementation that just different in the way coherent

Re: [PATCH v3] fs: dax: Adding new return type vm_fault_t

On Sun, Apr 22, 2018 at 3:04 AM, Matthew Wilcox wrote: > On Sun, Apr 22, 2018 at 02:35:29AM +0530, Souptick Joarder wrote: >> Use new return type vm_fault_t for fault handler. For >> now, this is just documenting that the function returns >> a VM_FAULT value rather than an

Re: [PATCH v3] fs: dax: Adding new return type vm_fault_t

On Sun, Apr 22, 2018 at 3:04 AM, Matthew Wilcox wrote: > On Sun, Apr 22, 2018 at 02:35:29AM +0530, Souptick Joarder wrote: >> Use new return type vm_fault_t for fault handler. For >> now, this is just documenting that the function returns >> a VM_FAULT value rather than an errno. Once all

Re: [PATCH 22/22] parisc: use generic dma_noncoherent_ops

On Fri, 2018-04-20 at 10:03 +0200, Christoph Hellwig wrote: > diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c > index 8d3a7b80ac42..4e87c35c22b7 100644 > --- a/arch/parisc/kernel/setup.c > +++ b/arch/parisc/kernel/setup.c > @@ -97,14 +97,12 @@ void __init dma_ops_init(void) >  

Re: [PATCH 22/22] parisc: use generic dma_noncoherent_ops

On Fri, 2018-04-20 at 10:03 +0200, Christoph Hellwig wrote: > diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c > index 8d3a7b80ac42..4e87c35c22b7 100644 > --- a/arch/parisc/kernel/setup.c > +++ b/arch/parisc/kernel/setup.c > @@ -97,14 +97,12 @@ void __init dma_ops_init(void) >  

Re: [PATCH v3] fs: dax: Adding new return type vm_fault_t

On Sun, Apr 22, 2018 at 02:35:29AM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a distinct type. >

Re: [PATCH v3] fs: dax: Adding new return type vm_fault_t

On Sun, Apr 22, 2018 at 02:35:29AM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a distinct type. >

Re: [PATCH 4/7] sched/core: uclamp: add utilization clamping to the CPU controller

Hi Tejun, On Tue, Apr 10, 2018 at 1:05 PM, Tejun Heo wrote: > Hello, > > On Tue, Apr 10, 2018 at 06:16:12PM +0100, Patrick Bellasi wrote: >> > I'm not too enthusiastic about util_min/max given that it can easily >> > be read as actual utilization based bandwidth control when

Re: [PATCH 4/7] sched/core: uclamp: add utilization clamping to the CPU controller

Hi Tejun, On Tue, Apr 10, 2018 at 1:05 PM, Tejun Heo wrote: > Hello, > > On Tue, Apr 10, 2018 at 06:16:12PM +0100, Patrick Bellasi wrote: >> > I'm not too enthusiastic about util_min/max given that it can easily >> > be read as actual utilization based bandwidth control when what's >> > actually

[PATCH v3] fs: dax: Adding new return type vm_fault_t

Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. commit 1c8f422059ae ("mm: change return type to vm_fault_t") There was an

[PATCH v3] fs: dax: Adding new return type vm_fault_t

Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. commit 1c8f422059ae ("mm: change return type to vm_fault_t") There was an

Re: [PATCH 2/2] iio: adc128s052: add ACPI _HID AANT1280

Hi Jonathan, On Sat, Apr 21, 2018 at 05:05:05PM +0100, Jonathan Cameron wrote: > This is in principle fine, but I'd like to see it done somewhat more > explicitly. > > 1) Add the adc124s101 and similar families to the driver first. I think >this is just a case of IDs for all of >

Re: [PATCH 2/2] iio: adc128s052: add ACPI _HID AANT1280

Hi Jonathan, On Sat, Apr 21, 2018 at 05:05:05PM +0100, Jonathan Cameron wrote: > This is in principle fine, but I'd like to see it done somewhat more > explicitly. > > 1) Add the adc124s101 and similar families to the driver first. I think >this is just a case of IDs for all of >

Re: [PATCH 1/2] iio: adc128s052: allow driver to be matched using ACPI

Hi Jonathan, On Sat, Apr 21, 2018 at 04:54:41PM +0100, Jonathan Cameron wrote: > I don't really see the connection between the change in here > and what the description says... I think you're right, we didn't make our intent clear here. > If you are probing from ACPI then there is no need to

Re: [PATCH 1/2] iio: adc128s052: allow driver to be matched using ACPI

Hi Jonathan, On Sat, Apr 21, 2018 at 04:54:41PM +0100, Jonathan Cameron wrote: > I don't really see the connection between the change in here > and what the description says... I think you're right, we didn't make our intent clear here. > If you are probing from ACPI then there is no need to

Re: possible BUG: selftests: proc-loadavg-001 failed during kernel testing

This problem is fixed now. $sudo make -C tools/testing/selftests/proc run_tests [sudo] password for jeffrin: make: Entering directory '/home/jeffrin/upstream-kernel/linux/tools/testing/selftests/proc' TAP version 13 selftests: proc-loadavg-001 ok 1..1

Re: possible BUG: selftests: proc-loadavg-001 failed during kernel testing

This problem is fixed now. $sudo make -C tools/testing/selftests/proc run_tests [sudo] password for jeffrin: make: Entering directory '/home/jeffrin/upstream-kernel/linux/tools/testing/selftests/proc' TAP version 13 selftests: proc-loadavg-001 ok 1..1

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Sat, Apr 21, 2018 at 11:34:22PM +0300, Alexey Dobriyan wrote: > On Thu, Apr 19, 2018 at 04:23:02PM -0700, Joel Fernandes (Google) wrote: > > Can we not just remove per-IRQ stats from /proc/stat (since I gather > > from this discussion it isn't scalable), and just have applications > > that need

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Sat, Apr 21, 2018 at 11:34:22PM +0300, Alexey Dobriyan wrote: > On Thu, Apr 19, 2018 at 04:23:02PM -0700, Joel Fernandes (Google) wrote: > > Can we not just remove per-IRQ stats from /proc/stat (since I gather > > from this discussion it isn't scalable), and just have applications > > that need

Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV

On Fri, Apr 20, 2018 at 12:28:08PM -0400, Alexander Duyck wrote: > This series is meant to add support for SR-IOV on devices when the VFs are > not managed by the kernel. Examples of recent patches attempting to do this > include: > virto - https://patchwork.kernel.org/patch/10241225/ > pci-stub -

Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV

On Fri, Apr 20, 2018 at 12:28:08PM -0400, Alexander Duyck wrote: > This series is meant to add support for SR-IOV on devices when the VFs are > not managed by the kernel. Examples of recent patches attempting to do this > include: > virto - https://patchwork.kernel.org/patch/10241225/ > pci-stub -

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Thu, Apr 19, 2018 at 04:23:02PM -0700, Joel Fernandes (Google) wrote: > Can we not just remove per-IRQ stats from /proc/stat (since I gather > from this discussion it isn't scalable), and just have applications > that need per-IRQ stats use /proc/interrupts ? If you can prove noone is using

Re: [PATCH] proc/stat: Separate out individual irq counts into /proc/stat_irqs

On Thu, Apr 19, 2018 at 04:23:02PM -0700, Joel Fernandes (Google) wrote: > Can we not just remove per-IRQ stats from /proc/stat (since I gather > from this discussion it isn't scalable), and just have applications > that need per-IRQ stats use /proc/interrupts ? If you can prove noone is using

False memory leak in iwlmvm

Gentlemen, I was checking a scan of /sys/kernel/debug/kmemleak with 4.17.0-rc1 and came across this leak message arising from iwlwifi. It is a false message as unloading iwlmvm has it disappearing from the scan. Thanks, Larry unreferenced object 0x88021da6c580 (size 128): comm

False memory leak in iwlmvm

Gentlemen, I was checking a scan of /sys/kernel/debug/kmemleak with 4.17.0-rc1 and came across this leak message arising from iwlwifi. It is a false message as unloading iwlmvm has it disappearing from the scan. Thanks, Larry unreferenced object 0x88021da6c580 (size 128): comm

Re: [PATCH v2] fs: dax: Adding new return type vm_fault_t

On Sat, Apr 21, 2018 at 10:44:42PM +0530, Souptick Joarder wrote: > @@ -1112,7 +1112,7 @@ int __dax_zero_page_range(struct block_device *bdev, > } > EXPORT_SYMBOL_GPL(dax_iomap_rw); > > -static int dax_fault_return(int error) > +static vm_fault_t dax_fault_return(int error) > { > if

Re: [PATCH v2] fs: dax: Adding new return type vm_fault_t

On Sat, Apr 21, 2018 at 10:44:42PM +0530, Souptick Joarder wrote: > @@ -1112,7 +1112,7 @@ int __dax_zero_page_range(struct block_device *bdev, > } > EXPORT_SYMBOL_GPL(dax_iomap_rw); > > -static int dax_fault_return(int error) > +static vm_fault_t dax_fault_return(int error) > { > if

Re: [PATCH] Input: atmel_mxt_ts - fix reset-gpio for level based irqs

On Fri, Apr 20, 2018 at 09:42:07PM +0200, Sebastian Reichel wrote: > On Fri, Apr 20, 2018 at 02:44:02PM -0300, Ezequiel Garcia wrote: > > Hi Sebastian, > > > > On Fri, 2018-04-20 at 19:24 +0200, Sebastian Reichel wrote: > > > The current reset-gpio support triggers an interrupt storm on platforms

Re: [PATCH] Input: atmel_mxt_ts - fix reset-gpio for level based irqs

On Fri, Apr 20, 2018 at 09:42:07PM +0200, Sebastian Reichel wrote: > On Fri, Apr 20, 2018 at 02:44:02PM -0300, Ezequiel Garcia wrote: > > Hi Sebastian, > > > > On Fri, 2018-04-20 at 19:24 +0200, Sebastian Reichel wrote: > > > The current reset-gpio support triggers an interrupt storm on platforms

Dear friend

Dear friend I am contacting you for a business deal of $17.5 Million US Dollars, ready for transfer into your account if we make this claim, we will share it 60%/40%. 100% risk free and it will be legally backed up with government approved If you are interested reply for more details. You can

Dear friend

Dear friend I am contacting you for a business deal of $17.5 Million US Dollars, ready for transfer into your account if we make this claim, we will share it 60%/40%. 100% risk free and it will be legally backed up with government approved If you are interested reply for more details. You can

Re: [PATCH] mm: memory: Introduce new vmf_insert_mixed_mkwrite

On Sun, Apr 22, 2018 at 1:04 AM, Matthew Wilcox wrote: > On Sat, Apr 21, 2018 at 10:35:40PM +0530, Souptick Joarder wrote: >> As of now vm_insert_mixed_mkwrite() is only getting >> invoked from fs/dax.c, so this change has to go first >> in linus tree before changes in dax. >

Re: [PATCH] mm: memory: Introduce new vmf_insert_mixed_mkwrite

On Sun, Apr 22, 2018 at 1:04 AM, Matthew Wilcox wrote: > On Sat, Apr 21, 2018 at 10:35:40PM +0530, Souptick Joarder wrote: >> As of now vm_insert_mixed_mkwrite() is only getting >> invoked from fs/dax.c, so this change has to go first >> in linus tree before changes in dax. > > No. One patch

Re: WARNING in perf_trace_buf_alloc (2)

[+bpf maintainers and netdev] On Mon, Nov 06, 2017 at 03:56:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 5cb0512c02ecd7e6214e912e4c150f4219ac78e0 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 >

Re: [PATCH 29/61] mtd: devices: simplify getting .drvdata

Wolfram Sang writes: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Acked-by: Robert Jarzmik

Re: WARNING in perf_trace_buf_alloc (2)

[+bpf maintainers and netdev] On Mon, Nov 06, 2017 at 03:56:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 5cb0512c02ecd7e6214e912e4c150f4219ac78e0 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 >

Re: [PATCH 29/61] mtd: devices: simplify getting .drvdata

Wolfram Sang writes: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Acked-by: Robert Jarzmik Cheers. -- Robert

Re: [PATCH] mm: memory: Introduce new vmf_insert_mixed_mkwrite

On Sat, Apr 21, 2018 at 10:35:40PM +0530, Souptick Joarder wrote: > As of now vm_insert_mixed_mkwrite() is only getting > invoked from fs/dax.c, so this change has to go first > in linus tree before changes in dax. No. One patch which changes both at the same time. The history should be

Re: [PATCH] mm: memory: Introduce new vmf_insert_mixed_mkwrite

On Sat, Apr 21, 2018 at 10:35:40PM +0530, Souptick Joarder wrote: > As of now vm_insert_mixed_mkwrite() is only getting > invoked from fs/dax.c, so this change has to go first > in linus tree before changes in dax. No. One patch which changes both at the same time. The history should be

Re: [PATCH 10/15] ata: pata_pxa: remove the dmaengine compat need

Robert Jarzmik writes: > As the pxa architecture switched towards the dmaengine slave map, the > old compatibility mechanism to acquire the dma requestor line number and > priority are not needed anymore. > > This patch simplifies the dma resource acquisition, using the

Re: [PATCH 10/15] ata: pata_pxa: remove the dmaengine compat need

Robert Jarzmik writes: > As the pxa architecture switched towards the dmaengine slave map, the > old compatibility mechanism to acquire the dma requestor line number and > priority are not needed anymore. > > This patch simplifies the dma resource acquisition, using the more > generic function

Re: [PATCH 09/15] net: irda: pxaficp_ir: remove the dmaengine compat need

Robert Jarzmik writes: > As the pxa architecture switched towards the dmaengine slave map, the > old compatibility mechanism to acquire the dma requestor line number and > priority are not needed anymore. > > This patch simplifies the dma resource acquisition, using the

Re: [PATCH 09/15] net: irda: pxaficp_ir: remove the dmaengine compat need

Robert Jarzmik writes: > As the pxa architecture switched towards the dmaengine slave map, the > old compatibility mechanism to acquire the dma requestor line number and > priority are not needed anymore. > > This patch simplifies the dma resource acquisition, using the more > generic function

Re: [PATCH 04/15] media: pxa_camera: remove the dmaengine compat need

Robert Jarzmik writes: > From: Robert Jarzmik > > As the pxa architecture switched towards the dmaengine slave map, the > old compatibility mechanism to acquire the dma requestor line number and > priority are not needed anymore. > > This

Re: [PATCH 04/15] media: pxa_camera: remove the dmaengine compat need

Robert Jarzmik writes: > From: Robert Jarzmik > > As the pxa architecture switched towards the dmaengine slave map, the > old compatibility mechanism to acquire the dma requestor line number and > priority are not needed anymore. > > This patch simplifies the dma resource acquisition, using the

Re: [PATCH] platform/x86: acer-wmi: add another KEY_POWER keycode

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, On 20/04/2018 23:26, Antonio Rosario Intilisano wrote: > Now that we have informed the firmware that the Power Button driver is > active, laptops such as the Acer Swift 3 will generate > a WMI key event with code 0x87 when the

Re: [PATCH] platform/x86: acer-wmi: add another KEY_POWER keycode

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, On 20/04/2018 23:26, Antonio Rosario Intilisano wrote: > Now that we have informed the firmware that the Power Button driver is > active, laptops such as the Acer Swift 3 will generate > a WMI key event with code 0x87 when the

[PATCH] ARM: dts: exynos: Fix invalid node referenced by i2c20 alias

After moving all nodes under "soc" node in commit 5d99cc59a3c6 ("ARM: dts: exynos: Move Exynos5250 and Exynos5420 nodes under soc"), the i2c20 alias stopped point to proper node: arch/arm/boot/dts/exynos5420-peach-pit.dtb: Warning (alias_paths): /aliases:i2c20: aliases property is not

[PATCH] ARM: dts: exynos: Fix invalid node referenced by i2c20 alias

After moving all nodes under "soc" node in commit 5d99cc59a3c6 ("ARM: dts: exynos: Move Exynos5250 and Exynos5420 nodes under soc"), the i2c20 alias stopped point to proper node: arch/arm/boot/dts/exynos5420-peach-pit.dtb: Warning (alias_paths): /aliases:i2c20: aliases property is not

Re: possible deadlock in ftrace_profile_set_filter (2)

On Mon, Jan 22, 2018 at 09:49:00AM -0800, syzbot wrote: > syzbot has found reproducer for the following crash on > git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/master commit > ebdd7b491b8a65d65936e07004caabca4a3c94a0 (Sun Jan 21 23:21:31 2018 +) > Merge branch

Re: possible deadlock in ftrace_profile_set_filter (2)

On Mon, Jan 22, 2018 at 09:49:00AM -0800, syzbot wrote: > syzbot has found reproducer for the following crash on > git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/master commit > ebdd7b491b8a65d65936e07004caabca4a3c94a0 (Sun Jan 21 23:21:31 2018 +) > Merge branch

  1   2   3   4   >