[PATCH v2] fs: fix possible Spectre V1 indexing in __close_fd()

_index_nospec() to prevent speculation past the end of current->fdt. Reported-by: Omer Tripp Cc: sta...@vger.kernel.org Signed-off-by: Greg Hackmann --- v2: include Omer Tripp's analysis in commit message, and update my email address fs/file.c | 2 ++ 1 file changed, 2 insertions(+)

[PATCH] fs: fix possible Spectre V1 indexing in __close_fd()

__close_fd() is reachable via the close() syscall with a userspace-controlled fd. Ensure that it can't be used to speculatively access past the end of current->fdt. Reported-by: Omer Tripp Cc: sta...@vger.kernel.org Signed-off-by: Greg Hackmann --- fs/file.c | 2 ++ 1 file changed

[PATCH] fs: fix possible Spectre V1 indexing in __close_fd()

__close_fd() is reachable via the close() syscall with a userspace-controlled fd. Ensure that it can't be used to speculatively access past the end of current->fdt. Reported-by: Omer Tripp Cc: sta...@vger.kernel.org Signed-off-by: Greg Hackmann --- fs/file.c | 2 ++ 1 file changed

[PATCH v2] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

of 4.4.y, and applies to older kernels too. 4.9.y was fixed separately. Kernels 4.12 and later are unaffected, since all the underlying ion_handle infrastructure has been ripped out. Cc: sta...@vger.kernel.org # v4.4- Signed-off-by: Greg Hackmann --- v2: remove Change-Id line from commit m

[PATCH v2] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

of 4.4.y, and applies to older kernels too. 4.9.y was fixed separately. Kernels 4.12 and later are unaffected, since all the underlying ion_handle infrastructure has been ripped out. Cc: sta...@vger.kernel.org # v4.4- Signed-off-by: Greg Hackmann --- v2: remove Change-Id line from commit m

Re: [PATCH] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

On 08/31/2018 01:27 PM, Greg Hackmann wrote: > Change-Id: Ia0542dd8134e81cd5e1412e126545303c766f738 Sorry, please disregard the Change-Id line. This is what I get for forgetting to re-run checkpatch after amending my commit message. :/

Re: [PATCH] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

On 08/31/2018 01:27 PM, Greg Hackmann wrote: > Change-Id: Ia0542dd8134e81cd5e1412e126545303c766f738 Sorry, please disregard the Change-Id line. This is what I get for forgetting to re-run checkpatch after amending my commit message. :/

[PATCH] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

of 4.4.y, and applies to older kernels too. 4.9.y was fixed separately. Kernels 4.12 and later are unaffected, since all the underlying ion_handle infrastructure has been ripped out. Change-Id: Ia0542dd8134e81cd5e1412e126545303c766f738 Cc: sta...@vger.kernel.org # v4.4- Signed-off-by: Greg Ha

[PATCH] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

of 4.4.y, and applies to older kernels too. 4.9.y was fixed separately. Kernels 4.12 and later are unaffected, since all the underlying ion_handle infrastructure has been ripped out. Change-Id: Ia0542dd8134e81cd5e1412e126545303c766f738 Cc: sta...@vger.kernel.org # v4.4- Signed-off-by: Greg Ha

Re: [PATCH] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

On 08/31/2018 01:12 PM, Greg Kroah-Hartman wrote: > On Fri, Aug 31, 2018 at 01:06:27PM -0700, Greg Hackmann wrote: >> The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several >> times while operating on one of the client's ion_handles. This creates >> win

Re: [PATCH] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

On 08/31/2018 01:12 PM, Greg Kroah-Hartman wrote: > On Fri, Aug 31, 2018 at 01:06:27PM -0700, Greg Hackmann wrote: >> The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several >> times while operating on one of the client's ion_handles. This creates >> win

[PATCH] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

of 4.9.y. Kernels 4.12 and later are unaffected, since all the underlying ion_handle infrastructure has been ripped out. Cc: sta...@vger.kernel.org # v4.11- Signed-off-by: Greg Hackmann --- drivers/staging/android/ion/ion-ioctl.c | 12 --- drivers/staging/android/ion/ion.c

[PATCH] staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

of 4.9.y. Kernels 4.12 and later are unaffected, since all the underlying ion_handle infrastructure has been ripped out. Cc: sta...@vger.kernel.org # v4.11- Signed-off-by: Greg Hackmann --- drivers/staging/android/ion/ion-ioctl.c | 12 --- drivers/staging/android/ion/ion.c

