Re: where is the code for read system call?

Am Montag, 23. Juli 2007 schrieb Agarwal, Lomesh: > For future how do I trace a system call to a function in a kernel? strace. i.e: $ strace ls - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at ht

Re: [PATCH] LinuxPPS - definitive version

On Mon, Jul 23, 2007 at 02:35:16PM +0100, David Woodhouse wrote: > > s/Documentaion/Documentation/ in the last line of Documentation/pps/pps.txt Fixed. > Please feed it to scripts/checkpatch.pl -- you can ignore all the > warnings about lines greater than 80 characters, and the complete crap > a

Re: [PATCH] usb/atm: fix Kconfig garbage

On Mon, Jul 23, 2007 at 01:53:30PM +0200, Adrian Bunk wrote: > On Mon, Jul 23, 2007 at 08:56:04AM +0200, Borislav Petkov wrote: > > Hi there, > > > > I don't know whether this is the proper Kconfig-way to fix this but it > > works ok here. > > > > > > When entered, the menu point "USB DSL m

[PATCH 0/8] i386: bitops: Cleanup, sanitize, optimize

Hi, There was a lot of bogus stuff that include/asm-i386/bitops.h was doing, that was unnecessary and not required for the correctness of those APIs. All that superfluous stuff was also unnecessarily disallowing compiler optimization possibilities, and making gcc generate code that wasn't as beaut

[PATCH 1/8] i386: bitops: Update/correct comments

From: Satyam Sharma <[EMAIL PROTECTED]> [1/8] i386: bitops: Update/correct comments Just trying to standardize the look of comments for various functions of the bitops API, removed some trailing whitespace here and there, give different kernel-doc description to the atomic functions and their cor

[PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

From: Satyam Sharma <[EMAIL PROTECTED]> [2/8] i386: bitops: Rectify bogus "Ir" constraints The "I" constraint (on the i386 platform) is used to restrict constants to the 0..31 range, for use with instructions that must deal with bit numbers. However: * The "I" constraint modifier is applicable o

[PATCH 3/8] i386: bitops: Rectify bogus "+m" constraints

From: Satyam Sharma <[EMAIL PROTECTED]> [3/8] i386: bitops: Rectify bogus "+m" constraints >From the gcc manual: Extended asm supports input-output or read-write operands. Use the constraint character `+' to indicate such an operand and list it with the output operands. You should only use

[PATCH 4/8] i386: bitops: Kill volatile-casting of memory addresses

From: Satyam Sharma <[EMAIL PROTECTED]> [4/8] i386: bitops: Kill volatile-casting of memory addresses All the occurrences of "volatile" that are used to qualify access to the passed bit-string pointer/address must be removed, because "volatile" is crazy, doesn't really work anyway, has nothing to

[PATCH 5/8] i386: bitops: Contain warnings fallout from the death of volatiles

From: Satyam Sharma <[EMAIL PROTECTED]> [5/8] i386: bitops: Contain warnings fallout from the death of volatiles The wrappers below included from all over tree re-used "volatile" just because the bitops used them. With them killed, almost every file ends up crying about: warning: passing argumen

[PATCH 6/8] i386: bitops: Don't mark memory as clobbered unnecessarily

From: Satyam Sharma <[EMAIL PROTECTED]> [6/8] i386: bitops: Don't mark memory as clobbered unnecessarily The goal is to let gcc generate good, beautiful, optimized code. But test_and_set_bit, test_and_clear_bit, __test_and_change_bit, and test_and_change_bit unnecessarily mark all of memory as c

[PATCH 7/8] i386: bitops: Kill needless usage of __asm__ __volatile__

From: Satyam Sharma <[EMAIL PROTECTED]> [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__ Another oddity I noticed in this file. The semantics of __volatile__ when used to qualify inline __asm__ are that the compiler will not (1) elid, or, (2) reorder, or, (3) intersperse, our inlin

[PATCH 8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions

From: Satyam Sharma <[EMAIL PROTECTED]> [8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions >From Documentation/atomic_ops.txt, those archs that require explicit memory barriers around clear_bit() must also implement these two interfaces. However, for i386, clear_bit() is a strict

Re: Pin-pointing the root of unusual application latencies

* John Sigler <[EMAIL PROTECTED]> wrote: > > ./trace-it 1 > trace.txt > > > > does it produce lots of trace entries? If not then > > CONFIG_FUNCTION_TRACING is not enabled. Once you see lots of output > > in the file, the tracer is up and running and you can start tracing > > the latency in yo

RE: drivers/dma/ioatdma.c - address of '__this_module' will always evaluate as 'true' , warning

Gabriel C [mailto:[EMAIL PROTECTED] > >Hi, > >I got this warning on current git using gcc 4.2.1 : > >... > >drivers/dma/ioatdma.c: In function 'ioat_init_module': >drivers/dma/ioatdma.c:816: warning: the address of >'__this_module' will always evaluate as 'true' Can you forward a copy of your .c

Re: [PATCH] fix broken handling of port=... in NFS option parsing

ACK. Al Viro wrote: Obviously broken on little-endian; fortunately, the option is not frequently used... Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/fs/nfs/super.c b/fs/nfs/super.c index b34b7a7..b2a851c 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -732,7 +732,7 @

Re: Determine version of kernel that produced vmcore

On Mon, Jul 23, 2007 at 04:02:39PM +0300, Dan Aloni wrote: > On Mon, Jul 23, 2007 at 08:47:23PM +0900, Ken'ichi Ohmichi wrote: > > > > Hi, > > > > 2007/07/23 10:31:47 +0530, Vivek Goyal <[EMAIL PROTECTED]> wrote: > [..] > > > > > >I am also in favour of a complete kernel based solution. Export re

Plan 9 Resource Sharing Support - what is it?

Hi! Plan 9 Resource Sharing Support (9P2000) (Experimental) (NET_9P) [N/m/y/?] (NEW) ? If you say Y here, you will get experimental support for Plan 9 resource sharing via the 9P2000 protocol. See for more information. If unsure, say N. What is "plan 9 resource sharing"?

Re: [2.6 patch] eepro100 resume patch

On Fri 2007-07-13 21:11:28, Kok, Auke wrote: > [adding netdev] > > David Fries wrote: > >When I did a software suspend to disk then resumed the Intel network > >card using eepro100 driver would be unable to transmit packets. I > >tracked this down and found a register write after the print messag

Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

On Monday 23 July 2007 18:05:38 Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [2/8] i386: bitops: Rectify bogus "Ir" constraints > > The "I" constraint (on the i386 platform) is used to restrict constants to > the 0..31 range, for use with instructions that must deal with bit

Re: Plan 9 Resource Sharing Support - what is it?

On Mon, Jul 23, 2007 at 09:54:34AM +0200, Pavel Machek wrote: > Plan 9 Resource Sharing Support (9P2000) (Experimental) (NET_9P) > [N/m/y/?] (NEW) ? > > If you say Y here, you will get experimental support for > Plan 9 resource sharing via the 9P2000 protocol. > > See for m

Re: [PATCH 6/8] i386: bitops: Don't mark memory as clobbered unnecessarily

On Monday 23 July 2007 18:05:58 Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [6/8] i386: bitops: Don't mark memory as clobbered unnecessarily > > The goal is to let gcc generate good, beautiful, optimized code. The first goal is correct code. The reason for the memory bar

Re: [PATCH 7/8] i386: bitops: Kill needless usage of __asm__ __volatile__

On Monday 23 July 2007 18:06:03 Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__ > > Another oddity I noticed in this file. The semantics of __volatile__ > when used to qualify inline __asm__ are that the compiler w

Re: 2.6.22.1-rt4 lockups

On Sat, 2007-07-21 at 23:07 +0100, Rui Nuno Capela wrote: > Call Trace: > [] show_trace_log_lvl+0x1a/0x30 > [] show_stack_log_lvl+0xb6/0xe0 > [] show_registers+0x201/0x330 > [] die+0x118/0x260 > [] do_page_fault+0x193/0x600 > [] error_code+0x72/0x78 > [] activate_task+0x4f/0xb0 > [] try_to

Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

Hi Andi, On Mon, 23 Jul 2007, Andi Kleen wrote: > On Monday 23 July 2007 18:05:38 Satyam Sharma wrote: > > From: Satyam Sharma <[EMAIL PROTECTED]> > > > > [2/8] i386: bitops: Rectify bogus "Ir" constraints > > > > The "I" constraint (on the i386 platform) is used to restrict constants to > > t

Re: [PATCH 7/8] i386: bitops: Kill needless usage of __asm__ __volatile__ II

BTW if you want to optimize inline asm code a bit -- find_first_bit / find_first_zero_bit / for_each_cpu could really benefit from a optimized version for cpumask_t sized bitmaps. That would save a lot of cycles in some of the hotter paths of the kernel like the scheduler. -Andi - To unsubsc

Section mismatch warnings for early memory allocations

Checking for section mismatches across all of vmlinux is kicking out a bunch of new warnings. Many of them real, but I have a few from routines like this: foo(...) { static int first_time = 1; if (first_time) { all_i_need = alloc_bootmem(NR_CPUS * xxx);

Re: [PATCH 7/8] i386: bitops: Kill needless usage of __asm__ __volatile__

Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__ > > Another oddity I noticed in this file. The semantics of __volatile__ > when used to qualify inline __asm__ are that the compiler will not > (1) elid, or, (2) reorde

Re: [PATCH 6/8] i386: bitops: Don't mark memory as clobbered unnecessarily

Hi Andi, On Mon, 23 Jul 2007, Andi Kleen wrote: > On Monday 23 July 2007 18:05:58 Satyam Sharma wrote: > > From: Satyam Sharma <[EMAIL PROTECTED]> > > > > [6/8] i386: bitops: Don't mark memory as clobbered unnecessarily > > > > The goal is to let gcc generate good, beautiful, optimized code. >

Re: 2.6.23rc1 git: EIP is at acpi_processor_throttling_seq_show+0x8b/0xdd [processor]

On Monday 23 July 2007 11:40, Arkadiusz Miskiewicz wrote: > > After booting fresh 2.6.23rc1 taken from git I noticed oops in dmesg: > [ 46.274038] BUG: unable to handle kernel NULL pointer dereference at > virtual address > [ 46.274042] printing eip: > [ 46.274044] f8b5b2dc > [

Re: SCSI vs SATA

BuraphaLinux Server wrote: Hello, I have had a hard time determining if /dev/sda is SCSI or SATA from my boot scripts. It matters for smartd which needs an added parameter -d sat in the configuration file for SATA drives. Finally I came up with this, but I wonder if there is a better way?

Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

> Whoa, thanks for explaining that to me -- I didn't know, obviously. I had > just written a test program that used "Ir" with an automatic variable > defined in the inline function (as is the case with these bitops) and > observed that even when I gave > 32 values, it would still work -- hence > m

Re: [PATCH 7/8] i386: bitops: Kill needless usage of __asm__ __volatile__

Hi, On Mon, 23 Jul 2007, Andi Kleen wrote: > On Monday 23 July 2007 18:06:03 Satyam Sharma wrote: > > From: Satyam Sharma <[EMAIL PROTECTED]> > > > > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__ > > > > Another oddity I noticed in this file. The semantics of __volatile__ > >

Re: where is the code for read system call?

On Mon, 23 Jul 2007 18:01:32 +0200 Karsten Wiese wrote: > Am Montag, 23. Juli 2007 schrieb Agarwal, Lomesh: > > For future how do I trace a system call to a function in a kernel? > > strace. i.e: > $ strace ls I thought (maybe I misunderstood) that Lomesh wanted to know which kernel functi

Re: [PATCH] release quicklist before free_page

On Mon, 2007-07-23 at 08:21 -0700, Daniel Walker wrote: > Resolves, > > BUG: sleeping function called from invalid context cc1(29651) at > kernel/rtmutex.c:636 > in_atomic():1 [0001], irqs_disabled():0 > [] __might_sleep+0xf3/0xf9 > [] __rt_spin_lock+0x21/0x3c > [] get_zone_pcp+0x20/0x29 >

Re: [PATCH 6/8] i386: bitops: Don't mark memory as clobbered unnecessarily

> Yes, but _that_ address (of the bit-string) is protected already -- by the > implicit memory barrier due to the LOCK prefix. Compiler barrier != CPU barrier. The memory clobber is a compiler barrier that prevents its global optimizer from moving memory references. The CPU memory ordering guara

[PATCH] 0 -> NULL, drivers/usb/gadget/

When comparing a pointer, it's clearer to compare it to NULL than to 0. Here is the semantic patch: @@ expression *E; @@ E == - 0 + NULL @@ expression *E; @@ - 0 + NULL == E @@ expression *E; @@ E != - 0 + NULL @@ expression *E; @@ - 0 + NULL != E PS: I have performed the same

Re: [PATCH] release quicklist before free_page

On Mon, 2007-07-23 at 18:32 +0200, Peter Zijlstra wrote: > On Mon, 2007-07-23 at 08:21 -0700, Daniel Walker wrote: > > Resolves, > > > > BUG: sleeping function called from invalid context cc1(29651) at > > kernel/rtmutex.c:636 > > in_atomic():1 [0001], irqs_disabled():0 > > [] __might_sleep+

Re: [PATCH 3/8] i386: bitops: Rectify bogus "+m" constraints

On Monday 23 July 2007 18:05:43 Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [3/8] i386: bitops: Rectify bogus "+m" constraints > > From the gcc manual: > > Extended asm supports input-output or read-write operands. Use the > constraint character `+' to indicate such an

Re: Plan 9 Resource Sharing Support - what is it?

On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote: Hi! What is "plan 9 resource sharing"? Some kind of mosix-like process migration? Could you explain it in two lines in Kconfig? http://v9fs.sf.net is redirect to http://v9fs.sourceforge.net/ which tells me Moved to SWiK after clicking on

Re: drivers/dma/ioatdma.c - address of '__this_module' will always evaluate as 'true' , warning

Nelson, Shannon wrote: > Gabriel C [mailto:[EMAIL PROTECTED] >> Hi, >> >> I got this warning on current git using gcc 4.2.1 : >> >> ... >> >> drivers/dma/ioatdma.c: In function 'ioat_init_module': >> drivers/dma/ioatdma.c:816: warning: the address of >> '__this_module' will always evaluate as 'tr

Dynamic kernel updates using DynAMOS

Hello, please CC me as I'm not registered in these lists. I'd like to announce DynAMOS, a dynamic kernel updating system that supports Linux and could be of help in kernel development and high availability. This system has been a research project at Arizona State University for the past 3 years a

Re: Plan 9 Resource Sharing Support - what is it?

> > Plan 9 Resource Sharing Support (9P2000) (Experimental) (NET_9P) > > [N/m/y/?] (NEW) ? > > > > If you say Y here, you will get experimental support for > > Plan 9 resource sharing via the 9P2000 protocol. > > > > See for more information. > > > > If unsure, say N. > >

Re: [PATCH 7/8] i386: bitops: Kill needless usage of __asm__ __volatile__

Hi Jeremy, On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote: > Satyam Sharma wrote: > > From: Satyam Sharma <[EMAIL PROTECTED]> > > > > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__ > > > > Another oddity I noticed in this file. The semantics of __volatile__ > > when used to qual

Re: Section mismatch warnings for early memory allocations

On Mon, Jul 23, 2007 at 09:22:14AM -0700, Luck, Tony wrote: > Checking for section mismatches across all of vmlinux is kicking > out a bunch of new warnings. Many of them real, but I have a > few from routines like this: > > foo(...) > { > static int first_time = 1; > > if (first_tim

Re: Pin-pointing the root of unusual application latencies

Ingo Molnar wrote: add 'notrace' to the definition of read_tsc in arch/i386/kernel/tsc.c OK. (or do echo 1 > /proc/sys/kernel/trace_use_raw_cycles if you are using recent enough -rt) Is patch-2.6.20-rt8 recent enough? # ./trace-it 1 >trace # cat trace preemption latency trace v1.1.5 on 2.

Re: Linus 2.6.23-rc1

I get some ACPI Exception. ... [ 33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] [ 33.075437] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ 33.075490] ACPI Exception (processor_throttling-0084): AE_NO

Re: Problems with timerfd()

Hey there Michael, all, On 7/22/07, Michael Kerrisk <[EMAIL PROTECTED]> wrote: Problem 1 - The value returned by read(2)ing from a timerfd file descriptor is the number of timer overruns. In 2.6.22, this value is 4 bytes, limiting the overrun count to 2^32. Consider an application wh

Re: Git tree for old kernels from before the current tree

On Sun, 22 Jul 2007, H. Peter Anvin wrote: > > Wouldn't be hard to make a git tree with all the patches all the way > back to 0.01 even... I actually tried to get something like this together back in the BK days and early in the SCO saga. It was pretty painful to try to find all the historic

Re: Linus 2.6.23-rc1

On Monday 23 July 2007 19:43:56 Gabriel C wrote: > I get some ACPI Exception. > > ... > > [ 33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, > Evaluating _PTC [20070126] [ 33.075437] ACPI Exception > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ >

Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

> > > Whoa, thanks for explaining that to me -- I didn't know, obviously. I had > > just written a test program that used "Ir" with an automatic variable > > defined in the inline function (as is the case with these bitops) and > > observed that even when I gave > 32 values, it would still work --

[PATCH]: Add command-line option to i8042 to completely disable it

(I tried to send this patch to linux-input@, but it seems to be currently having some problems, so I'm going directly to LKML). Certain (broken) pieces of South Bridge hardware will respond to i8042_read_status() on boot with 0x0, despite there not being a real i8042 controller hooked up in the so

Re: [PATCH 6/8] i386: bitops: Don't mark memory as clobbered unnecessarily

Hi, On Mon, 23 Jul 2007, Andi Kleen wrote: > > > Yes, but _that_ address (of the bit-string) is protected already -- by the > > implicit memory barrier due to the LOCK prefix. > > Compiler barrier != CPU barrier. Exactly, but the actual _synchronization_ in all users of the bitops API should (

Re: [PATCH 3/8] i386: bitops: Rectify bogus "+m" constraints

On Mon, 23 Jul 2007, Andi Kleen wrote: > On Monday 23 July 2007 18:05:43 Satyam Sharma wrote: > > From: Satyam Sharma <[EMAIL PROTECTED]> > > > > [3/8] i386: bitops: Rectify bogus "+m" constraints > > > > From the gcc manual: > > > > Extended asm supports input-output or read-write operands.

Re: CTL_UNNUMBERED (Re: [PATCH] 9p: Don't use binary sysctl numbers.)

On 7/21/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote: Alexey Dobriyan <[EMAIL PROTECTED]> writes: > > That's separate patch but CTL_UNNUMBERED must die, because it's totally > unneeded. If you don't want sysctl(2) interface just SKIP ->ctl_name > initialization and save one line for something

Re: Linus 2.6.23-rc1: ACPI-related oops on x86_64

On Monday 23 July 2007 05:50, Mel Gorman wrote: > This was seen on a machine on test.kernel.org; > > Unable to handle kernel NULL pointer dereference at > RIP: > [] acpi_processor_throttling_seq_show+0xa7/0xd6 > PGD 3bd9e067 PUD 3bc6a067 PMD 0 > Oops: [1] SMP > CPU 3 >

Re: blackfin - cmpxchg not atomic ?

On Fri 20 Jul 2007 16:28, Mathieu Desnoyers pondered: > > I also don't like the comment in asm-blackfin/atomic.h : > > * Generally we do not concern about SMP BFIN systems, so we don't have > * to deal with that. > > I have seen on the blackfin website that you actually sell a board with > SMP.

[PATCH] fix inode_table test in ext234_check_descriptors

ext[234]_check_descriptors sanity checks block group descriptor geometry at mount time, testing whether the block bitmap, inode bitmap, and inode table reside wholly within the blockgroup. However, the inode table test is off by one so that if the last block in the inode table resides on the last

fallocate syscall interface defficiency

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The fallocate syscall returns ENOSYS in case the filesystem does not support the operation and expects the userlevel code to fill in. This is good in concept. The problem is that the libc code for old kernels should be able to distinguish the case wh

[patch] AGP: document boot options

Add documentation for AGP boot options. Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt |7 +++ 1 file changed, 7 insertions(+) --- 2.6.22-git11-d390.orig/Documentation/kernel-parameters.txt +++ 2.6.22-git11-d390/Documentation/kernel-parameters.tx

Re: [linux-pm] Power Management framework proposal

On Mon, 23 Jul 2007, Ondrej Zajicek wrote: On Sun, Jul 22, 2007 at 09:19:17PM -0700, Arjan van de Ven wrote: let me give you a real world example then, and the numbers I'm using are ballpark the same as you'll find in a (mobile) core 2 duo datasheet, I just rounded them a little so that the mat

Re: [PATCH 7/8] i386: bitops: Kill needless usage of __asm__ __volatile__

Satyam Sharma wrote: > Hi Jeremy, > > > On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote: > > >> Satyam Sharma wrote: >> >>> From: Satyam Sharma <[EMAIL PROTECTED]> >>> >>> [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__ >>> >>> Another oddity I noticed in this file. The seman

Re: [PATCH 07/10] Task Containers(V11): Automatic userspace notification of idle containers

Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > This patch adds the following files to the container filesystem: > > notify_on_release - configures/reports whether the container subsystem should > attempt to run a release script when this container becomes unused > > release_agent - configures/r

Re: posible latency issues in seq_read

Eric Dumazet wrote: The problem is in established_get_next() and established_get_first() not allowing softirq processing, while scanning a possibly huge hash table, even if few sockets are hashed in. As cond_resched_softirq() was added in linux-2.6.11, you probably *need* to check the diffs

Re: [PATCH 3/8] i386: bitops: Rectify bogus "+m" constraints

On Mon, 23 Jul 2007, Satyam Sharma wrote: > > [3/8] i386: bitops: Rectify bogus "+m" constraints > > From the gcc manual: > > Extended asm supports input-output or read-write operands. Use the > constraint character `+' to indicate such an operand and list it with > the output operands.

Re: Git tree for old kernels from before the current tree

On Mon, 23 Jul 2007, Linus Torvalds wrote: > So I've been thinking about trying to re-create some really old history > into git, but it's still a lot of work.. And obviously not very useful, > just interesting from an archeological standpoint. I started this once. I have (sort of) a GIT tree w

Re: [PATCH 6/8] i386: bitops: Don't mark memory as clobbered unnecessarily

Satyam Sharma wrote: > Exactly, but the actual _synchronization_ in all users of the bitops API > should (should, at least, otherwise the bugs lie in the callers) depend > upon the _bit-string_ whose address is passed to us. That could be some > flags/lock/etc in some caller, whatever, but all the

[PATCH] remove unused bh in calls to ext234_get_group_desc

ext[234]_get_group_desc never tests the bh argument, and only sets it if it is passed in; it is perfectly happy with a NULL bh argument. But, many callers send one in and never use it. May as well call with NULL like other callers who don't use the bh. Signed-off-by: Eric Sandeen <[EMAIL PROTECTE

Re: [PATCH 4/8] i386: bitops: Kill volatile-casting of memory addresses

On Mon, 23 Jul 2007, Satyam Sharma wrote: > > [4/8] i386: bitops: Kill volatile-casting of memory addresses This is wrong. The "const volatile" is so that you can pass an arbitrary pointer. The only kind of abritraty pointer is "const volatile". In other words, the "volatile" has nothing at

Re: [PATCH 6/8] i386: bitops: Don't mark memory as clobbered unnecessarily

On Mon, 23 Jul 2007, Satyam Sharma wrote: > > The goal is to let gcc generate good, beautiful, optimized code. No. The point is to let gcc generate *correct* code. It's either "=m" together with "memory", or it's "+m". You just introduced a bug. Linus - To unsubscribe from th

Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

On Mon, 23 Jul 2007, Satyam Sharma wrote: > > * The "I" constraint modifier is applicable only to immediate-value operands, > and combining it with "r" is bogus. This is wrong too. The whole point of a "Ir" modifier is to say that the instruction takes *either* an "I" or an "r". Andrew - th

Re: "build-id" changes break sparc64

On Mon, Jul 23, 2007 at 12:49:36PM +0100, Al Viro wrote: > On Mon, Jul 23, 2007 at 06:55:59PM +0930, Alan Modra wrote: > > On Mon, Jul 23, 2007 at 10:14:35AM +0200, Sam Ravnborg wrote: > > > But I would still like to hear from Alan what the benefits are. > > > > See http://sourceware.org/ml/binuti

Possible clocksource wrapping issues w/ new vdso clock_gettime() code?

Hey Andi, I've not been able to review the new vdso code very carefully yet, but I noticed one thing right off: the offset calculation is not masked, so its possible w/ counters less then 64bits wide to have wrapping issues. It seems something like the following would be needed. diff --g

__unsafe() usage

On Mon, Jul 23, 2007 at 09:05:54AM -0700, Nelson, Shannon wrote: > Gabriel C [mailto:[EMAIL PROTECTED] > > > >Hi, > > > >I got this warning on current git using gcc 4.2.1 : > > > >... > > > >drivers/dma/ioatdma.c: In function 'ioat_init_module': > >drivers/dma/ioatdma.c:816: warning: the address o

Re: [PATCH] include/linux/slab.h: new KFREE() macro.

>Amit Choudhary <[EMAIL PROTECTED]> wrote: >> --- Christoph Hellwig <[EMAIL PROTECTED]> wrote: >>> On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote: >> Any strong reason why not? x has some value that does not make sense and can >> create only problems. And as I explained, it can re

[WATCHDOG] v2.6.23-rc1 patches 2

Hi Linus, It seems I just missed the closure of the -rc1 merge window. Could you still add following 3 new watchdog drivers + some clean-ups from the watchdog git tree for the -rc2 version? If yes, please pull from 'master' branch of git://git.kernel.org/pub/scm/linux/kernel/git/wim/linu

Re: Git tree for old kernels from before the current tree

On Mon, 23 Jul 2007, Nicolas Pitre wrote: > > I started this once. > > I have (sort of) a GIT tree with all Linux revisions that I could find > from v0.01 up to v1.0.9. But the most interesting information and also > what is the most time consuming is the retrieval of announcement > message

Re: Possible clocksource wrapping issues w/ new vdso clock_gettime() code?

On Mon, 2007-07-23 at 10:59 -0700, john stultz wrote: > Hey Andi, > I've not been able to review the new vdso code very carefully yet, but > I noticed one thing right off: the offset calculation is not masked, so > its possible w/ counters less then 64bits wide to have wrapping issues. Here'

Re: CTL_UNNUMBERED (Re: [PATCH] 9p: Don't use binary sysctl numbers.)

It doesn't really matter (for me) whether it is sysctl or sysfs interface. The sysctl approach seemed easier to implement. If the consensus is to use sysfs, I'll send a patch (for 2.6.24). Sorry for the incorrect implementation, I guess I stole the code from unappropriate place :) Thanks, Luc

Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

Andi Kleen wrote: >> Whoa, thanks for explaining that to me -- I didn't know, obviously. I had >> just written a test program that used "Ir" with an automatic variable >> defined in the inline function (as is the case with these bitops) and >> observed that even when I gave > 32 values, it would st

Re: [PATCH 7/8] i386: bitops: Kill needless usage of __asm__ __volatile__

On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote: > I'm not quite sure what your point is. Could be a case of terminology confusion ... > The paragraph you quoted is > pretty explicit in saying that volatile doesn't prevent an "asm > volatile" from being interspersed with other code, and the examp

Re: CTL_UNNUMBERED (Re: [PATCH] 9p: Don't use binary sysctl numbers.)

On 7/23/07, Latchesar Ionkov <[EMAIL PROTECTED]> wrote: It doesn't really matter (for me) whether it is sysctl or sysfs interface. The sysctl approach seemed easier to implement. If the consensus is to use sysfs, I'll send a patch (for 2.6.24). Sorry for the incorrect implementation, I guess I s

[PATCH respin, was PATCH for review] During VM oom condition, kill all threads in process group

During VM oom condition, kill all threads in process group. We have had complaints where a threaded application is left in a bad state after one of it's threads is killed when we hit a VM: out_of_memory condition. Killing just one of the process threads can leave the application in a bad state, w

Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

On Mon, 23 Jul 2007, Linus Torvalds wrote: > On Mon, 23 Jul 2007, Satyam Sharma wrote: > > > > * The "I" constraint modifier is applicable only to immediate-value > > operands, > > and combining it with "r" is bogus. > > This is wrong too. > > The whole point of a "Ir" modifier is to say that

Re: [linux-pm] Power Management framework proposal

On Mon, 23 Jul 2007, Igor Stoppa wrote: On Sun, 2007-07-22 at 14:21 -0700, ext [EMAIL PROTECTED] wrote: [snip] this is another one. I'd be happy to get pointers to prior ones to learn from. https://lists.linux-foundation.org/pipermail/linux-pm/2007-March/011204.html This is probably one of

Re: early_printk accessing __log_buf

On Sun 22 Jul 2007 19:50, Mike Frysinger pondered: > > i think the attached two functions account for what Robin and Andrew > were thinking ... A note about why/when grab_lock would be set to zero (pre-kernel init, or OOPs) might be nice. Or - remove it - and tell people they should be using do

Re: [linux-pm] Power Management framework proposal

On Mon, 23 Jul 2007, Arjan van de Ven wrote: On Sun, 2007-07-22 at 22:25 -0700, [EMAIL PROTECTED] wrote: only if the transitions don't cost anything significant, these are second order effects though. On a pc, the transition costs are quite low (as I said, single or low double digit microsec

Re: [PATCH][36/37] Clean up duplicate includes in sound/ppc/

Jesper Juhl wrote: > Hi, > > This patch cleans up duplicate includes in > / > > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> > --- > > diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c > index 1aa0b46..27b6189 100644 > --- a/sound/ppc/snd_ps3.c > +++ b/sound/ppc/snd_ps3.c > @

Re: [PATCH] release quicklist before free_page

* Daniel Walker <[EMAIL PROTECTED]> wrote: > > Not quite, it uses preempt_disable() to avoid migration and stick to > > a cpu. Without that it might end up freeing pages from another > > quicklist. i.e. the patch hides a debug warning and there's possibly silent data corruption - not good. >

Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

H. Peter Anvin wrote: > > "I" is correct. The Intel documentation on this is highly confusing > (and has bugs in it), but it does unambiguously state: > > "Some assemblers support immediate bit offsets larger than 31 by using > the immediate bit offset field in combination with the displacement

Re: [PATCH 7/8] i386: bitops: Kill needless usage of __asm__ __volatile__

Satyam Sharma wrote: > The (3) as I had originally written / meant was that multiple > instructions in a volatile asm would not get _individually_ > interspersed with the rest of the code i.e. be emitted out > _consecutively_. I don't think we need any such guarantees for > the non-atomic variants

[2.6 patch] remove Documentation/networking/net-modules.txt

kAccording to git, the only one who touched this file during the last 5 years was me when removing drivers... modinfo offers a less ancient version of this information. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- Documentation/networking/00-INDEX|2 Documentation/networking

Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

On Monday 23 July 2007 20:14:52 Satyam Sharma wrote: > On Mon, 23 Jul 2007, Linus Torvalds wrote: > > > On Mon, 23 Jul 2007, Satyam Sharma wrote: > > > > > > * The "I" constraint modifier is applicable only to immediate-value > > > operands, > > > and combining it with "r" is bogus. > > > > Th

Re: [RFC] Thread Migration Preemption

* Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > Thread Migration Preemption > > This patch adds the ability to protect critical sections from > migration to another CPU without disabling preemption. > > This will be useful to minimize the amount of preemption disabling for > the -rt patch. [

Re: [BUG] firewire: mass-storage i/o-problems

On Mon, Jul 23, 2007 at 01:34:28PM +0200, Stefan Richter wrote: > Manuel Lauss wrote: > > I noticed the failures start when there are 2 concurrent disk accesses > > (copy something from fw disk on shell 1 and it runs fine; start to > > copy something TO the fw disk on shell 2 and a "management writ

Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

On Mon, 23 Jul 2007 12:03:40 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > Daniel recently spotted that __GFP_ZERO is not (and has never been) > part of GFP_LEVEL_MASK. I could not find a reason for this in the > original patch: 3977971c7f09ce08ed1b8d7a67b2098eb732e4cd in the -bk > tree. It d

Re: [PATCH] release quicklist before free_page

On Mon, 2007-07-23 at 20:23 +0200, Ingo Molnar wrote: > > how about: "if you've got some time then please also add a few comments, > because the code was quite non-obvious to me and I misunderstood it when > I tried to fix it. Thanks." Not exactly what I was thinking of .. More like, "LOCKING

RE: which signal is sent to freeze process?

The other problem I am facing that read from socket returns with ENODATA when resuming. any ideas? -Original Message- From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED] Sent: Friday, July 20, 2007 3:10 PM To: Agarwal, Lomesh Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Subject: Re:

[RFC] scheduler: improve SMP fairness in CFS

This patch extends CFS to achieve better fairness for SMPs. For example, with 10 tasks (same priority) on 8 CPUs, it enables each task to receive equal CPU time (80%). The code works on top of CFS and provides SMP fairness at a coarser time grainularity; local on each CPU, it relies on CFS to p

2.6.23-rc1: BUG_ON in kmap_atomic_prot()

Managed to hit BUG_ON() in kmap_atomic_prot() three times while doing nothing unusual for this box (two times it was under X, so I can't guarantee, one time while trying to reproduce via ./configure in gdb tarball) Box has 2.5G of RAM. 2.6.22 was OK. [dives into framebuffer console setup for comp

Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

On Mon, 2007-07-23 at 11:37 -0700, Andrew Morton wrote: > On Mon, 23 Jul 2007 12:03:40 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > Daniel recently spotted that __GFP_ZERO is not (and has never been) > > part of GFP_LEVEL_MASK. I could not find a reason for this in the > > original patch:

<    1   2   3   4   5   6   >