Re: [PATCH] x86: always use SYSCALL_DEFINE*

Michael, On Tue, Mar 13, 2018 at 11:18:08PM +, Andy Lutomirski wrote: > On Tue, Mar 13, 2018 at 9:16 PM, Jann Horn wrote: > > On Sat, Mar 10, 2018 at 12:55 PM, Tautschnig, Michael > > wrote: > >> All syscall arguments are passed in as types of the

Re: [PATCH] x86: always use SYSCALL_DEFINE*

Michael, On Tue, Mar 13, 2018 at 11:18:08PM +, Andy Lutomirski wrote: > On Tue, Mar 13, 2018 at 9:16 PM, Jann Horn wrote: > > On Sat, Mar 10, 2018 at 12:55 PM, Tautschnig, Michael > > wrote: > >> All syscall arguments are passed in as types of the same byte size as > >> unsigned long (width

Re: [PATCH v5 06/36] drm/rockchip: Only wait for panel ACK on PSR entry

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote: From: zain wang We currently wait for the panel to mirror our intended PSR state before continuing on both PSR enter and PSR exit. This is really only important to do when we're entering PSR, since we want

Re: [PATCH v5 06/36] drm/rockchip: Only wait for panel ACK on PSR entry

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote: From: zain wang We currently wait for the panel to mirror our intended PSR state before continuing on both PSR enter and PSR exit. This is really only important to do when we're entering PSR, since we want to be sure the last

Re: [PATCH v5 05/36] drm/bridge: analogix_dp: add fast link train for eDP

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote: From: zain wang We would meet a short black screen when exit PSR with the full link training, In this case, we should use fast link train instead of full link training. Signed-off-by: zain wang

Re: [PATCH v5 05/36] drm/bridge: analogix_dp: add fast link train for eDP

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote: From: zain wang We would meet a short black screen when exit PSR with the full link training, In this case, we should use fast link train instead of full link training. Signed-off-by: zain wang Signed-off-by: Sean Paul

[PATCH ghak21 V3 1/2] audit: remove path param from link denied function

In commit 45b578fe4c3cade6f4ca1fc934ce199afd857edc ("audit: link denied should not directly generate PATH record") the need for the struct path *link parameter was removed. Remove the now useless struct path argument. Signed-off-by: Richard Guy Briggs --- fs/namei.c

[PATCH ghak21 V3 0/2] audit: address ANOM_LINK excess records

This V3 is a supplement to patches 1 and 2 of v1 already merged. Audit link denied events were being unexpectedly produced in a disjoint way when audit was disabled, and when they were expected, there were duplicate PATH records. This patchset addresses both issues for symlinks and hardlinks.

[PATCH ghak21 V3 1/2] audit: remove path param from link denied function

In commit 45b578fe4c3cade6f4ca1fc934ce199afd857edc ("audit: link denied should not directly generate PATH record") the need for the struct path *link parameter was removed. Remove the now useless struct path argument. Signed-off-by: Richard Guy Briggs --- fs/namei.c| 2 +-

[PATCH ghak21 V3 0/2] audit: address ANOM_LINK excess records

This V3 is a supplement to patches 1 and 2 of v1 already merged. Audit link denied events were being unexpectedly produced in a disjoint way when audit was disabled, and when they were expected, there were duplicate PATH records. This patchset addresses both issues for symlinks and hardlinks.

[PATCH ghak21 V3 2/2] audit: add refused symlink to audit_names

Audit link denied events for symlinks had duplicate PATH records rather than just updating the existing PATH record. Update the symlink's PATH record with the current dentry and inode information. See: https://github.com/linux-audit/audit-kernel/issues/21 Signed-off-by: Richard Guy Briggs

[PATCH ghak21 V3 2/2] audit: add refused symlink to audit_names

Audit link denied events for symlinks had duplicate PATH records rather than just updating the existing PATH record. Update the symlink's PATH record with the current dentry and inode information. See: https://github.com/linux-audit/audit-kernel/issues/21 Signed-off-by: Richard Guy Briggs ---

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

Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from include/linux/kernel.h:15:0, from include/linux/list.h:9, from mm/hugetlb.c:5: mm/hugetlb.c: In function

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

Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from include/linux/kernel.h:15:0, from include/linux/list.h:9, from mm/hugetlb.c:5: mm/hugetlb.c: In function

Re: [PATCH v4 09/24] fpga: dfl-pci: add enumeration for feature devices

On Tue, Mar 13, 2018 at 01:30:24PM -0500, Alan Tull wrote: > On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao wrote: > > Hi Hao, > > Thanks again for splitting the pci part of the code from enumeration > and everything else. > > One thing that may need to be fixed below, so with that

Re: [PATCH v4 09/24] fpga: dfl-pci: add enumeration for feature devices

On Tue, Mar 13, 2018 at 01:30:24PM -0500, Alan Tull wrote: > On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao wrote: > > Hi Hao, > > Thanks again for splitting the pci part of the code from enumeration > and everything else. > > One thing that may need to be fixed below, so with that fixed, adding my

Re: [PATCH v5 03/36] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote: From: zain wang There is a race between AUX CH bring-up and enabling bridge which will cause link training to fail. To avoid hitting it, don't change psr state while enabling the bridge. Reviewed-by:

Re: [PATCH v5 03/36] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote: From: zain wang There is a race between AUX CH bring-up and enabling bridge which will cause link training to fail. To avoid hitting it, don't change psr state while enabling the bridge. Reviewed-by: Archit Taneja Cc:

Re: [PATCH v5 01/36] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote: From: Yakir Yang Make sure the request PSR state takes effect in analogix_dp_send_psr_spd() function, or print the sink PSR error state if we failed to apply the requested PSR setting. Reviewed-by:

Re: [PATCH v5 01/36] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote: From: Yakir Yang Make sure the request PSR state takes effect in analogix_dp_send_psr_spd() function, or print the sink PSR error state if we failed to apply the requested PSR setting. Reviewed-by: Archit Taneja Cc: 征增 王

Re: [PATCH ghak21 V2 3/4] audit: add refused symlink to audit_names

On 2018-03-13 16:24, Paul Moore wrote: > On Tue, Mar 13, 2018 at 6:52 AM, Richard Guy Briggs wrote: > > On 2018-03-13 11:38, Steve Grubb wrote: > >> On Tue, 13 Mar 2018 06:11:08 -0400 > >> Richard Guy Briggs wrote: > >> > >> > On 2018-03-13 09:35, Steve Grubb

Re: [PATCH ghak21 V2 3/4] audit: add refused symlink to audit_names

On 2018-03-13 16:24, Paul Moore wrote: > On Tue, Mar 13, 2018 at 6:52 AM, Richard Guy Briggs wrote: > > On 2018-03-13 11:38, Steve Grubb wrote: > >> On Tue, 13 Mar 2018 06:11:08 -0400 > >> Richard Guy Briggs wrote: > >> > >> > On 2018-03-13 09:35, Steve Grubb wrote: > >> > > On Mon, 12 Mar 2018

[PATCH] ARM: dts: uniphier: add sound node for UniPhier PXs2

This patch adds audio controller, external codec and simple card node of UniPhier AIO sound system for PXs2 SoCs. Signed-off-by: Katsuhiro Suzuki --- arch/arm/boot/dts/uniphier-pxs2-gentil.dts | 24 + arch/arm/boot/dts/uniphier-pxs2-vodka.dts | 37

[PATCH] ARM: dts: uniphier: add sound node for UniPhier PXs2

This patch adds audio controller, external codec and simple card node of UniPhier AIO sound system for PXs2 SoCs. Signed-off-by: Katsuhiro Suzuki --- arch/arm/boot/dts/uniphier-pxs2-gentil.dts | 24 + arch/arm/boot/dts/uniphier-pxs2-vodka.dts | 37

[PATCH v2] x86: i8237: Register based on FADT legacy boot flag

>From Skylake onwards, the platform controller hub (Sunrisepoint PCH) does not support legacy DMA operations to IO ports 81h-83h, 87h, 89h-8Bh, 8Fh. Currently this driver registers as syscore ops and its resume function is called on every resume from S3. On Skylake and Kabylake, this causes a

[PATCH v4] HID: google: add google hammer HID driver

From: Wei-Ning Huang Add Google hammer HID driver. This driver allow us to control hammer keyboard backlight and support future features. We add a new HID quirk, that allows us to have the keyboard interface to bind to google-hammer driver, while the touchpad interface can

[PATCH v2] x86: i8237: Register based on FADT legacy boot flag

>From Skylake onwards, the platform controller hub (Sunrisepoint PCH) does not support legacy DMA operations to IO ports 81h-83h, 87h, 89h-8Bh, 8Fh. Currently this driver registers as syscore ops and its resume function is called on every resume from S3. On Skylake and Kabylake, this causes a

[PATCH v4] HID: google: add google hammer HID driver

From: Wei-Ning Huang Add Google hammer HID driver. This driver allow us to control hammer keyboard backlight and support future features. We add a new HID quirk, that allows us to have the keyboard interface to bind to google-hammer driver, while the touchpad interface can bind to the

[PATCH] ARM: dts: uniphier: add audio in/out pin-mux node

The UniPhier AIO audio system needs I2S data in/out lines and clock signal pins to connect external codec chip. Signed-off-by: Katsuhiro Suzuki --- arch/arm/boot/dts/uniphier-pinctrl.dtsi | 40 + 1 file changed, 40 insertions(+)

[PATCH] ARM: dts: uniphier: add audio in/out pin-mux node

The UniPhier AIO audio system needs I2S data in/out lines and clock signal pins to connect external codec chip. Signed-off-by: Katsuhiro Suzuki --- arch/arm/boot/dts/uniphier-pinctrl.dtsi | 40 + 1 file changed, 40 insertions(+) diff --git

linux-next: build failure after merge of the syscalls tree

Hi Dominik, After merging the syscalls tree, today's linux-next build (powerpc allnoconfig) failed like this: arch/powerpc/kernel/syscalls.o: In function `ppc_fadvise64_64': syscalls.c:(.text+0xb8): undefined reference to `ksys_fadvise64_64' Caused by commit fabbf34a610d ("mm: add

linux-next: build failure after merge of the syscalls tree

Hi Dominik, After merging the syscalls tree, today's linux-next build (powerpc allnoconfig) failed like this: arch/powerpc/kernel/syscalls.o: In function `ppc_fadvise64_64': syscalls.c:(.text+0xb8): undefined reference to `ksys_fadvise64_64' Caused by commit fabbf34a610d ("mm: add

[PATCH] pinctrl: uniphier: add PXs2 Audio in/out pin-mux settings

The UniPhier PXs2 SoC audio core use following 25 pins: ain1: 2ch I2S input : AI1ADCCK, AI1BCK, AI1D0, AI1LRCK ain2: 8ch I2S input : AI2ADCCK, AI2BCK, AI2D[0-3], AI2LRCK ainiec1 : S/PDIF input : XIRQ17 (for AO1IEC) aout2 : 8ch I2S output: AO2BCK, AO2D0, AO2DACCK, AO2LRCK

[PATCH] pinctrl: uniphier: add PXs2 Audio in/out pin-mux settings

The UniPhier PXs2 SoC audio core use following 25 pins: ain1: 2ch I2S input : AI1ADCCK, AI1BCK, AI1D0, AI1LRCK ain2: 8ch I2S input : AI2ADCCK, AI2BCK, AI2D[0-3], AI2LRCK ainiec1 : S/PDIF input : XIRQ17 (for AO1IEC) aout2 : 8ch I2S output: AO2BCK, AO2D0, AO2DACCK, AO2LRCK

Re: [PATCH 2/2] cpufreq: scmi: add thermal dependency

On 13-03-18, 12:45, Arnd Bergmann wrote: > A built-in scmi cpufreq driver cannot link against a modular > thermal framework: > > drivers/cpufreq/scmi-cpufreq.o: In function `scmi_cpufreq_ready': > scmi-cpufreq.c:(.text+0x40): undefined reference to > `of_cpufreq_cooling_register' >

Re: [PATCH 2/2] cpufreq: scmi: add thermal dependency

On 13-03-18, 12:45, Arnd Bergmann wrote: > A built-in scmi cpufreq driver cannot link against a modular > thermal framework: > > drivers/cpufreq/scmi-cpufreq.o: In function `scmi_cpufreq_ready': > scmi-cpufreq.c:(.text+0x40): undefined reference to > `of_cpufreq_cooling_register' >

Re: [PATCH 1/2] cpufreq: scpi: add thermal dependency

On 13-03-18, 12:45, Arnd Bergmann wrote: > A built-in scpi cpufreq driver cannot link against a modular > thermal framework: > > drivers/cpufreq/scpi-cpufreq.o: In function `scpi_cpufreq_ready': > scpi-cpufreq.c:(.text+0x4c): undefined reference to > `of_cpufreq_cooling_register' >

Re: [PATCH 1/2] cpufreq: scpi: add thermal dependency

On 13-03-18, 12:45, Arnd Bergmann wrote: > A built-in scpi cpufreq driver cannot link against a modular > thermal framework: > > drivers/cpufreq/scpi-cpufreq.o: In function `scpi_cpufreq_ready': > scpi-cpufreq.c:(.text+0x4c): undefined reference to > `of_cpufreq_cooling_register' >

Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

On 3/13/18 10:20 PM, Sinan Kaya wrote: +/* Assumes caller has executed a write barrier to order memory and device + * requests. + */ static inline void ixgbevf_write_tail(struct ixgbevf_ring *ring, u32 value) { - writel(value, ring->tail); + writel_relaxed(value, ring->tail); }

Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

On 3/13/18 10:20 PM, Sinan Kaya wrote: +/* Assumes caller has executed a write barrier to order memory and device + * requests. + */ static inline void ixgbevf_write_tail(struct ixgbevf_ring *ring, u32 value) { - writel(value, ring->tail); + writel_relaxed(value, ring->tail); }

[PATCH 1/3] selftests/x86/entry_from_vm86: Exit with 1 if we fail

Fix a logic error that caused the test to exit with 0 even if test cases failed. Cc: sta...@vger.kernel.org Signed-off-by: Andy Lutomirski --- tools/testing/selftests/x86/entry_from_vm86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/3] selftests/x86/entry_from_vm86: Exit with 1 if we fail

Fix a logic error that caused the test to exit with 0 even if test cases failed. Cc: sta...@vger.kernel.org Signed-off-by: Andy Lutomirski --- tools/testing/selftests/x86/entry_from_vm86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 0/3] x86/vm86/32: A bugfix and a matching test improvement