[PATCH v2 1/2] arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()

t; KPF_NOPAGE). kpageflags_read() treats the offset as valid, and stable_page_flags() will try to access an address between the user and kernel address ranges. Fixes: c1cc1552616d ("arm64: MMU initialisation") Cc: sta...@vger.kernel.org Signed-off-by: Greg Hackmann --- arch/arm64/mm/

[PATCH v2 1/2] arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()

t; KPF_NOPAGE). kpageflags_read() treats the offset as valid, and stable_page_flags() will try to access an address between the user and kernel address ranges. Fixes: c1cc1552616d ("arm64: MMU initialisation") Cc: sta...@vger.kernel.org Signed-off-by: Greg Hackmann --- arch/arm64/mm/

[PATCH v2 2/2] arm: mm: check for upper PAGE_SHIFT bits in pfn_valid()

kernel.org Signed-off-by: Greg Hackmann --- arch/arm/mm/init.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index 0cc8e04295a4..bee1f2e4ecf3 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -196,7 +196,11 @@ static v

[PATCH v2 2/2] arm: mm: check for upper PAGE_SHIFT bits in pfn_valid()

kernel.org Signed-off-by: Greg Hackmann --- arch/arm/mm/init.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index 0cc8e04295a4..bee1f2e4ecf3 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -196,7 +196,11 @@ static v

Re: [PATCH] arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()

On 08/14/2018 08:29 AM, Will Deacon wrote: > On Tue, Aug 14, 2018 at 08:17:48AM -0700, Greg Hackmann wrote: >> On 08/14/2018 03:40 AM, Will Deacon wrote: >>> Hi Greg, >>> >>> On Mon, Aug 13, 2018 at 12:30:11PM -0700, Greg Hackmann wrote: >>>> ARM6

Re: [PATCH] arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()

On 08/14/2018 08:29 AM, Will Deacon wrote: > On Tue, Aug 14, 2018 at 08:17:48AM -0700, Greg Hackmann wrote: >> On 08/14/2018 03:40 AM, Will Deacon wrote: >>> Hi Greg, >>> >>> On Mon, Aug 13, 2018 at 12:30:11PM -0700, Greg Hackmann wrote: >>>> ARM6

Re: [PATCH] arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()

On 08/14/2018 03:40 AM, Will Deacon wrote: > Hi Greg, > > On Mon, Aug 13, 2018 at 12:30:11PM -0700, Greg Hackmann wrote: >> ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input >> before seeing if the PFN is valid. This leads to false positives when >

Re: [PATCH] arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()

On 08/14/2018 03:40 AM, Will Deacon wrote: > Hi Greg, > > On Mon, Aug 13, 2018 at 12:30:11PM -0700, Greg Hackmann wrote: >> ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input >> before seeing if the PFN is valid. This leads to false positives when >

[PATCH] arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()

t; KPF_NOPAGE). kpageflags_read() treats the offset as valid, and stable_page_flags() will try to access an address between the user and kernel address ranges. Signed-off-by: Greg Hackmann --- arch/arm64/mm/init.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64

[PATCH] arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()

t; KPF_NOPAGE). kpageflags_read() treats the offset as valid, and stable_page_flags() will try to access an address between the user and kernel address ranges. Signed-off-by: Greg Hackmann --- arch/arm64/mm/init.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64

[PATCH] arm64: remove no-op -p linker flag

wards compatibility". Since this flag is a no-op on ARM64, we can safely drop it. Signed-off-by: Greg Hackmann --- arch/arm64/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 45272266dafb..79bd701071de 100644 --- a/

[PATCH] arm64: remove no-op -p linker flag

wards compatibility". Since this flag is a no-op on ARM64, we can safely drop it. Signed-off-by: Greg Hackmann --- arch/arm64/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 45272266dafb..79bd701071de 100644 --- a/

[PATCH] Revert "xhci: plat: Register shutdown for xhci_plat"

the change made the issue go away. This reverts commit b07c12517f2aed0add8ce18146bb426b14099392. Cc: sta...@vger.kernel.org Signed-off-by: Greg Hackmann <ghackm...@google.com> --- drivers/usb/host/xhci-plat.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/xhci-pl

[PATCH] Revert "xhci: plat: Register shutdown for xhci_plat"

