On Fri, Apr 06, 2007 at 10:55:57AM +0200, Guillaume Thouvenin wrote:
> Cleanup unneeded macros used for register space address calculation.
> Now we are using the EBDA to find the space address.
>
> Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
Applied, thank you. I'll push it out with
Cleanup unneeded macros used for register space address calculation.
Now we are using the EBDA to find the space address.
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
pci-calgary.c |5 -
1 file changed, 5 deletions(-)
Index: linux-2.6.20.4/arch/x86_64/kernel/pci-calgary.c
Cleanup unneeded macros used for register space address calculation.
Now we are using the EBDA to find the space address.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
pci-calgary.c |5 -
1 file changed, 5 deletions(-)
Index: linux-2.6.20.4/arch/x86_64/kernel/pci-calgary.c
On Fri, Apr 06, 2007 at 10:55:57AM +0200, Guillaume Thouvenin wrote:
Cleanup unneeded macros used for register space address calculation.
Now we are using the EBDA to find the space address.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
Applied, thank you. I'll push it out with the
Yes, you are right.
I need more work on my trival patch.
On Thu, Apr 05, 2007 at 01:34:42PM +0600, Alexander E. Patrakov wrote:
> lepton wrote:
> >Hi,
> > When reading corrupted reiserfs directory data, d_reclen
> > could be a negative number, then memcpy will overflow
> > kernel stack. This
lepton wrote:
Hi,
When reading corrupted reiserfs directory data, d_reclen
could be a negative number, then memcpy will overflow
kernel stack. This can lead to kernel panic.
The following patch adds a sanity check. (against 2.6.20.4)
Is it possible to get a large positive number here
Hi,
When reading corrupted reiserfs directory data, d_reclen
could be a negative number, then memcpy will overflow
kernel stack. This can lead to kernel panic.
The following patch adds a sanity check. (against 2.6.20.4)
Signed-off-by: Lepton Wu <[EMAIL PROTECTED]>
diff -pru
Hi,
When reading corrupted reiserfs directory data, d_reclen
could be a negative number, then memcpy will overflow
kernel stack. This can lead to kernel panic.
The following patch adds a sanity check. (against 2.6.20.4)
Signed-off-by: Lepton Wu [EMAIL PROTECTED]
diff -pru
lepton wrote:
Hi,
When reading corrupted reiserfs directory data, d_reclen
could be a negative number, then memcpy will overflow
kernel stack. This can lead to kernel panic.
The following patch adds a sanity check. (against 2.6.20.4)
Is it possible to get a large positive number here
Yes, you are right.
I need more work on my trival patch.
On Thu, Apr 05, 2007 at 01:34:42PM +0600, Alexander E. Patrakov wrote:
lepton wrote:
Hi,
When reading corrupted reiserfs directory data, d_reclen
could be a negative number, then memcpy will overflow
kernel stack. This can lead
On Fri, Mar 30, 2007 at 01:33:45PM -0600, Eric W. Biederman wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> >
> > Sorry, but this isn't going to go into 2.6.20 any time soon as it
> > doesn't fit the rules for the -stable tree.
> >
> > But I'll take an updated version for my pci tree to go to Linus
Greg KH <[EMAIL PROTECTED]> writes:
>
> Sorry, but this isn't going to go into 2.6.20 any time soon as it
> doesn't fit the rules for the -stable tree.
>
> But I'll take an updated version for my pci tree to go to Linus after
> 2.6.21 is out.
Greg this does fix a bug that affects 2.6.21. We have
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks
On Fri, 2007-03-30 at 11:56 -0700, Mitch Williams wrote:
> This patch fixes a kernel bug which is triggered when using the
> irqbalance daemon with MSI-X hardware.
>
Grrr. Evolution cut-n-sometimes-paste feature bit me. Will resend with
a proper subject line.
-Mitch
-
To unsubscribe from this
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks
On Fri, 2007-03-30 at 11:56 -0700, Mitch Williams wrote:
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Grrr. Evolution cut-n-sometimes-paste feature bit me. Will resend with
a proper subject line.
-Mitch
-
To unsubscribe from this
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks
Greg KH [EMAIL PROTECTED] writes:
Sorry, but this isn't going to go into 2.6.20 any time soon as it
doesn't fit the rules for the -stable tree.
But I'll take an updated version for my pci tree to go to Linus after
2.6.21 is out.
Greg this does fix a bug that affects 2.6.21. We have
On Fri, Mar 30, 2007 at 01:33:45PM -0600, Eric W. Biederman wrote:
Greg KH [EMAIL PROTECTED] writes:
Sorry, but this isn't going to go into 2.6.20 any time soon as it
doesn't fit the rules for the -stable tree.
But I'll take an updated version for my pci tree to go to Linus after
Fix NULL pointer dereference on hot ejection of a FireWire card while
dv1394 was loaded. http://bugzilla.kernel.org/show_bug.cgi?id=7121
I did not test card ejection with open /dev/dv1394 files yet.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
Picked from 2.6.21-rc1.
Fix NULL pointer dereference on hot ejection of a FireWire card while
dv1394 was loaded. http://bugzilla.kernel.org/show_bug.cgi?id=7121
I did not test card ejection with open /dev/dv1394 files yet.
Signed-off-by: Stefan Richter [EMAIL PROTECTED]
---
Picked from 2.6.21-rc1.
22 matches
Mail list logo