A patch in 4.2 broke vm86's POPF emulation in a way that was somehow subtle enough that no one noticed until now. Fix it and improve the test case to exercise the code. (The improved test case also exercises some code paths that were *not* broken but that would have become broken if Stas'

[PATCH 0/3] x86/vm86/32: A bugfix and a matching test improvement

A patch in 4.2 broke vm86's POPF emulation in a way that was somehow subtle enough that no one noticed until now. Fix it and improve the test case to exercise the code. (The improved test case also exercises some code paths that were *not* broken but that would have become broken if Stas'

[PATCH 3/3] x86/vm86/32: Fix POPF emulation

POPF would trap if VIP was set regardless of whether IF was set. Fix it. Reported-by: Bart Oldeman Suggested-by: Stas Sergeev Cc: sta...@vger.kernel.org Fixes: 5ed92a8ab71f ("x86/vm86: Use the normal pt_regs area for vm86") Signed-off-by: Andy Lutomirski

[PATCH 3/3] x86/vm86/32: Fix POPF emulation

POPF would trap if VIP was set regardless of whether IF was set. Fix it. Reported-by: Bart Oldeman Suggested-by: Stas Sergeev Cc: sta...@vger.kernel.org Fixes: 5ed92a8ab71f ("x86/vm86: Use the normal pt_regs area for vm86") Signed-off-by: Andy Lutomirski --- arch/x86/kernel/vm86_32.c | 3 ++-