the change made the issue go away. This reverts commit b07c12517f2aed0add8ce18146bb426b14099392. Cc: sta...@vger.kernel.org Signed-off-by: Greg Hackmann --- drivers/usb/host/xhci-plat.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci

Re: Linux 4.9.93

eir side to upstream (Greg?), but >> definitely >> useful to isolate actual issues. > > Ah, yeah, if you are taking anything from the Android tree, all bets are > off :) > > Greg Hackmann can probably answer the questions about CFI and these > patches, as he's working on

Re: Linux 4.9.93

a kernel with CFI' for arm64? >> >> From Google work on Android-4.9 >> >> https://android.googlesource.com/kernel/common/+/00a195e7c0752ff5d65c9caadfbcc226270ca232 >> >> I am not sure what is the plan on their side to upstream (Greg?), but >> definitely >> usef

Re: [PATCH] arm/arm64: smccc: Use xN for arm64 register constraints with clang

t;> https://gist.github.com/xairy/ee11682ea86044a45c0291c528cd936f >> >> and another by: >> >> Greg Hackmann <ghackm...@google.com>: >> https://android-review.googlesource.com/c/kernel/common/+/645181 >> >> If you used either as a reference, you may want to credit them wi

Re: [PATCH] arm/arm64: smccc: Use xN for arm64 register constraints with clang

91c528cd936f >> >> and another by: >> >> Greg Hackmann : >> https://android-review.googlesource.com/c/kernel/common/+/645181 >> >> If you used either as a reference, you may want to credit them with a >> `Suggested-by:` in the commit message.

[PATCH v2 net] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

fc15c0 R10: R11: 0207 R12: 00400440 R13: 7ffe14fc16b0 R14: R15: Signed-off-by: Greg Hackmann <ghackm...@google.com> --- v2: expand commit log to clarify that kernel 3.15 and later are impacted net/xfrm/xfrm_ipcomp.

[PATCH v2 net] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

fc15c0 R10: R11: 0207 R12: 00400440 R13: 7ffe14fc16b0 R14: R15: Signed-off-by: Greg Hackmann --- v2: expand commit log to clarify that kernel 3.15 and later are impacted net/xfrm/xfrm_ipcomp.c | 2 +- 1 file changed, 1

Re: [PATCH] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

On 03/07/2018 12:21 PM, Eric Dumazet wrote: > On Wed, 2018-03-07 at 11:24 -0800, Greg Hackmann wrote: >> f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added >> a >> __this_cpu_read() call inside ipcomp_alloc_tfms().  Since this call >> was &g

Re: [PATCH] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

On 03/07/2018 12:21 PM, Eric Dumazet wrote: > On Wed, 2018-03-07 at 11:24 -0800, Greg Hackmann wrote: >> f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added >> a >> __this_cpu_read() call inside ipcomp_alloc_tfms().  Since this call >> was &g

[PATCH] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

org Signed-off-by: Greg Hackmann <ghackm...@google.com> --- net/xfrm/xfrm_ipcomp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/xfrm/xfrm_ipcomp.c b/net/xfrm/xfrm_ipcomp.c index ccfdc7115a83..a00ec715aa46 100644 --- a/net/xfrm/xfrm_ipcomp.c +++ b/net/xfrm/xfrm_ip

[PATCH] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

org Signed-off-by: Greg Hackmann --- net/xfrm/xfrm_ipcomp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/xfrm/xfrm_ipcomp.c b/net/xfrm/xfrm_ipcomp.c index ccfdc7115a83..a00ec715aa46 100644 --- a/net/xfrm/xfrm_ipcomp.c +++ b/net/xfrm/xfrm_ipcomp.c @@ -283,7 +283,7 @@ sta

Re: [PATCH v2] staging: android: ashmem: Fix lockdep issue during llseek

gt;i_rwsem >>> causing a lockdep splat [2] during a syzcaller test, this patch fixes >>> the issue by unlocking the mutex earlier. Functionally that's Ok since >>> we don't need to protect vfs_llseek. >>> >>> [1] https://patchwork.kernel.org/patch/10185031

Re: [PATCH v2] staging: android: ashmem: Fix lockdep issue during llseek

ckdep splat [2] during a syzcaller test, this patch fixes >>> the issue by unlocking the mutex earlier. Functionally that's Ok since >>> we don't need to protect vfs_llseek. >>> >>> [1] https://patchwork.kernel.org/patch/10185031/ >>> [2] https://lkml.or

