LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: 2.6.6-mm5
@ 2004-05-22 10:27 Oleg Nesterov
0 siblings, 0 replies; 32+ messages in thread
From: Oleg Nesterov @ 2004-05-22 10:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton
Hello.
Andrew Morton wrote:
>
> +ia32-fault-deadlock-fix.patch
>
> + if ((error_code & 4) == 0 && !check_exception(regs))
> + goto bad_area_nosemaphore;
I just can't understand, why check_exception() was introduced.
if ((error_code & 4) == 0 && !search_exception_tables(regs->eip))
has the same effect?
Oleg.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-26 12:59 ` 2.6.6-mm5 Anders Gustafsson
@ 2004-05-26 13:03 ` Jens Axboe
0 siblings, 0 replies; 32+ messages in thread
From: Jens Axboe @ 2004-05-26 13:03 UTC (permalink / raw)
To: Anders Gustafsson; +Cc: Andrew Morton, linux-kernel
On Wed, May 26 2004, Anders Gustafsson wrote:
> On Wed, May 26, 2004 at 02:49:44PM +0200, Jens Axboe wrote:
> > But they need to be bisabled, since -o barrier doesn't work on SCSI yet.
> > Only non-data tagged flushes are supported, those from
> > blkdev_issue_flush().
>
> :(
>
> Is the problem in the scsi drivers or at a higher level? Would really
> like to have them unbisabled, got a huge speed improvement in a
> logging-application with barriers when tested on IDE.
The error handling needs some work to safely enbable it on SCSI. Will
happen soonish. Additionally, low level drivers need to be updated. This
last step should not be too bad, though.
--
Jens Axboe
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-26 12:49 ` 2.6.6-mm5 Jens Axboe
@ 2004-05-26 12:59 ` Anders Gustafsson
2004-05-26 13:03 ` 2.6.6-mm5 Jens Axboe
0 siblings, 1 reply; 32+ messages in thread
From: Anders Gustafsson @ 2004-05-26 12:59 UTC (permalink / raw)
To: Jens Axboe; +Cc: Andrew Morton, linux-kernel
On Wed, May 26, 2004 at 02:49:44PM +0200, Jens Axboe wrote:
> But they need to be bisabled, since -o barrier doesn't work on SCSI yet.
> Only non-data tagged flushes are supported, those from
> blkdev_issue_flush().
:(
Is the problem in the scsi drivers or at a higher level? Would really
like to have them unbisabled, got a huge speed improvement in a
logging-application with barriers when tested on IDE.
anders
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-26 12:41 ` 2.6.6-mm5 Anders Gustafsson
@ 2004-05-26 12:49 ` Jens Axboe
2004-05-26 12:59 ` 2.6.6-mm5 Anders Gustafsson
0 siblings, 1 reply; 32+ messages in thread
From: Jens Axboe @ 2004-05-26 12:49 UTC (permalink / raw)
To: Anders Gustafsson; +Cc: Andrew Morton, linux-kernel
On Wed, May 26 2004, Anders Gustafsson wrote:
> On Sat, May 22, 2004 at 01:36:36AM -0700, Andrew Morton wrote:
> >
> > - Implementation of request barriers for IDE and SCSI. The idea here is
> > that a filesystem can tag an IO request as a barrier and the disk will not
> > reorder writes across the barrier. It provides additional integrity
> > guarantees for the journalling filesystems. The feature is enabled for
> > reiserfs and ext3.
>
> I get: this error message when using barriers on a scsi disk:
>
> lost page write due to I/O error on sdb1
> JBD: barrier-based sync failed on sdb1 - bisabling barriers
>
> and I don't want them barriers bisabled :)
>
> ext3 filesystem. reiser also disables barriers.
>
> I have a "Adaptec AIC-7902 U320 (rev 3)" SCSI controller and the disk is a
> SEAGATE ST373307LW.
But they need to be bisabled, since -o barrier doesn't work on SCSI yet.
Only non-data tagged flushes are supported, those from
blkdev_issue_flush().
--
Jens Axboe
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (6 preceding siblings ...)
2004-05-25 13:53 ` 2.6.6-mm5 Pavel Machek
@ 2004-05-26 12:41 ` Anders Gustafsson
2004-05-26 12:49 ` 2.6.6-mm5 Jens Axboe
7 siblings, 1 reply; 32+ messages in thread
From: Anders Gustafsson @ 2004-05-26 12:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Jens Axboe
On Sat, May 22, 2004 at 01:36:36AM -0700, Andrew Morton wrote:
>
> - Implementation of request barriers for IDE and SCSI. The idea here is
> that a filesystem can tag an IO request as a barrier and the disk will not
> reorder writes across the barrier. It provides additional integrity
> guarantees for the journalling filesystems. The feature is enabled for
> reiserfs and ext3.
I get: this error message when using barriers on a scsi disk:
lost page write due to I/O error on sdb1
JBD: barrier-based sync failed on sdb1 - bisabling barriers
and I don't want them barriers bisabled :)
ext3 filesystem. reiser also disables barriers.
I have a "Adaptec AIC-7902 U320 (rev 3)" SCSI controller and the disk is a
SEAGATE ST373307LW.
It works on ide.
--
Anders Gustafsson - andersg@0x63.nu - http://0x63.nu/
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (5 preceding siblings ...)
2004-05-23 1:01 ` 2.6.6-mm5 Eric W. Biederman
@ 2004-05-25 13:53 ` Pavel Machek
2004-05-26 12:41 ` 2.6.6-mm5 Anders Gustafsson
7 siblings, 0 replies; 32+ messages in thread
From: Pavel Machek @ 2004-05-25 13:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Hi!
> - Implementation of request barriers for IDE and SCSI. The idea here is
> that a filesystem can tag an IO request as a barrier and the disk will not
> reorder writes across the barrier. It provides additional integrity
> guarantees for the journalling filesystems. The feature is enabled for
> reiserfs and ext3.
*Additional* guarantees? Is there anything we can garant
without request barriers?
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-24 17:43 ` 2.6.6-mm5 Roland Dreier
@ 2004-05-25 7:25 ` Eric W. Biederman
0 siblings, 0 replies; 32+ messages in thread
From: Eric W. Biederman @ 2004-05-25 7:25 UTC (permalink / raw)
To: Roland Dreier; +Cc: Matt Mackall, Andrew Morton, linux-kernel
Roland Dreier <roland@topspin.com> writes:
> Eric> If no hardware actually cared or someone could show me that
> Eric> you can't generate a 64bit memory I/O cycle on the PCI bus
> Eric> that would be interesting. I have seen several drivers that
> Eric> care. Later today I intend to look at my pci docs and
> Eric> confirm that 64bit I/O cycles do exist on the bus, even in
> Eric> 32bit slots. PCI bus traffic is packet based so I would be
> Eric> strongly surprised if 64bit cycles did not exist.
>
> Hang on -- how could you generate a 64-bit cycle on a 32-bit PCI bus?
> By definition a 32-bit PCI bus can only transfer 32 bits per cycle.
>
> PCI Express traffic is packet based but parallel PCI definitely is not.
But parallel PCI is transaction based, which largely gives the same
effect as being packet based. And you can have man data cycles for
every address cycle. What I am not yet clear are the transaction splitting
rules. My outstanding questions that I really need to track down are:
- Must a 64bit memory write transaction have the same effect as 2
32bit write transactions?
- Must a 64bit read transaction have the same effect as 2 32bit
read transactions?
If true then it is impossible to implement the corresponding 64bit
atomic transaction on the PCI bus, and locks are required for
everyone's code.
The same questions can be asked of PCI-Express.
As soon as I managed to dig a copy of the protocol specifications
I will see if I can answer those questions.
Eric
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-24 17:03 ` 2.6.6-mm5 Eric W. Biederman
@ 2004-05-24 17:43 ` Roland Dreier
2004-05-25 7:25 ` 2.6.6-mm5 Eric W. Biederman
0 siblings, 1 reply; 32+ messages in thread
From: Roland Dreier @ 2004-05-24 17:43 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Matt Mackall, Andrew Morton, linux-kernel
Eric> If no hardware actually cared or someone could show me that
Eric> you can't generate a 64bit memory I/O cycle on the PCI bus
Eric> that would be interesting. I have seen several drivers that
Eric> care. Later today I intend to look at my pci docs and
Eric> confirm that 64bit I/O cycles do exist on the bus, even in
Eric> 32bit slots. PCI bus traffic is packet based so I would be
Eric> strongly surprised if 64bit cycles did not exist.
Hang on -- how could you generate a 64-bit cycle on a 32-bit PCI bus?
By definition a 32-bit PCI bus can only transfer 32 bits per cycle.
PCI Express traffic is packet based but parallel PCI definitely is not.
- Roland
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-24 16:17 ` 2.6.6-mm5 Matt Mackall
@ 2004-05-24 17:03 ` Eric W. Biederman
2004-05-24 17:43 ` 2.6.6-mm5 Roland Dreier
0 siblings, 1 reply; 32+ messages in thread
From: Eric W. Biederman @ 2004-05-24 17:03 UTC (permalink / raw)
To: Matt Mackall; +Cc: Roland Dreier, Andrew Morton, linux-kernel
Matt Mackall <mpm@selenic.com> writes:
> On Sat, May 22, 2004 at 06:15:51PM -0700, Roland Dreier wrote:
> > Andrew> I don't think we can expect all architectures to be able
> > Andrew> to implement atomic 64-bit IO's, can we?
> >
> > Andrew> ergo, drivers which want to use readq and writeq should
> > Andrew> provide the appropriate locking.
> >
> > Perhaps we should have ARCH_HAS_ATOMIC_WRITEQ or something so that
> > drivers don't add the overhead of locking on architectures where it's
> > not necessary?
>
> Or perhaps we just need a lockless __readq/__writeq for drivers that
> know better.
I can see implementing these emulations with a name of
readq_emulated/writeq_emulated, or readl2/writel2. For drivers that
can stand not generating a true 64bit bus I/O cycle to the device,
that sounds helpful.
However there are and will likely continue to be devices that need a
64bit I/O cycle on the bus. That is what writeq logically/obviously
does. Putting an emulation in place of the real thing is likely to
cause all sorts subtle of problems.
Having listened to this conversation for a while I strongly dislike
the atomic language because that sounds like generating the wrong bus
cycles are somehow OK, and doing what the function says it does is
somehow just an optimization.
If no hardware actually cared or someone could show me that you can't
generate a 64bit memory I/O cycle on the PCI bus that would be
interesting. I have seen several drivers that care. Later today
I intend to look at my pci docs and confirm that 64bit I/O cycles
do exist on the bus, even in 32bit slots. PCI bus traffic is packet
based so I would be strongly surprised if 64bit cycles did not
exist.
Eric
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-23 1:15 ` 2.6.6-mm5 Roland Dreier
@ 2004-05-24 16:17 ` Matt Mackall
2004-05-24 17:03 ` 2.6.6-mm5 Eric W. Biederman
0 siblings, 1 reply; 32+ messages in thread
From: Matt Mackall @ 2004-05-24 16:17 UTC (permalink / raw)
To: Roland Dreier; +Cc: Andrew Morton, Eric W. Biederman, linux-kernel
On Sat, May 22, 2004 at 06:15:51PM -0700, Roland Dreier wrote:
> Andrew> I don't think we can expect all architectures to be able
> Andrew> to implement atomic 64-bit IO's, can we?
>
> Andrew> ergo, drivers which want to use readq and writeq should
> Andrew> provide the appropriate locking.
>
> Perhaps we should have ARCH_HAS_ATOMIC_WRITEQ or something so that
> drivers don't add the overhead of locking on architectures where it's
> not necessary?
Or perhaps we just need a lockless __readq/__writeq for drivers that
know better.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-23 11:39 ` 2.6.6-mm5 Andi Kleen
2004-05-23 21:32 ` 2.6.6-mm5 Eric W. Biederman
@ 2004-05-24 0:02 ` Eric W. Biederman
1 sibling, 0 replies; 32+ messages in thread
From: Eric W. Biederman @ 2004-05-24 0:02 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
Andi Kleen <ak@muc.de> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
> > Currently I know of a safe version that will work on x86 on processors
> > with sse support. And I how to generate 64bit I/O cycles with using
> > mmx or x87 registers, but don't know if I can write code that touches
> > the FPU registers that is interrupt safe.
>
> As long as you save/restore cr0 and the FPU registers and do clts
> interrupts are not a problem. In fact interrupts are even easier that
> process context, where you need preempt_disable().
Thinking about this some more, I would need to transform every
preempt_disable() into a local_irq_disable() if I wanted to save
the FP registers to their home in struct task.
It looks to me like the only way to handle all of the x87 and mmx
subtleties is to call fsave which takes 108 bytes. That is a lot of
stack bytes to eat in irq context, and I suspect it is time consuming,
as well.
So I suspect it makes most sense just submit a patch for a sse version
of writeq on x86, and let the drivers that care use that. It does
mean that the drivers that care can't build for pre PentiumIII
hardware or must use a work around in generic kernels. So far the
cure for that looks much worse than the disease.
Eric
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-23 11:39 ` 2.6.6-mm5 Andi Kleen
@ 2004-05-23 21:32 ` Eric W. Biederman
2004-05-24 0:02 ` 2.6.6-mm5 Eric W. Biederman
1 sibling, 0 replies; 32+ messages in thread
From: Eric W. Biederman @ 2004-05-23 21:32 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
Andi Kleen <ak@muc.de> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
> > Currently I know of a safe version that will work on x86 on processors
> > with sse support. And I how to generate 64bit I/O cycles with using
> > mmx or x87 registers, but don't know if I can write code that touches
> > the FPU registers that is interrupt safe.
>
> As long as you save/restore cr0 and the FPU registers and do clts
> interrupts are not a problem. In fact interrupts are even easier that
> process context, where you need preempt_disable().
The saving and restoring is where things are looking icky.
It does not look like that kernel_fpu_begin() will work safely in
an interrupt context.
The generic x86 variant is to do:
fild
fistp
Which works for 64bit values because the floating point registers
have a 64bit mantissa.
I suppose I could unconditionally save the x87 floating point registers
to a local variable, but that sounds like a terribly expensive operation.
At least with kernel_fpu_begin() the floating point save only
needs to happen once, per context switch.
With SSE it is easy to save just a single register. For the x87 I don't
see how to do that. Beyond the stack based nature of the x87 there is
the question if the registers are in mmx mode or not.
I guess a conservative always correct version would be a place to start.
Eric
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:46 ` 2.6.6-mm5 Felipe Alfaro Solana
@ 2004-05-23 15:51 ` James Morris
0 siblings, 0 replies; 32+ messages in thread
From: James Morris @ 2004-05-23 15:51 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: Andrew Morton, Kernel Mailinglist, David S. Miller
On Sat, 22 May 2004, Felipe Alfaro Solana wrote:
> On Sat, 2004-05-22 at 10:36, Andrew Morton wrote:
> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> >
>
> Will you included the i586-optimized AES patch from Fruhwirth Clemens to
> the -mm tree? I find this patch really interesting, as it boost IPSec
> ESP AES considerably.
The problem is that we still need some kind of algorithm selection
mechanism (config time, preferrably), so that the right boxes get the asm
version loaded.
- James
--
James Morris
<jmorris@redhat.com>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
[not found] ` <1YRdQ-3pu-5@gated-at.bofh.it>
@ 2004-05-23 11:39 ` Andi Kleen
2004-05-23 21:32 ` 2.6.6-mm5 Eric W. Biederman
2004-05-24 0:02 ` 2.6.6-mm5 Eric W. Biederman
0 siblings, 2 replies; 32+ messages in thread
From: Andi Kleen @ 2004-05-23 11:39 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-kernel
ebiederm@xmission.com (Eric W. Biederman) writes:
> Currently I know of a safe version that will work on x86 on processors
> with sse support. And I how to generate 64bit I/O cycles with using
> mmx or x87 registers, but don't know if I can write code that touches
> the FPU registers that is interrupt safe.
As long as you save/restore cr0 and the FPU registers and do clts
interrupts are not a problem. In fact interrupts are even easier that
process context, where you need preempt_disable().
-Andi
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-23 1:08 ` 2.6.6-mm5 Andrew Morton
2004-05-23 1:15 ` 2.6.6-mm5 Roland Dreier
@ 2004-05-23 2:45 ` Eric W. Biederman
1 sibling, 0 replies; 32+ messages in thread
From: Eric W. Biederman @ 2004-05-23 2:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton <akpm@osdl.org> writes:
> ebiederm@xmission.com (Eric W. Biederman) wrote:
> >
> > Andrew Morton <akpm@osdl.org> writes:
> >
> > >
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
>
> > >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
>
> > >
> > >
> > > add-i386-readq.patch
> > > add i386 readq()/writeq()
> >
> > > static inline u64 readq(void *addr)
> > > {
> > > return readl(addr) | (((u64)readl(addr + 4)) << 32);
> > > }
> > >
> > > static inline void writeq(u64 v, void *addr)
> > > {
> > > u32 v32;
> > >
> > > v32 = v;
> > > writel(v32, addr);
> > > v32 = v >> 32;
> > > writel(v32, addr + 4);
> > > }
> > >
> > > #endif
> >
> > The implementation is broken and it will break drivers that actually
> > expect writeq and readq to be 64bit reads and writes.
>
> I don't think we can expect all architectures to be able to implement
> atomic 64-bit IO's, can we?
No I don't think we can expect all architectures to be able to
generate 64-bit bus cycles. Although I think we can expect a majority
of them to, and I believe that majority encompasses all the platforms
we want to run drivers that require readq and writeq.
There are some drivers that cannot be implemented on architectures
without 64bit transactions on the I/O bus. This is not always a race
issue that can be fixed with locking. I know of at least mtd map
driver where if you don't feed the device 64bit writes you will store
corrupt data.
If we want to use the above quoted functions we need to call them
readq_emulated and writeq_emulated. Because they are not the real
mccoy. Likely only readq_emulated and writeq_emulated can be
implemented on all architectures.
As I understand the current situation every architecture that
implements readq/writeq generates true 64bit bus cycles. A driver can
test if it the support exists at compile time with a simple #ifdef to
see if the function is present. If the function is not supported at
compile time the driver can implement a work around (like
readq_emulated) or it can fail to compile.
> ergo, drivers which want to use readq and writeq should provide the
> appropriate locking.
Hmm. I thought the logic:
I am going to introduce a broken implementation of a generic
function and this will reduce the maintainability of your driver in
subtle incomprehensible ways by not doing what is advertised. In
addition I will not even attempt to fix all of the drivers in the
tree when I generate the patch.
did not fly in linux.
I am worried about the general and subtle breakage that may occur
from a driver that works when real 64bit read/writes are generated
on the bus, and fails when we emulate them.
Knowing of two drivers off the top of my head that will break
with this patch, I am opposed to it on general grounds. The
infiniband driver is not in the tree and it can have locking
added to correct the additional race. The 64bit mtd map drivers
I have seen for some ppc platrrom will break as soon as they stop
rolling readq/writeq by hand, and no amount of locking will help
there. I don't know what else in the tree will break.
> > I attempted to suggest some alternative implementations earlier
> > in the original thread that brought this up but it looks like
> > you missed that.
>
> I saw some stuff float past, but I don't recall seeing anything which would
> work on all architectures?
I am not yet convinced you can write code that will work on all
architectures. I have yet to see generic code that with all
existing drivers.
I was attempting to start the conversation, because I don't know all
of the answers, I can just detect failures. In general on a 32bit
arch you need to use the FPU to implement a 64bit read or write. This
is not something you can code casually in the kernel or that you can
write generically. Although the basic idiom will likely be the same
for different architectures.
Currently I know of a safe version that will work on x86 on processors
with sse support. And I how to generate 64bit I/O cycles with using
mmx or x87 registers, but don't know if I can write code that touches
the FPU registers that is interrupt safe.
Eric
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-23 1:08 ` 2.6.6-mm5 Andrew Morton
@ 2004-05-23 1:15 ` Roland Dreier
2004-05-24 16:17 ` 2.6.6-mm5 Matt Mackall
2004-05-23 2:45 ` 2.6.6-mm5 Eric W. Biederman
1 sibling, 1 reply; 32+ messages in thread
From: Roland Dreier @ 2004-05-23 1:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Eric W. Biederman, linux-kernel
Andrew> I don't think we can expect all architectures to be able
Andrew> to implement atomic 64-bit IO's, can we?
Andrew> ergo, drivers which want to use readq and writeq should
Andrew> provide the appropriate locking.
Perhaps we should have ARCH_HAS_ATOMIC_WRITEQ or something so that
drivers don't add the overhead of locking on architectures where it's
not necessary?
(I happen to be working on a driver that needs atomic 64-bit writes,
and where those writes happen to be in the fast path)
Thanks,
Roland
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-23 1:01 ` 2.6.6-mm5 Eric W. Biederman
@ 2004-05-23 1:08 ` Andrew Morton
2004-05-23 1:15 ` 2.6.6-mm5 Roland Dreier
2004-05-23 2:45 ` 2.6.6-mm5 Eric W. Biederman
0 siblings, 2 replies; 32+ messages in thread
From: Andrew Morton @ 2004-05-23 1:08 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-kernel
ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
>
> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> >
> >
> > add-i386-readq.patch
> > add i386 readq()/writeq()
>
> > static inline u64 readq(void *addr)
> > {
> > return readl(addr) | (((u64)readl(addr + 4)) << 32);
> > }
> >
> > static inline void writeq(u64 v, void *addr)
> > {
> > u32 v32;
> >
> > v32 = v;
> > writel(v32, addr);
> > v32 = v >> 32;
> > writel(v32, addr + 4);
> > }
> >
> > #endif
>
> The implementation is broken and it will break drivers that actually
> expect writeq and readq to be 64bit reads and writes.
I don't think we can expect all architectures to be able to implement
atomic 64-bit IO's, can we?
ergo, drivers which want to use readq and writeq should provide the
appropriate locking.
> I attempted to suggest some alternative implementations earlier
> in the original thread that brought this up but it looks like
> you missed that.
I saw some stuff float past, but I don't recall seeing anything which would
work on all architectures?
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (4 preceding siblings ...)
2004-05-22 11:59 ` 2.6.6-mm5 Matthias Andree
@ 2004-05-23 1:01 ` Eric W. Biederman
2004-05-23 1:08 ` 2.6.6-mm5 Andrew Morton
2004-05-25 13:53 ` 2.6.6-mm5 Pavel Machek
2004-05-26 12:41 ` 2.6.6-mm5 Anders Gustafsson
7 siblings, 1 reply; 32+ messages in thread
From: Eric W. Biederman @ 2004-05-23 1:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton <akpm@osdl.org> writes:
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
>
>
> add-i386-readq.patch
> add i386 readq()/writeq()
> static inline u64 readq(void *addr)
> {
> return readl(addr) | (((u64)readl(addr + 4)) << 32);
> }
>
> static inline void writeq(u64 v, void *addr)
> {
> u32 v32;
>
> v32 = v;
> writel(v32, addr);
> v32 = v >> 32;
> writel(v32, addr + 4);
> }
>
> #endif
The implementation is broken and it will break drivers that actually
expect writeq and readq to be 64bit reads and writes.
In particular an interrupt can come in during the middle of a read
or a write and widely separate the two different halves.
Unless the driver has a lock protecting access to the card already
this race could be nasty and quite difficult to debug. And I have
looked and we do have some cases in the kernel that do not have
a lock protecting them.
I attempted to suggest some alternative implementations earlier
in the original thread that brought this up but it looks like
you missed that.
Eric
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:41 ` 2.6.6-mm5 hch
@ 2004-05-22 19:03 ` Brian King
0 siblings, 0 replies; 32+ messages in thread
From: Brian King @ 2004-05-22 19:03 UTC (permalink / raw)
To: hch; +Cc: Andrew Morton, linux-kernel
hch@infradead.org wrote:
> On Sat, May 22, 2004 at 02:32:18AM -0700, Andrew Morton wrote:
>
>>>code more readable sometimes) or stick a
>>
>>It uses a *ton* of anonymous unions.
>>
>>
>>>#if (__GNUC__ < 3)
>>># error "This driver requires GCC 3.x"
>>>#endif
>>
>>That breaks allfooconfig.
>
>
> Well, the patch currently in -mm also breaks allmodconfig. Just not on
> your arch or with a recent enough compiler, while with this it'll break
> an all arches unless you have a recent enough compiler. And give the
> driver isn't actually ppc specific that sounds like a really bad tradeoff.
I'll pull out the anonymous unions and submit to linux-scsi.
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 32+ messages in thread
* RE: 2.6.6-mm5
@ 2004-05-22 18:02 Adam Radford
0 siblings, 0 replies; 32+ messages in thread
From: Adam Radford @ 2004-05-22 18:02 UTC (permalink / raw)
To: hch, Jeff Garzik; +Cc: Andrew Morton, linux-kernel, SCSI Mailing List
Hch,
I did try to CC linux-scsi in the original email for the 3ware driver submission/review,
and 2 emails since then. None of them went through (no bounce message either).
Does anybody know what the max email size is? Is it < 145k?
--
Adam Radford
Staff Software Engineer
AMCC
-----Original Message-----
From: linux-scsi-owner@vger.kernel.org
[mailto:linux-scsi-owner@vger.kernel.org]On Behalf Of hch@infradead.org
Sent: Saturday, May 22, 2004 2:23 AM
To: Jeff Garzik
Cc: Andrew Morton; linux-kernel@vger.kernel.org; SCSI Mailing List
Subject: Re: 2.6.6-mm5
On Sat, May 22, 2004 at 05:09:59AM -0400, Jeff Garzik wrote:
> Andrew Morton wrote:
> >- Added a new SATA RAID driver from 3ware. From a quick peek it seem to
> > need a little work yet.
>
>
> It's not too bad... but it looks more like a 2.2 driver forward ported
> to 2.4, than a 2.6.x driver. Needs some luvin' from the 2.6 scsi api crew.
>
> Overall, it appears to be a message-based firmware engine like
> drivers/block/carmel.c, that hides the SATA details in the firmware.
In addition driver submission should always go through linux-scsi. Please
tell them to submit it to linux-scsi so we can have a public review process
there.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (3 preceding siblings ...)
2004-05-22 9:46 ` 2.6.6-mm5 Felipe Alfaro Solana
@ 2004-05-22 11:59 ` Matthias Andree
2004-05-23 1:01 ` 2.6.6-mm5 Eric W. Biederman
` (2 subsequent siblings)
7 siblings, 0 replies; 32+ messages in thread
From: Matthias Andree @ 2004-05-22 11:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sat, 22 May 2004, Andrew Morton wrote:
> - Implementation of request barriers for IDE and SCSI. The idea here is
> that a filesystem can tag an IO request as a barrier and the disk will not
> reorder writes across the barrier. It provides additional integrity
> guarantees for the journalling filesystems. The feature is enabled for
> reiserfs and ext3.
>
> On reiserfs do `mount /dev/hda /wherever -o barrier=flush' or
> `barrier=none'.
>
> On ext3 do `mount ... -o barrier=1' or `barrier=0'.
>
> ext3 also supports `mount -o remount,barrier=N'. I didn't check whether
> reiserfs supports switching at remount time and nobody tells me these
> things.
Ah, progress!
What SCSI low level drivers will translate barriers to tags?
Of particular personal egoistic interest for me are, in decreasing order
of importance: sym53c8xx_2 megaraid aic7xxx tmscsim
How will the system handle the Queue Algorithm Modifier? Appearently,
allowing command reordering is a matter of the device, not of the
individual partitions, so the barrier stuff is a property that would
belong into the block driver rather than into partition handling. Upon
mounting, the file system would have to query if the underlying block
device requires write barriers or will execute commands in order
(control mode page, queue algorithm modifier). If I need to operate the
target with "restricted reordering" algorithm for any other partition
that is mounted without barriers or with a barriers-unaware file system,
we won't gain much by all this barrier stuff for the target mustn't
reorder operations anyways.
The potential benefits of Queue Algorithm Modifier "Unrestricted
Reordering allowed" however requires that all file systems inform the
target about their write ordering requirements. IMHO, the barrier
"switch" does not belong into the file systems -- I don't see OTOH how
using these on a device that performs writes in order will matter, so
using these always will probably not harm (it's still useful for testing
probably).
--
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:09 ` 2.6.6-mm5 Jeff Garzik
2004-05-22 9:22 ` 2.6.6-mm5 hch
@ 2004-05-22 11:51 ` R. J. Wysocki
1 sibling, 0 replies; 32+ messages in thread
From: R. J. Wysocki @ 2004-05-22 11:51 UTC (permalink / raw)
To: Jeff Garzik, Andrew Morton; +Cc: linux-kernel, SCSI Mailing List
On Saturday 22 of May 2004 11:09, Jeff Garzik wrote:
> Andrew Morton wrote:
> > - Added a new SATA RAID driver from 3ware. From a quick peek it seem to
> > need a little work yet.
>
> It's not too bad... but it looks more like a 2.2 driver forward ported
> to 2.4, than a 2.6.x driver. Needs some luvin' from the 2.6 scsi api crew.
>
> Overall, it appears to be a message-based firmware engine like
> drivers/block/carmel.c, that hides the SATA details in the firmware.
BTW, which 3ware driver would you suggest to use with the 2.6.x now? I'm
going to install such a controller in my box ...
RJW
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
` (2 preceding siblings ...)
2004-05-22 9:38 ` 2.6.6-mm5 hch
@ 2004-05-22 9:46 ` Felipe Alfaro Solana
2004-05-23 15:51 ` 2.6.6-mm5 James Morris
2004-05-22 11:59 ` 2.6.6-mm5 Matthias Andree
` (3 subsequent siblings)
7 siblings, 1 reply; 32+ messages in thread
From: Felipe Alfaro Solana @ 2004-05-22 9:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: Kernel Mailinglist
On Sat, 2004-05-22 at 10:36, Andrew Morton wrote:
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
>
Will you included the i586-optimized AES patch from Fruhwirth Clemens to
the -mm tree? I find this patch really interesting, as it boost IPSec
ESP AES considerably.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:38 ` 2.6.6-mm5 hch
@ 2004-05-22 9:44 ` Jens Axboe
0 siblings, 0 replies; 32+ messages in thread
From: Jens Axboe @ 2004-05-22 9:44 UTC (permalink / raw)
To: hch, Andrew Morton, linux-kernel
On Sat, May 22 2004, hch@infradead.org wrote:
> > +disk-barrier-core.patch
> > +disk-barrier-core-tweaks.patch
> > +disk-barrier-ide.patch
> > +disk-barrier-ide-symbol-expoprt.patch
> > +disk-barrier-ide-warning-fix.patch
> > +disk-barrier-scsi.patch
> >
> > Support for IDE and SCSI barriers
> >
> > +disk-barrier-dm.patch
> > +disk-barrier-md.patch
> >
> > Via device mapper and raid as well.
>
> Some comments on the API and the SCSI part:
>
> - issue_flush_fn prototype choice is bad, the request_queue_t argument
> wile always be disk->queue so it's not needed and only causes
> confusion.
Agree, it's mutated into place which is probably the reason for the
dupe.
> - issue_flush sounds a little strange to me, what about cache_flush
> or sync_cache instead?
Fine with me, I'm notoriously bad at naming.
> - scsi_drive.issue_flush should take a scsi_device * as first parameter,
> not struct device * - makes life for bother caller and callee easier.
> - should probably add a small helper to get the scsi_driver from the
> gendisk instead of duplicating the code, ala:
>
> static inline struct scsi_driver *scsi_disk_driver(struct gendisk *disk)
> {
> return *(struct scsi_driver **) disk->private_data;
> }
Fine too.
> - the WCE check should move into sd_sync_cache
Ditto
> - NULL scsi_disk can't happen for sd_issue_flush, no need to check,
> and thus the disctinction of sd_issue_flush vs sd_sync_cache can
> go and sd_shutdown can simply call the cache flush method.
Neat, thanks.
Thanks for the review Christoph!
--
Jens Axboe
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:32 ` 2.6.6-mm5 Andrew Morton
@ 2004-05-22 9:41 ` hch
2004-05-22 19:03 ` 2.6.6-mm5 Brian King
0 siblings, 1 reply; 32+ messages in thread
From: hch @ 2004-05-22 9:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: brking, linux-kernel
On Sat, May 22, 2004 at 02:32:18AM -0700, Andrew Morton wrote:
> > code more readable sometimes) or stick a
>
> It uses a *ton* of anonymous unions.
>
> > #if (__GNUC__ < 3)
> > # error "This driver requires GCC 3.x"
> > #endif
>
> That breaks allfooconfig.
Well, the patch currently in -mm also breaks allmodconfig. Just not on
your arch or with a recent enough compiler, while with this it'll break
an all arches unless you have a recent enough compiler. And give the
driver isn't actually ppc specific that sounds like a really bad tradeoff.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
2004-05-22 9:09 ` 2.6.6-mm5 Jeff Garzik
2004-05-22 9:26 ` 2.6.6-mm5 hch
@ 2004-05-22 9:38 ` hch
2004-05-22 9:44 ` 2.6.6-mm5 Jens Axboe
2004-05-22 9:46 ` 2.6.6-mm5 Felipe Alfaro Solana
` (4 subsequent siblings)
7 siblings, 1 reply; 32+ messages in thread
From: hch @ 2004-05-22 9:38 UTC (permalink / raw)
To: Andrew Morton, axboe; +Cc: linux-kernel
> +disk-barrier-core.patch
> +disk-barrier-core-tweaks.patch
> +disk-barrier-ide.patch
> +disk-barrier-ide-symbol-expoprt.patch
> +disk-barrier-ide-warning-fix.patch
> +disk-barrier-scsi.patch
>
> Support for IDE and SCSI barriers
>
> +disk-barrier-dm.patch
> +disk-barrier-md.patch
>
> Via device mapper and raid as well.
Some comments on the API and the SCSI part:
- issue_flush_fn prototype choice is bad, the request_queue_t argument
wile always be disk->queue so it's not needed and only causes
confusion.
- issue_flush sounds a little strange to me, what about cache_flush
or sync_cache instead?
- scsi_drive.issue_flush should take a scsi_device * as first parameter,
not struct device * - makes life for bother caller and callee easier.
- should probably add a small helper to get the scsi_driver from the
gendisk instead of duplicating the code, ala:
static inline struct scsi_driver *scsi_disk_driver(struct gendisk *disk)
{
return *(struct scsi_driver **) disk->private_data;
}
- the WCE check should move into sd_sync_cache
- NULL scsi_disk can't happen for sd_issue_flush, no need to check,
and thus the disctinction of sd_issue_flush vs sd_sync_cache can
go and sd_shutdown can simply call the cache flush method.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:26 ` 2.6.6-mm5 hch
@ 2004-05-22 9:32 ` Andrew Morton
2004-05-22 9:41 ` 2.6.6-mm5 hch
0 siblings, 1 reply; 32+ messages in thread
From: Andrew Morton @ 2004-05-22 9:32 UTC (permalink / raw)
To: hch; +Cc: brking, linux-kernel
hch@infradead.org wrote:
>
> > +ipr-ppc64-depends.patch
> >
> > Make ipr.c depend on PPC
>
> >> Makes ipr depend on CONFIG_PPC since this driver is unique to PPC hardware.
> >>
> >> (It actually builds OK on x86, but it heavily uses anonymous unions, which
> >> breaks on gcc-2.95)
>
> I use gcc-2.95 happily on ppc. Better thing is to either fix it up not to
> use anonymous unions (which is a pitty because that feature helps making
> code more readable sometimes) or stick a
It uses a *ton* of anonymous unions.
> #if (__GNUC__ < 3)
> # error "This driver requires GCC 3.x"
> #endif
That breaks allfooconfig.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:22 ` 2.6.6-mm5 hch
@ 2004-05-22 9:26 ` Andrew Morton
0 siblings, 0 replies; 32+ messages in thread
From: Andrew Morton @ 2004-05-22 9:26 UTC (permalink / raw)
To: hch; +Cc: jgarzik, linux-kernel, linux-scsi
hch@infradead.org wrote:
>
> On Sat, May 22, 2004 at 05:09:59AM -0400, Jeff Garzik wrote:
> > Andrew Morton wrote:
> > >- Added a new SATA RAID driver from 3ware. From a quick peek it seem to
> > > need a little work yet.
> >
> >
> > It's not too bad... but it looks more like a 2.2 driver forward ported
> > to 2.4, than a 2.6.x driver. Needs some luvin' from the 2.6 scsi api crew.
> >
> > Overall, it appears to be a message-based firmware engine like
> > drivers/block/carmel.c, that hides the SATA details in the firmware.
>
> In addition driver submission should always go through linux-scsi. Please
> tell them to submit it to linux-scsi so we can have a public review process
> there.
Adam did attempt to cc linux-scsi but at 140kbytes the email probably got
spat out.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
2004-05-22 9:09 ` 2.6.6-mm5 Jeff Garzik
@ 2004-05-22 9:26 ` hch
2004-05-22 9:32 ` 2.6.6-mm5 Andrew Morton
2004-05-22 9:38 ` 2.6.6-mm5 hch
` (5 subsequent siblings)
7 siblings, 1 reply; 32+ messages in thread
From: hch @ 2004-05-22 9:26 UTC (permalink / raw)
To: Andrew Morton, brking; +Cc: linux-kernel
> +ipr-ppc64-depends.patch
>
> Make ipr.c depend on PPC
>> Makes ipr depend on CONFIG_PPC since this driver is unique to PPC hardware.
>>
>> (It actually builds OK on x86, but it heavily uses anonymous unions, which
>> breaks on gcc-2.95)
I use gcc-2.95 happily on ppc. Better thing is to either fix it up not to
use anonymous unions (which is a pitty because that feature helps making
code more readable sometimes) or stick a
#if (__GNUC__ < 3)
# error "This driver requires GCC 3.x"
#endif
ontop of the driver so people know why it fails at least.
Still wondering why these fixes don't go trhough linux-scsi..
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 9:09 ` 2.6.6-mm5 Jeff Garzik
@ 2004-05-22 9:22 ` hch
2004-05-22 9:26 ` 2.6.6-mm5 Andrew Morton
2004-05-22 11:51 ` 2.6.6-mm5 R. J. Wysocki
1 sibling, 1 reply; 32+ messages in thread
From: hch @ 2004-05-22 9:22 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, linux-kernel, SCSI Mailing List
On Sat, May 22, 2004 at 05:09:59AM -0400, Jeff Garzik wrote:
> Andrew Morton wrote:
> >- Added a new SATA RAID driver from 3ware. From a quick peek it seem to
> > need a little work yet.
>
>
> It's not too bad... but it looks more like a 2.2 driver forward ported
> to 2.4, than a 2.6.x driver. Needs some luvin' from the 2.6 scsi api crew.
>
> Overall, it appears to be a message-based firmware engine like
> drivers/block/carmel.c, that hides the SATA details in the firmware.
In addition driver submission should always go through linux-scsi. Please
tell them to submit it to linux-scsi so we can have a public review process
there.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: 2.6.6-mm5
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
@ 2004-05-22 9:09 ` Jeff Garzik
2004-05-22 9:22 ` 2.6.6-mm5 hch
2004-05-22 11:51 ` 2.6.6-mm5 R. J. Wysocki
2004-05-22 9:26 ` 2.6.6-mm5 hch
` (6 subsequent siblings)
7 siblings, 2 replies; 32+ messages in thread
From: Jeff Garzik @ 2004-05-22 9:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, SCSI Mailing List
Andrew Morton wrote:
> - Added a new SATA RAID driver from 3ware. From a quick peek it seem to
> need a little work yet.
It's not too bad... but it looks more like a 2.2 driver forward ported
to 2.4, than a 2.6.x driver. Needs some luvin' from the 2.6 scsi api crew.
Overall, it appears to be a message-based firmware engine like
drivers/block/carmel.c, that hides the SATA details in the firmware.
Jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* 2.6.6-mm5
@ 2004-05-22 8:36 Andrew Morton
2004-05-22 9:09 ` 2.6.6-mm5 Jeff Garzik
` (7 more replies)
0 siblings, 8 replies; 32+ messages in thread
From: Andrew Morton @ 2004-05-22 8:36 UTC (permalink / raw)
To: linux-kernel
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm5/
- Some rearchitecting of the VFS's symlink walking code. Reduces stack
usage and apparently permits us to increase the maximum hop count from 5 to
8, although the patch doesn't actually do that.
- Implementation of request barriers for IDE and SCSI. The idea here is
that a filesystem can tag an IO request as a barrier and the disk will not
reorder writes across the barrier. It provides additional integrity
guarantees for the journalling filesystems. The feature is enabled for
reiserfs and ext3.
On reiserfs do `mount /dev/hda /wherever -o barrier=flush' or
`barrier=none'.
On ext3 do `mount ... -o barrier=1' or `barrier=0'.
ext3 also supports `mount -o remount,barrier=N'. I didn't check whether
reiserfs supports switching at remount time and nobody tells me these
things.
(Yes, we should give these mount options the same name).
Although this feature has been around for a while it is new code, and the
usual cautions apply. If it munches all your files please tell Jens and
he'll type them in again for you.
- The pagecache radix-tree spinlocks have gone back to rwlocks again. It
helps big SMP significantly and doesn't seem to make much difference to
small SMP (1-2% at most IIRC). It does need some more measuring.
- Added a new SATA RAID driver from 3ware. From a quick peek it seem to
need a little work yet.
linus.patch
bk-agpgart.patch
bk-alsa.patch
bk-arm.patch
bk-cpufreq.patch
bk-driver-core.patch
bk-i2c.patch
bk-input.patch
bk-libata.patch
bk-netdev.patch
bk-ntfs.patch
bk-pci.patch
bk-pcmcia.patch
bk-scsi.patch
Latest versions of various development trees
-system-state-splitup.patch
-idedisk_reboot.patch
-fealnx-bogon-fix.patch
-blk_run_page-race-fix.patch
-put-module-license-in-swim3c.patch
-ppc32-get-full-register-set-on-bad-kernel-accesses.patch
-stack-reductions-nfsread.patch
-use-less-stack-in-ide_unregister.patch
-mark-config_mac_serial-drivers-macintosh-macserialc-as-broken.patch
-dpt_i2o-warning-fixes.patch
-invalid-notify_changesymlink-in-nfsd.patch
-nfs_writepage_sync-stack-reduction.patch
-nfs4-stack-reduction.patch
-raid-locking-fix.patch
-seeky-readahead-speedups.patch
-add-disable-param-to-capabilities-module.patch
-remove-hardcoded-offsets-from-i386-asm.patch
-madvise-len-check.patch
-dentry-size-tuning.patch
-vm-shrink-zone.patch
-vm-shrink-zone-fix.patch
-enable-runtime-cache-line-size-for-slab-on-i386.patch
-allow-arch-override-for-kmem_bufctl_t.patch
-add-kmem_cache_alloc_node.patch
-work-around-gcc-333-hammer-sched-miscompilation-on-x86-64.patch
-befs-maintainer-update.patch
-nfs-long-symlinks-fix.patch
-fix-for-266-makefiles-to-get-kbuild_output-working.patch
-kexec-reserve-syscall-slot.patch
-fore200e-warning-fixes.patch
-qlogicfas408-warning-fix.patch
-blk_run_queues-remnants.patch
-use-idr_get_new-to-allocate-a-bus-id-in-drivers-i2c-i2c-corec.patch
-use-idr_get_new-to-allocate-a-bus-id-in-drivers-i2c-i2c-corec-update-to-new-api.patch
-replace-mod_inc_use_count-in-cyber2000fb.patch
-dont-mention-mod_inc_use_count-mod_dec_use_count-in-docs.patch
-mark-plan-video-driver-broken.patch
-kbuild-subdirs=more-than-one.patch
-correct-ps2esdi-module-parm-name.patch
-fix-error-handling-in-selinuxfs.patch
-quota-fix-3-quota-file-corruption.patch
-submittingdrivers-completeness.patch
-edd-remove-unused-scsi-header-files.patch
-efivars-add-module_version-remove-unnecessary-check-in-exit.patch
-do_generic_mapping_read-cleanup.patch
-drivers-cdrom-aztcdc-warning-fix.patch
-init-mca_bus_type-even-if-mca_bus.patch
-split-backing_dev-memory-backed.patch
-ramdisk-fixes.patch
-ramdisk-memory-allocation-fixes.patch
-ramdisk-lock-io-pages.patch
-ramdisk-use-kmap_atomic.patch
-ramdisk-page-uptodate-fix.patch
-ramdisk-writepages.patch
-blockdev-split-backing_dev_info.patch
-ramdisk-split-backing_dev_info.patch
-knfsd-1-of-10-use-correct-_bh-locking-on-sv_lock.patch
-knfsd-2-of-10-make-sure-cache_negative-is-cleared-when-a-cache-entry-is-updates.patch
-knfsd-3-of-10-allow-larger-writes-to-sunrpc-svc-caches.patch
-knfsd-4-of-10-change-fh_compose-to-not-consume-a-reference-to-the-dentry.patch
-knfsd-5-of-10-protect-reference-to-exp-across-calls-to-nfsd_cross_mnt.patch
-knfsd-6-of-10-fix-race-conditions-in-idmapper.patch
-knfsd-7-of-10-improve-idmapper-behaviour-on-failure.patch
-knfsd-8-of-10-reduce-timeout-when-waiting-for-idmapper-userspace-daemon.patch
-knfsd-9-of-10-remove-check-on-number-of-threads-waiting-on-user-space.patch
-knfsd-10-of-10-add-a-warning-when-upcalls-fail.patch
-svc_recv-fix.patch
-debugging-option-to-put-data-symbols-in-kallsyms.patch
-sis900-add-new-isa-bridge-pci-id.patch
-sis900-small-cleanup-and-spelling-fixes.patch
-cache-sizing-fix.patch
-vga16fb-fix.patch
-fix-overzealous-use-of-online-cpu-iterators.patch
Merged
+nosysfs-sysfs_rename_dir-fix.patch
Fix !CONFIG_SYSFS build
+vga16fb-warning-fix.patch
Fix a warning
+gss_api-build-fix.patch
+gss_api-build-fix-tweak.patch
Fix NFS build with gcc-2.95
+make-tree_lock-an-rwlock.patch
Switch the pagecache lock back from a spinlock to an rwlock. Better for big
SMP and pretty much a wash for small SMP.
+radix_tree_tag_set-atomic.patch
Make the radix-tree tagging operations atomic
+radix_tree_tag_set-only-needs-read_lock.patch
Switch lots of pagecache write_locks to read_locks.
+ppc64-console-autodetection-for-pmac.patch
PPC64 power mac fix/feature
-sched-ifdef-active-balancing.patch
Dropped - was a bit messy.
-speed-up-sata.patch
Dropped - was obsolete.
+reiserfs-block-allocator-should-not-inherit-packing-locality.patch
Fix a bug in reiserfs-group-alloc-9.patch
-make-4k-stacks-permanent.patch
Dropped - 8k stacks work better with kgdb.
-mlock_group-sysctl.patch
Dropped - don't see a need for this.
+use-idr_get_new-to-allocate-a-bus-id-in-drivers-i2c-i2c-corec-update-to-new-api.patch
Fix i2c build for lib/idr.c changes
-mqueue-rlimit-compile-fix-for-ppc-cris-m68k.patch
Folded into rlim-add-rlimit-entry-for-posix-mqueue-allocation.patch
+hpet-rtc-dependency-fix.patch
+hpet-free_irq-deadlock-fix.patch
HPET driver fixes
+ext3-retry-allocation-after-transaction-commit-v2-jbd-api.patch
Clean up the interfaces in the ext3 -ENOSPC fix patch
+vmscan-handle-synchronous-writepage-fix.patch
Fix vmscan-handle-synchronous-writepage.patch
+ramdisk-buffer-uptodate-fix.patch
Fiddle with the ramdisk pagecache code a bit.
+ppc64-fault-deadlock-fix.patch
+ia32-fault-deadlock-fix.patch
+ia32-fault-deadlock-fix-cleanup.patch
Avoid deadlocking the kernel when it takes an oops while holding the tasks's
mmap_sem.
+ext3-htree-rename-fix.patch
Fix an htree bug
+out-of-bounds-access-in-hiddev_cleanup.patch
Fix some USB oops
+sis900-xcvr-fix.patch
sis900 transceiver handling fix
+advansys-basic-highmem-dma-support.patch
Add highmem support to the Advansys scsi driver
+fbdev-mode-switching-fix.patch
fbdev fix
+ipr-gcc-attribute-fixes.patch
scsi driver fix
+ipr-ppc64-depends.patch
Make ipr.c depend on PPC
+SL0-core-RC6-bk5.patch
+SL1-ext2-RC6-bk5.patch
+SL2-trivial-RC6-bk5.patch
+SL3-page-RC6-bk5.patch
+SL4-smb-RC6-bk5.patch
+SL5-xfs-RC6-bk5.patch
+SL6-shm-RC6-bk5.patch
+SL7-befs-RC6-bk5.patch
+SL8-jffs2-RC6-bk5.patch
symlink rework
+scsi-qla1280c-warning-fix.patch
Fix a warning
+trivial-use-page_to_phys-in-dma_map_page.patch
cleanup
+trivial-fix-duplicated-includes.patch
Remove lots of duplicated includes
+fix-knfsd-scary-message.patch
Prevent a rude boot-time message coming out of the kernel NFS server.
+mangled-printk-oops-output-fix.patch
+mangled-printk-oops-output-fix-tweaks.patch
Should fix the mess which comes out on the serial console when an SMP box
oopses.
+crypto-scatterwalk-fixes.patch
Fix a few things in the crypto scatter/gather code
+sanitise-unneeded-syscall-stubs.patch
+sanitise-unneeded-syscall-stubs-fixes.patch
Clean up the selection of which architectures want which syscall stubs.
+ep_send_events-simplification.patch
Stack reduction in eventpoll
+blk-completion-clear-stack-pointer-on-return.patch
Prevent possible crashes which haven't happened yet.
+disk-barrier-core.patch
+disk-barrier-core-tweaks.patch
+disk-barrier-ide.patch
+disk-barrier-ide-symbol-expoprt.patch
+disk-barrier-ide-warning-fix.patch
+disk-barrier-scsi.patch
Support for IDE and SCSI barriers
+disk-barrier-dm.patch
+disk-barrier-md.patch
Via device mapper and raid as well.
+reiserfs-v3-barrier-support.patch
Implement it on reiserfs
+ext3-barrier-support.patch
+#ext3-barrier-support-default-on.patch
+sync_dirty_buffer-retval.patch
+jbd-barrier-fallback-on-failure.patch
And on ext3
+x86-stack-dump-fixes.patch
Tidy a few things up
+add-futex_cmp_requeue-futex-op.patch
New futex mode
+swsusp-kill-unneccessary-debugging.patch
Cleanup
+race-condition-with-current-group_info.patch
+race-condition-with-current-group_info-tweaks.patch
Fix a race in the new group-handling code
+swsusp-fix-devfs-breakage-introduced-in-266.patch
swsusp fix
+check-return-status-of-register-calls-in-i82365.patch
Missing error return checks
+26-isdn-eicon-driver-fix-__devexit-in-prototype.patch
ISDN fix
+cpuid-cache-info-update.patch
Intel P4E's were missing cache-size info.
+3ware-9000-sata-raid-driver-for-266-mm5.patch
New SATA RAID driver from 3ware.
+autofs4-printk-cleanup.patch
+autofs4-maintainer.patch
autofs changes.
All 264 patches
linus.patch
nosysfs-sysfs_rename_dir-fix.patch
Fix !CONFIG_SYSFS build
vga16fb-warning-fix.patch
vga16fb warning fix
gss_api-build-fix.patch
gss_api build fix
gss_api-build-fix-tweak.patch
gss_api-build-fix-tweak
bk-agpgart.patch
bk-alsa.patch
bk-arm.patch
bk-cpufreq.patch
bk-driver-core.patch
bk-i2c.patch
bk-input.patch
bk-libata.patch
bk-netdev.patch
bk-ntfs.patch
bk-pci.patch
bk-pcmcia.patch
bk-scsi.patch
mm.patch
add -mmN to EXTRAVERSION
revert-i8042-interrupt-handling.patch
revert i8042 input interrupt handling changes
kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kgdbL warning fix
kgdb buffer overflow fix
kgdbL warning fix
kgdb: CONFIG_DEBUG_INFO fix
x86_64 fixes
correct kgdb.txt Documentation link (against 2.6.1-rc1-mm2)
kgdb: fix for recent gcc
kgdb warning fixes
THREAD_SIZE fixes for kgdb
kgdb-in-sched_functions.patch
kgdboe-netpoll.patch
kgdb-over-ethernet via netpoll
kgdboe: fix configuration of MAC address
kgdb-x86_64-support.patch
kgdb-x86_64-support.patch for 2.6.2-rc1-mm3
kgdb-x86_64-warning-fixes
kgdb-in-sched_functions-x86_64.patch
kgdb-ia64-support.patch
IA64 kgdb support
swapper_space-tree_lock-fix.patch
Make swapper_space tree_lock irq-safe
__add_to_swap_cache-simplification.patch
__add_to_swap_cache and add_to_pagecache() simplification
revert-swapcache-changes.patch
revert recent swapcache handling changes
vmscan-revert-may_enter_fs-changes.patch
vmscan-revert-may_enter_fs-changes
sync_page-use-swapper-space.patch
Make sync_page use swapper_space again
__set_page_dirty_nobuffers-race-fix.patch
__set_page_dirty_nobuffers race fix
rmap-7-object-based-rmap.patch
rmap 7 object-based rmap
rmap-7-object-based-rmap-sync_page-fix
ia64-rmap-build-fix.patch
ia64 rmap build fix
rmap-8-unmap-nonlinear.patch
rmap 8 unmap nonlinear
try_to_unmap_cluster-comment
slab-panic.patch
slab: consolidate panic code
rmap-9-remove-pte_chains.patch
rmap 9 remove pte_chains
page_add_anon_rmap BUG fix
rmap-10-add-anonmm-rmap.patch
rmap 10 add anonmm rmap
rmap-anonhd-locking-fix.patch
rmap anonhd locking fix
rmap-11-mremap-moves.patch
rmap 11 mremap moves
rmap-12-pgtable-remove-rmap.patch
rmap 12 pgtable remove rmap
rmap-13-include-asm-deletions.patch
rmap 13 include/asm deletions
i_mmap_lock.patch
Convert i_shared_sem back to a spinlock
i_mmap_lock fix 1
i_mmap_lock fix 2
i_mmap_lock mremap fix
rmap-14-i_shared_lock-fixes.patch
rmap 14: i_shared_lock fixes
numa-api-x86_64.patch
numa api: -64 support
numa api: Bitmap bugfix
numa-api-i386.patch
numa api: Add i386 support
numa-api-ia64.patch
numa api: Add IA64 support
numa-api-core.patch
numa api: Core NUMA API code
numa api: docs and policy_vma() locking fix
numa-api-core-tweaks
Some fixes for NUMA API
From: Matthew Dobson <colpatch@us.ibm.com>
Subject: [PATCH] include/linux/gfp.h cleanup for NUMA API
numa-api-core bitmap_clear fixes
mpol-in-copy_vma.patch
mpol in copy_vma
numa-api-core-slab-panic.patch
numa-api-core-slab-panic
numa-api-statistics-2.patch
Re-add NUMA API statistics
numa-api-vma-policy-hooks.patch
numa api: Add VMA hooks for policy
numa-api-vma-policy-hooks fix
numa-api-shared-memory-support.patch
numa api: Add shared memory support
numa-api-shared-memory-support-tweaks
small-numa-api-fixups.patch
small numa api fixups
small-numa-api-fixups-fix
small-numa-api-fixups-fix.patch
small-numa-api-fixups-fix
numa-api-statistics.patch
numa api: Add statistics
numa-api-anon-memory-policy.patch
numa api: Add policy support to anonymous memory
numa-api-fix-end-of-memory-handling-in-mbind.patch
numa api: fix end of memory handling in mbind
rmap-15-vma_adjust.patch
rmap 15: vma_adjust
rmap-16-pretend-prio_tree.patch
rmap 16: pretend prio_tree
rmap-17-real-prio_tree.patch
rmap 17: real prio_tree
rmap-18-i_mmap_nonlinear.patch
rmap 18: i_mmap_nonlinear
unmap_mapping_range-comment.patch
unmap_mapping_range-comment
rmap-19-arch-prio_tree.patch
rmap 19: arch prio_tree
rmap-19-arch-prio_tree-parisc
vm_area_struct-size-comment.patch
vm_area_struct size comment
rmapc-comment-style-fixups.patch
rmap.c comment/style fixups
rmap-20-i_mmap_shared-into-i_mmap.patch
rmap 20 i_mmap_shared into i_mmap
rmap-20-i_mmap_shared-into-i_mmap-parisc
rmap-21-try_to_unmap_one-mapcount.patch
rmap 21 try_to_unmap_one mapcount
rmap-22-flush_dcache_mmap_lock.patch
rmap 22 flush_dcache_mmap_lock
rmap-22-flush_dcache_mmap_lock-parisc
rmap-23-empty-flush_dcache_mmap_lock.patch
rmap 23 empty flush_dcache_mmap_lock
rmap-24-no-rmap-fastcalls.patch
rmap 24 no rmap fastcalls
rmap-27-memset-0-vma.patch
rmap 27 memset 0 vma
rmap-28-remove_vm_struct.patch
rmap 28 remove_vm_struct
rmap-29-vm_reserved-safety.patch
rmap 29 VM_RESERVED safety
rmap-30-fix-bad-mapcount.patch
rmap 30 fix bad mapcount
rmap-31-unlikely-bad-memory.patch
rmap 31 unlikely bad memory
rmap-32-zap_pmd_range-wrap.patch
rmap 32 zap_pmd_range wrap
rmap-33-install_arg_page-vma.patch
rmap 33 install_arg_page vma
rmap-34-vm_flags-page_table_lock.patch
rmap 34 vm_flags page_table_lock
rmap-35-mmapc-cleanups.patch
rmap 35 mmap.c cleanups
rmap-36-mprotect-use-vma_merge.patch
rmap 36 mprotect use vma_merge
rmap-37-page_add_anon_rmap-vma.patch
rmap 37 page_add_anon_rmap vma
rmap-38-remove-anonmm-rmap.patch
rmap 38 remove anonmm rmap
rmap-39-add-anon_vma-rmap.patch
rmap 39 add anon_vma rmap
rmap-40-better-anon_vma-sharing.patch
rmap 40 better anon_vma sharing
partial-prefetch-for-vma_prio_tree_next.patch
partial prefetch for vma_prio_tree_next
make-tree_lock-an-rwlock.patch
make mapping->tree_lock an rwlock
radix_tree_tag_set-atomic.patch
Make radix_tree_tag_set/clear atomic wrt the tag
radix_tree_tag_set-only-needs-read_lock.patch
radix_tree_tag_set only needs read_lock()
must-fix.patch
must fix lists update
must fix list update
mustfix update
must-fix-update-5.patch
must-fix update
ppc64-console-autodetection-for-pmac.patch
From: Olaf Hering <olh@suse.de>
Subject: [PATCH] console autodetection for pmac
ppc64-reloc_hide.patch
invalidate_inodes-speedup.patch
invalidate_inodes speedup
more invalidate_inodes speedup fixes
config_spinline.patch
uninline spinlocks for profiling accuracy.
allow-i386-to-reenable-interrupts-on-lock-contention.patch
Allow i386 to reenable interrupts on lock contention
pdflush-diag.patch
get_user_pages-handle-VM_IO.patch
fix get_user_pages() against mappings of /dev/mem
pci_set_power_state-might-sleep.patch
slab-leak-detector.patch
slab leak detector
mm/slab.c warning in cache_alloc_debugcheck_after
local_bh_enable-warning-fix.patch
schedstats.patch
sched: scheduler statistics
cond_resched-might-sleep.patch
cond_resched() might sleep
fa311-mac-address-fix.patch
wrong mac address with netgear FA311 ethernet card
pid_max-fix.patch
Bug when setting pid_max > 32k
non-readable-binaries.patch
Handle non-readable binfmt_misc executables
binfmt_misc-credentials.patch
binfmt_misc: improve calaulation of interpreter's credentials
poll-select-longer-timeouts.patch
poll()/select(): support longer timeouts
poll-select-range-check-fix.patch
poll()/select() range checking fix
poll-select-handle-large-timeouts.patch
poll()/select(): handle long timeouts
add-a-slab-for-ethernet.patch
Add a kmalloc slab for ethernet packets
siimage-update.patch
ide: update for siimage driver
shm-do_munmap-check.patch
stack-overflow-test-fix.patch
Fix stack overflow test for non-8k stacks
jbd-remove-livelock-avoidance.patch
JBD: remove livelock avoidance code in journal_dirty_data()
logitech-keyboard-fix.patch
2.6.5-rc2 keyboard breakage
journal_add_journal_head-debug.patch
journal_add_journal_head-debug
list_del-debug.patch
list_del debug check
oops-dump-preceding-code.patch
i386 oops output: dump preceding code
lockmeter.patch
lockmeter
ia64 CONFIG_LOCKMETER fix
sk98lin-buggy-vpd-workaround.patch
net/sk98lin: correct buggy VPD in ASUS MB
unplug-can-sleep.patch
unplug functions can sleep
firestream-warnings.patch
firestream warnings
ext3_rsv_cleanup.patch
ext3 block reservation patch set -- ext3 preallocation cleanup
ext3_rsv_base.patch
ext3 block reservation patch set -- ext3 block reservation
ext3 reservations: fix performance regression
ext3 block reservation patch set -- mount and ioctl feature
ext3 block reservation patch set -- dynamically increase reservation window
ext3-reservation-default-on.patch
ext3 reservation: default to on
ext3-reservation-ifdef-cleanup-patch.patch
ext3 reservation ifdef cleanup patch
ext3-reservation-max-window-size-check-patch.patch
ext3 reservation max window size check patch
ext3-reservation-file-ioctl-fix.patch
ext3 reservation file ioctl fix
ext3-lazy-discard-reservation-window-patch.patch
ext3 lazy discard reservation window patch
ext3 discard reservation in last iput fix patch
Fix lazy reservation discard
ext3-reservation-bad-inode-fix.patch
ext3 reservations: bad_inode fix
ext3_reservation_discard_race_fix.patch
ext3 reservation discard race fix
clean-up-asm-pgalloch-include.patch
Clean up asm/pgalloc.h include
clean-up-asm-pgalloch-include-2.patch
Clean up asm/pgalloc.h include
clean-up-asm-pgalloch-include-3.patch
Clean up asm/pgalloc.h include 3
ppc64-uninline-__pte_free_tlb.patch
ppc64: uninline __pte_free_tlb()
input-tsdev-fixes.patch
tsdev.c fixes
fix-scancode-keycode-scancode-conversion-for-265.patch
Fix scancode->keycode->scancode conversion
fealnx-mac-address-and-other-issues.patch
Fealnx. Mac address and other issues
reiserfs-group-alloc-9.patch
reiserfs: block allocator optimizations
reiserfs-block-allocator-should-not-inherit-packing-locality.patch
reiserfs: block allocator should not inherit "packing locality 1"
reiserfs-remove-debugging-warning-from-block-allocator.patch
reiserfs: remove debugging warning from block allocator
reiserfs-group-alloc-9-build-fix.patch
reiserfs-group-alloc-9 build fix
reiserfs-search_reada-5.patch
reiserfs: btree readahead
reiserfs-data-logging-support.patch
reiserfs data logging support
problems-with-atkbd_command--atkbd_interrupt-interaction.patch
Problems with atkbd_command & atkbd_interrupt interaction
sis-agp-updates.patch
fbdev: SIS AGP updates
clear_backing_dev_congested.patch
clear_baking_dev_congested
force-config_regparm-to-y.patch
Force CONFIG_REGPARM to `y'
hugetlb_shm_group-sysctl-gid-0-fix.patch
hugetlb_shm_group sysctl-gid-0-fix
idr-overflow-fixes.patch
Fixes for idr code
idr-remove-counter.patch
idr: remove counter bits from id's
idr-fixups.patch
IDR fixups
use-idr_get_new-to-allocate-a-bus-id-in-drivers-i2c-i2c-corec-update-to-new-api.patch
use-idr_get_new-to-allocate-a-bus-id-in-drivers-i2c-i2c-corec-update-to-new-api
rlim-add-rlimit-entry-for-controlling-queued-signals.patch
RLIM: add rlimit entry for controlling queued signals
rlim-add-sigpending-field-to-user_struct.patch
RLIM: add sigpending field to user_struct
rlim-pass-task_struct-in-send_signal.patch
RLIM: pass task_struct in send_signal()
rlim-add-simple-get_uid-helper.patch
RLIM: add simple get_uid() helper
rlim-enforce-rlimits-on-queued-signals.patch
RLIM: enforce rlimits on queued signals
rlim-remove-unused-queued_signals-global-accounting.patch
RLIM: remove unused queued_signals global accounting
rlim-add-rlimit-entry-for-posix-mqueue-allocation.patch
RLIM: add rlimit entry for POSIX mqueue allocation
rlim-add-mq_bytes-to-user_struct.patch
RLIM: add mq_bytes to user_struct
rlim-add-mq_attr_ok-helper.patch
RLIM: add mq_attr_ok() helper
rlim-enforce-rlimits-for-posix-mqueue-allocation.patch
RLIM: enforce rlimits for POSIX mqueue allocation
rlim-adjust-default-mqueue-sizes.patch
RLIM: adjust default mqueue sizes
call-might_sleep-in-tasklet_kill.patch
Call might_sleep() in tasklet_kill
add-qsort-library-function.patch
add qsort library function
have-xfs-use-kernel-provided-qsort.patch
Have XFS use kernel-provided qsort
have-xfs-use-kernel-provided-qsort-fix.patch
have-xfs-use-kernel-provided-qsort-fix
slabify-iocontext-request_queue-SLAB_PANIC.patch
slabify-iocontext-request_queue: use SLAB_PANIC
really-ptrace-single-step-2.patch
ptrace single-stepping fix
fix-crash-on-modprobe-ohci1394.patch
fix crash on `modprobe ohci1394; modprobe -r ohci1394'
abs-cleanup.patch
abs() cleanup
add-i386-readq.patch
add i386 readq()/writeq()
hpet-driver.patch
HPET driver
hpet-driver-updates.patch
HPET driver updates
hpet-driver-updates-move-readq.patch
hpet-driver-updates-move-readq
hpet-kconfig-loop-fix.patch
HPET: Fix Kconfig dependency loop
hpet-rtc-dependency-fix.patch
HPET RTC dependency fix
hpet-free_irq-deadlock-fix.patch
hpet-free_irq-deadlock-fix
checkstack-target.patch
Add `make checkstack' target
kill-off-pc9800.patch
Remove PC9800 support
more-pc9800-removal.patch
more PC9800 removal
pc9800-merge-std_resourcesc-back-into-setupc.patch
pc9800: merge std_resources.c back into setup.c
266-mm2-r8169-ethtool-set_settings.patch
r8169: ethtool .set_settings
266-mm2-r8169-ethtool-get_settings.patch
r8169: ethtool .get_settings
266-mm2-r8169-link-handling-rework-1-2.patch
r8169: link handling rework (1/2)
266-mm2-r8169-link-handling-rework-2-2.patch
r8169: link handling rework (2/2)
hfsplus-dir-rename-fix.patch
hfsplus directory renaming fix
ftruncate-vs-block_write_full_page.patch
ftruncate-vs-block_write_full_page
fix-userspace-include-of-linux-fsh.patch
Fix userspace include of linux/fs.h
ext3-retry-allocation-after-transaction-commit-v2.patch
Ext3: Retry allocation after transaction commit (v2)
ext3-retry-allocation-after-transaction-commit-v2-jbd-api.patch
ext3-retry-allocation-after-transaction-commit-v2: implement JBD API
sysfs-leaves-mount.patch
sysfs backing store: add sysfs_dirent
sysfs-leaves-dir.patch
sysfs backing store: add sysfs_dirent
sysfs-leaves-file.patch
sysfs backing store: sysfs_create() changes
sysfs-leaves-bin.patch
sysfs backing store: bin attribute changes
sysfs-leaves-symlink.patch
sysfs backing store: sysfs_create_link changes
sysfs-leaves-misc.patch
sysfs backing store: attribute groups and misc routines
pty-allocation-first-fit.patch
pty-allocation-first-fit-fix
sync_inodes_sb-debug.patch
sync_inodes_sb-debug
vmscan-handle-synchronous-writepage.patch
vmscan: handle synchronous writepage()
vmscan-handle-synchronous-writepage-fix.patch
vmscan-handle-synchronous-writepage-fix
ramdisk-buffer-uptodate-fix.patch
ramdisk: buffer_uptodate fix
2-3-small-tweaks-to-standard-resource-stuff.patch
small tweaks to standard resource stuff
3-3-same-small-tweaks-x86_64-version.patch
same small resource tweaks, x86_64 version
sis900-maintainer.patch
Sis900: maintainer update
sis900-fix-phy-transceiver-detection.patch
sis900: Fix PHY transceiver detection
getgroups16-fix.patch
getgroups16() fix
fixing-sendfile-on-64bit-architectures.patch
fix sendfile on 64bit architectures
ppc64-fault-deadlock-fix.patch
ppc64: fix deadlocks due to fault-inside-mmap_sem
ia32-fault-deadlock-fix.patch
ia32: fix deadlocks due to fault-inside-mmap_sem
ia32-fault-deadlock-fix-cleanup.patch
ia32-fault-deadlock-fix cleanup
ext3-htree-rename-fix.patch
ext3: htree rename fix
out-of-bounds-access-in-hiddev_cleanup.patch
out of bounds access in hiddev_cleanup
sis900-xcvr-fix.patch
sis900 transceiver fix
advansys-basic-highmem-dma-support.patch
advansys: add basic highmem/DMA support
fbdev-mode-switching-fix.patch
fbdev: mode switching fix.
ipr-gcc-attribute-fixes.patch
Fix drivers/scsi/ipr.c on ia32
SL0-core-RC6-bk5.patch
symlinks: infrastructure
SL1-ext2-RC6-bk5.patch
symlinks: ext2 conversion
SL2-trivial-RC6-bk5.patch
symlinks: trivial cases
SL3-page-RC6-bk5.patch
symlinks: reuse new helpers
SL4-smb-RC6-bk5.patch
symlinks: smbfs
SL5-xfs-RC6-bk5.patch
symlinks: XFS
SL6-shm-RC6-bk5.patch
symlinks: tmpfs
SL7-befs-RC6-bk5.patch
symlinks: befs
SL8-jffs2-RC6-bk5.patch
symlinks: jffs2
ipr-ppc64-depends.patch
Make ipr.c require ppc
scsi-qla1280c-warning-fix.patch
scsi/qla1280.c warning fix.
trivial-use-page_to_phys-in-dma_map_page.patch
trivial: use page_to_phys in dma_map_page()
trivial-fix-duplicated-includes.patch
trivial: remove duplicated #includes
trivial: drivers/media/video_saa7134_saa7134-input.c: kill duplicate include
Subject: [TRIVIAL] [TRIVIAL 2.6] drivers_net_wireless_orinoco_plx.c: kill duplicate
fix-knfsd-scary-message.patch
Prevent scary warnings from knfsd
mangled-printk-oops-output-fix.patch
Fix the mangled-oops-output-on-SMP problem
mangled-printk-oops-output-fix-tweaks.patch
mangled-printk-oops-output-fix tweaks
crypto-scatterwalk-fixes.patch
crypto scatterwalking fixes
sanitise-unneeded-syscall-stubs.patch
Sanitise handling of unneeded syscall stubs
sanitise-unneeded-syscall-stubs-fixes.patch
sanitise-unneeded-syscall-stubs-fixes
ep_send_events-simplification.patch
ep_send_events-simplification
blk-completion-clear-stack-pointer-on-return.patch
blk: clear completion stack pointer on return
disk-barrier-core.patch
disk barriers: core
disk-barrier-core-tweaks.patch
disk-barrier-core-tweaks
disk-barrier-ide.patch
disk barriers: IDE
disk-barrier-ide-symbol-expoprt.patch
disk-barrier-ide-symbol-expoprt
disk-barrier-ide-warning-fix.patch
disk-barrier ide warning fix
disk-barrier-scsi.patch
disk barriers: scsi
disk-barrier-dm.patch
disk barriers: devicemapper
disk-barrier-md.patch
disk barriers: MD
reiserfs-v3-barrier-support.patch
reiserfs v3 barrier support
ext3-barrier-support.patch
ext3 barrier support
sync_dirty_buffer-retval.patch
make sync_dirty_buffer() return something useful
jbd-barrier-fallback-on-failure.patch
jbd: barrier fallback on failure
x86-stack-dump-fixes.patch
x86 stack dump fixes
add-futex_cmp_requeue-futex-op.patch
Add FUTEX_CMP_REQUEUE futex op
swsusp-kill-unneccessary-debugging.patch
From: Pavel Machek <pavel@ucw.cz>
Subject: swsusp: kill unneccessary debugging
race-condition-with-current-group_info.patch
Fix race condition with current->group_info
race-condition-with-current-group_info-tweaks.patch
race-condition-with-current-group_info-tweaks
swsusp-fix-devfs-breakage-introduced-in-266.patch
swsusp: fix devfs breakage introduced in 2.6.6
check-return-status-of-register-calls-in-i82365.patch
Check return status of register calls in i82365
26-isdn-eicon-driver-fix-__devexit-in-prototype.patch
i4l: Eicon driver: fix __devexit in prototype
cpuid-cache-info-update.patch
x86 cpuid cache info update
3ware-9000-sata-raid-driver-for-266-mm5.patch
3ware 9000 SATA-RAID driver for 2.6.6-mm5
autofs4-printk-cleanup.patch
autofs4: printk cleanup
autofs4-maintainer.patch
autofs4: MAINTAINERS update
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2004-05-27 19:16 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-22 10:27 2.6.6-mm5 Oleg Nesterov
[not found] <1YAd2-6Th-13@gated-at.bofh.it>
[not found] ` <1YPF4-2hJ-11@gated-at.bofh.it>
[not found] ` <1YPOI-2nq-1@gated-at.bofh.it>
[not found] ` <1YRdQ-3pu-5@gated-at.bofh.it>
2004-05-23 11:39 ` 2.6.6-mm5 Andi Kleen
2004-05-23 21:32 ` 2.6.6-mm5 Eric W. Biederman
2004-05-24 0:02 ` 2.6.6-mm5 Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2004-05-22 18:02 2.6.6-mm5 Adam Radford
2004-05-22 8:36 2.6.6-mm5 Andrew Morton
2004-05-22 9:09 ` 2.6.6-mm5 Jeff Garzik
2004-05-22 9:22 ` 2.6.6-mm5 hch
2004-05-22 9:26 ` 2.6.6-mm5 Andrew Morton
2004-05-22 11:51 ` 2.6.6-mm5 R. J. Wysocki
2004-05-22 9:26 ` 2.6.6-mm5 hch
2004-05-22 9:32 ` 2.6.6-mm5 Andrew Morton
2004-05-22 9:41 ` 2.6.6-mm5 hch
2004-05-22 19:03 ` 2.6.6-mm5 Brian King
2004-05-22 9:38 ` 2.6.6-mm5 hch
2004-05-22 9:44 ` 2.6.6-mm5 Jens Axboe
2004-05-22 9:46 ` 2.6.6-mm5 Felipe Alfaro Solana
2004-05-23 15:51 ` 2.6.6-mm5 James Morris
2004-05-22 11:59 ` 2.6.6-mm5 Matthias Andree
2004-05-23 1:01 ` 2.6.6-mm5 Eric W. Biederman
2004-05-23 1:08 ` 2.6.6-mm5 Andrew Morton
2004-05-23 1:15 ` 2.6.6-mm5 Roland Dreier
2004-05-24 16:17 ` 2.6.6-mm5 Matt Mackall
2004-05-24 17:03 ` 2.6.6-mm5 Eric W. Biederman
2004-05-24 17:43 ` 2.6.6-mm5 Roland Dreier
2004-05-25 7:25 ` 2.6.6-mm5 Eric W. Biederman
2004-05-23 2:45 ` 2.6.6-mm5 Eric W. Biederman
2004-05-25 13:53 ` 2.6.6-mm5 Pavel Machek
2004-05-26 12:41 ` 2.6.6-mm5 Anders Gustafsson
2004-05-26 12:49 ` 2.6.6-mm5 Jens Axboe
2004-05-26 12:59 ` 2.6.6-mm5 Anders Gustafsson
2004-05-26 13:03 ` 2.6.6-mm5 Jens Axboe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).