Mailing List Archive

[PATCH] [2/11] Add unlocked_fasync
Add a new fops entry point to allow fasync without BKL. While it's arguably
unclear this entry point is called often enough for it really matters
it was still relatively easy to do. And there are far less async users
in the tree than ioctls so it's likely they can be all converted
eventually and then the non unlocked async entry point could be dropped.

There was still the problem of the actual flags change being
protected against other setters of flags. Instead of using BKL
for this use the i_mutex now.

I also added a mutex_lock against one other flags change
that was lockless and could potentially lose updates.

There are a couple of potential problems I added comments about on.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

---
Documentation/filesystems/vfs.txt | 5 ++++-
fs/fcntl.c | 6 +++++-
fs/ioctl.c | 5 ++++-
include/linux/fs.h | 1 +
4 files changed, 14 insertions(+), 3 deletions(-)

Index: linux/fs/fcntl.c
===================================================================
--- linux.orig/fs/fcntl.c
+++ linux/fs/fcntl.c
@@ -227,18 +227,26 @@ static int setfl(int fd, struct file * f
if (error)
return error;

- lock_kernel();
+ /* AK: potential race here. Since test is unlocked fasync could
+ be called several times in a row with on. We hope the drivers
+ deal with it. */
if ((arg ^ filp->f_flags) & FASYNC) {
- if (filp->f_op && filp->f_op->fasync) {
- error = filp->f_op->fasync(fd, filp, (arg & FASYNC) != 0);
- if (error < 0)
- goto out;
+ int on = !!(arg & FASYNC);
+ if (filp->f_op && filp->f_op->unlocked_fasync)
+ error = filp->f_op->unlocked_fasync(fd, filp, on);
+ else if (filp->f_op && filp->f_op->fasync) {
+ lock_kernel();
+ error = filp->f_op->fasync(fd, filp, on);
+ unlock_kernel();
}
+ /* AK: no else error = -EINVAL here? */
+ if (error < 0)
+ return error;
}

+ mutex_lock(&filp->f_dentry->d_inode->i_mutex);
filp->f_flags = (arg & SETFL_MASK) | (filp->f_flags & ~SETFL_MASK);
- out:
- unlock_kernel();
+ mutex_unlock(&filp->f_dentry->d_inode->i_mutex);
return error;
}

Index: linux/fs/ioctl.c
===================================================================
--- linux.orig/fs/ioctl.c
+++ linux/fs/ioctl.c
@@ -103,10 +103,13 @@ static int ioctl_fionbio(struct file *fi
if (O_NONBLOCK != O_NDELAY)
flag |= O_NDELAY;
#endif
+ /* Protect f_flags */
+ mutex_lock(&filp->f_dentry->d_inode->i_mutex);
if (on)
filp->f_flags |= flag;
else
filp->f_flags &= ~flag;
+ mutex_unlock(&filp->f_dentry->d_inode->i_mutex);
return error;
}

@@ -122,8 +125,13 @@ static int ioctl_fioasync(unsigned int f
flag = on ? FASYNC : 0;

/* Did FASYNC state change ? */
+ /* AK: potential race here: ->fasync could be called with on two times
+ in a row. We hope the drivers deal with it. */
if ((flag ^ filp->f_flags) & FASYNC) {
- if (filp->f_op && filp->f_op->fasync) {
+ if (filp->f_op && filp->f_op->unlocked_fasync) {
+ error = filp->f_op->unlocked_fasync(fd,
+ filp, on);
+ } else if (filp->f_op && filp->f_op->fasync) {
lock_kernel();
error = filp->f_op->fasync(fd, filp, on);
unlock_kernel();
@@ -133,10 +141,13 @@ static int ioctl_fioasync(unsigned int f
if (error)
return error;

+ /* Protect f_flags */
+ mutex_lock(&filp->f_dentry->d_inode->i_mutex);
if (on)
filp->f_flags |= FASYNC;
else
filp->f_flags &= ~FASYNC;
+ mutex_unlock(&filp->f_dentry->d_inode->i_mutex);
return error;
}

Index: linux/include/linux/fs.h
===================================================================
--- linux.orig/include/linux/fs.h
+++ linux/include/linux/fs.h
@@ -1237,6 +1237,7 @@ struct file_operations {
int (*fsync) (struct file *, struct dentry *, int datasync);
int (*aio_fsync) (struct kiocb *, int datasync);
int (*fasync) (int, struct file *, int);
+ int (*unlocked_fasync) (int, struct file *, int);
int (*lock) (struct file *, int, struct file_lock *);
ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
Index: linux/Documentation/filesystems/vfs.txt
===================================================================
--- linux.orig/Documentation/filesystems/vfs.txt
+++ linux/Documentation/filesystems/vfs.txt
@@ -755,6 +755,7 @@ struct file_operations {
int (*fsync) (struct file *, struct dentry *, int datasync);
int (*aio_fsync) (struct kiocb *, int datasync);
int (*fasync) (int, struct file *, int);
+ int (*unlocked_fasync) (int, struct file *, int);
int (*lock) (struct file *, int, struct file_lock *);
ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *);
ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *);
@@ -814,7 +815,9 @@ otherwise noted.
fsync: called by the fsync(2) system call

fasync: called by the fcntl(2) system call when asynchronous
- (non-blocking) mode is enabled for a file
+ (non-blocking) mode is enabled for a file. BKL hold
+
+ unlocked_fasync: like fasync, but without BKL

lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW
commands
--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
On Mon, May 19, 2008 at 02:31:11PM +0200, Andi Kleen wrote:
>
> Add a new fops entry point to allow fasync without BKL. While it's arguably
> unclear this entry point is called often enough for it really matters
> it was still relatively easy to do. And there are far less async users
> in the tree than ioctls so it's likely they can be all converted
> eventually and then the non unlocked async entry point could be dropped.
>
> There was still the problem of the actual flags change being
> protected against other setters of flags. Instead of using BKL
> for this use the i_mutex now.
>
> I also added a mutex_lock against one other flags change
> that was lockless and could potentially lose updates.
>
> There are a couple of potential problems I added comments about on.

I'd rather do a properly flag day and move lock_kernel into the
instances instead of adding this _unlocked gunk.
--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
> I'd rather do a properly flag day and move lock_kernel into the
> instances instead of adding this _unlocked gunk.

I've considered that, but it's a bit too many fasync instances
all over the tree, so I chose this method.

-Andi

--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
On Mon, 19 May 2008 16:43:05 +0200
Andi Kleen <andi@firstfloor.org> wrote:

>
> > I'd rather do a properly flag day and move lock_kernel into the
> > instances instead of adding this _unlocked gunk.
>
> I've considered that, but it's a bit too many fasync instances
> all over the tree, so I chose this method.

If I can do all the watchdog drivers in one go then we can do all the
fasync interfaces in one go. It isn't that hard other than making sure
people didn't hide them in odd places on platforms not usually built.

Alan
--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
> The good news is that none of them I looked at actually needed BKL
> (or perhaps I just missed it)

Far better to send an initial patch that simply adds all the lock/unlocks
then remove them later than worry about it immediately - that makes it
easier to verify changes and to do testing

Alan
--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
Alan Cox wrote:
> On Mon, 19 May 2008 16:43:05 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
>
>>> I'd rather do a properly flag day and move lock_kernel into the
>>> instances instead of adding this _unlocked gunk.
>> I've considered that, but it's a bit too many fasync instances
>> all over the tree, so I chose this method.
>
> If I can do all the watchdog drivers in one go then we can do all the
> fasync interfaces in one go. It isn't that hard other than making sure
> people didn't hide them in odd places on platforms not usually built.

If it's that easy for you please audit the ones then I didn't cover yet and send
me a list.

The good news is that none of them I looked at actually needed BKL
(or perhaps I just missed it)

-Andi

--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
Alan Cox wrote:
>> The good news is that none of them I looked at actually needed BKL
>> (or perhaps I just missed it)
>
> Far better to send an initial patch that simply adds all the lock/unlocks
> then remove them later than worry about it immediately - that makes it
> easier to verify changes and to do testing

I fail to see how that makes it easier than with ->fasync_unlocked.

-Andi

--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
On Mon, 19 May 2008 14:31:11 +0200 (CEST) Andi Kleen wrote:

> Index: linux/Documentation/filesystems/vfs.txt
> ===================================================================
> --- linux.orig/Documentation/filesystems/vfs.txt
> +++ linux/Documentation/filesystems/vfs.txt
> @@ -755,6 +755,7 @@ struct file_operations {
> int (*fsync) (struct file *, struct dentry *, int datasync);
> int (*aio_fsync) (struct kiocb *, int datasync);
> int (*fasync) (int, struct file *, int);
> + int (*unlocked_fasync) (int, struct file *, int);
> int (*lock) (struct file *, int, struct file_lock *);
> ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *);
> ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *);
> @@ -814,7 +815,9 @@ otherwise noted.
> fsync: called by the fsync(2) system call
>
> fasync: called by the fcntl(2) system call when asynchronous
> - (non-blocking) mode is enabled for a file
> + (non-blocking) mode is enabled for a file. BKL hold

? BKL is held.

> +
> + unlocked_fasync: like fasync, but without BKL
>
> lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW
> commands


---
~Randy
--
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/
[PATCH] [2/11] Add unlocked_fasync [ In reply to ]
Add a new fops entry point to allow fasync without BKL. While it's arguably
unclear this entry point is called often enough for it really matters
it was still relatively easy to do. And there are far less async users
in the tree than ioctls so it's likely they can be all converted
eventually and then the non unlocked async entry point could be dropped.

There was still the problem of the actual flags change being
protected against other setters of flags. Instead of using BKL
for this use the i_mutex now.

I also added a mutex_lock against one other flags change
that was lockless and could potentially lose updates.

There are a couple of potential problems I added comments about on.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>

---
Documentation/filesystems/vfs.txt | 5 ++++-
fs/fcntl.c | 22 +++++++++++++++-------
fs/ioctl.c | 13 ++++++++++++-
include/linux/fs.h | 1 +
4 files changed, 32 insertions(+), 9 deletions(-)

Index: linux/fs/fcntl.c
===================================================================
--- linux.orig/fs/fcntl.c
+++ linux/fs/fcntl.c
@@ -227,18 +227,26 @@ static int setfl(int fd, struct file * f
if (error)
return error;

- lock_kernel();
+ /* AK: potential race here. Since test is unlocked fasync could
+ be called several times in a row with on. We hope the drivers
+ deal with it. */
if ((arg ^ filp->f_flags) & FASYNC) {
- if (filp->f_op && filp->f_op->fasync) {
- error = filp->f_op->fasync(fd, filp, (arg & FASYNC) != 0);
- if (error < 0)
- goto out;
+ int on = !!(arg & FASYNC);
+ if (filp->f_op && filp->f_op->unlocked_fasync)
+ error = filp->f_op->unlocked_fasync(fd, filp, on);
+ else if (filp->f_op && filp->f_op->fasync) {
+ lock_kernel();
+ error = filp->f_op->fasync(fd, filp, on);
+ unlock_kernel();
}
+ /* AK: no else error = -EINVAL here? */
+ if (error < 0)
+ return error;
}

+ mutex_lock(&filp->f_dentry->d_inode->i_mutex);
filp->f_flags = (arg & SETFL_MASK) | (filp->f_flags & ~SETFL_MASK);
- out:
- unlock_kernel();
+ mutex_unlock(&filp->f_dentry->d_inode->i_mutex);
return error;
}

Index: linux/fs/ioctl.c
===================================================================
--- linux.orig/fs/ioctl.c
+++ linux/fs/ioctl.c
@@ -103,10 +103,13 @@ static int ioctl_fionbio(struct file *fi
if (O_NONBLOCK != O_NDELAY)
flag |= O_NDELAY;
#endif
+ /* Protect f_flags */
+ mutex_lock(&filp->f_dentry->d_inode->i_mutex);
if (on)
filp->f_flags |= flag;
else
filp->f_flags &= ~flag;
+ mutex_unlock(&filp->f_dentry->d_inode->i_mutex);
return error;
}

@@ -122,8 +125,13 @@ static int ioctl_fioasync(unsigned int f
flag = on ? FASYNC : 0;

/* Did FASYNC state change ? */
+ /* AK: potential race here: ->fasync could be called with on two times
+ in a row. We hope the drivers deal with it. */
if ((flag ^ filp->f_flags) & FASYNC) {
- if (filp->f_op && filp->f_op->fasync) {
+ if (filp->f_op && filp->f_op->unlocked_fasync) {
+ error = filp->f_op->unlocked_fasync(fd,
+ filp, on);
+ } else if (filp->f_op && filp->f_op->fasync) {
lock_kernel();
error = filp->f_op->fasync(fd, filp, on);
unlock_kernel();
@@ -133,10 +141,13 @@ static int ioctl_fioasync(unsigned int f
if (error)
return error;

+ /* Protect f_flags */
+ mutex_lock(&filp->f_dentry->d_inode->i_mutex);
if (on)
filp->f_flags |= FASYNC;
else
filp->f_flags &= ~FASYNC;
+ mutex_unlock(&filp->f_dentry->d_inode->i_mutex);
return error;
}

Index: linux/include/linux/fs.h
===================================================================
--- linux.orig/include/linux/fs.h
+++ linux/include/linux/fs.h
@@ -1237,6 +1237,7 @@ struct file_operations {
int (*fsync) (struct file *, struct dentry *, int datasync);
int (*aio_fsync) (struct kiocb *, int datasync);
int (*fasync) (int, struct file *, int);
+ int (*unlocked_fasync) (int, struct file *, int);
int (*lock) (struct file *, int, struct file_lock *);
ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
Index: linux/Documentation/filesystems/vfs.txt
===================================================================
--- linux.orig/Documentation/filesystems/vfs.txt
+++ linux/Documentation/filesystems/vfs.txt
@@ -755,6 +755,7 @@ struct file_operations {
int (*fsync) (struct file *, struct dentry *, int datasync);
int (*aio_fsync) (struct kiocb *, int datasync);
int (*fasync) (int, struct file *, int);
+ int (*unlocked_fasync) (int, struct file *, int);
int (*lock) (struct file *, int, struct file_lock *);
ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *);
ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *);
@@ -814,7 +815,9 @@ otherwise noted.
fsync: called by the fsync(2) system call

fasync: called by the fcntl(2) system call when asynchronous
- (non-blocking) mode is enabled for a file
+ (non-blocking) mode is enabled for a file. BKL hold
+
+ unlocked_fasync: like fasync, but without BKL

lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW
commands
--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
On Tue, 20 May 2008 17:28:43 +0200 (CEST)
Andi Kleen <andi@firstfloor.org> wrote:

>
> Add a new fops entry point to allow fasync without BKL.

I (again) really don't like having another entry point for this...
it'll stay around forever rather than doing this as one step and
move on.
--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
On Tue, 20 May 2008 17:28:43 +0200 (CEST) Andi Kleen wrote:

>
> Add a new fops entry point to allow fasync without BKL. While it's arguably
> unclear this entry point is called often enough for it really matters
> it was still relatively easy to do. And there are far less async users
> in the tree than ioctls so it's likely they can be all converted
> eventually and then the non unlocked async entry point could be dropped.
>
> There was still the problem of the actual flags change being
> protected against other setters of flags. Instead of using BKL
> for this use the i_mutex now.
>
> I also added a mutex_lock against one other flags change
> that was lockless and could potentially lose updates.
>
> There are a couple of potential problems I added comments about on.
>
> Signed-off-by: Andi Kleen <ak@suse.de>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
>
> ---
> Documentation/filesystems/vfs.txt | 5 ++++-
> fs/fcntl.c | 22 +++++++++++++++-------
> fs/ioctl.c | 13 ++++++++++++-
> include/linux/fs.h | 1 +
> 4 files changed, 32 insertions(+), 9 deletions(-)

> Index: linux/Documentation/filesystems/vfs.txt
> ===================================================================
> --- linux.orig/Documentation/filesystems/vfs.txt
> +++ linux/Documentation/filesystems/vfs.txt
> @@ -755,6 +755,7 @@ struct file_operations {
> int (*fsync) (struct file *, struct dentry *, int datasync);
> int (*aio_fsync) (struct kiocb *, int datasync);
> int (*fasync) (int, struct file *, int);
> + int (*unlocked_fasync) (int, struct file *, int);
> int (*lock) (struct file *, int, struct file_lock *);
> ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *);
> ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *);
> @@ -814,7 +815,9 @@ otherwise noted.
> fsync: called by the fsync(2) system call
>
> fasync: called by the fcntl(2) system call when asynchronous
> - (non-blocking) mode is enabled for a file
> + (non-blocking) mode is enabled for a file. BKL hold

BKL held.
so is that BKL must be held by the caller or this function
holds the BKL?

> +
> + unlocked_fasync: like fasync, but without BKL
>
> lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW
> commands


---
~Randy
--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
I guess my one concern with this mirrors what other people have said:
might not it be better to just push the BKL down into the fasync()
implementations and avoid adding yet another file operation? A quick
grep shows 43 drivers defining fasync() functions - and many of those
use the same one. fs/ has a few more. Obnoxious but doable, unless
there's something I'm missing?

Thanks,

jon
--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
Arjan van de Ven wrote:
> On Tue, 20 May 2008 17:28:43 +0200 (CEST)
> Andi Kleen <andi@firstfloor.org> wrote:
>
>> Add a new fops entry point to allow fasync without BKL.
>
> I (again) really don't like having another entry point for this...
> it'll stay around forever rather than doing this as one step and
> move on.

Yes the goal is for it staying around forever, correct. And ->fasync()
will go instead.

Advantage is that out of tree drivers will be compile broken which I
consider an advantage. Yes I know Linus said earlier that's not
important to him, but in this case my standards are higher than his.

Also BTW if you're that worried about the audit not getting
finished then the result would be just that lots of lock_kernel()s
would stay around. Hardly better.

But cannot do that many drivers in one step.

My goal is to just audit the remaining ones and then remove ->fasync()
and unlocked_fasync stays. Will be hopefully not that far away, since
fasync is relatively easy. The conversions are mostly for me to keep
track which ones I audited.

-Andi




--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
Jonathan Corbet wrote:
> I guess my one concern with this mirrors what other people have said:
> might not it be better to just push the BKL down into the fasync()
> implementations and avoid adding yet another file operation? A quick
> grep shows 43 drivers defining fasync() functions - and many of those
> use the same one. fs/ has a few more. Obnoxious but doable, unless
> there's something I'm missing?

See my reply to Arjan. While for complicated stuff pushing down first
is better, fasync is not that complicated and I think my strategy
with the new entry point, with the old one going away is better in this
case.

-Andi

--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
On Tue, 20 May 2008 08:58:30 -0700
Arjan van de Ven <arjan@infradead.org> wrote:

> On Tue, 20 May 2008 17:28:43 +0200 (CEST)
> Andi Kleen <andi@firstfloor.org> wrote:
>
> >
> > Add a new fops entry point to allow fasync without BKL.
>
> I (again) really don't like having another entry point for this...
> it'll stay around forever rather than doing this as one step and
> move on.

Agreed entirely - all our unlocked_foo methods we got stuck with, all our
push down everyone cases we got most cases promptly fixed and the other
lock/unlocks show up clearly in grep and help embarass the
maintainer/author 8)
--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
> Agreed entirely - all our unlocked_foo methods we got stuck with,

That's the goal actually to "get stuck with it" and ->fasync going
away.

-Andi
--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
On Tue, 20 May 2008 20:30:06 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> Arjan van de Ven wrote:
> > On Tue, 20 May 2008 17:28:43 +0200 (CEST)
> > Andi Kleen <andi@firstfloor.org> wrote:
> >
> >> Add a new fops entry point to allow fasync without BKL.
> >
> > I (again) really don't like having another entry point for this...
> > it'll stay around forever rather than doing this as one step and
> > move on.
>
> Yes the goal is for it staying around forever, correct. And ->fasync()
> will go instead.
>
> Advantage is that out of tree drivers will be compile broken which I
> consider an advantage. Yes I know Linus said earlier that's not
> important to him, but in this case my standards are higher than his.

I'd say it's just different standards.
My concern is that the new API as long lived is ugly and not the right
thing. I assume Linus and others have similar concerns, and weigh that
over the "some obscure out of tree driver might break".
--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
> My concern is that the new API as long lived is ugly and not the right
> thing. I assume Linus and others have similar concerns, and weigh that
> over the "some obscure out of tree driver might break".

What do you find ugly exactly? The prefix "unlocked_" ? Other than
that there is no difference.

Duplicated entry points are not great, but they will be going away.

-Andi


--
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/
Re: [PATCH] [2/11] Add unlocked_fasync [ In reply to ]
On Wed, 21 May 2008 01:35:21 +0200
Andi Kleen <andi@firstfloor.org> wrote:

>
> > My concern is that the new API as long lived is ugly and not the
> > right thing. I assume Linus and others have similar concerns, and
> > weigh that over the "some obscure out of tree driver might break".
>
> What do you find ugly exactly? The prefix "unlocked_" ?

yes exactly

--
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/