On Fri, 2013-04-26 at 11:09 -0700, Andy Grover wrote: > We can still see the error reported in > > https://patchwork.kernel.org/patch/2338981/ > > when using fileio backed by a block device. > > I'm assuming this will get us past that error (from sbc_parse_cdb), > and also assuming it's OK to have our max_sectors be larger than > the block's queue max hw sectors? > > Reported-by: Eric Harney <eharney@xxxxxxxxxx> > Signed-off-by: Andy Grover <agrover@xxxxxxxxxx> > --- Looks fine. Applying to target-pending/queue, and will include a CC' to stable. Thanks, --nab > drivers/target/target_core_file.c | 9 ++------- > 1 files changed, 2 insertions(+), 7 deletions(-) > > diff --git a/drivers/target/target_core_file.c b/drivers/target/target_core_file.c > index 58ed683..1b1d544 100644 > --- a/drivers/target/target_core_file.c > +++ b/drivers/target/target_core_file.c > @@ -153,10 +153,6 @@ static int fd_configure_device(struct se_device *dev) > struct request_queue *q = bdev_get_queue(inode->i_bdev); > unsigned long long dev_size; > > - dev->dev_attrib.hw_block_size = > - bdev_logical_block_size(inode->i_bdev); > - dev->dev_attrib.hw_max_sectors = queue_max_hw_sectors(q); > - > /* > * Determine the number of bytes from i_size_read() minus > * one (1) logical sector from underlying struct block_device > @@ -203,9 +199,6 @@ static int fd_configure_device(struct se_device *dev) > goto fail; > } > > - dev->dev_attrib.hw_block_size = FD_BLOCKSIZE; > - dev->dev_attrib.hw_max_sectors = FD_MAX_SECTORS; > - > /* > * Limit UNMAP emulation to 8k Number of LBAs (NoLB) > */ > @@ -226,6 +219,8 @@ static int fd_configure_device(struct se_device *dev) > > fd_dev->fd_block_size = dev->dev_attrib.hw_block_size; > > + dev->dev_attrib.hw_block_size = FD_BLOCKSIZE; > + dev->dev_attrib.hw_max_sectors = FD_MAX_SECTORS; > dev->dev_attrib.hw_queue_depth = FD_MAX_DEVICE_QUEUE_DEPTH; > > if (fd_dev->fbd_flags & FDBD_HAS_BUFFERED_IO_WCE) { -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
