Hi Linus,
[ and others; I think there's a communication gap in a lot of this
thread, and a little summary would be useful. Hence this posting. ]
On Thu, 16 Aug 2007, Linus Torvalds wrote:
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> >
> > I'm really surprised it's as much as a few K. I
Herbert Xu writes:
> On Fri, Aug 17, 2007 at 03:09:57PM +1000, Paul Mackerras wrote:
> > Herbert Xu writes:
> >
> > > Can you find an actual atomic_read code snippet there that is
> > > broken without the volatile modifier?
> >
> > There are some in arch-specific code, for example line 1073 of
On Fri, Aug 17, 2007 at 03:09:57PM +1000, Paul Mackerras wrote:
> Herbert Xu writes:
>
> > Can you find an actual atomic_read code snippet there that is
> > broken without the volatile modifier?
>
> There are some in arch-specific code, for example line 1073 of
> arch/mips/kernel/smtc.c. On
This patch fixes a bug of change_page_attr/change_page_attr_addr on
Intel x86_64 CPU. After changing page attribute to be executable with
these functions, the page remains un-executable on Intel x86_64
CPU. Because on Intel x86_64 CPU, only if the "NX" bits of all four
level page tables are
On 8/17/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-08-17 at 06:37 +0200, Miguel Ojeda wrote:
> > On 8/16/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> > > On Thu, 2007-08-16 at 11:16 +0200, Miguel Ojeda wrote:
> > > > I think you could add also:
> > > > +F:
On Thu, Aug 16, 2007 at 08:42:23PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> >
> > I'm really surprised it's as much as a few K. I tried it on powerpc
> > and it only saved 40 bytes (10 instructions) for a G5 config.
>
> One of the things that "volatile"
Herbert Xu writes:
> Can you find an actual atomic_read code snippet there that is
> broken without the volatile modifier?
There are some in arch-specific code, for example line 1073 of
arch/mips/kernel/smtc.c. On mips, cpu_relax() is just barrier(), so
the empty loop body is ok provided that
On Fri, Aug 17, 2007 at 09:28:00AM +0800, Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 06:02:32PM -0700, Paul E. McKenney wrote:
> >
> > Yep. Or you can use atomic_dec_return() instead of using a barrier.
>
> Or you could use smp_mb__{before,after}_atomic_dec.
Yep. That would be an example of
The overall approach looks fine to me, although I'm not the arbiter of
taste for the DMA API.
However, I think this wants to be split into at least three parts for
merging: adding the dmaflush flags stuff into the DMA API; adding the
dmaflush parameter to the ib_umem_get() API (and fixing every
Herbert Xu writes:
> So the point here is that if you don't mind getting a stale
> value from the CPU cache when doing an atomic_read, then
> surely you won't mind getting a stale value from the compiler
> "cache".
No, that particular argument is bogus, because there is a cache
coherency
Add PCI IDs for the onchip UARTs on PA Semi PWRficient.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/serial/8250_pci.c
===
--- linux-2.6.orig/drivers/serial/8250_pci.c
+++
In message <[EMAIL PROTECTED]> you wrote:
> Michael Neuling wrote:
> >> I'd also request for you to add a cpu_scaled_run_real_total for use
> >> by delay accounting. cpu_scaled_run_real_total should be similar in
> >> functionality to cpu_run_real_total.
> >
> > Will do. Should I add
--- Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > I will write you a Perl script which will generate a complete
> > > and functionally equivalent SELinux policy (assuming I have enough
> > > free time) given a file with your policy language. But I can do this
> > > if and only if
On Fri, 2007-08-17 at 06:37 +0200, Miguel Ojeda wrote:
> On 8/16/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-08-16 at 11:16 +0200, Miguel Ojeda wrote:
> > > I think you could add also:
> > > +F: Documentation/auxdisplay/cfag12864bfb
> does not exist. I meant
>
On Thu, 16 Aug 2007 21:24:22 PDT, Marc Perkel said:
> And then everything that's stored as /1/2/3/4 is still
> the same but the sections resolve to different names.
At that point, you need to go re-think your full-pathname permission scheme,
because that severely broke it.
> I'm sure there are
Hi All,
Recently, I got a funny problem that my NFS client can't show some of
mounted directories. These directories that can't be showed by "ls"
command have great deals of files.
For example. I have a directory on NFS server log and there are 69
files. I can't show it's child files
Michael Neuling wrote:
>> I'd also request for you to add a cpu_scaled_run_real_total for use
>> by delay accounting. cpu_scaled_run_real_total should be similar in
>> functionality to cpu_run_real_total.
>
> Will do. Should I add cpu_scaled_run_real_total to the end of the
> struct taskstat, or
Paul Mackerras wrote:
Nick Piggin writes:
Why are people making these undocumented and just plain false
assumptions about atomic_t?
Well, it has only been false since December 2006. Prior to that
atomics *were* volatile on all platforms.
Hmm, although I don't think it has ever been
Michael Neuling wrote:
>
> SLB shadow was bust. Make sure you have
> edd0622bd2e8f755c960827e15aa6908c3c5aa94
>
> [POWERPC] Fix potential duplicate entry in SLB shadow buffer
>
> We were getting a duplicate entry in the SLB shadow buffer in
> slb_flush_and_rebolt() if the
On 8/16/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-16 at 11:16 +0200, Miguel Ojeda wrote:
> > I think you could add also:
> > +F: Documentation/auxdisplay/cfag12864bfb
>
> This is what I have now:
>
> CFAG12864BFB LCD FRAMEBUFFER DRIVER
> P: Miguel Ojeda Sandonis
> M:
On 08/16/2007 09:00 PM, Junio C Hamano wrote:
Git or no git, I think a file that can be viewed with less,
edited with regular editor and processed with sed/perl/grep
tools is the way to go. I do not think adding 600+ patches to
the single MAINTAINERS list is workable in the longer term, as
it
On 8/16/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-16 at 11:16 +0200, Miguel Ojeda wrote:
> > I think you could add also:
> > +F: Documentation/auxdisplay/cfag12864bfb
>
> This is what I have now:
>
> CFAG12864BFB LCD FRAMEBUFFER DRIVER
> P: Miguel Ojeda Sandonis
> M:
Several people have asked about how to mass move a
tree under my idea for a new kind of file system. I
have an idea. Suppose you have the file name as
follies.
/one/two/three/four/file1
Except the are a million files in /four/ named file1
to file100.
We want to move thes files to
[ Your mailer drops Cc: lists, munges headers,
does all sorts of badness. Please fix that. ]
On Thu, 16 Aug 2007, David Schwartz wrote:
>
> > There is a quite convincing argument that such an access _is_ an
> > access to a volatile object; see GCC PR21568 comment #9. This
> > probably isn't
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
> > Here, I should obviously admit that the semantics of *(volatile int *)&
> > aren't any neater or well-defined in the _language standard_ at all. The
> > standard does say (verbatim) "precisely what constitutes as access to
> > object of
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
> > Note that "volatile"
> > is a type-qualifier, not a type itself, so a cast of the _object_ itself
> > to a qualified-type i.e. (volatile int) would not make the access itself
> > volatile-qualified.
>
> There is no such thing as
Nick Piggin writes:
> Why are people making these undocumented and just plain false
> assumptions about atomic_t?
Well, it has only been false since December 2006. Prior to that
atomics *were* volatile on all platforms.
> If they're using lockless code (ie.
> which they must be if using
On Wed, 2007-08-15 at 14:31 +0800, Ian Kent wrote:
> 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
On Fri, Aug 17, 2007 at 11:44:37AM +0800, Fengguang Wu wrote:
> > I'm so-so on this.
>
> Not that way! It's a good thing that people have different experiences
> and hence viewpoints. Maybe the concept of PFN sharing are
> straightforward to you, while I have been playing with seq_file a lot.
>
On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote:
>
> The cost of doing so seems to me to be well down in the noise - 44
> bytes of extra kernel text on a ppc64 G5 config, and I don't believe
> the extra few cycles for the occasional extra load would be measurable
> (they should all
On Fri, 17 Aug 2007, Nick Piggin wrote:
>
> I'm surprised too. Numbers were from the "...use asm() like the other
> atomic operations already do" thread. According to them,
>
> textdata bss dec hex filename
> 3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux
>
On Thu, Aug 16, 2007 at 09:38:46PM -0500, Matt Mackall wrote:
> On Fri, Aug 17, 2007 at 06:05:20AM +0800, Fengguang Wu wrote:
> > Show a process's page-by-page address space infomation in /proc//pmaps.
> > It helps to analyze applications' memory footprints in a comprehensive way.
> >
> > Pages
Linus Torvalds writes:
> In general, I'd *much* rather we used barriers. Anything that "depends" on
> volatile is pretty much set up to be buggy. But I'm certainly also willing
> to have that volatile inside "atomic_read/atomic_set()" if it avoids code
> that would otherwise break - ie if it
On Fri, 17 Aug 2007, Paul Mackerras wrote:
>
> I'm really surprised it's as much as a few K. I tried it on powerpc
> and it only saved 40 bytes (10 instructions) for a G5 config.
One of the things that "volatile" generally screws up is a simple
volatile int i;
i++;
which a
Paul Mackerras wrote:
Nick Piggin writes:
So i386 and x86-64 don't have volatiles there, and it saves them a
few K of kernel text. What you need to justify is why it is a good
I'm really surprised it's as much as a few K. I tried it on powerpc
and it only saved 40 bytes (10 instructions)
Nick Piggin writes:
> So i386 and x86-64 don't have volatiles there, and it saves them a
> few K of kernel text. What you need to justify is why it is a good
I'm really surprised it's as much as a few K. I tried it on powerpc
and it only saved 40 bytes (10 instructions) for a G5 config.
Paul.
Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 06:42:50PM +0800, Herbert Xu wrote:
In fact, volatile doesn't guarantee that the memory gets
read anyway. You might be reading some stale value out
of the cache. Granted this doesn't happen on x86 but
when you're coding for the kernel you
On Fri, 17 Aug 2007, Paul Mackerras wrote:
>
> Volatile doesn't mean it can't be reordered; volatile means the
> accesses can't be eliminated.
It also does limit re-ordering.
Of course, since *normal* accesses aren't necessarily limited wrt
re-ordering, the question then becomes one of "with
On Thu, Aug 16, 2007 at 09:16:17PM -0500, Matt Mackall wrote:
> On Fri, Aug 17, 2007 at 06:05:18AM +0800, Fengguang Wu wrote:
> > Split large vmas into page groups of proc_maps_private.batch_size bytes, and
> > iterate them one by one for seqfile->show. This allows us to export large
> > scale
>
Christoph Lameter writes:
> No it does not have any volatile semantics. atomic_dec() can be reordered
> at will by the compiler within the current basic unit if you do not add a
> barrier.
Volatile doesn't mean it can't be reordered; volatile means the
accesses can't be eliminated.
Paul.
-
To
On Thu, Aug 16, 2007 at 09:13:47PM -0500, Matt Mackall wrote:
> On Fri, Aug 17, 2007 at 06:05:17AM +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.
> >
On Fri, Aug 17, 2007 at 06:05:20AM +0800, Fengguang Wu wrote:
> Show a process's page-by-page address space infomation in /proc//pmaps.
> It helps to analyze applications' memory footprints in a comprehensive way.
>
> Pages share the same states are grouped into a page range.
> For each page
> Hi,
>
> My machine reboots automatically after a few seconds of booting 2.6.23-rc2-mm
2.
> I've tried several ways to debug the problem, but I've had no success.
> I am not sure if this problem has been reported already, a few simple searche
s
> did not indicate that the problem had been
A new driver for the Broadcom BCM43xx devices has been written that uses mac80211, rather than
softmac. The newest versions of the Broadcom firmware does not support all the BCM devices.
Accordingly, a separate driver is being prepared that will use an older version of the firmware and
support
Chris Snook wrote:
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
Can you find an actual atomic_read code snippet there that is
broken without the volatile modifier?
A whole bunch of atomic_read uses will be broken without the volatile
modifier once we
On Thu, 2007-08-16 at 19:13 -0700, Joe Perches wrote:
> Sorry, not a git developer, so the paths are wrong.
> This seems to work:
Sorry. Patch reversed too.
--- /usr/local/bin/git-send-email 2007-05-01 11:59:14.0 -0700
+++ /home/joe/bin/git-send-email.pl 2007-08-16
On 08/17/2007 03:58 AM, Alan Stern wrote:
On Fri, 17 Aug 2007, Rene Herman wrote:
On 08/16/2007 11:39 PM, Stefan Richter wrote:
Rene Herman wrote:
I personally don't think there's a whole lot wrong with more and
more expecting people who submit patches (for whom this automation
is
On Thu, 2007-08-16 at 14:56 -0400, Jeff Garzik wrote:
> Mike Frysinger wrote:
> > On 8/16/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >> Mike Frysinger wrote:
> >>> On 8/16/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Sonic Zhang wrote:
> > +static void bfin_set_piomode(struct ata_port
Segher Boessenkool 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.
Almost everything is a tradeoff; and so is this. I don't
believe most people would
On Fri, Aug 17, 2007 at 06:05:18AM +0800, Fengguang Wu wrote:
> Split large vmas into page groups of proc_maps_private.batch_size bytes, and
> iterate them one by one for seqfile->show. This allows us to export large
> scale
> process address space information via the seqfile interface. The old
On Thu, Aug 16, 2007 at 10:04:24PM -0400, Chris Snook wrote:
>
> >Could you please cite the file/function names so we can
> >see whether removing the barrier makes sense?
>
> At a glance, several architectures' implementations of smp_call_function()
> have one or more legitimate atomic_read()
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
On Fri, Aug 17, 2007 at 06:05:17AM +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
> if
> a process has 1000 pages all to itself, and 1000 shared with one
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
Can you find an actual atomic_read code snippet there that is
broken without the volatile modifier?
A whole bunch of atomic_read uses will be broken without the volatile
modifier once we start removing barriers that
On Fri, 17 Aug 2007, Rene Herman wrote:
> On 08/16/2007 11:39 PM, Stefan Richter wrote:
> > Rene Herman wrote:
>
> >> I personally don't think there's a whole lot wrong with more and more
> >> expecting people who submit patches (for whom this automation is
> >> intended) to be using git.
> >
>
On 08/16/2007 11:39 PM, Stefan Richter wrote:
Rene Herman wrote:
I personally don't think there's a whole lot wrong with more and more
expecting people who submit patches (for whom this automation is
intended) to be using git.
You mean "people who frequently submit patches for various
This patch removes the __STR() and STR() macros from x86_64 header files.
They seem to be legacy, and has no more users. Even if there were users,
they should use __stringify() instead.
In fact, there were one third place in which this macro was defined
(ia32_binfmt.c), and used just below. In
On Fri, 17 Aug 2007 01:14:50 +0900, Paul Mundt <[EMAIL PROTECTED]> wrote:
> > +MODULE_ALIAS("ds1742");
>
> Presumably this should be ds1553.
Oh of course! Thanks.
Subject: [PATCH] rtc: Make rtc-ds1553 driver hotplug-aware
Add an MODULE_ALIAS() to make this platform driver hotplug-aware.
On Thu, Aug 16, 2007 at 06:02:32PM -0700, Paul E. McKenney wrote:
>
> Yep. Or you can use atomic_dec_return() instead of using a barrier.
Or you could use smp_mb__{before,after}_atomic_dec.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
On Tue, Aug 14, 2007 at 04:41:16PM -0700, Paul E. McKenney wrote:
> 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
On Thu, 2007-08-16 at 16:16 -0400, Dave Jones wrote:
> asides from the needed Kconfig clarification, is it necessary for khvcd
> to run at all if the lguest module hasn't been loaded ? Is it possible
> we can somehow delay creation of the kthread ?
It's for lguest guests, so it kind of needs to
On Thu, 2007-08-16 at 16:11 +0200, Andi Kleen wrote:
> Huang, Ying wrote:
> > On Thu, 2007-08-16 at 06:42 +0800, 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
Alan Stern wrote:
> This patch (as960) removes the error message and stack dump logged by
> sysfs_remove_bin_file() when someone tries to remove a nonexistent
> file. The warning doesn't seem to be needed, since none of the other
> file-, symlink-, or directory-removal routines in sysfs complain
This adds items to the taststats struct to account for user and system
time based on scaling the CPU frequency and instruction issue rates.
Adds account_(user|system)_time_scaled callbacks which architectures
can use to account for time using this mechanism.
Signed-off-by: Michael Neuling
On Thu, Aug 16, 2007 at 01:20:26PM -0700, Christoph Lameter wrote:
> On Thu, 16 Aug 2007, Chris Snook wrote:
>
> > atomic_dec() already has volatile behavior everywhere, so this is
> > semantically
> > okay, but this code (and any like it) should be calling cpu_relax() each
> > iteration through
On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
> >
> > The compiler can also reorder non-volatile accesses. For an example
> > patch that cares about this, please see:
> >
> > http://lkml.org/lkml/2007/8/7/280
>
On Thu, Aug 16, 2007 at 05:10:25PM -0700, Shannon Nelson wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
>
> This patch contains the following changes to the DMA engine menus:
>...
> - make it clear in the INTEL_IOATDMA help text that this driver is for
> rare hardware the user most likely
On Sun, Aug 05, 2007 at 11:00:29AM -0400, Theodore Tso wrote:
> P.S. Yet alternative is to specify noatime on an individual
> file/directory basis. We've had this capability for a *long* time,
> and if a distro were to set noatime for all files in certain
> hierarchies (i.e., /usr/include)
Segher Boessenkool writes:
> Instead, use asm() like all other atomic operations already do.
> +static __inline__ long atomic64_read(const atomic_t *v)
> +static __inline__ void atomic64_set(atomic_t *v, long i)
s/atomic_t/atomic64_t/ in both lines. I've edited my copy of the patch.
Paul.
-
On Thursday August 16, [EMAIL PROTECTED] wrote:
> On Thu, Aug 16 2007, NeilBrown wrote:
> > Following are 5 patches which - I think - clean up various bits and pieces
> > in the block layer.
> >
> > The only part that might be seen as a function change rather than
> > simply rearranging code is
In message <[EMAIL PROTECTED]> you wrote:
> Hi, Michael,
>
> Thanks for doing this, this is really useful.
>
> Michael Neuling wrote:
> > This adds two items to the taststats struct to account for user and
> > system time based on scaling the CPU frequency and instruction issue
> > rates.
> >
From: Adrian Bunk <[EMAIL PROTECTED]>
This patch contains the following changes to the DMA engine menus:
- switch to menuconfig
- INTEL_IOATDMA must depend on X86
- INTEL_IOATDMA must select DCA
- device drivers shouldn't "default m"
- DCA shouldn't be a user visible option
- make it clear in the
On Thu, Aug 16, 2007 at 03:23:49PM -0400, Chris Snook wrote:
>
> >You keep saying this yet everytime I ask for an example I
> >get nothing.
>
> Just look for all the code (and there's an immense amount) that has a
> barrier() between two atomic_* operations, or in a loop with such
> operations.
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
>
> >Can you find an actual atomic_read code snippet there that is
> >broken without the volatile modifier?
>
> A whole bunch of atomic_read uses will be broken without the volatile
> modifier once we start removing barriers that
On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
>
> The compiler can also reorder non-volatile accesses. For an example
> patch that cares about this, please see:
>
> http://lkml.org/lkml/2007/8/7/280
>
> This patch uses an ORDERED_WRT_IRQ() in rcu_read_lock() and
>
In message <[EMAIL PROTECTED]> you wrote:
> Michael Neuling wrote:
> > This adds POWERPC specific hooks for scaled time accounting.
> >
> > POWER6 includes a SPURR register. The SPURR is based off the PURR
> > register but is scaled based on CPU frequency and issue rates. This
> > gives a
--- Milan Plzik <[EMAIL PROTECTED]> wrote:
> On Å t, 2007-08-09 at 16:06 +0100, Steven Newbury wrote:
> > --- Milan Plzik <[EMAIL PROTECTED]> wrote:
> >
> > > Good day,
> > >
> > > recently I've been trying to get working PCMCIA interface on H5000
> > > ipaq series, using dual PCMCIA
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
include/linux/percpu_list.h |2 +-
include/linux/smp.h |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
Index: dev/include/linux/percpu_list.h
===
---
On Thu, Aug 16, 2007 at 03:57:24PM -0700, Linus Torvalds wrote:
> I personally consider this an affront to everythign that is decent.
>
> Why the *hell* would mkdir() be so magical as to need something like that?
>
> Make it something sane, like a "struct nameidata" instead, and make it at
>
On Aug 16, 2007, at 18:57:24, Linus Torvalds wrote:
On Wed, 15 Aug 2007, David Howells wrote:
Would you object greatly to functions like vfs_mkdir() gaining a
security parameter? What I'm thinking of is this:
int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode,
struct security
Recent versions of the Linux kernel auto-suspend attached USB devices.
After this happens to the Canon EOS 5D camera, the camera's interrupt endpoints
don't seem to wake back up correctly, causing further use with libgphoto2
to fail with a -114 "OS error in camera communication" error.
A
On Friday 17 August 2007 01:06:47 Len Brown wrote:
> On Thursday 16 August 2007 15:36, Andi Kleen wrote:
> > > @@ -157,10 +162,13 @@ early_param("nosmp", nosmp);
> > > static int __init maxcpus(char *str)
> > > {
> > > get_option(, _cpus);
> > > - return 1;
> > > + if (max_cpus == 0)
> > > +
On Aug 16, 2007, at 11:09:16, Phillip Susi wrote:
Kyle Moffett wrote:
Let me repeat myself here: Algorithmically you fundamentally
CANNOT implement inheritance-based ACLs without one of the
following (although if you have some other algorithm in mind, I'm
listening):
(A) Some kind of
Marc Perkel wrote:
> Yep - way outside the box - and thus the title of the
> thread.
>
> The idea is that people have permissions - not files.
> By people I mean users, groups, managers, applications
> etc. One might even specify that there are no
> permission restrictions at all. Part of the
On Thursday 16 August 2007 15:36, Andi Kleen wrote:
> > @@ -157,10 +162,13 @@ early_param("nosmp", nosmp);
> > static int __init maxcpus(char *str)
> > {
> > get_option(, _cpus);
> > - return 1;
> > + if (max_cpus == 0)
> > + disable_ioapic_setup();
>
> I must say I never
On Wed, 15 Aug 2007, David Howells wrote:
>
> Would you object greatly to functions like vfs_mkdir() gaining a security
> parameter? What I'm thinking of is this:
>
> int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode,
> struct security *security)
I
Altix supports "posted DMA", so that DMA may complete out
of order. In some cases it's necessary for a driver to
ensure that in-flight DMA has been flushed to memory for
correct operation.
In particular this can be a problem with Infiniband, where
writes to Completion Queues can race with
> There is a quite convincing argument that such an access _is_ an
> access to a volatile object; see GCC PR21568 comment #9. This
> probably isn't the last word on the matter though...
I find this argument completely convincing and retract the contrary argument
that I've made many times in
On Thu, 2007-08-16 at 17:58 +0200, Laurent Vivier wrote:
> [PATCH 3/3] introduce "account modifiers" mechanism in the kernel allowing a
> module to modify the collected accounting for a given task. This
> implementation
> is based on the "preempt_notifier". "account_system_time()" and
>
On Wednesday 15 August 2007 13:40, David Howells wrote:
>
> Hi Linus, Al,
>
> Would you object greatly to functions like vfs_mkdir() gaining a security
> parameter? What I'm thinking of is this:
>
> int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode,
>
Indeed, Andreas was taling about the as options.
But AFLAGS is in fact passed to $(CC).
Honestly, I don't think there is any reason not just to use -g.
If something else should be passed to the assembler, the compiler
can be the one to worry about that.
Thanks,
Roland
-
To unsubscribe from
Linas Vepstas writes:
> My gut impression (maybe wrong?) is that the scaled time is,
> in a certain sense, "more accurate" than the unscaled time.
The "unscaled" time is just time, as in "how many seconds did this
task spend on the CPU". It's what all the tools (except a certain
proprietary
This should have been part of the previous Moxa patch I just sent, but I
forgot to include it, so here it is as a seperate patch. Sorry about that.
This fixes the warning :
drivers/char/mxser.c:427: warning: 'CheckIsMoxaMust' defined but not used
when building Moxa driver without
On Wednesday 15 August 2007 18:23, Casey Schaufler wrote:
> > Hi Linus, Al,
> >
> > Would you object greatly to functions like vfs_mkdir() gaining a security
> > parameter?
>
> Could you describe how this compares to the proposal that the
> AppArmor developers suggested recently? I expect that
Hello All,
I've got NFSv4 problems on a big partition. Both NFS server and client run
kernel version 2.6.21.6. Exported file system is on an AoE etherdrive
(/dev/etherd/e1.1) device, having no partition table, XFS file system. The
file system is pretty large, 8.9T. Typical file size 1-10M.
On Thu, Aug 16, 2007 at 02:02:01PM -0700, Andrew Morton wrote:
> On Tue, 14 Aug 2007 23:23:29 +0200
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > It's -gdwarf-2, not -gdwarf2. With this fix it can actually work.
>
> Andreas Schwab has said "The option is officially called -gdwarf-2, and
>
Fix this tiny compiler warning in Moxa driver :
drivers/char/mxser.c:386: warning: 'mxser_get_PCI_conf' declared 'static' but
never defined
when building without CONFIG_PCI.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/char/mxser.c |2 ++
1 files changed, 2
Show a process's page-by-page address space infomation in /proc//pmaps.
It helps to analyze applications' memory footprints in a comprehensive way.
Pages share the same states are grouped into a page range.
For each page range, the following fields are exported:
- first page index
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 if
a process has 1000 pages all to itself, and 1000 shared with one other process,
its PSS will be 1500.
- lwn.net: "ELC: How
Split large vmas into page groups of proc_maps_private.batch_size bytes, and
iterate them one by one for seqfile->show. This allows us to export large scale
process address space information via the seqfile interface. The old behavior
of walking one vma at a time can be achieved by setting the
1 - 100 of 770 matches
Mail list logo
