All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Takashi Sato <t-sato@yk.jp.nec.com>
Cc: axboe@kernel.dk, mtk.manpages@googlemail.com,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org,
	dm-devel@redhat.com, viro@ZenIV.linux.org.uk,
	linux-fsdevel@vger.kernel.org, linux-ext4@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?

WARNING: multiple messages have this Message-ID (diff)
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?

  reply	other threads:[~2008-08-21 20:20 UTC|newest]

Thread overview: 123+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-18 12:28 [PATCH 3/3] Add timeout feature Takashi Sato
2008-08-18 12:28 ` Takashi Sato
2008-08-21 20:20 ` Andrew Morton [this message]
2008-08-21 20:20   ` Andrew Morton
2008-08-22 18:16   ` Christoph Hellwig
2008-08-22 18:16     ` Christoph Hellwig
2008-08-24 17:03   ` Oleg Nesterov
2008-08-29  9:39   ` Takashi Sato
2008-08-29  9:39     ` Takashi Sato
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 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  8:52       ` Takashi Sato
2008-09-26 10:58       ` Ric Wheeler
2008-09-29 11:11         ` Takashi Sato
2008-09-29 11:11           ` Takashi Sato
2008-09-29 11:11           ` Takashi Sato
2008-09-26 12:35       ` Valdis.Kletnieks
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: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:12                 ` Takashi Sato
2008-10-09 10:12                 ` Takashi Sato
2008-10-09 10:18                 ` Christoph Hellwig
2008-10-09 10:18                   ` Christoph Hellwig
2008-07-22  9:36 Takashi Sato
2008-07-22  9:36 ` Takashi Sato
2008-07-22  9:36 ` Takashi Sato
2008-07-22  9:36 Takashi Sato
2008-06-30 12:24 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:10       ` Dave Chinner
2008-07-08 23:20       ` Pavel Machek
2008-07-08 23:20         ` Pavel Machek
2008-07-09  0:52         ` Dave Chinner
2008-07-09  1:09           ` Theodore Tso
2008-07-09  1:09           ` Theodore Tso
2008-07-09  1:09             ` Theodore Tso
2008-07-09  4:21             ` Brad Boyer
2008-07-09  4:21               ` Brad Boyer
2008-07-09  4:21             ` Brad Boyer
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:22                   ` Miklos Szeredi
2008-07-09  6:22                   ` Miklos Szeredi
2008-07-09  6:41                   ` Arjan van de Ven
2008-07-09  6:41                     ` Arjan van de Ven
2008-07-09  6:41                     ` Arjan van de Ven
2008-07-09  6:48                     ` Miklos Szeredi
2008-07-09  6:48                       ` Miklos Szeredi
2008-07-09  6:55                       ` Arjan van de Ven
2008-07-09  6:55                         ` Arjan van de Ven
2008-07-09  6:55                         ` Arjan van de Ven
2008-07-09  7:08                         ` Miklos Szeredi
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:09                             ` Theodore Tso
2008-07-09 11:49                             ` Dave Chinner
2008-07-09 11:49                             ` Dave Chinner
2008-07-09 11:49                             ` Dave Chinner
2008-07-09 11:49                               ` Dave Chinner
2008-07-09 12:24                               ` Theodore Tso
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:57                                     ` Arjan van de Ven
2008-07-09 12:24                               ` Theodore Tso
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 13:12                                   ` Takashi Sato
2008-07-14 14:04                                   ` jim owens
2008-07-09 11:09                           ` Theodore Tso
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  7:33                           ` Dave Chinner
2008-07-09  8:11                           ` Miklos Szeredi
2008-07-09  8:11                             ` Miklos Szeredi
2008-07-09 11:15                             ` Dave Chinner
2008-07-09 11:15                               ` Dave Chinner
2008-07-09  1:09           ` Theodore Tso
2008-07-09 20:44           ` Pavel Machek
2008-07-09 20:44             ` Pavel Machek
2008-07-09 20:44           ` Pavel Machek
2008-07-09 20:44           ` Pavel Machek
2008-07-08 23:20       ` Pavel Machek
2008-07-08 23:20       ` Pavel Machek
2008-06-24  7:00 Takashi Sato
2008-06-24  7:00 ` Takashi Sato
2008-06-24 22:09 ` Andrew Morton
2008-06-27 11:33   ` Takashi Sato
2008-06-27 11:33     ` Takashi Sato
2008-06-27 11:33     ` Takashi Sato
2008-06-27 18:57     ` Andrew Morton
2008-06-29 23:13       ` Takashi Sato
2008-06-29 23:13         ` Takashi Sato
2008-06-29 23:13         ` Takashi Sato
2008-06-30  0:01         ` Andrew Morton
2008-06-30  0:01           ` Andrew Morton
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 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.