Prev: [PATCH v2] USB: isp1760: Soften DW3 X/transaction error bit handling
Next: cgroup freezer: Update stale locking comments
From: Christoph Hellwig on 6 May 2010 17:20
> +struct btrfs_dio_private {
> + struct inode *inode;
> + u64 logical_offset;
> + u32 *csums;
> + void *private;
> +};
> +
> +static void btrfs_endio_direct(struct bio *bio, int err)
> +{
> + struct bio_vec *bvec_end = bio->bi_io_vec + bio->bi_vcnt - 1;
> + struct bio_vec *bvec = bio->bi_io_vec;
> + struct btrfs_dio_private *dip = bio->bi_private;
> + struct inode *inode = dip->inode;
> + struct btrfs_root *root = BTRFS_I(inode)->root;
> + u64 start;
> + u32 *private = dip->csums;
> +
> + start = dip->logical_offset;
> + do {
> + if (!(BTRFS_I(inode)->flags & BTRFS_INODE_NODATASUM)) {
> + struct page *page = bvec->bv_page;
> + char *kaddr;
> + u32 csum = ~(u32)0;
> +
> + kaddr = kmap_atomic(page, KM_USER0);

KM_USER0 seems wrong given that the bio completion callback can and
usually will be called from some kind of IRQ context.

> + ret = blockdev_direct_IO_own_submit(rw, iocb, inode, NULL, iov,
> + offset, nr_segs,
> + btrfs_get_blocks_direct,
> + btrfs_submit_direct);

Don't you need to do some alignment checks of your own given that you
don't pass in a block device?

Btw, passing in the bdev here is a really horrible API, I'd much rather
move this to the callers..

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jamie Lokier on 7 May 2010 06:00
Josef Bacik wrote:
> 3) Lock the entire range during DIO. I originally had it so we would lock the
> extents as get_block was called, and then unlock them as the endio function was
> called, which worked great, but if we ever had an error in the submit_io hook,
> we could have locked an extent that would never be submitted for IO, so we
> wouldn't be able to unlock it, so this solution fixed that problem and made it a
> bit cleaner.

Does this prevent concurrent DIOs to overlapping or nearby ranges?

Thanks,
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Josef Bacik on 7 May 2010 09:50
On Fri, May 07, 2010 at 10:55:37AM +0100, Jamie Lokier wrote:
> Josef Bacik wrote:
> > 3) Lock the entire range during DIO. I originally had it so we would lock the
> > extents as get_block was called, and then unlock them as the endio function was
> > called, which worked great, but if we ever had an error in the submit_io hook,
> > we could have locked an extent that would never be submitted for IO, so we
> > wouldn't be able to unlock it, so this solution fixed that problem and made it a
> > bit cleaner.
>
> Does this prevent concurrent DIOs to overlapping or nearby ranges?
>

It just prevents them from overlapping areas. Thanks,

Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH v2] USB: isp1760: Soften DW3 X/transaction error bit handling
Next: cgroup freezer: Update stale locking comments