lkml.org 
[lkml]   [2011]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices
    On Thu, Dec 22, 2011 at 2:08 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
    >
    > I don't know.  But given the ways in which earlier versions broke during
    > testing, I wouldn't be able to tell before running many tests.  Which with
    > the Christmas break would easily mean a little less than 2 weeks.

    I don't think I'm ready to apply this as-is anyway, exactly because
    I'd worry about some distribution really depending on being able to
    eject disks by partition etc.

    I don't *think* anybody does something as crazy as giving actual block
    device ownership to people, but I don't know - and I could easily
    imagine that even if they don't give the block device to the user, the
    suid binary might do "eject /dev/sda1" etc. And one way to do that is
    to do the "door unlock" scsi command itself.

    So at this point I'd much *much* rather see this as a "we merge it for
    3.3 and mark it for stable", so that we can at least get the testing
    in the git tree, rather than me taking what could potentially break
    peoples setups very late in the -rc series just before a release.

    >> That's a completely independent bug that has been discussed several
    >> times. We probably should just bite the bullet and fix it. EINVAL is
    >> never the right return value (unless the per-ioctl arguments
    >> themselves are invalid, not for bad ioctls).
    >
    > Makes a lot of sense and I was wondering about it myself, but I'm not sure
    > stable would accept that.

    Again, I think it's something we should do during the merge window
    (early at that).

    It really has come up several times, it just always comes up at the
    wrong moment. If you remind me after the 3.2 release, I'll make sure
    to "just do it", and we'll see if anything break.

    I doubt anything will, because ENOTTY really is the correct error
    return (to user space - for traditional reasons) for "no such ioctl".

    Inside the kernel we generally want to use ENOIOCTLCMD, which is much
    better named - and thus avoids the confusion that some people have
    about the ENOTTY name - and that also has the whole "let's just try
    another approach one then".

    >> The EINVAL return comes from some people who didn't understand that
    >> ENOTTY means "no such ioctl" despite the name.
    >
    > I did. :)

    I suspect most people who have used Unix for a long time kind of take
    the "ENOTTY - no such ioctl" thing for granted and don't even think
    about it, but we do have a lot of people who write drivers etc and
    that started with Linux, and I can understand why they think "ENOTTY"
    is an odd name for a SCSI device driver to use.

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

    \
     
     \ /
      Last update: 2011-12-22 23:29    [W:0.023 / U:29.396 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site