Re: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
Roland Dreier wrote: > BTW: any idea how this ever got triggered? The only way I can see is > if you're either not using libipathverbs and libibverbs and you just > create the CQ some other way, which seems unlikely. Do you know how > Jason triggered this bug? Yes, it was because he was using 32-bit userspace and so it was impossible to libipathverbs to mmap the address the kernel driver was looking for. So the mmap failed and the pending mmap never got taken off the list. Oh, OK. Got it. That problem is on my list, too, along with the other pending_mmap-related cleanups you suggested. Hopefully I'll have a patch finished tonight. - 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: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
> BTW: any idea how this ever got triggered? The only way I can see is > if you're either not using libipathverbs and libibverbs and you just > create the CQ some other way, which seems unlikely. Do you know how > Jason triggered this bug? Yes, it was because he was using 32-bit userspace and so it was impossible to libipathverbs to mmap the address the kernel driver was looking for. So the mmap failed and the pending mmap never got taken off the list. - R. - 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: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
Roland Dreier wrote: I just queued all of this for 2.6.22. Is there any chance of getting a fix for the use-after-free that can be caused by allocating something from userspace, failing to mmap the buffer and then exiting? To see what happens, look at how ipath_create_cq sticks a struct ipath_mmap_info into the pending mmap "list" (and yes it would be much cleaner to just use struct list_head here rather than reimplementing a linked list yourself), and then look at how ipath_destroy_cq() frees the same structure without checking if it has been removed from the pending mmap list. BTW: any idea how this ever got triggered? The only way I can see is if you're either not using libipathverbs and libibverbs and you just create the CQ some other way, which seems unlikely. Do you know how Jason triggered this bug? I'm also going to fix a problem where hitting the maximum number of CQs causes an error return, but doesn't clean up the pending list and thus leaks memory. Regards, Robert. - 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: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
Roland Dreier wrote: I just queued all of this for 2.6.22. Is there any chance of getting a fix for the use-after-free that can be caused by allocating something from userspace, failing to mmap the buffer and then exiting? To see what happens, look at how ipath_create_cq sticks a struct ipath_mmap_info into the pending mmap list (and yes it would be much cleaner to just use struct list_head here rather than reimplementing a linked list yourself), and then look at how ipath_destroy_cq() frees the same structure without checking if it has been removed from the pending mmap list. BTW: any idea how this ever got triggered? The only way I can see is if you're either not using libipathverbs and libibverbs and you just create the CQ some other way, which seems unlikely. Do you know how Jason triggered this bug? I'm also going to fix a problem where hitting the maximum number of CQs causes an error return, but doesn't clean up the pending list and thus leaks memory. Regards, Robert. - 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: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
BTW: any idea how this ever got triggered? The only way I can see is if you're either not using libipathverbs and libibverbs and you just create the CQ some other way, which seems unlikely. Do you know how Jason triggered this bug? Yes, it was because he was using 32-bit userspace and so it was impossible to libipathverbs to mmap the address the kernel driver was looking for. So the mmap failed and the pending mmap never got taken off the list. - R. - 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: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
Roland Dreier wrote: BTW: any idea how this ever got triggered? The only way I can see is if you're either not using libipathverbs and libibverbs and you just create the CQ some other way, which seems unlikely. Do you know how Jason triggered this bug? Yes, it was because he was using 32-bit userspace and so it was impossible to libipathverbs to mmap the address the kernel driver was looking for. So the mmap failed and the pending mmap never got taken off the list. Oh, OK. Got it. That problem is on my list, too, along with the other pending_mmap-related cleanups you suggested. Hopefully I'll have a patch finished tonight. - 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: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
Roland Dreier wrote: > Is there any chance of getting a fix for the use-after-free that can > be caused by allocating something from userspace, failing to mmap the > buffer and then exiting? To see what happens, look at how > ipath_create_cq sticks a struct ipath_mmap_info into the pending mmap > "list" (and yes it would be much cleaner to just use struct list_head > here rather than reimplementing a linked list yourself), and then look > at how ipath_destroy_cq() frees the same structure without checking if > it has been removed from the pending mmap list. By the way, would it help get this fixed if I opened a bug on openfabrics.org? Or is that a waste of time? We're tracking it here (bug 12010 on our internal bugzilla), and it's on my list to get done "soon". I'm currently in the middle of some other bug fixes, but when I get to a good stopping point, I'll get this fixed. Shouldn't be too difficult. If you'd like to track it yourself, feel free to open an OpenFabrics bug. I'll update the bug when I get a patch done. Regards, Robert. - 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: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
> Is there any chance of getting a fix for the use-after-free that can > be caused by allocating something from userspace, failing to mmap the > buffer and then exiting? To see what happens, look at how > ipath_create_cq sticks a struct ipath_mmap_info into the pending mmap > "list" (and yes it would be much cleaner to just use struct list_head > here rather than reimplementing a linked list yourself), and then look > at how ipath_destroy_cq() frees the same structure without checking if > it has been removed from the pending mmap list. By the way, would it help get this fixed if I opened a bug on openfabrics.org? Or is that a waste of time? - 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 00 of 33] Set of ipath patches for 2.6.22
I just queued all of this for 2.6.22. Is there any chance of getting a fix for the use-after-free that can be caused by allocating something from userspace, failing to mmap the buffer and then exiting? To see what happens, look at how ipath_create_cq sticks a struct ipath_mmap_info into the pending mmap "list" (and yes it would be much cleaner to just use struct list_head here rather than reimplementing a linked list yourself), and then look at how ipath_destroy_cq() frees the same structure without checking if it has been removed from the pending mmap list. - R. - 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 00 of 33] Set of ipath patches for 2.6.22
I just queued all of this for 2.6.22. Is there any chance of getting a fix for the use-after-free that can be caused by allocating something from userspace, failing to mmap the buffer and then exiting? To see what happens, look at how ipath_create_cq sticks a struct ipath_mmap_info into the pending mmap list (and yes it would be much cleaner to just use struct list_head here rather than reimplementing a linked list yourself), and then look at how ipath_destroy_cq() frees the same structure without checking if it has been removed from the pending mmap list. - R. - 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: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
Is there any chance of getting a fix for the use-after-free that can be caused by allocating something from userspace, failing to mmap the buffer and then exiting? To see what happens, look at how ipath_create_cq sticks a struct ipath_mmap_info into the pending mmap list (and yes it would be much cleaner to just use struct list_head here rather than reimplementing a linked list yourself), and then look at how ipath_destroy_cq() frees the same structure without checking if it has been removed from the pending mmap list. By the way, would it help get this fixed if I opened a bug on openfabrics.org? Or is that a waste of time? - 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: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
Roland Dreier wrote: Is there any chance of getting a fix for the use-after-free that can be caused by allocating something from userspace, failing to mmap the buffer and then exiting? To see what happens, look at how ipath_create_cq sticks a struct ipath_mmap_info into the pending mmap list (and yes it would be much cleaner to just use struct list_head here rather than reimplementing a linked list yourself), and then look at how ipath_destroy_cq() frees the same structure without checking if it has been removed from the pending mmap list. By the way, would it help get this fixed if I opened a bug on openfabrics.org? Or is that a waste of time? We're tracking it here (bug 12010 on our internal bugzilla), and it's on my list to get done soon. I'm currently in the middle of some other bug fixes, but when I get to a good stopping point, I'll get this fixed. Shouldn't be too difficult. If you'd like to track it yourself, feel free to open an OpenFabrics bug. I'll update the bug when I get a patch done. Regards, Robert. - 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 00 of 33] Set of ipath patches for 2.6.22
Are these really all for 2.6.22? Some of them seem like bugfixes that you would want in 2.6.21... - 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 00 of 33] Set of ipath patches for 2.6.22
Are these really all for 2.6.22? Some of them seem like bugfixes that you would want in 2.6.21... - 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/
[PATCH 00 of 33] Set of ipath patches for 2.6.22
- 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/
[PATCH 00 of 33] Set of ipath patches for 2.6.22
- 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/
