From: Andrew Morton <akpm@linux-foundation.org>
To: Takashi Sato <t-sato@yk.jp.nec.com>
Cc: linux-fsdevel@vger.kernel.org, dm-devel@redhat.com,
viro@ZenIV.linux.org.uk, linux-ext4@vger.kernel.org,
xfs@oss.sgi.com, hch@infradead.org, axboe@kernel.dk,
mtk.manpages@googlemail.com, linux-kernel@vger.kernel.org,
Oleg Nesterov <oleg@tv-sign.ru>
Subject: Re: [PATCH 3/3] Add timeout feature
Date: Thu, 21 Aug 2008 13:20:06 -0700 [thread overview]
Message-ID: <20080821132006.9949101c.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080818212856t-sato@mail.jp.nec.com>
On Mon, 18 Aug 2008 21:28:56 +0900
Takashi Sato <t-sato@yk.jp.nec.com> wrote:
> The timeout feature is added to freeze ioctl. And new ioctl
> to reset the timeout period is added.
> o Freeze the filesystem
> int ioctl(int fd, int FIFREEZE, long *timeout_sec)
> fd: The file descriptor of the mountpoint
> FIFREEZE: request code for the freeze
> timeout_sec: the timeout period in seconds
> If it's 0 or 1, the timeout isn't set.
> This special case of "1" is implemented to keep
> the compatibility with XFS applications.
> Return value: 0 if the operation succeeds. Otherwise, -1
>
> o Reset the timeout period
> int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeout_sec)
> fd:file descriptor of mountpoint
> FIFREEZE_RESET_TIMEOUT: request code for reset of timeout period
> timeout_sec: new timeout period in seconds
> Return value: 0 if the operation succeeds. Otherwise, -1
> Error number: If the filesystem has already been unfrozen,
> errno is set to EINVAL.
I don't think the changelogs actually explained why this feature is
being added?
Which userspace tools are expected to send these ioctls? Something in
util-linux? dm-utils? Are patches to those packages planned?
>
> ...
>
> /*
> + * ioctl_freeze_reset_timeout - Reset timeout for freeze.
> + *
> + * @filp: target file
> + * @argp: timeout value(sec)
> + *
> + * Reset timeout for freeze.
> + */
> +static int
> +ioctl_freeze_reset_timeout(struct file *filp, int __user *argp)
> +{
> + int timeout_sec;
> + unsigned int timeout_msec;
> + struct super_block *sb = filp->f_path.dentry->d_inode->i_sb;
> + struct block_device *bdev = sb->s_bdev;
> + int error;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + /* If a regular file or a directory isn't specified, return EINVAL. */
> + if (bdev == NULL)
> + return -EINVAL;
> +
> + /* arg(sec) to tick value */
> + error = get_user(timeout_sec, argp);
> + if (error)
> + return error;
> +
> + if (timeout_sec <= 0 || timeout_sec > UINT_MAX/1000)
> + return -EINVAL;
> +
> + timeout_msec = timeout_sec * 1000;
> +
> + down(&bdev->bd_freeze_sem);
> + if (!bdev->bd_freeze_count) {
> + up(&bdev->bd_freeze_sem);
> + return -EINVAL;
> + }
> + /* setup unfreeze timer */
> + add_freeze_timeout(bdev, timeout_msec);
> + up(&bdev->bd_freeze_sem);
> +
> + return 0;
> +}
This duplicates quite a bit of code from ioctl_freeze(). Can this be
cleaned up?
> +/*
> * When you add any new common ioctls to the switches above and below
> * please update compat_sys_ioctl() too.
> *
> @@ -235,13 +302,17 @@ int do_vfs_ioctl(struct file *filp, unsi
> break;
>
> case FIFREEZE:
> - error = ioctl_freeze(filp);
> + error = ioctl_freeze(filp, argp);
> break;
>
> case FITHAW:
> error = ioctl_thaw(filp);
> break;
>
> + case FIFREEZE_RESET_TIMEOUT:
> + error = ioctl_freeze_reset_timeout(filp, argp);
> + break;
> +
> default:
> if (S_ISREG(filp->f_path.dentry->d_inode->i_mode))
> error = file_ioctl(filp, cmd, arg);
>
> ...
>
> EXPORT_SYMBOL_GPL(kern_mount_data);
> +
> +/*
> + * freeze_timeout - Thaw the filesystem.
> + *
> + * @work: work queue (delayed_work.work)
> + *
> + * Called by the delayed work when elapsing the timeout period.
> + * Thaw the filesystem.
> + */
> +void freeze_timeout(struct work_struct *work)
> +{
> + struct block_device *bd = container_of(work,
> + struct block_device, bd_freeze_timeout.work);
> + struct super_block *sb = get_super(bd);
> +
> + thaw_bdev(bd, sb);
> +
> + if (sb)
> + drop_super(sb);
> +}
> +EXPORT_SYMBOL_GPL(freeze_timeout);
I can't see why this was exported.
> +/*
> + * add_freeze_timeout - Add timeout for freeze.
> + *
> + * @bdev: block device struct
> + * @timeout_msec: timeout period
> + *
> + * Add the delayed work for freeze timeout to the delayed work queue.
> + */
> +void add_freeze_timeout(struct block_device *bdev, unsigned int timeout_msec)
> +{
> + s64 timeout_jiffies = msecs_to_jiffies(timeout_msec);
> +
> + /* Set delayed work queue */
> + cancel_delayed_work_sync(&bdev->bd_freeze_timeout);
> + schedule_delayed_work(&bdev->bd_freeze_timeout, timeout_jiffies);
> +}
I don't particularly like the names of these new global symbols. The
kernel already has a "freezer" thing, part of power-management.
Introducing another one is a bit confusing.
otoh, freezer seems to have consistently used "freezer", so the 'r'
arguable saves us.
Still, I'd have thought that "fsfreeze" would have been a clearer, more
specific identifier for the whole project.
> +/*
> + * del_freeze_timeout - Delete timeout for freeze.
> + *
> + * @bdev: block device struct
> + *
> + * Delete the delayed work for freeze timeout from the delayed work queue.
> + */
> +void del_freeze_timeout(struct block_device *bdev)
> +{
> + /*
> + * It's possible that the delayed work task (freeze_timeout()) calls
> + * del_freeze_timeout(). If the delayed work task calls
> + * cancel_delayed_work_sync((), the deadlock will occur.
> + * So we need this check (delayed_work_pending()).
> + */
> + if (delayed_work_pending(&bdev->bd_freeze_timeout))
> + cancel_delayed_work_sync(&bdev->bd_freeze_timeout);
> +}
So if the calling task is keventd via run_workqueue() then
delayed_work_pending() should return false due to run_workqueue()
ordering, so we avoid the deadlock.
Seems a bit racy if some other process starts the delayed-work while
this function is running but I guess the new semaphore prevents that.
Perhaps cancel_delayed_work_sync() shouldn't hang up if called from the
work handler?
next prev parent reply other threads:[~2008-08-21 20:21 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-18 12:28 [PATCH 3/3] Add timeout feature Takashi Sato
2008-08-21 20:20 ` Andrew Morton [this message]
2008-08-22 18:16 ` Christoph Hellwig
2008-08-24 17:03 ` Oleg Nesterov
2008-08-29 9:39 ` Takashi Sato
-- strict thread matches above, loose matches on Subject: below --
2008-09-08 11:53 Takashi Sato
2008-09-08 17:11 ` Christoph Hellwig
2008-09-25 21:06 ` Ric Wheeler
2008-09-26 8:52 ` Takashi Sato
2008-09-26 10:58 ` Ric Wheeler
2008-09-29 11:11 ` Takashi Sato
2008-09-26 12:35 ` Valdis.Kletnieks
2008-09-29 14:13 ` Christoph Hellwig
2008-09-29 14:36 ` Eric Sandeen
2008-09-29 14:37 ` Christoph Hellwig
2008-09-29 14:45 ` Eric Sandeen
2008-09-29 22:08 ` jim owens
2008-10-05 10:00 ` Pavel Machek
2008-10-09 10:12 ` Takashi Sato
2008-10-09 10:18 ` Christoph Hellwig
2008-07-22 9:36 Takashi Sato
2008-06-30 12:24 Takashi Sato
2008-07-01 8:10 ` Christoph Hellwig
2008-07-07 11:07 ` Pavel Machek
2008-07-08 23:10 ` Dave Chinner
2008-07-08 23:20 ` Pavel Machek
2008-07-09 0:52 ` Dave Chinner
2008-07-09 1:09 ` Theodore Tso
2008-07-09 4:21 ` Brad Boyer
2008-07-09 6:13 ` Miklos Szeredi
2008-07-09 6:16 ` Christoph Hellwig
2008-07-09 6:22 ` Miklos Szeredi
2008-07-09 6:41 ` Arjan van de Ven
2008-07-09 6:48 ` Miklos Szeredi
2008-07-09 6:55 ` Arjan van de Ven
2008-07-09 7:08 ` Miklos Szeredi
2008-07-09 20:48 ` Pavel Machek
2008-07-09 7:13 ` Dave Chinner
2008-07-09 11:09 ` Theodore Tso
2008-07-09 11:49 ` Dave Chinner
2008-07-09 12:24 ` Theodore Tso
2008-07-09 12:59 ` Olaf Frączyk
2008-07-09 13:57 ` Arjan van de Ven
2008-07-09 13:55 ` Arjan van de Ven
2008-07-09 13:58 ` jim owens
2008-07-09 14:13 ` jim owens
2008-07-13 12:06 ` Pavel Machek
2008-07-13 17:15 ` jim owens
2008-07-14 6:36 ` Pavel Machek
2008-07-14 13:17 ` jim owens
2008-07-14 13:12 ` Takashi Sato
2008-07-14 14:04 ` jim owens
2008-07-09 13:53 ` Arjan van de Ven
2008-07-09 6:59 ` Dave Chinner
2008-07-09 7:13 ` Miklos Szeredi
2008-07-09 7:33 ` Dave Chinner
2008-07-09 8:11 ` Miklos Szeredi
2008-07-09 11:15 ` Dave Chinner
2008-07-09 20:44 ` Pavel Machek
2008-06-24 7:00 Takashi Sato
2008-06-24 22:09 ` Andrew Morton
2008-06-27 11:33 ` Takashi Sato
2008-06-27 18:57 ` Andrew Morton
2008-06-29 23:13 ` Takashi Sato
2008-06-30 0:01 ` Andrew Morton
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=20080821132006.9949101c.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@googlemail.com \
--cc=oleg@tv-sign.ru \
--cc=t-sato@yk.jp.nec.com \
--cc=viro@ZenIV.linux.org.uk \
--cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox