From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] fs: record task name which froze superblock
Date: Wed, 18 Feb 2015 10:18:12 +0000 [thread overview]
Message-ID: <54E466E4.5080704@redhat.com> (raw)
In-Reply-To: <20150218091323.GA4614@quack.suse.cz>
Hi,
On 18/02/15 09:13, Jan Kara wrote:
> On Wed 18-02-15 10:34:55, Alexey Dobriyan wrote:
>> On Mon, Feb 16, 2015 at 10:38:52AM +0100, Jan Kara wrote:
>>> On Sat 14-02-15 21:55:24, Alexey Dobriyan wrote:
>>>> Freezing and thawing are separate system calls, task which is supposed
>>>> to thaw filesystem/superblock can disappear due to crash or not thaw
>>>> due to a bug. Record at least task name (we can't take task_struct
>>>> reference) to make support engineer's life easier.
>>>>
>>>> Hopefully 16 bytes per superblock isn't much.
>>>>
>>>> P.S.: Cc'ing GFS2 people just in case they want to correct
>>>> my understanding of GFS2 having async freeze code.
>>>>
>>>> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
>>> Hum, and when do you show the task name? Or do you expect that customer
>>> takes a crashdump and support just finds it in memory?
>> Yeah, having at least something in crashdump is fine.
> OK, then comment about this at freeze_comm[] definition so that it's
> clear it isn't just set-but-never-read field.
>
>>>> --- a/fs/ioctl.c
>>>> +++ b/fs/ioctl.c
>>>> @@ -518,6 +518,7 @@ static int ioctl_fioasync(unsigned int fd, struct file *filp,
>>>> static int ioctl_fsfreeze(struct file *filp)
>>>> {
>>>> struct super_block *sb = file_inode(filp)->i_sb;
>>>> + int rv;
>>>>
>>>> if (!capable(CAP_SYS_ADMIN))
>>>> return -EPERM;
>>>> @@ -527,22 +528,31 @@ static int ioctl_fsfreeze(struct file *filp)
>>>> return -EOPNOTSUPP;
>>>>
>>>> /* Freeze */
>>>> - if (sb->s_op->freeze_super)
>>>> - return sb->s_op->freeze_super(sb);
>>>> - return freeze_super(sb);
>>>> + if (sb->s_op->freeze_super) {
>>>> + rv = sb->s_op->freeze_super(sb);
>>>> + if (rv == 0)
>>>> + get_task_comm(sb->s_writers.freeze_comm, current);
>>>> + } else
>>>> + rv = freeze_super(sb);
>>>> + return rv;
>>> Why don't you just set the name in ioctl_fsfreeze() in both cases?
>> There are users of freeze_super() in GFS2 unless I'm misreading code.
> Yes, there are. The call in fs/gfs2/glops.c is in a call path from
> ->freeze_super() handler for GFS2 so that one is handled in
> ioctl_fsfreeze() anyway. The call in fs/gfs2/sys.c is a way to freeze
> filesystem via sysfs (dunno why GFS2 has to invent its own thing and ioctl
> isn't enough). Steven? So having the logic in ioctl_fsfreeze(),
> freeze_bdev() and freeze_store() in gfs2 seems to be enough.
>
The sysfs freeze thing is historical and strongly deprecated - I hope
that we may be able to remove it one day,
Steve.
WARNING: multiple messages have this Message-ID (diff)
From: Steven Whitehouse <swhiteho@redhat.com>
To: Jan Kara <jack@suse.cz>, Alexey Dobriyan <adobriyan@gmail.com>
Cc: akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
cluster-devel@redhat.com
Subject: Re: [PATCH] fs: record task name which froze superblock
Date: Wed, 18 Feb 2015 10:18:12 +0000 [thread overview]
Message-ID: <54E466E4.5080704@redhat.com> (raw)
In-Reply-To: <20150218091323.GA4614@quack.suse.cz>
Hi,
On 18/02/15 09:13, Jan Kara wrote:
> On Wed 18-02-15 10:34:55, Alexey Dobriyan wrote:
>> On Mon, Feb 16, 2015 at 10:38:52AM +0100, Jan Kara wrote:
>>> On Sat 14-02-15 21:55:24, Alexey Dobriyan wrote:
>>>> Freezing and thawing are separate system calls, task which is supposed
>>>> to thaw filesystem/superblock can disappear due to crash or not thaw
>>>> due to a bug. Record at least task name (we can't take task_struct
>>>> reference) to make support engineer's life easier.
>>>>
>>>> Hopefully 16 bytes per superblock isn't much.
>>>>
>>>> P.S.: Cc'ing GFS2 people just in case they want to correct
>>>> my understanding of GFS2 having async freeze code.
>>>>
>>>> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
>>> Hum, and when do you show the task name? Or do you expect that customer
>>> takes a crashdump and support just finds it in memory?
>> Yeah, having at least something in crashdump is fine.
> OK, then comment about this at freeze_comm[] definition so that it's
> clear it isn't just set-but-never-read field.
>
>>>> --- a/fs/ioctl.c
>>>> +++ b/fs/ioctl.c
>>>> @@ -518,6 +518,7 @@ static int ioctl_fioasync(unsigned int fd, struct file *filp,
>>>> static int ioctl_fsfreeze(struct file *filp)
>>>> {
>>>> struct super_block *sb = file_inode(filp)->i_sb;
>>>> + int rv;
>>>>
>>>> if (!capable(CAP_SYS_ADMIN))
>>>> return -EPERM;
>>>> @@ -527,22 +528,31 @@ static int ioctl_fsfreeze(struct file *filp)
>>>> return -EOPNOTSUPP;
>>>>
>>>> /* Freeze */
>>>> - if (sb->s_op->freeze_super)
>>>> - return sb->s_op->freeze_super(sb);
>>>> - return freeze_super(sb);
>>>> + if (sb->s_op->freeze_super) {
>>>> + rv = sb->s_op->freeze_super(sb);
>>>> + if (rv == 0)
>>>> + get_task_comm(sb->s_writers.freeze_comm, current);
>>>> + } else
>>>> + rv = freeze_super(sb);
>>>> + return rv;
>>> Why don't you just set the name in ioctl_fsfreeze() in both cases?
>> There are users of freeze_super() in GFS2 unless I'm misreading code.
> Yes, there are. The call in fs/gfs2/glops.c is in a call path from
> ->freeze_super() handler for GFS2 so that one is handled in
> ioctl_fsfreeze() anyway. The call in fs/gfs2/sys.c is a way to freeze
> filesystem via sysfs (dunno why GFS2 has to invent its own thing and ioctl
> isn't enough). Steven? So having the logic in ioctl_fsfreeze(),
> freeze_bdev() and freeze_store() in gfs2 seems to be enough.
>
The sysfs freeze thing is historical and strongly deprecated - I hope
that we may be able to remove it one day,
Steve.
next prev parent reply other threads:[~2015-02-18 10:18 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-14 18:55 [Cluster-devel] [PATCH] fs: record task name which froze superblock Alexey Dobriyan
2015-02-14 18:55 ` Alexey Dobriyan
2015-02-16 9:38 ` [Cluster-devel] " Jan Kara
2015-02-16 9:38 ` Jan Kara
2015-02-18 7:34 ` [Cluster-devel] " Alexey Dobriyan
2015-02-18 7:34 ` Alexey Dobriyan
2015-02-18 7:36 ` [Cluster-devel] [PATCH v2] " Alexey Dobriyan
2015-02-18 7:36 ` Alexey Dobriyan
2015-02-18 9:13 ` [Cluster-devel] [PATCH] " Jan Kara
2015-02-18 9:13 ` Jan Kara
2015-02-18 10:18 ` Steven Whitehouse [this message]
2015-02-18 10:18 ` Steven Whitehouse
2015-02-20 11:42 ` [Cluster-devel] " Alexey Dobriyan
2015-02-20 11:42 ` Alexey Dobriyan
2015-02-20 12:15 ` [Cluster-devel] " Jan Kara
2015-02-20 12:15 ` Jan Kara
2015-02-28 14:22 ` [Cluster-devel] " Alexey Dobriyan
2015-02-28 14:22 ` Alexey Dobriyan
2015-02-28 14:25 ` [Cluster-devel] [PATCH v3] " Alexey Dobriyan
2015-02-28 14:25 ` Alexey Dobriyan
2015-02-28 21:31 ` [Cluster-devel] " Dave Chinner
2015-02-28 21:31 ` Dave Chinner
2015-03-02 4:38 ` [Cluster-devel] " Mateusz Guzik
2015-03-02 4:38 ` Mateusz Guzik
2015-03-02 4:46 ` [Cluster-devel] " Mateusz Guzik
2015-03-02 4:46 ` Mateusz Guzik
2015-03-09 15:14 ` [Cluster-devel] " Alexey Dobriyan
2015-03-09 15:14 ` Alexey Dobriyan
2015-03-02 21:33 ` [Cluster-devel] " Dave Chinner
2015-03-02 21:33 ` Dave Chinner
2015-03-04 15:14 ` [Cluster-devel] " Alexey Dobriyan
2015-03-04 15:14 ` Alexey Dobriyan
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=54E466E4.5080704@redhat.com \
--to=swhiteho@redhat.com \
/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.