The first two patches contain the basic framework for the 64 bit time migration
for filesystems.
The next two patches shows how the framework has been adapted to vfs layer and
cifs filesystem.
There might be some minor changes or additions required as I start adapting to
other filesystems.
The change to timestamp conversion functions(to and from unix format to others)
and range checks will be part of a separate series.
Changes since RFC:
* struct inode_time added unconditionally
* uniform use of CONFIG_FS_USES_64BIT_TIME
* struct inode_timespec added
* merged the first two patches in the previous series
Deepa Dinamani (4):
vfs: Add 64 bit time support
kernel: time: Add macros and functions to support 64 bit time
vfs: Add support for vfs code to use 64 bit time.
fs: cifs: Add support for cifs to use 64 bit time
fs/attr.c | 14 +++++-----
fs/bad_inode.c | 9 ++++--
fs/binfmt_misc.c | 7 +++--
fs/cifs/cache.c | 16 +++++++----
fs/cifs/cifsencrypt.c | 2 +-
fs/cifs/cifsglob.h | 6 ++--
fs/cifs/cifsproto.h | 7 +++--
fs/cifs/cifssmb.c | 9 ++++--
fs/cifs/file.c | 9 ++++--
fs/cifs/inode.c | 68 +++++++++++++++++++++++++++++-----------------
fs/cifs/netmisc.c | 10 +++----
fs/inode.c | 44 +++++++++++++++++++-----------
fs/libfs.c | 58 +++++++++++++++++++++++++++++----------
fs/locks.c | 5 ++--
fs/nsfs.c | 6 +++-
fs/pipe.c | 6 +++-
fs/posix_acl.c | 2 +-
fs/stat.c | 6 ++--
fs/utimes.c | 4 +--
include/linux/fs.h | 74 ++++++++++++++++++++++++++++++++++++++++++--------
include/linux/stat.h | 6 ++--
include/linux/time64.h | 43 +++++++++++++++++++++++++++++
kernel/time/time.c | 65 +++++++++++++++++++++++++++++++++++++++++++-
23 files changed, 359 insertions(+), 117 deletions(-)
--
1.9.1
Concerned with migrating the key related structs in security/keys to
use 64-bit time datatypes; and their corresponding system calls and
macros. The patches are highly correlated and should be either accepted
or rejected as a series. However, they were generated in such
a way that they would be independent. This is for the sake of
readability and to avoid the introduction of new warnings while
building the kernel.
Aya Mahfouz (2):
security: keys: migrate structs key and keyring_search_context
security: keys: migrate struct key_preparsed_payload and time_t
variables
include/linux/key-type.h | 2 +-
include/linux/key.h | 6 +++---
security/keys/gc.c | 20 ++++++++++----------
security/keys/internal.h | 8 ++++----
security/keys/key.c | 20 +++++++-------------
security/keys/keyring.c | 16 ++++++++--------
security/keys/permission.c | 3 +--
security/keys/proc.c | 8 ++++----
security/keys/process_keys.c | 2 +-
9 files changed, 39 insertions(+), 46 deletions(-)
--
2.4.3
--
Kind Regards,
Aya Saif El-yazal Mahfouz
This is the basic framework for the 64 bit time migration for filesystems.
There might be some changes or additions required as I start adapting to
filesystems.
This gives the basic high level concept so that we can start discussing.
Actual changes to vfs and other file systems will be in a separate
series.
Changes since v1:
* struct inode_time added unconditionally
* uniform use of CONFIG_FS_USES_64BIT_TIME
Deepa Dinamani (4):
fs: vfs: add accessors for inode times
fs: Add new data type for inode times
fs: Add support for 64 bit time
fs: macros and functions support 64 bit time
include/linux/fs.h | 42 +++++++++++++++++++++++++++++++++++-------
include/linux/stat.h | 12 +++++++++---
include/linux/time.h | 2 ++
include/linux/time64.h | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/time/time.c | 28 ++++++++++++++++++++++++++++
5 files changed, 124 insertions(+), 10 deletions(-)
--
1.9.1
Hi,
I am new to linux kernel and trying to understand the process of
different git branch to work.
So, if I am not wrong then there are different branch like stable, next,
staging etc. Previously I work with staging branch so if I am making
any changes for drivers/staging I have to work with staging branch like
follow.
git clone
git checkout -t -b staging-testing origin/staging-testing
git chekcout -b MY_LOCAL_BRANCH
not do work and subimt
So, how it work for other source structure, like now I want to make some
for y2038 -> drivers/scsi which branch should I set up and work with,
next/stable/or is there any specific y2038 branch.
Any wiki link or documentation that explain this full process which
branch to work with when making changes to specific directory will be
useful.
Thanks,
Shirish
These series of patches try to convert parport device(ppdev) to
y2038 safe, and support y2038 safe and unsafe application at the
same time. There were some discussions in y2038 mailing list[1].
An y2038 safe application/kernel use 64bit time_t(aka time64_t)
to avoid 32-bit time types broken in the year 2038. Given that
some time relative struct(e.g. timeval in ppdev.c) is mainly the
offset of the real time, the old 32bit time_t in such application
is safe. We need to handle the 32bit time_t and 64bit time_t
application at the same time. My approach here is handle them as
different ioctl command for different size of timeval.
Build successful on arm64 and arm.
[1] https://lists.linaro.org/pipermail/y2038/
Bamvor Jian Zhang (2):
ppdev: convert to y2038 safe
ppdev: add support for compat ioctl
drivers/char/ppdev.c | 86 ++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 66 insertions(+), 20 deletions(-)
--
2.1.4
Here is the sixth version for converting parport device(ppdev) to
y2038 safe. The first four could found at [1][2][3][4][5].
An y2038 safe application/kernel use 64bit time_t(aka time64_t)
instead of 32bit time_t. Given that some time relative struct(e.g.
timeval in ppdev.c) is mainly the offset of the real time, the old
32bit time_t in such application is safe. We need to handle the
32bit time_t and 64bit time_t application at the same time.
My approach here is handle them as different ioctl command for
different size of timeval.
Build successful on arm64 and arm.
Changes since v5:
1. Replace PP[GS]ETTIME_safe/unsafe with PP[GS]ETTIME32/64.
2. Rewirte PPSETTIME ioctl with jiffies_to_timespec64 in order to
replace user fake HZ(TICK_USEC) to kernel HZ(TICK_NSEC).
3. define tv_sec as long and tv_usec as int in pp_set_timeout. It
should be enough for the timeout.
Change since v4:
1. change type of tv_sec and tv_usec to s64 in pp_set_timeout.
Use s64 could avoid s64 cast to s32 in arm 32bit.
Changes since V3:
1. create pp_set_timeout, pp_get_timeout to reduce the duplicated
code in my patch according to the suggestion of arnd.
I use div_u64_rem instead of jiffies_to_timespec64 because
it could save a divide operaion.
[1] https://lists.linaro.org/pipermail/y2038/2015-June/000522.html
[2] https://lists.linaro.org/pipermail/y2038/2015-June/000567.html
[3] https://lists.linaro.org/pipermail/y2038/2015-November/001093.html
[4] https://lists.linaro.org/pipermail/y2038/2015-November/001132.html
[5] https://lists.linaro.org/pipermail/y2038/2015-December/001201.html
Bamvor Jian Zhang (2):
ppdev: convert to y2038 safe
ppdev: add support for compat ioctl
drivers/char/ppdev.c | 86 ++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 66 insertions(+), 20 deletions(-)
--
2.1.4
This is the basic framework for the 64 bit time migration for filesystems.
There might be some changes or additions required as I start adapting to
filesystems.
This gives the basic high level concept so that we can start discussing.
Actual changes to vfs and other file systems will be in a separate
series.
Deepa Dinamani (4):
fs: vfs: add accessors for inode times
fs: Add new data type for inode times
fs: Add support for 64 bit time
fs: macros and functions support 64 bit time
include/linux/fs.h | 42 ++++++++++++++++++++++++++++++++-------
include/linux/stat.h | 12 +++++++++---
include/linux/time.h | 2 ++
include/linux/time64.h | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/time/time.c | 28 ++++++++++++++++++++++++++
5 files changed, 127 insertions(+), 10 deletions(-)
--
1.9.1
Here is the fifth version for converting parport device(ppdev) to
y2038 safe. The first four could found at [1], [2], [3], [4].
An y2038 safe application/kernel use 64bit time_t(aka time64_t)
instead of 32bit time_t. There are the 5 cases need to support:
summary |u:arch |u:tv_sec |k:arch |k:tv_sec
-------------------|-------|---------|-------|--------
32_y2038_unsafe |32 |32 |32 |32
32_y2038_safe |32 |64 |32 |64
compat_y2038_unsafe|32 |32 |64 |64
compat_y2038_safe |32 |64 |64 |64
64_y2038_safe |64 |64 |64 |64
notes:
1. xxx_y2038_safe/unsafe. 32 means app running on the 32bit
kernel. Compat means 32bit app running on 64bit kernel. 64
means 64bit app running on 64bit kernel.
2. 1.3.5 are the original one, we need keep the compatability.
2,4 is new one we need to support.
There are different ways to do this. Convert to 64bit time and/or
define COMPAT_USE_64BIT_TIME 0 or 1 to indicate y2038 safe or unsafe.
But it is not mean that we need to convert all the time relative
struct to 64bit. Because some time relative struct(e.g. timeval in
ppdev.c) is mainly the offset of the real time.
The main issue in ppdev.c is PPSETTIME/PPGETTIME which transfer
timeval between user space and kernel. My approach here is handle them
as different ioctl command.
Build successful on arm64 and arm.
Change since v4:
1. change type of tv_sec and tv_usec to s64 in pp_set_timeout.
Use s64 could avoid s64 cast to s32 in arm 32bit.
Changes since V3:
1. create pp_set_timeout, pp_get_timeout to reduce the duplicated
code in my patch according to the suggestion of arnd.
I use div_u64_rem instead of jiffies_to_timespec64 because
it could save a divide operaion.
[1] https://lists.linaro.org/pipermail/y2038/2015-June/000522.html
[2] https://lists.linaro.org/pipermail/y2038/2015-June/000567.html
[3] https://lists.linaro.org/pipermail/y2038/2015-November/001093.html
[4] https://lists.linaro.org/pipermail/y2038/2015-November/001132.html
Bamvor Jian Zhang (2):
ppdev: convert to y2038 safe
ppdev: add support for compat ioctl
drivers/char/ppdev.c | 92 ++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 72 insertions(+), 20 deletions(-)
--
2.1.4
On Friday 27 November 2015 18:00:29 WEN Pingbo wrote:
> To solve the y2038 problem in input_event, I had some attempts before [1],
> and this is the second one.
>
> We can force userspace to use monotonic time in event timestamp, so the
> 'struct timeval' is enough to keep y2038-safe, as Arnd suggested. But we
> can not find a way to make kernel compatible with old binaries, which use
> realtime, and there are still some devices, which depend on realtime.
>
> So I get a idea to add a new evdev interface, which is y2038 safe. And
> userspace can switch between the old and new interface via ioctl.
>
> The patch series add three evdev interface type:
>
> - EV_IF_LEGACY
> send event by input_event. This is the default option, keep kernel
> backward compatible.
The problem I see with this approach is that it still breaks any
legacy source code that is compiled with a new libc that uses 64-bit
time_t. If we are requiring source code changes for building users
of input devices with a new libc, we can easily get them to handle
the overflow (they normally only care about the microsecond portion
anyway, so it doesn't matter in most cases), or to use monotonic time.
Did I miss something here?
Arnd