[PATCH] staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl

From: Viktor Slavkovic A lock-unlock is missing in ASHMEM_SET_SIZE ioctl which can result in a race condition when mmap is called. After the !asma->file check, before setting asma->size, asma->file can be set in mmap. That would result in having different asma->size than the

[PATCH] staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl

From: Viktor Slavkovic A lock-unlock is missing in ASHMEM_SET_SIZE ioctl which can result in a race condition when mmap is called. After the !asma->file check, before setting asma->size, asma->file can be set in mmap. That would result in having different asma->size than the mapped memory size.

[PATCH v2] selftests: vdso_test: support ARM64 targets

ARM64's vDSO exports its gettimeofday() implementation with a different name (__kernel_gettimeofday) and version (LINUX_2.6.39) from other architectures. Add a corresponding special-case to vdso_test. Signed-off-by: Greg Hackmann <ghackm...@google.com> --- Changes since v1: * Moved defin

[PATCH v2] selftests: vdso_test: support ARM64 targets

ARM64's vDSO exports its gettimeofday() implementation with a different name (__kernel_gettimeofday) and version (LINUX_2.6.39) from other architectures. Add a corresponding special-case to vdso_test. Signed-off-by: Greg Hackmann --- Changes since v1: * Moved definitions outside main

[PATCH] selftests: vdso_test: support ARM64 targets

ARM64's vDSO exports its gettimeofday() implementation with a different name (__kernel_gettimeofday) and version (LINUX_2.6.39) from other architectures. Add a corresponding special-case to vdso_test. Signed-off-by: Greg Hackmann <ghackm...@google.com> --- tools/testing/selftest

[PATCH] selftests: vdso_test: support ARM64 targets

ARM64's vDSO exports its gettimeofday() implementation with a different name (__kernel_gettimeofday) and version (LINUX_2.6.39) from other architectures. Add a corresponding special-case to vdso_test. Signed-off-by: Greg Hackmann --- tools/testing/selftests/vDSO/vdso_test.c | 17

Re: [PATCH] selftests: timers: set-timer-lat: Fix hang when testing unsupported alarms

On 09/22/2017 07:41 AM, Shuah Khan wrote: I assume you are good with this fix. I plan to apply it to linux-kselftest fixes today. Please let me know if you have any objections. thanks, -- Shuah AIUI this check was added so set-timer-lat would treat a missing CAP_WAKE_ALARM as a skipped test

Re: [PATCH] selftests: timers: set-timer-lat: Fix hang when testing unsupported alarms

On 09/22/2017 07:41 AM, Shuah Khan wrote: I assume you are good with this fix. I plan to apply it to linux-kselftest fixes today. Please let me know if you have any objections. thanks, -- Shuah AIUI this check was added so set-timer-lat would treat a missing CAP_WAKE_ALARM as a skipped test

Re: [PATCH] selftests: timers: set-timer-lat: fix hang when std out/err are redirected

imer_delete(tm1); I assume you are good with this fix. I plan to apply it to linux-kselftest fixes today. Please let me know if you have any objections. thanks, -- Shuah Thanks for looking into this. Acked-by: Greg Hackmann <ghackm...@google.com>

Re: [PATCH] selftests: timers: set-timer-lat: fix hang when std out/err are redirected

ou are good with this fix. I plan to apply it to linux-kselftest fixes today. Please let me know if you have any objections. thanks, -- Shuah Thanks for looking into this. Acked-by: Greg Hackmann

Re: [tip:timers/core] kselftests: timers: set-timer-lat: Tweak reporting when timer fires early

On 09/20/2017 04:38 PM, Shuah Khan wrote: On 09/20/2017 06:31 AM, Prarit Bhargava wrote: On 09/19/2017 11:36 PM, John Stultz wrote: On Tue, Sep 19, 2017 at 6:02 PM, Shuah Khan <sh...@kernel.org> wrote: Hi Greg, On 08/20/2017 03:56 AM, tip-bot for Greg Hackmann wrote: Com

Re: [tip:timers/core] kselftests: timers: set-timer-lat: Tweak reporting when timer fires early

On 09/20/2017 04:38 PM, Shuah Khan wrote: On 09/20/2017 06:31 AM, Prarit Bhargava wrote: On 09/19/2017 11:36 PM, John Stultz wrote: On Tue, Sep 19, 2017 at 6:02 PM, Shuah Khan wrote: Hi Greg, On 08/20/2017 03:56 AM, tip-bot for Greg Hackmann wrote: Commit-ID

