Re: [patch] raw: don't allow the creation of a raw device with minor number 0
==> Regarding Re: [patch] raw: don't allow the creation of a raw device with minor number 0; Jan Engelhardt <[EMAIL PROTECTED]> adds: jengelh> On Jan 12 2007 11:32, Jeff Moyer wrote: >> Date: Fri, 12 Jan 2007 11:32:11 -0500 >> From: Jeff Moyer <[EMAIL PROTECTED]> >> To: Linux Kernel Mailing List >> Cc: Steven Fernandez <[EMAIL PROTECTED]>, Andrew Morton <[EMAIL PROTECTED]> >> Subject: [patch] raw: don't allow the creation of a raw device with minor >> number 0 >> >> Hi, >> >> Minor number 0 (under the raw major) is reserved for the rawctl device >> file, which is used to query, set, and unset raw device bindings. >> However, the ioctl interface does not protect the user from specifying >> a raw device with minor number 0: jengelh> No idea what to say about this... probably: jengelh> What: RAW driver (CONFIG_RAW_DRIVER) jengelh> When: December 2005 jengelh> Why:declared obsolete since kernel 2.6.3 jengelh> O_DIRECT can be used instead jengelh> Who:Adrian Bunk <[EMAIL PROTECTED]> It's still present, still used, and so would benefit from being fixed, in my opinion. Cheers, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] raw: don't allow the creation of a raw device with minor number 0
== Regarding Re: [patch] raw: don't allow the creation of a raw device with minor number 0; Jan Engelhardt [EMAIL PROTECTED] adds: jengelh On Jan 12 2007 11:32, Jeff Moyer wrote: Date: Fri, 12 Jan 2007 11:32:11 -0500 From: Jeff Moyer [EMAIL PROTECTED] To: Linux Kernel Mailing List linux-kernel@vger.kernel.org Cc: Steven Fernandez [EMAIL PROTECTED], Andrew Morton [EMAIL PROTECTED] Subject: [patch] raw: don't allow the creation of a raw device with minor number 0 Hi, Minor number 0 (under the raw major) is reserved for the rawctl device file, which is used to query, set, and unset raw device bindings. However, the ioctl interface does not protect the user from specifying a raw device with minor number 0: jengelh No idea what to say about this... probably: jengelh What: RAW driver (CONFIG_RAW_DRIVER) jengelh When: December 2005 jengelh Why:declared obsolete since kernel 2.6.3 jengelh O_DIRECT can be used instead jengelh Who:Adrian Bunk [EMAIL PROTECTED] It's still present, still used, and so would benefit from being fixed, in my opinion. Cheers, Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] aio: fix buggy put_ioctx call in aio_complete
==> Regarding RE: [patch] aio: fix buggy put_ioctx call in aio_complete; "Chen, Kenneth W" <[EMAIL PROTECTED]> adds: kenneth.w.chen> [EMAIL PROTECTED] wrote on Thursday, December 21, 2006 8:56 kenneth.w.chen> AM I think I'm going to abandon this whole synchronize kenneth.w.chen> thing and going to put the wake up call inside ioctx_lock kenneth.w.chen> spin lock along with the other patch you mentioned above in kenneth.w.chen> the waiter path. On top of that, I have another patch kenneth.w.chen> attempts to perform wake-up only when the waiter can truly kenneth.w.chen> proceed in aio_read_evt so dribbling I/O completion doesn't kenneth.w.chen> inefficiently waking up waiter too frequently and only to kenneth.w.chen> have waiter put back to sleep again. I will dig that up and kenneth.w.chen> experiment. >> In the mean time, can't we simply take the context lock in >> wait_for_all_aios? Unless I missed something, I think that will address >> the reference count problem. kenneth.w.chen> Take ioctx_lock is one part, the other part is to move kenneth.w.chen> spin_unlock_irqrestore(>ctx_lock, flags); kenneth.w.chen> in aio_complete all the way down to the end of the kenneth.w.chen> function, after wakeup and put_ioctx. But then the ref kenneth.w.chen> counting on ioctx in aio_complete path is Meaningless, kenneth.w.chen> which is the thing I'm trying to remove. OK, right. But are we simply papering over the real problem? Earlier in this thread, you stated: > flush_workqueue() is not allowed to be called in the softirq context. > However, aio_complete() called from I/O interrupt can potentially call > put_ioctx with last ref count on ioctx and trigger a bug warning. It > is simply incorrect to perform ioctx freeing from aio_complete. But how do we end up with the last reference to the ioctx in the aio completion path? That's a question I haven't seen answered. -Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] aio: fix buggy put_ioctx call in aio_complete
==> Regarding RE: [patch] aio: fix buggy put_ioctx call in aio_complete; "Chen, Kenneth W" <[EMAIL PROTECTED]> adds: kenneth.w.chen> I think I'm going to abandon this whole synchronize thing kenneth.w.chen> and going to put the wake up call inside ioctx_lock spin kenneth.w.chen> lock along with the other patch you mentioned above in the kenneth.w.chen> waiter path. On top of that, I have another patch attempts kenneth.w.chen> to perform wake-up only when the waiter can truly proceed kenneth.w.chen> in aio_read_evt so dribbling I/O completion doesn't kenneth.w.chen> inefficiently waking up waiter too frequently and only to kenneth.w.chen> have waiter put back to sleep again. I will dig that up and kenneth.w.chen> experiment. In the mean time, can't we simply take the context lock in wait_for_all_aios? Unless I missed something, I think that will address the reference count problem. Thanks, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] aio: fix buggy put_ioctx call in aio_complete
== Regarding RE: [patch] aio: fix buggy put_ioctx call in aio_complete; Chen, Kenneth W [EMAIL PROTECTED] adds: kenneth.w.chen I think I'm going to abandon this whole synchronize thing kenneth.w.chen and going to put the wake up call inside ioctx_lock spin kenneth.w.chen lock along with the other patch you mentioned above in the kenneth.w.chen waiter path. On top of that, I have another patch attempts kenneth.w.chen to perform wake-up only when the waiter can truly proceed kenneth.w.chen in aio_read_evt so dribbling I/O completion doesn't kenneth.w.chen inefficiently waking up waiter too frequently and only to kenneth.w.chen have waiter put back to sleep again. I will dig that up and kenneth.w.chen experiment. In the mean time, can't we simply take the context lock in wait_for_all_aios? Unless I missed something, I think that will address the reference count problem. Thanks, Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] aio: fix buggy put_ioctx call in aio_complete
== Regarding RE: [patch] aio: fix buggy put_ioctx call in aio_complete; Chen, Kenneth W [EMAIL PROTECTED] adds: kenneth.w.chen [EMAIL PROTECTED] wrote on Thursday, December 21, 2006 8:56 kenneth.w.chen AM I think I'm going to abandon this whole synchronize kenneth.w.chen thing and going to put the wake up call inside ioctx_lock kenneth.w.chen spin lock along with the other patch you mentioned above in kenneth.w.chen the waiter path. On top of that, I have another patch kenneth.w.chen attempts to perform wake-up only when the waiter can truly kenneth.w.chen proceed in aio_read_evt so dribbling I/O completion doesn't kenneth.w.chen inefficiently waking up waiter too frequently and only to kenneth.w.chen have waiter put back to sleep again. I will dig that up and kenneth.w.chen experiment. In the mean time, can't we simply take the context lock in wait_for_all_aios? Unless I missed something, I think that will address the reference count problem. kenneth.w.chen Take ioctx_lock is one part, the other part is to move kenneth.w.chen spin_unlock_irqrestore(ctx-ctx_lock, flags); kenneth.w.chen in aio_complete all the way down to the end of the kenneth.w.chen function, after wakeup and put_ioctx. But then the ref kenneth.w.chen counting on ioctx in aio_complete path is Meaningless, kenneth.w.chen which is the thing I'm trying to remove. OK, right. But are we simply papering over the real problem? Earlier in this thread, you stated: flush_workqueue() is not allowed to be called in the softirq context. However, aio_complete() called from I/O interrupt can potentially call put_ioctx with last ref count on ioctx and trigger a bug warning. It is simply incorrect to perform ioctx freeing from aio_complete. But how do we end up with the last reference to the ioctx in the aio completion path? That's a question I haven't seen answered. -Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
