On Fri, 17 Aug 2007 15:43:04 -0400
Masami Hiramatsu [EMAIL PROTECTED] wrote:
This patch introduces architecture dependent kretprobe
blacklists to prohibit users from inserting return
probes on the function in which kprobes can be inserted
but kretprobes can not.
Signed-off-by: Masami
Of course, since *normal* accesses aren't necessarily limited wrt
re-ordering, the question then becomes one of with regard to *what*
does
it limit re-ordering?.
A C compiler that re-orders two different volatile accesses that have a
sequence point in between them is pretty clearly a buggy
On Fri 17 Aug 2007 17:10, David Brownell pondered:
On the other hand, maybe you want your typical customer to
be more of a systems integrator than anything else.
We are getting yelled at by our customers (I was on the phone yesterday),
because the kernel build environment we distribute (the
(and yes, it is perfectly legitimate to
want a non-volatile read for a data type that you also want to do
atomic RMW operations on)
...which is undefined behaviour in C (and GCC) when that data is
declared volatile, which is a good argument against implementing
atomics that way in itself.
On 17/08/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The patch titled
CIFS: check for granted memory
has been added to the -mm tree. Its filename is
cifs-check-for-granted-memory.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See
Neil Horman wrote:
+static int proc_pid_limits(struct task_struct *task, char *buffer)
+{
+ unsigned int i;
+ int count = 0;
+ char *bufptr = buffer;
+
+ struct rlimit rlim[RLIM_NLIMITS];
+
+ read_lock(tasklist_lock);
+ memcpy(rlim, task-signal-rlim,
In a reasonable world, gcc should just make that be (on x86)
addl $1,i(%rip)
on x86-64, which is indeed what it does without the volatile. But with
the
volatile, the compiler gets really nervous, and doesn't dare do it in
one
instruction, and thus generates crap like
movl
On Friday 17 August 2007, Robin Getz wrote:
On Fri 17 Aug 2007 14:24, David Brownell pondered:
Just for the record, this is an unusual way to use these calls.
That is part of the natural evolution of the kernel isn't it - per James's
keynote at OLS - you release something, and see how
Now the second wording *IS* technically correct, but come on, it's
24 words long whereas the original one was 3 -- and hopefully anybody
reading the shorter phrase *would* have known anyway what was meant,
without having to be pedantic about it :-)
Well you were talking pretty formal (and
On Friday 17 August 2007, Robin Getz wrote:
On Fri 17 Aug 2007 17:10, David Brownell pondered:
On the other hand, maybe you want your typical customer to
be more of a systems integrator than anything else.
We are getting yelled at by our customers (I was on the phone yesterday),
because
#define forget(a) __asm__ __volatile__ ( :=m (a) :m (a))
[ This is exactly equivalent to using +m in the constraints, as
recently
explained on a GCC list somewhere, in response to the patch in my
bitops
series a few weeks back where I thought +m was bogus. ]
[It wasn't explained
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 volatile-qualified type is implementation-defined, but GCC
does help us
On Fri, Aug 17, 2007 at 02:18:56PM -0700, Andrew Morton wrote:
Please always provide at least a copy of the error message when providing
patches which fix warnings, or build errors, or section mismatches.
For section mismatches, an analysis of what caused the problem would help,
too. It
Hi Andrew,
Thank you for comments.
Andrew Morton wrote:
Index: 2.6-mm/include/asm-i386/kprobes.h
===
--- 2.6-mm.orig/include/asm-i386/kprobes.h
+++ 2.6-mm/include/asm-i386/kprobes.h
@@ -44,6 +44,7 @@ typedef u8 kprobe_opcode_t;
On Sat, 18 Aug 2007, Pekka Enberg wrote:
Agreed, especially as we have real zero-sized objects returned from
kmalloc() et al now.
Slab allocators: Fail if ksize is called with a NULL parameter
A NULL pointer means that the object was not allocated. One cannot
determine the size of an object
When using RDMA you lose the capability to do packet shaping,
classification, and all the other wonderful networking facilities
you've grown to love and use over the years.
Same thing with TSO and LRO and who knows what else.
Not true at all. Full classification and
[PATCH] serial: keep the DTR setting for serial console.
with reverting x86, serial: convert legacy COM ports to platform devices, we
will have the serial console before the port is probled again.
uart_add_one_port==uart_configure_port==set_mcttrl(port, 0) will clear the
DTR setting by
Optimize uses of memset with small constant offsets.
This will generate smaller code, and avoid the slow rep/string instructions.
Code copied from i386 with a little cleanup.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- a/include/asm-x86_64/string.h 2007-08-17 15:14:32.0
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
#define forget(a) __asm__ __volatile__ ( :=m (a) :m (a))
[ This is exactly equivalent to using +m in the constraints, as recently
explained on a GCC list somewhere, in response to the patch in my bitops
series a few weeks back
On Sat, 2007-08-18 at 00:42 +0300, Pekka Enberg wrote:
On 8/18/07, Christoph Lameter [EMAIL PROTECTED] wrote:
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated object.
Agreed, especially as we have real zero-sized objects
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
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 has nothing to do with reordering.
If you're
On Sat, 18 Aug 2007, Thomas Gleixner wrote:
On Sat, 2007-08-18 at 00:42 +0300, Pekka Enberg wrote:
On 8/18/07, Christoph Lameter [EMAIL PROTECTED] wrote:
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated object.
Tne network code does memset for 6 and 8 byte values, that can easily
be optimized into simple assignments without string instructions.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- a/include/asm-i386/string.h 2007-08-17 15:14:37.0 -0700
+++ b/include/asm-i386/string.h
On Thu, Aug 16, 2007 at 08:50:30PM -0700, Linus Torvalds wrote:
Just try it yourself:
volatile int i;
int j;
int testme(void)
{
return i = 1;
}
int testme2(void)
{
return j = 1;
}
and compile with all
#define forget(a) __asm__ __volatile__ ( :=m (a) :m (a))
[ This is exactly equivalent to using +m in the constraints, as
recently
explained on a GCC list somewhere, in response to the patch in my
bitops
series a few weeks back where I thought +m was bogus. ]
[It wasn't explained
From: Roland Dreier [EMAIL PROTECTED]
Date: Fri, 17 Aug 2007 16:31:07 -0700
When using RDMA you lose the capability to do packet shaping,
classification, and all the other wonderful networking facilities
you've grown to love and use over the years.
Same thing with TSO
For those interested, an updated PS3 Linux Distributor's Starter
Kit (v1.4) was released.
The release note is here:
http://www.kernel.org/pub/linux/kernel/people/geoff/cell/CELL-Linux-CL_20070817-ADDON/README-e.txt
And the CD-ROM iso image is here (169 MiB):
On Fri, 17 Aug 2007 05:42:13 -0700 (PDT)
Kevin E [EMAIL PROTECTED] wrote:
Hi all,
I've read where the onboard Marvell lan controller on
some Gigabyte boards don't work. I've got two systems
using the same Gigabyte board, on one the LAN works on
the other it dies like described by
Andi Kleen wrote:
Commit 19d36ccdc34f5ed444f8a6af0cbfdb6790eb1177 x86: Fix alternatives
and kprobes to remap write-protected kernel text uses code which is
being patched for patching.
In particular, paravirt_ops does patching in two stages: first it
calls paravirt_ops.patch, then it fills
atomic_dec() writes
to memory, so it _does_ have volatile semantics, implicitly, as
long as the compiler cannot optimise the atomic variable away
completely -- any store counts as a side effect.
I don't think an atomic_dec() implemented as an inline asm volatile
or one that uses a forget macro
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
I had totally forgotten that I'd already filed that bug more
than six years ago until they just closed yours as a duplicate
of mine :)
Good luck in getting it
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
This patch breaks Xen booting. I get infinite recursive faults during
patching when this patch is present. If I boot with
noreplace-paravirt it works OK, and it works as expected if I back
this patch out. I haven't tracked down the exact
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 has nothing to do with reordering.
If you're talking of volatile the type-qualifier keyword, then
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 DMA
Introduce a no-op stub function dma_flags_set_dmaflush. Arches
can override this if necessary to associate a dmaflush attribute
with a DMA-able memory region. In-flight DMA will be flushed to
host memory when a memory region with the dmaflush attribute is
written to.
Signed-off-by: Arthur
Define ARCH_DOES_POSTED_DMA, and override the dma_flags_set_dmaflush
function. Also define dma_flags_get_direction, dma_flags_get_dmaflush
to retrieve the direction and dmaflush attribute from flags
passed to the sn_dma_map_* functions.
Signed-off-by: Arthur Kepner [EMAIL PROTECTED]
--
Add a new parameter dmaflush to ib_umem_get, and update all
callers. For now only the mthca IB driver makes use of the new
parameter.
Signed-off-by: Arthur Kepner [EMAIL PROTECTED]
--
drivers/infiniband/core/umem.c |8 ++--
drivers/infiniband/hw/amso1100/c2_provider.c |
Joe Perches [EMAIL PROTECTED] writes:
Here's a path to enable a command line option
that takes a string argument
cc-cmd
This modifies the @cc array to include whatever
output is produced by cc_cmd $patchfile
cccmd can be stored in a config settings file
previous versions of this
These patches are 2.6.24 material.
They are code cleanup, plus a minor bug fix.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Tidy the tlb flushing code.
With tt mode gone, there is no reason to have the capability to have
different host-level address space updating routines. So, do_op is
called directly from do_mmap, do_mprotect, and do_munmap, rather than
calling a function pointer that it is given.
There was a
A number of files that were changed in the recent removal of tt mode
are userspace files which call the os_* wrappers instead of calling
libc directly. A few other files were affected by this, through
This patch makes these call glibc directly.
There are also style fixes in the affected areas.
extern inline will have different semantics with gcc 4.3.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
include/asm-um/pgalloc.h |2 +-
include/asm-um/pgtable-3level.h |2 +-
include/asm-um/processor-x86_64.h |2 +-
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]
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/os-Linux/file.c |
Get rid of an empty if statement which might look like a bug to a
casual reader.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
fs/hostfs/hostfs_user.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.22/fs/hostfs/hostfs_user.c
Style fixes in hostfs.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
fs/hostfs/hostfs.h |9 +
fs/hostfs/hostfs_kern.c | 226
fs/hostfs/hostfs_user.c | 139 +
3 files changed, 202 insertions(+), 172
On Sat, 18 Aug 2007, Thomas Gleixner wrote:
If yes, who invented this 1980s reminiscence, where you got valid
pointers for malloc(0) ?
I believe his first name started with an L and ended with an s ;-)
Seriously the kmalloc(0) pointer allowed us to detect cases in which
people tried to store
On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
I had totally forgotten that I'd already filed that bug more
than six years ago until they
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
I had totally forgotten that I'd already
On Fri, 17 Aug 2007, Christoph Lameter wrote:
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
gcc bugzilla bug #33102, for whatever that ends up being
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.
Ouch, sorry about that.
Segher
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
atomic_dec() writes
to memory, so it _does_ have volatile semantics, implicitly, as
long as the compiler cannot optimise the atomic variable away
completely -- any store counts as a side effect.
I don't think an
On Fri, 2007-08-17 at 16:38 -0700, Junio C Hamano wrote:
Joe Perches [EMAIL PROTECTED] writes:
... Signed-off-by: ...
I do not see a patch to Documentation/git-send-email.txt here...
Something like this, with appropriate error checking, perhaps?
open my $cc, ${cc_cmd} $t |;
On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
Tne network code does memset for 6 and 8 byte values, that can easily
be optimized into simple assignments without string instructions.
so... question.
Why are we doing this by hand? Wouldn't gcc just generate this code in
the first
On Fri, 17 Aug 2007 18:49:34 -0700
Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
Tne network code does memset for 6 and 8 byte values, that can easily
be optimized into simple assignments without string instructions.
so...
On Fri, 2007-08-17 at 18:54 -0700, Stephen Hemminger wrote:
On Fri, 17 Aug 2007 18:49:34 -0700
Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
Tne network code does memset for 6 and 8 byte values, that can easily
be optimized
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
I didn't quite understand what you said here, so I'll tell what I think:
* foo() is a compiler barrier if the definition of foo() is invisible to
the compiler at a callsite.
* foo() is also a compiler barrier if the
The asm volatile implementation does have exactly the same
reordering guarantees as the volatile cast thing,
I don't think so.
asm volatile creates a side effect.
Yeah.
Side effects aren't
allowed to be reordered wrt sequence points.
Yeah.
This is exactly
the same reason as why
On Fri, 2007-08-17 at 12:50 -0700, David Brownell wrote:
On Friday 17 August 2007, Kay Sievers wrote:
On Fri, 2007-08-17 at 09:55 -0700, David Brownell wrote:
If so, then whoever tried to change the usage of module aliases
in that way goofed in several ways. First, by not changing
Matt,
On Fri, Aug 17, 2007 at 11:58:08AM -0500, Matt Mackall wrote:
On Fri, Aug 17, 2007 at 02:47:27PM +0800, Fengguang Wu wrote:
It's not easy to do direct performance comparisons between pmaps and
pagemap/kpagemap. However some close analyzes are still possible :)
1) code size
pmaps
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
On Fri, 17 Aug 2007, Mathieu Desnoyers wrote:
Why do you printk inside the timing period ? Filling the printk buffers
or outputting on things such as serial console could really hurt your
results.
It was easier to code?
I hope you run
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
The asm volatile implementation does have exactly the same
reordering guarantees as the volatile cast thing,
I don't think so.
asm volatile creates a side effect.
Yeah.
Side effects aren't
allowed to be
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
On Fri, 17 Aug 2007, Mathieu Desnoyers wrote:
Actually, get_cycles() at least on some AMD cpus, do not synchronize the
core, which can skew the results. You might want to use
get_cycles_sync() there.
get_cycle() results as used here are
On Fri, 17 Aug 2007 18:57:00 -0700
Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-08-17 at 18:54 -0700, Stephen Hemminger wrote:
On Fri, 17 Aug 2007 18:49:34 -0700
Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
[Jesper Juhl - Sat, Aug 18, 2007 at 12:17:33AM +0200]
| On 17/08/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
|
| The patch titled
| CIFS: check for granted memory
| has been added to the -mm tree. Its filename is
| cifs-check-for-granted-memory.patch
|
| *** Remember to use
On Friday 17 August 2007, Kay Sievers wrote:
I'm not the one who's advocating a change here. If you want to
first change/break and then fix things, all of that is up to you.
I'm happy to do that. Patch is attached.
NAK. That wasn't even a serious attempt at the fix part,
though it does
On Sat, 18 Aug 2007, Satyam Sharma wrote:
No code does (or would do, or should do):
x.counter++;
on an atomic_t x; anyway.
That's just an example of a general problem.
No, you don't use x.counter++. But you *do* use
if (atomic_read(x) = 1)
and loading into a register
Add a easier method to find maintainers to CC for a patch
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Changes since last submittal:
Added options to include|ignore penguin-chiefs
Changed defaults to appropriate for git-send-email
Added optional git signed-off-by: checking
Changed syntax to be
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 17 Aug 2007 20:31:39 -0700
On Fri, 17 Aug 2007 18:57:00 -0700
Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-08-17 at 18:54 -0700, Stephen Hemminger wrote:
On Fri, 17 Aug 2007 18:49:34 -0700
Arjan van de Ven [EMAIL
Hi Christoph,
When I force SLUB debugging on sparc64, it barfs on early bootup while
making the sysfs nodes. Removing the BUG()'s on the sysfs error
returns, and adding some tracing I captured the log below.
BTW, I would recommending removing the BUG() calls, they serve only to
force someone
The documentation simply doesn't say +m is allowed. The code to
allow it was added for the benefit of people who do not read the
documentation. Documentation for +m might get added later if it
is decided this [the code, not the documentation] is a sane thing
to have (which isn't directly
On Thu, Aug 16, 2007 at 09:23:48PM +0100, Alan Cox wrote:
On Thu, 16 Aug 2007 19:50:43 +0200
Authenticated [EMAIL PROTECTED] wrote:
===
[ INFO: possible circular locking dependency detected ]
2.6.20-1.2948.self #1
This is also a series of falsehoods. All packet filtering,
queue management, and packet scheduling facilities work perfectly
fine and as designed with both LRO and TSO.
I'm not sure I follow. Perhaps broken was too strong a word to use,
but if you pass a huge segment to a NIC with TSO,
Finally moved back in and with internet. Yay!
On Aug 17, 2007, at 00:56:44, Casey Schaufler wrote:
It would not surprise me particularly much if Kyle or someone like
him could produce a perl script that could generate an SELinux
policy that, when added to the reference policy on a system
On Fri, Aug 17, 2007 at 11:34:37AM -0700, K Naru wrote:
From: Kim Naru ([EMAIL PROTECTED])
Added support to offload TCP/UDP/IP checksum to the
VIA Technologies VT6105M chip.
Firstly, let the stack know this chip is capable of
doing its own checksum(IPV4 only).
Secondly offload checksum to
On Fri, Aug 17, 2007 at 06:24:17PM +0200, Xu Yang wrote:
Hi everyone,
I have built up a software virtual prototype system with ARM11MPCORE.
my system is similar with realview_eb_mpcore. but my system is
simpler, which has only a mpcore , uart0, console,timer0_1, and
memorys.
I want to
On Fri, Aug 17, 2007 at 05:03:41PM -0700, Stephen Hemminger wrote:
On Fri, 17 Aug 2007 05:42:13 -0700 (PDT)
Kevin E [EMAIL PROTECTED] wrote:
Hi all,
I've read where the onboard Marvell lan controller on
some Gigabyte boards don't work. I've got two systems
using the same
On Aug 17, 2007, at 15:01:48, Phillip Susi wrote:
[EMAIL PROTECTED] wrote:
It will become even *more* of a not that common if the lock will
block moves and ACL changes *across the filesystem* for
potentially *minutes* at a time.
It will not take anywhere NEAR minutes at a time to update
Per the post here:
http://lkml.org/lkml/2007/6/18/228
it appears that the group ownership patch has made it into .23. I am
using these patches, amongst which the kernel component appears to be
identical:
http://sigxcpu.org/unsorted-patches/0001-allow-tun-ownership-by-group.patch
601 - 678 of 678 matches
Mail list logo