[PATCH 2/3] selftests/x86/entry_from_vm86: Add test cases for POPF

POPF is currently broken -- add tests to catch the error. This results in: [RUN]POPF with VIP set and IF clear from vm86 mode [INFO] Exited vm86 mode due to STI [FAIL] Incorrect return reason (started at eip = 0xd, ended at eip = 0xf) because POPF currently fails

[PATCH 2/3] selftests/x86/entry_from_vm86: Add test cases for POPF

POPF is currently broken -- add tests to catch the error. This results in: [RUN]POPF with VIP set and IF clear from vm86 mode [INFO] Exited vm86 mode due to STI [FAIL] Incorrect return reason (started at eip = 0xd, ended at eip = 0xf) because POPF currently fails

[PATCH] x86, memremap: fix altmap accounting at free

Commit 24b6d4164348 "mm: pass the vmem_altmap to vmemmap_free" converted the vmemmap_free() path to pass the altmap argument all the way through the call chain rather than looking it up based on the page. Unfortunately that ends up over freeing altmap allocated pages in some cases since

[PATCH] x86, memremap: fix altmap accounting at free

Commit 24b6d4164348 "mm: pass the vmem_altmap to vmemmap_free" converted the vmemmap_free() path to pass the altmap argument all the way through the call chain rather than looking it up based on the page. Unfortunately that ends up over freeing altmap allocated pages in some cases since

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