[PATCH 0/2] kselftests: set-timer-lat: test one-shot timers

the console with failure messages. The second patch actually adds the one-shot testcases. Greg Hackmann (2): kselftests: set-timer-lat: tweak reporting when timer fires early kselftests: set-timer-lat: add one-shot timer test cases tools/testing/selftests/timers/set-timer-lat.c | 103

[PATCH 0/2] kselftests: set-timer-lat: test one-shot timers

the console with failure messages. The second patch actually adds the one-shot testcases. Greg Hackmann (2): kselftests: set-timer-lat: tweak reporting when timer fires early kselftests: set-timer-lat: add one-shot timer test cases tools/testing/selftests/timers/set-timer-lat.c | 103

[PATCH 1/2] kselftests: set-timer-lat: tweak reporting when timer fires early

Rather than printing an error inside the alarm signal handler, set a flag that we check later. This keeps the test from spamming the console every time the alarm fires early. It also fixes the test exiting with error code 0 if this was the only test failure. Signed-off-by: Greg Hackmann <gha

[PATCH 1/2] kselftests: set-timer-lat: tweak reporting when timer fires early

Rather than printing an error inside the alarm signal handler, set a flag that we check later. This keeps the test from spamming the console every time the alarm fires early. It also fixes the test exiting with error code 0 if this was the only test failure. Signed-off-by: Greg Hackmann

[PATCH 2/2] kselftests: set-timer-lat: add one-shot timer test cases

seconds and verify that the alarm fired exactly once. Signed-off-by: Greg Hackmann <ghackm...@google.com> --- tools/testing/selftests/timers/set-timer-lat.c | 86 ++ 1 file changed, 73 insertions(+), 13 deletions(-) diff --git a/tools/testing/selftests/timers/set-timer-la

[PATCH 2/2] kselftests: set-timer-lat: add one-shot timer test cases

seconds and verify that the alarm fired exactly once. Signed-off-by: Greg Hackmann --- tools/testing/selftests/timers/set-timer-lat.c | 86 ++ 1 file changed, 73 insertions(+), 13 deletions(-) diff --git a/tools/testing/selftests/timers/set-timer-lat.c b/tools/testing

[PATCH] alarmtimer: don't rate limit one-shot timers

.y. Older -stable trees have a slightly different patch, and 4.13-rc2 isn't impacted due to a later refactoring. Fixes: ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals") Reported-by: Ben Fennema <fenn...@google.com> Signed-off-by: Greg Hackmann <ghackm...@google.co

[PATCH] alarmtimer: don't rate limit one-shot timers

.y. Older -stable trees have a slightly different patch, and 4.13-rc2 isn't impacted due to a later refactoring. Fixes: ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals") Reported-by: Ben Fennema Signed-off-by: Greg Hackmann Cc: sta...@vger.kernel.org --- kernel/time/alarmti

Re: [PATCH] alarmtimer: don't rate limit one-shot timers

On 07/24/2017 11:21 AM, Greg KH wrote: On Mon, Jul 24, 2017 at 10:19:24AM -0700, Greg Hackmann wrote: Commit ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals") sets a minimum bound on the alarm timer interval. This minimum bound shouldn't be applied if the interval is 0.

Re: [PATCH] alarmtimer: don't rate limit one-shot timers

On 07/24/2017 11:21 AM, Greg KH wrote: On Mon, Jul 24, 2017 at 10:19:24AM -0700, Greg Hackmann wrote: Commit ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals") sets a minimum bound on the alarm timer interval. This minimum bound shouldn't be applied if the interval is 0.

[PATCH] alarmtimer: don't rate limit one-shot timers

nly needed in -stable trees. 4.13-rc2 isn't impacted due to a later refactoring. Fixes: ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals") Reported-by: Ben Fennema <fenn...@google.com> Signed-off-by: Greg Hackmann <ghackm...@google.com> Cc: sta...@vger.kernel.org --- ker

[PATCH] alarmtimer: don't rate limit one-shot timers

nly needed in -stable trees. 4.13-rc2 isn't impacted due to a later refactoring. Fixes: ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals") Reported-by: Ben Fennema Signed-off-by: Greg Hackmann Cc: sta...@vger.kernel.org --- kernel/time/alarmtimer.c | 3 ++- 1 file changed, 2 inser

