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
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
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
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
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
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
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
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.
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 +-
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.
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
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
---
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
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
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
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
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:
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:
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:
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: 征增 王
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
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
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
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
>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
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
>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
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
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(+)
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
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
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
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
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
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'
>
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'
>
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'
>
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'
>
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);
}
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);
}
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
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
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'
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'
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
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 ++-
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
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
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
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
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'
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
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
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
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
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
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:
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
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;
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;
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
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
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
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
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
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
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
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
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
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
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:
>> >>
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
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
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
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
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
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
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
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
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
---
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
---
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
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
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 - 100 of 3138 matches
Mail list logo