Hi Dominik, On Wed, 14 Mar 2018 15:57:25 +1100 Stephen Rothwell wrote: > > After merging the syscalls tree, today's linux-next build (x86_64 > allnoconfig) failed like this: kernel/fork.o: In function `mm_release': fork.c:(.text+0x1a17): undefined reference to `do_futex'

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

Hi Dominik, On Wed, 14 Mar 2018 15:57:25 +1100 Stephen Rothwell wrote: > > After merging the syscalls tree, today's linux-next build (x86_64 > allnoconfig) failed like this: kernel/fork.o: In function `mm_release': fork.c:(.text+0x1a17): undefined reference to `do_futex' -- Cheers, Stephen

linux-next: build failure after merge of the syscalls tree

Hi Dominik, After merging the syscalls tree, today's linux-next build (x86_64 allnoconfig) failed like this: Caused by commit 3e334170db85 ("mm: use do_futex() instead of sys_futex() in mm_release()") CONFIG_FUTEX is not set for this build. Normally sys_futex() would be the one from

linux-next: build failure after merge of the syscalls tree

Hi Dominik, After merging the syscalls tree, today's linux-next build (x86_64 allnoconfig) failed like this: Caused by commit 3e334170db85 ("mm: use do_futex() instead of sys_futex() in mm_release()") CONFIG_FUTEX is not set for this build. Normally sys_futex() would be the one from

