RE: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

>-Original Message- >From: Javier Martinez Canillas [mailto:javi...@redhat.com] >Sent: Monday, December 18, 2017 11:30 AM >To: Jason Gunthorpe >Cc: Jarkko Sakkinen ; James Ettle >; linux-integr...@vger.kernel.org;

RE: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

>-Original Message- >From: Javier Martinez Canillas [mailto:javi...@redhat.com] >Sent: Monday, December 18, 2017 11:30 AM >To: Jason Gunthorpe >Cc: Jarkko Sakkinen ; James Ettle >; linux-integr...@vger.kernel.org; Shaikh, Azhar >; linux-kernel@vger.kernel.org; >james.l.mor...@oracle.com

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

Hello James, On 12/18/2017 07:26 PM, James Ettle wrote: > The keyboard and touchpad work OK with the patch quoted below and the earlier > two applied, i.e. the three patches with signatures: > > 667dcc75be864ff4c17cf58891853b7393bba3e2 > db3248e8a036c39141c8f7e9f1cf5c5ae6815f76 >

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

Hello James, On 12/18/2017 07:26 PM, James Ettle wrote: > The keyboard and touchpad work OK with the patch quoted below and the earlier > two applied, i.e. the three patches with signatures: > > 667dcc75be864ff4c17cf58891853b7393bba3e2 > db3248e8a036c39141c8f7e9f1cf5c5ae6815f76 >

Re: [PATCH v4 1/2] dm-unstripe: unstripe RAID 0/dm-striped device

On Mon, Dec 18 2017 at 1:52pm -0500, Scott Bauer wrote: > > > > +config DM_UN_STRIPE > > > + tristate "Transpose IO to individual drives on a raid device" > > > + depends on BLK_DEV_DM > > > + ---help--- > > > + Enable this feature if you with to

Re: [PATCH v4 1/2] dm-unstripe: unstripe RAID 0/dm-striped device

On Mon, Dec 18 2017 at 1:52pm -0500, Scott Bauer wrote: > > > > +config DM_UN_STRIPE > > > + tristate "Transpose IO to individual drives on a raid device" > > > + depends on BLK_DEV_DM > > > + ---help--- > > > + Enable this feature if you with to unstripe I/O on a RAID 0 >

Re: [PATCH v4.1 2/2] livepatch: force transition to finish

On Mon, Dec 18, 2017 at 02:23:40PM +0100, Miroslav Benes wrote: > On Fri, 15 Dec 2017, Jason Baron wrote: > > > On 11/22/2017 05:29 AM, Miroslav Benes wrote: > > > If a task sleeps in a set of patched functions uninterruptedly, it could > > > block the whole transition indefinitely. Thus it may

Re: [PATCH v4.1 2/2] livepatch: force transition to finish

On Mon, Dec 18, 2017 at 02:23:40PM +0100, Miroslav Benes wrote: > On Fri, 15 Dec 2017, Jason Baron wrote: > > > On 11/22/2017 05:29 AM, Miroslav Benes wrote: > > > If a task sleeps in a set of patched functions uninterruptedly, it could > > > block the whole transition indefinitely. Thus it may

Re: [PATCH v2] Adjustments: lock/unlock task in context_switch

Thanks; I've slightly changed it, find below. I'll queue it for the next merge window. --- Subject: sched: Rework / clarify prepare_lock_switch() From: rodrigosiqueira Date: Fri, 15 Dec 2017 12:06:03 -0200 The function prepare_lock_switch has an unused

Re: [PATCH v2] Adjustments: lock/unlock task in context_switch

Thanks; I've slightly changed it, find below. I'll queue it for the next merge window. --- Subject: sched: Rework / clarify prepare_lock_switch() From: rodrigosiqueira Date: Fri, 15 Dec 2017 12:06:03 -0200 The function prepare_lock_switch has an unused parameter, and also the function name

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

Hello Jason, Thanks a lot for your feedback. On 12/18/2017 06:55 PM, Jason Gunthorpe wrote: > On Mon, Dec 18, 2017 at 01:29:01PM +0100, Javier Martinez Canillas wrote: >> On 12/18/2017 01:22 PM, Javier Martinez Canillas wrote: >> >> [snip] >> >>> >>> James, >>> >>> Can you please test the

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

