lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070508175410.d5b7e91f.akpm@linux-foundation.org>
Date:	Tue, 8 May 2007 17:54:10 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Alasdair G Kergon <agk@...hat.com>
Cc:	dm-devel@...hat.com, linux-kernel@...r.kernel.org,
	Heinz Mauelshagen <mauelshagen@...hat.com>,
	Christoph Lameter <clameter@....com>
Subject: Re: [2.6.22 PATCH 23/26] dm delay:

On Tue, 8 May 2007 20:48:59 +0100
Alasdair G Kergon <agk@...hat.com> wrote:

> From: Heinz Mauelshagen <mauelshagen@...hat.com>
> 
> New device-mapper target that can delay I/O (for testing).
> Reads can be separated from writes, redirected to different underlying
> devices and delayed by differing amounts of time.
> 
> ..
>
> +/*
> + * Copyright (C) 2005-2007 Red Hat GmbH
> + *
> + * A target that delays reads and/or writes and can send
> + * them to different devices.
> + *
> + * This file is released under the GPL.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/blkdev.h>
> +#include <linux/bio.h>
> +#include <linux/slab.h>
> +
> +#include "dm.h"
> +#include "dm-bio-list.h"
> +
> +#define DM_MSG_PREFIX "delay"
> +
> +struct delay_c {
> +	struct timer_list delay_timer;
> +	struct semaphore timer_lock;

Can we get this converted to a mutex asap, please?

It's only used in a single place and perhaps we don't need this lock at
all?

> +	struct work_struct flush_expired_bios;
> +	struct list_head delayed_bios;
> +	atomic_t may_delay;
> +	mempool_t *delayed_pool;
> +
> +	struct dm_dev *dev_read;
> +	sector_t start_read;
> +	unsigned read_delay;
> +	unsigned reads;
> +
> +	struct dm_dev *dev_write;
> +	sector_t start_write;
> +	unsigned write_delay;
> +	unsigned writes;
> +};
> +
> +struct delay_info {
> +	struct delay_c *context;
> +	struct list_head list;
> +	struct bio *bio;
> +	unsigned long expires;
> +};
> +
> +static DEFINE_MUTEX(delayed_bios_lock);
> +
> +static struct workqueue_struct *kdelayd_wq;
> +static struct kmem_cache *delayed_cache;
> +
> +static void handle_delayed_timer(unsigned long data)
> +{
> +	struct delay_c *dc = (struct delay_c *)data;
> +
> +	queue_work(kdelayd_wq, &dc->flush_expired_bios);
> +}
> +
> +static void queue_timeout(struct delay_c *dc, unsigned long expires)
> +{
> +	down(&dc->timer_lock);
> +
> +	if (!timer_pending(&dc->delay_timer) || expires < dc->delay_timer.expires)
> +		mod_timer(&dc->delay_timer, expires);
> +
> +	up(&dc->timer_lock);
> +}
>
> ...
>
> +
> +	init_timer(&dc->delay_timer);
> +	dc->delay_timer.function = handle_delayed_timer;
> +	dc->delay_timer.data = (unsigned long)dc;

setup_timer() could be used here.

> +	INIT_WORK(&dc->flush_expired_bios, flush_expired_bios);
> +	INIT_LIST_HEAD(&dc->delayed_bios);
> +	init_MUTEX(&dc->timer_lock);
> +	atomic_set(&dc->may_delay, 1);
> +
> +	ti->private = dc;
> +	return 0;
> +
> +bad:
> +	kfree(dc);
> +	return -EINVAL;
> +}
> +
>
> ...
>
> +
> +static int __init dm_delay_init(void)
> +{
> +	int r = -ENOMEM;
> +
> +	kdelayd_wq = create_workqueue("kdelayd");
> +	if (!kdelayd_wq) {
> +		DMERR("Couldn't start kdelayd");
> +		goto bad_queue;
> +	}

Do we really really need one instance of kdelayd on each CPU?

I suspect a single-threaded workqueue would suffice here.  We have a big
global lock in this driver anyway....

Probably create_workqueue() should have defaulted to single-threaded on day
one.  Oh well.


> +	delayed_cache = kmem_cache_create("dm-delay",
> +					  sizeof(struct delay_info),
> +					  __alignof__(struct delay_info),
> +					  0, NULL, NULL);

We have an ugly^Wnice new KMEM_CACHE macro for this now.

What's that __alignof__ doing in there?

> +	if (!delayed_cache) {
> +		DMERR("Couldn't create delayed bio cache.");
> +		goto bad_memcache;
> +	}
> +
> +	r = dm_register_target(&delay_target);
> +	if (r < 0) {
> +		DMERR("register failed %d", r);
> +		goto bad_register;
> +	}
> +
> +	return 0;
> +
> +bad_register:
> +	kmem_cache_destroy(delayed_cache);
> +bad_memcache:
> +	destroy_workqueue(kdelayd_wq);
> +bad_queue:
> +	return r;
> +}
> +

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