Re: [PATCH 2/5] MODSIGN: print appropriate status message when getting UEFI certificates list

Hi James, Thanks for your review. On Tue, Mar 13, 2018 at 10:17:50AM -0700, James Bottomley wrote: > On Tue, 2018-03-13 at 18:35 +0800, Lee, Chun-Yi wrote: > > When getting certificates list from UEFI variable, the original error > > message shows the state number from UEFI firmware. It's hard

Re: [PATCH 2/5] MODSIGN: print appropriate status message when getting UEFI certificates list

Hi James, Thanks for your review. On Tue, Mar 13, 2018 at 10:17:50AM -0700, James Bottomley wrote: > On Tue, 2018-03-13 at 18:35 +0800, Lee, Chun-Yi wrote: > > When getting certificates list from UEFI variable, the original error > > message shows the state number from UEFI firmware. It's hard

Re: [PATCH v1 2/2] usb: dwc3: Add Qualcomm DWC3 glue driver

Hi, On 3/13/2018 4:38 PM, Felipe Balbi wrote: > Hi, > > +Andy > > Manu Gautam writes: >> DWC3 controller on Qualcomm SOCs has a Qscratch wrapper. >> Some of its uses are described below resulting in need to >> have a separate glue driver instead of using dwc3-of-simple:

Re: [PATCH v1 2/2] usb: dwc3: Add Qualcomm DWC3 glue driver