Hello Jason, Thanks a lot for your feedback. On 12/18/2017 06:55 PM, Jason Gunthorpe wrote: > On Mon, Dec 18, 2017 at 01:29:01PM +0100, Javier Martinez Canillas wrote: >> On 12/18/2017 01:22 PM, Javier Martinez Canillas wrote: >> >> [snip] >> >>> >>> James, >>> >>> Can you please test the

Re: [PATCH] Staging: irda: Do not check for NOT NULL before kfree()

On Mon, 2017-12-18 at 11:20 -0800, Stephen Hemminger wrote: > On Tue, 19 Dec 2017 00:41:30 +0530 > Shreeya Patel wrote: > > > > > Do not check for NOT NULL before calling kfree because if the > > pointer is NULL, no action occurs. > > Done using the following

Re: [PATCH] Staging: irda: Do not check for NOT NULL before kfree()

On Mon, 2017-12-18 at 11:20 -0800, Stephen Hemminger wrote: > On Tue, 19 Dec 2017 00:41:30 +0530 > Shreeya Patel wrote: > > > > > Do not check for NOT NULL before calling kfree because if the > > pointer is NULL, no action occurs. > > Done using the following semantic patch by coccinelle. > >

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

On Mon, Dec 18, 2017 at 07:39:50PM +0100, Knut Omang wrote: > On Mon, 2017-12-18 at 17:56 +, Bart Van Assche wrote: > > On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote: > > > On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote: > > > > > > > > Today when we run checkers we get

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

On Mon, Dec 18, 2017 at 07:39:50PM +0100, Knut Omang wrote: > On Mon, 2017-12-18 at 17:56 +, Bart Van Assche wrote: > > On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote: > > > On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote: > > > > > > > > Today when we run checkers we get

Re: [net-next] phylib: Add device reset GPIO support causes DSA MT7530 acquires reset-gpios fails

On 12/18/2017 12:01 AM, Andrew Lunn wrote: > Hi Sean > >> It probably can't. Because before the GPIO line is manipulated to reset, >> certain power control should be handled such as power sources from >> external PMIC to let devices actually enter the proper state. >> >> So, I thought the kind of

Re: [net-next] phylib: Add device reset GPIO support causes DSA MT7530 acquires reset-gpios fails

On 12/18/2017 12:01 AM, Andrew Lunn wrote: > Hi Sean > >> It probably can't. Because before the GPIO line is manipulated to reset, >> certain power control should be handled such as power sources from >> external PMIC to let devices actually enter the proper state. >> >> So, I thought the kind of

Re: [PATCH] Staging: irda: Do not check for NOT NULL before kfree()