Re: [PATCH 1/4] kasan: support alloca() poisoning

On 07/10/2017 03:30 AM, Andrey Ryabinin wrote: gcc now supports this too. So I think this patch should enable it. It's off by default so you'll have to add --param asan-instrument-allocas=1 into cflags to make it work Thanks, will fix. For now, it looks like I'll need to build gcc from git

Re: [PATCH 1/4] kasan: support alloca() poisoning

On 07/10/2017 03:30 AM, Andrey Ryabinin wrote: gcc now supports this too. So I think this patch should enable it. It's off by default so you'll have to add --param asan-instrument-allocas=1 into cflags to make it work Thanks, will fix. For now, it looks like I'll need to build gcc from git

Re: [PATCH 1/4] kasan: support alloca() poisoning

Hi, Thanks for taking a look at this patchstack. I apologize for the delay in responding. On 07/10/2017 01:44 AM, Dmitry Vyukov wrote: + + const void *left_redzone = (const void *)(addr - + KASAN_ALLOCA_REDZONE_SIZE); + const void *right_redzone = (const

Re: [PATCH 1/4] kasan: support alloca() poisoning

Hi, Thanks for taking a look at this patchstack. I apologize for the delay in responding. On 07/10/2017 01:44 AM, Dmitry Vyukov wrote: + + const void *left_redzone = (const void *)(addr - + KASAN_ALLOCA_REDZONE_SIZE); + const void *right_redzone = (const

Re: [PATCH 1/4] kasan: support alloca() poisoning

On 07/06/2017 03:01 PM, Greg Hackmann wrote: @@ -101,6 +101,9 @@ static const char *get_shadow_bug_type(struct kasan_access_info *info) break; case KASAN_USE_AFTER_SCOPE: bug_type = "use-after-scope"; + case KASAN_ALLOCA_LEFT: +

Re: [PATCH 1/4] kasan: support alloca() poisoning

On 07/06/2017 03:01 PM, Greg Hackmann wrote: @@ -101,6 +101,9 @@ static const char *get_shadow_bug_type(struct kasan_access_info *info) break; case KASAN_USE_AFTER_SCOPE: bug_type = "use-after-scope"; + case KASAN_ALLOCA_LEFT: +

[PATCH 4/4] kasan: add compiler support for clang

For now we can hard-code ASAN ABI level 5, since historical clang builds can't build the kernel anyway. We also need to emulate gcc's __SANITIZE_ADDRESS__ flag, or memset() calls won't be instrumented. Signed-off-by: Greg Hackmann <ghackm...@google.com> --- include/linux/compiler-clang.

[PATCH 4/4] kasan: add compiler support for clang

For now we can hard-code ASAN ABI level 5, since historical clang builds can't build the kernel anyway. We also need to emulate gcc's __SANITIZE_ADDRESS__ flag, or memset() calls won't be instrumented. Signed-off-by: Greg Hackmann --- include/linux/compiler-clang.h | 10 ++ 1 file

[PATCH 2/4] kasan: added functions for unpoisoning stack variables

kernel when using KASAN. Signed-off-by: Alexander Potapenko <gli...@google.com> [ghackm...@google.com: fix memset() parameters, and tweak commit message to describe new callbacks] Signed-off-by: Greg Hackmann <ghackm...@google.com> --- mm/kasan/kasan.c | 15 +++ 1 file chan

[PATCH 2/4] kasan: added functions for unpoisoning stack variables

. Signed-off-by: Alexander Potapenko [ghackm...@google.com: fix memset() parameters, and tweak commit message to describe new callbacks] Signed-off-by: Greg Hackmann --- mm/kasan/kasan.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c index

[PATCH 1/4] kasan: support alloca() poisoning

of the dynamic stack area, so unpoisoning is simpler. Signed-off-by: Greg Hackmann <ghackm...@google.com> --- lib/test_kasan.c | 22 ++ mm/kasan/kasan.c | 26 ++ mm/kasan/kasan.h | 8 mm/kasan/report.c | 3 +++ 4 files changed, 59 insertions(+)

[PATCH 1/4] kasan: support alloca() poisoning

of the dynamic stack area, so unpoisoning is simpler. Signed-off-by: Greg Hackmann --- lib/test_kasan.c | 22 ++ mm/kasan/kasan.c | 26 ++ mm/kasan/kasan.h | 8 mm/kasan/report.c | 3 +++ 4 files changed, 59 insertions(+) diff --git a/lib

[PATCH 3/4] kasan: support LLVM-style asan parameters

Use cc-option to figure out whether the compiler's sanitizer uses LLVM-style parameters ("-mllvm -asan-foo=bar") or GCC-style parameters ("--param asan-foo=bar"). Signed-off-by: Greg Hackmann <ghackm...@google.com> --- scripts/Makefile.kasan | 10 +- 1 file c

[PATCH 3/4] kasan: support LLVM-style asan parameters

Use cc-option to figure out whether the compiler's sanitizer uses LLVM-style parameters ("-mllvm -asan-foo=bar") or GCC-style parameters ("--param asan-foo=bar"). Signed-off-by: Greg Hackmann --- scripts/Makefile.kasan | 10 +- 1 file changed, 9 insertions(+), 1 del

[PATCH 0/4] kasan: add clang support

*** Alexander Potapenko (1): kasan: added functions for unpoisoning stack variables Greg Hackmann (3): kasan: support alloca() poisoning kasan: support LLVM-style asan parameters kasan: add compiler support for clang include/linux/compiler-clang.h | 10 ++ lib/test_kasan.c

[PATCH 0/4] kasan: add clang support

*** Alexander Potapenko (1): kasan: added functions for unpoisoning stack variables Greg Hackmann (3): kasan: support alloca() poisoning kasan: support LLVM-style asan parameters kasan: add compiler support for clang include/linux/compiler-clang.h | 10 ++ lib/test_kasan.c

Re: [PATCH] efi/libstub: Indicate clang the relocation mode for arm64

On 05/11/2017 06:51 AM, Ard Biesheuvel wrote: [snip] In my opinion, the correct fix would be to make -fpie (as opposed to -fpic) imply hidden visibility, given that PIE executables don't export symbols in the first place, and so the preemption rules do not apply. It is worth a try whether -fpie

Re: [PATCH] efi/libstub: Indicate clang the relocation mode for arm64

On 05/11/2017 06:51 AM, Ard Biesheuvel wrote: [snip] In my opinion, the correct fix would be to make -fpie (as opposed to -fpic) imply hidden visibility, given that PIE executables don't export symbols in the first place, and so the preemption rules do not apply. It is worth a try whether -fpie

Re: [PATCH] efi/libstub: Indicate clang the relocation mode for arm64

On 05/09/2017 12:36 PM, Matthias Kaehlcke wrote: From: Greg Hackmann <ghackm...@google.com> Without any extra guidance, clang will generate libstub with either absolute or relative ELF relocations. Use the right combination of -fpic and -fno-pic on different files to avoid this. Sign

Re: [PATCH] efi/libstub: Indicate clang the relocation mode for arm64

On 05/09/2017 12:36 PM, Matthias Kaehlcke wrote: From: Greg Hackmann Without any extra guidance, clang will generate libstub with either absolute or relative ELF relocations. Use the right combination of -fpic and -fno-pic on different files to avoid this. Signed-off-by: Greg Hackmann Signed

Re: [PATCH v2] x86/mm/kaslr: Use _ASM_MUL macro for multiplication

On 04/26/2017 02:24 PM, h...@zytor.com wrote: This really feels like a "fix your compiler" issue. We already use the other forms, what's so bad about adding mul too? And if this lets us build under clang, all the better. -Kees It's not bad per se, but if this doesn't eventually gets fixed

Re: [PATCH v2] x86/mm/kaslr: Use _ASM_MUL macro for multiplication

On 04/26/2017 02:24 PM, h...@zytor.com wrote: This really feels like a "fix your compiler" issue. We already use the other forms, what's so bad about adding mul too? And if this lets us build under clang, all the better. -Kees It's not bad per se, but if this doesn't eventually gets fixed

Re: [PATCH] staging: android: ashmem: lseek failed due to no FMODE_LSEEK.

On 04/06/2017 10:08 AM, Greg KH wrote: On Thu, Apr 06, 2017 at 08:30:40AM -0700, Greg Hackmann wrote: On 04/06/2017 07:30 AM, zhangshuxia...@gmail.com wrote: From: zhangshuxiao <zhangshux...@xiaomi.com> vfs_llseek will check whether the file mode has FMODE_LSEEK, no return failure. But

Re: [PATCH] staging: android: ashmem: lseek failed due to no FMODE_LSEEK.

On 04/06/2017 10:08 AM, Greg KH wrote: On Thu, Apr 06, 2017 at 08:30:40AM -0700, Greg Hackmann wrote: On 04/06/2017 07:30 AM, zhangshuxia...@gmail.com wrote: From: zhangshuxiao vfs_llseek will check whether the file mode has FMODE_LSEEK, no return failure. But ashmem can be lseek, so add

Re: [PATCH] staging: android: ashmem: lseek failed due to no FMODE_LSEEK.

iaomi.com> Tested-by: Greg Hackmann <ghackm...@google.com> --- drivers/staging/android/ashmem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c index 3f11332..e4530ac 100644 --- a/drivers/staging/android/ashmem.c +++

Re: [PATCH] staging: android: ashmem: lseek failed due to no FMODE_LSEEK.

On 04/06/2017 07:30 AM, zhangshuxia...@gmail.com wrote: From: zhangshuxiao vfs_llseek will check whether the file mode has FMODE_LSEEK, no return failure. But ashmem can be lseek, so add FMODE_LSEEK to ashmem file. Signed-off-by: Shuxiao Zhang Tested-by: Greg Hackmann --- drivers/staging

[PATCH] config: android-base: CONFIG_SYNC -> CONFIG_SYNC_FILE

Explicit sync was renamed to CONFIG_SYNC_FILE when it was destaged, but the Android config fragment still tries to use the old name. Signed-off-by: Greg Hackmann <ghackm...@google.com> --- kernel/configs/android-base.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH] config: android-base: CONFIG_SYNC -> CONFIG_SYNC_FILE

Explicit sync was renamed to CONFIG_SYNC_FILE when it was destaged, but the Android config fragment still tries to use the old name. Signed-off-by: Greg Hackmann --- kernel/configs/android-base.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/configs/android

Re: [RFC v2 5/8] drm/fence: add in-fences support

On 04/26/2016 11:39 PM, Daniel Vetter wrote: A (per-CRTC?) array of fences would be more flexible. And even in the cases where you could make a 1-to-1 mapping between planes and fences, it's not that much more work for userspace to assemble those fences into an array anyway. I'm ok with an

Re: [RFC v2 5/8] drm/fence: add in-fences support

On 04/26/2016 11:39 PM, Daniel Vetter wrote: A (per-CRTC?) array of fences would be more flexible. And even in the cases where you could make a 1-to-1 mapping between planes and fences, it's not that much more work for userspace to assemble those fences into an array anyway. I'm ok with an

Re: [RFC v2 5/8] drm/fence: add in-fences support

On 04/26/2016 01:05 PM, Daniel Vetter wrote: On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote: On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote: On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote: But really the reason for per-plane is hw composer from

Re: [RFC v2 5/8] drm/fence: add in-fences support

On 04/26/2016 01:05 PM, Daniel Vetter wrote: On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote: On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote: On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote: But really the reason for per-plane is hw composer from

Re: [PATCH] staging/android: change IOCTLs opcode after ABI change

; Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk> Acked-by: Greg Hackmann <ghackm...@google.com>

Re: [PATCH] staging/android: change IOCTLs opcode after ABI change

yet and the only user is Android, but we don't expect anyone trying to run android userspace and all it dependencies on top of upstream kernels. Moreover Android should be converted to use upstream sync_files. Suggested-by: Rob Clark Signed-off-by: Gustavo Padovan Acked-by: Greg Hackmann

Re: [PATCH v7 1/5] staging/android: add num_fences field to struct sync_file_info

at's needed to get sync moved out of staging. Pragmatically speaking, this won't break ordinary Android apps, because they don't get direct access to sync fence fds to begin with. Some privileged system processes do, but they go through libsync, which can be changed to deal with the ABI differences.

Re: [PATCH v7 1/5] staging/android: add num_fences field to struct sync_file_info

t get direct access to sync fence fds to begin with. Some privileged system processes do, but they go through libsync, which can be changed to deal with the ABI differences. Anyway, for the whole series: Acked-by: Greg Hackmann

[PATCH] selftests: breakpoint: add step_after_suspend_test

Commit e56d82a11617 ("arm64: cpu hotplug: ensure we mask out CPU_TASKS_FROZEN in notifiers") fixed a long-standing ARM64 bug that broke single-stepping after a suspend/resume cycle. Add a kernel selftest to make sure this doesn't regress or affect other platforms. Signed-off-by: Gre

  1   2   >