lkml.org 
[lkml]   [2004]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: f_ops flag to speed up compatible ioctls in linux kernel

    Quoting Lee Revell (rlrevell@joe-job.com) "Re: f_ops flag to speed up compatible ioctls in linux kernel":
    > By adding a new ioctl you are adding a new use of the BKL. It has been
    > suggested on dri-devel that this should be fixed. Is this even
    > possible?
    >
    > Lee

    I dont know - can the lock be released before the call to
    filp->f_op->ioctl ?

    I assume the reason its there is for legacy code - existing ioctls
    may be assuming the BKL is taken, but maybe there could be another
    flag in f_ops to let sys_ioctl release the lock before doing the call ...

    Like this - would that be safe?


    --- linux-2.6.8.1/fs/ioctl.c 2004-08-14 13:54:51.000000000 +0300
    +++ linux-2.6.8.1-built/fs/ioctl.c 2004-09-01 11:14:59.944417160 +0300
    @@ -126,6 +126,14 @@
    error = -ENOTTY;
    if (S_ISREG(filp->f_dentry->d_inode->i_mode))
    error = file_ioctl(filp, cmd, arg);
    + else if (filp->f_op && filp->f_op->ioctl &&
    + (filp->f_op->fops_flags & FOPS_IOCTL_NOLOCK)) {
    + {
    + unlock_kernel();
    + error = filp->f_op->ioctl(filp->f_dentry->d_inode, filp, cmd, arg);
    + goto out;
    +
    + }
    else if (filp->f_op && filp->f_op->ioctl)
    error = filp->f_op->ioctl(filp->f_dentry->d_inode, filp, cmd, arg);
    }
    -
    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: 2005-03-22 14:05    [W:0.021 / U:89.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site