Re: linux-next: build failure after merge of the akpm-current tree

On Wed, Jun 14, 2017 at 7:12 PM, Daniel Micay wrote: > On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote: >> Hi Daniel, >> >> On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay > > wrote: >> > >> > They're false positive warnings. I think

Re: linux-next: build failure after merge of the akpm-current tree

On Wed, Jun 14, 2017 at 7:12 PM, Daniel Micay wrote: > On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote: >> Hi Daniel, >> >> On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay > > wrote: >> > >> > They're false positive warnings. I think objtool has a list of >> > __noreturn functions and

[PATCH] objtool: Add fortify_panic as __noreturn function

CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function, so objtool needs to know about it too. Suggested-by: Daniel Micay Signed-off-by: Kees Cook Cc: Josh Poimboeuf --- tools/objtool/builtin-check.c | 3 ++-

[PATCH] objtool: Add fortify_panic as __noreturn function

CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function, so objtool needs to know about it too. Suggested-by: Daniel Micay Signed-off-by: Kees Cook Cc: Josh Poimboeuf --- tools/objtool/builtin-check.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: linux-next: build failure after merge of the akpm-current tree

On Wed, Jun 14, 2017 at 7:06 PM, Stephen Rothwell wrote: > Hi Kees, > > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook wrote: >> >> I sent a series for -mm (or maintainers) to merge that should catch >> everything. Do you want me to carry it in my kspp

Re: linux-next: build failure after merge of the akpm-current tree

