On Fri, 29 Dec 2006 03:32:02 -0800
Amit Choudhary [EMAIL PROTECTED] wrote:
Description: Fix error-path leak in function jffs2_scan_medium(), in file
fs/jffs2/scan.c
Signed-off-by: Amit Choudhary [EMAIL PROTECTED]
diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
index e241346..cd9ed6e
Unlike x86, x86_64 already passes arguments in registers. The use of
regparm attribute makes no difference in produced code, and the use of
fastcall just bloats the code.
--
Glauber de Oliveira Costa
Red Hat Inc.
Free as in Freedom
diff -rup linux-2.6.19.1-devel/arch/x86_64/kernel/acpi/sleep.c
On Sun, Dec 31, 2006 at 04:55:51PM +, Alistair John Strachan wrote:
On Sunday 31 December 2006 16:27, Adrian Bunk wrote:
On Sat, Dec 30, 2006 at 04:59:35PM +, Alistair John Strachan wrote:
On Thursday 28 December 2006 04:14, Alistair John Strachan wrote:
On Thursday 28 December
On Tue, 2006-12-26 at 13:37 -0500, jamal wrote:
On Tue, 2006-26-12 at 18:56 +0100, Ingo Molnar wrote:
+ xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
+ AUDIT_MAC_IPSEC_DELSPD, delete, xp, NULL);
+
if (!delete) {
struct sk_buff
On Sun, Dec 31, 2006 at 04:48:43PM +, Alistair John Strachan wrote:
On Sunday 31 December 2006 16:28, Adrian Bunk wrote:
On Sat, Dec 30, 2006 at 06:29:15PM +, Alistair John Strachan wrote:
On Saturday 30 December 2006 17:21, Chuck Ebbert wrote:
In-Reply-To: [EMAIL PROTECTED]
This is a silly complaint because the SFF layer in libata doesn't handle
this case yet anyway.
Yes, it's silly people people use configurations you find inconvenient.
At least one embedded x86 case cares, that I know of. They only needed
to make two minor changes to make it work.
*It
I/O errors could go unnoticed when syncing, for example the following code
could
write a file bigger than 10Mib on a 10Mib filesystem. With this patch, msync()
will report the error originally encountered by sync(). Tuning the number of
sync may be needed to reproduce the bug.
make_file.c:
Alan wrote:
This is a silly complaint because the SFF layer in libata doesn't handle
this case yet anyway.
Yes, it's silly people people use configurations you find inconvenient.
At least one embedded x86 case cares, that I know of. They only needed
to make two minor changes to make it work.
Jeff Garzik wrote:
* After your patch, the code explicitly calls pci_request_region() for
BARs 0-4, but never for BAR5.
Without checking for failures, I might add.
Let's call that regression/obvious bug #4, because the previous code
actually CARED if the resource was reserved.
The 32bit and 64bit PARISC Linux kernels suffers from the problem, that the
gettimeofday() call sometimes returns non-monotonic times.
The easiest way to fix this, is to drop the PARISC-specific implementation and
switch over to the generic TIME_INTERPOLATION framework.
But in order to make it
Quoting Mimi Zohar ([EMAIL PROTECTED]):
Being able to compile both SELinux and SLIM into the kernel was done
intentionally.
Intentionally so that you can switch back and forth for testing?
The kernel parameters 'selinux' and 'slim' can enable
or disable the LSM module at boot. Perhaps, for
On Tue, Jan 02, 2007 at 10:33:25PM +0100, Helge Deller wrote:
Ok, not Ok ?
Um, this is still doing cmpxchg() with insufficient locking. So, not
OK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Mon, Dec 25, 2006 at 01:08:31AM -0700, Grant Grundler wrote:
On Mon, Dec 25, 2006 at 01:06:35AM -0700, Grant Grundler wrote:
On Sat, Dec 23, 2006 at 11:07:26PM -0700, Grant Grundler wrote:
final patch v7 and commit log entry appended below. :)
v8 adds 2cd round of feedback from Randy
Oops ;-) resending, as I forgot to sign last version:
Unlike x86, x86_64 already passes arguments in registers. The use of
regparm attribute makes no difference in produced code, and the use of
fastcall just bloats the code.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
--
Glauber
On Tuesday 02 January 2007 21:10, Adrian Bunk wrote:
[snip]
Comparing your report and [1], it seems that if these are the same
problem, it's not a hardware bug but a gcc or kernel bug.
This bug specifically indicates some kind of miscompilation in a driver,
causing boot time hangs. My
This patch contains the scheduled IEEE1394_EXPORT_FULL_API removal.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
Documentation/feature-removal-schedule.txt |8 ---
drivers/ieee1394/Kconfig |7 --
drivers/ieee1394/ieee1394_core.c | 22
Incremental bugfix to previous 3 patch patchset of cpufreq lock rewrite.
There was one code path in cpufreq_get, that was using the write lock
in place of read and also potential recursive lock with sysfs
interface of cpuinfo_cur_freq.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
This patch contains the scheduled find_trylock_page() removal.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
Documentation/feature-removal-schedule.txt | 12
include/linux/pagemap.h|2 --
mm/filemap.c | 20
On Tue, 2 Jan 2007, Adrian Bunk wrote:
My point is that we have several reported problems only visible
with gcc 4.1.
Other bug reports are e.g. [2] and [3], but they are only present with
using gcc 4.1 _and_ using -Os.
Traditionally, afaik, -Os has tended to show compiler problems that
On Fri, 2006-12-29 at 11:25 -0500, Shawn Starr wrote:
Hello,
If any of you have used a Commodore 64 emulator in Linux (such as vice)
noticed when using audio there is severe starvation while other activities of
the system are going on. i.e. moving a window in X or starting another
On Tuesday 02 January 2007 16:56, Alistair John Strachan wrote:
On Tuesday 02 January 2007 21:10, Adrian Bunk wrote:
[snip]
Comparing your report and [1], it seems that if these are the same
problem, it's not a hardware bug but a gcc or kernel bug.
This bug specifically indicates
In the kernels later than 2.6.19 there is a regression that makes swsusp fail
if the resume device is not explicitly specified.
It can be fixed by adding an additional parameter to
mm/swapfile.c:swap_type_of() allowing us to pass the (struct block_device *)
corresponding to the first available
On Tue, 2 Jan 2007, Alistair John Strachan wrote:
At any rate, I have absolute confirmation that it is GCC 4.1.1, because with
GCC 3.4.6 the same kernel I reported booting three days ago is still
cheerfully working. I regularly get uptimes of 60+ days on that machine,
rebooting only for
On Tuesday January 2, [EMAIL PROTECTED] wrote:
On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
On Tue, 2 Jan 2007, Theodore Tso wrote:
I can very easily believe it. The US patent system and justice
system in the US is completely and totally insane, and companies
On Tue, Jan 02, 2007 at 11:23:35AM -0500, Lee Schermerhorn wrote:
When building 2.6.20-rc2-mm1 with CHECK_HEADERS=y, the Makefile will
build the target include/config/kernel.release twice.
I will try to take a look at this tomorrow.
This behavior appears to have been introduced by the patch:
I am wondering if we should define __likely/__unlikely macros no matter whether
CONFIG_LIKELY_PROFILE is defined, like the following. This way people can always
use the raw macros in case the debugging version causes problems.
Signed-off-by: Hua Zhong [EMAIL PROTECTED]
---
We use BAR5 on two devices in legacy mode. Both of those reserve all the
other resources.
Translation: You want to hand-wave away an obvious regression that YOU
have created with your fix-to-a-fix.
It's not regressing anything.
Why INTRODUCE these 2.6.20 Alan-isms, if they are going
On Tue, 02 Jan 2007 16:32:01 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Jeff Garzik wrote:
* After your patch, the code explicitly calls pci_request_region() for
BARs 0-4, but never for BAR5.
Without checking for failures, I might add.
The old code didn't reserve 1 or 3 at all let alone
On Wed, 3 Jan 2007 08:11:21 +1100 Neil Brown wrote:
Of course if people would just put milk in their coffee, we would have
this problem :-)
[We now return you to our regular program of filesystem corruption
and flame wars].
Yes, PLEEZE!
---
~Randy
-
To unsubscribe from this list: send the
Bill Huey (hui) wrote:
On Tue, Dec 26, 2006 at 04:51:21PM -0800, Chen, Tim C wrote:
Ingo Molnar wrote:
If you'd like to profile this yourself then the lowest-cost way of
profiling lock contention on -rt is to use the yum kernel and run
the attached trace-it-lock-prof.c code on the box while
Alan wrote:
We use BAR5 on two devices in legacy mode. Both of those reserve all the
other resources.
Translation: You want to hand-wave away an obvious regression that YOU
have created with your fix-to-a-fix.
It's not regressing anything.
False:
2.6.0 - 2.6.19: libata guarantees that
How many of them stuffed the cup between their legs though? I think it
she would have sqeezed the cup too hard and burned her hand and sued
McDonalds for that people would be more understainding...
How would what she did have any bearing on the key issue, which is whether
or not McDonald's
Alan wrote:
Actually it didn't reserve BAR1 and BAR3 in legacy mode precisely because
of the PCI resource mismanagement in the old tree. So you take your pick.
I pick old bugs over new regressions.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Tue, Jan 02, 2007 at 02:51:05PM -0800, Chen, Tim C wrote:
Bill,
I'm having some problem getting this patch to run stablely. I'm
encoutering errors like that in the trace that follow:
Thanks.
Tim
Unable to handle kernel NULL pointer dereference at 0008
Yes, those are
On Tue, 2 Jan 2007, Linus Torvalds wrote:
Traditionally, afaik, -Os has tended to show compiler problems that
_could_ happen with -O2 too, but never do in practice. It may be that
gcc-4.1 without -Os miscompiles some very unusual code, and then with -Os
we just hit more cases of that.
Certainly, but tar isn't going to remember all the inode numbers.
Even if you solve the storage requirements (not impossible) it would
have to do (4e9^2)/2=8e18 comparisons, which computers don't have
enough CPU power just yet.
It is remembering all inode numbers with nlink 1 and many
Certainly, but tar isn't going to remember all the inode numbers.
Even if you solve the storage requirements (not impossible) it would
have to do (4e9^2)/2=8e18 comparisons, which computers don't have
enough CPU power just yet.
It is remembering all inode numbers with nlink 1 and many other
On 12/28/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
[ I'm only subscribed to linux-fsdevel@ from above Cc list, please keep this
list in Cc: for AIO related stuff. ]
On Wed, Dec 27, 2006 at 04:25:30PM +, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
(1) note that there is another
On Sat, 2006-12-30 at 19:19 +, Alistair John Strachan wrote:
On Saturday 30 December 2006 19:11, Michael S. Tsirkin wrote:
On Friday 29 December 2006 06:25, Michael S. Tsirkin wrote:
Virtual MIDI Card 1
Compile this feature out, I bet things start working again.
Yes, this
On Mon, 2007-01-01 at 23:45 +, Russell King wrote:
However the cache flushing in kmap/kunmap idea might be cleaner and
better.
It has the significant advantage that, unlike the flush* calls, they
can't really be forgotten by folk programming on cache alias-free
hardware. That's a
Benjamin Herrenschmidt wrote:
This is a trivial implementation that suits it's purpose.
It's simple. I'm not sure what more is needed for this
project when it's pretty clear that i386 will never need
any additional support for open firmware.
I don't agree. It's definitely not clear to me
On Tue, 2007-01-02 at 12:45 +0100, Segher Boessenkool wrote:
In addition, I haven't given on the idea one day of actually merging
the
powerpc and sparc implementation of a lot of that stuff. Mostly the
device-tree accessors proper, the of_device/of_platform bits etc...
into
something
On Tue, 2007-01-02 at 12:37 +0100, Segher Boessenkool wrote:
So please do this crap right.
I strongly agree. Nowadays, both powerpc and sparc use an in-memory
copy
of the tree (wether you use the flattened format during the trampoline
from OF runtime to the kernel or not is a
We could of course have the interface work either on a copy of the tree
or on a real OF (though that means changing things like get_property on
powerpc and fixing the gazillions of users) but I tend to think that
working on a copy always is more efficient.
The patch that I posted creates a
On Tue, 2007-01-02 at 13:22 +0100, Segher Boessenkool wrote:
Except that none of the powerpc platforms can keep OF alive after the
kernel has booted, which is why we do an in-memory copy of the tree.
Adding that functionality hasn't gotten easier at all since
we use the flattened tree for
On Tue, 2007-01-02 at 10:11 -1000, Mitch Bradley wrote:
We could of course have the interface work either on a copy of the tree
or on a real OF (though that means changing things like get_property on
powerpc and fixing the gazillions of users) but I tend to think that
working on a copy
Are you really suggesting that using a kernel copy of the
device tree is the correct thing to do, and the only correct
thing to do -- with the sole argument that that's what the
current ports do?
Well, there are reasons why that's what the current ports do :-)
Sure. It might have been a good
Not single thread -- but a global OF lock yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, or
The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
I'm a bit concerned about the
I do object basically to having something that doesn't also provide
in-kernel interfaces to access the device nodes properties.
That's the wrong way around. Work is underway to instead
have the devicetreefs *use* the in-kernel interfaces. Would
that be acceptable?
I don't
agree with the
The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
Oh I know. With a sane OF
All should converge on the same interface. That does not
ab initio mean we should converge on what you currently
have (although that might eventually be that case).
Well, Dave and I will happen to be in the same place in a few weeks for
LCA so we might spend some time having a look there if
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Tue, 2 Jan 2007 22:15:50 +0100
We also can keep the old names as compatibility accessors for
PowerPC only for a while, until everything is converted -- SPARC
can do the same then. You can't really keep the old PowerPC names
in kernel-wide code
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Tue, 2 Jan 2007 22:28:21 +0100
Not single thread -- but a global OF lock yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Tue, 2 Jan 2007 22:37:32 +0100
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Tue, 2 Jan 2007 22:40:17 +0100
The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That
On Sat, 2006-12-30 at 02:04 +0100, Mikulas Patocka wrote:
On Fri, 29 Dec 2006, Trond Myklebust wrote:
On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
Why don't you rip off the support for colliding inode number from the
kernel at all (i.e. remove iget5_locked)?
It's
2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the
libata driver.
Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
BAR 0 to BAR 3 of a compatibility mode controller
You then request_region 0x1f0 and 0x170 (BAR 0 and BAR 2) directly. You
never
Linus,
On Tuesday 02 January 2007 22:13, Linus Torvalds wrote:
[snip]
What are the exact crash details? That might narrow things down enough
that maybe you could try just one or two files that are suspect.
I'll do a digest of the problem for you and anybody else that's lost track of
the
On Tue, Jan 02, 2007 at 05:06:14PM -0500, D. Hazelton wrote:
On Tuesday 02 January 2007 16:56, Alistair John Strachan wrote:
On Tuesday 02 January 2007 21:10, Adrian Bunk wrote:
[snip]
Comparing your report and [1], it seems that if these are the same
problem, it's not a hardware
From: Daniel Jacobowitz [EMAIL PROTECTED]
Do not implement CLONE_PARENT_SETTID until we know that clone will succeed.
If we do it too early NPTL's data structures temporarily reference a
non-existant TID.
Signed-off-by: Daniel Jacobowitz [EMAIL PROTECTED]
---
On Tue, Sep 26, 2006 at 08:59:15PM
Shrink the held_lock struct by using bitfields.
This shrinks task_struct on lockdep enabled kernels by 480 bytes.
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index ea097dd..ba81cce 100644
--- a/include/linux/lockdep.h
+++
On Tue, Jan 02, 2007 at 06:35:58PM -0500, Dave Jones wrote:
Sent the wrong diff. Here's the fixed version...
Shrink the held_lock struct by using bitfields.
This shrinks task_struct on lockdep enabled kernels by 480 bytes.
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git
Subject: [patch] profiling: fix sched profiling typo
From: Ingo Molnar [EMAIL PROTECTED]
fix sched profiling typo, introduced by the sleep profiling patch. This
bug caused profile=sched to not work.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
kernel/profile.c |2 +-
1 file changed, 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
* Paul Slootman [EMAIL PROTECTED] writes:
Steve Youngs [EMAIL PROTECTED] wrote:
The last kernel from Linus' tree[1] that boots for me is v2.6.19. And
before I take my first stab at
On Tuesday 02 January 2007 18:24, you wrote:
On Tue, Jan 02, 2007 at 05:06:14PM -0500, D. Hazelton wrote:
On Tuesday 02 January 2007 16:56, Alistair John Strachan wrote:
On Tuesday 02 January 2007 21:10, Adrian Bunk wrote:
[snip]
Comparing your report and [1], it seems that if
Alan wrote:
2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the
libata driver.
Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
BAR 0 to BAR 3 of a compatibility mode controller
(a) I'm well of aware of this, and (b) that changes nothing.
I
On Tue, Jan 02, 2007 at 03:12:34PM -0800, Bill Huey wrote:
On Tue, Jan 02, 2007 at 02:51:05PM -0800, Chen, Tim C wrote:
Bill,
I'm having some problem getting this patch to run stablely. I'm
encoutering errors like that in the trace that follow:
It might the case that the lock isn't
Or maybe this rephrase helps:
Regardless of how the IDE quirks have configured the PCI BARs, libata is
written to assume that /all/ struct pci_dev resources for a single PCI
device are reserved to the libata driver.
Thus, if you avoid calling pci_request_regions (as your patch does), you
Hello Segher,
The comment used to be inside the if block, is this
change correct?
You'd prefer an empty line in there?
[And, do we want all these changes anyway? I don't care
either way, both sides have their pros and their cons --
just asking :-) ]
You know my opinion already :-)
--
Across different boots using the same 2.6.19 kernel on a quad-core xeon
I see huge variance in the migration_cost being reported during boot.
-migration_cost=39,3940
+migration_cost=25,4941
This CPU has a very large cache which could be key here...
L1 Instruction cache: 32KB, 8-way associative.
I am posting this because my kernel told me so...
The attached file contains dmesg's with and without pci-assign-busses.
My hardware is a Samsung Q35 Pro. Feel free to contact me
if you need any further information.
--Michael
dmesg.bz2
Description: Binary data
On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote:
The recommendet _serving_ temperature for coffe is 55 °C or below.
Nonsense! 55C (100F) is ludicrously low for coffee.
70C (125F) is the *minimum* recommended serving temperature. 165-190F is the
preferred serving range. I can cite
from: Brian Pomerantz [EMAIL PROTECTED]
Description:
The fatal vs. non-fatal mask for the sysbus FERR status is
incorrect
according to the E7520 datasheet. This patch corrects the mask to
correctly
handle fatal and non-fatal errors.
Signed-off-by: Brian Pomerantz [EMAIL PROTECTED]
from: Frithiof Jensen [EMAIL PROTECTED]
This patch is meant for Kernel version 2.6.19
This is a first, naive, attempt of providing an interface for memory
scrubbing in EDAC.
The following things are still outstanding:
- Only the K8 driver has been refactored with a HW scrub function
from: Brian Pomerantz [EMAIL PROTECTED]
Source: MontaVista Software, Inc.
MR: 17525
Type: Defect Fix
Disposition: local
Description:
The reading of the DRA registers should be a byte at a time (one
register at a time) instead of 4 bytes at a time (four registers).
Reading a dword at a
from: Frithiof Jensen [EMAIL PROTECTED]
This patch is meant for Kernel version 2.6.19
This is a first, naive, attempt of providing an interface for memory
scrubbing in EDAC.
The following things are still outstanding:
- Only the K8 driver has been refactored with a HW scrub function
The comment used to be inside the if block, is this
change correct?
You'd prefer an empty line in there?
Obviously, you should change the comment to include the
conditional, if that is what is needed.
[And, do we want all these changes anyway? I don't care
either way, both sides have their
The 32bit and 64bit PARISC Linux kernels suffers from the problem, that the
gettimeofday() call sometimes returns non-monotonic times.
This certainly needs to be fixed. I see stuff like this from ping:
64 bytes from 132.246.100.193: icmp_seq=19 ttl=255 time=0.4 ms
64 bytes from
1) Programmatically reserve /all/ resources associated with
our PCI device
2) Manually reserve resources associated with our PCI device,
but are not listed in struct pci_dev.
Which it doesn't actually do. You reserve 0x1F0-0x1F7 but forget the
other register. BTW
On Sat, 30 Dec 2006 19:10:31 +0300
Oleg Nesterov [EMAIL PROTECTED] wrote:
[PATCH 1/2] reimplement flush_workqueue() fixed one race when CPU goes down
while flush_cpu_workqueue() plays with it. But there is another problem, CPU
can die before flush_workqueue() has a chance to call
Thus, if you avoid calling pci_request_regions (as your patch does), you
must manually provide the same guarantees that pci_request_regions
provides to its callers.
pci_request_regions reserves only BAR4/BAR5 in legacy mode because of the
fact the resources are mashed and eventually cleaare
Older versions of the iBase FWA7304 BIOS have a bug that causes the
system to use way too much power when you run 'init 0', causing
the power brick to burn out after about 3 hours.
The fix for this is to get an updated BIOS from the manufacturer:
IB798F-T2-CP1A-1229
The problem still happens if
On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote:
The recommendet _serving_ temperature for coffe is 55 °C or below.
Nonsense! 55C (100F) is ludicrously low for coffee.
70C (125F) is the *minimum* recommended serving temperature.
165-190F is the
preferred serving range. I
On Dec 29, 2006, at 6:31 PM, Chen, Kenneth W wrote:
The AIO wake-up notification from aio_complete is really inefficient
in current AIO implementation in the presence of process waiting in
io_getevents().
Yeah, it's a real deficiency. Thanks for taking a stab at it.
This patch adds a wait
Dave Jones [EMAIL PROTECTED] wrote:
Shrink the held_lock struct by using bitfields.
This shrinks task_struct on lockdep enabled kernels by 480 bytes.
* The following field is used to detect when we cross into an
* interrupt context:
*/
- int irq_context;
Adrian Bunk wrote:
Documentation/feature-removal-schedule.txt |8 ---
drivers/ieee1394/Kconfig |7 --
drivers/ieee1394/ieee1394_core.c | 22 -
3 files changed, 37 deletions(-)
---
Alan wrote:
Once combined mode is fixed not to abuse resources (and it originally
did it that way for a good reason I grant and am not criticising that) the
entire management for legacy mode, mixed mode and native mode resources
for an ATA device (including 0x170, 0x3F6 and other wacky magic)
Given the previous patch aio: add per task aio wait event condition
that we properly wake up event waiting process knowing that we have
enough events to reap, it's just plain waste of time to insert itself
into a wait queue, and then immediately remove itself from the wait
queue for *every* event
On Wed, Jan 03, 2007 at 01:47:36AM +0100, Bodo Eggert wrote:
Dave Jones [EMAIL PROTECTED] wrote:
Shrink the held_lock struct by using bitfields.
This shrinks task_struct on lockdep enabled kernels by 480 bytes.
* The following field is used to detect when we cross into an
*
This makes the modulo of ring-head into local variable head
unnecessary.
This patch removes that bogus code.
Looks fine to me:
Acked-by: Zach Brown [EMAIL PROTECTED]
- z
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
--- ./include/linux/aio.h.orig 2006-12-24 22:31:55.0 -0800
+++ ./include/linux/aio.h 2006-12-24 22:41:28.0 -0800
@@ -165,7 +165,7 @@ struct aio_ring_info {
struct page **ring_pages;
spinlock_t ring_lock;
- long
Zach Brown wrote on Tuesday, January 02, 2007 4:49 PM
On Dec 29, 2006, at 6:31 PM, Chen, Kenneth W wrote:
This patch adds a wait condition to the wait queue and only wake-up
process when that condition meets. And this condition is added on a
per task base for handling multi-threaded app
Zach Brown wrote on Tuesday, January 02, 2007 5:14 PM
To: Chen, Kenneth W
--- ./include/linux/aio.h.orig 2006-12-24 22:31:55.0 -0800
+++ ./include/linux/aio.h 2006-12-24 22:41:28.0 -0800
@@ -165,7 +165,7 @@ struct aio_ring_info {
struct page
That is not possible because when multiple tasks waiting for
events, they
enter the wait queue in FIFO order, prepare_to_wait_exclusive() does
__add_wait_queue_tail(). So first io_getevents() with min_nr of 2
will
be woken up when 2 ops completes.
So switch the order of the two sleepers
I had that changes earlier, but dropped it to make the patch smaller.
Still have it kicking around?
Making this stuff more consistent would be nice, I agree, I'm just
not sure it's worth the risk of running into some subtle bugs.
- z
-
To unsubscribe from this list: send the line
From: James Bottomley [EMAIL PROTECTED]
Date: Tue, 02 Jan 2007 16:53:23 -0600
OK, so lets get down to brass tacks and look at the API characteristics.
Some of the issues are:
1. Should kmap() actually flush all the user spaces?
2. Do we need additional hints in to kmap/kunmap?
From: [EMAIL PROTECTED]
Date: Tue, 02 Jan 2007 15:02:47 -0800
The patch titled
net: ifb error path loop fix
has been added to the -mm tree. Its filename is
net-ifb-error-path-loop-fix.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what
On Sun, 2006-12-31 at 16:19 -0500, Halevy, Benny wrote:
Trond Myklebust wrote:
On Thu, 2006-12-28 at 17:12 +0200, Benny Halevy wrote:
As an example, some file systems encode hint information into the
filehandle
and the hints may change over time, another example is encoding
On Sun, 2006-12-31 at 16:25 -0500, Halevy, Benny wrote:
Trond Myklebust wrote:
On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
Mikulas Patocka wrote:
BTW. how does (or how should?) NFS client deal with cache coherency if
filehandles for the same file differ?
201 - 300 of 772 matches
Mail list logo
