On Thu, 16 Aug 2007, Paul Mackerras wrote:
> In the kernel we use atomic variables in precisely those situations
> where a variable is potentially accessed concurrently by multiple
> CPUs, and where each CPU needs to see updates done by other CPUs in a
> timely fashion. That is what they are
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> > > > What you probably mean is that the compiler has to assume any code
> > > > it cannot currently see can do anything (insofar as allowed by the
> > > > relevant standards etc.)
> >
> > I think this was just terminology confusion here again.
On Thu, Aug 16, 2007 at 08:12:48AM +0800, Herbert Xu wrote:
> On Wed, Aug 15, 2007 at 04:53:35PM -0700, Paul E. McKenney wrote:
> >
> > > > Communicating between process context and interrupt/NMI handlers using
> > > > per-CPU variables.
> > >
> > > Remeber we're talking about
On Wed, Aug 15, 2007 at 04:53:35PM -0700, Paul E. McKenney wrote:
>
> > > Communicating between process context and interrupt/NMI handlers using
> > > per-CPU variables.
> >
> > Remeber we're talking about atomic_read/atomic_set. Please
> > cite the actual file/function name you have in mind.
>
David P. Reed wrote:
>
> The idea in the comment at the top seems to suggest that the author
> thought that the UIP flag indicates an update is in progress at that
> very instant, so one needs to synchronize with the "falling edge" of
> that flag to ensure that one can read the RTC state without
>
> Anyone have any ideas?
you don't appear to have ACPI enabled... how does 2.6.22 or 2.6.23-rc
fare?
-
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
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c
index 3330917..0ed02b7 100644
--- a/drivers/infiniband/hw/mlx4/mad.c
+++ b/drivers/infiniband/hw/mlx4/mad.c
@@ -109,7 +109,7 @@ int mlx4_MAD_IFC(struct mlx4_ib_dev *dev,
On Thu, Aug 16, 2007 at 07:41:46AM +0800, Herbert Xu wrote:
> On Wed, Aug 15, 2007 at 11:45:20AM -0700, Paul E. McKenney wrote:
> > On Wed, Aug 15, 2007 at 07:19:57PM +0100, David Howells wrote:
> > > Herbert Xu <[EMAIL PROTECTED]> wrote:
> > >
> > > > Let's turn this around. Can you give a
On Thu, Aug 16, 2007 at 07:40:21AM +0800, Herbert Xu wrote:
> On Wed, Aug 15, 2007 at 12:13:12PM -0400, Chris Snook wrote:
> >
> > Part of the motivation here is to fix heisenbugs. If I knew where they
>
> By the same token we should probably disable optimisations
> altogether since that too
> So the proper way to read the RTC contents is to read the UIP flag, and
> if zero, read all the RTC registers with interrupts masked completely,
> so all reads happen in the 224 usec window. (NMI can still be a
> problem, but you can have NMI's set a flag that forces a retry).
SMM/SMI is
On Wed, Aug 15, 2007 at 01:02:23PM -0400, Chris Snook wrote:
> Herbert Xu wrote:
> >Andi Kleen <[EMAIL PROTECTED]> wrote:
> >>>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
On Wed, Aug 15, 2007 at 11:45:20AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 07:19:57PM +0100, David Howells wrote:
> > Herbert Xu <[EMAIL PROTECTED]> wrote:
> >
> > > Let's turn this around. Can you give a single example where
> > > the volatile semantics is needed in a
On Wed, Aug 15, 2007 at 01:36:54PM +0800, gshan wrote:
> 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
I would recommend that you use
# sysctl -w
On Wed, Aug 15, 2007 at 12:13:12PM -0400, Chris Snook wrote:
>
> Part of the motivation here is to fix heisenbugs. If I knew where they
By the same token we should probably disable optimisations
altogether since that too can create heisenbugs.
Cheers,
--
Visit Openswan at
On Wednesday, August 15, 2007 8:02 AM, James Bottomley wrote:
> Actually, we just got a second potential consumer ... although I'll
> reprod to have the reporter send it to the list. It's a device that
> needs notice of report luns data changing. The proposed
> mechanism looks
> a bit narrow
>From: Adrian Bunk [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, July 25, 2007 10:26 PM
>To: Andrew Morton; Nelson, Shannon
>Cc: linux-kernel@vger.kernel.org
>Subject: [-mm patch] DMA engine kconfig improvements
>
>On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
>>...
>> Changes
Chris Friesen wrote:
Hi all,
I've got a system that has two hyperthread-capable Xeons. If I boot it
with 2.6.10 it shows up as 4 cpus, but with 2.6.14 it only shows 2 cpus.
The relevent boot logs are:
2.6.10:
DMI 2.3 present.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor
In trying to track down a bug related to hwclock hanging my x86_64
machine, I found myself reading include/asm-generic/rtc.h carefully with
a chipset spec for several RTC chips (in particular, the granddaddy, the
MC146818A) in my hand.
I found that the code in get_rtc_time() is very, very
The latest maintenance release GIT 1.5.2.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.2.5.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.2.5.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.2.5.tar.{gz,bz2}
Satyam Sharma writes:
> > Doesn't "atomic WRT all processors" require volatility?
>
> No, it definitely doesn't. Why should it?
>
> "Atomic w.r.t. all processors" is just your normal, simple "atomicity"
> for SMP systems (ensure that that object is modified / set / replaced
> in main memory
Andrew Morton wrote:
> On Mon, 13 Aug 2007 15:30:19 +0800
> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
>
>> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
>> Interface) runtime services support to x86_64 architecture.
>
> OK, we have a major trainwreck when these patches meet
On Wed, Aug 15, 2007 at 09:37:45PM +0200, Krzysztof Halasa wrote:
> > I'm not suggesting something like [EMAIL PROTECTED] with something
> > like majordomo allowing to add yourself to those,
>
> Why not
You'd need to implement serious anti-spam measures for that. Besides,
cross-postings between
Hi all,
I've got a system that has two hyperthread-capable Xeons. If I boot it
with 2.6.10 it shows up as 4 cpus, but with 2.6.14 it only shows 2 cpus.
The relevent boot logs are:
2.6.10:
DMI 2.3 present.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
On Mon, 13 Aug 2007 15:30:19 +0800
"Huang, Ying" <[EMAIL PROTECTED]> wrote:
> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
> Interface) runtime services support to x86_64 architecture.
OK, we have a major trainwreck when these patches meet Peter's
get-newsetup.patch.
I'm
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri, 10 Aug 2007 16:56:17 -0400
> All this is currently checked into the 'eflags' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
>
> But when everybody is happy with it, IMO we should get it into
> net-2.6.24.git, as
On Wed, 2007-08-15 at 15:46 -0700, john stultz wrote:
> Andrew requested this fixup awhile back, and I just now got to it
> (apologies for being slow).
>
> To avoid lock contention, we distribute the sched_timer calls across the
> cpus so they do not trigger at the same instant. However, I used
>
--- [EMAIL PROTECTED] wrote:
> On Wed, 15 Aug 2007 13:50:17 PDT, Marc Perkel said:
> > I don't see it as being any worse that what we
> have
> > now. To open a file you have to start at the
> bottom
> > and open each directory and evaluate the
> permissions
> > on the way to the file. In my
Andrew requested this fixup awhile back, and I just now got to it
(apologies for being slow).
To avoid lock contention, we distribute the sched_timer calls across the
cpus so they do not trigger at the same instant. However, I used
NR_CPUS, which can cause needless grouping on small smp systems
--- [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d4325c7..78e5b0c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1662,6 +1662,9 @@ M: [EMAIL PROTECTED]
> L:
I apologize for sending a separate cover letter for a single patch.
Andi Kleen wrote:
On Wed, Aug 15, 2007 at 05:02:47PM -0400, Chuck Lever wrote:
The return type of __scanbit() doesn't match the return type of
find_{first,next}_bit(). Thus when you construct something like
this:
boolean
On Wed, Aug 15, 2007 at 11:05:35PM +0200, Segher Boessenkool wrote:
> >>No; compilation units have nothing to do with it, GCC can optimise
> >>across compilation unit boundaries just fine, if you tell it to
> >>compile more than one compilation unit at once.
> >
> >Last I checked, the Linux kernel
--- [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c26b346..c2ef686 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1705,6 +1705,7 @@ M: [EMAIL PROTECTED]
> L:
On Mon, 13 Aug 2007 15:30:19 +0800
"Huang, Ying" <[EMAIL PROTECTED]> wrote:
> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
> Interface) runtime services support to x86_64 architecture.
I had to rework these a bit due to clashes with
x86_64-add-acpi-reboot-option.patch.
On Wed, Aug 15, 2007 at 10:52:53PM +0200, Segher Boessenkool wrote:
> >>I think this was just terminology confusion here again. Isn't "any
> >>code
> >>that it cannot currently see" the same as "another compilation unit",
> >>and wouldn't the "compilation unit" itself expand if we ask gcc to
>
On Wed, Aug 15, 2007 at 02:31:40PM -0700, David Wilder wrote:
> Placing a kprobe on "bc" instruction (s390/s390x) can cause an oops.
> The instruction length is encoded into the first two bits of the s390
> instruction. Kprobe is incorrectly computing the instruction length.
> The instruction
--- [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 569f89f..08e62f1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1723,6 +1723,7 @@ M: [EMAIL PROTECTED]
> L:
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> Al Viro added to the CC, since he's one of the
> experts on this stuff
> and will probably whack me with a LART for
> explaining it all wrong,
> or something. :-D
>
Thanks - I appreciate that.
Just to catch everyone up on what this thread is
--- [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 78e5b0c..678cca3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1674,6 +1674,7 @@ M: [EMAIL PROTECTED]
> L:
--- [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f1dfcd2..c26b346 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1697,6 +1697,7 @@ M: [EMAIL PROTECTED]
> L:
--- [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 678cca3..f1dfcd2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1689,6 +1689,7 @@ M: [EMAIL PROTECTED]
> L:
--- [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c2ef686..569f89f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1715,6 +1715,7 @@ M: [EMAIL PROTECTED]
> L:
--- [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 08e62f1..84f6f6b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1731,6 +1731,7 @@ M: [EMAIL PROTECTED]
> L:
On 08/15/2007 06:08 PM, Jeff Garzik wrote:
> While upgrading nfs-utils on my NFSv4 file server (F7 x86-64
> 2.6.23-rc3), I got an oops on the NFSv4 client (FC6 x86-64 2.6.23-rc3),
> and communications stopped.
>
> I rebooted the client, and everything was fine again. Then, on the
> server, I
* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
> On 08/03, Chris Wright wrote:
> >
> > +long do_restart_poll(struct restart_block *restart_block)
> > +{
> > + struct pollfd __user *ufds = (struct pollfd __user*)restart_block->arg0;
> > + int nfds = restart_block->arg1;
> > + s64 timeout =
On Wed, Aug 15, 2007 at 05:02:47PM -0400, Chuck Lever wrote:
> The return type of __scanbit() doesn't match the return type of
> find_{first,next}_bit(). Thus when you construct something like
> this:
>
>boolean ? __scanbit() : find_first_bit()
Why would you want to write this? What is
Jeremy Fitzhardinge escreveu:
Glauber de Oliveira Costa wrote:
Thanks for the explanation, Andi. I understand it much better now, and
agree with you.
As alternatives what we have now, we can either keep the paravirt_ops
as it is now for the native case, just hooking the vsmp functions in
place
Kyle Moffett wrote:
I am well aware of that, I'm simply saying that sucks. Doing a
recursive chmod or setfacl on a large directory tree is slow as all hell.
Doing it in the kernel won't make it any faster.
Right... I'm talking about getting rid of it entirely.
You can't safely preserve
On Wed, 15 Aug 2007, [EMAIL PROTECTED] wrote:
> --
> Subject: fix NULL pointer dereference in __vm_enough_memory()
> From: Alan Cox <[EMAIL PROTECTED]>
>
> The new exec code inserts an accounted vma into an mm struct which is not
> current->mm.
While upgrading nfs-utils on my NFSv4 file server (F7 x86-64
2.6.23-rc3), I got an oops on the NFSv4 client (FC6 x86-64 2.6.23-rc3),
and communications stopped.
I rebooted the client, and everything was fine again. Then, on the
server, I removed an extra nfs-utils package left over from FC6,
On Wednesday 15 August 2007 08:03:24 am Thomas Renninger wrote:
> This is not a real feature, more a fix.
> Without, PNP IO ports might not get considered. This mainly affects ACPI
> system board devices with HID PNP0C02 (at least I saw this on my and
> some other machines, but it may affect
Glauber de Oliveira Costa wrote:
> Thanks for the explanation, Andi. I understand it much better now, and
> agree with you.
>
> As alternatives what we have now, we can either keep the paravirt_ops
> as it is now for the native case, just hooking the vsmp functions in
> place of the normal one,
> between __cacheline_aligned_in_smp and other compile time bits based on
> VSMP specific INTERNODE_CACHE, etc. I think compile time the way to go.
Yes you're right they'll need an additional build option for that.
It would be too wasteful to have the big cache line for all paravirt kernels.
But
Hi,
today I got the "status write for unknown orb" during early boot
sequence. This corrupted somehow my root filesystem which is
completely located at the external disk.
Aug 15 23:06:02 Mini kernel: firewire_sbp2: logged in to sbp2 unit
fw1.0 (0 retries)
Aug 15 23:06:02 Mini kernel:
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 15 Aug 2007 16:33:35 +0800
> [NET]: Fix unbalanced rcu_read_unlock in __sock_create
>
> The recent RCU work created an unbalanced rcu_read_unlock
> in __sock_create. This patch fixes that. Reported by
> oleg 123.
>
> Signed-off-by: Herbert Xu
The BLKGETSIZE ioctl expects a pointer to a long, os_file_size was providing
an int. Therefore, ubd access to host block devices caused a segmentation
fault on 64 bits systems.
Signed-off-by: Nicolas George <[EMAIL PROTECTED]>
---
Jeff Dike wrote:
> Looks sane, can I have a properly
Placing a kprobe on "bc" instruction (s390/s390x) can cause an oops.
The instruction length is encoded into the first two bits of the s390
instruction. Kprobe is incorrectly computing the instruction length.
The instruction length is used for determining what type of "fix-up" is
needed for
On Wed, 15 Aug 2007 13:50:17 PDT, Marc Perkel said:
> I don't see it as being any worse that what we have
> now. To open a file you have to start at the bottom
> and open each directory and evaluate the permissions
> on the way to the file. In my system you have to look
> up the permission of the
Al Viro added to the CC, since he's one of the experts on this stuff
and will probably whack me with a LART for explaining it all wrong,
or something. :-D
On Aug 15, 2007, at 16:38:36, Phillip Susi wrote:
Kyle Moffett wrote:
We've *always* had to do this; that's what "chmod -R" or "setfacl
Please check the definition of "cache coherence".
Which of the twelve thousand such definitions? :-)
Summary: the CPU is indeed within its rights to execute loads and
stores
to a single variable out of order, -but- only if it gets the same
result
that it would have obtained by executing
Possibly these were too trivial to expose any potential problems that
you
may have been referring to, so would be helpful if you could write a
more
concrete example / sample code.
The trick is to have a sufficiently complicated expression to force
the compiler to run out of registers.
You
The return type of __scanbit() doesn't match the return type of
find_{first,next}_bit(). Thus when you construct something like
this:
boolean ? __scanbit() : find_first_bit()
you get an unsigned long result if "boolean" is true, and a signed
long result if "boolean" is false.
In file
In include/asm-x86_64/bitops.h, the find_{first,next,first_zero,next_zero}_bit
macros return a result type that depends on the width of the "size" argument.
The type of both arms of a conditional expression should always be the same.
I changed the return type of __scanbit() to match the return
No; compilation units have nothing to do with it, GCC can optimise
across compilation unit boundaries just fine, if you tell it to
compile more than one compilation unit at once.
Last I checked, the Linux kernel build system did compile each .c file
as a separate compilation unit.
I have some
Diff to last post:
- no __*__ functions used.
- no white space fixes.
I converted i386+x86-64 arch. 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
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 Wed, 15 Aug 2007, Chuck Ebbert wrote:
> But your patch is enabling randomization for x86_64, because CONFIG_X86
> includes both 32 and 64 bit archs.
Hi Chuck,
yes, and this is addressed by the second patch I have sent yesterday,
which enables flexmmap for x86_64.
--
Jiri Kosina
SUSE Labs
On Wed, Aug 15, 2007 at 01:44:50PM -0700, Marc Perkel wrote:
> Yes - that's a good example. Git is far more powerful
> and a different paradigm for CVS. Someone had to think
> outside the box and come up with a new way of looking
> at things. I'm trying to do something like that with
> this idea.
Of course, if we find there are more callers in the kernel who want
the
volatility behaviour than those who don't care, we can re-define the
existing ops to such variants, and re-name the existing definitions
to
somethine else, say "atomic_read_nonvolatile" for all I care.
Do we really need
On 8/15/07, Chris Wright <[EMAIL PROTECTED]> wrote:
> * Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> > Only caveat, is that it has to be done before smp gets in the game, and
> > with interrupts disabled. (which makes the function in vsmp.c not eligible).
> >
> > My current option is to
I think this was just terminology confusion here again. Isn't "any
code
that it cannot currently see" the same as "another compilation unit",
and wouldn't the "compilation unit" itself expand if we ask gcc to
compile more than one unit at once? Or is there some more specific
"definition" for
What volatile does are a) never optimise away a read (or write)
to the object, since the data can change in ways the compiler
cannot see; and b) never move stores to the object across a
sequence point. This does not mean other accesses cannot be
reordered wrt the volatile access.
If the
NFS unregisters sysctls only if V4 support is compiled in. However, sysctl
table is not V4 specific, so unregister it always.
Steps to reproduce:
[build nfs.ko with CONFIG_NFS_V4=n]
modrobe nfs
rmmod nfs
ls /proc/sys
Unable to handle kernel paging request at
--- Phillip Susi <[EMAIL PROTECTED]> wrote:
> Marc Perkel wrote:
> >
> > Kyle - you are still missing the point. chmod goes
> > away. File permissions goes away. Directories as
> you
> > know them goes away.
>
> You are missing the point Marc... open()ing a file
> will have to perform
> a
On Wed, 2007-08-15 at 13:36 -0700, Christoph Lameter wrote:
> On Wed, 15 Aug 2007, Lee Schermerhorn wrote:
>
> > > So its always true for node 0. The "bit" is set.
> >
> > The issue is with the N_*_MEMORY masks. They don't get initialized
> > properly because node_set_state() is a no-op if
What you probably mean is that the compiler has to assume any code
it cannot currently see can do anything (insofar as allowed by the
relevant standards etc.)
I think this was just terminology confusion here again. Isn't "any code
that it cannot currently see" the same as "another compilation
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 15, 2007, at 15:26:07, Lennart Sorensen
> wrote:
> > On Wed, Aug 15, 2007 at 10:59:12AM -0700, Marc
> Perkel wrote:
> >> When one thinks outside the box one has to think
> about evolving
> >> beyond what you are used to. When I moved
> >>
Marc Perkel wrote:
Kyle - you are still missing the point. chmod goes
away. File permissions goes away. Directories as you
know them goes away.
You are missing the point Marc... open()ing a file will have to perform
a number of these pattern matches to decide if it is allowed or not...
On Wed, 15 Aug 2007, Lee Schermerhorn wrote:
> Thanks for testing. If Christoph agrees, I'll repost to -mm to request
> merging.
Please do. Looks right from what I can tell so far.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Wed, Aug 15, 2007 at 10:13:49PM +0200, Segher Boessenkool wrote:
> >Well if there is only one memory location involved, then smp_rmb()
> >isn't
> >going to really do anything anyway, so it would be incorrect to use
> >it.
>
> rmb() orders *any* two reads; that includes
On Wed, 15 Aug 2007, Serge E. Hallyn wrote:
> > Index: Linux/mm/page_alloc.c
> > ===
> > --- Linux.orig/mm/page_alloc.c 2007-08-15 10:01:23.0 -0400
> > +++ Linux/mm/page_alloc.c 2007-08-15 10:05:41.0 -0400
> >
Kyle Moffett wrote:
We've *always* had to do this; that's what "chmod -R" or "setfacl -R"
are for :-D. The major problem is that the locking and lookup overhead
gets really significant if you have to look at the entire directory tree
in order to determine the permissions for one single
On Wed, 15 Aug 2007, Lee Schermerhorn wrote:
> > So its always true for node 0. The "bit" is set.
>
> The issue is with the N_*_MEMORY masks. They don't get initialized
> properly because node_set_state() is a no-op if !NUMA. So, where we
> look for intersections with or where we AND with the
How does the compiler know that msleep() has got barrier()s?
Because msleep_interruptible() is in a separate compilation unit,
the compiler has to assume that it might modify any arbitrary global.
No; compilation units have nothing to do with it, GCC can optimise
across compilation unit
--- Craig Ruff <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 15, 2007 at 10:30:19AM -0700, Marc
> Perkel wrote:
> > --- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> > > Except they do, and without directories the
> > > performance of your average filesystem is going
> to suck.
> >
> > Actually you
On Wed, 15 Aug 2007, Peter Zijlstra wrote:
> The thing I strongly objected to was the 20%.
Well then set it to 10%. We have min_free_kbytes now and so we are used
to these limits.
> Also his approach misses the threshold - the extra condition needed to
> break out of the various network
On Wed, 15 Aug 2007, Peter Zijlstra wrote:
> Christoph's suggestion to set min_free_kbytes to 20% is ridiculous - nor
> does it solve all deadlocks :-(
Only if min_free_kbytes is really the mininum number of free pages and not
the mininum number of clean pages as I suggested.
All deadlocks?
On Wed, 15 Aug 2007, Lucio Correia wrote:
> It worked fine, both for normal kernel and for dump kernel on Cell. Is
> this patch intended to go mainline?
Yes it is now in my to-linus archive on git.kernel.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Thu, Aug 16, 2007 at 01:24:42AM +0530, Satyam Sharma wrote:
> [ The Cc: list scares me. Should probably trim it. ]
Trim away! ;-)
> On Wed, 15 Aug 2007, Paul E. McKenney wrote:
>
> > On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
> > > >>How does the compiler know that
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 15, 2007, at 14:05:23, Marc Perkel wrote:
> > In this new system setfacl, chmod, chown, and
> chgrp all go away
> > except inside of an emulation layer. File and
> directories no longer
> > have permissions. People have permission to
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use
it.
rmb() orders *any* two reads; that includes two reads from the same
location.
If the two reads are to the same location, all CPUs I am aware of
will
On Wed, Aug 15, 2007 at 11:30:05PM +1000, Nick Piggin wrote:
> Paul E. McKenney wrote:
> >On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
>
> >>Maybe it is the safe way to go, but it does obscure cases where there
> >>is a real need for barriers.
> >
> >
> >I prefer burying barriers
On Aug 15, 2007, at 15:26:07, Lennart Sorensen wrote:
On Wed, Aug 15, 2007 at 10:59:12AM -0700, Marc Perkel wrote:
When one thinks outside the box one has to think about evolving
beyond what you are used to. When I moved
beyond DOS I have to give up the idea of 8.3 file names. The idea
here
On 8/15/07, Marc Perkel <[EMAIL PROTECTED]> wrote:
> 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
On Wed, 15 Aug 2007, Andi Kleen wrote:
> BTW I suspect this is true for some other GFP_DMA usages too.
> Some driver writers seem to confuse it with the PCI DMA
> APIs or believe it is always needed for them.
See especially ARM.
-
To unsubscribe from this list: send the line "unsubscribe
On Wed, Aug 15, 2007 at 09:46:55PM +0200, Segher Boessenkool wrote:
> >>>Well if there is only one memory location involved, then smp_rmb()
> >>>isn't
> >>>going to really do anything anyway, so it would be incorrect to use
> >>>it.
> >>
> >>rmb() orders *any* two reads; that includes two reads
On Wed, 15 Aug 2007, Stefan Richter wrote:
> LDD3 says on page 125: "The following operations are defined for the
> type [atomic_t] and are guaranteed to be atomic with respect to all
> processors of an SMP computer."
>
> Doesn't "atomic WRT all processors" require volatility?
Atomic
(trimmed Cc)
Satyam Sharma wrote:
> [PATCH] ieee1394: Fix kthread stopping in nodemgr_host_thread
>
> The nodemgr host thread can exit on its own even when kthread_should_stop
> is not true, on receiving a signal (might never happen in practice, as
> it ignores signals). But considering
On Tue, 2007-08-14 at 19:11 -0700, Christoph Lameter wrote:
> Can you try this patch?
Thanks, Christoph
It worked fine, both for normal kernel and for dump kernel on Cell. Is
this patch intended to go mainline?
>
> From 74863f472810cb58dc56dde050616581d38f7673 Mon Sep 17 00:00:00 2001
> From:
On Wed, 15 Aug 2007 15:38:23 -0400 Jiri Slaby <[EMAIL PROTECTED]>
wrote:
>Ok. I was just curious, why did you CC drm people for char drivers
>changes.
>
>BTW. is there anybody on janitors list, who collects all those
>patches and
>forwards them upstream?
>
The "MAINTAINERS" list claims that
Hi Jesper,
On 8/9/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> EHLO,
>
> If, in em28xx_usb_probe() the memory allocation
> dev->alt_max_pkt_size = kmalloc(32*
> dev->num_alt,GFP_KERNEL);
> fails, then we'll bail out and return -ENOMEM.
> The
101 - 200 of 984 matches
Mail list logo