Hi, On 3/13/2018 4:38 PM, Felipe Balbi wrote: > Hi, > > +Andy > > Manu Gautam writes: >> DWC3 controller on Qualcomm SOCs has a Qscratch wrapper. >> Some of its uses are described below resulting in need to >> have a separate glue driver instead of using dwc3-of-simple: >> - It exposes

RE: [PATCH v2] Revert "base: arch_topology: fix section mismatch build warnings"

Hi, Greg, would you review this? I confirmed it can be applied rebased on 4.16-rc5. Regards Inami > -Original Message- > From: Gaku Inami > Sent: Tuesday, February 13, 2018 11:07 AM > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org > Cc: dietmar.eggem...@arm.com;

RE: [PATCH v2] Revert "base: arch_topology: fix section mismatch build warnings"

Hi, Greg, would you review this? I confirmed it can be applied rebased on 4.16-rc5. Regards Inami > -Original Message- > From: Gaku Inami > Sent: Tuesday, February 13, 2018 11:07 AM > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org > Cc: dietmar.eggem...@arm.com;

Re: [PATCH v1 2/2] usb: dwc3: Add Qualcomm DWC3 glue driver

Hi Manu, Thank you for the patch! Yet something to improve: [auto build test ERROR on v4.16-rc4] [also build test ERROR on next-20180313] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Manu

Re: [PATCH v1 2/2] usb: dwc3: Add Qualcomm DWC3 glue driver

Hi Manu, Thank you for the patch! Yet something to improve: [auto build test ERROR on v4.16-rc4] [also build test ERROR on next-20180313] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Manu

[PATCH v4.16-rc5 1/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index f19856d..fbc7371 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -182,6 +182,18 @@ notrace static u64 vread_tsc(void) return last; } +notrace

[PATCH v4.16-rc5 1/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index f19856d..fbc7371 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -182,6 +182,18 @@ notrace static u64 vread_tsc(void) return last; } +notrace

[PATCH v4.16-rc5 (3)] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

[PATCH v4.16-rc5 (3)] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

