From: Jan Kara <jack@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jan Kara <jack@suse.cz>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2] fat: Provide option for setting timezone offset
Date: Wed, 14 Nov 2012 02:04:02 +0100 [thread overview]
Message-ID: <20121114010402.GA30196@quack.suse.cz> (raw)
In-Reply-To: <20121113154022.4bd68ecd.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]
On Tue 13-11-12 15:40:22, Andrew Morton wrote:
> On Mon, 12 Nov 2012 23:27:28 +0100
> Jan Kara <jack@suse.cz> wrote:
>
> > So far FAT either offsets time stamps by sys_tz.minuteswest or leaves them
> > as they are (when tz=UTC mount option is used). However in some cases it
> > is useful if one can specify time stamp offset on his own (e.g. when time
> > zone of the camera connected is different from time zone of the computer,
> > or when HW clock is in UTC and thus sys_tz.minuteswest == 0).
> >
> > So provide a mount option time_offset= which allows user to specify offset in
> > minutes that should be applied to time stamps on the filesystem.
>
>
> Did you test "mount -o remount"?
>
> I suspect it won't work correctly - inodes which are already in
> cache at remount time will not reflect the updated offset?
>
> If so, a quick fix would be to disallow the ability to set time_offset
> via remount (dunno how?) and document it.
fat_remount() is actually:
static int fat_remount(struct super_block *sb, int *flags, char *data)
{
struct msdos_sb_info *sbi = MSDOS_SB(sb);
*flags |= MS_NODIRATIME | (sbi->options.isvfat ? 0 : MS_NOATIME);
return 0;
}
so all option changes are just ignored on remount. But I admit I checked
only now ;) So thanks for asking.
> > ...
> >
> > @@ -1005,8 +1011,17 @@ static int parse_options(struct super_block *sb, char *options, int is_vfat,
> > case Opt_flush:
> > opts->flush = 1;
> > break;
> > + case Opt_time_offset:
> > + if (match_int(&args[0], &option))
> > + return 0;
> > + if (option < -12 * 60 || option > 12 * 60)
> > + return 0;
>
> Is it correct to return 0 here? 0 means "success"?
Right. I just copied it from other options without checking. Apparently
they are all wrong but logic in match_token() catches most of the faults so
noone noticed. So something like the attached patch?
>
> > + opts->tz_set = 1;
> > + opts->time_offset = option;
> > + break;
> > case Opt_tz_utc:
> > - opts->tz_utc = 1;
> > + opts->tz_set = 1;
> > + opts->time_offset = 0;
> > break;
> > case Opt_err_cont:
> > opts->errors = FAT_ERRORS_CONT;
> >
> > ...
> >
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
[-- Attachment #2: 0001-fat-Fix-mount-option-parsing.patch --]
[-- Type: text/x-patch, Size: 2376 bytes --]
>From b1fb4805fc0a40ee924fbdbd1e4e1ea37f2e7456 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Wed, 14 Nov 2012 01:57:03 +0100
Subject: [PATCH] fat: Fix mount option parsing
parse_options() is supposed to return value < 0 on error however we returned 0
(success) in a lot of cases. This actually was not a problem in practice
because match_token() used by parse_options() is clever and catches most of the
problems for us.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/fat/inode.c | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index e3ef664..030bb1e 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -971,41 +971,41 @@ static int parse_options(struct super_block *sb, char *options, int is_vfat,
break;
case Opt_uid:
if (match_int(&args[0], &option))
- return 0;
+ return -EINVAL;
opts->fs_uid = make_kuid(current_user_ns(), option);
if (!uid_valid(opts->fs_uid))
- return 0;
+ return -EINVAL;
break;
case Opt_gid:
if (match_int(&args[0], &option))
- return 0;
+ return -EINVAL;
opts->fs_gid = make_kgid(current_user_ns(), option);
if (!gid_valid(opts->fs_gid))
- return 0;
+ return -EINVAL;
break;
case Opt_umask:
if (match_octal(&args[0], &option))
- return 0;
+ return -EINVAL;
opts->fs_fmask = opts->fs_dmask = option;
break;
case Opt_dmask:
if (match_octal(&args[0], &option))
- return 0;
+ return -EINVAL;
opts->fs_dmask = option;
break;
case Opt_fmask:
if (match_octal(&args[0], &option))
- return 0;
+ return -EINVAL;
opts->fs_fmask = option;
break;
case Opt_allow_utime:
if (match_octal(&args[0], &option))
- return 0;
+ return -EINVAL;
opts->allow_utime = option & (S_IWGRP | S_IWOTH);
break;
case Opt_codepage:
if (match_int(&args[0], &option))
- return 0;
+ return -EINVAL;
opts->codepage = option;
break;
case Opt_flush:
@@ -1013,9 +1013,9 @@ static int parse_options(struct super_block *sb, char *options, int is_vfat,
break;
case Opt_time_offset:
if (match_int(&args[0], &option))
- return 0;
+ return -EINVAL;
if (option < -12 * 60 || option > 12 * 60)
- return 0;
+ return -EINVAL;
opts->tz_set = 1;
opts->time_offset = option;
break;
--
1.7.1
next prev parent reply other threads:[~2012-11-14 1:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-12 22:27 [PATCH v2] fat: Provide option for setting timezone offset Jan Kara
2012-11-13 2:23 ` OGAWA Hirofumi
2012-11-13 10:30 ` Jan Kara
2012-11-13 11:00 ` OGAWA Hirofumi
2012-11-13 23:40 ` Andrew Morton
2012-11-14 1:04 ` Jan Kara [this message]
2012-11-14 1:11 ` Andrew Morton
2012-11-15 9:25 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121114010402.GA30196@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.