On Tue, 19 Dec 2017 00:41:30 +0530 Shreeya Patel wrote: > Do not check for NOT NULL before calling kfree because if the > pointer is NULL, no action occurs. > Done using the following semantic patch by coccinelle. > > @@ > expression ptr; > @@ > > - if (ptr !=

Re: [PATCH] Staging: irda: Do not check for NOT NULL before kfree()

On Tue, 19 Dec 2017 00:41:30 +0530 Shreeya Patel wrote: > Do not check for NOT NULL before calling kfree because if the > pointer is NULL, no action occurs. > Done using the following semantic patch by coccinelle. > > @@ > expression ptr; > @@ > > - if (ptr != NULL) { > kfree(ptr); > ptr =

Re: [PATCH] [man-pages] adjtimex.2: document clock_adjtime

Hi Richard, On 11/21/2017 05:06 PM, Richard Cochran wrote: > On Tue, Nov 21, 2017 at 09:06:37AM +0100, Arnd Bergmann wrote: >> >> I copied that line from clock_gettime() man page. I suppose we want to >> fix change this in both pages, right? Any suggestions for a good way to >> express your

Re: [PATCH] [man-pages] adjtimex.2: document clock_adjtime

Hi Richard, On 11/21/2017 05:06 PM, Richard Cochran wrote: > On Tue, Nov 21, 2017 at 09:06:37AM +0100, Arnd Bergmann wrote: >> >> I copied that line from clock_gettime() man page. I suppose we want to >> fix change this in both pages, right? Any suggestions for a good way to >> express your

Re: [PATCH v2 5/5] RDMA/core: Add runchecks.cfg for drivers/infiniband/core

On Mon, Dec 18, 2017 at 11:03:51AM -0800, Joe Perches wrote: > On Mon, 2017-12-18 at 13:36 +0100, Knut Omang wrote: > > On Mon, 2017-12-18 at 10:02 +0200, Leon Romanovsky wrote: > [] > > > Also, I agree with other reviewers, there is no excuse for adding > > > checkpatch specifics

Re: [PATCH v2 5/5] RDMA/core: Add runchecks.cfg for drivers/infiniband/core

On Mon, Dec 18, 2017 at 11:03:51AM -0800, Joe Perches wrote: > On Mon, 2017-12-18 at 13:36 +0100, Knut Omang wrote: > > On Mon, 2017-12-18 at 10:02 +0200, Leon Romanovsky wrote: > [] > > > Also, I agree with other reviewers, there is no excuse for adding > > > checkpatch specifics

Re: [PATCH v5] mmap.2: MAP_FIXED updated documentation

On 12/12/2017 01:23 AM, john.hubb...@gmail.com wrote: > From: John Hubbard > > -- Expand the documentation to discuss the hazards in >enough detail to allow avoiding them. > > -- Mention the upcoming MAP_FIXED_SAFE flag. > > -- Enhance the alignment

Re: [PATCH v5] mmap.2: MAP_FIXED updated documentation

On 12/12/2017 01:23 AM, john.hubb...@gmail.com wrote: > From: John Hubbard > > -- Expand the documentation to discuss the hazards in >enough detail to allow avoiding them. > > -- Mention the upcoming MAP_FIXED_SAFE flag. > > -- Enhance the alignment requirement slightly. >

Re: [PATCH v4 1/2] dm-unstripe: unstripe RAID 0/dm-striped device

> > +config DM_UN_STRIPE > > + tristate "Transpose IO to individual drives on a raid device" > > + depends on BLK_DEV_DM > > + ---help--- > > + Enable this feature if you with to unstripe I/O on a RAID 0 > > + device to the respective drive. If your hardware has physical

Re: [PATCH v4 1/2] dm-unstripe: unstripe RAID 0/dm-striped device

> > +config DM_UN_STRIPE > > + tristate "Transpose IO to individual drives on a raid device" > > + depends on BLK_DEV_DM > > + ---help--- > > + Enable this feature if you with to unstripe I/O on a RAID 0 > > + device to the respective drive. If your hardware has physical

RE: [PATCH V2 6/8] perf top: add overwrite fall back

> > On 2017/12/7 7:33, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Switch to non-overwrite mode if kernel doesnot support overwrite > > ringbuffer. > > > > It's only effect when overwrite mode is supported. > > No change to current behavior. > > > > Signed-off-by:

RE: [PATCH V2 6/8] perf top: add overwrite fall back

> > On 2017/12/7 7:33, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Switch to non-overwrite mode if kernel doesnot support overwrite > > ringbuffer. > > > > It's only effect when overwrite mode is supported. > > No change to current behavior. > > > > Signed-off-by: Kan Liang > > --- >

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On Mon, 2017-12-18 at 20:01 +0100, Tobias Klausmann wrote: > On 12/18/17 7:06 PM, Mike Galbraith wrote: > > Greetings, > > > > Kernel bound workloads seem to trigger the below for whatever reason. > >  I only see this when beating up NFS.  There was a kworker wakeup > > latency issue, but with a

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On Mon, 2017-12-18 at 20:01 +0100, Tobias Klausmann wrote: > On 12/18/17 7:06 PM, Mike Galbraith wrote: > > Greetings, > > > > Kernel bound workloads seem to trigger the below for whatever reason. > >  I only see this when beating up NFS.  There was a kworker wakeup > > latency issue, but with a

Re: [PATCH 2/2] mmap.2: MAP_FIXED updated documentation

Hello Kees, I'm late to the party, and only just caught up with the fuss :-). On 12/14/2017 12:19 AM, Kees Cook wrote: > On Wed, Dec 13, 2017 at 6:40 AM, Cyril Hrubis wrote: >> Hi! >>> You selected stupid name for a flag. Everyone and their dog agrees >>> with that. There's

Re: [PATCH 2/2] mmap.2: MAP_FIXED updated documentation

Hello Kees, I'm late to the party, and only just caught up with the fuss :-). On 12/14/2017 12:19 AM, Kees Cook wrote: > On Wed, Dec 13, 2017 at 6:40 AM, Cyril Hrubis wrote: >> Hi! >>> You selected stupid name for a flag. Everyone and their dog agrees >>> with that. There's even consensus on

Re: [PATCH v4 1/2] dm-unstripe: unstripe RAID 0/dm-striped device

On 12/18/2017 09:28 AM, Scott Bauer wrote: > This device mapper module remaps and unstripes IO so it lands > solely on a single drive in a RAID 0/dm-stripe target. > In a 4 drive RAID 0 the mapper exposes 1/4th of the LBA range > as a virtual drive. Each IO to that virtual drive will land on >

Re: [PATCH v4 1/2] dm-unstripe: unstripe RAID 0/dm-striped device

On 12/18/2017 09:28 AM, Scott Bauer wrote: > This device mapper module remaps and unstripes IO so it lands > solely on a single drive in a RAID 0/dm-stripe target. > In a 4 drive RAID 0 the mapper exposes 1/4th of the LBA range > as a virtual drive. Each IO to that virtual drive will land on >

[PATCH] Staging: irda: Do not check for NOT NULL before kfree()

Do not check for NOT NULL before calling kfree because if the pointer is NULL, no action occurs. Done using the following semantic patch by coccinelle. @@ expression ptr; @@ - if (ptr != NULL) { kfree(ptr); ptr = NULL; - } The semantic patch has the effect of adding an assignment of ptr to

[PATCH] Staging: irda: Do not check for NOT NULL before kfree()

Do not check for NOT NULL before calling kfree because if the pointer is NULL, no action occurs. Done using the following semantic patch by coccinelle. @@ expression ptr; @@ - if (ptr != NULL) { kfree(ptr); ptr = NULL; - } The semantic patch has the effect of adding an assignment of ptr to

Re: [PATCH 2/5 v3] Modify behaviour of request_*muxed_region()

On Mon, Dec 18, 2017 at 09:48:38AM +0100, Zoltan Boszormenyi wrote: > From: Böszörményi Zoltán > > In order to make request_*muxed_region() behave more like > mutex_lock(), a possible failure case needs to be eliminated. > When drivers do not properly share the same I/O region,

Re: [PATCH 2/5 v3] Modify behaviour of request_*muxed_region()

On Mon, Dec 18, 2017 at 09:48:38AM +0100, Zoltan Boszormenyi wrote: > From: Böszörményi Zoltán > > In order to make request_*muxed_region() behave more like > mutex_lock(), a possible failure case needs to be eliminated. > When drivers do not properly share the same I/O region, e.g. > one is

RE: [PATCH V2 2/8] perf tools: rewrite perf mmap read for overwrite

> > -union perf_event *perf_mmap__read_backward(struct perf_mmap *map) > > +union perf_event *perf_mmap__read_backward(struct perf_mmap *map, > > + u64 *start, u64 end) > > { > > - u64 head, end; > > - u64 start = map->prev; > > - > > - /* > > -*

RE: [PATCH V2 2/8] perf tools: rewrite perf mmap read for overwrite

> > -union perf_event *perf_mmap__read_backward(struct perf_mmap *map) > > +union perf_event *perf_mmap__read_backward(struct perf_mmap *map, > > + u64 *start, u64 end) > > { > > - u64 head, end; > > - u64 start = map->prev; > > - > > - /* > > -*

Re: [PATCH v2 5/5] RDMA/core: Add runchecks.cfg for drivers/infiniband/core

On Mon, 2017-12-18 at 13:36 +0100, Knut Omang wrote: > On Mon, 2017-12-18 at 10:02 +0200, Leon Romanovsky wrote: [] > > Also, I agree with other reviewers, there is no excuse for adding > > checkpatch specifics per-subsystem/folder, the differences are better > > to be treated in checkpatch.pl

Re: [PATCH v2 5/5] RDMA/core: Add runchecks.cfg for drivers/infiniband/core

On Mon, 2017-12-18 at 13:36 +0100, Knut Omang wrote: > On Mon, 2017-12-18 at 10:02 +0200, Leon Romanovsky wrote: [] > > Also, I agree with other reviewers, there is no excuse for adding > > checkpatch specifics per-subsystem/folder, the differences are better > > to be treated in checkpatch.pl

Re: [PATCH] clk: check ops pointer on clock register

On 12/18, Jerome Brunet wrote: > Nothing really prevents a provider from (trying to) register a clock > without providing the clock ops structure. > > We do check the individual fields before using them, but not the > structure pointer itself. This may have the usual nasty consequences when > the

Re: [PATCH] clk: check ops pointer on clock register

On 12/18, Jerome Brunet wrote: > Nothing really prevents a provider from (trying to) register a clock > without providing the clock ops structure. > > We do check the individual fields before using them, but not the > structure pointer itself. This may have the usual nasty consequences when > the

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On 12/18/17 7:06 PM, Mike Galbraith wrote: Greetings, Kernel bound workloads seem to trigger the below for whatever reason.  I only see this when beating up NFS.  There was a kworker wakeup latency issue, but with a bandaid applied to fix that up, I can still trigger this. Hi, i have seen

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On 12/18/17 7:06 PM, Mike Galbraith wrote: Greetings, Kernel bound workloads seem to trigger the below for whatever reason.  I only see this when beating up NFS.  There was a kworker wakeup latency issue, but with a bandaid applied to fix that up, I can still trigger this. Hi, i have seen

Re: [PATCH 1/5 v3] Extend the request_region() infrastructure

On Mon, Dec 18, 2017 at 09:48:37AM +0100, Zoltan Boszormenyi wrote: > From: Böszörményi Zoltán > > Add a new IORESOURCE_ALLOCATED flag that is automatically used > when alloc_resource() is used internally in kernel/resource.c > and free_resource() now takes this flag into account.

Re: [PATCH 1/5 v3] Extend the request_region() infrastructure

On Mon, Dec 18, 2017 at 09:48:37AM +0100, Zoltan Boszormenyi wrote: > From: Böszörményi Zoltán > > Add a new IORESOURCE_ALLOCATED flag that is automatically used > when alloc_resource() is used internally in kernel/resource.c > and free_resource() now takes this flag into account. > > The core

Re: [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE

On Mon, Dec 18, 2017 at 03:33:34PM +1000, Nicholas Piggin wrote: > On Sun, 17 Dec 2017 20:58:54 -0600 > Josh Poimboeuf wrote: > > > On Fri, Dec 15, 2017 at 07:40:09PM +1000, Nicholas Piggin wrote: > > > On Tue, 12 Dec 2017 08:05:01 -0600 > > > Josh Poimboeuf

Re: [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE

On Mon, Dec 18, 2017 at 03:33:34PM +1000, Nicholas Piggin wrote: > On Sun, 17 Dec 2017 20:58:54 -0600 > Josh Poimboeuf wrote: > > > On Fri, Dec 15, 2017 at 07:40:09PM +1000, Nicholas Piggin wrote: > > > On Tue, 12 Dec 2017 08:05:01 -0600 > > > Josh Poimboeuf wrote: > > > > > > > On Tue, Dec

Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

On 11/06/2017 12:57 AM, Ram Pai wrote: > Expose useful information for programs using memory protection keys. > Provide implementation for powerpc and x86. > > On a powerpc system with pkeys support, here is what is shown: > > $ head /sys/kernel/mm/protection_keys/* > ==>

Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

On 11/06/2017 12:57 AM, Ram Pai wrote: > Expose useful information for programs using memory protection keys. > Provide implementation for powerpc and x86. > > On a powerpc system with pkeys support, here is what is shown: > > $ head /sys/kernel/mm/protection_keys/* > ==>

[PATCH] mm: don't use the same value for MAP_FIXED_SAFE and MAP_SYNC

Cc: Michal Hocko Fixes: ("fs, elf: drop MAP_FIXED usage from elf_map") Signed-off-by: Andrei Vagin --- include/uapi/asm-generic/mman-common.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/uapi/asm-generic/mman-common.h

[PATCH] mm: don't use the same value for MAP_FIXED_SAFE and MAP_SYNC

Cc: Michal Hocko Fixes: ("fs, elf: drop MAP_FIXED usage from elf_map") Signed-off-by: Andrei Vagin --- include/uapi/asm-generic/mman-common.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h

Re: [PATCH] scripts/spelling.txt: add more spelling mistakes to spelling.txt

On Mon, 2017-12-18 at 10:10 -0800, Randy Dunlap wrote: > On 12/18/2017 06:19 AM, Colin King wrote: > > Here are some of the more spelling mistakes and typos that I've found > > while fixing up spelling mistakes in kernel error message text since > > October 2017 [] > > diff --git

Re: [PATCH] scripts/spelling.txt: add more spelling mistakes to spelling.txt

On Mon, 2017-12-18 at 10:10 -0800, Randy Dunlap wrote: > On 12/18/2017 06:19 AM, Colin King wrote: > > Here are some of the more spelling mistakes and typos that I've found > > while fixing up spelling mistakes in kernel error message text since > > October 2017 [] > > diff --git

Re: [PATCH] USB: serial: option: adding support for YUGA CLM920-NC5

Johan Hovold writes: >> +static const struct option_blacklist_info yuga_clm920_nc5_blacklist = { >> +.reserved = BIT(0) | BIT(1) | BIT(4), >> +}; > > Do you really need to blacklist the first interface? Good question. Interface #0 does look a lot like a Qualcomm DM/DIAG

Re: [PATCH] USB: serial: option: adding support for YUGA CLM920-NC5

Johan Hovold writes: >> +static const struct option_blacklist_info yuga_clm920_nc5_blacklist = { >> +.reserved = BIT(0) | BIT(1) | BIT(4), >> +}; > > Do you really need to blacklist the first interface? Good question. Interface #0 does look a lot like a Qualcomm DM/DIAG function, based on

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Mon, Dec 18, 2017 at 3:54 AM, Peter Zijlstra wrote: > On Fri, Dec 15, 2017 at 08:38:02AM -0800, Dan Williams wrote: > >> The motivation was that I noticed that get_user_pages_fast() was doing >> a full pud_access_permitted() check, but the get_user_pages() slow >> path

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Mon, Dec 18, 2017 at 3:54 AM, Peter Zijlstra wrote: > On Fri, Dec 15, 2017 at 08:38:02AM -0800, Dan Williams wrote: > >> The motivation was that I noticed that get_user_pages_fast() was doing >> a full pud_access_permitted() check, but the get_user_pages() slow >> path was only doing a

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

On Mon, 2017-12-18 at 17:56 +, Bart Van Assche wrote: > On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote: > > On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote: > > > > > > Today when we run checkers we get so many warnings it is too hard to > > > > make any sense of it. > >

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

On Mon, 2017-12-18 at 17:56 +, Bart Van Assche wrote: > On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote: > > On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote: > > > > > > Today when we run checkers we get so many warnings it is too hard to > > > > make any sense of it. > >

[PATCH v2 8/9] dt-bindings: PCI: cadence: Add DT bindings for Cadence PCIe endpoint controller

This patch documents the DT bindings for the Cadence PCIe controller when configured in endpoint mode. Signed-off-by: Cyrille Pitchen --- .../devicetree/bindings/pci/cdns,cdns-pcie-ep.txt | 23 ++ 1 file changed, 23 insertions(+) create

[PATCH 3.18 10/69] KEYS: Dont permit request_key() to construct a new keyring

3.18-stable review patch. If anyone has any objections, please let me know. -- From: David Howells commit 911b79cde95c7da0ec02f48105358a36636b7a71 upstream. If request_key() is used to find a keyring, only do the search part - don't do the construction

[PATCH v2 8/9] dt-bindings: PCI: cadence: Add DT bindings for Cadence PCIe endpoint controller

This patch documents the DT bindings for the Cadence PCIe controller when configured in endpoint mode. Signed-off-by: Cyrille Pitchen --- .../devicetree/bindings/pci/cdns,cdns-pcie-ep.txt | 23 ++ 1 file changed, 23 insertions(+) create mode 100644

[PATCH 3.18 10/69] KEYS: Dont permit request_key() to construct a new keyring

3.18-stable review patch. If anyone has any objections, please let me know. -- From: David Howells commit 911b79cde95c7da0ec02f48105358a36636b7a71 upstream. If request_key() is used to find a keyring, only do the search part - don't do the construction part if the keyring was

[PATCH 3.18 14/69] net: bcmgenet: correct MIB access of UniMAC RUNT counters

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Doug Berger [ Upstream commit 1ad3d225e5a40ca6c586989b4baaca710544c15a ] The gap between the Tx status counters and the Rx RUNT counters is now being added to allow

[PATCH 3.18 14/69] net: bcmgenet: correct MIB access of UniMAC RUNT counters

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Doug Berger [ Upstream commit 1ad3d225e5a40ca6c586989b4baaca710544c15a ] The gap between the Tx status counters and the Rx RUNT counters is now being added to allow correct reporting of the

[PATCH 3.18 13/69] net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Doug Berger [ Upstream commit 71328a3c321f7c14cc1edd33577717037744 ] The location of the RBUF overflow and error counters has moved between different version of the

[PATCH 3.18 13/69] net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Doug Berger [ Upstream commit 71328a3c321f7c14cc1edd33577717037744 ] The location of the RBUF overflow and error counters has moved between different version of the GENET MAC. This

[PATCH 3.18 17/69] NFSD: fix nfsd_reset_versions for NFSv4.

3.18-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown [ Upstream commit 800a938f0bf9130c8256116649c0cc5806bfb2fd ] If you write "-2 -3 -4" to the "versions" file, it will notice that no versions are enabled, and

[PATCH 3.18 15/69] net: bcmgenet: Power up the internal PHY before probing the MII

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Doug Berger [ Upstream commit 6be371b053dc86f11465cc1abce2e99bda0a0574 ] When using the internal PHY it must be powered up when the MII is probed or the PHY will not be

[PATCH 3.18 17/69] NFSD: fix nfsd_reset_versions for NFSv4.

3.18-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown [ Upstream commit 800a938f0bf9130c8256116649c0cc5806bfb2fd ] If you write "-2 -3 -4" to the "versions" file, it will notice that no versions are enabled, and nfsd_reset_versions()

[PATCH 3.18 15/69] net: bcmgenet: Power up the internal PHY before probing the MII

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Doug Berger [ Upstream commit 6be371b053dc86f11465cc1abce2e99bda0a0574 ] When using the internal PHY it must be powered up when the MII is probed or the PHY will not be detected. Since the

[PATCH 3.18 18/69] Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Dmitry Torokhov [ Upstream commit a4c2a13129f7c5bcf81704c06851601593303fd5 ] TUXEDO BU1406 does not implement active multiplexing mode properly, and takes around

[PATCH 3.18 18/69] Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Dmitry Torokhov [ Upstream commit a4c2a13129f7c5bcf81704c06851601593303fd5 ] TUXEDO BU1406 does not implement active multiplexing mode properly, and takes around 550 ms in

[PATCH 3.18 19/69] net: wimax/i2400m: fix NULL-deref at probe

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Johan Hovold [ Upstream commit 6e526fdff7be4f13b24f929a04c0e9ae6761291e ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing

[PATCH 3.18 19/69] net: wimax/i2400m: fix NULL-deref at probe

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Johan Hovold [ Upstream commit 6e526fdff7be4f13b24f929a04c0e9ae6761291e ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the

[PATCH 3.18 03/69] autofs: fix careless error in recent commit

3.18-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit 302ec300ef8a545a7fc7f667e5fd743b091c2eeb upstream. Commit ecc0c469f277 ("autofs: don't fail mount for transient error") was meant to replace an 'if' with a

[PATCH 3.18 03/69] autofs: fix careless error in recent commit

3.18-stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit 302ec300ef8a545a7fc7f667e5fd743b091c2eeb upstream. Commit ecc0c469f277 ("autofs: don't fail mount for transient error") was meant to replace an 'if' with a 'switch', but

[PATCH 3.18 04/69] USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID

3.18-stable review patch. If anyone has any objections, please let me know. -- From: David Kozub commit 62354454625741f0569c2cbe45b2d192f8fd258e upstream. There is another JMS567-based USB3 UAS enclosure (152d:0578) that fails with the following

[PATCH 3.18 06/69] usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Shuah Khan commit be6123df1ea8f01ee2f896a16c2b7be3e4557a5a upstream. stub_send_ret_submit() handles urb with a potential null transfer_buffer, when it replays a

Re: NFS: 82ms wakeup latency 4.14-rc4

On Mon, 2017-12-18 at 12:27 -0500, J. Bruce Fields wrote: > I'd forgotten about throughput/latency tradeoffs--but > couldn't those in theory be managed by runtime configuration of the > sceduler, or at least some smaller hammer than turning off preemption > entirely? A kernel that has all of the

[PATCH 3.18 04/69] USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID

3.18-stable review patch. If anyone has any objections, please let me know. -- From: David Kozub commit 62354454625741f0569c2cbe45b2d192f8fd258e upstream. There is another JMS567-based USB3 UAS enclosure (152d:0578) that fails with the following error: [sda] tag#0 FAILED

[PATCH 3.18 06/69] usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Shuah Khan commit be6123df1ea8f01ee2f896a16c2b7be3e4557a5a upstream. stub_send_ret_submit() handles urb with a potential null transfer_buffer, when it replays a packet with potential

Re: NFS: 82ms wakeup latency 4.14-rc4

On Mon, 2017-12-18 at 12:27 -0500, J. Bruce Fields wrote: > I'd forgotten about throughput/latency tradeoffs--but > couldn't those in theory be managed by runtime configuration of the > sceduler, or at least some smaller hammer than turning off preemption > entirely? A kernel that has all of the

[PATCH 3.18 07/69] xhci: Dont add a virt_dev to the devs array before its fully allocated

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Mathias Nyman commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 upstream. Avoid null pointer dereference if some function is walking through the devs array

[PATCH 3.18 07/69] xhci: Dont add a virt_dev to the devs array before its fully allocated

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Mathias Nyman commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 upstream. Avoid null pointer dereference if some function is walking through the devs array accessing members of a new virt_dev

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

Hi Ard 2017-12-18 10:40 GMT+01:00 Ard Biesheuvel : > On 18 December 2017 at 10:17, Marcin Wojtas wrote: >> Hi, >> >> This patchset introduces ACPI support in mvpp2 and mvmdio drivers. >> First three patches introduce fwnode helpers for obtaining PHY

[GIT PULL] parisc architecture fixes for 4.15-rc5

Hi Linus, please pull a few important fixes for the parisc architecture from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.15-2 There are two important fixes: - Add PCI quirks to disable built-in a serial AUX and a graphics cards from specific GSP

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

Hi Ard 2017-12-18 10:40 GMT+01:00 Ard Biesheuvel : > On 18 December 2017 at 10:17, Marcin Wojtas wrote: >> Hi, >> >> This patchset introduces ACPI support in mvpp2 and mvmdio drivers. >> First three patches introduce fwnode helpers for obtaining PHY >> information from nodes and also MDIO fwnode

[GIT PULL] parisc architecture fixes for 4.15-rc5

Hi Linus, please pull a few important fixes for the parisc architecture from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.15-2 There are two important fixes: - Add PCI quirks to disable built-in a serial AUX and a graphics cards from specific GSP

[PATCH v2 1/9] PCI: Regroup all PCI related entries into drivers/pci/Makefile

This patch cleans drivers/Makefile up by moving the pci/endpoint and pci/dwc entries from drivers/Makefile into drivers/pci/Makefile. Since we don't want to introduce any dependency between CONFIG_PCI and CONFIG_PCI_ENDPOINT, we now always execute drivers/pci/Makefile. Hence all Makefiles in

[PATCH v2 1/9] PCI: Regroup all PCI related entries into drivers/pci/Makefile

This patch cleans drivers/Makefile up by moving the pci/endpoint and pci/dwc entries from drivers/Makefile into drivers/pci/Makefile. Since we don't want to introduce any dependency between CONFIG_PCI and CONFIG_PCI_ENDPOINT, we now always execute drivers/pci/Makefile. Hence all Makefiles in

[PATCH 3.18 21/69] net: Resend IGMP memberships upon peer notification.

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Vlad Yasevich [ Upstream commit 37c343b4f4e70e9dc328ab04903c0ec8d154c1a4 ] When we notify peers of potential changes, it's also good to update IGMP memberships. For

[PATCH 3.18 08/69] ext4: fix crash when a directorys i_size is too small

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Chandan Rajendra commit 9d5afec6b8bd46d6ed821aa1579634437f58ef1f upstream. On a ppc64 machine, when mounting a fuzzed ext2 image (generated by fsfuzzer) the

[PATCH 3.18 21/69] net: Resend IGMP memberships upon peer notification.

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Vlad Yasevich [ Upstream commit 37c343b4f4e70e9dc328ab04903c0ec8d154c1a4 ] When we notify peers of potential changes, it's also good to update IGMP memberships. For example, during VM

[PATCH 3.18 08/69] ext4: fix crash when a directorys i_size is too small

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Chandan Rajendra commit 9d5afec6b8bd46d6ed821aa1579634437f58ef1f upstream. On a ppc64 machine, when mounting a fuzzed ext2 image (generated by fsfuzzer) the following call trace is seen,

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