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
| ||
|
Date: Wed, 26 Nov 2014 18:00:55 -0500 From: Mike Snitzer <snitzer@...hat.com> To: Jens Axboe <axboe@...nel.dk> Cc: martin.petersen@...cle.com, mst@...hat.com, rusty@...tcorp.com.au, qemu-devel@...gnu.org, linux-kernel@...r.kernel.org, Christoph Hellwig <hch@...radead.org>, dm-devel@...hat.com, Paolo Bonzini <pbonzini@...hat.com> Subject: Re: virtio_blk: fix defaults for max_hw_sectors and max_segment_size On Wed, Nov 26 2014 at 4:53pm -0500, Jens Axboe <axboe@...nel.dk> wrote: > On 11/26/2014 02:51 PM, Mike Snitzer wrote: > > > > But while you're here, I wouldn't mind getting your take on virtio-blk > > setting max_hw_sectors to -1U. > > > > As I said in my original reply to mst: it only makes sense to set a > > really high initial upper bound like that in a driver if that driver > > goes on to stack an underlying device's limit. > > -1U should just work, IMHO, there's no reason we should need to cap it > at some synthetic value. That said, it seems it should be one of > those parameters that should be negotiated up and set appropriately. I'm saying set it to the underlying device's value for max_hw_sectors -- not some synthetic value. So I think we're saying the same thing. But it isn't immediately clear (to me) how that benefits virtio-blk users (obviously they are getting by today). So until that is pinned down I imagine nobody will care to extend the virtio-blk protocol to allow stacking max_hw_sectors and max_sectors up. -- 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