Re: [patch 00/21] 2.6.19-stable review
On Wed, Feb 21, 2007 at 02:36:40PM +0100, Stefan Richter wrote: > Greg KH wrote: > > This is the start of the stable review cycle for the 2.6.19.5 release. > > > > This will probably be the last release of the 2.6.19-stable series, so > > if there are patches that you feel should be applied to that tree, > > please let me know. > > There is one here: "Missing critical phys_to_virt in lib/swiotlb.c". > http://lkml.org/lkml/2007/2/4/116 > It fixes a DMA related bug which was seen with a variety of drivers > especially on EM64T machines with more than 3GB RAM. I hope you can > extract the patch from this MIME attachment. > > Adrian, AFAICS it applies as-is to 2.6.16.y too. I don't have a machine > to test personally, but it is quite obvious. Thanks. It applies fine and it's now in my tree. > The mentioned bigger patch has been merged by Linus between 2.6.20 and > 2.6.21-rc1. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/21] 2.6.19-stable review
On Wed, Feb 21, 2007 at 02:36:40PM +0100, Stefan Richter wrote: Greg KH wrote: This is the start of the stable review cycle for the 2.6.19.5 release. This will probably be the last release of the 2.6.19-stable series, so if there are patches that you feel should be applied to that tree, please let me know. There is one here: Missing critical phys_to_virt in lib/swiotlb.c. http://lkml.org/lkml/2007/2/4/116 It fixes a DMA related bug which was seen with a variety of drivers especially on EM64T machines with more than 3GB RAM. I hope you can extract the patch from this MIME attachment. Adrian, AFAICS it applies as-is to 2.6.16.y too. I don't have a machine to test personally, but it is quite obvious. Thanks. It applies fine and it's now in my tree. The mentioned bigger patch has been merged by Linus between 2.6.20 and 2.6.21-rc1. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/21] 2.6.19-stable review
Zwane Mwaikambo <[EMAIL PROTECTED]> writes: > Hi Eric, > Thanks for getting this cruft cleaned up. I have a few comments > regarding; > > handle-irqs-pending-in-irr-during-irq-migration.patch > > 1) It relies on checking the IRR, this could race with the corresponding > vector bit being set by hardware. The mostly correct assumption is that because that vector is masked and has been for a while we should not have a race. > 2) apic_handle_pending_vector is oddly named since it doesn't actually > handle a pending vector but drops it if it has been freed. > > 3) It looks complex > > So how about the following scheme. Add a check in do_IRQ whether the irq's > domain contains the current cpu, if not we free the vector upon handler > completion. Because that check will leak vector entries. And after a while the box will be unable to migrate irqs, and possible something more severe. Yes. It is moderately complex. After receiving a little feedback like this I have something much simpler and more robust mered into the current git for 2.6.21. Which except for my stupid it doesn't compile on uniprocessor bug should be good. However it took me 13 patches to come up with something clean and simple. Basically I wait until an irq has arrived at the new location until I free it, and even then I send a lowest priority IPI to land to the cpu in question before I free it so that if that other cpu has it stuck in the pending bit that gets processed before the freeing happens. Even with that I'm still only 99% certain that the last in flight irq before we reprogrammed it actually made it to a different cpus local apic. But there appears to be nothing more that I can do. I have exhausted every property I can find. Added to that is the fact that simply handing the irq in IRR empirically is sufficient. So I truly believe in practice the code in my first patch is sufficient, and what I am doing for 2.6.21 is better simply because it is simpler and much more paranoid and thus affords us with a bit of margin. If one irq is delivered to a local apic you would expect the previous incarnation of that irq to be delivered to a local apic first... Honestly I would be completely happy if all that gets back ported is my stupid patch, that adds: if (!disable_apic) ack_APIC_irq(); Before if (printk_ratelimit()) printk(KERN_EMERG "%s: %d.%d No irq handler for vector\n", In do_IRQ. That is sufficient in most cases to keep the box from falling over. Is obviously correct. And only emits a scary message. If that isn't sufficient to give everyone warm fuzzy. I think the patch under discussion make sense for a backport. At least it doesn't change lot so things. Honestly. I am happy if I fix this for 2.6.21. Beyond that I am happy to offer my advice but I have no expectations of anyone following it. Possibly I suffer from giving to complete an answer? What are the rules that are supposed to govern backports to stable trees these days anyway? Eric - 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/21] 2.6.19-stable review
On Tue, 27 Feb 2007, Eric W. Biederman wrote: > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch > >> > >> That's mainly an Andi decision. Let's cc him. > > > > Would be good to have Eric also ack them as safe and obvious. > > > > Btw, that latter one has corrupted sign-offs from Andi (it's in the middle > > of the text, very confusing). > > There are two questions. > 1) What can we do to make the situation better. > 2) Is the hole completely plugged. > > When I wrote the patch I had the local apic priorities backwards in my > head. So apic_in_service_vector can return the wrong value if two > irqs are in service. Now I don't think we allows ourselves to enable > interrupts in an interrupt service routing until after we have acked > the local apic so this should be harmless. The fix is also trivial > of just having apic_in_service_vector return: "~get_irq_regs()->orig_rax". > > Except for that one possible problem everything I can think of are > just theoretical cracks at this point, and they don't make the > situation any worse. > > Given that this patch has appears to have undergone a noticeable > amount of testing, by people other than myself, and clears up the > symptoms. I have no problem Hi Eric, Thanks for getting this cruft cleaned up. I have a few comments regarding; handle-irqs-pending-in-irr-during-irq-migration.patch 1) It relies on checking the IRR, this could race with the corresponding vector bit being set by hardware. 2) apic_handle_pending_vector is oddly named since it doesn't actually handle a pending vector but drops it if it has been freed. 3) It looks complex So how about the following scheme. Add a check in do_IRQ whether the irq's domain contains the current cpu, if not we free the vector upon handler completion. Cheers, Zwane - 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/21] 2.6.19-stable review
On Tue, 27 Feb 2007, Eric W. Biederman wrote: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch That's mainly an Andi decision. Let's cc him. Would be good to have Eric also ack them as safe and obvious. Btw, that latter one has corrupted sign-offs from Andi (it's in the middle of the text, very confusing). There are two questions. 1) What can we do to make the situation better. 2) Is the hole completely plugged. When I wrote the patch I had the local apic priorities backwards in my head. So apic_in_service_vector can return the wrong value if two irqs are in service. Now I don't think we allows ourselves to enable interrupts in an interrupt service routing until after we have acked the local apic so this should be harmless. The fix is also trivial of just having apic_in_service_vector return: ~get_irq_regs()-orig_rax. Except for that one possible problem everything I can think of are just theoretical cracks at this point, and they don't make the situation any worse. Given that this patch has appears to have undergone a noticeable amount of testing, by people other than myself, and clears up the symptoms. I have no problem Hi Eric, Thanks for getting this cruft cleaned up. I have a few comments regarding; handle-irqs-pending-in-irr-during-irq-migration.patch 1) It relies on checking the IRR, this could race with the corresponding vector bit being set by hardware. 2) apic_handle_pending_vector is oddly named since it doesn't actually handle a pending vector but drops it if it has been freed. 3) It looks complex So how about the following scheme. Add a check in do_IRQ whether the irq's domain contains the current cpu, if not we free the vector upon handler completion. Cheers, Zwane - 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/21] 2.6.19-stable review
Zwane Mwaikambo [EMAIL PROTECTED] writes: Hi Eric, Thanks for getting this cruft cleaned up. I have a few comments regarding; handle-irqs-pending-in-irr-during-irq-migration.patch 1) It relies on checking the IRR, this could race with the corresponding vector bit being set by hardware. The mostly correct assumption is that because that vector is masked and has been for a while we should not have a race. 2) apic_handle_pending_vector is oddly named since it doesn't actually handle a pending vector but drops it if it has been freed. 3) It looks complex So how about the following scheme. Add a check in do_IRQ whether the irq's domain contains the current cpu, if not we free the vector upon handler completion. Because that check will leak vector entries. And after a while the box will be unable to migrate irqs, and possible something more severe. Yes. It is moderately complex. After receiving a little feedback like this I have something much simpler and more robust mered into the current git for 2.6.21. Which except for my stupid it doesn't compile on uniprocessor bug should be good. However it took me 13 patches to come up with something clean and simple. Basically I wait until an irq has arrived at the new location until I free it, and even then I send a lowest priority IPI to land to the cpu in question before I free it so that if that other cpu has it stuck in the pending bit that gets processed before the freeing happens. Even with that I'm still only 99% certain that the last in flight irq before we reprogrammed it actually made it to a different cpus local apic. But there appears to be nothing more that I can do. I have exhausted every property I can find. Added to that is the fact that simply handing the irq in IRR empirically is sufficient. So I truly believe in practice the code in my first patch is sufficient, and what I am doing for 2.6.21 is better simply because it is simpler and much more paranoid and thus affords us with a bit of margin. If one irq is delivered to a local apic you would expect the previous incarnation of that irq to be delivered to a local apic first... Honestly I would be completely happy if all that gets back ported is my stupid patch, that adds: if (!disable_apic) ack_APIC_irq(); Before if (printk_ratelimit()) printk(KERN_EMERG %s: %d.%d No irq handler for vector\n, In do_IRQ. That is sufficient in most cases to keep the box from falling over. Is obviously correct. And only emits a scary message. If that isn't sufficient to give everyone warm fuzzy. I think the patch under discussion make sense for a backport. At least it doesn't change lot so things. Honestly. I am happy if I fix this for 2.6.21. Beyond that I am happy to offer my advice but I have no expectations of anyone following it. Possibly I suffer from giving to complete an answer? What are the rules that are supposed to govern backports to stable trees these days anyway? Eric - 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/21] 2.6.19-stable review
Hmm.. I seem to have failed to send out this reply a few days ago :( Linus Torvalds <[EMAIL PROTECTED]> writes: > On Wed, 21 Feb 2007, Andrew Morton wrote: >> > >> > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch >> > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch >> >> That's mainly an Andi decision. Let's cc him. > > Would be good to have Eric also ack them as safe and obvious. > > Btw, that latter one has corrupted sign-offs from Andi (it's in the middle > of the text, very confusing). There are two questions. 1) What can we do to make the situation better. 2) Is the hole completely plugged. When I wrote the patch I had the local apic priorities backwards in my head. So apic_in_service_vector can return the wrong value if two irqs are in service. Now I don't think we allows ourselves to enable interrupts in an interrupt service routing until after we have acked the local apic so this should be harmless. The fix is also trivial of just having apic_in_service_vector return: "~get_irq_regs()->orig_rax". Except for that one possible problem everything I can think of are just theoretical cracks at this point, and they don't make the situation any worse. Given that this patch has appears to have undergone a noticeable amount of testing, by people other than myself, and clears up the symptoms. I have no problem Eric - 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/21] 2.6.19-stable review
Hmm.. I seem to have failed to send out this reply a few days ago :( Linus Torvalds [EMAIL PROTECTED] writes: On Wed, 21 Feb 2007, Andrew Morton wrote: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch That's mainly an Andi decision. Let's cc him. Would be good to have Eric also ack them as safe and obvious. Btw, that latter one has corrupted sign-offs from Andi (it's in the middle of the text, very confusing). There are two questions. 1) What can we do to make the situation better. 2) Is the hole completely plugged. When I wrote the patch I had the local apic priorities backwards in my head. So apic_in_service_vector can return the wrong value if two irqs are in service. Now I don't think we allows ourselves to enable interrupts in an interrupt service routing until after we have acked the local apic so this should be harmless. The fix is also trivial of just having apic_in_service_vector return: ~get_irq_regs()-orig_rax. Except for that one possible problem everything I can think of are just theoretical cracks at this point, and they don't make the situation any worse. Given that this patch has appears to have undergone a noticeable amount of testing, by people other than myself, and clears up the symptoms. I have no problem Eric - 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/21] 2.6.19-stable review
Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.19.5 release.
>
> This will probably be the last release of the 2.6.19-stable series, so
> if there are patches that you feel should be applied to that tree,
> please let me know.
This seems appropriate for 2.6.19-stable. It fixes CVE-2006-5753,
listed as a "high" security risk. Taken from hg kernel repository,
and already in 2.6.20.
# HG changeset patch
# User Eric Sandeen <[EMAIL PROTECTED]>
# Date 1168070123 28800
# Node ID 2ce8209bd3b1a96b6701821b70144b69d61098c6
# Parent e1242b48d243513737eaa39f3ad0a7d849030359
[PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
CVE-2006-5753 is for a case where an inode can be marked bad, switching
the ops to bad_inode_ops, which are all connected as:
static int return_EIO(void)
{
return -EIO;
}
#define EIO_ERROR ((void *) (return_EIO))
static struct inode_operations bad_inode_ops =
{
.create = bad_inode_create
...etc...
The problem here is that the void cast causes return types to not be
promoted, and for ops such as listxattr which expect more than 32 bits of
return value, the 32-bit -EIO is interpreted as a large positive 64-bit
number, i.e. 0xfffa instead of 0xfffa.
This goes particularly badly when the return value is taken as a number of
bytes to copy into, say, a user's buffer for example...
I originally had coded up the fix by creating a return_EIO_ macro
for each return type, like this:
static int return_EIO_int(void)
{
return -EIO;
}
#define EIO_ERROR_INT ((void *) (return_EIO_int))
static struct inode_operations bad_inode_ops =
{
.create = EIO_ERROR_INT,
...etc...
but Al felt that it was probably better to create an EIO-returner for each
actual op signature. Since so few ops share a signature, I just went ahead
& created an EIO function for each individual file & inode op that returns
a value.
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
committer: Linus Torvalds <[EMAIL PROTECTED]> 1168070123 -0800
--- a/fs/bad_inode.cFri Jan 05 23:55:23 2007 -0800
+++ b/fs/bad_inode.cFri Jan 05 23:55:23 2007 -0800
@@ -14,59 +14,307 @@
#include
#include
#include
-
-static int return_EIO(void)
-{
- return -EIO;
-}
-
-#define EIO_ERROR ((void *) (return_EIO))
+#include
+
+
+static loff_t bad_file_llseek(struct file *file, loff_t offset, int origin)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_read(struct file *filp, char __user *buf,
+ size_t size, loff_t *ppos)
+{
+return -EIO;
+}
+
+static ssize_t bad_file_write(struct file *filp, const char __user *buf,
+ size_t siz, loff_t *ppos)
+{
+return -EIO;
+}
+
+static ssize_t bad_file_aio_read(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t pos)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t pos)
+{
+ return -EIO;
+}
+
+static int bad_file_readdir(struct file *filp, void *dirent, filldir_t filldir)
+{
+ return -EIO;
+}
+
+static unsigned int bad_file_poll(struct file *filp, poll_table *wait)
+{
+ return POLLERR;
+}
+
+static int bad_file_ioctl (struct inode *inode, struct file *filp,
+ unsigned int cmd, unsigned long arg)
+{
+ return -EIO;
+}
+
+static long bad_file_unlocked_ioctl(struct file *file, unsigned cmd,
+ unsigned long arg)
+{
+ return -EIO;
+}
+
+static long bad_file_compat_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ return -EIO;
+}
+
+static int bad_file_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ return -EIO;
+}
+
+static int bad_file_open(struct inode *inode, struct file *filp)
+{
+ return -EIO;
+}
+
+static int bad_file_flush(struct file *file, fl_owner_t id)
+{
+ return -EIO;
+}
+
+static int bad_file_release(struct inode *inode, struct file *filp)
+{
+ return -EIO;
+}
+
+static int bad_file_fsync(struct file *file, struct dentry *dentry,
+ int datasync)
+{
+ return -EIO;
+}
+
+static int bad_file_aio_fsync(struct kiocb *iocb, int datasync)
+{
+ return -EIO;
+}
+
+static int bad_file_fasync(int fd, struct file *filp, int on)
+{
+ return -EIO;
+}
+
+static int bad_file_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_sendfile(struct file *in_file, loff_t *ppos,
+ size_t count, read_actor_t actor, void *target)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_sendpage(struct file *file, struct page *page,
+ int off, size_t len, loff_t *pos,
Re: [patch 00/21] 2.6.19-stable review
Greg KH wrote:
This is the start of the stable review cycle for the 2.6.19.5 release.
This will probably be the last release of the 2.6.19-stable series, so
if there are patches that you feel should be applied to that tree,
please let me know.
This seems appropriate for 2.6.19-stable. It fixes CVE-2006-5753,
listed as a high security risk. Taken from hg kernel repository,
and already in 2.6.20.
# HG changeset patch
# User Eric Sandeen [EMAIL PROTECTED]
# Date 1168070123 28800
# Node ID 2ce8209bd3b1a96b6701821b70144b69d61098c6
# Parent e1242b48d243513737eaa39f3ad0a7d849030359
[PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
CVE-2006-5753 is for a case where an inode can be marked bad, switching
the ops to bad_inode_ops, which are all connected as:
static int return_EIO(void)
{
return -EIO;
}
#define EIO_ERROR ((void *) (return_EIO))
static struct inode_operations bad_inode_ops =
{
.create = bad_inode_create
...etc...
The problem here is that the void cast causes return types to not be
promoted, and for ops such as listxattr which expect more than 32 bits of
return value, the 32-bit -EIO is interpreted as a large positive 64-bit
number, i.e. 0xfffa instead of 0xfffa.
This goes particularly badly when the return value is taken as a number of
bytes to copy into, say, a user's buffer for example...
I originally had coded up the fix by creating a return_EIO_TYPE macro
for each return type, like this:
static int return_EIO_int(void)
{
return -EIO;
}
#define EIO_ERROR_INT ((void *) (return_EIO_int))
static struct inode_operations bad_inode_ops =
{
.create = EIO_ERROR_INT,
...etc...
but Al felt that it was probably better to create an EIO-returner for each
actual op signature. Since so few ops share a signature, I just went ahead
created an EIO function for each individual file inode op that returns
a value.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Cc: Al Viro [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
committer: Linus Torvalds [EMAIL PROTECTED] 1168070123 -0800
--- a/fs/bad_inode.cFri Jan 05 23:55:23 2007 -0800
+++ b/fs/bad_inode.cFri Jan 05 23:55:23 2007 -0800
@@ -14,59 +14,307 @@
#include linux/time.h
#include linux/smp_lock.h
#include linux/namei.h
-
-static int return_EIO(void)
-{
- return -EIO;
-}
-
-#define EIO_ERROR ((void *) (return_EIO))
+#include linux/poll.h
+
+
+static loff_t bad_file_llseek(struct file *file, loff_t offset, int origin)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_read(struct file *filp, char __user *buf,
+ size_t size, loff_t *ppos)
+{
+return -EIO;
+}
+
+static ssize_t bad_file_write(struct file *filp, const char __user *buf,
+ size_t siz, loff_t *ppos)
+{
+return -EIO;
+}
+
+static ssize_t bad_file_aio_read(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t pos)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t pos)
+{
+ return -EIO;
+}
+
+static int bad_file_readdir(struct file *filp, void *dirent, filldir_t filldir)
+{
+ return -EIO;
+}
+
+static unsigned int bad_file_poll(struct file *filp, poll_table *wait)
+{
+ return POLLERR;
+}
+
+static int bad_file_ioctl (struct inode *inode, struct file *filp,
+ unsigned int cmd, unsigned long arg)
+{
+ return -EIO;
+}
+
+static long bad_file_unlocked_ioctl(struct file *file, unsigned cmd,
+ unsigned long arg)
+{
+ return -EIO;
+}
+
+static long bad_file_compat_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ return -EIO;
+}
+
+static int bad_file_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ return -EIO;
+}
+
+static int bad_file_open(struct inode *inode, struct file *filp)
+{
+ return -EIO;
+}
+
+static int bad_file_flush(struct file *file, fl_owner_t id)
+{
+ return -EIO;
+}
+
+static int bad_file_release(struct inode *inode, struct file *filp)
+{
+ return -EIO;
+}
+
+static int bad_file_fsync(struct file *file, struct dentry *dentry,
+ int datasync)
+{
+ return -EIO;
+}
+
+static int bad_file_aio_fsync(struct kiocb *iocb, int datasync)
+{
+ return -EIO;
+}
+
+static int bad_file_fasync(int fd, struct file *filp, int on)
+{
+ return -EIO;
+}
+
+static int bad_file_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_sendfile(struct file *in_file, loff_t *ppos,
+ size_t count, read_actor_t actor, void *target)
+{
+ return -EIO;
+}
+
+static ssize_t bad_file_sendpage(struct file *file, struct page *page,
+
Re: [patch 00/21] 2.6.19-stable review
On Wed, Feb 21, 2007 at 05:39:01PM -0500, Chuck Ebbert wrote: > Andi Kleen wrote: > >>> What is the status of: > >>> > >>> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch > >>> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch > >> That's mainly an Andi decision. Let's cc him. > > > > I didn't think the problem was serious enough for a backport. Do we have > > user reports? > > Yes, lots: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225399 Ok for me then. -Andi - 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/21] 2.6.19-stable review
Chuck Ebbert <[EMAIL PROTECTED]> writes:
> We've tested it and found no problems so far. It's definitely
> better than what's there now. :)
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Would be good to have Eric also ack them as safe and obvious.
Andi Kleen <[EMAIL PROTECTED]> writes:
> I didn't think the problem was serious enough for a backport. Do we have
> user reports?
>
> It's certainly not trivial obvious patches.
>
> Eric, what is your opinion?
Bug reports:
I have seen a couple of user reports and heard about a few more. Given
that Chuck Ebbert appears to have tested them I'm guessing redhat has
seen a couple of reports as well. One of the issues is that in
some cases you can be susceptible and go for weeks without hitting
this, so the bug reports aren't likely to come back fast. So this is
a long term stability issue.
Even if we just put in my tiny fix that allows us to generally
survive this condition in stable, it prints a nasty warning message
so I expect people will want a more complete fix.
Vulnerability:
I believe it is possible to trigger this bug on any SMP machine.
Obviousness:
The first patch is obvious, but of course that isn't the interesting
bit.
The second patch is still fairly simple, and it appears to have
undergone testing from people besides myself.
So in the interest of a timely if not perfect fix I think it is a
good patch. In particular I do not see any area where it would makes
things worse.
Bugs:
There is one small issue that is probably worth fixing.
apic_in_service_vector only works correctly because we never have
more than one local apic irq in service at the same time, (we keep
irqs disabled during all of the interrupt routines). The appended
incremental patch addresses that.
Outstanding Issues:
The big outstanding issue I am currently working on is that in my
testing I have found evidence to suggest that ioapics do not strictly
follow the pci ordering rules, so exactly when the last interrupt
sent before we masked the interrupt at the interrupt controller will
arrive is in question. So to really be safe we cannot tear down the
data structures for handling the interrupt in the old location until
after we have seen the next interrupt showing up in the new location.
I don't know if it is possible to for the issue I have just described
to cause problems in practice. I intend to fix this for 2.6.21 if the
patch will be accepted. I have a patch that appears to work
that I am currently testing now.
I don't think my more complete fix will be as simple to backport
because it is a more intrusive patch.
Subject: [PATCH] x86_64 irq: Make apic_in_service_vector robust
Currently apic_in_service_vector because it scans isr in the wrong
direction only works reliably because we never enable interrupts
during an interrupt handler. I had the apic priorities backwards
in my head when I wrote it :(
It turns out that we have already saved off the vector we are servicing
in the irq regs so use that instead to make the code simpler and
more robust.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/io_apic.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index fc42340..b6f9896 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -1395,15 +1395,9 @@ static int ioapic_retrigger_irq(unsigned int irq)
static unsigned apic_in_service_vector(void)
{
- unsigned isr, vector;
+ unsigned vector;
/* Figure out which vector we are servicing */
- for (vector = FIRST_EXTERNAL_VECTOR; vector < FIRST_SYSTEM_VECTOR;
vector += 32) {
- isr = apic_read(APIC_ISR + ((vector/32) * 0x10));
- if (isr)
- break;
- }
- /* Find the low bits of the vector we are servicing */
- vector += __ffs(isr);
+ vector = ~get_irq_regs()->orig_rax;
return vector;
}
--
1.5.0.g53756
-
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/21] 2.6.19-stable review
Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.19.5 release.
>
> This will probably be the last release of the 2.6.19-stable series, so
> if there are patches that you feel should be applied to that tree,
> please let me know.
This is the rest of the NAPI fixes for 2.6.19-stable.
# HG changeset patch
# User Francois Romieu <[EMAIL PROTECTED]>
# Date 1167168251 18000
# Node ID 7c05514de8881339775cfd86e6357a82735c34f2
# Parent bf34fac7fcce4300f7199337160dab99deefc738
netpoll: drivers must not enable IRQ unconditionally in their NAPI handler
net/core/netpoll.c::netpoll_send_skb() calls the poll handler when
it is available. As netconsole can be used from almost any context,
IRQ must not be enabled blindly in the NAPI handler of a driver which
supports netpoll.
b57bd06655a028aba7b92e1c19c2093e7fcfb341 fixed the issue for the
8139too.c driver.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
committer: Jeff Garzik <[EMAIL PROTECTED]> 1167168251 -0500
--- a/drivers/net/8139cp.c Tue Dec 26 15:51:30 2006 -0500
+++ b/drivers/net/8139cp.c Tue Dec 26 16:24:11 2006 -0500
@@ -617,13 +617,15 @@ rx_next:
* this round of polling
*/
if (rx_work) {
+ unsigned long flags;
+
if (cpr16(IntrStatus) & cp_rx_intr_mask)
goto rx_status_loop;
- local_irq_disable();
+ local_irq_save(flags);
cpw16_f(IntrMask, cp_intr_mask);
__netif_rx_complete(dev);
- local_irq_enable();
+ local_irq_restore(flags);
return 0; /* done */
}
--- a/drivers/net/b44.c Tue Dec 26 15:51:30 2006 -0500
+++ b/drivers/net/b44.c Tue Dec 26 16:24:11 2006 -0500
@@ -879,12 +879,14 @@ static int b44_poll(struct net_device *n
}
if (bp->istat & ISTAT_ERRORS) {
- spin_lock_irq(>lock);
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
b44_halt(bp);
b44_init_rings(bp);
b44_init_hw(bp, 1);
netif_wake_queue(bp->dev);
- spin_unlock_irq(>lock);
+ spin_unlock_irqrestore(>lock, flags);
done = 1;
}
--- a/drivers/net/forcedeth.c Tue Dec 26 15:51:30 2006 -0500
+++ b/drivers/net/forcedeth.c Tue Dec 26 16:24:11 2006 -0500
@@ -2576,14 +2576,15 @@ static int nv_napi_poll(struct net_devic
int pkts, limit = min(*budget, dev->quota);
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
+ unsigned long flags;
pkts = nv_rx_process(dev, limit);
if (nv_alloc_rx(dev)) {
- spin_lock_irq(>lock);
+ spin_lock_irqsave(>lock, flags);
if (!np->in_shutdown)
mod_timer(>oom_kick, jiffies + OOM_REFILL);
- spin_unlock_irq(>lock);
+ spin_unlock_irqrestore(>lock, flags);
}
if (pkts < limit) {
@@ -2591,13 +2592,15 @@ static int nv_napi_poll(struct net_devic
netif_rx_complete(dev);
/* re-enable receive interrupts */
- spin_lock_irq(>lock);
+ spin_lock_irqsave(>lock, flags);
+
np->irqmask |= NVREG_IRQ_RX_ALL;
if (np->msi_flags & NV_MSI_X_ENABLED)
writel(NVREG_IRQ_RX_ALL, base + NvRegIrqMask);
else
writel(np->irqmask, base + NvRegIrqMask);
- spin_unlock_irq(>lock);
+
+ spin_unlock_irqrestore(>lock, flags);
return 0;
} else {
/* used up our quantum, so reschedule */
--- a/drivers/net/skge.cTue Dec 26 15:51:30 2006 -0500
+++ b/drivers/net/skge.cTue Dec 26 16:24:11 2006 -0500
@@ -2920,6 +2920,7 @@ static int skge_poll(struct net_device *
struct skge_hw *hw = skge->hw;
struct skge_ring *ring = >rx_ring;
struct skge_element *e;
+ unsigned long flags;
int to_do = min(dev->quota, *budget);
int work_done = 0;
@@ -2957,12 +2958,12 @@ static int skge_poll(struct net_device *
if (work_done >= to_do)
return 1; /* not done */
- spin_lock_irq(>hw_lock);
+ spin_lock_irqsave(>hw_lock, flags);
__netif_rx_complete(dev);
hw->intr_mask |= irqmask[skge->port];
skge_write32(hw, B0_IMSK, hw->intr_mask);
skge_read32(hw, B0_IMSK);
- spin_unlock_irq(>hw_lock);
+ spin_unlock_irqrestore(>hw_lock, flags);
return 0;
}
Re: [patch 00/21] 2.6.19-stable review
Andi Kleen wrote: >>> What is the status of: >>> >>> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch >>> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch >> That's mainly an Andi decision. Let's cc him. > > I didn't think the problem was serious enough for a backport. Do we have > user reports? Yes, lots: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225399 > It's certainly not trivial obvious patches. - 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/21] 2.6.19-stable review
Chuck Ebbert wrote: > Greg KH wrote: >> This is the start of the stable review cycle for the 2.6.19.5 release. >> >> This will probably be the last release of the 2.6.19-stable series, so >> if there are patches that you feel should be applied to that tree, >> please let me know. > > This patch should go in 2.6.19 and 2.6.20 -stable as well. > (It's in 2.6.21-rc.) > > > > > > From: Steve French <[EMAIL PROTECTED]> > Date: Mon, 22 Jan 2007 01:19:30 + (+) > Subject: [CIFS] Fix oops when Windows server sent bad domain name null > terminator > X-Git-Tag: v2.6.20^0~147^2 > X-Git-Url: > http://www2.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Fsfrench%2Fcifs-2.6.git;a=commitdiff_plain;h=8e6f195af0e1f226e9b2e0256af8df46adb9d595 > > [CIFS] Fix oops when Windows server sent bad domain name null terminator Oops, this is already in 2.6.20. - 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/21] 2.6.19-stable review
Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.19.5 release.
>
> This will probably be the last release of the 2.6.19-stable series, so
> if there are patches that you feel should be applied to that tree,
> please let me know.
This patch should go in 2.6.19 and 2.6.20 -stable as well.
(It's in 2.6.21-rc.)
From: Steve French <[EMAIL PROTECTED]>
Date: Mon, 22 Jan 2007 01:19:30 + (+)
Subject: [CIFS] Fix oops when Windows server sent bad domain name null
terminator
X-Git-Tag: v2.6.20^0~147^2
X-Git-Url:
http://www2.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Fsfrench%2Fcifs-2.6.git;a=commitdiff_plain;h=8e6f195af0e1f226e9b2e0256af8df46adb9d595
[CIFS] Fix oops when Windows server sent bad domain name null terminator
Fixes RedHat bug 211672
Windows sends one byte (instead of two) of null to terminate final Unicode
string (domain name) in session setup response in some cases - this caused
cifs to misalign some informational strings (making it hard to convert
from UCS16 to UTF8).
Thanks to Shaggy for his help and Akemi Yagi for debugging/testing
Signed-off-by: Shirish Pargaonkar <[EMAIL PROTECTED]>
Signed-off-by: Steve French <[EMAIL PROTECTED]>
---
diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index bbdda99..7584646 100644
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -182,11 +182,14 @@ static int decode_unicode_ssetup(char ** pbcc_area, int
bleft, struct cifsSesInf
cFYI(1,("bleft %d",bleft));
- /* word align, if bytes remaining is not even */
- if(bleft % 2) {
- bleft--;
- data++;
- }
+ /* SMB header is unaligned, so cifs servers word align start of
+ Unicode strings */
+ data++;
+ bleft--; /* Windows servers do not always double null terminate
+ their final Unicode string - in which case we
+ now will not attempt to decode the byte of junk
+ which follows it */
+
words_left = bleft / 2;
/* save off server operating system */
Re: [patch 00/21] 2.6.19-stable review
> commit 2fb12a9bca5ad9aa6dcd2c639b4a7656a8843ef8 > Author: Eric W. Biederman <[EMAIL PROTECTED]> > Date: Tue Feb 13 13:26:25 2007 +0100 > > [PATCH] x86-64: survive having no irq mapping for a vector Putting that patch into stable would be a good idea, agreed. -Andi - 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/21] 2.6.19-stable review
On Wed, Feb 21, 2007 at 11:47:37AM -0800, Andrew Morton wrote: > On Wed, 21 Feb 2007 14:31:41 -0500 > Chuck Ebbert <[EMAIL PROTECTED]> wrote: > > > Greg KH wrote: > > > This is the start of the stable review cycle for the 2.6.19.5 release. > > > > > > This will probably be the last release of the 2.6.19-stable series, so > > > if there are patches that you feel should be applied to that tree, > > > please let me know. > > > > > > There are 21 patches in this series, all will be posted as a response to > > > this one. If anyone has any issues with these being applied, please let > > > us know. If anyone is a maintainer of the proper subsystem, and wants > > > to add a Signed-off-by: line to the patch, please respond with it. > > > > > > > What is the status of: > > > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch > > That's mainly an Andi decision. Let's cc him. I didn't think the problem was serious enough for a backport. Do we have user reports? It's certainly not trivial obvious patches. Eric, what is your opinion? -Andi - 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/21] 2.6.19-stable review
Greg KH wrote: >> What is the status of: >> >> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch >> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch >> >> They fix a serious bug that causes machines to freeze up >> or just run very slowly. >> >> I'd like to see these in -stable if possible. > > -stable for 2.6.19 and/or .18? > The bug is new in .19 and is still in .20 and .21-rc. - 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/21] 2.6.19-stable review
On Wed, Feb 21, 2007 at 02:31:41PM -0500, Chuck Ebbert wrote: > Greg KH wrote: > > This is the start of the stable review cycle for the 2.6.19.5 release. > > > > This will probably be the last release of the 2.6.19-stable series, so > > if there are patches that you feel should be applied to that tree, > > please let me know. > > > > There are 21 patches in this series, all will be posted as a response to > > this one. If anyone has any issues with these being applied, please let > > us know. If anyone is a maintainer of the proper subsystem, and wants > > to add a Signed-off-by: line to the patch, please respond with it. > > > > What is the status of: > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch > > They fix a serious bug that causes machines to freeze up > or just run very slowly. > > I'd like to see these in -stable if possible. -stable for 2.6.19 and/or .18? I haven't pushed out the next round of patches for the 2.6.20-stable tree, I have a _lot_ of them there to catch up on still... thanks, greg k-h - 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/21] 2.6.19-stable review
Eric W. Biederman wrote: > Andrew Morton <[EMAIL PROTECTED]> writes: > >> On Wed, 21 Feb 2007 14:31:41 -0500 >> Chuck Ebbert <[EMAIL PROTECTED]> wrote: >>> What is the status of: >>> >>> >> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch >> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch >> >> That's mainly an Andi decision. Let's cc him. >> >>> They fix a serious bug that causes machines to freeze up >>> or just run very slowly. >>> >>> I'd like to see these in -stable if possible. >> They're not even in mainline yet. > > If you don't have it you at least want the patch below. It generally > makes the bug non-fatal. > > I'm still working my way through possible fixes... Although the > patch in question is close, and normally fixes it in my utmost > paranoia I can still find problems with it. We've tested it and found no problems so far. It's definitely better than what's there now. :) - 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/21] 2.6.19-stable review
Andrew Morton <[EMAIL PROTECTED]> writes: > On Wed, 21 Feb 2007 14:31:41 -0500 > Chuck Ebbert <[EMAIL PROTECTED]> wrote: >> What is the status of: >> >> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch >> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch > > That's mainly an Andi decision. Let's cc him. > >> They fix a serious bug that causes machines to freeze up >> or just run very slowly. >> >> I'd like to see these in -stable if possible. > > They're not even in mainline yet. If you don't have it you at least want the patch below. It generally makes the bug non-fatal. I'm still working my way through possible fixes... Although the patch in question is close, and normally fixes it in my utmost paranoia I can still find problems with it. Eric commit 2fb12a9bca5ad9aa6dcd2c639b4a7656a8843ef8 Author: Eric W. Biederman <[EMAIL PROTECTED]> Date: Tue Feb 13 13:26:25 2007 +0100 [PATCH] x86-64: survive having no irq mapping for a vector Occasionally the kernel has bugs that result in no irq being found for a given cpu vector. If we acknowledge the irq the system has a good chance of continuing even though we dropped an irq message. If we continue to simply print a message and not acknowledge the irq the system is likely to become non-responsive shortly there after. AK: Fixed compilation for UP kernels Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> Cc: "Luigi Genoni" <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> - 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/21] 2.6.19-stable review
On Wed, 21 Feb 2007, Andrew Morton wrote: > > > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch > > That's mainly an Andi decision. Let's cc him. Would be good to have Eric also ack them as safe and obvious. Btw, that latter one has corrupted sign-offs from Andi (it's in the middle of the text, very confusing). Linus - 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/21] 2.6.19-stable review
On Wed, 21 Feb 2007 14:31:41 -0500 Chuck Ebbert <[EMAIL PROTECTED]> wrote: > Greg KH wrote: > > This is the start of the stable review cycle for the 2.6.19.5 release. > > > > This will probably be the last release of the 2.6.19-stable series, so > > if there are patches that you feel should be applied to that tree, > > please let me know. > > > > There are 21 patches in this series, all will be posted as a response to > > this one. If anyone has any issues with these being applied, please let > > us know. If anyone is a maintainer of the proper subsystem, and wants > > to add a Signed-off-by: line to the patch, please respond with it. > > > > What is the status of: > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch That's mainly an Andi decision. Let's cc him. > They fix a serious bug that causes machines to freeze up > or just run very slowly. > > I'd like to see these in -stable if possible. They're not even in mainline yet. - 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/21] 2.6.19-stable review
Greg KH wrote: > This is the start of the stable review cycle for the 2.6.19.5 release. > > This will probably be the last release of the 2.6.19-stable series, so > if there are patches that you feel should be applied to that tree, > please let me know. > > There are 21 patches in this series, all will be posted as a response to > this one. If anyone has any issues with these being applied, please let > us know. If anyone is a maintainer of the proper subsystem, and wants > to add a Signed-off-by: line to the patch, please respond with it. > What is the status of: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch They fix a serious bug that causes machines to freeze up or just run very slowly. I'd like to see these in -stable if possible. - 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/21] 2.6.19-stable review
Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.19.5 release.
>
> This will probably be the last release of the 2.6.19-stable series, so
> if there are patches that you feel should be applied to that tree,
> please let me know.
>
The attached fixes an oops in the usbnet driver. The same patch is
in 2.6.21-rc1, but that one has many whitespace changes. This is much
smaller.
From: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: linux-2.6.20.noarch/drivers/usb/net/usbnet.c
===
--- linux-2.6.20.noarch.orig/drivers/usb/net/usbnet.c 2007-02-04
13:44:54.0 -0500
+++ linux-2.6.20.noarch/drivers/usb/net/usbnet.c2007-02-18
18:57:05.0 -0500
@@ -1182,6 +1182,9 @@
// NOTE net->name still not usable ...
if (info->bind) {
status = info->bind (dev, udev);
+ if (status < 0)
+ goto out1;
+
// heuristic: "usb%d" for links we know are two-host,
// else "eth%d" when there's reasonable doubt. userspace
// can rename the link if it knows better.
@@ -1208,12 +1211,12 @@
if (status == 0 && dev->status)
status = init_status (dev, udev);
if (status < 0)
- goto out1;
+ goto out3;
if (!dev->rx_urb_size)
dev->rx_urb_size = dev->hard_mtu;
dev->maxpacket = usb_maxpacket (dev->udev, dev->out, 1);
-
+
SET_NETDEV_DEV(net, >dev);
status = register_netdev (net);
if (status)
Re: [patch 00/21] 2.6.19-stable review
Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.19.5 release.
>
> This will probably be the last release of the 2.6.19-stable series, so
> if there are patches that you feel should be applied to that tree,
> please let me know.
The attached patch is in 2.6.20 and fixes problems with
no sound from certain Intel HDA adapters.
# HG changeset patch
# User Takashi Iwai <[EMAIL PROTECTED]>
# Date 1166601341 -3600
# Node ID d53318ba5eb26fbefb63d85c402cb368096436f3
# Parent e20d24388f86121d3ac6f58560e3b7acd686fd39
[ALSA] hda-codec - Don't return error at initialization of modem codec
Some modem codec seem to fail in the initialization, and this
stopped loading of the whole module although the audio is OK.
Since it's usually a non-fatal issue, the driver tries to proceed
to initialize now.
Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
Signed-off-by: Jaroslav Kysela <[EMAIL PROTECTED]>
committer: Jaroslav Kysela <[EMAIL PROTECTED]> 1166601341 +0100
--- a/sound/pci/hda/patch_si3054.c Wed Dec 20 08:55:39 2006 +0100
+++ b/sound/pci/hda/patch_si3054.c Wed Dec 20 08:55:41 2006 +0100
@@ -243,7 +243,8 @@ static int si3054_init(struct hda_codec
if((val_MEI_READY) != SI3054_MEI_READY) {
snd_printk(KERN_ERR "si3054: cannot initialize. EXT MID =
%04x\n", val);
- return -EACCES;
+ /* let's pray that this is no fatal error */
+ /* return -EACCES; */
}
SET_REG(codec, SI3054_GPIO_POLARITY, 0x);
Re: [patch 00/21] 2.6.19-stable review
I wrote: > I hope you can extract the patch from this MIME attachment. Probably not unless I attach it for real. -- Stefan Richter -=-=-=== --=- =-=-= http://arcgraph.de/sr/ Subject: [PATCH] Missing critical phys_to_virt in lib/swiotlb.c From: David Moore <[EMAIL PROTECTED]> Date: Sun, 04 Feb 2007 13:39:40 -0500 From: David Moore <[EMAIL PROTECTED]> Adds missing call to phys_to_virt() in the lib/swiotlb.c:swiotlb_sync_sg() function. Without this change, a kernel panic will always occur whenever a SWIOTLB bounce buffer from a scatter-gather list gets synced. Signed-off-by: David Moore <[EMAIL PROTECTED]> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- This is a fraction of patch "[IA64] swiotlb bug fixes" in 2.6.20-git#, commit cde14bbfb3aa79b479db35bd29e6c083513d8614. Unlike its heading suggests, it is also important for EM64T. Example crashes caused by swiotlb_sync_sg: http://lists.opensuse.org/opensuse-bugs/2006-12/msg02943.html http://qa.mandriva.com/show_bug.cgi?id=28224 http://www.pchdtv.com/forum/viewtopic.php?t=2063=a959a14a4c2db0eebaab7b0df56103ce --- linux-2.6.19.x86_64/lib/swiotlb.c.orig 2007-02-04 13:18:41.0 -0500 +++ linux-2.6.19.x86_64/lib/swiotlb.c 2007-02-04 13:19:43.0 -0500 @@ -750,7 +750,7 @@ swiotlb_sync_sg(struct device *hwdev, st for (i = 0; i < nelems; i++, sg++) if (sg->dma_address != SG_ENT_PHYS_ADDRESS(sg)) - sync_single(hwdev, (void *) sg->dma_address, + sync_single(hwdev, phys_to_virt(sg->dma_address), sg->dma_length, dir, target); }
Re: [patch 00/21] 2.6.19-stable review
Greg KH wrote: > This is the start of the stable review cycle for the 2.6.19.5 release. > > This will probably be the last release of the 2.6.19-stable series, so > if there are patches that you feel should be applied to that tree, > please let me know. There is one here: "Missing critical phys_to_virt in lib/swiotlb.c". http://lkml.org/lkml/2007/2/4/116 It fixes a DMA related bug which was seen with a variety of drivers especially on EM64T machines with more than 3GB RAM. I hope you can extract the patch from this MIME attachment. Adrian, AFAICS it applies as-is to 2.6.16.y too. I don't have a machine to test personally, but it is quite obvious. The mentioned bigger patch has been merged by Linus between 2.6.20 and 2.6.21-rc1. -- Stefan Richter -=-=-=== --=- =-=-= http://arcgraph.de/sr/ - 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/21] 2.6.19-stable review
Greg KH wrote: This is the start of the stable review cycle for the 2.6.19.5 release. This will probably be the last release of the 2.6.19-stable series, so if there are patches that you feel should be applied to that tree, please let me know. There is one here: Missing critical phys_to_virt in lib/swiotlb.c. http://lkml.org/lkml/2007/2/4/116 It fixes a DMA related bug which was seen with a variety of drivers especially on EM64T machines with more than 3GB RAM. I hope you can extract the patch from this MIME attachment. Adrian, AFAICS it applies as-is to 2.6.16.y too. I don't have a machine to test personally, but it is quite obvious. The mentioned bigger patch has been merged by Linus between 2.6.20 and 2.6.21-rc1. -- Stefan Richter -=-=-=== --=- =-=-= http://arcgraph.de/sr/ - 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/21] 2.6.19-stable review
I wrote: I hope you can extract the patch from this MIME attachment. Probably not unless I attach it for real. -- Stefan Richter -=-=-=== --=- =-=-= http://arcgraph.de/sr/ Subject: [PATCH] Missing critical phys_to_virt in lib/swiotlb.c From: David Moore [EMAIL PROTECTED] Date: Sun, 04 Feb 2007 13:39:40 -0500 From: David Moore [EMAIL PROTECTED] Adds missing call to phys_to_virt() in the lib/swiotlb.c:swiotlb_sync_sg() function. Without this change, a kernel panic will always occur whenever a SWIOTLB bounce buffer from a scatter-gather list gets synced. Signed-off-by: David Moore [EMAIL PROTECTED] Signed-off-by: Stefan Richter [EMAIL PROTECTED] --- This is a fraction of patch [IA64] swiotlb bug fixes in 2.6.20-git#, commit cde14bbfb3aa79b479db35bd29e6c083513d8614. Unlike its heading suggests, it is also important for EM64T. Example crashes caused by swiotlb_sync_sg: http://lists.opensuse.org/opensuse-bugs/2006-12/msg02943.html http://qa.mandriva.com/show_bug.cgi?id=28224 http://www.pchdtv.com/forum/viewtopic.php?t=2063sid=a959a14a4c2db0eebaab7b0df56103ce --- linux-2.6.19.x86_64/lib/swiotlb.c.orig 2007-02-04 13:18:41.0 -0500 +++ linux-2.6.19.x86_64/lib/swiotlb.c 2007-02-04 13:19:43.0 -0500 @@ -750,7 +750,7 @@ swiotlb_sync_sg(struct device *hwdev, st for (i = 0; i nelems; i++, sg++) if (sg-dma_address != SG_ENT_PHYS_ADDRESS(sg)) - sync_single(hwdev, (void *) sg-dma_address, + sync_single(hwdev, phys_to_virt(sg-dma_address), sg-dma_length, dir, target); }
Re: [patch 00/21] 2.6.19-stable review
Greg KH wrote:
This is the start of the stable review cycle for the 2.6.19.5 release.
This will probably be the last release of the 2.6.19-stable series, so
if there are patches that you feel should be applied to that tree,
please let me know.
The attached patch is in 2.6.20 and fixes problems with
no sound from certain Intel HDA adapters.
# HG changeset patch
# User Takashi Iwai [EMAIL PROTECTED]
# Date 1166601341 -3600
# Node ID d53318ba5eb26fbefb63d85c402cb368096436f3
# Parent e20d24388f86121d3ac6f58560e3b7acd686fd39
[ALSA] hda-codec - Don't return error at initialization of modem codec
Some modem codec seem to fail in the initialization, and this
stopped loading of the whole module although the audio is OK.
Since it's usually a non-fatal issue, the driver tries to proceed
to initialize now.
Signed-off-by: Takashi Iwai [EMAIL PROTECTED]
Signed-off-by: Jaroslav Kysela [EMAIL PROTECTED]
committer: Jaroslav Kysela [EMAIL PROTECTED] 1166601341 +0100
--- a/sound/pci/hda/patch_si3054.c Wed Dec 20 08:55:39 2006 +0100
+++ b/sound/pci/hda/patch_si3054.c Wed Dec 20 08:55:41 2006 +0100
@@ -243,7 +243,8 @@ static int si3054_init(struct hda_codec
if((valSI3054_MEI_READY) != SI3054_MEI_READY) {
snd_printk(KERN_ERR si3054: cannot initialize. EXT MID =
%04x\n, val);
- return -EACCES;
+ /* let's pray that this is no fatal error */
+ /* return -EACCES; */
}
SET_REG(codec, SI3054_GPIO_POLARITY, 0x);
Re: [patch 00/21] 2.6.19-stable review
Greg KH wrote:
This is the start of the stable review cycle for the 2.6.19.5 release.
This will probably be the last release of the 2.6.19-stable series, so
if there are patches that you feel should be applied to that tree,
please let me know.
The attached fixes an oops in the usbnet driver. The same patch is
in 2.6.21-rc1, but that one has many whitespace changes. This is much
smaller.
From: David Brownell [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
Index: linux-2.6.20.noarch/drivers/usb/net/usbnet.c
===
--- linux-2.6.20.noarch.orig/drivers/usb/net/usbnet.c 2007-02-04
13:44:54.0 -0500
+++ linux-2.6.20.noarch/drivers/usb/net/usbnet.c2007-02-18
18:57:05.0 -0500
@@ -1182,6 +1182,9 @@
// NOTE net-name still not usable ...
if (info-bind) {
status = info-bind (dev, udev);
+ if (status 0)
+ goto out1;
+
// heuristic: usb%d for links we know are two-host,
// else eth%d when there's reasonable doubt. userspace
// can rename the link if it knows better.
@@ -1208,12 +1211,12 @@
if (status == 0 dev-status)
status = init_status (dev, udev);
if (status 0)
- goto out1;
+ goto out3;
if (!dev-rx_urb_size)
dev-rx_urb_size = dev-hard_mtu;
dev-maxpacket = usb_maxpacket (dev-udev, dev-out, 1);
-
+
SET_NETDEV_DEV(net, udev-dev);
status = register_netdev (net);
if (status)
Re: [patch 00/21] 2.6.19-stable review
Greg KH wrote: This is the start of the stable review cycle for the 2.6.19.5 release. This will probably be the last release of the 2.6.19-stable series, so if there are patches that you feel should be applied to that tree, please let me know. There are 21 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. What is the status of: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch They fix a serious bug that causes machines to freeze up or just run very slowly. I'd like to see these in -stable if possible. - 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/21] 2.6.19-stable review
On Wed, 21 Feb 2007 14:31:41 -0500 Chuck Ebbert [EMAIL PROTECTED] wrote: Greg KH wrote: This is the start of the stable review cycle for the 2.6.19.5 release. This will probably be the last release of the 2.6.19-stable series, so if there are patches that you feel should be applied to that tree, please let me know. There are 21 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. What is the status of: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch That's mainly an Andi decision. Let's cc him. They fix a serious bug that causes machines to freeze up or just run very slowly. I'd like to see these in -stable if possible. They're not even in mainline yet. - 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/21] 2.6.19-stable review
On Wed, 21 Feb 2007, Andrew Morton wrote: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch That's mainly an Andi decision. Let's cc him. Would be good to have Eric also ack them as safe and obvious. Btw, that latter one has corrupted sign-offs from Andi (it's in the middle of the text, very confusing). Linus - 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/21] 2.6.19-stable review
Andrew Morton [EMAIL PROTECTED] writes: On Wed, 21 Feb 2007 14:31:41 -0500 Chuck Ebbert [EMAIL PROTECTED] wrote: What is the status of: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch That's mainly an Andi decision. Let's cc him. They fix a serious bug that causes machines to freeze up or just run very slowly. I'd like to see these in -stable if possible. They're not even in mainline yet. If you don't have it you at least want the patch below. It generally makes the bug non-fatal. I'm still working my way through possible fixes... Although the patch in question is close, and normally fixes it in my utmost paranoia I can still find problems with it. Eric commit 2fb12a9bca5ad9aa6dcd2c639b4a7656a8843ef8 Author: Eric W. Biederman [EMAIL PROTECTED] Date: Tue Feb 13 13:26:25 2007 +0100 [PATCH] x86-64: survive having no irq mapping for a vector Occasionally the kernel has bugs that result in no irq being found for a given cpu vector. If we acknowledge the irq the system has a good chance of continuing even though we dropped an irq message. If we continue to simply print a message and not acknowledge the irq the system is likely to become non-responsive shortly there after. AK: Fixed compilation for UP kernels Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] Signed-off-by: Andi Kleen [EMAIL PROTECTED] Cc: Luigi Genoni [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] - 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/21] 2.6.19-stable review
Eric W. Biederman wrote: Andrew Morton [EMAIL PROTECTED] writes: On Wed, 21 Feb 2007 14:31:41 -0500 Chuck Ebbert [EMAIL PROTECTED] wrote: What is the status of: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch That's mainly an Andi decision. Let's cc him. They fix a serious bug that causes machines to freeze up or just run very slowly. I'd like to see these in -stable if possible. They're not even in mainline yet. If you don't have it you at least want the patch below. It generally makes the bug non-fatal. I'm still working my way through possible fixes... Although the patch in question is close, and normally fixes it in my utmost paranoia I can still find problems with it. We've tested it and found no problems so far. It's definitely better than what's there now. :) - 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/21] 2.6.19-stable review
On Wed, Feb 21, 2007 at 02:31:41PM -0500, Chuck Ebbert wrote: Greg KH wrote: This is the start of the stable review cycle for the 2.6.19.5 release. This will probably be the last release of the 2.6.19-stable series, so if there are patches that you feel should be applied to that tree, please let me know. There are 21 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. What is the status of: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch They fix a serious bug that causes machines to freeze up or just run very slowly. I'd like to see these in -stable if possible. -stable for 2.6.19 and/or .18? I haven't pushed out the next round of patches for the 2.6.20-stable tree, I have a _lot_ of them there to catch up on still... thanks, greg k-h - 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/21] 2.6.19-stable review
Greg KH wrote: What is the status of: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch They fix a serious bug that causes machines to freeze up or just run very slowly. I'd like to see these in -stable if possible. -stable for 2.6.19 and/or .18? The bug is new in .19 and is still in .20 and .21-rc. - 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/21] 2.6.19-stable review
On Wed, Feb 21, 2007 at 11:47:37AM -0800, Andrew Morton wrote: On Wed, 21 Feb 2007 14:31:41 -0500 Chuck Ebbert [EMAIL PROTECTED] wrote: Greg KH wrote: This is the start of the stable review cycle for the 2.6.19.5 release. This will probably be the last release of the 2.6.19-stable series, so if there are patches that you feel should be applied to that tree, please let me know. There are 21 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. What is the status of: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch That's mainly an Andi decision. Let's cc him. I didn't think the problem was serious enough for a backport. Do we have user reports? It's certainly not trivial obvious patches. Eric, what is your opinion? -Andi - 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/21] 2.6.19-stable review
commit 2fb12a9bca5ad9aa6dcd2c639b4a7656a8843ef8 Author: Eric W. Biederman [EMAIL PROTECTED] Date: Tue Feb 13 13:26:25 2007 +0100 [PATCH] x86-64: survive having no irq mapping for a vector Putting that patch into stable would be a good idea, agreed. -Andi - 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/21] 2.6.19-stable review
Greg KH wrote:
This is the start of the stable review cycle for the 2.6.19.5 release.
This will probably be the last release of the 2.6.19-stable series, so
if there are patches that you feel should be applied to that tree,
please let me know.
This patch should go in 2.6.19 and 2.6.20 -stable as well.
(It's in 2.6.21-rc.)
From: Steve French [EMAIL PROTECTED]
Date: Mon, 22 Jan 2007 01:19:30 + (+)
Subject: [CIFS] Fix oops when Windows server sent bad domain name null
terminator
X-Git-Tag: v2.6.20^0~147^2
X-Git-Url:
http://www2.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Fsfrench%2Fcifs-2.6.git;a=commitdiff_plain;h=8e6f195af0e1f226e9b2e0256af8df46adb9d595
[CIFS] Fix oops when Windows server sent bad domain name null terminator
Fixes RedHat bug 211672
Windows sends one byte (instead of two) of null to terminate final Unicode
string (domain name) in session setup response in some cases - this caused
cifs to misalign some informational strings (making it hard to convert
from UCS16 to UTF8).
Thanks to Shaggy for his help and Akemi Yagi for debugging/testing
Signed-off-by: Shirish Pargaonkar [EMAIL PROTECTED]
Signed-off-by: Steve French [EMAIL PROTECTED]
---
diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index bbdda99..7584646 100644
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -182,11 +182,14 @@ static int decode_unicode_ssetup(char ** pbcc_area, int
bleft, struct cifsSesInf
cFYI(1,(bleft %d,bleft));
- /* word align, if bytes remaining is not even */
- if(bleft % 2) {
- bleft--;
- data++;
- }
+ /* SMB header is unaligned, so cifs servers word align start of
+ Unicode strings */
+ data++;
+ bleft--; /* Windows servers do not always double null terminate
+ their final Unicode string - in which case we
+ now will not attempt to decode the byte of junk
+ which follows it */
+
words_left = bleft / 2;
/* save off server operating system */
Re: [patch 00/21] 2.6.19-stable review
Chuck Ebbert wrote: Greg KH wrote: This is the start of the stable review cycle for the 2.6.19.5 release. This will probably be the last release of the 2.6.19-stable series, so if there are patches that you feel should be applied to that tree, please let me know. This patch should go in 2.6.19 and 2.6.20 -stable as well. (It's in 2.6.21-rc.) From: Steve French [EMAIL PROTECTED] Date: Mon, 22 Jan 2007 01:19:30 + (+) Subject: [CIFS] Fix oops when Windows server sent bad domain name null terminator X-Git-Tag: v2.6.20^0~147^2 X-Git-Url: http://www2.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Fsfrench%2Fcifs-2.6.git;a=commitdiff_plain;h=8e6f195af0e1f226e9b2e0256af8df46adb9d595 [CIFS] Fix oops when Windows server sent bad domain name null terminator Oops, this is already in 2.6.20. - 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/21] 2.6.19-stable review
Andi Kleen wrote: What is the status of: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch That's mainly an Andi decision. Let's cc him. I didn't think the problem was serious enough for a backport. Do we have user reports? Yes, lots: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225399 It's certainly not trivial obvious patches. - 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/21] 2.6.19-stable review
Greg KH wrote:
This is the start of the stable review cycle for the 2.6.19.5 release.
This will probably be the last release of the 2.6.19-stable series, so
if there are patches that you feel should be applied to that tree,
please let me know.
This is the rest of the NAPI fixes for 2.6.19-stable.
# HG changeset patch
# User Francois Romieu [EMAIL PROTECTED]
# Date 1167168251 18000
# Node ID 7c05514de8881339775cfd86e6357a82735c34f2
# Parent bf34fac7fcce4300f7199337160dab99deefc738
netpoll: drivers must not enable IRQ unconditionally in their NAPI handler
net/core/netpoll.c::netpoll_send_skb() calls the poll handler when
it is available. As netconsole can be used from almost any context,
IRQ must not be enabled blindly in the NAPI handler of a driver which
supports netpoll.
b57bd06655a028aba7b92e1c19c2093e7fcfb341 fixed the issue for the
8139too.c driver.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
committer: Jeff Garzik [EMAIL PROTECTED] 1167168251 -0500
--- a/drivers/net/8139cp.c Tue Dec 26 15:51:30 2006 -0500
+++ b/drivers/net/8139cp.c Tue Dec 26 16:24:11 2006 -0500
@@ -617,13 +617,15 @@ rx_next:
* this round of polling
*/
if (rx_work) {
+ unsigned long flags;
+
if (cpr16(IntrStatus) cp_rx_intr_mask)
goto rx_status_loop;
- local_irq_disable();
+ local_irq_save(flags);
cpw16_f(IntrMask, cp_intr_mask);
__netif_rx_complete(dev);
- local_irq_enable();
+ local_irq_restore(flags);
return 0; /* done */
}
--- a/drivers/net/b44.c Tue Dec 26 15:51:30 2006 -0500
+++ b/drivers/net/b44.c Tue Dec 26 16:24:11 2006 -0500
@@ -879,12 +879,14 @@ static int b44_poll(struct net_device *n
}
if (bp-istat ISTAT_ERRORS) {
- spin_lock_irq(bp-lock);
+ unsigned long flags;
+
+ spin_lock_irqsave(bp-lock, flags);
b44_halt(bp);
b44_init_rings(bp);
b44_init_hw(bp, 1);
netif_wake_queue(bp-dev);
- spin_unlock_irq(bp-lock);
+ spin_unlock_irqrestore(bp-lock, flags);
done = 1;
}
--- a/drivers/net/forcedeth.c Tue Dec 26 15:51:30 2006 -0500
+++ b/drivers/net/forcedeth.c Tue Dec 26 16:24:11 2006 -0500
@@ -2576,14 +2576,15 @@ static int nv_napi_poll(struct net_devic
int pkts, limit = min(*budget, dev-quota);
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
+ unsigned long flags;
pkts = nv_rx_process(dev, limit);
if (nv_alloc_rx(dev)) {
- spin_lock_irq(np-lock);
+ spin_lock_irqsave(np-lock, flags);
if (!np-in_shutdown)
mod_timer(np-oom_kick, jiffies + OOM_REFILL);
- spin_unlock_irq(np-lock);
+ spin_unlock_irqrestore(np-lock, flags);
}
if (pkts limit) {
@@ -2591,13 +2592,15 @@ static int nv_napi_poll(struct net_devic
netif_rx_complete(dev);
/* re-enable receive interrupts */
- spin_lock_irq(np-lock);
+ spin_lock_irqsave(np-lock, flags);
+
np-irqmask |= NVREG_IRQ_RX_ALL;
if (np-msi_flags NV_MSI_X_ENABLED)
writel(NVREG_IRQ_RX_ALL, base + NvRegIrqMask);
else
writel(np-irqmask, base + NvRegIrqMask);
- spin_unlock_irq(np-lock);
+
+ spin_unlock_irqrestore(np-lock, flags);
return 0;
} else {
/* used up our quantum, so reschedule */
--- a/drivers/net/skge.cTue Dec 26 15:51:30 2006 -0500
+++ b/drivers/net/skge.cTue Dec 26 16:24:11 2006 -0500
@@ -2920,6 +2920,7 @@ static int skge_poll(struct net_device *
struct skge_hw *hw = skge-hw;
struct skge_ring *ring = skge-rx_ring;
struct skge_element *e;
+ unsigned long flags;
int to_do = min(dev-quota, *budget);
int work_done = 0;
@@ -2957,12 +2958,12 @@ static int skge_poll(struct net_device *
if (work_done = to_do)
return 1; /* not done */
- spin_lock_irq(hw-hw_lock);
+ spin_lock_irqsave(hw-hw_lock, flags);
__netif_rx_complete(dev);
hw-intr_mask |= irqmask[skge-port];
skge_write32(hw, B0_IMSK, hw-intr_mask);
skge_read32(hw, B0_IMSK);
- spin_unlock_irq(hw-hw_lock);
+ spin_unlock_irqrestore(hw-hw_lock, flags);
return 0;
}
Re: [patch 00/21] 2.6.19-stable review
Chuck Ebbert [EMAIL PROTECTED] writes:
We've tested it and found no problems so far. It's definitely
better than what's there now. :)
Linus Torvalds [EMAIL PROTECTED] writes:
Would be good to have Eric also ack them as safe and obvious.
Andi Kleen [EMAIL PROTECTED] writes:
I didn't think the problem was serious enough for a backport. Do we have
user reports?
It's certainly not trivial obvious patches.
Eric, what is your opinion?
Bug reports:
I have seen a couple of user reports and heard about a few more. Given
that Chuck Ebbert appears to have tested them I'm guessing redhat has
seen a couple of reports as well. One of the issues is that in
some cases you can be susceptible and go for weeks without hitting
this, so the bug reports aren't likely to come back fast. So this is
a long term stability issue.
Even if we just put in my tiny fix that allows us to generally
survive this condition in stable, it prints a nasty warning message
so I expect people will want a more complete fix.
Vulnerability:
I believe it is possible to trigger this bug on any SMP machine.
Obviousness:
The first patch is obvious, but of course that isn't the interesting
bit.
The second patch is still fairly simple, and it appears to have
undergone testing from people besides myself.
So in the interest of a timely if not perfect fix I think it is a
good patch. In particular I do not see any area where it would makes
things worse.
Bugs:
There is one small issue that is probably worth fixing.
apic_in_service_vector only works correctly because we never have
more than one local apic irq in service at the same time, (we keep
irqs disabled during all of the interrupt routines). The appended
incremental patch addresses that.
Outstanding Issues:
The big outstanding issue I am currently working on is that in my
testing I have found evidence to suggest that ioapics do not strictly
follow the pci ordering rules, so exactly when the last interrupt
sent before we masked the interrupt at the interrupt controller will
arrive is in question. So to really be safe we cannot tear down the
data structures for handling the interrupt in the old location until
after we have seen the next interrupt showing up in the new location.
I don't know if it is possible to for the issue I have just described
to cause problems in practice. I intend to fix this for 2.6.21 if the
patch will be accepted. I have a patch that appears to work
that I am currently testing now.
I don't think my more complete fix will be as simple to backport
because it is a more intrusive patch.
Subject: [PATCH] x86_64 irq: Make apic_in_service_vector robust
Currently apic_in_service_vector because it scans isr in the wrong
direction only works reliably because we never enable interrupts
during an interrupt handler. I had the apic priorities backwards
in my head when I wrote it :(
It turns out that we have already saved off the vector we are servicing
in the irq regs so use that instead to make the code simpler and
more robust.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
arch/x86_64/kernel/io_apic.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index fc42340..b6f9896 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -1395,15 +1395,9 @@ static int ioapic_retrigger_irq(unsigned int irq)
static unsigned apic_in_service_vector(void)
{
- unsigned isr, vector;
+ unsigned vector;
/* Figure out which vector we are servicing */
- for (vector = FIRST_EXTERNAL_VECTOR; vector FIRST_SYSTEM_VECTOR;
vector += 32) {
- isr = apic_read(APIC_ISR + ((vector/32) * 0x10));
- if (isr)
- break;
- }
- /* Find the low bits of the vector we are servicing */
- vector += __ffs(isr);
+ vector = ~get_irq_regs()-orig_rax;
return vector;
}
--
1.5.0.g53756
-
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/21] 2.6.19-stable review
On Wed, Feb 21, 2007 at 05:39:01PM -0500, Chuck Ebbert wrote: Andi Kleen wrote: What is the status of: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch That's mainly an Andi decision. Let's cc him. I didn't think the problem was serious enough for a backport. Do we have user reports? Yes, lots: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225399 Ok for me then. -Andi - 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/