[PATCH v4.16-rc5 2/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index fbc7371..2c46675 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -184,10 +184,9 @@ notrace static u64 vread_tsc(void) notrace static u64

[PATCH v4.16-rc5 2/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index fbc7371..2c46675 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -184,10 +184,9 @@ notrace static u64 vread_tsc(void) notrace static u64

[PATCH v4.16-rc5 3/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index 2c46675..772988c 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -21,6 +21,7 @@ #include #include #include +#include #define gtod

[PATCH v4.16-rc5 3/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index 2c46675..772988c 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -21,6 +21,7 @@ #include #include #include +#include #define gtod

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Tue, Mar 13, 2018 at 3:20 AM, Peter Zijlstra wrote: > On Sun, Mar 11, 2018 at 10:15:55AM -0700, Dan Williams wrote: >> On Sun, Mar 11, 2018 at 4:27 AM, Peter Zijlstra wrote: >> > On Fri, Mar 09, 2018 at 10:55:32PM -0800, Dan Williams wrote: >> >>

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Tue, Mar 13, 2018 at 3:20 AM, Peter Zijlstra wrote: > On Sun, Mar 11, 2018 at 10:15:55AM -0700, Dan Williams wrote: >> On Sun, Mar 11, 2018 at 4:27 AM, Peter Zijlstra wrote: >> > On Fri, Mar 09, 2018 at 10:55:32PM -0800, Dan Williams wrote: >> >> Add a generic facility for awaiting an

Re: [PATCH 3/7] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs

On Tue, Mar 13, 2018 at 11:20:24PM -0400, Sinan Kaya wrote: > Code includes wmb() followed by writel() in multiple places. writel() > already has a barrier on some architectures like arm64. > > This ends up CPU observing two barriers back to back before executing the > register write. > > Since

Re: [PATCH 3/7] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs

On Tue, Mar 13, 2018 at 11:20:24PM -0400, Sinan Kaya wrote: > Code includes wmb() followed by writel() in multiple places. writel() > already has a barrier on some architectures like arm64. > > This ends up CPU observing two barriers back to back before executing the > register write. > > Since

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

Hi Artem, At 03/14/2018 11:29 AM, Dou Liyang wrote: Hi All, At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote: On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy wrote: On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote: Then looks this issue need to fix by making possible

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

Hi Artem, At 03/14/2018 11:29 AM, Dou Liyang wrote: Hi All, At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote: On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy wrote: On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote: Then looks this issue need to fix by making possible CPU count accurate

[PATCH v5 08/10] fix get_timespec64() for y2038 safe compat interfaces

get/put_timespec64() interfaces will eventually be used for conversions between the new y2038 safe struct __kernel_timespec and struct timespec64. The new y2038 safe syscalls have a common entry for native and compat interfaces. On compat interfaces, the high order bits of nanoseconds should be

[PATCH v5 09/10] change time types to new y2038 safe __kernel_* types

Change over clock_settime, clock_gettime and clock_getres syscalls to use __kernel_timespec times. This will enable changing over of these syscalls to use new y2038 safe syscalls when the architectures define the CONFIG_64BIT_TIME. Cc: linux-...@vger.kernel.org Signed-off-by: Deepa Dinamani

[PATCH v5 08/10] fix get_timespec64() for y2038 safe compat interfaces

get/put_timespec64() interfaces will eventually be used for conversions between the new y2038 safe struct __kernel_timespec and struct timespec64. The new y2038 safe syscalls have a common entry for native and compat interfaces. On compat interfaces, the high order bits of nanoseconds should be

[PATCH v5 09/10] change time types to new y2038 safe __kernel_* types

Change over clock_settime, clock_gettime and clock_getres syscalls to use __kernel_timespec times. This will enable changing over of these syscalls to use new y2038 safe syscalls when the architectures define the CONFIG_64BIT_TIME. Cc: linux-...@vger.kernel.org Signed-off-by: Deepa Dinamani ---

[PATCH v5 07/10] include: Add new y2038 safe __kernel_timespec

The new struct __kernel_timespec is similar to current internal kernel struct timespec64 on 64 bit architecture. The compat structure however is similar to below on little endian systems (padding and tv_nsec are switched for big endian systems): typedef s32compat_long_t; typedef s64

[PATCH v5 07/10] include: Add new y2038 safe __kernel_timespec

The new struct __kernel_timespec is similar to current internal kernel struct timespec64 on 64 bit architecture. The compat structure however is similar to below on little endian systems (padding and tv_nsec are switched for big endian systems): typedef s32compat_long_t; typedef s64

[PATCH v5 05/10] arch: Introduce CONFIG_COMPAT_32BIT_TIME

Compat functions are now used to support 32 bit time_t in compat mode on 64 bit architectures and in native mode on 32 bit architectures. Introduce COMPAT_32BIT_TIME to conditionally compile these functions. Note that turning off 32 bit time_t support requires more changes on architecture side.

[PATCH v5 10/10] nanosleep: change time types to safe __kernel_* types

Change over clock_nanosleep syscalls to use y2038 safe __kernel_timespec times. This will enable changing over of these syscalls to use new y2038 safe syscalls when the architectures define the CONFIG_64BIT_TIME. Note that nanosleep syscall is deprecated and does not have a plan for making it

[PATCH v5 05/10] arch: Introduce CONFIG_COMPAT_32BIT_TIME

Compat functions are now used to support 32 bit time_t in compat mode on 64 bit architectures and in native mode on 32 bit architectures. Introduce COMPAT_32BIT_TIME to conditionally compile these functions. Note that turning off 32 bit time_t support requires more changes on architecture side.

[PATCH v5 10/10] nanosleep: change time types to safe __kernel_* types

Change over clock_nanosleep syscalls to use y2038 safe __kernel_timespec times. This will enable changing over of these syscalls to use new y2038 safe syscalls when the architectures define the CONFIG_64BIT_TIME. Note that nanosleep syscall is deprecated and does not have a plan for making it

[PATCH v5 04/10] arch: introduce CONFIG_64BIT_TIME

There are a total of 53 system calls (aside from ioctl) that pass a time_t or derived data structure as an argument, and in order to extend time_t to 64-bit, we have to replace them with new system calls and keep providing backwards compatibility. To avoid adding completely new and untested code

[PATCH v5 04/10] arch: introduce CONFIG_64BIT_TIME

There are a total of 53 system calls (aside from ioctl) that pass a time_t or derived data structure as an argument, and in order to extend time_t to 64-bit, we have to replace them with new system calls and keep providing backwards compatibility. To avoid adding completely new and untested code

[PATCH v5 06/10] posix-clocks: Make compat syscalls depend on CONFIG_COMPAT_32BIT_TIME

clock_gettime, clock_settime, clock_getres and clock_nanosleep compat syscalls are also repurposed to provide backward compatibility to support 32 bit time_t on 32 bit systems. Note that nanosleep compat syscall will also be treated the same way as the above syscalls as it shares common handler

[PATCH v5 06/10] posix-clocks: Make compat syscalls depend on CONFIG_COMPAT_32BIT_TIME

clock_gettime, clock_settime, clock_getres and clock_nanosleep compat syscalls are also repurposed to provide backward compatibility to support 32 bit time_t on 32 bit systems. Note that nanosleep compat syscall will also be treated the same way as the above syscalls as it shares common handler

[PATCH v5 02/10] include: Move compat_timespec/ timeval to compat_time.h

All the current architecture specific defines for these are the same. Refactor these common defines to a common header file. The new common linux/compat_time.h is also useful as it will eventually be used to hold all the defines that are needed for compat time types that support non y2038 safe

[PATCH v5 03/10] compat: enable compat_get/put_timespec64 always

These functions are used in the repurposed compat syscalls to provide backward compatibility for using 32 bit time_t on 32 bit systems. Signed-off-by: Deepa Dinamani --- include/linux/compat.h | 2 -- include/linux/compat_time.h | 4 kernel/compat.c

[PATCH v5 02/10] include: Move compat_timespec/ timeval to compat_time.h

All the current architecture specific defines for these are the same. Refactor these common defines to a common header file. The new common linux/compat_time.h is also useful as it will eventually be used to hold all the defines that are needed for compat time types that support non y2038 safe

[PATCH v5 03/10] compat: enable compat_get/put_timespec64 always

These functions are used in the repurposed compat syscalls to provide backward compatibility for using 32 bit time_t on 32 bit systems. Signed-off-by: Deepa Dinamani --- include/linux/compat.h | 2 -- include/linux/compat_time.h | 4 kernel/compat.c | 52

[PATCH v5 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

The series is a preparation series for individual architectures to use 64 bit time_t syscalls in compat and 32 bit emulation modes. This is a follow up to the series Arnd Bergmann posted: https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html [1] Thomas, Arnd, this seems ready to be merged

[PATCH v5 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

The series is a preparation series for individual architectures to use 64 bit time_t syscalls in compat and 32 bit emulation modes. This is a follow up to the series Arnd Bergmann posted: https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html [1] Thomas, Arnd, this seems ready to be merged

[PATCH v5 01/10] compat: Make compat helpers independent of CONFIG_COMPAT

Many of the compat time syscalls are also repurposed as 32 bit native syscalls to provide backward compatibility while adding new y2038 safe sycalls. Enabling the helpers makes this possible. Signed-off-by: Arnd Bergmann Signed-off-by: Deepa Dinamani ---

[PATCH v5 01/10] compat: Make compat helpers independent of CONFIG_COMPAT

Many of the compat time syscalls are also repurposed as 32 bit native syscalls to provide backward compatibility while adding new y2038 safe sycalls. Enabling the helpers makes this possible. Signed-off-by: Arnd Bergmann Signed-off-by: Deepa Dinamani --- include/linux/compat.h | 8 ++-- 1

Re: [bug, bisected] pfifo_fast causes packet reordering

On 03/13/2018 11:35 AM, Dave Taht wrote: > On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher > wrote: >> During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux >> v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of

Re: [bug, bisected] pfifo_fast causes packet reordering

On 03/13/2018 11:35 AM, Dave Taht wrote: > On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher > wrote: >> During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux >> v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are >> delivered out-of-order. >>

  1   2   3   4   5   6   7   8   9   10   >