2020-02-04 15:02:43

by Al Viro

[permalink] [raw]
Subject: [put pull] timestamp stuff

More 64bit timestamp work

The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:

Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git imm.timestamp

for you to fetch changes up to f0f3588f7a95bb8e02b0f8f5138efb7064665730:

kernfs: don't bother with timestamp truncation (2019-12-08 19:10:57 -0500)

----------------------------------------------------------------
Al Viro (1):
kernfs: don't bother with timestamp truncation

Amir Goldstein (1):
utimes: Clamp the timestamps in notify_change()

Deepa Dinamani (6):
fs: fat: Eliminate timespec64_trunc() usage
fs: cifs: Delete usage of timespec64_trunc
fs: ceph: Delete timespec64_trunc() usage
fs: ubifs: Eliminate timespec64_trunc() usage
fs: Delete timespec64_trunc()
fs: Do not overload update_time

fs/attr.c | 23 +++++++++++------------
fs/ceph/mds_client.c | 4 +---
fs/cifs/inode.c | 13 +++++++------
fs/configfs/inode.c | 9 +++------
fs/f2fs/file.c | 18 ++++++------------
fs/fat/misc.c | 10 +++++++++-
fs/inode.c | 33 +++------------------------------
fs/kernfs/inode.c | 6 +++---
fs/ntfs/inode.c | 18 ++++++------------
fs/ubifs/file.c | 18 ++++++------------
fs/ubifs/sb.c | 11 ++++-------
fs/utimes.c | 4 ++--
include/linux/fs.h | 1 -
13 files changed, 61 insertions(+), 107 deletions(-)


2020-02-05 06:55:14

by Linus Torvalds

[permalink] [raw]
Subject: Re: [put pull] timestamp stuff

On Tue, Feb 4, 2020 at 3:00 PM Al Viro <[email protected]> wrote:
>
> More 64bit timestamp work

Heh. pr-tracker-bot is not replying to your pull request, because you
misspelled the subject line ("put pull").

But pr-tracker-bot _also_ isn't responding to the one where that
wasn't the case:

[git pull] kernel-initiated rm -rf on ramfs-style filesystems

and I'm not seeing why that one wasn't picked up. But it seems to be
because it never made it to lore.

I see

To: Linus Torvalds <[email protected]>
Cc: [email protected], [email protected]
Subject: [git pull] kernel-initiated rm -rf on ramfs-style filesystems
Message-ID: <[email protected]>

on that other message in my mailbox, but I don't see it on lore. Odd.
Is it because the "fsdevel" address is mis-spelled on the Cc line?
Strange.

Anyway, both pull requests pulled, even though neither got a
pr-tracker-bot response for two apparently very different reasons.

Linus

2020-02-05 16:09:48

by Konstantin Ryabitsev

[permalink] [raw]
Subject: Re: [put pull] timestamp stuff

On Wed, Feb 05, 2020 at 06:53:07AM +0000, Linus Torvalds wrote:
> But pr-tracker-bot _also_ isn't responding to the one where that
> wasn't the case:
>
> [git pull] kernel-initiated rm -rf on ramfs-style filesystems
>
> and I'm not seeing why that one wasn't picked up. But it seems to be
> because it never made it to lore.
>
> I see
>
> To: Linus Torvalds <[email protected]>
> Cc: [email protected], [email protected]
> Subject: [git pull] kernel-initiated rm -rf on ramfs-style filesystems
> Message-ID: <[email protected]>
>
> on that other message in my mailbox, but I don't see it on lore. Odd.
> Is it because the "fsdevel" address is mis-spelled on the Cc line?
> Strange.

That message-id doesn't appear to have traversed the mail system, so my
guess would be that it didn't make it past some upstream MTA -- either
vger or the one before it. The fact that this messages is not on
lkml.org either seems to confirm that theory.

Best,
-K

2020-02-05 16:26:32

by Al Viro

[permalink] [raw]
Subject: Re: [put pull] timestamp stuff

On Wed, Feb 05, 2020 at 11:08:01AM -0500, Konstantin Ryabitsev wrote:

> > To: Linus Torvalds <[email protected]>
> > Cc: [email protected], [email protected]
> > Subject: [git pull] kernel-initiated rm -rf on ramfs-style filesystems
> > Message-ID: <[email protected]>
> >
> > on that other message in my mailbox, but I don't see it on lore. Odd.
> > Is it because the "fsdevel" address is mis-spelled on the Cc line?
> > Strange.
>
> That message-id doesn't appear to have traversed the mail system, so my
> guess would be that it didn't make it past some upstream MTA -- either
> vger or the one before it. The fact that this messages is not on
> lkml.org either seems to confirm that theory.

At a guess, bogus address in Cc (mistyped mutt alias - "fsdevel" would've
become "[email protected]", "fsdevel." got interpreted as
local address) got something spooked enough to filter it out...