forgot to reply to all.
On 8/15/07, Sonic Zhang <[EMAIL PROTECTED]> wrote:
> On 8/14/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > +/**
> > > + * Register transfer timing table
> > > + */
> >
> > Libata has a complete set of transfer mode tables and timing functions -
> > any reason for not using
On Wed, Aug 15, 2007 at 02:37:41PM +0800, Fengguang Wu wrote:
> static void *ct_seq_next(struct seq_file *s, void *v, loff_t *pos)
> {
> loff_t *spos = (loff_t *) v;
> *pos = ++(*spos);
> return spos;
> }
>
> I mean 'pos' is sometimes increased in ct_seq_next(), and sometim
Chris Snook <[EMAIL PROTECTED]> wrote:
>
> Because atomic operations are generally used for synchronization, which
> requires
> volatile behavior. Most such codepaths currently use an inefficient
> barrier().
> Some forget to and we get bugs, because people assume that atomic_read()
> actua
On Wed, Aug 15, 2007 at 05:18:45AM +0100, Al Viro wrote:
>> On Wed, Aug 15, 2007 at 11:39:45AM +0800, Fengguang Wu wrote:
>> seqfile: remove seq_file's assumption about iterators
>>
>> The seq_file implementation has some hardcoded index++/pos++ lines,
>> which assumes iterators to be *continuous*
On Tue, 2007-08-14 at 10:17 -0400, Jeff Moyer wrote:
> Ian Kent <[EMAIL PROTECTED]> writes:
> >
> > After spending quite a bit of time trying to resolve this on more than
> > one occassion, using rather complex and ulgy approaches, it turns out
> > that just delaying the hashing of the dentry until
Andreas Radke wrote:
> already tried different ports, several SATA cables on that mainboard and
> psu works well. the Samsung drive works well no matter where
> connected. never had any issues with the Raptor drive when it was
> connected to the "old" Intel P965 board before. what's the difference
On 08/15/2007 07:25 AM, Junio C Hamano wrote:
Joe Perches <[EMAIL PROTECTED]> writes:
Rene Herman had an idea about using some git
metadata that might be useful. The completely
external data approach suggested by Al Viro
might be OK too in that it wouldn't tie listeners
to git requiring mo
Hi All,
I found that O_NOFOLLOW is used for opened core file in Linux 2.6.10.
This means the core file couldn't be a symbolic link. However, I want to
use symbolic link for core file, So I plan to remove O_NOFOLLOW as
follows, but I'm not sure there are any impacts introduced by the change?
On Tue, 2007-08-14 at 12:28 -0700, Mitchell Erblich wrote:
> Group, Ingo Molnar, etc,
>
> Why does the rt sched_class contain fewer elements than fair?
> missing is the RT for .task_new.
No class specific initialization needs to be done for RT tasks.
-Mike
-
To unsubscribe from this lis
Joe Perches <[EMAIL PROTECTED]> writes:
> Yes please.
Huh?
> Rene Herman had an idea about using some git
> metadata that might be useful. The completely
> external data approach suggested by Al Viro
> might be OK too in that it wouldn't tie listeners
> to git requiring more content in git met
On Mon, 13 Aug 2007 16:17:29 -0400 Jiri Slaby <[EMAIL PROTECTED]>
wrote:
>> diff --git a/drivers/char/sx.c b/drivers/char/sx.c
>> index 85a2328..30829ed 100644
>> --- a/drivers/char/sx.c
>> +++ b/drivers/char/sx.c
>> @@ -2627,6 +2627,12 @@ static void __devinit fix_sx_pci(struct
>> pci_dev *pdev,
On Wed, Aug 15, 2007 at 11:39:45AM +0800, Fengguang Wu wrote:
> On Sun, Aug 12, 2007 at 11:08:46AM -0400, Mathieu Desnoyers wrote:
> >
> > static void *m_next(struct seq_file *m, void *p, loff_t *pos)
> > {
> > - return seq_list_next(p, &modules, pos);
> > + return seq_sorted_list_next(p, &
On Tue, 14 Aug 2007 21:23:12 -0500 (CDT) Bob Tracy wrote:
> Unfortunately, I can't say where the bug was introduced, as this is
> the first kernel I've tried on my Alpha since 2.6.22-rc7. Best guess
> is somewhere between .23-rc1 and .23-rc2, based on changes to files in
> arch/alpha/boot in that
hello,
Got this when I booted into 2.6.23-rc3: Let me know if more info is
needed.
Gerhard
sysfs_remove_bin_file: bad dentry or inode or no such file: "descriptors"
Call Trace:
[] usb_remove_sysfs_dev_files+0x89/0x9d
[] usb_unbind_device+0x15/0x19
[] __device_release_driver+0x8e/
On Sun, Aug 12, 2007 at 11:08:46AM -0400, Mathieu Desnoyers wrote:
>
> static void *m_next(struct seq_file *m, void *p, loff_t *pos)
> {
> - return seq_list_next(p, &modules, pos);
> + return seq_sorted_list_next(p, &modules, &m->private);
> }
In theory it is not safe to use something
Sorry- its in my merge queue, but I've been fighting other fires.
Will try and get this regression tested and merged into v9fs-devel
tomorrow afternoon along with a few other patches.
-eric
On 8/14/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch #if 0's the unused v9fs_fi
On Aug 14, 2007, at 19:24:30, Dave Jones wrote:
On Tue, Aug 14, 2007 at 11:22:37AM -0700, Andrew Morton wrote:
On Tue, 14 Aug 2007 11:15:41 -0700 (PDT) Linus Torvalds
<[EMAIL PROTECTED]> wrote:
In other words, it would be much better to just have per-file
markers, along with some per-subdirec
Unfortunately, I can't say where the bug was introduced, as this is
the first kernel I've tried on my Alpha since 2.6.22-rc7. Best guess
is somewhere between .23-rc1 and .23-rc2, based on changes to files in
arch/alpha/boot in that patch set. The problem happens early: aboot
starts to load vmlinu
On Tue, 2007-08-14 at 18:31 -0700, Junio C Hamano wrote:
>On the other hand, git-send-email _is_ all about sending it
>out, and it needs to know who your patch should reach. I
>think it makes sense to have one script that, given a set of
>paths that are affected, gives a list of po
Can you try this patch?
>From 74863f472810cb58dc56dde050616581d38f7673 Mon Sep 17 00:00:00 2001
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Tue, 14 Aug 2007 19:09:00 -0700
Subject: [PATCH] SLUB: Do not fail on broken memory configurations
Print a big fat warning and do what is necessary to
On Wed, 15 Aug 2007, Michael Ellerman wrote:
> > Yes SLUB will fall back but not during bootstrap. Bootstrap needs to
> > carefully place structures on the right nodes. We fail during bootstrap
> > because there is *no* memory available on it.
>
> Sure, you want to have the structures on the righ
On Tue, 2007-08-14 at 11:15 -0700, Linus Torvalds wrote:
> In other words, it would be much better to just have per-file markers,
> along with some per-subdirectory stuff or similar.
So that there would be no hot single file, I cut the
MAINTAINER file into single file segments in maintainers/*
0
On 08/14/2007 09:33 PM, Al Viro wrote:
FWIW, I suspect that we are looking at that from the wrong POV. If
that's about "who ought to be Cc'd on the issues dealing with ", why does it have to be tied to "who is maintainer for
"?
I'm not suggesting something like [EMAIL PROTECTED] with something
On Mon, 2007-08-13 at 12:19 +0200, Johannes Berg wrote:
> On Sun, 2007-08-12 at 23:25 -0700, [EMAIL PROTECTED] wrote:
> > Add file pattern to MAINTAINER entry
>
> > +F: include/linux/nl80211.h
> > +F: include/net/cfg80211.h
> > +F: net/wireless/core.*
> > +F: net/wireless/sysfs.*
> > +F: net/wirel
Linus Torvalds wrote:
On Tue, 14 Aug 2007, Joe Perches wrote:
On Tue, 2007-08-14 at 20:03 +0200, Rene Herman wrote:
"git info --maintainer drivers/ide/ide-cd.c" or some such would say "Alan
Cox <[EMAIL PROTECTED]>".
Perhaps maintainer(s), approver(s), listener(s)?
I think some
Joe Perches <[EMAIL PROTECTED]> writes:
> On Tue, 2007-08-14 at 17:53 +0200, Rene Herman wrote:
>> It isn't about MODULE_FOO() tags, it is about tagging /source/ files
>> to help with putting CCs on patch submissals.
>> If we want to link source file foo.c and the
>> MAINTAINERS information, we
On 8/15/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 14 Aug 2007, Lucio Correia wrote:
>
> > > SLAB boots because it falls back to node 0 for the control structures. So
> > > it creates useless control structures for node 1. These are then never
> > > used since any allocation attemp
Hi Linus,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
for-linus
H. Peter Anvin (3):
[x86 setup] The current display page is returned in %bh, not %bl
[x86 setup] Don't use EDD to get the MBR signature
[x86 setup] edd.c: make sure MBR
Very old 64bit binutils have .cfi_startproc/endproc, but
no .cfi_rel_offset. Check for .cfi_rel_offset too.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Index: linux/arch/x86_64/Makefile
===
--- linux.orig/arch/x86_64/Makefile
+++ li
Very old binutils (2.12.90...) seem to have trouble with newlines
in assembler macro invocation. They put them into the resulting
argument expansion. In this case this lead to a parse error because
a .rept expression ended up spread over multiple lines. Change the PMDS()
invocation to a single li
This should fix an oops with PCMCIA PATA devices
http://bugzilla.kernel.org/show_bug.cgi?id=8424
This is not a full fix for the problem, but probably
still the right thing to do.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-dma.c |4
1 file changed, 4 inse
From: Daniel Gollub <[EMAIL PROTECTED]>
Fixed wrong expression which enabled watchdogs even if nmi_watchdog kernel
parameter wasn't set. This regression got slightly introduced with commit
b7471c6da94d30d3deadc55986cc38d1ff57f9ca.
Introduced NMI_DISABLED (-1) which allows to switch the value of
More late bug fixe for 2.6.23.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Tue, 14 Aug 2007 23:22:44 +0200
> The Coverity checker spotted that we'd have already oops'ed if "vlandev"
> was NULL.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Fair enough, applied, thanks Adrian.
-
To unsubscribe from this list: send the lin
Am Dienstag, den 14.08.2007, 18:02 +0400 schrieb Manu Abraham:
> On 8/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > > F: drivers/media/*
> > >
> > >
> > > This is NOT OK !
> >
> > This IS ok. You just need to read the definition of the 'F' tag:
> >
> > F: Files and directo
On Tue, Aug 14, 2007 at 01:19:40AM -0500, Matt Mackall wrote:
> On Tue, Aug 14, 2007 at 09:33:50AM +0800, Fengguang Wu wrote:
> > The "proportional set size" (PSS) of a process is the count of pages it has
> > in
> > memory, where each page is divided by the number of processes sharing it.
> > So
On Wed, 15 Aug 2007, Satyam Sharma wrote:
> [PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Good that actually has a code impact.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jeff Garzik wrote:
Divy Le Ray wrote:
> From: Divy Le Ray <[EMAIL PROTECTED]>
>
> Set PM1 internal memory to round robin mode
>
> Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
why?
For multiport adapters, it balances access to this internal memory.
Divy
-
To unsubscribe from this list: send
Hi Linus,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
for-linus
H. Peter Anvin (2):
[x86 setup] The current display page is returned in %bh, not %bl
[x86 setup] Don't use EDD to get the MBR signature
arch/i386/boot/edd.c | 28 --
On Sun, 12 Aug 2007, [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ae24def..270952c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4696,6 +4696,8 @@ M: [EMAIL PROTEC
On Sun, 12 Aug 2007, [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bdbf999..4a8770c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2071,6 +2071,8 @@ M: [EMAIL PROTEC
On Tue, Aug 14, 2007 at 04:35:02PM -0500, Serge E. Hallyn wrote:
> Quoting Adrian Bunk ([EMAIL PROTECTED]):
> > On Thu, Aug 09, 2007 at 10:42:54PM -0700, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.23-rc1-mm2:
> > >...
> > > +file-capabilities-clear-fcaps-on-inode-change.patch
> > >
> >
Hello!
Work in progress, not for inclusion.
The attached patch passes multiple hours of rcutorture while hotplugging
CPUs every ten seconds on 64-bit PPC and x86_64. It fails miserably on
32-bit i386 after a few hotplugs, but then again, so does stock 2.6.22
even without running rcutorture simul
On Tue, 14 Aug 2007, Arjan van de Ven wrote:
>
> On Tue, 2007-08-14 at 15:59 -0700, Tim Bird wrote:
> > Hi all,
> >
> > I have a quick question.
> >
> > I'm trying to resurrect a patch from the Linux-tiny patch suite,
> > to do accounting of kmalloc memory allocations. In testing it
> > with
On Tue, Aug 14, 2007 at 03:56:51PM -0700, Christoph Lameter wrote:
> On Tue, 14 Aug 2007, Chris Snook wrote:
>
> > > volatile means that there is some vague notion of "read it now". But that
> > > really does not exist. Instead we control visibility via barriers
> > > (smp_wmb,
> > > smp_rmb). Wo
Jeff Garzik wrote:
Divy Le Ray wrote:
From: Divy Le Ray <[EMAIL PROTECTED]>
Let the RDMA driver get HW page info to work around HW issues.
Assign explicit enum values.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
"HW issues" -- you need to go into far more detail, when adding a new
interf
Looks good to me.
Signed-off-by: Nathan Laredo <[EMAIL PROTECTED]>
- Nathan
On 8/14/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-08-14 at 14:51 -0700, Nathan Laredo wrote:
> > Just the ones that show my name at the top of the source file.
> > cs8240.h, ibmmpeg2.h, saa7121.h, saa714
> My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
> textdata bss dec hex filename
> 3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux
> 3435308 249176 176128 3860612 3ae884 atomic_inlineasm/vmlinux
What is the difference between atomic_normal and
On Wed, Aug 15, 2007 at 04:38:54AM +0530, Satyam Sharma wrote:
>
>
> On Tue, 14 Aug 2007, Christoph Lameter wrote:
>
> > On Thu, 9 Aug 2007, Chris Snook wrote:
> >
> > > This patchset makes the behavior of atomic_read uniform by removing the
> > > volatile keyword from all atomic_t and atomic64
Christoph Lameter wrote:
On Tue, 14 Aug 2007, Chris Snook wrote:
volatile means that there is some vague notion of "read it now". But that
really does not exist. Instead we control visibility via barriers (smp_wmb,
smp_rmb). Would it not be best to not have volatile at all in atomic
operations
Jeff Garzik wrote:
Divy Le Ray wrote:
> From: Divy Le Ray <[EMAIL PROTECTED]>
>
> Send small TX_DATA work requests as immediate data even when
> there are fragments.
>
> Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
> ---
>
> drivers/net/cxgb3/sge.c | 17 +++--
> 1 files changed,
On Tue, Aug 14, 2007 at 11:22:37AM -0700, Andrew Morton wrote:
> On Tue, 14 Aug 2007 11:15:41 -0700 (PDT)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > In other words, it would be much better to just have per-file markers,
> > along with some per-subdirectory stuff or similar.
>
> And
Jeff Garzik wrote:
Divy Le Ray wrote:
> From: Divy Le Ray <[EMAIL PROTECTED]>
>
> Set max Rx coalescing length to 12288
>
> Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
> ---
>
> drivers/net/cxgb3/common.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/
On Tue, 14 Aug 2007, Jiri Kosina wrote:
> It turned out recently that PIE-compiled binaries on x86_64, that
> perform larger amount of brk-allocations (for example bash) will not
> work (but they will work on ?86). This is because currently on ?86 the
> memory layout is as follows:
(Andi added
On Tue, Aug 14, 2007 at 15:55:48 -0700, Arjan van de Ven wrote:
> NULL is not 0 though.
It is. Its representation isn't guaranteed to be all-bits-zero, but
the constant value 0 when used in pointer context is always a null
pointer (and in fact the standard requires that NULL be #defined as 0
or a
On Tue, 14 Aug 2007, Chris Snook wrote:
> Because atomic operations are generally used for synchronization, which
> requires volatile behavior. Most such codepaths currently use an inefficient
> barrier(). Some forget to and we get bugs, because people assume that
> atomic_read() actually reads
Satyam Sharma wrote:
On Tue, 14 Aug 2007, Christoph Lameter wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly casts
Tim Bird wrote:
Hi all,
I have a quick question.
I'm trying to resurrect a patch from the Linux-tiny patch suite,
to do accounting of kmalloc memory allocations. In testing it
with Linux 2.6.22, I've found a large number of kfrees of
NULL pointers.
Is this considered OK? Or should I examine
On Tue, 2007-08-14 at 15:59 -0700, Tim Bird wrote:
> Hi all,
>
> I have a quick question.
>
> I'm trying to resurrect a patch from the Linux-tiny patch suite,
> to do accounting of kmalloc memory allocations. In testing it
> with Linux 2.6.22, I've found a large number of kfrees of
> NULL point
On Tue, 14 Aug 2007, Tim Bird wrote:
> Hi all,
>
> I have a quick question.
>
> I'm trying to resurrect a patch from the Linux-tiny patch suite,
> to do accounting of kmalloc memory allocations. In testing it
> with Linux 2.6.22, I've found a large number of kfrees of
> NULL pointers.
>
> Is
On Tue, 14 Aug 2007, Chris Snook wrote:
> > volatile means that there is some vague notion of "read it now". But that
> > really does not exist. Instead we control visibility via barriers (smp_wmb,
> > smp_rmb). Would it not be best to not have volatile at all in atomic
> > operations and let the
On Tue, 2007-08-14 at 13:05 -0700, Mike Anderson wrote:
> This patch series enables device mapper (dm) to send kobject uevents for
> dm events. Currently only two new events are sent related to path state
> changes.
Sounds fine.
> DM_ACTION=PATH_FAILED
> DM_SEQNUM=1
> DM_PATH=8:48
> DM_PATHS=1
O
On Tue, 14 Aug 2007, Christoph Lameter wrote:
> On Thu, 9 Aug 2007, Chris Snook wrote:
>
> > This patchset makes the behavior of atomic_read uniform by removing the
> > volatile keyword from all atomic_t and atomic64_t definitions that currently
> > have it, and instead explicitly casts the var
As Segher pointed out, inline asm is better than the volatile casting all over
the place. From the PowerPC patch description:
Also use inline functions instead of macros; this actually
improves code generation (some code becomes a little smaller,
probably because of improved alias information --
I converted i386+x86-64. Compiled, booted and played for a while. The
description of both patches contains the file size of four kernel builds:
- "normal" is 28e8351ac22de25034e048c680014ad824323c65 as it
- "inline asm" is with this patch
- "inline volatile" is *(volatile int *)&(v)->counter as a s
As Segher pointed out, inline asm is better than the volatile casting all over
the place. From the PowerPC patch description:
Also use inline functions instead of macros; this actually
improves code generation (some code becomes a little smaller,
probably because of improved alias information --
On Tue, Aug 07, 2007 at 10:28:43PM -0700, [EMAIL PROTECTED] wrote:
> Convert from class_device to device in drivers/char/drm.
>
> Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
> Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
>
> ---
> drivers/char/drm/drmP.h |8 ++---
> drivers/char/drm
On Tue, Aug 07, 2007 at 10:28:45PM -0700, [EMAIL PROTECTED] wrote:
> Convert from class_device to device for hwmon_device_register/unregister
>
> Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
> Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
Patches 3-5 here should go through the hwmon maintainer,
Hi all,
I have a quick question.
I'm trying to resurrect a patch from the Linux-tiny patch suite,
to do accounting of kmalloc memory allocations. In testing it
with Linux 2.6.22, I've found a large number of kfrees of
NULL pointers.
Is this considered OK? Or should I examine the offenders
to s
Christoph Lameter wrote:
On Mon, 13 Aug 2007, Chris Snook wrote:
@@ -38,7 +45,7 @@
Next, we have:
- #define atomic_read(v) ((v)->counter)
+ #define atomic_read(v) (*(volatile int *)&(v)->counter)
which simply reads the current value of the counter.
volatile means that there is
On Tue, 14 Aug 2007, Marc Perkel wrote:
For example. If you list a directory you only see the
files that you have some rights to and files where you
have no rights are invisible to you. If a file is read
only to you then you can't delete it either. Having
write access to a directory really means
On Tue, 14 Aug 2007, Chris Snook wrote:
> But barriers force a flush of *everything* in scope, which we generally don't
> want. On the other hand, we pretty much always want to flush atomic_*
> operations. One way or another, we should be restricting the volatile
> behavior to the thing that nee
Karl Meyer <[EMAIL PROTECTED]> :
> I did some additional testing, the results are:
> [0e4851502f846b13b29b7f88f1250c980d57e944] r8169: merge with version
> 8.001.00 of Realtek's r8168 driver
> does not work, I after some traffic the transmit timeout occurs.
> [6dccd16b7c2703e8bbf8bca62b5cf248332afb
> Then you fix the specific case and the game continues.
If they intercept netdev->hard_start_xmit there is nothing
to fix. Or inode->i_ops or any other virtual method pointer
that is called often..
Putting i_ops into const memory doesn't help either -- they
can just copy them and use their own a
On Tue, 2007-08-14 at 14:51 -0700, Nathan Laredo wrote:
> Just the ones that show my name at the top of the source file.
> cs8240.h, ibmmpeg2.h, saa7121.h, saa7146*.h, stradis.c
STRADIS MPEG-2 DECODER DRIVER
P: Nathan Laredo
M: [EMAIL PROTECTED]
W: http://www.stradis.com/
S: Ma
Christoph Lameter wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly casts the variable as volatile in
atomic_read().
On Mon, 13 Aug 2007, Chris Snook wrote:
> @@ -38,7 +45,7 @@
>
> Next, we have:
>
> - #define atomic_read(v) ((v)->counter)
> + #define atomic_read(v) (*(volatile int *)&(v)->counter)
>
> which simply reads the current value of the counter.
volatile means that there is some vague
On Wed, Aug 15, 2007 at 12:01:54AM +0200, Arnd Bergmann wrote:
> On Tuesday 14 August 2007, Paul E. McKenney wrote:
> > > #define order(x) asm volatile("" : "+m" (x))
> >
> > There was something very similar discussed earlier in this thread,
> > with quite a bit of debate as to exactly what the "m
I want to throw out some concepts about a new way of
thinking about file systems. But the first thing you
have to do is to forget what you know about file
systems now. This is a discussion about a new view of
looking a file storage that is radically different and
it's more easily undersood if you f
On Wed, 15 Aug 2007, Andi Kleen wrote:
> > Ok I have a vague idea on how this could but its likely that the
> > changes make things worse rather than better. Additional reference to a
> > new cacheline (per cpu but still), preempt disable. Lots of code at all
> > call sites. Interrupt enable/dis
On Thu, 9 Aug 2007, Chris Snook wrote:
> This patchset makes the behavior of atomic_read uniform by removing the
> volatile keyword from all atomic_t and atomic64_t definitions that currently
> have it, and instead explicitly casts the variable as volatile in
> atomic_read(). This leaves little r
> So even with Alan's hypervisor support the whole thing would be still
> quite holey. The argument of raising the bar also doesn't seem very
Its materially harder, especially with the hypervisor.
> convincing to me, because attackers reuse code too and it's enough
> when someone publishes such
On Tue, Aug 14, 2007 at 06:04:01PM -0400, Jeff Garzik wrote:
> Adrian Bunk wrote:
>> According to git, the only one who touched this file during the last
>> 5 years was me when removing drivers...
>> modinfo offers less ancient information.
>> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>> ---
>
Christoph Lameter wrote:
On Tue, 14 Aug 2007, Luck, Tony wrote:
I re-tried the macros ... the three warnings from mm/slub.c all result in
broken code ... and quite rightly too, they all come from code that does:
atomic_read(&n->nr_slabs)
But the nr_slabs field is an atomic_long_t, so
Hi Adrian.
On Tue, Aug 14, 2007 at 11:22:48PM +0200, Adrian Bunk ([EMAIL PROTECTED]) wrote:
> The Coverity checker spotted that we'd have already oops'ed if "dev"
> was NULL.
This is wrong.
Although dev can not be null there there is no way it will crash.
The right paranoidal solution is to setup
> Ok I have a vague idea on how this could but its likely that the
> changes make things worse rather than better. Additional reference to a
> new cacheline (per cpu but still), preempt disable. Lots of code at all
> call sites. Interrupt enable/disable is quite efficient in recent
> processors.
On Wed, 15 Aug 2007, Andi Kleen wrote:
> > > The interrupt handler shouldn't touch zone_flag. If it wants
> > > to it would need to be converted to a local_t and incremented/decremented
> > > (should be about the same cost at least on architectures with sane
> > > local_t implementation)
> >
> >
Michal Piotrowski <[EMAIL PROTECTED]> :
[...]
> Networking
>
> Subject : NETDEV WATCHDOG: eth0: transmit timed out
> References : http://lkml.org/lkml/2007/8/13/737
> Last known good : ?
> Submitter : Karl Meyer <[EMAIL PROTECTED]>
> Caused-By : ?
> Handled-By : ?
On Tue, Aug 14, 2007 at 03:07:10PM -0700, Christoph Lameter wrote:
> There are more spinlocks needed. So we would just check the whole bunch
> and fail if any of them are used?
Yes zone_flag would apply to all of them.
>
> > do things with zone locks
> > }
> >
> > The interrup
On Tue, 14 Aug 2007, Andi Kleen wrote:
> > Could you be a bit more specific? Where do you want to place the data?
>
> DEFINE_PER_CPU(int, zone_flag);
>
> get_cpu(); // likely already true and then not needed
> __get_cpu(zone_flag) = 1;
> /* wmb is implied in spin_lock I th
On Tue, 14 Aug 2007, Luck, Tony wrote:
> I re-tried the macros ... the three warnings from mm/slub.c all result in
> broken code ... and quite rightly too, they all come from code that does:
>
> atomic_read(&n->nr_slabs)
>
> But the nr_slabs field is an atomic_long_t, so we shouldn't be us
Adrian Bunk wrote:
According to git, the only one who touched this file during the last
5 years was me when removing drivers...
modinfo offers less ancient information.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch has been sent on:
- 23 Jul 2007
Documentation/networking/00-
>> include/linux/skbuff.h:521: warning: passing arg 1 of `atomic_read' discards
>> qualifiers from pointer target type
>> include/net/sock.h:1244: warning: passing arg 1 of `atomic_read' discards
>> qualifiers from pointer target type
>> include/net/tcp.h:958: warning: passing arg 1 of `atomic_re
On Tue, Aug 14, 2007 at 11:22:58PM +0200, Adrian Bunk wrote:
> On Thu, Aug 09, 2007 at 01:51:06AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.23-rc2-mm1:
> >...
> > git-nfsd.patch
> >...
> > git trees
> >...
>
>
> do_probe_callback() can become static.
Oops, thanks; applied.--b.
On Tuesday 14 August 2007, Paul E. McKenney wrote:
> > #define order(x) asm volatile("" : "+m" (x))
>
> There was something very similar discussed earlier in this thread,
> with quite a bit of debate as to exactly what the "m" flag should
> look like. I suggested something similar named ACCESS_ON
> Hi, All
>
> We were looking at "[kernel]/lib/string.c"
> (http://lxr.linux.no/source/lib/string.c#L500)
>
> memcpy copies a part of memory to some other location
> but It will not work for all cases of overlapping
> blocks.(if the start of destination block falls
> between the source block)
>
>
On Tue, Aug 14, 2007 at 02:48:31PM -0700, Christoph Lameter wrote:
> On Tue, 14 Aug 2007, Andi Kleen wrote:
>
> > > But that still creates lots of overhead each time we take the lru lock!
> >
> > A lot of overhead in what way? Setting a flag in a cache hot
> > per CPU data variable shouldn't be m
> The problem is, O_NONBLOCK flag is not attached to file *descriptor*,
> but to a "file description" mentioned in fcntl manpage:
[snip]
> We don't know whether our stdout descriptor #1 is shared with
> anyone or not,
> and if we were started from shell, it typically is. That's why we try to
> res
On Tue, 14 Aug 2007, Lee Schermerhorn wrote:
> > Ok then you did not have a NUMA system configured. So its okay for the
> > dummies to ignore the stuff. CONFIG_NODES_SHIFT is a constant and does not
> > change. The first bit is always set.
>
> The first bit [node 0] is only set for the N_ONLINE
No, not all of them. Just the ones that show my name at the top of
the source file.
cs8240.h, ibmmpeg2.h, saa7121.h, saa7146*.h, stradis.c
stradis.c includes all of the above .h files, so they weren't listed separately.
Additionally, it should probably be noted that I still use a 2.2
kernel wit
1 - 100 of 439 matches
Mail list logo
