From: Alexey Dobriyan <adobriyan@gmail.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] fs: record task name which froze superblock
Date: Wed, 18 Feb 2015 10:34:55 +0300 [thread overview]
Message-ID: <20150218073455.GA1752@p183.telecom.by> (raw)
In-Reply-To: <20150216093852.GB4749@quack.suse.cz>
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.
> > --- 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.
> Also you seem to be missing freezing / thawing in freeze/thaw_bdev()
> functions.
You are correct. Resending patch (blockdev freezing tested with XFS).
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -1221,6 +1221,8 @@ struct sb_writers {
> > int frozen; /* Is sb frozen? */
> > wait_queue_head_t wait_unfrozen; /* queue for waiting for
> > sb to be thawed */
> > + /* who froze superblock */
> > + char freeze_comm[16];
> Here should be TASK_COMM_LEN, shouldn't it?
It will pull sched.h, dunno if we care about headers anymore.
Alexey
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Dobriyan <adobriyan@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
swhiteho@redhat.com, cluster-devel@redhat.com
Subject: Re: [PATCH] fs: record task name which froze superblock
Date: Wed, 18 Feb 2015 10:34:55 +0300 [thread overview]
Message-ID: <20150218073455.GA1752@p183.telecom.by> (raw)
In-Reply-To: <20150216093852.GB4749@quack.suse.cz>
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.
> > --- 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.
> Also you seem to be missing freezing / thawing in freeze/thaw_bdev()
> functions.
You are correct. Resending patch (blockdev freezing tested with XFS).
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -1221,6 +1221,8 @@ struct sb_writers {
> > int frozen; /* Is sb frozen? */
> > wait_queue_head_t wait_unfrozen; /* queue for waiting for
> > sb to be thawed */
> > + /* who froze superblock */
> > + char freeze_comm[16];
> Here should be TASK_COMM_LEN, shouldn't it?
It will pull sched.h, dunno if we care about headers anymore.
Alexey
next prev parent reply other threads:[~2015-02-18 7:34 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 ` Alexey Dobriyan [this message]
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 ` [Cluster-devel] " Steven Whitehouse
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=20150218073455.GA1752@p183.telecom.by \
--to=adobriyan@gmail.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.