On Wed, Jun 14, 2017 at 7:06 PM, Stephen Rothwell wrote: > Hi Kees, > > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook wrote: >> >> I sent a series for -mm (or maintainers) to merge that should catch >> everything. Do you want me to carry it in my kspp tree instead? (My >> original intention was

Re: [PATCH 3/4] watchdog: Split up config options

Hi Don, On 6/14/2017 9:09 AM, Don Zickus wrote: On Wed, Jun 14, 2017 at 02:11:18AM +1000, Nicholas Piggin wrote: Yeah, if you wouldn't mind. Sorry for dragging this out, but I feel like we are getting close to have this defined properly which would allow us to split the code up correctly in

Re: [PATCH 3/4] watchdog: Split up config options

Hi Don, On 6/14/2017 9:09 AM, Don Zickus wrote: On Wed, Jun 14, 2017 at 02:11:18AM +1000, Nicholas Piggin wrote: Yeah, if you wouldn't mind. Sorry for dragging this out, but I feel like we are getting close to have this defined properly which would allow us to split the code up correctly in

Re: linux-next: build failure after merge of the akpm-current tree

On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote: > Hi Daniel, > > On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay > wrote: > > > > They're false positive warnings. I think objtool has a list of > > __noreturn functions and needs fortify_panic added there. It's

Re: linux-next: build failure after merge of the akpm-current tree

On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote: > Hi Daniel, > > On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay > wrote: > > > > They're false positive warnings. I think objtool has a list of > > __noreturn functions and needs fortify_panic added there. It's just > > a > > warning

Re: Qemu crashes in -next due to 'of: remove *phandle properties from expanded device tree'

On Wed, Jun 14, 2017 at 05:45:52PM -0700, Frank Rowand wrote: > On 06/14/17 15:35, Guenter Roeck wrote: > > On Wed, Jun 14, 2017 at 02:31:58PM -0700, Frank Rowand wrote: > >> Hi Guenter, > > < snip > > > >> Can you also include the console messages before the "[ cut here ]" line? > >> > >

Re: Qemu crashes in -next due to 'of: remove *phandle properties from expanded device tree'

On Wed, Jun 14, 2017 at 05:45:52PM -0700, Frank Rowand wrote: > On 06/14/17 15:35, Guenter Roeck wrote: > > On Wed, Jun 14, 2017 at 02:31:58PM -0700, Frank Rowand wrote: > >> Hi Guenter, > > < snip > > > >> Can you also include the console messages before the "[ cut here ]" line? > >> > >

Re: [HMM-CDM 5/5] mm/hmm: simplify kconfig and enable HMM and DEVICE_PUBLIC for ppc64

On Wed, Jun 14, 2017 at 04:10:32PM -0700, John Hubbard wrote: > On 06/14/2017 01:11 PM, Jérôme Glisse wrote: > > This just simplify kconfig and allow HMM and DEVICE_PUBLIC to be > > selected for ppc64 once ZONE_DEVICE is allowed on ppc64 (different > > patchset). > > > > Signed-off-by: Jérôme

Re: [HMM-CDM 5/5] mm/hmm: simplify kconfig and enable HMM and DEVICE_PUBLIC for ppc64

On Wed, Jun 14, 2017 at 04:10:32PM -0700, John Hubbard wrote: > On 06/14/2017 01:11 PM, Jérôme Glisse wrote: > > This just simplify kconfig and allow HMM and DEVICE_PUBLIC to be > > selected for ppc64 once ZONE_DEVICE is allowed on ppc64 (different > > patchset). > > > > Signed-off-by: Jérôme

Re: [HMM-CDM 5/5] mm/hmm: simplify kconfig and enable HMM and DEVICE_PUBLIC for ppc64

On Thu, Jun 15, 2017 at 11:46:11AM +1000, Balbir Singh wrote: > On Wed, 14 Jun 2017 16:11:44 -0400 > Jérôme Glisse wrote: > > > This just simplify kconfig and allow HMM and DEVICE_PUBLIC to be > > selected for ppc64 once ZONE_DEVICE is allowed on ppc64 (different > >

Re: [HMM-CDM 5/5] mm/hmm: simplify kconfig and enable HMM and DEVICE_PUBLIC for ppc64

On Thu, Jun 15, 2017 at 11:46:11AM +1000, Balbir Singh wrote: > On Wed, 14 Jun 2017 16:11:44 -0400 > Jérôme Glisse wrote: > > > This just simplify kconfig and allow HMM and DEVICE_PUBLIC to be > > selected for ppc64 once ZONE_DEVICE is allowed on ppc64 (different > > patchset). > > > >

Re: linux-next: build failure after merge of the akpm-current tree

Hi Kees, On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook wrote: > > I sent a series for -mm (or maintainers) to merge that should catch > everything. Do you want me to carry it in my kspp tree instead? (My > original intention was to carry all the fixes and the fortify patch

Re: linux-next: build failure after merge of the akpm-current tree

Hi Kees, On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook wrote: > > I sent a series for -mm (or maintainers) to merge that should catch > everything. Do you want me to carry it in my kspp tree instead? (My > original intention was to carry all the fixes and the fortify patch in > kspp but akpm took

Re: [HMM-CDM 4/5] mm/memcontrol: support MEMORY_DEVICE_PRIVATE and MEMORY_DEVICE_PUBLIC

On Thu, Jun 15, 2017 at 11:41:59AM +1000, Balbir Singh wrote: > On Wed, 14 Jun 2017 16:11:43 -0400 > Jérôme Glisse wrote: > > > HMM pages (private or public device pages) are ZONE_DEVICE page and > > thus need special handling when it comes to lru or refcount. This > > patch

Re: [HMM-CDM 4/5] mm/memcontrol: support MEMORY_DEVICE_PRIVATE and MEMORY_DEVICE_PUBLIC

On Thu, Jun 15, 2017 at 11:41:59AM +1000, Balbir Singh wrote: > On Wed, 14 Jun 2017 16:11:43 -0400 > Jérôme Glisse wrote: > > > HMM pages (private or public device pages) are ZONE_DEVICE page and > > thus need special handling when it comes to lru or refcount. This > > patch make sure that

Re: linux-next: build failure after merge of the akpm-current tree

Hi Daniel, On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay wrote: > > They're false positive warnings. I think objtool has a list of > __noreturn functions and needs fortify_panic added there. It's just a > warning so it doesn't need to happen immediately. There are

Re: linux-next: build failure after merge of the akpm-current tree

Hi Daniel, On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay wrote: > > They're false positive warnings. I think objtool has a list of > __noreturn functions and needs fortify_panic added there. It's just a > warning so it doesn't need to happen immediately. There are *lots* of them, so it does

Re: [Question or BUG] [NUMA]: I feel puzzled at the function cpumask_of_node

On 2017/6/8 22:12, Michal Hocko wrote: > [CC linux-api] > > On Wed 07-06-17 17:23:20, Leizhen (ThunderTown) wrote: >> When I executed numactl -H(print cpumask_of_node for each node), I got >> different result on X86 and ARM64. For each numa node, the former >> only displayed online CPUs, and

Re: [Question or BUG] [NUMA]: I feel puzzled at the function cpumask_of_node

On 2017/6/8 22:12, Michal Hocko wrote: > [CC linux-api] > > On Wed 07-06-17 17:23:20, Leizhen (ThunderTown) wrote: >> When I executed numactl -H(print cpumask_of_node for each node), I got >> different result on X86 and ARM64. For each numa node, the former >> only displayed online CPUs, and

Re: linux-next: build failure after merge of the akpm-current tree

On Wed, 2017-06-14 at 18:56 -0700, Kees Cook wrote: > On Wed, Jun 14, 2017 at 6:35 PM, Stephen Rothwell u> wrote: > > Hi all, > > > > On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell > g.au> wrote: > > > > > > After merging the akpm-current tree,

Re: linux-next: build failure after merge of the akpm-current tree

On Wed, 2017-06-14 at 18:56 -0700, Kees Cook wrote: > On Wed, Jun 14, 2017 at 6:35 PM, Stephen Rothwell u> wrote: > > Hi all, > > > > On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell > g.au> wrote: > > > > > > After merging the akpm-current tree, today's linux-next build > > > (x86_64 > > >

Re: linux-next: build failure after merge of the akpm-current tree

On Wed, Jun 14, 2017 at 6:35 PM, Stephen Rothwell wrote: > Hi all, > > On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell > wrote: >> >> After merging the akpm-current tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >>

Re: linux-next: build failure after merge of the akpm-current tree

On Wed, Jun 14, 2017 at 6:35 PM, Stephen Rothwell wrote: > Hi all, > > On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell > wrote: >> >> After merging the akpm-current tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >> sound/pcmcia/pdaudiocf/pdaudiocf.o: warning:

Re: [PATCH] fs/fcntl: return -ESRCH in f_setown when pid/pgid can't be found

yes, look good to me. but I found the another issue. if the pass argument is -1. by the spec describe, type should be assigned to PIDTYPE_MAX, Do you think that it deserve another patch ? Thanks zhongjiang On 2017/6/14 22:52, Jeff Layton wrote: > The current implementation of F_SETOWN

Re: [PATCH] fs/fcntl: return -ESRCH in f_setown when pid/pgid can't be found

yes, look good to me. but I found the another issue. if the pass argument is -1. by the spec describe, type should be assigned to PIDTYPE_MAX, Do you think that it deserve another patch ? Thanks zhongjiang On 2017/6/14 22:52, Jeff Layton wrote: > The current implementation of F_SETOWN

Re: Updated docs

Thanks for the update. I have 2 more things for you to consider. a. In multiple places, there is something like "return 0 when no error and return a negative error code otherwise." I would say "or return a negative error code otherwise." b. (below) > === > FILESYSTEM

Re: Updated docs

Thanks for the update. I have 2 more things for you to consider. a. In multiple places, there is something like "return 0 when no error and return a negative error code otherwise." I would say "or return a negative error code otherwise." b. (below) > === > FILESYSTEM

Re: [HMM-CDM 5/5] mm/hmm: simplify kconfig and enable HMM and DEVICE_PUBLIC for ppc64

On Wed, 14 Jun 2017 16:11:44 -0400 Jérôme Glisse wrote: > This just simplify kconfig and allow HMM and DEVICE_PUBLIC to be > selected for ppc64 once ZONE_DEVICE is allowed on ppc64 (different > patchset). > > Signed-off-by: Jérôme Glisse > Signed-off-by:

Re: [HMM-CDM 5/5] mm/hmm: simplify kconfig and enable HMM and DEVICE_PUBLIC for ppc64

On Wed, 14 Jun 2017 16:11:44 -0400 Jérôme Glisse wrote: > This just simplify kconfig and allow HMM and DEVICE_PUBLIC to be > selected for ppc64 once ZONE_DEVICE is allowed on ppc64 (different > patchset). > > Signed-off-by: Jérôme Glisse > Signed-off-by: John Hubbard > Cc: Balbir Singh > Cc:

Re: [HMM-CDM 4/5] mm/memcontrol: support MEMORY_DEVICE_PRIVATE and MEMORY_DEVICE_PUBLIC

On Wed, 14 Jun 2017 16:11:43 -0400 Jérôme Glisse wrote: > HMM pages (private or public device pages) are ZONE_DEVICE page and > thus need special handling when it comes to lru or refcount. This > patch make sure that memcontrol properly handle those when it face > them. Those

Re: [HMM-CDM 4/5] mm/memcontrol: support MEMORY_DEVICE_PRIVATE and MEMORY_DEVICE_PUBLIC

On Wed, 14 Jun 2017 16:11:43 -0400 Jérôme Glisse wrote: > HMM pages (private or public device pages) are ZONE_DEVICE page and > thus need special handling when it comes to lru or refcount. This > patch make sure that memcontrol properly handle those when it face > them. Those pages are use like

Re: [PATCH v3 05/14] dm: add ->flush() dax operation support

On Fri, 2017-06-09 at 13:24 -0700, Dan Williams wrote: > Allow device-mapper to route flush operations to the > per-target implementation. In order for the device stacking to work > we need a dax_dev and a pgoff relative to that device. This gives > each layer of the stack the information it needs

Re: [PATCH v3 05/14] dm: add ->flush() dax operation support

On Fri, 2017-06-09 at 13:24 -0700, Dan Williams wrote: > Allow device-mapper to route flush operations to the > per-target implementation. In order for the device stacking to work > we need a dax_dev and a pgoff relative to that device. This gives > each layer of the stack the information it needs

[PATCH v3 2/4] ACPI / EC: Add support to skip boot stage DSDT probe

We prepared _INI/_STA methods for \_SB, \_SB.PCI0, \_SB.LID0 and \_SB.EC, _HID(PNP0C09)/_CRS/_GPE for \_SB.EC to poke Windows behavior with qemu, we got the following execution sequence: \_SB._INI \_SB.PCI0._STA \_SB.LID0._STA \_SB.EC._STA \_SB.PCI0._INI \_SB.LID0._INI \_SB.EC._INI There is

[PATCH v3 2/4] ACPI / EC: Add support to skip boot stage DSDT probe

We prepared _INI/_STA methods for \_SB, \_SB.PCI0, \_SB.LID0 and \_SB.EC, _HID(PNP0C09)/_CRS/_GPE for \_SB.EC to poke Windows behavior with qemu, we got the following execution sequence: \_SB._INI \_SB.PCI0._STA \_SB.LID0._STA \_SB.EC._STA \_SB.PCI0._INI \_SB.LID0._INI \_SB.EC._INI There is

[PATCH v3 3/4] ACPI / EC: Fix media keys not working problem on some Asus laptops

From: Chris Chiu Some Asus laptops (verified on X550VXK/FX502VD/FX502VE) get no interrupts when pressing media keys thus the corresponding functions are not invoked. It's due to the _GPE defines in DSDT for EC returns differnt value compared to the GPE Number in ECDT.

[PATCH v3 4/4] ACPI / EC: Add quirk for GL720VMK

From: Carlo Caione ASUS GL720VMK is also affected by the EC GPE preference issue. Signed-off-by: Carlo Caione Signed-off-by: Lv Zheng --- drivers/acpi/ec.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH v3 1/4] ACPI / EC: Enhance boot EC sanity check

It's reported that some buggy BIOS tables can contain 2 DSDT ECs, one of them is invalid but acpi_ec_dsdt_probe() fails to pick the valid one. This patch simply enhances sanity checks in ec_parse_device() as a workaround to skip probing wrong namespace ECs. Link:

[PATCH v3 3/4] ACPI / EC: Fix media keys not working problem on some Asus laptops

From: Chris Chiu Some Asus laptops (verified on X550VXK/FX502VD/FX502VE) get no interrupts when pressing media keys thus the corresponding functions are not invoked. It's due to the _GPE defines in DSDT for EC returns differnt value compared to the GPE Number in ECDT. Confirmed with Asus that

[PATCH v3 4/4] ACPI / EC: Add quirk for GL720VMK

From: Carlo Caione ASUS GL720VMK is also affected by the EC GPE preference issue. Signed-off-by: Carlo Caione Signed-off-by: Lv Zheng --- drivers/acpi/ec.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index 2189048..ab04f0c

[PATCH v3 1/4] ACPI / EC: Enhance boot EC sanity check

It's reported that some buggy BIOS tables can contain 2 DSDT ECs, one of them is invalid but acpi_ec_dsdt_probe() fails to pick the valid one. This patch simply enhances sanity checks in ec_parse_device() as a workaround to skip probing wrong namespace ECs. Link:

[PATCH v3 0/4] ACPI / EC: Add quirk modes for boot EC support

It's reported that Asus laptop X580VD/X550VXK/GL720VMK/FX502VD/FX502VE have a BIOS bug where the ECDT correctly states that EC events trigger GPE 0x23, but the DSDT _GPE method incorrectly returns GPE 0x33. This patchset fixes this issue. Link:

[PATCH v3 0/4] ACPI / EC: Add quirk modes for boot EC support

It's reported that Asus laptop X580VD/X550VXK/GL720VMK/FX502VD/FX502VE have a BIOS bug where the ECDT correctly states that EC events trigger GPE 0x23, but the DSDT _GPE method incorrectly returns GPE 0x33. This patchset fixes this issue. Link:

Re: linux-next: state of the asm-generic tree

Hi Arnd, On Thu, 8 Jun 2017 10:28:53 +1000 Stephen Rothwell wrote: > > The asm-generic tree > (git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git#master) > hasn't been updated since last September and currently contains 2 commits: > > de4be6b87b6b

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Wednesday 14 June 2017 10:30 PM, Vlastimil Babka wrote: On 06/14/2017 06:55 PM, Will Deacon wrote: May be we should relook at pmd PTE udpate interface. We really need an interface that can update pmd entries such that we don't clear it in between. IMHO, we can avoid the pmdp_invalidate()

Re: linux-next: state of the asm-generic tree

Hi Arnd, On Thu, 8 Jun 2017 10:28:53 +1000 Stephen Rothwell wrote: > > The asm-generic tree > (git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git#master) > hasn't been updated since last September and currently contains 2 commits: > > de4be6b87b6b asm-generic: page.h: fix

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Wednesday 14 June 2017 10:30 PM, Vlastimil Babka wrote: On 06/14/2017 06:55 PM, Will Deacon wrote: May be we should relook at pmd PTE udpate interface. We really need an interface that can update pmd entries such that we don't clear it in between. IMHO, we can avoid the pmdp_invalidate()

Re: [PATCH 1/2] ARM: imx_v6_v7_defconfig: Set THERMAL_WRITABLE_TRIPS=y for testing

On Thu, Jun 08, 2017 at 07:26:57PM +0300, Leonard Crestez wrote: > Setting trip points is supported by the imx thermal driver and it is > useful to be able to test this without adjusting config. > > Signed-off-by: Leonard Crestez Applied, thanks.

Re: [PATCH 1/2] ARM: imx_v6_v7_defconfig: Set THERMAL_WRITABLE_TRIPS=y for testing

On Thu, Jun 08, 2017 at 07:26:57PM +0300, Leonard Crestez wrote: > Setting trip points is supported by the imx thermal driver and it is > useful to be able to test this without adjusting config. > > Signed-off-by: Leonard Crestez Applied, thanks.

Re: linux-next: build failure after merge of the akpm-current tree

Hi all, On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell wrote: > > After merging the akpm-current tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > sound/pcmcia/pdaudiocf/pdaudiocf.o: warning: objtool: .text: unexpected end > of section >

Re: linux-next: build failure after merge of the akpm-current tree

Hi all, On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell wrote: > > After merging the akpm-current tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > sound/pcmcia/pdaudiocf/pdaudiocf.o: warning: objtool: .text: unexpected end > of section >

Re: [PATCH 3/3] x86/xen: Move paravirt IOPL switching to slow the path

On Wed, Jun 14, 2017 at 11:25 AM, Brian Gerst wrote: > On Wed, Jun 14, 2017 at 2:02 PM, Andrew Cooper > wrote: >> On 14/06/17 18:40, Andy Lutomirski wrote: >>> On Wed, Jun 14, 2017 at 5:40 AM, Brian Gerst wrote: Since tasks

Re: [PATCH 3/3] x86/xen: Move paravirt IOPL switching to slow the path

On Wed, Jun 14, 2017 at 11:25 AM, Brian Gerst wrote: > On Wed, Jun 14, 2017 at 2:02 PM, Andrew Cooper > wrote: >> On 14/06/17 18:40, Andy Lutomirski wrote: >>> On Wed, Jun 14, 2017 at 5:40 AM, Brian Gerst wrote: Since tasks using IOPL are very rare, move the switching code to the slow

Re: linux-next: build warning after merge of the i2c tree

Hi Wolfram, On Mon, 5 Jun 2017 11:11:31 +1000 Stephen Rothwell wrote: > > After merging the i2c tree, today's linux-next build (x86_64 allmodconfig) > produced this warning: > > drivers/i2c/i2c-stub.c:18:0: warning: "DEBUG" redefined > #define DEBUG > ^ > :0:0: note:

Re: linux-next: build warning after merge of the i2c tree

Hi Wolfram, On Mon, 5 Jun 2017 11:11:31 +1000 Stephen Rothwell wrote: > > After merging the i2c tree, today's linux-next build (x86_64 allmodconfig) > produced this warning: > > drivers/i2c/i2c-stub.c:18:0: warning: "DEBUG" redefined > #define DEBUG > ^ > :0:0: note: this is the location of

Re: [PATCH v3 02/14] dm: add ->copy_from_iter() dax operation support

On Wed, 2017-06-14 at 18:45 -0600, Toshi Kani wrote: > On Fri, 2017-06-09 at 13:23 -0700, Dan Williams wrote: > > Allow device-mapper to route copy_from_iter operations to the > > per-target implementation. In order for the device stacking to work > > we need a dax_dev and a pgoff relative to that

Re: [PATCH v3 02/14] dm: add ->copy_from_iter() dax operation support

On Wed, 2017-06-14 at 18:45 -0600, Toshi Kani wrote: > On Fri, 2017-06-09 at 13:23 -0700, Dan Williams wrote: > > Allow device-mapper to route copy_from_iter operations to the > > per-target implementation. In order for the device stacking to work > > we need a dax_dev and a pgoff relative to that

[PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

Ensure the address limit is a user-mode segment before returning to user-mode. Otherwise a process can corrupt kernel-mode memory and elevate privileges [1]. The set_fs function sets the TIF_SETFS flag to force a slow path on return. In the slow path, the address limit is checked to be USER_DS if

[PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

Ensure the address limit is a user-mode segment before returning to user-mode. Otherwise a process can corrupt kernel-mode memory and elevate privileges [1]. The set_fs function sets the TIF_SETFS flag to force a slow path on return. In the slow path, the address limit is checked to be USER_DS if

[PATCH v10 3/3] arm64/syscalls: Check address limit on user-mode return

Ensure the address limit is a user-mode segment before returning to user-mode. Otherwise a process can corrupt kernel-mode memory and elevate privileges [1]. The set_fs function sets the TIF_SETFS flag to force a slow path on return. In the slow path, the address limit is checked to be USER_DS if

[PATCH v10 3/3] arm64/syscalls: Check address limit on user-mode return

Ensure the address limit is a user-mode segment before returning to user-mode. Otherwise a process can corrupt kernel-mode memory and elevate privileges [1]. The set_fs function sets the TIF_SETFS flag to force a slow path on return. In the slow path, the address limit is checked to be USER_DS if

[PATCH v10 1/3] x86/syscalls: Check address limit on user-mode return

Ensure the address limit is a user-mode segment before returning to user-mode. Otherwise a process can corrupt kernel-mode memory and elevate privileges [1]. The set_fs function sets the TIF_SETFS flag to force a slow path on return. In the slow path, the address limit is checked to be USER_DS if

Re: Sleeping BUG in khugepaged for i586

On Thu, 8 Jun 2017, Michal Hocko wrote: > collapse_huge_page > pte_offset_map > kmap_atomic > kmap_atomic_prot > preempt_disable > __collapse_huge_page_copy > pte_unmap > kunmap_atomic > __kunmap_atomic > preempt_enable > > I suspect, so cond_resched

[PATCH v10 1/3] x86/syscalls: Check address limit on user-mode return

Ensure the address limit is a user-mode segment before returning to user-mode. Otherwise a process can corrupt kernel-mode memory and elevate privileges [1]. The set_fs function sets the TIF_SETFS flag to force a slow path on return. In the slow path, the address limit is checked to be USER_DS if

Re: Sleeping BUG in khugepaged for i586

On Thu, 8 Jun 2017, Michal Hocko wrote: > collapse_huge_page > pte_offset_map > kmap_atomic > kmap_atomic_prot > preempt_disable > __collapse_huge_page_copy > pte_unmap > kunmap_atomic > __kunmap_atomic > preempt_enable > > I suspect, so cond_resched

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Wednesday 14 June 2017 10:25 PM, Will Deacon wrote: Hi Aneesh, On Wed, Jun 14, 2017 at 08:55:26PM +0530, Aneesh Kumar K.V wrote: On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote: Vlastimil noted that pmdp_invalidate() is not atomic and we can loose dirty and access bits if

Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages

On Wednesday 14 June 2017 10:25 PM, Will Deacon wrote: Hi Aneesh, On Wed, Jun 14, 2017 at 08:55:26PM +0530, Aneesh Kumar K.V wrote: On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote: Vlastimil noted that pmdp_invalidate() is not atomic and we can loose dirty and access bits if

Re: [PATCH] mm, memory_hotplug: support movable_node for hotplugable nodes

On Wed, Jun 14, 2017 at 11:07:31AM +0200, Vlastimil Babka wrote: >On 06/14/2017 11:06 AM, Wei Yang wrote: >> On Mon, Jun 12, 2017 at 08:45:02AM +0200, Michal Hocko wrote: >>> On Mon 12-06-17 12:28:32, Wei Yang wrote: On Thu, Jun 08, 2017 at 02:23:18PM +0200, Michal Hocko wrote: > From:

Re: [PATCH] mm, memory_hotplug: support movable_node for hotplugable nodes

On Wed, Jun 14, 2017 at 11:07:31AM +0200, Vlastimil Babka wrote: >On 06/14/2017 11:06 AM, Wei Yang wrote: >> On Mon, Jun 12, 2017 at 08:45:02AM +0200, Michal Hocko wrote: >>> On Mon 12-06-17 12:28:32, Wei Yang wrote: On Thu, Jun 08, 2017 at 02:23:18PM +0200, Michal Hocko wrote: > From:

Re: [PATCH 04/14] mm, memory_hotplug: get rid of is_zone_device_section

On Wed, Jun 14, 2017 at 11:24:38AM +0200, Michal Hocko wrote: >On Wed 14-06-17 17:12:06, Wei Yang wrote: >> On Wed, Jun 14, 2017 at 08:32:06AM +0200, Michal Hocko wrote: >> >On Wed 14-06-17 14:12:59, Wei Yang wrote: >> >[...] >> >> Hi, Michal >> >> >> >> Not sure you missed this one or you think

Re: [PATCH 04/14] mm, memory_hotplug: get rid of is_zone_device_section

On Wed, Jun 14, 2017 at 11:24:38AM +0200, Michal Hocko wrote: >On Wed 14-06-17 17:12:06, Wei Yang wrote: >> On Wed, Jun 14, 2017 at 08:32:06AM +0200, Michal Hocko wrote: >> >On Wed 14-06-17 14:12:59, Wei Yang wrote: >> >[...] >> >> Hi, Michal >> >> >> >> Not sure you missed this one or you think

Re: [PATCH] ip6_tunnel: Correct tos value in collect_md mode

> On 14 Jun 2017, at 1:28 PM, Peter Dawson wrote: > > On Wed, 14 Jun 2017 10:54:31 +0800 > 严海双 wrote: > > >>> Changes since v2: >>> * mask key->tos with RT_TOS() suggested by Daniel > > Can you help me understand the rationale for this

Re: [PATCH] ip6_tunnel: Correct tos value in collect_md mode

> On 14 Jun 2017, at 1:28 PM, Peter Dawson wrote: > > On Wed, 14 Jun 2017 10:54:31 +0800 > 严海双 wrote: > > >>> Changes since v2: >>> * mask key->tos with RT_TOS() suggested by Daniel > > Can you help me understand the rationale for this change? Is there are bug > introduced by dsfield =

Bad page state freeing hugepages

dead raw: ea6b0001 00090003 page dumped because: nonzero compound_mapcount Modules linked in: CPU: 1 PID: 25025 Comm: syz-executor1 Not tainted 4.12.0-rc5-next-20170614+ #119 Hardware name: QEMU Standard

Bad page state freeing hugepages

dead raw: ea6b0001 00090003 page dumped because: nonzero compound_mapcount Modules linked in: CPU: 1 PID: 25025 Comm: syz-executor1 Not tainted 4.12.0-rc5-next-20170614+ #119 Hardware name: QEMU Standard

Crypto Fixes for 4.12

Hi Linus: This push fixes a bug on sparc where we may dereference freed stack memory. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus David Miller (1): crypto: Work around deallocated stack frame reference gcc bug on sparc.

Crypto Fixes for 4.12

Hi Linus: This push fixes a bug on sparc where we may dereference freed stack memory. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus David Miller (1): crypto: Work around deallocated stack frame reference gcc bug on sparc.

Re: Using __always_inline attribute

On 2017-06-14 15:33, Sodagudi Prasad wrote: On 2017-06-14 03:06, Will Deacon wrote: Hi Prasad, On Tue, Jun 13, 2017 at 03:39:37PM -0700, Sodagudi Prasad wrote: With a variant of a CLANG(based on 4.0) following errors observed on Linux 4.12-rc5 tag. How are you building the kernel with

Re: Using __always_inline attribute

On 2017-06-14 15:33, Sodagudi Prasad wrote: On 2017-06-14 03:06, Will Deacon wrote: Hi Prasad, On Tue, Jun 13, 2017 at 03:39:37PM -0700, Sodagudi Prasad wrote: With a variant of a CLANG(based on 4.0) following errors observed on Linux 4.12-rc5 tag. How are you building the kernel with

Re: Qemu crashes in -next due to 'of: remove *phandle properties from expanded device tree'

On 06/14/17 15:35, Guenter Roeck wrote: > On Wed, Jun 14, 2017 at 02:31:58PM -0700, Frank Rowand wrote: >> Hi Guenter, < snip > >> Can you also include the console messages before the "[ cut here ]" line? >> > http://kerneltests.org/builders > > Check qemu test results in the 'next' column. ppc

Re: [PATCH v3 02/14] dm: add ->copy_from_iter() dax operation support

On Fri, 2017-06-09 at 13:23 -0700, Dan Williams wrote: > Allow device-mapper to route copy_from_iter operations to the > per-target implementation. In order for the device stacking to work > we > need a dax_dev and a pgoff relative to that device. This gives each > layer of the stack the

Re: Qemu crashes in -next due to 'of: remove *phandle properties from expanded device tree'

On 06/14/17 15:35, Guenter Roeck wrote: > On Wed, Jun 14, 2017 at 02:31:58PM -0700, Frank Rowand wrote: >> Hi Guenter, < snip > >> Can you also include the console messages before the "[ cut here ]" line? >> > http://kerneltests.org/builders > > Check qemu test results in the 'next' column. ppc

Re: [PATCH v3 02/14] dm: add ->copy_from_iter() dax operation support

On Fri, 2017-06-09 at 13:23 -0700, Dan Williams wrote: > Allow device-mapper to route copy_from_iter operations to the > per-target implementation. In order for the device stacking to work > we > need a dax_dev and a pgoff relative to that device. This gives each > layer of the stack the

[GIT PULL] ACPI fixes for v4.12-rc6

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.12-rc6 with top-most commit 9522933454f4c4bd5bedf3d71c538708b7c5de5b Merge branch 'acpica-fixes' on top of commit 32c1431eea4881a6b17bd7c639315010aeefa452 Linux 4.12-rc5 to

[GIT PULL] ACPI fixes for v4.12-rc6

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.12-rc6 with top-most commit 9522933454f4c4bd5bedf3d71c538708b7c5de5b Merge branch 'acpica-fixes' on top of commit 32c1431eea4881a6b17bd7c639315010aeefa452 Linux 4.12-rc5 to

[GIT PULL] Power management fixes for v4.12-rc6

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.12-rc6 with top-most commit f63e4f7d4179c9157c51bbe82af7c8f6b5fb39dd Merge branches 'pm-cpufreq', 'pm-cpuidle' and 'pm-devfreq' on top of commit

[GIT PULL] Power management fixes for v4.12-rc6

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.12-rc6 with top-most commit f63e4f7d4179c9157c51bbe82af7c8f6b5fb39dd Merge branches 'pm-cpufreq', 'pm-cpuidle' and 'pm-devfreq' on top of commit

RE: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")

Hi, Paul, Dmitry, About Laura's test result, it seems like this issue has to do with x_max, y_max, x_res, y_res. This values are set as following code. input_set_abs_params(dev1, ABS_MT_POSITION_X, 0, priv->x_max, 0, 0); input_set_abs_params(dev1, ABS_MT_POSITION_Y, 0,

RE: [REGRESSION] Touchpad failure after e7348396c6d5 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")

Hi, Paul, Dmitry, About Laura's test result, it seems like this issue has to do with x_max, y_max, x_res, y_res. This values are set as following code. input_set_abs_params(dev1, ABS_MT_POSITION_X, 0, priv->x_max, 0, 0); input_set_abs_params(dev1, ABS_MT_POSITION_Y, 0,

[PATCH v3 2/6] Fix unsigned return values being error checked as negative

Functions like read4 and read8 had unsigned return types but callers were checking for those return values being less than 0 for errors. This patch changes those functions to return signed int error values and take a pointer to a size parameter. Also changes several locals to match the function

[PATCH v3 2/6] Fix unsigned return values being error checked as negative

Functions like read4 and read8 had unsigned return types but callers were checking for those return values being less than 0 for errors. This patch changes those functions to return signed int error values and take a pointer to a size parameter. Also changes several locals to match the function

[PATCH v3 6/6] Fix cases where string literals were passed as string format args

Signed-off-by: Michael Sartain --- trace-capture.c | 12 ++-- trace-dialog.c | 4 ++-- trace-filter.c | 10 +- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/trace-capture.c b/trace-capture.c index 1acfe44..4e1392e 100644 ---

[PATCH v3 1/6] Fix bad force_token escape sequence

Signed-off-by: Michael Sartain --- event-parse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/event-parse.c b/event-parse.c index 3217131..61f48c1 100644 --- a/event-parse.c +++ b/event-parse.c @@ -1093,7 +1093,7 @@ static enum event_type

[PATCH v3 6/6] Fix cases where string literals were passed as string format args

Signed-off-by: Michael Sartain --- trace-capture.c | 12 ++-- trace-dialog.c | 4 ++-- trace-filter.c | 10 +- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/trace-capture.c b/trace-capture.c index 1acfe44..4e1392e 100644 --- a/trace-capture.c +++

[PATCH v3 1/6] Fix bad force_token escape sequence

Signed-off-by: Michael Sartain --- event-parse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/event-parse.c b/event-parse.c index 3217131..61f48c1 100644 --- a/event-parse.c +++ b/event-parse.c @@ -1093,7 +1093,7 @@ static enum event_type __read_token(char **tok)

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