On Wed, Aug 13 2008, David Woodhouse wrote: > On Wed, 2008-08-13 at 13:15 +0200, Jens Axboe wrote: > > On Tue, Aug 12 2008, David Woodhouse wrote: > > > On Tue, 2008-08-12 at 14:04 +0100, David Woodhouse wrote: > > > > > Or just match the check before -EOPNOTSUPP with bio_has_data(), > > > > > since it only applies to a barrier that carries data. > > > > > > > > Like this, you mean? Empty barriers don't get to there? > > > > > > Seems to work, although I'm somewhat dubious about it. Still, if you're > > > happy that it's correct and you really prefer it that way, then I can > > > commit it. > > > > Looks ok to me. > > OK, that version is now in the git tree. Alright, I'll pull it it. > > > Anything else I need to address before you pull the tree? Any comment on > > > the BLKDISCARD ioctl? I've left that one using the non-barrier version > > > since it's waiting for it anyway, and shouldn't be happening > > > concurrently with anything else. > > > > > > (http://,git://} git.infradead.org/users/dwmw2/discard-2.6.git > > > > I'm with Jamie on using the safer version for the ioctl, unless you > > ensure that the block device isn't mounted before allowing it. > > We don't ensure that the block device isn't mounted before we allow > reads/writes -- why should we do so before we allow discard? > > If the userspace tool 'owns' the block device, that's a different story > -- and that's OK too, because the BLKDISCARD ioctl is synchronous. It > won't return until it's actually _complete_, and userspace really > shouldn't be trying to write to the same sectors until that happens. Still seems a little unsafe. I guess you could make a case for making the ioctl privileged. We should at least ensure that the user has write access to the device before allowing a discard operation. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
