> On Mon, Oct 12, 2020 at 5:36 AM Christian Eggers wrote:
> > v2:
> > -
> > - integrated proposal from Willem de Bruijn
> > - added Reviewed-by: from Willem and Deepa
You may add my
Acked-by: Deepa Dinamani
-Deepa
th SO_TIMESTAMP(NS) and
> SO_TIMESTAMPING that can be independently turned on and off, disabling
> one can incorrectly switch modes while the other is still active.
This will not help the case when a child process that inherits the fd
and then sets SO_TIMESTAMP*_OLD/NEW on it, while the parent us
On Fri, Oct 9, 2020 at 5:43 PM Willem de Bruijn wrote:
>
> On Fri, Oct 9, 2020 at 8:30 PM Deepa Dinamani wrote:
> >
> > On Fri, Oct 9, 2020 at 3:32 AM Christian Eggers wrote:
> > >
> > > The comparison of optname with SO_TIMESTAMPING_NEW is wrong way around,
On Fri, Oct 9, 2020 at 3:32 AM Christian Eggers wrote:
>
> The comparison of optname with SO_TIMESTAMPING_NEW is wrong way around,
> so SOCK_TSTAMP_NEW will first be set and than reset again. Additionally
> move it out of the test for SOF_TIMESTAMPING_RX_SOFTWARE as this seems
> unrelated.
The
Thanks for the fix.
Would it be better to move the check and warning to a place where the
access is still safe?
-Deepa
> On Oct 9, 2019, at 12:19 AM, Eric Biggers wrote:
>
> From: Eric Biggers
On Wed, Oct 9, 2019 at 12:19 AM Eric Biggers wrote:
>
> From: Eric Biggers
>
> After
at
https://lore.kernel.org/lkml/1567523922.5576.57.ca...@lca.pw/.
I can post a separate follow-up patch after the conclusion.
Reported-by: Qian Cai
Signed-off-by: Deepa Dinamani
---
fs/ext4/ext4.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> On Sep 4, 2019, at 5:58 AM, Theodore Y. Ts'o wrote:
>
>> On Tue, Sep 03, 2019 at 09:50:09PM -0700, Deepa Dinamani wrote:
>> If we don't care to warn about the timestamps that are clamped in
>> memory, maybe we could just warn when they are being written out.
>> Wou
If we don't care to warn about the timestamps that are clamped in
memory, maybe we could just warn when they are being written out.
Would something like this be more acceptable? I would also remove the
warning in ext4.h. I think we don't have to check if the inode is 128
bytes here (Please correct
> > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> > index 9e3ae3be3de9..5a971d1b6d5e 100644
> > --- a/fs/ext4/ext4.h
> > +++ b/fs/ext4/ext4.h
> > @@ -835,7 +835,9 @@ do {
> > \
> > }
> > \
> > else{\
> >
On Tue, Sep 3, 2019 at 2:18 PM Theodore Y. Ts'o wrote:
>
> On Tue, Sep 03, 2019 at 09:18:44AM -0700, Deepa Dinamani wrote:
> >
> > This prints a warning for each inode that doesn't extend limits beyond
> > 2038. It is rate limited by the ext4_warning_inode().
> >
We might also want to consider updating the file system the LTP is
being run on here.
-Deepa
Actually this warning is coming from this patch:
https://lore.kernel.org/linux-fsdevel/20190818165817.32634-10-deepa.ker...@gmail.com/
([PATCH v8 09/20] ext4: Initialize timestamps limits).
This is the code generating the warning:
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index
().
Signed-off-by: Deepa Dinamani
---
This depends on the following patch in Arnd's y2038 tree:
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground y2038
188d20bcd1eb ("vfs: Add file timestamp range support")
fs/adfs/adfs.h | 13 +
fs/adfs/inode.c | 8 ---
)
Deepa Dinamani (19):
vfs: Add file timestamp range support
vfs: Add timestamp_truncate() api
timestamp_truncate: Replace users of timespec64_trunc
mount: Add mount warning for impending timestamp expiry
utimes
On Tue, Aug 20, 2019 at 12:20 AM Kees Cook wrote:
>
> On Sun, Aug 18, 2019 at 09:58:16AM -0700, Deepa Dinamani wrote:
> > Leaving granularity at 1ns because it is dependent on the specific
> > attached backing pstore module. ramoops has microsecond resolution.
> >
> &g
On Tue, Aug 20, 2019 at 9:28 AM Matthew Wilcox wrote:
>
> On Sun, Aug 18, 2019 at 09:58:05AM -0700, Deepa Dinamani wrote:
> > Note that the min timestamp is assumed to be
> > 01 Jan 1970 00:00:00 (Unix epoch). This is consistent
> > with the way we convert timestamp
is retained as S64_MAX.
This is because that is the upper bound supported by vfs.
Signed-off-by: Deepa Dinamani
Cc: eri...@gmail.com
Cc: lu...@ionkov.net
Cc: asmad...@codewreck.org
Cc: v9fs-develo...@lists.sourceforge.net
---
fs/9p/vfs_super.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion
struct nfstime3 {
uint32 seconds;
uint32 nseconds;
};
Use the limits as per the RFC.
Signed-off-by: Deepa Dinamani
Cc: trond.mykleb...@hammerspace.com
Cc: anna.schuma...@netapp.com
Cc: linux-...@vger.kernel.org
---
fs/nfs/super.c | 20 +++-
1 file
/openspecs/windows_protocols/ms-cifs/d416ff7c-c536-406e-a951-4f04b2fd1d2b
Signed-off-by: Deepa Dinamani
Cc: sfre...@samba.org
Cc: linux-c...@vger.kernel.org
---
fs/cifs/cifsfs.c | 22 ++
fs/cifs/netmisc.c | 14 +++---
2 files changed, 29 insertions(+), 7 deletions(-)
diff
Fill in the appropriate limits to avoid inconsistencies
in the vfs cached inode times when timestamps are
outside the permitted range.
Also fix timestamp calculation to avoid overflow
while converting from days to seconds.
Signed-off-by: Deepa Dinamani
Acked-by: David Sterba
Cc: dste
-by: Deepa Dinamani
Reviewed-by: Andreas Dilger
Cc: ty...@mit.edu
Cc: adilger.ker...@dilger.ca
Cc: linux-e...@vger.kernel.org
---
fs/ext4/ext4.h | 10 +-
fs/ext4/super.c | 17 +++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
pression e;
@@
inode->i_xtime =
- timespec64_trunc(
+ timestamp_truncate(
...,
- e);
+ inode);
Signed-off-by: Deepa Dinamani
Cc: adrian.hun...@intel.com
Cc: dedeki...@gmail.com
Cc: gre...@linuxfoundation.org
Cc: h...@lst.de
Cc: jaeg...@kernel.org
Cc: jl...@evilplan.org
Cc: rich...@nod.at
Cc: t.
Read and write to the 'compressed' flag of pstore").
Signed-off-by: Deepa Dinamani
Acked-by: Kees Cook
Cc: an...@enomsg.org
Cc: ccr...@android.com
Cc: keesc...@chromium.org
Cc: tony.l...@intel.com
---
fs/pstore/ram.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/pstore/ram.c b/fs/ps
we support the full range of years that can be represented, up to 2107.
Signed-off-by: Deepa Dinamani
Cc: hirof...@mail.parknet.co.jp
---
fs/fat/inode.c | 12
1 file changed, 12 insertions(+)
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 0bc2abc5d453..f27f84e2103f 100644
--- a/fs/f
Fill in the appropriate limits to avoid inconsistencies
in the vfs cached inode times when timestamps are
outside the permitted range.
Also change the local_to_gmt() to use time64_t instead
of time32_t.
Signed-off-by: Deepa Dinamani
Cc: miku...@artax.karlin.mff.cuni.cz
---
fs/hpfs/hpfs_fn.h
Fill in the appropriate limits to avoid inconsistencies
in the vfs cached inode times when timestamps are
outside the permitted range.
Signed-off-by: Deepa Dinamani
Cc: h...@infradead.org
---
fs/sysv/super.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/sysv/super.c
n/orangefs
Author: Neill Miller
Date: Thu Sep 2 15:00:38 2004 +
Signed-off-by: Deepa Dinamani
Cc: hub...@omnibond.com
Cc: mar...@omnibond.com
Cc: de...@lists.orangefs.org
---
fs/orangefs/super.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/orangefs/super.c b/fs/orangefs/sup
Fill in the appropriate limits to avoid inconsistencies
in the vfs cached inode times when timestamps are
outside the permitted range.
Signed-off-by: Deepa Dinamani
Acked-by: Bob Copeland
Cc: m...@bobcopeland.com
Cc: linux-karma-de...@lists.sourceforge.net
---
fs/omfs/inode.c | 4
1 file
Fill in the appropriate limits to avoid inconsistencies
in the vfs cached inode times when timestamps are
outside the permitted range.
Reference: http://www.ecma-international.org/publications/standards/Ecma-119.htm
Signed-off-by: Deepa Dinamani
---
fs/isofs/inode.c | 7 +++
1 file changed
.
Signed-off-by: Deepa Dinamani
Cc: z...@redhat.com
Cc: s...@redhat.com
Cc: idryo...@gmail.com
Cc: ceph-de...@vger.kernel.org
---
fs/ceph/super.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ceph/super.c b/fs/ceph/super.c
index 4406ec7018bb..2aa052b7bda7 100644
--- a/fs/ceph/super.c
+++ b
().
Signed-off-by: Deepa Dinamani
---
fs/adfs/adfs.h | 13 +
fs/adfs/inode.c | 8 ++--
fs/adfs/super.c | 2 ++
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/fs/adfs/adfs.h b/fs/adfs/adfs.h
index b7e844d2f321..dca8b23aa43f 100644
--- a/fs/adfs/adfs.h
+++ b/fs/adfs
to accommodate filesystem
timestamp clamping according to flesystem limits.
Note that the tv_nsec part is set to 0 if tv_sec is not within
the range supported for the filesystem.
Signed-off-by: Deepa Dinamani
---
fs/inode.c | 33 -
include/linux/fs.h | 2 ++
2
://pubs.opengroup.org/onlinepubs/009695399/functions/utimes.html
Signed-off-by: Deepa Dinamani
---
fs/utimes.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/utimes.c b/fs/utimes.c
index 350c9c16ace1..1ba3f7883870 100644
--- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -36,16 +36,14 @@ static
ies.
Given that the rtc_tm is not compiled on all architectures, this is not a
trivial patch. This can be added in the future.
Signed-off-by: Deepa Dinamani
---
fs/namespace.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/fs/namesp
to always support the
min and max allowable values for the fields.
Signed-off-by: Deepa Dinamani
---
fs/super.c | 2 ++
include/linux/fs.h | 3 +++
include/linux/time64.h | 2 ++
3 files changed, 7 insertions(+)
diff --git a/fs/super.c b/fs/super.c
index 36cb5aaf6f08..620c1911bb36
On Fri, Aug 2, 2019 at 12:15 AM Arnd Bergmann wrote:
>
> On Fri, Aug 2, 2019 at 4:26 AM Deepa Dinamani wrote:
> >
> > On Tue, Jul 30, 2019 at 12:36 AM Arnd Bergmann wrote:
> > >
> > > On Tue, Jul 30, 2019 at 6:31 AM Kees Cook wrote:
> > > >
On Mon, Aug 12, 2019 at 9:09 AM Deepa Dinamani wrote:
>
> On Mon, Aug 12, 2019 at 7:11 AM Arnd Bergmann wrote:
> >
> > On Mon, Aug 12, 2019 at 3:25 PM Ben Hutchings
> > wrote:
> > > On Sat, 2019-08-10 at 13:44 -0700, Deepa Dinamani wrote:
> > > >
On Mon, Aug 12, 2019 at 7:11 AM Arnd Bergmann wrote:
>
> On Mon, Aug 12, 2019 at 3:25 PM Ben Hutchings
> wrote:
> > On Sat, 2019-08-10 at 13:44 -0700, Deepa Dinamani wrote:
> > > On Mon, Aug 5, 2019 at 7:14 AM Ben Hutchings
> > > wrote:
> > > > On M
> This doesn't seem like a helpful way to log the time. Maybe use
> time64_to_tm() to convert to "broken down" time and then print it with
> "%ptR"... but that wants struct rtc_time. If you apply the attached
> patch, however, you should then be able to print struct tm with
> "%ptT".
OK. Will
On Mon, Aug 5, 2019 at 7:14 AM Ben Hutchings
wrote:
>
> On Mon, 2019-07-29 at 18:49 -0700, Deepa Dinamani wrote:
> > The warning reuses the uptime max of 30 years used by the
> > setitimeofday().
> >
> > Note that the warning is only added for new filesystem mounts
On Mon, Aug 5, 2019 at 6:30 AM Ben Hutchings
wrote:
>
> On Mon, 2019-07-29 at 18:49 -0700, Deepa Dinamani wrote:
> > POSIX is ambiguous on the behavior of timestamps for
> > futimens, utimensat and utimes. Whether to return an
> > error or silently clamp a timestamp beyond
> Rather than printing a warning at mount time (which may be confusing
> to users for a problem they may never see), it makes sense to only
> print such a warning in the vanishingly small case that someone actually
> tries to modify the inode timestamp but it doesn't fit, rather than on
> the
On Tue, Jul 30, 2019 at 12:36 AM Arnd Bergmann wrote:
>
> On Tue, Jul 30, 2019 at 6:31 AM Kees Cook wrote:
> >
> > On Mon, Jul 29, 2019 at 06:49:23PM -0700, Deepa Dinamani wrote:
> > > Also update the gran since pstore has microsecond granularity.
> >
> >
On Wed, Jul 31, 2019 at 8:26 AM Darrick J. Wong wrote:
>
> On Mon, Jul 29, 2019 at 06:49:13PM -0700, Deepa Dinamani wrote:
> > ext4 has different overflow limits for max filesystem
> > timestamps based on the extra bytes available.
> >
> > The timestamp l
On Wed, Jul 31, 2019 at 8:15 AM Darrick J. Wong wrote:
>
> On Mon, Jul 29, 2019 at 06:49:09PM -0700, Deepa Dinamani wrote:
> > POSIX is ambiguous on the behavior of timestamps for
> > futimens, utimensat and utimes. Whether to return an
> > error or silently clamp a ti
On Tue, Jul 30, 2019 at 2:31 AM OGAWA Hirofumi
wrote:
>
> Deepa Dinamani writes:
>
> > +/* DOS dates from 1980/1/1 through 2107/12/31 */
> > +#define FAT_DATE_MIN (0<<9 | 1<<5 | 1)
> > +#define FAT_DATE_MAX (127<<9 | 12<<5 |
On Tue, Jul 30, 2019 at 1:27 AM OGAWA Hirofumi
wrote:
>
> Deepa Dinamani writes:
>
> > diff --git a/fs/fat/misc.c b/fs/fat/misc.c
> > index 1e08bd54c5fb..53bb7c6bf993 100644
> > --- a/fs/fat/misc.c
> > +++ b/fs/fat/misc.c
> > @@ -307,8 +307,9 @@ int fat_tr
n/orangefs
Author: Neill Miller
Date: Thu Sep 2 15:00:38 2004 +
Signed-off-by: Deepa Dinamani
Cc: hub...@omnibond.com
Cc: mar...@omnibond.com
Cc: de...@lists.orangefs.org
---
fs/orangefs/super.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/orangefs/super.c b/fs/orangefs/sup
.
Signed-off-by: Deepa Dinamani
Cc: z...@redhat.com
Cc: s...@redhat.com
Cc: idryo...@gmail.com
Cc: ceph-de...@vger.kernel.org
---
fs/ceph/super.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ceph/super.c b/fs/ceph/super.c
index d57fa60dcd43..6cf3a4fceac1 100644
--- a/fs/ceph/super.c
+++ b
Fill in the appropriate limits to avoid inconsistencies
in the vfs cached inode times when timestamps are
outside the permitted range.
Signed-off-by: Deepa Dinamani
Cc: m...@bobcopeland.com
Cc: linux-karma-de...@lists.sourceforge.net
---
fs/omfs/inode.c | 4
1 file changed, 4 insertions
Fill in the appropriate limits to avoid inconsistencies
in the vfs cached inode times when timestamps are
outside the permitted range.
Also change the local_to_gmt() to use time64_t instead
of time32_t.
Signed-off-by: Deepa Dinamani
Cc: miku...@artax.karlin.mff.cuni.cz
---
fs/hpfs/hpfs_fn.h
Fill in the appropriate limits to avoid inconsistencies
in the vfs cached inode times when timestamps are
outside the permitted range.
Also fix timestamp calculation to avoid overflow
while converting from days to seconds.
Signed-off-by: Deepa Dinamani
Cc: dste...@suse.com
---
fs/affs
is retained as S64_MAX.
This is because that is the upper bound supported by vfs.
Signed-off-by: Deepa Dinamani
Cc: eri...@gmail.com
Cc: lu...@ionkov.net
Cc: asmad...@codewreck.org
Cc: v9fs-develo...@lists.sourceforge.net
---
fs/9p/vfs_super.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion
Also update the gran since pstore has microsecond granularity.
Signed-off-by: Deepa Dinamani
Cc: an...@enomsg.org
Cc: ccr...@android.com
Cc: keesc...@chromium.org
Cc: tony.l...@intel.com
---
fs/pstore/inode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/pstore
/openspecs/windows_protocols/ms-cifs/d416ff7c-c536-406e-a951-4f04b2fd1d2b
Signed-off-by: Deepa Dinamani
Cc: sfre...@samba.org
Cc: linux-c...@vger.kernel.org
---
fs/cifs/cifsfs.c | 22 ++
fs/cifs/netmisc.c | 14 +++---
2 files changed, 29 insertions(+), 7 deletions(-)
diff
Fill in the appropriate limits to avoid inconsistencies
in the vfs cached inode times when timestamps are
outside the permitted range.
Reference: http://www.ecma-international.org/publications/standards/Ecma-119.htm
Signed-off-by: Deepa Dinamani
---
fs/isofs/inode.c | 7 +++
1 file changed
().
Signed-off-by: Deepa Dinamani
---
fs/adfs/adfs.h | 13 +
fs/adfs/inode.c | 8 ++--
fs/adfs/super.c | 2 ++
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/fs/adfs/adfs.h b/fs/adfs/adfs.h
index 804c6a77c5db..781b1c3817e0 100644
--- a/fs/adfs/adfs.h
+++ b/fs/adfs
The warning reuses the uptime max of 30 years used by the
setitimeofday().
Note that the warning is only added for new filesystem mounts
through the mount syscall. Automounts do not have the same warning.
Signed-off-by: Deepa Dinamani
---
fs/namespace.c | 11 +++
1 file changed, 11
0x28000..0x2 0x3 2310-04-04..2378-04-22
* 1 100x3..0x37fff 0x3 2378-04-22..2446-05-10
Note that the time limits are not correct for deletion times.
Signed-off-by: Deepa Dinamani
Reviewed-by: Andreas Dilger
Cc: ty...@mit.edu
Cc: adilger.ker
://pubs.opengroup.org/onlinepubs/009695399/functions/utimes.html
Signed-off-by: Deepa Dinamani
---
fs/utimes.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/fs/utimes.c b/fs/utimes.c
index 350c9c16ace1..4c1a2ce90bbc 100644
--- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -21,6
struct nfstime3 {
uint32 seconds;
uint32 nseconds;
};
Use the limits as per the RFC.
Signed-off-by: Deepa Dinamani
Cc: trond.mykleb...@hammerspace.com
Cc: anna.schuma...@netapp.com
Cc: linux-...@vger.kernel.org
---
fs/nfs/super.c | 20 +++-
1 file
Fill in the appropriate limits to avoid inconsistencies
in the vfs cached inode times when timestamps are
outside the permitted range.
Signed-off-by: Deepa Dinamani
Cc: h...@infradead.org
---
fs/sysv/super.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/sysv/super.c
to always support the
min and max allowable values for the fields.
Signed-off-by: Deepa Dinamani
---
fs/super.c | 2 ++
include/linux/fs.h | 3 +++
include/linux/time64.h | 2 ++
3 files changed, 7 insertions(+)
diff --git a/fs/super.c b/fs/super.c
index 2739f57515f8..e5835c38d336
we support the full range of years that can be represented, up to 2107.
Signed-off-by: Deepa Dinamani
Cc: hirof...@mail.parknet.co.jp
---
fs/fat/inode.c | 12
1 file changed, 12 insertions(+)
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 05689198f5af..5f04c5c810fb 100644
--- a/fs/f
:
* No change in mount behavior because of expiry of timestamps.
* Included limits for more filesystems.
Deepa Dinamani (20):
vfs: Add file timestamp range support
vfs: Add timestamp_truncate() api
timestamp_truncate: Replace users of timespec64_trunc
mount: Add mount warning for impending timestamp
to accommodate filesystem
timestamp clamping according to flesystem limits.
Note that the tv_nsec part is set to 0 if tv_sec is not within
the range supported for the filesystem.
Signed-off-by: Deepa Dinamani
---
fs/inode.c | 33 -
include/linux/fs.h | 2 ++
2
sed instead of signal_pending() check, and
> > update the callers.
> >
> > Reported-by: Eric Wong
> > Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add
> > restore_user_sigmask()")
> > cc: sta...@vger.kernel.org (v5.0+)
> > Signed-of
On Thu, May 30, 2019 at 8:48 AM Deepa Dinamani wrote:
>
> > On May 30, 2019, at 8:38 AM, Eric W. Biederman
> > wrote:
> >
> > ebied...@xmission.com (Eric W. Biederman) writes:
> >
> >> Which means I believe we have a semantically valid change in
> On May 30, 2019, at 8:38 AM, Eric W. Biederman wrote:
>
> ebied...@xmission.com (Eric W. Biederman) writes:
>
>> Which means I believe we have a semantically valid change in behavior
>> that is causing a regression.
>
> I haven't made a survey of all of the functions yet but
> fucntions return
On Wed, May 29, 2019 at 9:57 AM Oleg Nesterov wrote:
>
> On 05/28, Deepa Dinamani wrote:
> >
> > I agree that signal handller being called and return value not being
> > altered is an issue with other syscalls also. I was just wondering if
> > some userspace cod
On Wed, May 29, 2019 at 9:12 AM Oleg Nesterov wrote:
>
> Al, Linus, Eric, please help.
>
> The previous discussion was very confusing, we simply can not understand each
> other.
>
> To me everything looks very simple and clear, but perhaps I missed something
> obvious? Please correct me.
>
> I
Resending due to inadvertent conversion of prior message to html.
On Wed, May 29, 2019 at 9:12 AM Oleg Nesterov wrote:
> Al, Linus, Eric, please help.
>
> The previous discussion was very confusing, we simply can not understand each
> other.
>
> To me everything looks very simple and clear, but
On Mon, May 27, 2019 at 8:04 AM Oleg Nesterov wrote:
>
> Deepa,
>
> it seems that we both are saying the same things again and again, and we
> simply can't understand each other.
Oleg, I'm sorry for the confusion. Maybe I should point out what I
agree with also.
I agree that signal handller
> On May 28, 2019, at 2:12 AM, David Laight wrote:
>
> From: Deepa Dinamani
>> Sent: 24 May 2019 18:02
> ...
>> Look at the code before 854a6ed56839a:
>>
>> /*
>> * If we changed the signal mask, we need to restore the original one.
>>
On Fri, May 24, 2019 at 9:33 AM Oleg Nesterov wrote:
>
> On 05/24, Deepa Dinamani wrote:
> >
> > On Fri, May 24, 2019 at 7:11 AM Oleg Nesterov wrote:
> > >
> > > On 05/23, Deepa Dinamani wrote:
> > > >
> > > > Ok, since there has
On Fri, May 24, 2019 at 7:11 AM Oleg Nesterov wrote:
>
> On 05/23, Deepa Dinamani wrote:
> >
> > Ok, since there has been quite a bit of argument here, I will
> > backtrack a little bit and maybe it will help us understand what's
> > happening here.
> > Ther
:
>
> On 05/23, Deepa Dinamani wrote:
> >
> > 1. block the signals you don't care about.
> > 2. syscall()
> > 3. unblock the signals blocked in 1.
>
> and even this part of your email is very confusing. because in this case
> we can never miss a signal. I'd say
>
> Just adding a little more clarification, there is an additional change
> between [a] and [b].
> As per [a] we would just restore the signal instead of changing the
> saved_sigmask and the signal could get delivered right then. [b]
> changes this to happen at syscall exit:
Rewording above, as
On Thu, May 23, 2019 at 11:06 AM Deepa Dinamani wrote:
>
> Ok, since there has been quite a bit of argument here, I will
> backtrack a little bit and maybe it will help us understand what's
> happening here.
> There are many scenarios being discussed on this thread:
> a. St
Ok, since there has been quite a bit of argument here, I will
backtrack a little bit and maybe it will help us understand what's
happening here.
There are many scenarios being discussed on this thread:
a. State of code before 854a6ed56839a
b. State after 854a6ed56839a
c. Proposed fix as per the
On Wed, May 22, 2019 at 3:18 PM Chris Down wrote:
>
> +Cc: linux-mm, since this broke mmots tree and has been applied there
>
> This patch is missing a definition for signal_detected in io_cqring_wait,
> which
> breaks the build.
This patch does not break the build.
The patch the breaks the
On Wed, May 22, 2019 at 9:14 AM Oleg Nesterov wrote:
>
> On 05/22, Deepa Dinamani wrote:
> >
> > -Deepa
> >
> > > On May 22, 2019, at 8:05 AM, Oleg Nesterov wrote:
> > >
> > >> On 05/21, Deepa Dinamani wrote:
> > >>
> > &
-Deepa
> On May 22, 2019, at 8:05 AM, Oleg Nesterov wrote:
>
>> On 05/21, Deepa Dinamani wrote:
>>
>> Note that this patch returns interrupted errors (EINTR, ERESTARTNOHAND,
>> etc) only when there is no other error. If there is a signal and an error
>> like
ors (EINTR, ERESTARTNOHAND,
etc) only when there is no other error. If there is a signal and an error
like EINVAL, the syscalls return -EINVAL rather than the interrupted
error codes.
Reported-by: Eric Wong
Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add
restore_user_sigmask()")
ors (EINTR, ERESTARTNOHAND,
etc) only when there is no other error. If there is a signal and an error
like EINVAL, the syscalls return -EINVAL rather than the interrupted
error codes.
Reported-by: Eric Wong
Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add
restore_user_sigmask()")
On Tue, May 21, 2019 at 5:35 PM Deepa Dinamani wrote:
>
> > > > It's been 2 weeks and this fix hasn't appeared in mmots / mmotm.
> > > > I also noticed it's missing Cc: for stable@ (below)
> > >
> > > Why is a -stable backport needed? I
> > > It's been 2 weeks and this fix hasn't appeared in mmots / mmotm.
> > > I also noticed it's missing Cc: for stable@ (below)
> >
> > Why is a -stable backport needed? I see some talk above about lost
> > signals but it is unclear whether these are being observed after fixing
> > the
will
follow up with a separate patch for that.
Reported-by: Eric Wong
Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add
restore_user_sigmask()")
Signed-off-by: Deepa Dinamani
Reviewed-by: Davidlohr Bueso
---
fs/aio.c | 24
fs/e
uld be a bit more verbose about the return
> semantics
> of restore_user_sigmask()... see at the end.
>
> >
> >Reported-by: Eric Wong
> >Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add
> >restore_user_sigmask()")
> >Signed-off-by: Deepa Dinamani
> >
On Thu, May 2, 2019 at 11:34 PM Eric Wong wrote:
>
> Deepa Dinamani wrote:
> > Sorry, I was trying a new setup at work. I should have tested it.
> > My bad, I've checked this one.
>
> Thanks. This is good w.r.t. epoll_pwait and ppoll when applied
> to 5.0.11 (no
,
etc) only when there is no other error. If there is a signal and an error
like EINVAL, the syscalls return -EINVAL rather than the interrupted
error codes.
Reported-by: Eric Wong
Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add
restore_user_sigmask()")
Signed-off-by: Deep
VAL, the syscalls return -EINVAL rather than the interrupted error codes.
Reported-by: Omar Kilani
Reported-by: Eric Wong
Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add
restore_user_sigmask()")
Signed-off-by: Deepa Dinamani
---
fs/aio.c | 24 ---
On Wed, May 1, 2019 at 1:48 PM Eric Wong wrote:
>
> Deepa Dinamani wrote:
> > So here is my analysis:
>
>
>
> > So the 854a6ed56839a40f6 seems to be better than the original code in
> > that it detects the signal.
>
> OTOH, does matter to anybody that a si
Thanks for trying the fix.
So here is my analysis:
Let's start with epoll_pwait:
ep_poll() is what checks for signal_pending() and is responsible for
setting errno to -EINTR when there is a signal.
So if a signal is received after ep_poll(), it is never noticed by the
syscall during execution.
I was also not able to reproduce this.
Arnd and I were talking about this today morning. Here is something
Arnd noticed:
If there was a signal after do_epoll_wait(), we never were not
entering the if (err = -EINTR) at all before. But, now we do.
We could try with the below patch:
diff --git
I tried to replicate the failure on qemu.
I do not see the failure with N=32.
Does it work for N < 32?
Does any other signal work?
Are there any other architectures that fail?
Could you help me figure out how to run just the one test that is failing?
-Deepa
On Tue, Feb 26, 2019 at 11:52 PM Xiongfeng Wang
wrote:
>
> When I ran Syzkaller testsuite, I got the following call trace.
>
> UBSAN: Undefined behaviour in ./include/linux/time64.h:120:27
> signed integer overflow:
On Tue, Feb 26, 2019 at 6:07 PM Xiongfeng Wang
wrote:
>
> When I ran Syzkaller testsuite, I got the following call trace.
>
> UBSAN: Undefined behaviour in ./include/linux/time64.h:120:27
> signed integer overflow:
>
On Mon, Feb 25, 2019 at 1:02 AM Arnd Bergmann wrote:
>
> On Mon, Feb 25, 2019 at 5:53 AM Deepa Dinamani wrote:
> >
> > On Sun, Feb 24, 2019 at 7:13 PM Hongbo Yao wrote:
On Sun, Feb 24, 2019 at 7:13 PM Hongbo Yao wrote:
>
> I ran into this:
>
> =
> UBSAN: Undefined behaviour in ./include/linux/time64.h:70:2
> signed integer overflow:
> 1551059291 +
1 - 100 of 1238 matches
Mail list logo
