Re: [PATCH] binfmt_elf: core dump masking support

[Kawai, Hidehiro]

Hello Andrew,

Thank you for your reply and advice.
I'll send the revised patchset after I fix what you pointed out.

Andrew Morton wrote:
 
> Regarding the implementation: if we add
> 
>   unsigned char coredump_omit_anon_memory:1;
> 
> into the mm_struct right next to `dumpable' then we avoid increasing the
> size of the mm_struct, and the code gets neater.
> 
> Modification of this field is racy, and we don't have a suitable lock in
> mm_struct to fix that.  I don't think we care about that a lot, but it'd be
> best to find some way of fixing it.

OK, I'll put a bit field right next to `dumpable' member and add a global
lock to protect them from the race.
I have the perception that only writing to these bit-fields needs to
acquire a lock. Simultaneous writes to both bit-fields can cause either one
to be overwritten with its old value. But simultaneous read and write
from/to separate bit-fields is safe because write to one bit-field
doesn't affect read from the other.

The dumpable can be modified at following timing:

  - before starting core dumping in do_coredump()
  - when initialize mm_struct in flush_old_exec()
  - when *uid or *gid is changed by the coresponding system call
  - when the dumpable is modified directly by prctl(2)

I expect that these don't occur so much frequently, so I consider that
the performance impact by using a global lock is small.


> Really we should convert binfmt_aout.c and any other coredumpers too.

Currently, binfmt_aout.c and binfmt_elf_fdpic.c have their own core dump
routines as well as binfmt_elf.c.  However, as far as I know,
binfmt_aout.c never dumps shared memory. 
So I will convert only binfmt_elf_fdpic.c to support this feature.

 
> Does this feature have any security implications?  For example, there might
> be system administration programs which force a coredump on a "bad"
> process, and leave the core somewhere for the administrator to look at. 
> With this change, we permit hiding of that corefile's anon memory from the
> administrator.  OK, lame example, but perhaps there are better ones.

I think we can avoid it by providing a sysctl parameter which
disables/enables this feature.

Another idea is that we provide a sysctl parameter to prohibit non-root
user from writing to /proc//coremask. If the administrator want to 
force a full coredump on a bad process, he/she only has to clear the
coremask after setting the sysctl parameter.

For now, I will implement the first idea, because its design and
implementation are simple and it is easy to use.

Best regards,

-- 
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: xfslogd-spinlock bug?

[Haar János]

- Original Message - 
From: "David Chinner" <[EMAIL PROTECTED]>
To: "Haar János" <[EMAIL PROTECTED]>
Cc: "David Chinner" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;

Sent: Monday, December 18, 2006 7:24 AM
Subject: Re: xfslogd-spinlock bug?


> On Mon, Dec 18, 2006 at 12:56:41AM +0100, Haar János wrote:
> > > On Sat, Dec 16, 2006 at 12:19:45PM +0100, Haar János wrote:
> > > > I dont know there is a context between 2 messages, but i can see,
the
> > > > spinlock bug comes always on cpu #3.
> > > >
> > > > Somebody have any idea?
> > >
> > > Your disk interrupts are directed to CPU 3, and so log I/O completion
> > > occurs on that CPU.
> >
> >CPU0   CPU1   CPU2   CPU3
> >   0:100  0  04583704   IO-APIC-edge
timer
> >   1:  0  0  0  2   IO-APIC-edge
i8042
> >   4:  0  0  03878668   IO-APIC-edge
serial
> .
> >  14:3072118  0  0181   IO-APIC-edge
ide0
> .
> >  52:  0  0  0  213052723   IO-APIC-fasteoi
eth1
> >  53:  0  0  0   91913759   IO-APIC-fasteoi
eth2
> > 100:  0  0  0   16776910   IO-APIC-fasteoi
eth0
> 
> >
> > Maybe
> > I have 3 XFS on this system, with 3 source.
> >
> > 1. 200G one ide hdd.
> > 2. 2x200G mirror on 1 ide + 1 sata hdd.
> > 3. 4x3.3TB strip on NBD.
> >
> > The NBD serves through eth1, and it is on the CPU3, but the ide0 is on
the
> > CPU0.
>
> I'd say your NBD based XFS filesystem is having trouble.
>
> > > Are you using XFS on a NBD?
> >
> > Yes, on the 3. source.
>
> Ok, I've never heard of a problem like this before and you are doing
> something that very few ppl are doing (i.e. XFS on NBD). I'd start
> Hence  I'd start by suspecting a bug in the NBD driver.

Ok, if you have right, this also can be in context with the following issue:

http://download.netcenter.hu/bughunt/20061217/messages.txt   (10KB)


>
> > > > Dec 16 12:08:36 dy-base RSP: 0018:81011fdedbc0  EFLAGS: 00010002
> > > > Dec 16 12:08:36 dy-base RAX: 0033 RBX: 6b6b6b6b6b6b6b6b
RCX:
> > >  
> > > Anyone recognise that pattern?
> >
> > I think i have one idea.
> > This issue can stops sometimes the 5sec automatic restart on crash, and
this
> > shows possible memory corruption, and if the bug occurs in the IRQ
> > handling :-)
> > I have a lot of logs about this issue, and the RAX, RBX always the same.
>
> And is this the only place where you see the problem? Or are there
> other stack traces that you see this in as well?

I have used the 2.6.16.18 for a long time, and it was stable, except this
issue. (~20 dump with xfslogd)
And i try the new releases, and now i have more. :-)

What do you think exactly?
I can see in the logs, but search for what?
The RAX, RBX thing, or the xfslogd-spinlock problem or the old nbd-deadlock
+ mem corruption?

[EMAIL PROTECTED] netlog]# grep "0033" messages*
messages.1:Dec 11 22:47:21 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.1:Dec 12 18:16:35 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.1:Dec 13 11:40:05 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.1:Dec 14 22:25:32 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.1:Dec 15 06:24:44 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.1:Dec 16 12:08:36 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.11:Oct  3 19:49:44 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.11:Oct  7 01:11:17 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.13:Sep 21 15:35:31 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.15:Sep  3 16:13:35 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.15:Sep  5 21:00:38 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.2:Dec  9 00:10:47 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.2:Dec  9 14:07:01 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.2:Dec 10 04:44:48 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.3:Nov 30 10:59:21 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.3:Dec  2 00:54:23 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.5:Nov 13 10:44:49 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.5:Nov 14 03:14:14 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.5:Nov 14 03:37:07 dy-base RAX: 0033 RBX:
6b6b6b6b6b6b6b6b RCX: 
messages.5:Nov 15 

Re: [ANNOUNCE] util-linux-ng

[Ian Kent]

On Mon, 2006-12-18 at 08:52 +0100, Karel Zak wrote:
> 
>  I'm pleased to announce a new "util-linux-ng" project. This project
>  is a fork of the original util-linux (2.13-pre7). 

Perhaps forwarding this to fs-devel would be good also.

> 
>  The goal of the project is to move util-linux code back to useful state, sync
>  with actual distributions and kernel and make development more transparent 
> end
>  open.
> 
>  The short term goals (for 2.13 release):
> 
>   - remove all NFS code from util-linux-ng 
>   (/sbin/mount.nfs from nfs-utils is replacement)
>   - remove FS/device detection code
>   (libblkid from e2fsprogs or libvolumeid is replacement)
>   - move as much as possible patches from distributions to upstream
> 
>  Mailing list:
>http://vger.kernel.org/vger-lists.html#util-linux-ng
> 
>  FTP:
>ftp://ftp.kernel.org/pub/scm/utils/util-linux-ng/
> 
>  GIT:
>git clone 
> git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git 
> util-linux-ng
> 
>[Note, GIT repo contains previous 47 versions of util-linux.]
> 
> 
>  The mailing list or my private e-mail are open for your patches, ideas and
>  suggestion. The mailing list is also place where you can help us review
>  patches.
> 
> Karel
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.34-rc3

[Willy Tarreau]

Hi,

Two changes before -final. The first one fixes a race where
one can hit a BUG(), the second one fixes CVE-2006-4814.

-final is just a few days ahead (it scares me, I'll have to check
my scripts to ensure everything's OK). If you have important fixes
you want to see in, or if it does not work for you, please
manifest yourself.

Willy

Summary of changes from v2.4.34-rc2 to v2.4.34-rc3


Hugh Dickins (1):
  zeromap may find a pte

Linus Torvalds (1):
  Fix incorrect user space access locking in mincore() (CVE-2006-4814)

Willy Tarreau (1):
  Change VERSION to 2.4.34-rc3

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Nick Piggin]

Linus Torvalds wrote:


On Mon, 18 Dec 2006, Nick Piggin wrote:


I can't see how that's exactly a problem -- so long as the page does not
get reclaimed (it won't, because we have a ref on it) then all that matters
is that the page eventually gets marked dirty.



But the point being that "try_to_free_buffers()" marks it clean 
AFTERWARDS.


For some reason I thought you were suggesting it is a problem on its own :P

Yes I agree there is a pagefault vs ttfb race.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] util-linux-ng

[Karel Zak]

On Mon, Dec 18, 2006 at 05:35:29PM +0900, Ian Kent wrote:
> On Mon, 2006-12-18 at 08:52 +0100, Karel Zak wrote:
> > 
> >  I'm pleased to announce a new "util-linux-ng" project. This project
> >  is a fork of the original util-linux (2.13-pre7). 
> 
> Perhaps forwarding this to fs-devel would be good also.

 Fixed.

   Karel

-- 
 Karel Zak  <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ebtables problems on 2.6.19.1

[Santiago Garcia Mantinan]

Hi!

When trying to upgrade a machine from 2.6.18 to 2.6.19.1 I found that it
crashed when loading the ebtables rules on startup.

This is an example of the crash I get:

BUG: unable to handle kernel paging request at virtual address e081e004 
 printing eip:  
c0283da0
*pde = 1fbcb067 
*pte =  
Oops:  [#1] 
CPU:0   
EIP:0060:[]Not tainted VLI
EFLAGS: 00010282   (2.6.19.1 #1)
EIP is at translate_table+0x600/0xe90   
eax: e081df98   ebx: 000e   ecx: e081df98   edx: e081df98   
esi: 0028   edi: dfb37cec   ebp: e081d000   esp: dfb37c30   
ds: 007b   es: 007b   ss: 0068  
Process ebtables (pid: 609, ti=dfb36000 task=c14d1550 task.ti=dfb36000) 
Stack: e081df4c 0024 e081b000 dfb37cec 0020  0010   
    0fc8 0f98 e081df98 0044 0110 0001 0001  
   0110 0138   e081d000 e081df98 0005 0010  
Call Trace: 
 [] do_ebt_set_ctl+0x28f/0x6b0
 [] __alloc_pages+0x4f/0x2e0  
 [] nf_sockopt+0xad/0x100 
 [] nf_setsockopt+0x1e/0x30   
 [] ip_setsockopt+0x12c/0xc50 
 [] do_page_fault+0x0/0x640   
 [] error_code+0x39/0x40  
 [] current_fs_time+0x48/0x60 
 [] touch_atime+0x5d/0xb0 
 [] do_generic_mapping_read+0x385/0x490   
 [] file_read_actor+0x0/0x100 
 [] generic_file_aio_read+0xf0/0x220  
 [] __alloc_pages+0x4f/0x2e0  
 [] filemap_nopage+0x14d/0x350
 [] unmap_vmas+0x29d/0x480
 [] __handle_mm_fault+0x53e/0x630 
 [] free_pgtables+0x85/0xb0   
 [] sock_common_setsockopt+0x23/0x30  
 [] sys_setsockopt+0x5f/0xb0  
 [] sys_socketcall+0x209/0x280
 [] do_page_fault+0x0/0x640   
 [] syscall_call+0x7/0xb  
 [] br_stp_change_bridge_id+0xb/0x1a0 
 ===
Code: 17 0f 83 a2 03 00 00 8b 4c 24 08 8b 5c 24 28 8b 7c 24 0c 8b 69 24 01 eb 89
 5c 24 2c 8b 44 24 2c 8b 54 24 2c 8b 5f 20 8b 4c 24 2c <8b> 40 6c 89 44 24 44 8b
 52 68 89 54 24 40 8b 01 85 c0 0f 84 3a 
EIP: [] translate_table+0x600/0xe90 SS:ESP 0068:dfb37c30  

I've tried to find a subset of the rules that are causing this and I found
that to be very difficult as I have only got this to fail if I load the
ebtables rules at boot time, if I try to load them after the machine is
completely booted it works ok. 2.6.18 still works ok, both kernels have the
"same" config where posible and they are not SMP.

The machine that was having the failure was a PIII 1GHz, I have copied the
filesystem to a PIV 1.6Ghz where it also fails and where I can do tests and
access the console via serial port.

The machine is not being used as a brouter but only as a bridge firewall, it
has some ebtables rules to cut non IP stuff and then does all the work at
iptables level.

I don't know what other info to add here, tell me if you need any other
stuff to diagnose this or any testing here.

Regards...
-- 
Santiago García Mantiñán
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc1-mm1

[Laurent Riffard]

Le 17.12.2006 12:07, Damien Wyart a écrit :

Also, I got panics when unmounting reiser4 filesystems with
2.6.20-rc1-mm1 but I guess this is related to your waring about
reiser4 being broken in 2.6.19-mm1 (even if it is not listed in
notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the
reiser4 panics did not get logged and I am not able to reboot on
2.6.20-rc1-mm1 right now. For the moment, I mainly wanted to report
the xfs messages which seems a bit suspect.



The reiser4 failure is unexpected. Could you please see if you can
capture a trace, let the people at [EMAIL PROTECTED] know?


Ok, I've handwritten the messages, here they are :

reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom 
(fs/reiser4/txmngr.c:1087) (zam-597)
write log failed (-5)

[ got 2 copies of them because I have 2 reiser4 fs)

I got them mainly when I try to reboot or halt the machine, and the
process doesn't finish, the computer gets stuck after the reiser4
messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2.



fix-sense-key-medium-error-processing-and-retry.patch seems to be the culprit.

Reverting it fix those reiser4 panics for me. Damien, could you confirm please ?

~~
laurent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Nick Piggin]

Andrew Morton wrote:

On Mon, 18 Dec 2006 15:51:52 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:



I think the problem Andrew identified is real.



I don't.  In fact I don't think I described any problem (well, I tried to,
but then I contradicted myself).


By saying that there shouldn't be any dirty ptes if there are no
dirty buffers? But in that case the _page_ shouldn't be dirty either,
so that clear_page_dirty would be redundant. But presumably it isn't.


Six hours here of fsx-linux plus high memory pressure on SMP on 1k
blocksize ext3, mainline.  Zero failures.  It's unlikely that this testing
would pass, yet people running normal workloads are able to easily trigger
failures.  I suspect we're looking in the wrong place.


Yes I could believe it the corruption is caused by something else
completely.


The issue is the disconnect between the pte dirtiness and a filesystem
bringing buffers clean.



Really?  The dirtying direction goes pte_dirty->PG_dirty->BH_Dirty and the
cleaning direction goes !BH_Dirty->!PG_dirty->!pte_dirty.  That's pretty
simple, setting aside races.

In the try_to_free_buffers case there's a large time inverval between
!BH_Dirty and !PG_dirty, but that shouldn't affect anything.


After try_to_free_buffers detaches the buffers from the page, a
pagefault can come in, and mark the pte writeable, then set_page_dirty
(which finds no buffers, so only sets PG_dirty).

The page can now get dirtied through this mapping.

try_to_free_buffers then goes on to clean the page and ptes.

I really thought you were the one who identified this race, and I didn't
see where you showed it is safe.

It may be very unlikely with small SMPs, but less so with preempt. All
we have to do is preempt at spin_unlock in try_to_free_buffers AFAIKS.
Were you testing with preempt?

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fallout from atomic_long_t patch

[Evgeniy Polyakov]

On Sun, Dec 17, 2006 at 10:08:49AM -0800, Linus Torvalds ([EMAIL PROTECTED]) 
wrote:
> So with that out of the way, I'll just expect that I'll get whatever you 
> decide on through Davem's git tree, once his drunken holiday revelry is 
> over ;)

This is important process - never interrupt it for things like patches
from external developers :)
I will push it through his tree.

>   Linus

-- 
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

s2disk curiosity :)

[Paolo Ornati]

Hello,

I'm using uswsusp and with commit

3592695c363c3f3119621bdcf5ed852d6b9d1a5c
uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode")


My PC power-light starts flashing during s2disk as expected (comment
from the commit that fixes the same thing in in-kernel suspend):

"[PATCH] swsusp: fix platform mode

At some point after 2.6.13, in-kernel software suspend got "incomplete" for
the so-called "platform" mode.  pm_ops->prepare() is never called.  A
visible sign of this is the "moon" light on thinkpads not flashing during
suspend.  Fix by readding the pm_ops->prepare call during suspend."


BUT: another thing that happens is that now my PC powers itself on
_without_ pressing the power button (just by plugging the AC power).


I don't like this all that much...

I understand this is probably MOBO specific but, is this behaviour
expected/common?

-- 
Paolo Ornati
Linux 2.6.20-rc1-g99f5e971 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Andrew Morton]

On Mon, 18 Dec 2006 18:22:42 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:

> Andrew Morton wrote:
> > On Mon, 18 Dec 2006 15:51:52 +1100
> > Nick Piggin <[EMAIL PROTECTED]> wrote:
> > 
> > 
> >>I think the problem Andrew identified is real.
> > 
> > 
> > I don't.  In fact I don't think I described any problem (well, I tried to,
> > but then I contradicted myself).
> 
> By saying that there shouldn't be any dirty ptes if there are no
> dirty buffers? But in that case the _page_ shouldn't be dirty either,
> so that clear_page_dirty would be redundant. But presumably it isn't.

I don't follow that.

The linkage between pte-dirtiness and buffer_heads is a bit hard to follow
without also considering page-dirtiness.

> > Six hours here of fsx-linux plus high memory pressure on SMP on 1k
> > blocksize ext3, mainline.  Zero failures.  It's unlikely that this testing
> > would pass, yet people running normal workloads are able to easily trigger
> > failures.  I suspect we're looking in the wrong place.
> 
> Yes I could believe it the corruption is caused by something else
> completely.

Think so.  We do have a problem here, but only on threaded apps, I believe.
rtorrent doesn't appear to be threaded, and the bug is hit on non-preempt
UP.

> >>The issue is the disconnect between the pte dirtiness and a filesystem
> >>bringing buffers clean.
> > 
> > 
> > Really?  The dirtying direction goes pte_dirty->PG_dirty->BH_Dirty and the
> > cleaning direction goes !BH_Dirty->!PG_dirty->!pte_dirty.  That's pretty
> > simple, setting aside races.
> > 
> > In the try_to_free_buffers case there's a large time inverval between
> > !BH_Dirty and !PG_dirty, but that shouldn't affect anything.
> 
> After try_to_free_buffers detaches the buffers from the page, a
> pagefault can come in, and mark the pte writeable, then set_page_dirty
> (which finds no buffers, so only sets PG_dirty).
> 
> The page can now get dirtied through this mapping.
> 
> try_to_free_buffers then goes on to clean the page and ptes.

try_to_free_buffers() isn't called against a page which doesn't have
buffers.  It'll oops.

> Were you testing with preempt?

nope, just SMP.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Andrei Popa]

I tried latest git with the patch from this email and it still get file
content corruption. If I can help you further debug the problem tell me
what to do.

On Sun, 2006-12-17 at 21:50 -0800, Linus Torvalds wrote:
> 
> On Mon, 18 Dec 2006, Nick Piggin wrote:
> > 
> > I can't see how that's exactly a problem -- so long as the page does not
> > get reclaimed (it won't, because we have a ref on it) then all that matters
> > is that the page eventually gets marked dirty.
> 
> But the point being that "try_to_free_buffers()" marks it clean 
> AFTERWARDS.
> 
> So yes, the page gets marked dirty in the pte's - the hardware generally 
> does that for us, so we don't have to worry about that part going on.
> 
> But "try_to_free_buffers()" seems to clear those dirty bits without 
> serializing it really any way. It just says "ok, I will now clear them". 
> Without knowing whether the dirty bits got set before the IO that cleared 
> the buffer head dirty bits or not.
> 
> What is _that_ serialization? As far as I can see, the only way to 
> guarantee that to happen (since the dirty bits in the page tables will get 
> set without us ever even being notified) is that the page tables 
> themselves must simply never contain that page in a writable form at all.
> 
> And that seems to be lacking.
> 
> Anyway, I have what I consider a much simpler solution: just don't DO all 
> that crap in try_to_free_buffers() at all. I sent it out to some people 
> already, not not very widely. 
> 
> I reproduce my suggestion here for you (and maybe others too who weren't 
> cc'd in that other discussion group) to comment on..
> 
>   Linus
> 
> ---
> 
> So I think your patch is really broken, how about this one instead?
> 
> It's really my previous patch, BUT it also adds a 
> 
>   if (PageDirty(page) ..
>   return 0;
> 
> case, on the assumption that since PageDirty() measn that one of the 
> buffers should be dirty, there's no point in even _trying_ drop_buffers, 
> since that should just fail anyway.
> 
> Now, that assumption is obviously wrong _if_ the buffers have been cleaned 
> by something else. So in that case, we now don't remove the buffer heads, 
> but who really cares? The page will remain on the dirty list, and 
> something should be trying to write it out, but since now all the buffers 
> are clean, once that happens, there is no actual IO to happen.
> 
> Hmm? So this means that we simply don't remove the buffers early from such 
> pages, but there shouldn't be any real downside.
> 
> Now, the only question would be if the page is marked dirty _while_ this 
> is running. We do hold the page lock, but page dirtying doesn't get the 
> lock, does it? But at least we won't mark the page _clean_ when it 
> shouldn't be.. And we still are atomic wrt the actual buffer lists 
> (mapping->private_lock), so I think this should all be ok, and 
> drop_buffers() will do the right thing.
> 
> So no race possible either.
> 
> At least as far as I can see. And the patch certainly is simple.
> 
> Now the question whether this actually _fixes_ any problems does remain, 
> but I think this should be a pretty good solution if the bug really is 
> here. Andrew?
> 
>   Linus
> 
> 
> diff --git a/fs/buffer.c b/fs/buffer.c
> index d1f1b54..263f88e 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -2834,7 +2834,7 @@ int try_to_free_buffers(struct page *page)
>   int ret = 0;
>  
>   BUG_ON(!PageLocked(page));
> - if (PageWriteback(page))
> + if (PageDirty(page) || PageWriteback(page))
>   return 0;
>  
>   if (mapping == NULL) {  /* can this still happen? */
> @@ -2845,22 +2845,6 @@ int try_to_free_buffers(struct page *page)
>   spin_lock(&mapping->private_lock);
>   ret = drop_buffers(page, &buffers_to_free);
>   spin_unlock(&mapping->private_lock);
> - if (ret) {
> - /*
> -  * If the filesystem writes its buffers by hand (eg ext3)
> -  * then we can have clean buffers against a dirty page.  We
> -  * clean the page here; otherwise later reattachment of buffers
> -  * could encounter a non-uptodate page, which is unresolvable.
> -  * This only applies in the rare case where try_to_free_buffers
> -  * succeeds but the page is not freed.
> -  *
> -  * Also, during truncate, discard_buffer will have marked all
> -  * the page's buffers clean.  We discover that here and clean
> -  * the page also.
> -  */
> - if (test_clear_page_dirty(page))
> - task_io_account_cancelled_write(PAGE_CACHE_SIZE);
> - }
>  out:
>   if (buffers_to_free) {
>   struct buffer_head *bh = buffers_to_free;
> 

-
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-

Linux 2.4.33.6

[Willy Tarreau]

Same fixes as in 2.4.34-rc3.
This one fixes CVE-2006-4814.

Willy

Summary of changes from v2.4.33.5 to v2.4.33.6


Hugh Dickins (1):
  zeromap may find a pte

Linus Torvalds (1):
  Fix incorrect user space access locking in mincore() (CVE-2006-4814)

Willy Tarreau (1):
  Change VERSION to 2.4.33.6

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Andrei Popa]

On Mon, 2006-12-18 at 01:18 -0800, Andrew Morton wrote:
> On Mon, 18 Dec 2006 18:22:42 +1100
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> 
> > Andrew Morton wrote:
> > > On Mon, 18 Dec 2006 15:51:52 +1100
> > > Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > 
> > > 
> > >>I think the problem Andrew identified is real.
> > > 
> > > 
> > > I don't.  In fact I don't think I described any problem (well, I tried to,
> > > but then I contradicted myself).
> > 
> > By saying that there shouldn't be any dirty ptes if there are no
> > dirty buffers? But in that case the _page_ shouldn't be dirty either,
> > so that clear_page_dirty would be redundant. But presumably it isn't.
> 
> I don't follow that.
> 
> The linkage between pte-dirtiness and buffer_heads is a bit hard to follow
> without also considering page-dirtiness.
> 
> > > Six hours here of fsx-linux plus high memory pressure on SMP on 1k
> > > blocksize ext3, mainline.  Zero failures.  It's unlikely that this testing
> > > would pass, yet people running normal workloads are able to easily trigger
> > > failures.  I suspect we're looking in the wrong place.
> > 
> > Yes I could believe it the corruption is caused by something else
> > completely.
> 
> Think so.  We do have a problem here, but only on threaded apps, I believe.
> rtorrent doesn't appear to be threaded, and the bug is hit on non-preempt
> UP.


ierdnac ~ # uname -a
Linux ierdnac 2.6.20-rc1 #2 SMP PREEMPT Mon Dec 18 11:01:52 EET 2006
i686 Genuine Intel(R) CPU   T2050  @ 1.60GHz GenuineIntel
GNU/Linux


and the other person who had corruption with rtorrent has also SMP and
PREEMPT.


> 
> > >>The issue is the disconnect between the pte dirtiness and a filesystem
> > >>bringing buffers clean.
> > > 
> > > 
> > > Really?  The dirtying direction goes pte_dirty->PG_dirty->BH_Dirty and the
> > > cleaning direction goes !BH_Dirty->!PG_dirty->!pte_dirty.  That's pretty
> > > simple, setting aside races.
> > > 
> > > In the try_to_free_buffers case there's a large time inverval between
> > > !BH_Dirty and !PG_dirty, but that shouldn't affect anything.
> > 
> > After try_to_free_buffers detaches the buffers from the page, a
> > pagefault can come in, and mark the pte writeable, then set_page_dirty
> > (which finds no buffers, so only sets PG_dirty).
> > 
> > The page can now get dirtied through this mapping.
> > 
> > try_to_free_buffers then goes on to clean the page and ptes.
> 
> try_to_free_buffers() isn't called against a page which doesn't have
> buffers.  It'll oops.
> 
> > Were you testing with preempt?
> 
> nope, just SMP.
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: util-linux: orphan

[Jan Engelhardt]

> after few weeks I'm pleased to announce a new "util-linux-ng" project. This
> project is a fork of the original util-linux (2.13-pre7). 
>
> The goal of the project is to move util-linux code back to useful state, sync
> with actual distributions and kernel and make development more transparent end
> open.

If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be
the maintainer, ask if you can take over, including the name.
This smells a lot like the RPM case [ http://lwn.net/Articles/196523/ ]
however, it does not look like anyone is going to call it rpm-ng just
because the original name is owned by the last maintainer.


Regards,
-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: s2disk curiosity :)

[Stefan Seyfried]

On Mon, Dec 18, 2006 at 10:06:12AM +0100, Paolo Ornati wrote:
> Hello,
> 
> I'm using uswsusp and with commit
> 
>   3592695c363c3f3119621bdcf5ed852d6b9d1a5c
>   uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode")
> 
> 
> My PC power-light starts flashing during s2disk as expected (comment
> from the commit that fixes the same thing in in-kernel suspend):
> 
> "[PATCH] swsusp: fix platform mode
> 
> At some point after 2.6.13, in-kernel software suspend got "incomplete" 
> for
> the so-called "platform" mode.  pm_ops->prepare() is never called.  A
> visible sign of this is the "moon" light on thinkpads not flashing during
> suspend.  Fix by readding the pm_ops->prepare call during suspend."
> 
> 
> BUT: another thing that happens is that now my PC powers itself on
> _without_ pressing the power button (just by plugging the AC power).
> 
> 
> I don't like this all that much...
> 
> I understand this is probably MOBO specific but, is this behaviour
> expected/common?

Well, yes.
It depends on the BIOS. Many BIOSes have a setting where you can set the
"power fail mode" to "on", "off" or "as before". Now if you enter S4, the
BIOS might set the mode temporarily to "on" or whatever.
For example, many notebooks (have not tried lots of desktops :-) do a "very
quick boot mode" BIOS itialization if they went through the "proper" S4
sequence. On my toughbook and some FSC notebooks, this speeds up the
"power-button to GRUB"-time from ~10 seconds to ~1-2 seconds. The toughbook
even resumes from disk by just opening the lid.

This all is, however, BIOS specific. I have also seen BIOSes where it did
not matter at all.

If you don't like it, you can easily switch it off by 
"echo shutdown > /sys/power/disk" (in-kernel suspend) or by adding
"shutdown method = shutdown" to /etc/suspend.conf (userspace suspend).
You won't get the blinking light, though :-)
-- 
Stefan Seyfried  \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices  \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Andrew Morton]

On Mon, 18 Dec 2006 11:19:04 +0200
Andrei Popa <[EMAIL PROTECTED]> wrote:

> 
> I tried latest git with the patch from this email and it still get file
> content corruption. If I can help you further debug the problem tell me
> what to do.

Can you please tell us all the steps which we need to take to reproduce this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 2.6.19-rt14 does not compile with CONFIG_NO_HZ

[Remy Bohmer]

Hello Ingo,

-rt15 is indeed better...
Thanks!

Remy

2006/12/16, Ingo Molnar <[EMAIL PROTECTED]>:


* Remy Bohmer <[EMAIL PROTECTED]> wrote:

> Hello,
>
> For your Information, I get the following compile error when
> CONFIG_NO_HZ is NOT configured on 2.6.19.1-rt14:

does -rt15 work any better?

Ingo



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Robert P. J. Day]

On Sat, 16 Dec 2006, Stefan Richter wrote:

> Robert P. J. Day wrote on 2006-12-14:
> >   i've posted on this before so here's a slightly-updated patch
> > that uses the kbuild "menuconfig" feature to make numerous entries
> > under the Device drivers menu selectable on the spot.
>
> Works for me, but I don't see a lot of benefit from it. Actually I
> see two disadvantages of the patch:
>
>  - Without the patch, the choice of y/m/n for a subsystem and the
> help text is put aside into the submenu. I find this current layout
> simpler and quieter.

it's certainly "simpler and quieter" in one sense, but one need only
look at a submenu like "Network device support" to see a very "loud"
menu, so it's not like this patch would be introducing an
unprecedented level of noise.

also, in the Device Drivers menu, i find it slightly annoying that i
have to *enter* a submenu to read its help information.  if i see the
entry, say, "Dallas's 1-wire bus" and i have no idea what that is and
select "Help", i get the generic help screen.  i need to select that
entry and enter the submenu just to read its top-level help.

in any event, i'm sure folks understand what i'm after here.  if
there's a cleaner and more efficient way to do this, that would work
for me.

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[DLM] Fix compile warning [1/2]

[Steven Whitehouse]

>From c80e7c83d56866a735236b45441f024b589f9e88 Mon Sep 17 00:00:00 2001
From: Patrick Caulfield <[EMAIL PROTECTED]>
Date: Fri, 8 Dec 2006 14:31:12 -0500
Subject: [PATCH] [DLM] fix compile warning

This patch fixes a compile warning in lowcomms-tcp.c indicating that
kmem_cache_t is deprecated.

Signed-Off-By: Patrick Caulfield <[EMAIL PROTECTED]>
Signed-off-by: Steven Whitehouse <[EMAIL PROTECTED]>
---
 fs/dlm/lowcomms-tcp.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/dlm/lowcomms-tcp.c b/fs/dlm/lowcomms-tcp.c
index 8f2791f..9be3a44 100644
--- a/fs/dlm/lowcomms-tcp.c
+++ b/fs/dlm/lowcomms-tcp.c
@@ -143,7 +143,7 @@ static DECLARE_WAIT_QUEUE_HEAD(lowcomms_
 /* An array of pointers to connections, indexed by NODEID */
 static struct connection **connections;
 static DECLARE_MUTEX(connections_lock);
-static kmem_cache_t *con_cache;
+static struct kmem_cache *con_cache;
 static int conn_array_size;
 
 /* List of sockets that have reads pending */
-- 
1.4.1



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

bcm43xx not properly working with 2.6.19.1

[t u]

Hi,

I filed this to the bugzilla, but all the documentation I read about the
kernel recommends posting to the mailing lists so here I go:

I'm using Ubuntu 6.06 and after booting with the 2.6.19.1 kernel from
kernel.org, the wireless card that uses bcm43xx driver does not work
properly. It fails with
sudo iwlist eth1 scan
 -> eth1: no scan results (even though there are many many ap's around)

The weird thing, after booting to Ubuntu's kernel, the card didn't work
either. I had to reboot to Windows, activate card and connect to an AP,
and then reboot back to Ubuntu's kernel to make it work properly.

I will probably not be able to test patches, as the bug disables the
card in a weird way (it scared the hell out of me).

I tried to provide all the information I could here:
http://bugzilla.kernel.org/show_bug.cgi?id=7682

Please let me know if I can provide more input,

Thanks,
Sincerely.

PS. Please CC me on your replies, thanks :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Binary Drivers

[Bernd Petrovitsch]

On Fri, 2006-12-15 at 21:20 +, James Porter wrote:
> I think some kernel developers take to much responsibility, is there a bug in 
> a
> binary driver? Send it upstream and explain to the user that it's a closed

Plaese name them. AFAICS if there is a response, it is similar to "your
kernel is tainted, please report the report elsewhere".

> source driver and is up to said company to fix it.
> 
> For what it's worth, I don't see any problem with binary drivers from hardware
> manufacturers. 

You are probably not looking at the right places.

> Just because nvidia makes a closed source driver doesn't mean that we can't 
> also

^^
Please send patches.

> create an open source driver(limited functionality, reverse engineered,
> etc.,etc.). I firmly believe that the choice should be up to the user and/or
> distro. I'm not a kernel dev, I don't know c...but I understand the concepts 
> and
^^
Then become one if you are serious with the "we" above.

> I should have the right to do what I want with this GPL code. Restricting me

Then you should discuss this with law makers, politicians and the
various pressure groups about copyright and/or authors rights and you
surely *must* deal beforehand with the patent plague since this is even
more restricting in any sense than author rights ever was (let alone
copyright).
And for such  political debate LKML is probably not a good place.

> only frustrates me. Should the default be open source, definitely; should 
> binary
> drivers be blocked from running on a linux kernel...certainly not.

They are not blocked - it is up to the users to decide and live with the
consequences.

[...]
> only to have the rug pulled out from under you. This is what makes the BSDs so
> attractive.

Why are you then here?

Bernd
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Robert P. J. Day]

On Sat, 16 Dec 2006, Stefan Richter wrote:

> Robert P. J. Day wrote on 2006-12-14:
> >   i've posted on this before so here's a slightly-updated patch that
> > uses the kbuild "menuconfig" feature to make numerous entries under
> > the Device drivers menu selectable on the spot.
>
> Works for me, but I don't see a lot of benefit from it. Actually I see
> two disadvantages of the patch:

... snip ...

>  - There are two out-of-tree FireWire drivers for special purposes
> (one bus sniffer, one remote debugging aid) which might perhaps be
> candidates for integration into mainline. These drivers do not use
> the ieee1394 base driver. (They just don't need to.) With your
> patch, disabling the subsystem menu would not only disable the
> subsystem core driver (which is correct) but would also hide the
> choice for such extra drivers which do not need the core driver. Or
> vice versa, enabling the submenu would enable the core driver, even
> though not all subsystem choices need the core driver.

... snip ...

i've noticed this sort of thing before -- submenus containing entries
that don't actually depend on the top-level config variable.  but
which drivers are you talking about here?  i'm looking at the
ieee1394/Kconfig file and every entry in that submenu appears to
depend explicitly on IEEE1394.

note that that patch i submitted earlier didn't try to modify every
single sub-entry under Device Drivers -- only those for which it
seemed that the transformation wouldn't cause *any* change in
functionality.  so if there was something about ieee1394 that didn't
fit the bill, it's because i must have overlooked something.

in any event, as i mentioned earlier, i'm just trying to find a way to
make the menu entries more obvious and more easily selectable, without
having to enter each submenu to see what it represents.  it's quite
possible that a whole new kbuild directive would be useful here.  who
knows?

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] util-linux-ng

[Arkadiusz Miskiewicz]

On Monday 18 December 2006 08:52, Karel Zak wrote:
>  I'm pleased to announce a new "util-linux-ng" project. This project
>  is a fork of the original util-linux (2.13-pre7).

Fork? Are you saying that you just didn't take over maintainership and now we 
will have two versions of util-linux!? :/

> Karel

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GFS2] Fix Kconfig [2/2]

[Steven Whitehouse]

>From 1003f06953472ecc34f12d9867670f475a8c1af6 Mon Sep 17 00:00:00 2001
From: Steven Whitehouse <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 10:16:25 +
Subject: [PATCH] [GFS2] Fix Kconfig
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Here is a patch to fix up the Kconfig so that we don't land up with
problems when people disable the NET subsystem.  Thanks for all the hints and
suggestions that people have sent me regarding this.

Signed-off-by: Steven Whitehouse <[EMAIL PROTECTED]>
Cc: Aleksandr Koltsoff <[EMAIL PROTECTED]>
Cc: Toralf Förster <[EMAIL PROTECTED]>
Cc: Randy Dunlap <[EMAIL PROTECTED]>
Cc: Adrian Bunk <[EMAIL PROTECTED]>
Cc: Chris Zubrzycki <[EMAIL PROTECTED]>
Cc: Patrick Caulfield <[EMAIL PROTECTED]>
---
 fs/gfs2/Kconfig |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/fs/gfs2/Kconfig b/fs/gfs2/Kconfig
index c0791cb..6a2ffa2 100644
--- a/fs/gfs2/Kconfig
+++ b/fs/gfs2/Kconfig
@@ -34,7 +34,9 @@ config GFS2_FS_LOCKING_NOLOCK
 
 config GFS2_FS_LOCKING_DLM
tristate "GFS2 DLM locking module"
-   depends on GFS2_FS
+   depends on GFS2_FS && NET && INET && (IPV6 || IPV6=n)
+   select IP_SCTP if DLM_SCTP
+   select CONFIGFS_FS
select DLM
help
Multiple node locking module for GFS2
-- 
1.4.1



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GFS2 & DLM] Pull request

[Steven Whitehouse]

Hi,

Please consider pulling the following two compile fixes for GFS2/DLM,

Steve.

--
The following changes since commit d1998ef38a13c4e74c69df55ccd38b0440c429b2:
  Ben Collins:
ib_verbs: Use explicit if-else statements to avoid errors with do-while 
macros

are found in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes.git

Patrick Caulfield:
  [DLM] fix compile warning

Steven Whitehouse:
  [GFS2] Fix Kconfig

 fs/dlm/lowcomms-tcp.c |2 +-
 fs/gfs2/Kconfig   |4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Andrei Popa]

On Mon, 2006-12-18 at 01:38 -0800, Andrew Morton wrote: 
> On Mon, 18 Dec 2006 11:19:04 +0200
> Andrei Popa <[EMAIL PROTECTED]> wrote:
> 
> > 
> > I tried latest git with the patch from this email and it still get file
> > content corruption. If I can help you further debug the problem tell me
> > what to do.
> 
> Can you please tell us all the steps which we need to take to reproduce this?

I'm using rtorrent-0.7.0 and libtorrent-0.11.0, just download a torrent
with multiple files(I downloaded 84 rar files) and when it will finish
it will do a hash check and at the end of the check will say "Hash check
on download completion found bad chunks, consider using "safe_sync"."
and stop and most of the downloaded files are broken. With Peter
Zijlstra patch this error doesn't show but there is file
corruption(although less files are corrupted); afther the hash check,
rtorrent will download the bad chunks and do another hash check and all
files are ok.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Brendan Scott]

> It's just that I'm so damn tired of this whole thing.  I'm tired of
> people thinking they have a right to violate my copyright all the time.
> I'm tired of people and companies somehow treating our license in ways
> that are blatantly wrong and feeling fine about it.  Because we are a
> loose band of a lot of individuals, and not a company or legal entity,
> it seems to give companies the chutzpah to feel that they can get away
> with violating our license.

Why don't you consider some intermediate position?  If the issue is that you 
don't want people infringing copyright, then don't load the module unless it's 
accompanied by a [text] file in a standard format which states that the module 
is not infringing.  

So the default would be that non-GPL modules would not be loaded, but that the 
non-load could be easily circumvented by someone with a legitimate non-GPL 
module.  That would mean truly non infringing modules could be loaded.  
Moreover, anyone could still load an infringing module, but to do so would mean 
they would need to actively be either reckless or lying (even if all the fields 
are left blank) - which would not look very good when it was exposed.  It would 
also help educate those people who are bona fide, but ignorant of their 
obligations.  

The file could include (eg):
Module name: 
Version number:
License: 
I have read the statement on GPL binary modules and the kernel developers' 
views on GPL-infringement available from [address]: yes/no
I verify that I have reviewed the developer's statement above and honestly 
believe that this version of this module does not infringe copyright in the 
kernel when assessed in accordance with that statement.  I also verify that in 
making this verification I am, or am acting on behalf of, the author(s) and 
copyright owner(s) of this module : [name]
Date verified: [date]
Name of organisation: 
Contact email:


If you're interested, I'd be happy to help draft something more involved. 


Regards


Brendan  

-- 
Brendan Scott IT Law Open Source Law 
0414 339 227 http://www.opensourcelaw.biz
Liability limited by a scheme approved under Professional Standards Legislation
Open Source Law Weekly digest: [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: util-linux: orphan

[Arkadiusz Miskiewicz]

On Monday 18 December 2006 10:33, Jan Engelhardt wrote:
> > after few weeks I'm pleased to announce a new "util-linux-ng" project.
> > This project is a fork of the original util-linux (2.13-pre7).
> >
> > The goal of the project is to move util-linux code back to useful state,
> > sync with actual distributions and kernel and make development more
> > transparent end open.
>
> If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be
> the maintainer, ask if you can take over, including the name.
> This smells a lot like the RPM case [ http://lwn.net/Articles/196523/ ]
> however, it does not look like anyone is going to call it rpm-ng just
> because the original name is owned by the last maintainer.

rpm.org case is even worse. Original maintainer still develops rpm - at this 
moment version 4.4.7 at http://wraptastic.org/ (while rpm.org starts from 
older 4.4.2 codebase), there is active mailing list, so we have two running 
projects with the same name which is bad thing and will cause confusion.

I hope that there will be one util-linux and one rpm project.

> Regards,
>   -`J'

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Peter Zijlstra]

On Mon, 2006-12-18 at 12:00 +0200, Andrei Popa wrote:
> On Mon, 2006-12-18 at 01:38 -0800, Andrew Morton wrote: 
> > On Mon, 18 Dec 2006 11:19:04 +0200
> > Andrei Popa <[EMAIL PROTECTED]> wrote:
> > 
> > > 
> > > I tried latest git with the patch from this email and it still get file
> > > content corruption. If I can help you further debug the problem tell me
> > > what to do.
> > 
> > Can you please tell us all the steps which we need to take to reproduce 
> > this?
> 
> I'm using rtorrent-0.7.0 and libtorrent-0.11.0, just download a torrent
> with multiple files(I downloaded 84 rar files) and when it will finish
> it will do a hash check and at the end of the check will say "Hash check
> on download completion found bad chunks, consider using "safe_sync"."
> and stop and most of the downloaded files are broken. With Peter
> Zijlstra patch this error doesn't show but there is file
> corruption(although less files are corrupted); afther the hash check,
> rtorrent will download the bad chunks and do another hash check and all
> files are ok.

OK, I'll try this on a ext3 box. BTW, what data mode are you using ext3
in?


Also, for testings sake, could you give this a go:
It's a total hack but I guess worth testing.

---
 mm/rmap.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6-git/mm/rmap.c
===
--- linux-2.6-git.orig/mm/rmap.c2006-12-18 11:06:29.0 +0100
+++ linux-2.6-git/mm/rmap.c 2006-12-18 11:07:16.0 +0100
@@ -448,7 +448,7 @@ static int page_mkclean_one(struct page 
goto unlock;
 
entry = ptep_get_and_clear(mm, address, pte);
-   entry = pte_mkclean(entry);
+   /* entry = pte_mkclean(entry); */
entry = pte_wrprotect(entry);
ptep_establish(vma, address, pte, entry);
lazy_mmu_prot_update(entry);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: s2disk curiosity :)

[Paolo Ornati]

On Mon, 18 Dec 2006 10:36:24 +0100
Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> It depends on the BIOS. Many BIOSes have a setting where you can set the
> "power fail mode" to "on", "off" or "as before".

Ok, I've found the BIOS setting: Restore on AC Poer Loss = {Power Off,
Power On, Last State}.

Anyway I found strange that the "state" after s2disk is considered
"ON"  ;)

-- 
Paolo Ornati
Linux 2.6.20-rc1-g99f5e971 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Remove logically superfluous comparisons from Kconfig files.

[Robert P. J. Day]

  Remove Kconfig comparisons of the form FUBAR || FUBAR=n, since they
appear to be superfluous.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  based on what i read in kconfig-language.txt, it would *appear* that
those comparisons are redundant, but i'm willing to be convinced
otherwise.  (unless the developer specifically wanted the case of
"!=m", which i'm fairly sure is not the same thing, yes?)



 drivers/char/drm/Kconfig   |2 +-
 fs/dlm/Kconfig |1 -
 net/ipv4/netfilter/Kconfig |1 -
 net/sctp/Kconfig   |1 -
 4 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/char/drm/Kconfig b/drivers/char/drm/Kconfig
index ef833a1..d681e68 100644
--- a/drivers/char/drm/Kconfig
+++ b/drivers/char/drm/Kconfig
@@ -6,7 +6,7 @@
 #
 config DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
support)"
-   depends on (AGP || AGP=n) && PCI
+   depends on && PCI
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
  introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/fs/dlm/Kconfig b/fs/dlm/Kconfig
index b5654a2..7cf868a 100644
--- a/fs/dlm/Kconfig
+++ b/fs/dlm/Kconfig
@@ -3,7 +3,6 @@ menu "Distributed Lock Manager"

 config DLM
tristate "Distributed Lock Manager (DLM)"
-   depends on IPV6 || IPV6=n
select CONFIGFS_FS
select IP_SCTP if DLM_SCTP
help
diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
index f6026d4..92b1bba 100644
--- a/net/ipv4/netfilter/Kconfig
+++ b/net/ipv4/netfilter/Kconfig
@@ -78,7 +78,6 @@ config IP_NF_CONNTRACK_NETLINK
tristate 'Connection tracking netlink interface (EXPERIMENTAL)'
depends on EXPERIMENTAL && IP_NF_CONNTRACK && NETFILTER_NETLINK
depends on IP_NF_CONNTRACK!=y || NETFILTER_NETLINK!=m
-   depends on IP_NF_NAT=n || IP_NF_NAT
help
  This option enables support for a netlink-based userspace interface

diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
index 9cba49e..4edf997 100644
--- a/net/sctp/Kconfig
+++ b/net/sctp/Kconfig
@@ -7,7 +7,6 @@ menu "SCTP Configuration (EXPERIMENTAL)"

 config IP_SCTP
tristate "The SCTP Protocol (EXPERIMENTAL)"
-   depends on IPV6 || IPV6=n
select CRYPTO if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5
select CRYPTO_HMAC if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5
select CRYPTO_SHA1 if SCTP_HMAC_SHA1

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment

[David Woodhouse]

On Fri, 2006-12-15 at 14:45 -0800, Linus Torvalds wrote:
> This uses "atomic_long_t" for the workstruct "data" field, which shares 
> the per-cpu pointer and the workstruct flag bits in one field.

This fixes drivers/connector/connector.c to cope...

Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>

diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index 5e7cd45..27f377b 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -135,9 +135,8 @@ static int cn_call_callback(struct cn_msg *msg, void 
(*destruct_data)(void *), v
spin_lock_bh(&dev->cbdev->queue_lock);
list_for_each_entry(__cbq, &dev->cbdev->queue_list, callback_entry) {
if (cn_cb_equal(&__cbq->id.id, &msg->id)) {
-   if (likely(!test_bit(WORK_STRUCT_PENDING,
-&__cbq->work.work.management) &&
-   __cbq->data.ddata == NULL)) {
+   if (likely(!work_pending(&__cbq->work.work) &&
+   __cbq->data.ddata == NULL)) {
__cbq->data.callback_priv = msg;
 
__cbq->data.ddata = data;

 

-- 
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment

[Evgeniy Polyakov]

On Mon, Dec 18, 2006 at 08:56:24AM +, David Woodhouse ([EMAIL PROTECTED]) 
wrote:
> On Fri, 2006-12-15 at 14:45 -0800, Linus Torvalds wrote:
> > This uses "atomic_long_t" for the workstruct "data" field, which shares 
> > the per-cpu pointer and the workstruct flag bits in one field.
> 
> This fixes drivers/connector/connector.c to cope...
> 
> Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>

Yep, there are already four different patches to fix it.
Proper one will be pushed through David Miller's netdev tree splitted into 
fix and delayed work removal.

Thanks David.
 
> -- 
> dwmw2

-- 
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment

[David Miller]

From: David Woodhouse <[EMAIL PROTECTED]>
Date: Mon, 18 Dec 2006 08:56:24 +

> On Fri, 2006-12-15 at 14:45 -0800, Linus Torvalds wrote:
> > This uses "atomic_long_t" for the workstruct "data" field, which shares 
> > the per-cpu pointer and the workstruct flag bits in one field.
> 
> This fixes drivers/connector/connector.c to cope...
> 
> Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>

I have a fix for this already in my net-2.6 tree and I'll push it
later tonight.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] cciss: fix XFER_READ/XFER_WRITE in do_cciss_request

[Jens Axboe]

On Fri, Dec 15 2006, Mike Miller (OS Dev) wrote:
> Patch 2 of 2
> 
> This patch fixes a stupid bug. Sometime during the 2tb enhancement I ended up
> replacing the macros XFER_READ and XFER_WRITE with h->cciss_read and
> h->cciss_write respectively. It seemed to work somehow at least on x86_64 and
> ia64. I don't know how. But people started complaining about command timeouts
> on older controllers like the 64xx series and only on ia32. This resolves the
> issue reproduced in our lab. Please consider this for inclusion. 

Great, works here as well. Applied 1+2.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Nick Piggin]

Andrew Morton wrote:

On Sun, 17 Dec 2006 21:50:43 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:




On Mon, 18 Dec 2006, Nick Piggin wrote:


I can't see how that's exactly a problem -- so long as the page does not
get reclaimed (it won't, because we have a ref on it) then all that matters
is that the page eventually gets marked dirty.


But the point being that "try_to_free_buffers()" marks it clean 
AFTERWARDS.


So yes, the page gets marked dirty in the pte's - the hardware generally 
does that for us, so we don't have to worry about that part going on.


But "try_to_free_buffers()" seems to clear those dirty bits without 
serializing it really any way. It just says "ok, I will now clear them". 
Without knowing whether the dirty bits got set before the IO that cleared 
the buffer head dirty bits or not.



Yes, I can't see anything correct about the current behaviour.

But I'm going blue in the face here trying to feed try_to_free_buffers() a
page_mapped(page), without success.  pagevec_strip() presumably isn't
triggering.


I can trigger it here, with a kernel patch to call pagevec_strip
unconditionally. I am seeing it clearing pte dirty bits, which is surely
a dataloss bug.

BUG: warning at mm/page-writeback.c:862/clear_page_dirty_warn()
 [] clear_page_dirty_warn+0xdb/0xdd
 [] try_to_free_buffers+0x6b/0x7e
 [] ext3_releasepage+0x0/0x74
 [] try_to_release_page+0x2c/0x40
 [] pagevec_strip+0x52/0x54
 [] shrink_active_list+0x2a0/0x3c8
 [] shrink_zone+0xcd/0xea
 [] kswapd+0x311/0x41e
 [] autoremove_wake_function+0x0/0x37
 [] kswapd+0x0/0x41e
 [] kthread+0xde/0xe2
 [] kthread+0x0/0xe2
 [] kernel_thread_helper+0x7/0x1c
 ===

(clear_page_dirty_warn() is test_clear_page_dirty which WARN_ON()s the
result of page_mkclean)


This will (at least) cause truncate to do peculiar things. 
do_invalidatepage() runs discard_buffer() against the dirty page and will

then expect try_to_free_buffers() to remove those buffers and then clean
the page.  truncate_complete_page() will clean the page, but it still has
those invalidated buffers.  We'll end up with a large number of clean,
unused pages on the LRU, with attached buffers.  These should eventually
get reaped, but it'll change the page aging dynamics.


This isn't so nice. I wonder if you could just ClearPageDirty before
calling try_to_free_buffers in this case, or is that too much of a
hack? Ideally I guess you want a variant that is happy to discard
dirtiness (alternatively, my proposal to redirty the page if we find
a dirty pte should also handle this).

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] MAINTAINERS: fix email for S3C2410 and S3C2440

[Ben Dooks]

Change the email address for the S3C2410 and S3C2440
maintainer. The old addresses have been deleted due
to spam issues.

Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>

--- linux-2.6.20-rc1/MAINTAINERS2006-12-17 23:04:58.0 +
+++ linux-2.6.20-rc1-fix2/MAINTAINERS   2006-12-18 10:21:25.0 +
@@ -406,14 +406,14 @@ S:Maintained
 
 ARM/S3C2410 ARM ARCHITECTURE
 P: Ben Dooks
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]   (subscribers-only)
 W: http://www.fluff.org/ben/linux/
 S: Maintained
 
 ARM/S3C2440 ARM ARCHITECTURE
 P: Ben Dooks
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]   (subscribers-only)
 W: http://www.fluff.org/ben/linux/
 S: Maintained
--- linux-2.6.20-rc1/MAINTAINERS	2006-12-17 23:04:58.0 +
+++ linux-2.6.20-rc1-fix2/MAINTAINERS	2006-12-18 10:21:25.0 +
@@ -406,14 +406,14 @@ S:	Maintained
 
 ARM/S3C2410 ARM ARCHITECTURE
 P:	Ben Dooks
-M:	[EMAIL PROTECTED]
+M:	[EMAIL PROTECTED]
 L:	[EMAIL PROTECTED]	(subscribers-only)
 W:	http://www.fluff.org/ben/linux/
 S:	Maintained
 
 ARM/S3C2440 ARM ARCHITECTURE
 P:	Ben Dooks
-M:	[EMAIL PROTECTED]
+M:	[EMAIL PROTECTED]
 L:	[EMAIL PROTECTED]	(subscribers-only)
 W:	http://www.fluff.org/ben/linux/
 S:	Maintained

Re: [PATCH] Remove logically superfluous comparisons from Kconfig files.

[Russell King]

On Mon, Dec 18, 2006 at 05:14:01AM -0500, Robert P. J. Day wrote:
>   Remove Kconfig comparisons of the form FUBAR || FUBAR=n, since they
> appear to be superfluous.

config FOO
tristate 'foo'
depends on BAR || BAR=n

is not superfluous.  The allowed states for FOO with the above construct
are (assuming modules are enabled):

BAR FOO
Y   Y,M,N
M   M,N
N   Y,M,N

Also, you create some constructs such as:

depends on && PCI

which is obviously wrong.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] microcode: Fix mc_cpu_notifier section warning

[Tigran Aivazian]

Hi Jean,

Ok, your patch is correct, although I assume you realize that it does 
nothing --- both the function and the data it operates on are inside 
CONFIG_HOTPLUG_CPU and checking include/linux/init.h I see that 
__cpuinitdata is nothing in this case. E.g. msr_class_cpu_notifier in the 
msr driver isn't declared __cpuinitdata...


But to tidy up one should add __cpuinitdata as you suggest (to guard for 
the case if these two slip out of CONFIG_HOTPLUG_CPU, although they are 
meaningless if cpu hotplug support is not configured in).


Kind regards
Tigran

On Sun, 17 Dec 2006, Jean Delvare wrote:


Structure mc_cpu_notifier references a __cpuinit function, but
isn't declared __cpuinitdata itself:

WARNING: arch/i386/kernel/microcode.o - Section mismatch: reference
to .init.text: from .data after 'mc_cpu_notifier' (at offset 0x118)

Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
---
arch/i386/kernel/microcode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.20-rc1.orig/arch/i386/kernel/microcode.c  2006-12-15 
09:05:20.0 +0100
+++ linux-2.6.20-rc1/arch/i386/kernel/microcode.c   2006-12-17 
15:23:40.0 +0100
@@ -722,7 +722,7 @@
return NOTIFY_OK;
}

-static struct notifier_block mc_cpu_notifier = {
+static struct notifier_block __cpuinitdata mc_cpu_notifier = {
.notifier_call = mc_cpu_callback,
};



--
Jean Delvare


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

[Catalin Marinas]

On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:


* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> I could also use a simple allocator based on alloc_pages since
> kmemleak doesn't track pages. [...]

actually, i'm quite sure we want to track pages later on too, any reason
why kmemleak shouldnt cover them?


It could track them but I'm not sure how efficient it would be since
you have different ways to get the page addresses like pfn, struct
page. The pfn would actually introduce a lot of false negatives.

This needs some investigation and it can probably be done but I'll
first focus on the slab allocator.


> [...] It could be so simple that it would never need to free any
> pages, just grow the size as required and reuse the freed memleak
> objects from a list.

sounds good to me. Please make it a per-CPU pool.


Isn't there a risk for the pools to become imbalanced? A lot of
allocations would initially happen on the first CPU.


[...] (Add a memleak_object->cpu pointer so that freeing can be
done on any other CPU as well.)


We could add the freed objects to the CPU pool where they were freed
and not use a memleak_object->cpu pointer.


We'll have to fix the
locking too, to be per-CPU - memleak_lock is quite a scalability problem
right now.


The memleak_lock is indeed too coarse (but it was easier to track the
locking dependencies). With a new allocator, however, I could do a
finer grain locking. It probably still needs a (rw)lock for the hash
table. Having per-CPU hash tables is inefficient as we would have to
look up all the tables at every freeing or scanning for the
corresponding memleak_object.

There is a global object_list as well covered by memleak_lock (only
for insertions/deletions as traversing is RCU). Since modifications to
this list happen at the same time with the hash table modifications,
the memleak_lock is held anyway so we probably don't need to do
per-CPU object lists (they would also need some locking if freeing
would happen on a different CPU). List insertion/deletion is very
small compared to the hash-table look-up and it wouldn't introduce a
scalability problem.

--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules

[Eric W. Biederman]

Jan Engelhardt <[EMAIL PROTECTED]> writes:

> On Dec 14 2006 09:52, Chris Wedgwood wrote:
>>On Thu, Dec 14, 2006 at 05:38:27PM +, Christoph Hellwig wrote:
>>
>>> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
>>
>>A quick grep shows that changing this now would require updating
>>nearly 1900 instances, so patches to do this would be pretty large and
>>disruptive (though we could support both during a transition and
>>migrate them over time).
>
> I'd prefer to do it at once. But that's not my decision so you anyway do what
> you want.
>
> That said, I would like to keep EXPORT_SYMBOL_GPL, because EXPORT and INTERNAL
> is somehow contrary. Just a wording issue.

I would suggest that we make the prefix MODULE and not EXPORT.  It
more accurately conveys what we are trying to say, and it doesn't
have the conflicting problem with INTERNAL.

I don't know if it is actually worth doing a great rename for such
a simple clarification in language.  But it is worth considering
because it would more strongly convey that we don't expect these
symbols to be used by everything.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] watchdog: cleanup s3c2410_wdt probe and release

[Ben Dooks]

Cleanup the s3c2410_wdt driver's exit point by
using labels instead of multiple returns. Also
remove the checks for the resources having been
allocate in the exit, as we will now either have
fully allocated or not allocated the resources
at-all.

Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>

diff -urpN -X ../dontdiff linux-2.6.20-rc1/drivers/char/watchdog/s3c2410_wdt.c 
linux-2.6.20-rc1-fix2/drivers/char/watchdog/s3c2410_wdt.c
--- linux-2.6.20-rc1/drivers/char/watchdog/s3c2410_wdt.c2006-11-29 
21:57:37.0 +
+++ linux-2.6.20-rc1-fix2/drivers/char/watchdog/s3c2410_wdt.c   2006-12-18 
10:26:55.0 +
@@ -366,13 +366,15 @@ static int s3c2410wdt_probe(struct platf
wdt_mem = request_mem_region(res->start, size, pdev->name);
if (wdt_mem == NULL) {
printk(KERN_INFO PFX "failed to get memory region\n");
-   return -ENOENT;
+   ret = -ENOENT;
+   goto err_req;
}
 
wdt_base = ioremap(res->start, size);
if (wdt_base == 0) {
printk(KERN_INFO PFX "failed to ioremap() region\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err_req;
}
 
DBG("probe: mapped wdt_base=%p\n", wdt_base);
@@ -380,22 +382,21 @@ static int s3c2410wdt_probe(struct platf
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (res == NULL) {
printk(KERN_INFO PFX "failed to get irq resource\n");
-   iounmap(wdt_base);
-   return -ENOENT;
+   ret = -ENOENT;
+   goto err_map;
}
 
ret = request_irq(res->start, s3c2410wdt_irq, 0, pdev->name, pdev);
if (ret != 0) {
printk(KERN_INFO PFX "failed to install irq (%d)\n", ret);
-   iounmap(wdt_base);
-   return ret;
+   goto err_map;
}
 
wdt_clock = clk_get(&pdev->dev, "watchdog");
if (wdt_clock == NULL) {
printk(KERN_INFO PFX "failed to find watchdog clock source\n");
-   iounmap(wdt_base);
-   return -ENOENT;
+   ret =  -ENOENT;
+   goto err_irq;
}
 
clk_enable(wdt_clock);
@@ -418,8 +419,7 @@ static int s3c2410wdt_probe(struct platf
if (ret) {
printk (KERN_ERR PFX "cannot register miscdev on minor=%d 
(%d)\n",
WATCHDOG_MINOR, ret);
-   iounmap(wdt_base);
-   return ret;
+   goto err_clk;
}
 
if (tmr_atboot && started == 0) {
@@ -434,26 +434,36 @@ static int s3c2410wdt_probe(struct platf
}
 
return 0;
+
+ err_clk:
+   clk_disable(wdt_clock);
+   clk_put(wdt_clock);
+   
+ err_irq:
+   free_irq(wdt_irq->start, pdev);
+
+ err_map:
+   iounmap(wdt_base);
+
+ err_req:
+   release_resource(wdt_mem);
+   kfree(wdt_mem);
+
+   return ret;
 }
 
 static int s3c2410wdt_remove(struct platform_device *dev)
 {
-   if (wdt_mem != NULL) {
-   release_resource(wdt_mem);
-   kfree(wdt_mem);
-   wdt_mem = NULL;
-   }
-
-   if (wdt_irq != NULL) {
-   free_irq(wdt_irq->start, dev);
-   wdt_irq = NULL;
-   }
-
-   if (wdt_clock != NULL) {
-   clk_disable(wdt_clock);
-   clk_put(wdt_clock);
-   wdt_clock = NULL;
-   }
+   release_resource(wdt_mem);
+   kfree(wdt_mem);
+   wdt_mem = NULL;
+   
+   free_irq(wdt_irq->start, dev);
+   wdt_irq = NULL;
+
+   clk_disable(wdt_clock);
+   clk_put(wdt_clock);
+   wdt_clock = NULL;
 
iounmap(wdt_base);
misc_deregister(&s3c2410wdt_miscdev);
diff -urpN -X ../dontdiff linux-2.6.20-rc1/drivers/char/watchdog/s3c2410_wdt.c linux-2.6.20-rc1-fix2/drivers/char/watchdog/s3c2410_wdt.c
--- linux-2.6.20-rc1/drivers/char/watchdog/s3c2410_wdt.c	2006-11-29 21:57:37.0 +
+++ linux-2.6.20-rc1-fix2/drivers/char/watchdog/s3c2410_wdt.c	2006-12-18 10:26:55.0 +
@@ -366,13 +366,15 @@ static int s3c2410wdt_probe(struct platf
 	wdt_mem = request_mem_region(res->start, size, pdev->name);
 	if (wdt_mem == NULL) {
 		printk(KERN_INFO PFX "failed to get memory region\n");
-		return -ENOENT;
+		ret = -ENOENT;
+		goto err_req;
 	}
 
 	wdt_base = ioremap(res->start, size);
 	if (wdt_base == 0) {
 		printk(KERN_INFO PFX "failed to ioremap() region\n");
-		return -EINVAL;
+		ret = -EINVAL;
+		goto err_req;
 	}
 
 	DBG("probe: mapped wdt_base=%p\n", wdt_base);
@@ -380,22 +382,21 @@ static int s3c2410wdt_probe(struct platf
 	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 	if (res == NULL) {
 		printk(KERN_INFO PFX "failed to get irq resource\n");
-		iounmap(wdt_base);
-		return -ENOENT;
+		ret = -ENOENT;
+		goto err_map;
 	}
 
 	ret = request_irq(res->start, s3c2410wdt_irq, 0, pdev->name, pdev);
 	if (ret != 0) {
 		printk(KERN_INFO PFX "f

Re: [PATCH] Remove logically superfluous comparisons from Kconfig files.

[Robert P. J. Day]

On Mon, 18 Dec 2006, Russell King wrote:

> On Mon, Dec 18, 2006 at 05:14:01AM -0500, Robert P. J. Day wrote:
> >   Remove Kconfig comparisons of the form FUBAR || FUBAR=n, since they
> > appear to be superfluous.
>
> config FOO
>   tristate 'foo'
>   depends on BAR || BAR=n
>
> is not superfluous.  The allowed states for FOO with the above construct
> are (assuming modules are enabled):
>
>   BAR FOO
>   Y   Y,M,N
>   M   M,N
>   N   Y,M,N

ah, ok, i get it now.

> Also, you create some constructs such as:
>
> depends on && PCI
>
> which is obviously wrong.

whoops, sorry, i didn't even notice that.

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Nick Piggin]

Andrew Morton wrote:

On Mon, 18 Dec 2006 18:22:42 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:


>>Yes I could believe it the corruption is caused by something else
>>completely.
>
>
> Think so.  We do have a problem here, but only on threaded apps, I believe.
> rtorrent doesn't appear to be threaded, and the bug is hit on non-preempt
> UP.

I think (see below) that it does not apply only to threaded apps. But
it would need one of SMP or PREEMPT to trigger.



After try_to_free_buffers detaches the buffers from the page, a
pagefault can come in, and mark the pte writeable, then set_page_dirty
(which finds no buffers, so only sets PG_dirty).

The page can now get dirtied through this mapping.

try_to_free_buffers then goes on to clean the page and ptes.



try_to_free_buffers() isn't called against a page which doesn't have
buffers.  It'll oops.


Sure. But I think the race exists... I'll try spelling it out in
the conventional way:

try_to_free_buffers()
  drop_buffers() (succeeds)

** preempt here or run right-hand thread on 2nd CPU in SMP **

   do_no_page()
 set_page_dirty()

   [now modify the page via this mapping
   (from this process or a concurrent thread)]


  clear_page_dirty() (clears PG_dirty + pte dirty, oops)


--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Andrei Popa]

> OK, I'll try this on a ext3 box. BTW, what data mode are you using ext3
> in?
> 

ordered

> 
> Also, for testings sake, could you give this a go:
> It's a total hack but I guess worth testing.
> 
> ---
>  mm/rmap.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6-git/mm/rmap.c
> ===
> --- linux-2.6-git.orig/mm/rmap.c  2006-12-18 11:06:29.0 +0100
> +++ linux-2.6-git/mm/rmap.c   2006-12-18 11:07:16.0 +0100
> @@ -448,7 +448,7 @@ static int page_mkclean_one(struct page 
>   goto unlock;
>  
>   entry = ptep_get_and_clear(mm, address, pte);
> - entry = pte_mkclean(entry);
> + /* entry = pte_mkclean(entry); */
>   entry = pte_wrprotect(entry);
>   ptep_establish(vma, address, pte, entry);
>   lazy_mmu_prot_update(entry);
> 

with latest git and this patch there is no corruption !



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: util-linux: orphan

[Matthias Koenig]

Jan Engelhardt <[EMAIL PROTECTED]> writes:
>> after few weeks I'm pleased to announce a new "util-linux-ng" project. This
>> project is a fork of the original util-linux (2.13-pre7). 
>>
>> The goal of the project is to move util-linux code back to useful state, sync
>> with actual distributions and kernel and make development more transparent 
>> end
>> open.
>
> If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be
> the maintainer, ask if you can take over, including the name.

Well, there hasn't been any response since about one month. I think the decision
to fork in this situation is reasonable. We all hope that it will be just a 
temporary fork.

Matthias

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Eric W. Biederman]

Things we can say without being hypocrites and without getting into
legal theory:

Kernel modules without source, or that don't have a GPL compatible
license are inconsiderate and rude.

Please don't be rude.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc1-git4: drivers/connector/connector.c doesn't build due to work_struct changes

[Peter Zijlstra]

On Sat, 2006-12-16 at 23:48 +0100, Alessandro Suardi wrote:
>   CC [M]  drivers/char/hangcheck-timer.o
>   CC  drivers/clocksource/acpi_pm.o
>   LD  drivers/clocksource/built-in.o
>   CC [M]  drivers/connector/cn_queue.o
>   CC [M]  drivers/connector/connector.o
> drivers/connector/connector.c: In function 'cn_call_callback':
> drivers/connector/connector.c:138: error: 'struct work_struct' has no
> member named 'management'
> drivers/connector/connector.c:138: error: 'struct work_struct' has no
> member named 'management'
> make[2]: *** [drivers/connector/connector.o] Error 1
> make[1]: *** [drivers/connector] Error 2
> make: *** [drivers] Error 2


Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---

diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index 5e7cd45..2b8893b 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -135,8 +135,7 @@ static int cn_call_callback(struct cn_ms
spin_lock_bh(&dev->cbdev->queue_lock);
list_for_each_entry(__cbq, &dev->cbdev->queue_list, callback_entry) {
if (cn_cb_equal(&__cbq->id.id, &msg->id)) {
-   if (likely(!test_bit(WORK_STRUCT_PENDING,
-&__cbq->work.work.management) &&
+   if (likely(!delayed_work_pending(&__cbq->work) &&
__cbq->data.ddata == NULL)) {
__cbq->data.callback_priv = msg;
 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GFS2] Fix Kconfig [2/2]

[Jan Engelhardt]

On Dec 18 2006 09:57, Steven Whitehouse wrote:
> config GFS2_FS_LOCKING_DLM
>   tristate "GFS2 DLM locking module"
>-  depends on GFS2_FS
>+  depends on GFS2_FS && NET && INET && (IPV6 || IPV6=n)

What is this supposed to do? IPV6 || IPV6=n is a tautology AFAICS.


-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.28: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) ?

[rrcwjpgr]

Hello,



first thanks for your great support on the Linux kernel.

I have a problem with kernel 2.4.28 and maybe somebody has an idea about my 
problem. When I type dmesg, I get this error messages:

__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

VM: killing process python



For any kind of reason a python script is killed.

What this kind of error message means?

Is this the memory killer? This would mean that maybe I have a memory leak in 
the python script?





Best regards,

saf
-- 
E-Mail sent with anti-spam site TrashMail.net!
Free disposable email addresses: http://www.trashmail.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] util-linux-ng

[Ian Kent]

On Mon, 18 Dec 2006, Arkadiusz Miskiewicz wrote:

> On Monday 18 December 2006 08:52, Karel Zak wrote:
> >  I'm pleased to announce a new "util-linux-ng" project. This project
> >  is a fork of the original util-linux (2.13-pre7).
> 
> Fork? Are you saying that you just didn't take over maintainership and now we 
> will have two versions of util-linux!? :/
> 

We tried, believe me, but couldn't get agreement (or a response from 
current maintainer).

Ian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GFS2] Fix Kconfig [2/2]

[Steven Whitehouse]

Hi,

On Mon, 2006-12-18 at 11:50 +0100, Jan Engelhardt wrote:
> On Dec 18 2006 09:57, Steven Whitehouse wrote:
> > config GFS2_FS_LOCKING_DLM
> > tristate "GFS2 DLM locking module"
> >-depends on GFS2_FS
> >+depends on GFS2_FS && NET && INET && (IPV6 || IPV6=n)
> 
> What is this supposed to do? IPV6 || IPV6=n is a tautology AFAICS.
> 
> 
>   -`J'

It looks odd, I'll grant you, but see the thread entitled "Re: [PATCH]
Remove logically superfluous comparisons from Kconfig files." and the
answer that Russell King has just given on the same subject where he
says:

>config FOO
>tristate 'foo'
>depends on BAR || BAR=n
>
>is not superfluous.  The allowed states for FOO with the above
>construct are (assuming modules are enabled):
>
>BAR FOO
>Y   Y,M,N
>M   M,N
>N   Y,M,N

which hopefully explains it a bit better,

Steve.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GFS2] Fix Kconfig [2/2]

[Robert P. J. Day]

On Mon, 18 Dec 2006, Jan Engelhardt wrote:

>
> On Dec 18 2006 09:57, Steven Whitehouse wrote:
> > config GFS2_FS_LOCKING_DLM
> > tristate "GFS2 DLM locking module"
> >-depends on GFS2_FS
> >+depends on GFS2_FS && NET && INET && (IPV6 || IPV6=n)
>
> What is this supposed to do? IPV6 || IPV6=n is a tautology AFAICS.

no, we just went through that and russell king is correct -- see the
brief series of posts from earlier this morning during which i made a
fool of myself.  :-P

although, it *is* curious that there appear to be only four places in
the entire source tree that incorporate that type of logical check.
i'm still trying to wrap my head around the rationale for that
particular combination, since it does seem to be rather infrequent and
(at least for me) a little non-intuitive.

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

[Ingo Molnar]

* Catalin Marinas <[EMAIL PROTECTED]> wrote:

> >> [...] It could be so simple that it would never need to free any
> >> pages, just grow the size as required and reuse the freed memleak
> >> objects from a list.
> >
> >sounds good to me. Please make it a per-CPU pool.
> 
> Isn't there a risk for the pools to become imbalanced? A lot of 
> allocations would initially happen on the first CPU.

hm, what's the problem with imbalance? These are trees and imbalance 
isnt a big issue.

> >[...] (Add a memleak_object->cpu pointer so that freeing can be done 
> >on any other CPU as well.)
> 
> We could add the freed objects to the CPU pool where they were freed 
> and not use a memleak_object->cpu pointer.

i mean totally per-CPU locking and per-CPU radix trees, etc.

> > We'll have to fix the locking too, to be per-CPU - memleak_lock is 
> > quite a scalability problem right now.
> 
> The memleak_lock is indeed too coarse (but it was easier to track the 
> locking dependencies). With a new allocator, however, I could do a 
> finer grain locking. It probably still needs a (rw)lock for the hash 
> table. Having per-CPU hash tables is inefficient as we would have to 
> look up all the tables at every freeing or scanning for the 
> corresponding memleak_object.

at freeing we only have to look up the tree belonging to object->cpu. 
Scanning overhead does not matter in comparison to runtime tracking 
overhead. (but i doubt it would be much different - scanning overhead 
scales with size of tree)

> There is a global object_list as well covered by memleak_lock (only 
> for insertions/deletions as traversing is RCU). [...]

yeah, that would have to become per-CPU too.

> [...] List insertion/deletion is very small compared to the hash-table 
> look-up and it wouldn't introduce a scalability problem.

it's a common misconception to think that 'small' critical sections are 
fine. That's not the issue. The pure fact of having globally modified 
resource is the problem, the lock cacheline would ping-pong, etc.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: amd64 agpgart aperture base value

[Eric W. Biederman]

Dave Jones <[EMAIL PROTECTED]> writes:

> On Thu, Dec 14, 2006 at 06:35:30PM -0500, Daniel Drake wrote:
>
>  > So, you think that the aperture moving to a different location on every 
>  > boot is what the BIOS desires? Is it normal for it to move so much?
>
> Beats me. I gave up trying to understand BIOS authors motivations years ago.
>
>  > The current patch drops the upper bits and results in the aperture 
>  > always being in the same place, and this appears to work. If the BIOS 
>  > did really put the aperture beyond 4GB but my patch is making Linux put 
>  > it somewhere else, does it surprise you that things are still working 
>  > smoothly?
>
> Does it survive a run of testgart when masking out the high bits?
> It could be that you're right, and the upper bits being reported really
> are garbage.
>
>  > Is it even possible for the aperture to start beyond 4GB when the system 
>  > has less than 4GB of RAM?
>
> The amount of RAM is irrelevant, it can appear anywhere in the address space,
> which on 64bit, is pretty darned huge.  The aperture isn't backed by RAM,
> it's a 'virtual window' of sorts. When you write to an address in that range, 
> it
> gets transparently remapped to somewhere else in the address space.
> The window is the 'aperture', where it remaps to is controlled by a 
> translation
> table called the GATT (which does live in real memory).
>
> That's pretty much all there is to AGP. It's just a really dumb MMU of sorts.

Well I just took a quick look, and it looks like there is a bug in amd64-agp.c
It isn't masking off the reserved high bits of the register at 0x94, and it
isn't being very careful with the promotion to 64bits.

However that does not appear to be the problem, as the base addresses you are
seeing are only seeing 40 bits long, and you are fixing it in the register
before the code in amd64-agp.c runs.

So I do agree that it appears that the BIOS is letting the upper address bits
float, and giving you a 32bit value.

Fixing this with a board specific pci quirk is questionable but it may
be ok.  A reliable fix is probably if the address is sufficiently questionable
to allocate a new aperture ourselves, and scream that the BIOS messed up.
arch/x86_64/kernel/aperture.c appears to do that when we use the agp aperture
for an iommu.

I don't think a agp aperture above 64bits is actually very interesting,
in practice as most agp cards are only 32bits so won't be able to use it.
And we are talking bus addresses here.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux disk performance.

[Arjan van de Ven]

> 
> Can we achieve smooth write times in Linux?

if you want truely really smooth writes you'll have to work for it,
since "bumpy" writes tend to be better for performance so naturally the
kernel will favor those.

to get smooth writes you'll need to do a threaded setup where you do an
msync/fdatasync/sync_file_range on a frequent-but-regular interval from
a thread. Be aware that this is quite likely to give you lower maximum
performance than the batching behavior though.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] lockdep: returns after DEBUG_LOCKS_WARN_ONs etc.

[Jarek Poplawski]

Hello,

If any of this proposals should be omitted or separated
let me know. 

Regards,
Jarek P.

---
[PATCH] lockdep: returns after DEBUG_LOCKS_WARN_ONs etc. 

lockdep.c changes:

- returns after DEBUG_LOCKS_WARN_ON added in 3 places

- debug_locks checking after lookup_chain_cache()
  added in __lock_acquire()

- locking for testing and changing global variable
  max_lockdep_depth added in __lock_acquire()

- local_irq_save/restore() replaced by raw versions
  in debug_check_no_locks_freed()

Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---

diff -Nurp linux-2.6.20-rc1-/kernel/lockdep.c linux-2.6.20-rc1/kernel/lockdep.c
--- linux-2.6.20-rc1-/kernel/lockdep.c  2006-12-18 08:59:24.0 +0100
+++ linux-2.6.20-rc1/kernel/lockdep.c   2006-12-18 11:57:40.0 +0100
@@ -1293,7 +1293,8 @@ out_unlock_set:
if (!subclass || force)
lock->class_cache = class;
 
-   DEBUG_LOCKS_WARN_ON(class->subclass != subclass);
+   if (DEBUG_LOCKS_WARN_ON(class->subclass != subclass))
+   return NULL;
 
return class;
 }
@@ -1308,7 +1309,8 @@ static inline int lookup_chain_cache(u64
struct list_head *hash_head = chainhashentry(chain_key);
struct lock_chain *chain;
 
-   DEBUG_LOCKS_WARN_ON(!irqs_disabled());
+   if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
+   return 0;
/*
 * We can walk it lock-free, because entries only get added
 * to the hash:
@@ -1390,7 +1392,9 @@ static void check_chain_key(struct task_
return;
}
id = hlock->class - lock_classes;
-   DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS);
+   if (DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS))
+   return;
+
if (prev_hlock && (prev_hlock->irq_context !=
hlock->irq_context))
chain_key = 0;
@@ -2201,7 +2205,11 @@ out_calc_hash:
if (!check_prevs_add(curr, hlock))
return 0;
graph_unlock();
-   }
+
+   } else if (unlikely(!debug_locks))
+   /* after lookup_chain_cache() */
+   return 0;
+
curr->lockdep_depth++;
check_chain_key(curr);
if (unlikely(curr->lockdep_depth >= MAX_LOCK_DEPTH)) {
@@ -2210,9 +2218,14 @@ out_calc_hash:
printk("turning off the locking correctness validator.\n");
return 0;
}
+
+   if (!graph_lock())
+   return 0;
+
if (unlikely(curr->lockdep_depth > max_lockdep_depth))
max_lockdep_depth = curr->lockdep_depth;
 
+   graph_unlock();
return 1;
 }
 
@@ -2665,7 +2678,7 @@ void debug_check_no_locks_freed(const vo
if (unlikely(!debug_locks))
return;
 
-   local_irq_save(flags);
+   raw_local_irq_save(flags);
for (i = 0; i < curr->lockdep_depth; i++) {
hlock = curr->held_locks + i;
 
@@ -2679,7 +2692,7 @@ void debug_check_no_locks_freed(const vo
print_freed_lock_bug(curr, mem_from, mem_to, hlock);
break;
}
-   local_irq_restore(flags);
+   raw_local_irq_restore(flags);
 }
 EXPORT_SYMBOL_GPL(debug_check_no_locks_freed);
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

OOPS: divide error while s2dsk (2.6.20-rc1-mm1)

[Jiri Slaby]

Hi.

I got this oops while suspending:
[  309.366557] Disabling non-boot CPUs ...
[  309.386563] CPU 1 is now offline
[  309.387625] CPU1 is down
[  309.387704] Stopping tasks ... done.
[  310.030991] Shrinking memory... -<0>divide error:  [#1]
[  310.456669] SMP
[  310.456814] last sysfs file:
/devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions
[  310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 cdrom
[  310.457259] CPU:0
[  310.457260] EIP:0060:[]Not tainted VLI
[  310.457261] EFLAGS: 00210246   (2.6.20-rc1-mm1 #207)
[  310.457478] EIP is at shrink_slab+0x9e/0x169
[  310.457548] eax:    ebx:    ecx:    edx: 
[  310.457623] esi:    edi: c18fe500   ebp: f7b3fe3c   esp: f7b3fe08
[  310.457696] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[  310.457772] Process swsusp (pid: 3243, ti=f7b3e000 task=f756f030
task.ti=f7b3e000)
[  310.457845] Stack: c175d8a0 c175daa0 c175db00   c053cec0
45ec 00d0
[  310.458286]  1179 1179  f7b3fe94
c0151445 0001
[  310.458723]f7b3fe64 1df1 0002 0001 0001 00038000
0c79 117b
[  310.459199] Call Trace:
[  310.459334]  [] show_trace_log_lvl+0x1a/0x30
[  310.459450]  [] show_stack_log_lvl+0xa5/0xca
[  310.459562]  [] show_registers+0x1d3/0x2b8
[  310.459673]  [] die+0x121/0x243
[  310.459781]  [] do_trap+0x76/0x9c
[  310.459892]  [] do_divide_error+0x94/0x9e
[  310.460001]  [] error_code+0x7c/0x84
[  310.460113]  [] shrink_all_memory+0x211/0x2eb
[  310.460225]  [] swsusp_shrink_memory+0x187/0x196
[  310.460335]  [] prepare_processes+0x35/0xc8
[  310.460446]  [] pm_suspend_disk+0xd/0x16f
[  310.460558]  [] enter_state+0x129/0x19b
[  310.460668]  [] state_store+0xa3/0xac
[  310.460777]  [] subsys_attr_store+0x20/0x25
[  310.460889]  [] sysfs_write_file+0x97/0xd8
[  310.460998]  [] vfs_write+0x8b/0x149
[  310.461108]  [] sys_write+0x3d/0x64
[  310.461216]  [] syscall_call+0x7/0xb
[  310.461328]  ===
[  310.461397] Code: 31 c0 ff 17 89 c3 8b 45 e4 31 d2 f7 77 0c f7 e3 89 45 d8 89
55 dc 89 d1 89 c6 31 d2 85 c9 74 09 89 c8 31 d2 f7 75 f0 89 c1 89 f0  75 f0
89 ca 89 45 d8 89 55 dc 8b 45 d8 03 47 10 89 47 10 85
[  310.464079] EIP: [] shrink_slab+0x9e/0x169 SS:ESP 0068:f7b3fe08
[  310.464228]

swsusp script is something like this:
echo platform > /sys/power/disk
echo disk > /sys/power/state

regards,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

[Catalin Marinas]

On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:


* Catalin Marinas <[EMAIL PROTECTED]> wrote:

> >> [...] It could be so simple that it would never need to free any
> >> pages, just grow the size as required and reuse the freed memleak
> >> objects from a list.
> >
> >sounds good to me. Please make it a per-CPU pool.
>
> Isn't there a risk for the pools to become imbalanced? A lot of
> allocations would initially happen on the first CPU.

hm, what's the problem with imbalance? These are trees and imbalance
isnt a big issue.


It could just be more available (freed) memleak_objects on one CPU
than on the others and use more memory. Not a big problem though.


> > We'll have to fix the locking too, to be per-CPU - memleak_lock is
> > quite a scalability problem right now.
>
> The memleak_lock is indeed too coarse (but it was easier to track the
> locking dependencies). With a new allocator, however, I could do a
> finer grain locking. It probably still needs a (rw)lock for the hash
> table. Having per-CPU hash tables is inefficient as we would have to
> look up all the tables at every freeing or scanning for the
> corresponding memleak_object.

at freeing we only have to look up the tree belonging to object->cpu.


At freeing, kmemleak only gets a pointer value which has to be looked
up in the hash table for the corresponding memleak_object. Only after
that, we can know memleak_object->cpu. That's why I think we only need
to have a global hash table. The hash table look-up can be RCU.

It would work with per-CPU hash tables but we still need to look-up
the other hash tables in case the freeing happened on a different CPU
(i.e. look-up the current hash table and, if it fails, look-up the
other per-CPU hashes). Freeing would need to remove the entry from the
hash table and acquire a lock but this would be per-CPU. I'm not sure
how often you get this scenario (allocation and freeing on different
CPUs) but it might introduce an overhead to the memory freeing.

Do you have a better solution here?


> There is a global object_list as well covered by memleak_lock (only
> for insertions/deletions as traversing is RCU). [...]

yeah, that would have to become per-CPU too.


That's not that difficult but, as above, we need the hash table
look-up before we find which list it is on.


> [...] List insertion/deletion is very small compared to the hash-table
> look-up and it wouldn't introduce a scalability problem.

it's a common misconception to think that 'small' critical sections are
fine. That's not the issue. The pure fact of having globally modified
resource is the problem, the lock cacheline would ping-pong, etc.


You are right but I didn't mean that small critical sections are
better, just that in case we need a critical section for the global
hash table look-up, extending this critical region with list
addition/deletion wouldn't make things any worse (than they are,
regarding scalability).

--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] remove the broken SCSI_SEAGATE driver

[Arjan van de Ven]

On Sun, 2006-12-17 at 22:18 +0100, Krzysztof Halasa wrote:
> James Bottomley <[EMAIL PROTECTED]> writes:
> 
> > One of the touted benefits of Linux is that we run on old hardware.
> > Unless the driver is demonstrably wrong (and they do become so as the
> > APIs evolve)
> 
> Sure, I expect they do - but nobody is able to check.

if a tree falls in a forest but there's nobody around to hear it, does
it make a sound?

This sort of heisenbug questions aren't solved by "nobody hears it so
lets chop down the forest to make houses out of the wood" answers...


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] IA64: virt_to_page() can be called with NULL arg

[Kirill Korotaev]

[IA64] virt_to_page() cannot be called with NULL (mainstream bug)

It does not return NULL when arg is NULL.

Signed-Off-By: Alexey Kuznetsov <[EMAIL PROTECTED]>
Signed-Off-By: Kirill Korotaev <[EMAIL PROTECTED]>

--- linus-2.6.git/include/asm-ia64/pgalloc.h.orig   2006-12-18 
14:59:09.0 +0300
+++ linus-2.6.git/include/asm-ia64/pgalloc.h2006-12-18 15:07:44.0 
+0300
@@ -137,7 +137,8 @@ pmd_populate_kernel(struct mm_struct *mm
 static inline struct page *pte_alloc_one(struct mm_struct *mm,
 unsigned long addr)
 {
-   return virt_to_page(pgtable_quicklist_alloc());
+   void *pg = pgtable_quicklist_alloc();
+   return pg ? virt_to_page(pg) : NULL;
 }
 
 static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] IA64: alignment bug in ldscript

[Kirill Korotaev]

[IA64] bug in ldscript (mainstream)

Occasionally, in mainstream number of fsys entries is even.
In OpenVZ it is odd and we get misaligned kernel image,
which does not boot.

Signed-Off-By: Alexey Kuznetsov <[EMAIL PROTECTED]>
Signed-Off-By: Kirill Korotaev <[EMAIL PROTECTED]>

diff -urp ../linux-2.6.18-vz/arch/ia64/kernel/vmlinux.lds.S 
linux-2.6.18-vz/arch/ia64/kernel/vmlinux.lds.S
--- ../linux-2.6.18-vz/arch/ia64/kernel/vmlinux.lds.S   2006-12-08 
13:34:19.0 +0300
+++ linux-2.6.18-vz/arch/ia64/kernel/vmlinux.lds.S  2006-12-13 
02:51:03.0 +0300
@@ -163,6 +163,7 @@ SECTIONS
}
 #endif
 
+  . = ALIGN(8);
__con_initcall_start = .;
   .con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET)
{ *(.con_initcall.init) }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] Add MMC Password Protection (lock/unlock) support V8: mmc_sysfs.diff

[Anderson Briglia]

ext Russell King wrote:
> On Mon, Dec 04, 2006 at 04:13:39PM -0400, Anderson Briglia wrote:
>> Implement MMC password force erase, remove password, change password,
>> unlock card and assign password operations. It uses the sysfs mechanism
>> to send commands to the MMC subsystem. 
> 
> Sorry, this is still unsuitable for mainline.

Ok. I will fix the code and send another version of this patch on the V9 series 
e-mail thread.

> 
>> Signed-off-by: Carlos Eduardo Aguiar  indt.org.br>
>> Signed-off-by: Anderson Lizardo  indt.org.br>
>> Signed-off-by: Anderson Briglia  indt.org.br>
> 
> Please use the standard format, do not obfuscate these.  The kernel
> community utterly abhors this.

Ok.
> 
>> +/*
>> + * implement MMC password functions: force erase, remove password, change
>> + * password, unlock card and assign password.
>> + */
>> +static ssize_t
>> +mmc_lockable_store(struct device *dev, struct device_attribute *att,
>> +const char *data, size_t len)
>> +{
>> +struct mmc_card *card = dev_to_mmc_card(dev);
>> +int err = 0;
> 
> Where is the check that the host can do byte-wise data transfers?

It's checked on the macro "mmc_card_lockable".

> 
>> +
>> +err = mmc_card_claim_host(card);
>> +if (err != MMC_ERR_NONE)
>> +return -EINVAL;
>> +
>> +if (!mmc_card_lockable(card))
>> +return -EINVAL;
> 
> So writing to this file with a card which is not lockable results in
> deadlocking the host.  Suggest you do as other subsystems do and have
> one exit path, and use gotos, setting the appropriate return code in a
> variable.  If everything goes via that it forces you to think about
> where you want to jump to in each case.
> 

Thanks, as said before, I'll update the code and send it again.

Best Regards,

Anderson Briglia

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux disk performance.

[Manish Regmi]

On 12/18/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:

if you want truely really smooth writes you'll have to work for it,
since "bumpy" writes tend to be better for performance so naturally the
kernel will favor those.

to get smooth writes you'll need to do a threaded setup where you do an
msync/fdatasync/sync_file_range on a frequent-but-regular interval from
a thread. Be aware that this is quite likely to give you lower maximum
performance than the batching behavior though.



Thanks...

But isn't O_DIRECT supposed to bypass buffering in Kernel?
Doesn't it directly write to disk?
I tried to put fdatasync() at regular intervals but there was no
visible effect.

--
---
regards
Manish Regmi

---
UNIX without a C Compiler is like eating Spaghetti with your mouth
sewn shut. It just doesn't make sense.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

State of Serial Attached SCSI in linux?

[Maciej Sołtysiak]

Hello,

I am choosing hardware for new servers that will run Linux hence I would
like to ask whether current SAS support is production grade ?
Any comments on the state of the thing?

Best regards,
Maciej

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Detecting disk I/O errors

[Olivier Galibert]

Is there a way to know if there has been I/O error(s) on a specific
disk or partition since boot other than parsing dmesg and hoping it's
both still there and in the expected format?

Of course that's if the error didn't kill the system in the first
place :-)

  OG.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux disk performance.

[Nick Piggin]

Manish Regmi wrote:

On 12/18/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:


if you want truely really smooth writes you'll have to work for it,
since "bumpy" writes tend to be better for performance so naturally the
kernel will favor those.

to get smooth writes you'll need to do a threaded setup where you do an
msync/fdatasync/sync_file_range on a frequent-but-regular interval from
a thread. Be aware that this is quite likely to give you lower maximum
performance than the batching behavior though.



Thanks...

But isn't O_DIRECT supposed to bypass buffering in Kernel?
Doesn't it directly write to disk?
I tried to put fdatasync() at regular intervals but there was no
visible effect.



I don't know exactly how to interpret the numbers you gave, but
they look like they might be a (HZ quantised) delay coming from
block layer plugging.

O_DIRECT bypasses caching, but not (all) buffering.

Not sure whether the block layer can handle an unplug_delay set
to 0, but that might be something to try (see block/ll_rw_blk.c).

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] kill_something_info: misc cleanups

[Eric W. Biederman]

Oleg Nesterov <[EMAIL PROTECTED]> writes:

> On 12/17, Eric W. Biederman wrote:
>>
>> I am sitting here wondering why we bother to ignore init, as init
>> is protected from all signals it doesn't explicitly setup a signal
>> handler for.
>> ...
>>   So I believe we can delete we can delete
>> the is_init check entirely without changing anything and with a less
>> surprising if anyone ever cares.
>
> is_init() is very cheap. But if we send a signal and it is not ignored
> we will wake up /sbin/init without good reason, just to complete unneded
> do_signal(). 

kill(-1, SIGXXX) is sufficiently expensive and rare that waking up an
additional process doesn't matter.

> Also, we may have a special setup so that this signal really
> means something for init (and it has a handler for). In that case the
> caller of kill(-1, sig) will be surprised.

If it exists sure.  My quick glance suggested that nothing in user
space cares.  My thinking about it suggests that have a different
rule for ignoring signals for kill(-1,..) and every other kill
function is confusing.  So we may be doing the wrong thing.

> Btw, de_thread() already takes care about multithread init, but
> get_signal_to_deliver() does not:
>
>   if (current == child_reaper(current))
>   continue;

Yep.  That looks like something that needs to be fixed.  Looks like
I missed it when I realized multi-threaded init was a problem.
Probably just: current->group_leader == child_reaper(current).

Hmm.  If the code already has a child_reaper(current) tests in the
signal delivery that is probably the idiom we should use to start
with to detect init for signal handling purposes.

Hmm.  I don't like that test there at all.  I think this is quite
likely something I got wrong the first time through.

The desired action is: kill(1, SIGKILL) is ignored, kill(75, SIGKILL)
is delivered, even if both of those refer to the same process
the difference being in perspective which pid namespace we are
coming from.

Can we do the ignore in send_signal?

I definitely need to look at signal deliver more.

>   // handle sig_kernel_stop()/sig_fatal()
>
> This doesn't protect init from SIGKILL if we send it to sub-thread (and
> this can happen even if we use kill(1, sig), not tkill). Yes, the main
> thread will survive, but still this is not what we want. SIGSTOP will
> manage to stop entire group because sub-thread sets ->group_stop_count.

Yep.  We need to fix this.  It doesn't happen today because we don't
have a multi-threaded init.  But as soon as untrusted users can have
their own init this becomes we need to handle everything properly.

>> > Christoph Hellwig <[EMAIL PROTECTED]> writes:
>> >
>> > This also looks rather unreadable, an
>> >
>> >   } else if (pid) {
>> >   ret = kill_pgrp_info(sig, info, find_pid(-pid));
>> >   } else {
>> >   ret = kill_pgrp_info(sig, info, task_pgrp(current));
>> >   }
>> >
>> > might be slightly more code, but also a lot more readable.
>
> I personally disagree, but this is matter of taste.
>
> Ok, it was a cleanup only, let's forget it.
>
> Still I don't like "p->pid > 1" check. And I don't think we need a new
> helper (pid_leader or such) now. When we have multiple pid namespaces
> we should rework kill(-1, sig) anyway. Right now this check means
> "skip init", nothing more.

We need two specific helpers.
1) To detect the real machine init and the special things we have to
   do for it.
2) To detect the init of a pid namespace for user visible semantic
   purposes like signal handling (is there anything else).

I really don't care much about them so long as they are separate
functions.  The reason I care is that we are in the middle of
implementing the pid namespace.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IO-APIC + timer doesn't work (was: Linux 2.6.20-rc1)

[Eric W. Biederman]

Tobias Diedrich <[EMAIL PROTECTED]> writes:

> Linus Torvalds wrote:
>
>> Your dmesg is kind of interesting:
>> 
>> ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on CPU0:
> 04(40)
>>  .. failed
>> 
>> where that APIC error on CPU0 seems to be a "Send accept error" and "Send 
>> illegal vector" thing. I think we actually got the interrupt there, but 
>> because we had some APIC setup bug, we didn't accept it properly, and it 
>> resulted in that "APIC error" thing. Maybe. 
>
> I just tried changing the code so the "8259 IRQ0 enabled" case is
> tested first and with that it boots fine.

Could you try removing the clear_IO_APIC_pin from try_io_apic_pin.

This isn't a complete fix but I believe for your hardware it will
fix the problem and it points at what the real fix is.  

Not properly programming the io_apic for the case we want to test.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux disk performance.

[Erik Mouw]

On Mon, Dec 18, 2006 at 06:24:39PM +0545, Manish Regmi wrote:
> On 12/18/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> >if you want truely really smooth writes you'll have to work for it,
> >since "bumpy" writes tend to be better for performance so naturally the
> >kernel will favor those.
> >
> >to get smooth writes you'll need to do a threaded setup where you do an
> >msync/fdatasync/sync_file_range on a frequent-but-regular interval from
> >a thread. Be aware that this is quite likely to give you lower maximum
> >performance than the batching behavior though.
> >
> 
> Thanks...
> 
> But isn't O_DIRECT supposed to bypass buffering in Kernel?

It is.

> Doesn't it directly write to disk?

Yes, but it still uses an IO scheduler.

> I tried to put fdatasync() at regular intervals but there was no
> visible effect.

In your first message you mentioned you were using an ancient 2.6.10
kernel. That kernel uses the anticipatory IO scheduler. Update to the
latest stable kernel (2.6.19.1 at time of writing) and it will default
to the CFQ scheduler which has a smoother writeout, plus you can give
your process a different IO scheduling class and level (see
Documentation/block/ioprio.txt).


Erik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] kill pxa2xx Kconfig warning

[Frederik Deweerdt]

On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
>   
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>  git-alsa.patch
Hi,

The following patch silences the following Kconfig warning:
scripts/kconfig/conf -s arch/i386/Kconfig
sound/soc/pxa/Kconfig:18:warning: 'select' used by config symbol 
'SND_PXA2XX_SOC_AC97' refer to undefined symbol 'SND_AC97_BUS'

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>


diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index a07598c..579e1c8 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -15,7 +15,7 @@ config SND_PXA2XX_AC97
 
 config SND_PXA2XX_SOC_AC97
tristate
-   select SND_AC97_BUS
+   select AC97_BUS
select SND_SOC_AC97_BUS
 
 config SND_PXA2XX_SOC_I2S
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Detecting disk I/O errors

[Erik Mouw]

On Mon, Dec 18, 2006 at 02:05:41PM +0100, Olivier Galibert wrote:
> Is there a way to know if there has been I/O error(s) on a specific
> disk or partition since boot other than parsing dmesg and hoping it's
> both still there and in the expected format?

Use smartctl. It can be started in a monitor mode.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fwd: escape key]

[Stephen Clark]

James Cloos wrote:


"Jan" == Jan Engelhardt <[EMAIL PROTECTED]> writes:
   



Jan> HOWEVER, unix people probably _had a reason_ to make ESC generate
Jan> part of what function keys do.

You are looking at it backwards.  The Escape key generates an ASCII
escape.  The funtion keys (including the cursor keys) generate escape
sequences because the vt100 won out the title as the most ubiquitous
async serial terminal, and linux devs chose to have the console be
(mostly) vt100 compatable.  As xterm, et al had done before.

The terminals (the actual hardware) used ASCII, so it was normal to
use Escape to initiate the sequences used by the function keys.

And that concept goes back a *lot* longer than unix.  (Hmm.  I can't
remember.  Did TOPS-20 or its predecessor have glass terminals in the
day?  I did get to use a DEC paper terminal a couple of times, but
that was connected to a VMS box back in the '80s; most of the time it
sat in the corner collecting dust)

At any rate, given that Escape was used to initiate sequences sent to
the terminal for funtions such as moving the cursor around the screen,
clearing rows or cols, et al it must have only seemed natural to also
have it initiate sequences /from/ the terminal which did not fit into
standard ASCII.  That was after all Escape's purpose in the ASCII std.

If you do want to change the console's terminal emulation, a good
first step would be to check whether any existing terminal already
uses something other than Escape to initiate function key sequences,
and, if so, promote that as the alternative to vt100-esque emulation.

Finally, note that the reason vt100 was chosen for the console was to
make it more useful for users who were physically at a linux box, were
logged in on the console, and from there logged in to remote servers.
That does remain something which the console *must* support.

-JimC
 

Also ansi came along and pretty much put their blessing on what DEC had 
done and made the

escape sequences a standard.

Steve

--

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)


"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] incorrect direct io error handling

[Dmitriy Monakhov]

This patch is result of discussion started week ago here:
http://lkml.org/lkml/2006/12/11/66
changes from original patch:
 - Update wrong comments about i_mutex locking.
 - Add BUG_ON(!mutex_is_locked(..)) for non blkdev. 
 - vmtruncate call only for non blockdev
LOG:
If generic_file_direct_write() has fail (ENOSPC condition) inside 
__generic_file_aio_write_nolock() it may have instantiated
a few blocks outside i_size. And fsck will complain about wrong i_size
(ext2, ext3 and reiserfs interpret i_size and biggest block difference as 
error),
after fsck will fix error i_size will be increased to the biggest block,
but this blocks contain gurbage from previous write attempt, this is not 
information leak, but its silence file data corruption. This issue affect 
fs regardless the values of blocksize or pagesize.
We need truncate any block beyond i_size after write have failed , do in simular
generic_file_buffered_write() error path. If host is !S_ISBLK i_mutex always
held inside generic_file_aio_write_nolock() and we may safely call vmtruncate().
Some fs (XFS at least) may directly call generic_file_direct_write()with 
i_mutex not held. There is no general scenario in this case. This fs have to 
handle generic_file_direct_write() error by its own specific way (place).  

Issue was found during OpenVZ kernel testing.

Exampe:
open("mnt2/FILE3", O_WRONLY|O_CREAT|O_DIRECT, 0666) = 3
write(3, "aa"..., 4096) = -1 ENOSPC (No space left on device)

stat mnt2/FILE3
File: `mnt2/FILE3'
Size: 0   Blocks: 4  IO Block: 4096   regular empty file
>>^^ file size is less than biggest block idx
Device: 700h/1792d  Inode: 14  Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)

fsck.ext2 -f -n  mnt1/fs_img
Pass 1: Checking inodes, blocks, and sizes
Inode 14, i_size is 0, should be 2048.  Fix? no

Signed-off-by: Dmitriy Monakhov <[EMAIL PROTECTED]>
-
diff --git a/mm/filemap.c b/mm/filemap.c
index 8332c77..7c571dd 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2044,8 +2044,9 @@ generic_file_direct_write(struct kiocb *
/*
 * Sync the fs metadata but not the minor inode changes and
 * of course not the data as we did direct DMA for the IO.
-* i_mutex is held, which protects generic_osync_inode() from
-* livelocking.  AIO O_DIRECT ops attempt to sync metadata here.
+* i_mutex may not being held (XFS does this), if so some specific 
locking
+* ordering must protect generic_osync_inode() from livelocking.
+* AIO O_DIRECT ops attempt to sync metadata here.
 */
if ((written >= 0 || written == -EIOCBQUEUED) &&
((file->f_flags & O_SYNC) || IS_SYNC(inode))) {
@@ -2279,6 +2280,17 @@ __generic_file_aio_write_nolock(struct k
 
written = generic_file_direct_write(iocb, iov, &nr_segs, pos,
ppos, count, ocount);
+   /*
+* If host is not S_ISBLK generic_file_direct_write() may 
+* have instantiated a few blocks outside i_size  files
+* Trim these off again.
+*/
+   if (unlikely(written < 0) && !S_ISBLK(inode->i_mode)) {
+   loff_t isize = i_size_read(inode);
+   if (pos + count > isize)
+   vmtruncate(inode, isize);
+   }
+
if (written < 0 || written == count)
goto out;
/*
@@ -2341,6 +2353,13 @@ ssize_t generic_file_aio_write_nolock(st
ssize_t ret;
 
BUG_ON(iocb->ki_pos != pos);
+   /*
+*  generic_file_buffered_write() may be called inside 
+*  __generic_file_aio_write_nolock() even in case of
+*  O_DIRECT for non S_ISBLK files. So i_mutex must be held.
+*/
+   if (!S_ISBLK(inode->i_mode))
+   BUG_ON(!mutex_is_locked(&inode->i_mutex));
 
ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs,
&iocb->ki_pos);
@@ -2383,8 +2402,8 @@ ssize_t generic_file_aio_write(struct ki
 EXPORT_SYMBOL(generic_file_aio_write);
 
 /*
- * Called under i_mutex for writes to S_ISREG files.   Returns -EIO if 
something
- * went wrong during pagecache shootdown.
+ * May be called without i_mutex for writes to S_ISREG files. XFS does this.
+ * Returns -EIO if something went wrong during pagecache shootdown.
  */
 static ssize_t
 generic_file_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,

[patch] lockdep: also check for freed locks in kmem_cache_free()

[Ingo Molnar]

Subject: [patch] lockdep: also check for freed locks in kmem_cache_free()
From: Ingo Molnar <[EMAIL PROTECTED]>

kmem_cache_free() was missing the check for freeing held locks.

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 mm/slab.c |1 +
 1 file changed, 1 insertion(+)

Index: linux/mm/slab.c
===
--- linux.orig/mm/slab.c
+++ linux/mm/slab.c
@@ -3533,6 +3533,7 @@ void kmem_cache_free(struct kmem_cache *
BUG_ON(virt_to_cache(objp) != cachep);
 
local_irq_save(flags);
+   debug_check_no_locks_freed(objp, obj_size(cachep));
__cache_free(cachep, objp);
local_irq_restore(flags);
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add PCI class ID for firewire OHCI controllers.

[Stefan Richter]

Kristian Høgsberg wrote:
> Pull this define out of drivers/ieee1394/ohci1394.c and rename to match
> other PCI class defines.

Committed to linux1394-2.6.git.
-- 
Stefan Richter
-=-=-==- ==-- =--=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Binary Drivers

[Lennart Sorensen]

On Fri, Dec 15, 2006 at 09:59:43PM +, Alan wrote:
> 3DFx invented SLI many years ago. The SLI programming information for the
> 3DFx cards is public. Nvidia are a bit late to the party except on the PR
> front.

Well they do work differently.  3Dfx just did alternate line rendering,
while nvidia does a lot more methods of dividing the work load (many of
which are likely to be more efficient than alternate line rendering in
general).  No doubt why they picked the name SLI though.  They did also
buy out 3Dfx so I guess by that they can claim to have "invented" it. :)

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Binary Drivers

[Eric W. Biederman]

Tomas Carnecky <[EMAIL PROTECTED]> writes:

> Alexey Dobriyan wrote:
>> On Fri, Dec 15, 2006 at 09:20:58PM +, James Porter wrote:
>>> For what it's worth, I don't see any problem with binary drivers from
> hardware
>>> manufacturers.
>>
>> Binary drivers from hardware manufacturers are crap. Learn it by heart.
>>
>
> That's your personal opinion! A lot other people (including me) have had
> excellent experience with binary drivers!

Almost all software is crap.  Binary drivers are just unreviewed unfixable
crap.  Things don't get better if you encourage crap.

The practical problem with simple testing for detecting problems is that
you don't frequently test the corner cases, and corner cases are what
developers often get wrong, often make software a security hazard, and
are often what developers spend most of their time building
infrastructure for so that we can get the corner cases right.

One such corner case that causes me to run in fear of binary only
kernel drivers are times when drivers accidentally write to variables
used for something else.  Which can cause failure somewhere else
someplace a long time after it has happened.  Like driving over a
tack in the road and having your tire go flat 1000 miles later because
of a slow leak.

These are the kinds of problems you have to address if you want
everyone to have a good experience with their hardware.  These are
precisely the kinds of problems that cannot be addressed with
binary only drivers.


We have a process that has worked for centuries to improve our
knowledge base.  The scientific method and peer review.  We use a
variation of this proven process for writing software in linux.  The
binary only vendors are being rude and refusing to participate. 

Do you understand why we have no sympathy for their efforts, no desire
to make their lives easier.

In general people doing binary only drivers are being rude.

> The day you show me that the open-source driver is faster and more stable then
> the binary driver, I'll switch. But until then I'll stay with my binary
> driver. I haven't had any serious problems with it, in fact, I'm very happy, 
> so
> why should I want to switch?

Oh.  So you have had problems with it.   The goal for system software
is quality so high you can not find problems with it.  That doesn't
always happen but we try.  The fact you have minor problems indicates
there are problems in the driver, and which probably means that
it is indeed crap.

Anytime an end user has to be aware of drivers and not the problem
at hand it is a problem.

> I don't see Linux in such a political way like some of you do, for me Linux is
> just like any other OS. There are good drivers and bad drivers. And I don't 
> care
> if they are open source or binary, I don't judge them based on that, but based
> on how well they work and how good the support is.

A very reasonable attitude.  But a binary driver is an automatic
negative on the support side.  It fundamentally reduces the number and
quality of the people who can support you.  The developers are not
being cooperative with other developers so the system as a whole
cannot improve to support it better.


Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] lockdep: more unlock-on-error fixes

[Ingo Molnar]

* Jarek Poplawski <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> If any of this proposals should be omitted or separated let me know.

thanks for the fixes, they look good to me. I have reorganized the 
__lock_acquire() changes a bit. Plus i dropped the check_locks_freed() 
changes: there's no reason lockdep should be using 'raw' irq flags 
saving - these functions are not part of the irq-flags tracing code so 
they dont /need/ to be raw.

An updated patch is below. I also have boot tested it. Andrew, Linus, 
please apply.

Ingo

->
Subject: [patch] lockdep: more unlock-on-error fixes
From: Jarek Poplawski <[EMAIL PROTECTED]>

- returns after DEBUG_LOCKS_WARN_ON added in 3 places

- debug_locks checking after lookup_chain_cache()
  added in __lock_acquire()

- locking for testing and changing global variable
  max_lockdep_depth added in __lock_acquire()

Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 kernel/lockdep.c |   25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

Index: linux/kernel/lockdep.c
===
--- linux.orig/kernel/lockdep.c
+++ linux/kernel/lockdep.c
@@ -1297,7 +1297,8 @@ out_unlock_set:
if (!subclass || force)
lock->class_cache = class;
 
-   DEBUG_LOCKS_WARN_ON(class->subclass != subclass);
+   if (DEBUG_LOCKS_WARN_ON(class->subclass != subclass))
+   return NULL;
 
return class;
 }
@@ -1312,7 +1313,8 @@ static inline int lookup_chain_cache(u64
struct list_head *hash_head = chainhashentry(chain_key);
struct lock_chain *chain;
 
-   DEBUG_LOCKS_WARN_ON(!irqs_disabled());
+   if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
+   return 0;
/*
 * We can walk it lock-free, because entries only get added
 * to the hash:
@@ -1394,7 +1396,9 @@ static void check_chain_key(struct task_
return;
}
id = hlock->class - lock_classes;
-   DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS);
+   if (DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS))
+   return;
+
if (prev_hlock && (prev_hlock->irq_context !=
hlock->irq_context))
chain_key = 0;
@@ -2210,19 +2214,24 @@ out_calc_hash:
if (!chain_head && ret != 2)
if (!check_prevs_add(curr, hlock))
return 0;
-   graph_unlock();
-   }
+   } else
+   /* after lookup_chain_cache(): */
+   if (unlikely(!debug_locks))
+   return 0;
+
curr->lockdep_depth++;
check_chain_key(curr);
if (unlikely(curr->lockdep_depth >= MAX_LOCK_DEPTH)) {
-   debug_locks_off();
+   debug_locks_off_graph_unlock();
printk("BUG: MAX_LOCK_DEPTH too low!\n");
printk("turning off the locking correctness validator.\n");
return 0;
}
+
if (unlikely(curr->lockdep_depth > max_lockdep_depth))
max_lockdep_depth = curr->lockdep_depth;
 
+   graph_unlock();
return 1;
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: util-linux: orphan

[Karel Zak]

On Mon, Dec 18, 2006 at 10:33:33AM +0100, Jan Engelhardt wrote:
> 
> > after few weeks I'm pleased to announce a new "util-linux-ng" project. This
> > project is a fork of the original util-linux (2.13-pre7). 
> >
> > The goal of the project is to move util-linux code back to useful state, 
> > sync
> > with actual distributions and kernel and make development more transparent 
> > end
> > open.
> 
> If Adrian [ http://lkml.org/lkml/2006/11/9/262 ] does not want to be
> the maintainer, ask if you can take over, including the name.

On Mon, Dec 18, 2006 at 10:55:05AM +0100, Arkadiusz Miskiewicz wrote:
> On Monday 18 December 2006 08:52, Karel Zak wrote:
> >  I'm pleased to announce a new "util-linux-ng" project. This project
> >  is a fork of the original util-linux (2.13-pre7).
> 
> Fork? Are you saying that you just didn't take over maintainership and now we 
> will have two versions of util-linux!? :/

 People around util-linux-ng are not so naive ;-)
 
 We spent last month with discussion about a way how (non-)fork this
 project. We made decision that a fork is the right way, because
 Adrian Bunk completely ignores __everyone__ who wants to talk with
 him about utils-linux.

 A fork is nothing attractive, but it's also a way how improve things
 in Open Source world.

 The goal is not only improve source code, but also a way how this
 project is maintained (mailing list, discussion about changes, git,
 transparent development, ...).

Karel

-- 
 Karel Zak  <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Stefan Richter]

Robert P. J. Day wrote:
> On Sat, 16 Dec 2006, Stefan Richter wrote:
>> Works for me, but I don't see a lot of benefit from it. Actually I see
>> two disadvantages of the patch:
> 
> ... snip ...
> 
>>  - There are two out-of-tree FireWire drivers for special purposes
^^^
>> (one bus sniffer, one remote debugging aid) which might perhaps be
>> candidates for integration into mainline. These drivers do not use
>> the ieee1394 base driver.
[...]
> i've noticed this sort of thing before -- submenus containing entries
> that don't actually depend on the top-level config variable.  but
> which drivers are you talking about here?

As yet non-existent drivers. (Out-of-tree drivers.)

> i'm looking at the
> ieee1394/Kconfig file and every entry in that submenu appears to
> depend explicitly on IEEE1394.

Correct. What I described is purely hypothetical in case of
drivers/ieee1394. There surely are other submenus with actual
independent entries. But AFAIU you didn't touch such menus of course.

[...]
> in any event, as i mentioned earlier, i'm just trying to find a way to
> make the menu entries more obvious and more easily selectable, without
> having to enter each submenu to see what it represents.
[...]

Yes, this and the points you made in the other post are definitely valid.
-- 
Stefan Richter
-=-=-==- ==-- =--=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Task watchers v2

[Matt Helsley]

On Mon, 2006-12-18 at 13:44 +0800, Zhang, Yanmin wrote:
> On Thu, 2006-12-14 at 16:07 -0800, Matt Helsley wrote:
> > plain text document attachment (task-watchers-v2)
> > Associate function calls with significant events in a task's lifetime much 
> > like
> > we handle kernel and module init/exit functions. This creates a table for 
> > each
> > of the following events in the task_watchers_table ELF section:
> >
> > WATCH_TASK_INIT at the beginning of a fork/clone system call when the
> > new task struct first becomes available.
> >
> > WATCH_TASK_CLONE just before returning successfully from a fork/clone.
> >
> > WATCH_TASK_EXEC just before successfully returning from the exec
> > system call.
> >
> > WATCH_TASK_UID every time a task's real or effective user id changes.
> >
> > WATCH_TASK_GID every time a task's real or effective group id changes.
> >
> > WATCH_TASK_EXIT at the beginning of do_exit when a task is exiting
> > for any reason.
> >
> > WATCH_TASK_FREE is called before critical task structures like
> > the mm_struct become inaccessible and the task is subsequently freed.
> >
> > The next patch will add a debugfs interface for measuring fork and exit 
> > rates
> > which can be used to calculate the overhead of the task watcher 
> > infrastructure.
> >
> > Subsequent patches will make use of task watchers to simplify fork, exit,
> > and many of the system calls that set [er][ug]ids.
> It's easier to get such watch capabilities by kprobe/systemtap. Why to
> add new codes to kernel?

Good question! Disclaimer: Everything I know about kprobes I learned
from Documentation/kprobes.txt

The task watchers patches have a few distinguishing capabilities yet
lack capabilities important for kprobes -- so neither is a replacement
for the other. Specifically:

- Task watchers are for use by the kernel for more than profiling and
debugging. They need to work even when kernel debugging and
instrumentation are disabled.

- Task watchers do not need to be dynamically enabled, disabled, or
removed (though dynamic insertion would be nice -- I'm working on that).
In fact I've been told that dynamically enabling, disabling, or removing
them would incur unacceptable complexity and/or cost for an
uninstrumented kernel.

- Task watchers don't require arch support. They use completely generic
code.
- Since they are written into the code task watchers don't need
  to modify instructions.

- Task watchers doesn't need to single-step an instruction

- Task watchers don't need to know about arch registers, calling
  conventions, etc. to work

- Task watchers don't need to have the same (possibly extensive)
argument list as the function being "probed". This makes maintenance
easier -- no need to keep the signature of the watchers in synch with
the signature of the "probed" function.

- Task watchers don't require MODULES (2.6.20-rc1-mm1's
arch/i386/Kconfig suggests this is true of kprobes).

- Task watchers don't need kernel symbols.

- Task watchers can affect flow control (see the patch hunks that change
copy_process()) with their return value.

- Task watchers do not need to know the instruction address to be
"probed".

- Task watchers can actually improve kernel performance slightly (up to
2% in extremely fork-heavy workloads for instance).

- Task watchers require local variables -- not necessarily arguments to
the "probed" function.

- Task watchers don't care if preemption is enabled or disabled.

- Task watchers could sleep if they want to.

So to the best of my knowledge kprobes isn't a replacement for task
watchers nor is task watchers capable of replacing kprobes.

Cheers,
-Matt Helsley

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Make JFFS depend on CONFIG_BROKEN

[Josh Boyer]

Mark JFFS as broken and provide a warning to users that it is
deprecated and scheduled for removal in 2.6.21

Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>

diff --git a/fs/Kconfig b/fs/Kconfig
index b3b5aa0..4ac367d 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -1204,13 +1204,16 @@ config EFS_FS

config JFFS_FS
tristate "Journalling Flash File System (JFFS) support"
-   depends on MTD && BLOCK
+   depends on MTD && BLOCK && BROKEN
help
  JFFS is the Journalling Flash File System developed by Axis
  Communications in Sweden, aimed at providing a crash/powerdown-safe
  file system for disk-less embedded devices. Further information is
  available at ().

+ NOTE: This filesystem is deprecated and is scheduled for removal in
+ 2.6.21.  See Documentation/feature-removal-schedule.txt
+
config JFFS_FS_VERBOSE
int "JFFS debugging verbosity (0 = quiet, 3 = noisy)"
depends on JFFS_FS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] remove the broken SCSI_SEAGATE driver

[Krzysztof Halasa]

Arjan van de Ven <[EMAIL PROTECTED]> writes:

> if a tree falls in a forest but there's nobody around to hear it, does
> it make a sound?
>
> This sort of heisenbug questions aren't solved by "nobody hears it so
> lets chop down the forest to make houses out of the wood" answers...

Does that mean you don't want to know which hardware/drivers aren't used
anymore and which ones are?
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] remove the broken SCSI_SEAGATE driver

[Arjan van de Ven]

On Mon, 2006-12-18 at 14:48 +0100, Krzysztof Halasa wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> 
> > if a tree falls in a forest but there's nobody around to hear it, does
> > it make a sound?
> >
> > This sort of heisenbug questions aren't solved by "nobody hears it so
> > lets chop down the forest to make houses out of the wood" answers...
> 
> Does that mean you don't want to know which hardware/drivers aren't used
> anymore and which ones are?

it means that IT DOESN'T MATTER.
* If it's entirely unused, we get no bugreports -> there is no problem.
* If it's used but good quality, we get no bugreports -> there is no
problem

we can't distinguish the two. But.. in neither case is there a problem
so why force anything? I know some people don't like Heisenberg
uncertainty, but... personally for me if the effect is the same I
couldn't care less.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IO-APIC + timer doesn't work (was: Linux 2.6.20-rc1)

[Tobias Diedrich]

Eric W. Biederman wrote:
> Tobias Diedrich <[EMAIL PROTECTED]> writes:
> 
> > Linus Torvalds wrote:
> >
> >> Your dmesg is kind of interesting:
> >> 
> >> ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on 
> >> CPU0:
> > 04(40)
> >>  .. failed
> >> 
> >> where that APIC error on CPU0 seems to be a "Send accept error" and "Send 
> >> illegal vector" thing. I think we actually got the interrupt there, but 
> >> because we had some APIC setup bug, we didn't accept it properly, and it 
> >> resulted in that "APIC error" thing. Maybe. 
> >
> > I just tried changing the code so the "8259 IRQ0 enabled" case is
> > tested first and with that it boots fine.
> 
> Could you try removing the clear_IO_APIC_pin from try_io_apic_pin.
> 
> This isn't a complete fix but I believe for your hardware it will
> fix the problem and it points at what the real fix is.  
> 
> Not properly programming the io_apic for the case we want to test.

Yes, this works:

|[   27.535937] init IO_APIC IRQs
|[   27.536009]  IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 
2-23 not connected.
|[   27.536140] ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled<3> 
(clear_IO_APIC_pin not called)<3> .. failed
|[   27.569357] ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled<3> .. 
works
|[   27.602547] Using local APIC timer interrupts.

I can also report, that updating the BIOS to version 0609 (released
last week or so, also adds the long-missing HPET support) also makes
the problem go away since the first testcase then already works.
I'm currently running with the BIOS downgraded to version 0402.

|[   23.646371] ENABLING IO-APIC IRQs
|[   23.646477] init IO_APIC IRQs
|[   23.646479]  IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 
2-22, 2-23 not connected.
|[   23.646674] ..TIMER: trying IO-APIC=0 PIN=2 with 8259 IRQ0 disabled<3> .. 
works
|[   23.679872] Using local APIC timer interrupts.

Index: linux-2.6.20-rc1/arch/x86_64/kernel/io_apic.c
===
--- linux-2.6.20-rc1.orig/arch/x86_64/kernel/io_apic.c  2006-12-18 
15:56:38.0 +0100
+++ linux-2.6.20-rc1/arch/x86_64/kernel/io_apic.c   2006-12-18 
16:04:15.0 +0100
@@ -1586,9 +1586,11 @@
setup_nmi();
enable_8259A_irq(0);
}
+   apic_printk(APIC_QUIET, KERN_ERR " .. works\n");
return 1;
}
-   clear_IO_APIC_pin(apic, pin);
+   printk(KERN_ERR " (clear_IO_APIC_pin not called)");
+   /* clear_IO_APIC_pin(apic, pin); */
apic_printk(APIC_QUIET, KERN_ERR " .. failed\n");
return 0;
 }

HTH,

-- 
Tobias  PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Gene Heskett]

On Monday 18 December 2006 05:49, Andrei Popa wrote:
>> OK, I'll try this on a ext3 box. BTW, what data mode are you using
>> ext3 in?
>
>ordered
>
>> Also, for testings sake, could you give this a go:
>> It's a total hack but I guess worth testing.
>>
>> ---
>>  mm/rmap.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Index: linux-2.6-git/mm/rmap.c
>> ===
>> --- linux-2.6-git.orig/mm/rmap.c 2006-12-18 11:06:29.0 +0100
>> +++ linux-2.6-git/mm/rmap.c  2006-12-18 11:07:16.0 +0100
>> @@ -448,7 +448,7 @@ static int page_mkclean_one(struct page
>>  goto unlock;
>>
>>  entry = ptep_get_and_clear(mm, address, pte);
>> -entry = pte_mkclean(entry);
>> +/* entry = pte_mkclean(entry); */
>>  entry = pte_wrprotect(entry);
>>  ptep_establish(vma, address, pte, entry);
>>  lazy_mmu_prot_update(entry);
>
>with latest git and this patch there is no corruption !
>
I've not run a torrent app here recently.  Should this patch be applied to 
a plain 2.6-20-rc1 before I do run azureas or similar apps?
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [EMAIL PROTECTED]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[BUG] Linux 2.6.19.1 - "page_mapcount(page) went negative (-1)"

[Chris Rankin]

Hi,

I just tripped this bug when compiling xine-lib on 2.6.19.1. This is on a dual 
P4, SMP and HT, 2
GB RAM, compiled with gcc-4.1.1.

Cheers,
Chris

Eeek! page_mapcount(page) went negative! (-1)
  page->flags = 14
  page->count = 0
  page->mapping = 
[ cut here ]
kernel BUG at /home/chris/LINUX/linux-2.6.19/mm/rmap.c:578!
invalid opcode:  [#1]
PREEMPT SMP
Modules linked in: radeon drm pwc eeprom cpufreq_ondemand p4_clockmod 
speedstep_lib nfsd exportfs
ipv6 autofs4 nfs lockd sunrpc af_packet firmware_class binfmt_misc video 
thermal processor fan
button ac lp parport_pc parport nvram video1394 raw1394 eth1394 compat_ioctl32 
videodev
v4l1_compat v4l2_common snd_usb_audio snd_usb_lib snd_intel8x0 
snd_emu10k1_synth snd_emux_synth
snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec 
snd_ac97_bus
snd_seq_dummy snd_seq_oss ohci1394 snd_seq_midi_event snd_seq ieee1394 
snd_pcm_oss snd_mixer_oss
snd_pcm ehci_hcd e7xxx_edac serio_raw snd_seq_device uhci_hcd edac_mc e1000 
psmouse snd_timer
snd_page_alloc snd_util_mem snd_hwdep ide_cd cdrom snd soundcore pcspkr 
intel_agp i2c_i801
i2c_core agpgart usbcore ext3 jbd
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010282   (2.6.19.1 #1)
EIP is at page_remove_rmap+0x70/0x8f
eax: 001e   ebx: c100f500   ecx: ebd0c000   edx: 0002
esi: 0020   edi: 08665000   ebp: eac11994   esp: ebd0cee0
ds: 007b   es: 007b   ss: 0068
Process cc1 (pid: 24220, ti=ebd0c000 task=ed5b3a90 task.ti=ebd0c000)
Stack: c0284bf0  c100f500 c0140c39  edb60518 ebd0cf54 
   0001 08696000 ec3f3084 f798f040 c200f0c0 fff9  c155822c
   ec3f3084 08696000   ebd0cf54 ecfab5c0 f798f040 0001
Call Trace:
 [] unmap_vmas+0x24d/0x4df
 [] exit_mmap+0x7e/0x10e
 [] mmput+0x1d/0x78
 [] do_exit+0x1a9/0x77c
 [] do_page_fault+0x281/0x51a
 [] vfs_write+0xfc/0x13b
 [] sys_exit_group+0x0/0xd
 [] sysenter_past_esp+0x56/0x79
 ===
Code: 74 03 8b 53 0c 8b 42 04 89 44 24 04 c7 04 24 d9 4b 28 c0 e8 52 3c fd ff 
8b 43 10 89 44 24 04
c7 04 24 f0 4b 28 c0 e8 3f 3c fd ff <0f> 0b 42 02 66 4b 28 c0 8b 53 10 83 f2 01 
83 e2 01 89 d8 5b
59
EIP: [] page_remove_rmap+0x70/0x8f SS:ESP 0068:ebd0cee0
 <1>Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: cc1/0x0002/24220
 [] __sched_text_start+0x4f/0x900
 [] cfq_free_io_context+0x57/0xbb
 [] sys_madvise+0x168/0x3a4
 [] do_exit+0xee/0x77c
 [] sys_madvise+0x168/0x3a4
 [] sys_madvise+0x168/0x3a4
 [] die+0x2a5/0x2cc
 [] do_invalid_op+0x0/0xab
 [] do_invalid_op+0xa2/0xab
 [] page_remove_rmap+0x70/0x8f
 [] vprintk+0x2b9/0x313
 [] vprintk+0x2c3/0x313
 [] __pagevec_free+0x18/0x22
 [] error_code+0x39/0x40
 [] page_remove_rmap+0x70/0x8f
 [] unmap_vmas+0x24d/0x4df
 [] exit_mmap+0x7e/0x10e
 [] mmput+0x1d/0x78
 [] do_exit+0x1a9/0x77c
 [] do_page_fault+0x281/0x51a
 [] vfs_write+0xfc/0x13b
 [] sys_exit_group+0x0/0xd
 [] sysenter_past_esp+0x56/0x79
 ===



Send instant messages to your online friends http://uk.messenger.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

bug: depca_module_init() cleanup error

[Ingo Molnar]

while doing an allyesconfig bootup on a PC the depca driver triggered 
the crash below.

Ingo

-->
Calling initcall 0xc1ea0506: depca_module_init+0x0/0xd7()
PM: Adding info for platform:depca.0
depca: probe of depca.0 failed with error -16
PM: Removing info for platform:depca.0
kfree_debugcheck: out of range ptr 300h.
BUG at mm/slab.c:2910!
stopped custom tracer.
[ cut here ]
kernel BUG at mm/slab.c:2910!
invalid opcode:  [#1]
PREEMPT SMP 
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286   (2.6.19.1-rt16 #494)
EIP is at kfree_debugcheck+0x52/0xa9
eax: 001a   ebx: 0004   ecx: c01356a9   edx: 0001
esi: 0300   edi: 0300   ebp: f7c21ec4   esp: f7c21eb0
ds: 007b   es: 007b   ss: 0068   preempt: 0001
Process swapper (pid: 1, ti=f7c21000 task=f7c30c50 task.ti=f7c21000)
Stack: c14f9371 c150c05d 0b5e f772aea0 c1fd4ea0 f7c21ee8 c01953b2 0300 
   fff0 f772b080  f772aea0 f772b080 c1902880 f7c21ef8 c06e3d0e 
   0300 c19029f0 f7c21f0c c06dfcd9 f772aea8 c06dfe6e f772b080 f7c21f28 
Call Trace:
 [] show_trace_log_lvl+0x34/0x4a
 [] show_stack_log_lvl+0xa9/0xb9
 [] show_registers+0x1f5/0x290
 [] die+0x1de/0x2db
 [] do_trap+0xac/0xca
 [] do_invalid_op+0xae/0xb8
 [] error_code+0x39/0x40
 [] kfree+0x42/0xce
 [] platform_device_release+0x1e/0x38
 [] device_release+0x36/0x6b
 [] kobject_cleanup+0x4d/0x74
 [] kobject_release+0x17/0x19
 [] kref_put+0x5b/0x69
 [] kobject_put+0x24/0x26
 [] put_device+0x1d/0x1f
 [] platform_device_put+0x1b/0x1d
 [] depca_module_init+0x92/0xd7
 [] init+0x178/0x451
 [] kernel_thread_helper+0x7/0x10
 ===
Code: 24 e7 c3 50 c1 e8 00 17 fa ff e8 49 08 fd ff c7 44 24 08 5e 0b 00 00 c7 
44 24 04 5d c0 50 c1 c7 04 24 71 93 4f c1 e8 df 16 fa ff <0f> 0b 5e 0b 5d c0 50 
c1 6b c3 74 03 05 10 f2 35 c2 8b 00 84 c0 
EIP: [] kfree_debugcheck+0x52/0xa9 SS:ESP 0068:f7c21eb0
 <0>Kernel panic - not syncing: Attempted to kill init!
 [] show_trace_log_lvl+0x34/0x4a
 [] show_trace+0x2c/0x2e
 [] dump_stack+0x2b/0x2d
 [] panic+0x67/0x124
 [] do_exit+0xb8/0x9ed
 [] die+0x2d3/0x2db
 [] do_trap+0xac/0xca
 [] do_invalid_op+0xae/0xb8
 [] error_code+0x39/0x40
 [] kfree+0x42/0xce
 [] platform_device_release+0x1e/0x38
 [] device_release+0x36/0x6b
 [] kobject_cleanup+0x4d/0x74
 [] kobject_release+0x17/0x19
 [] kref_put+0x5b/0x69
 [] kobject_put+0x24/0x26
 [] put_device+0x1d/0x1f
 [] platform_device_put+0x1b/0x1d
 [] depca_module_init+0x92/0xd7
 [] init+0x178/0x451
 [] kernel_thread_helper+0x7/0x10
 ===
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Peter Zijlstra]

On Mon, 2006-12-18 at 10:24 -0500, Gene Heskett wrote:
> On Monday 18 December 2006 05:49, Andrei Popa wrote:
> >> OK, I'll try this on a ext3 box. BTW, what data mode are you using
> >> ext3 in?
> >
> >ordered
> >
> >> Also, for testings sake, could you give this a go:
> >> It's a total hack but I guess worth testing.
> >>
> >> ---
> >>  mm/rmap.c |2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> Index: linux-2.6-git/mm/rmap.c
> >> ===
> >> --- linux-2.6-git.orig/mm/rmap.c   2006-12-18 11:06:29.0 +0100
> >> +++ linux-2.6-git/mm/rmap.c2006-12-18 11:07:16.0 +0100
> >> @@ -448,7 +448,7 @@ static int page_mkclean_one(struct page
> >>goto unlock;
> >>
> >>entry = ptep_get_and_clear(mm, address, pte);
> >> -  entry = pte_mkclean(entry);
> >> +  /* entry = pte_mkclean(entry); */
> >>entry = pte_wrprotect(entry);
> >>ptep_establish(vma, address, pte, entry);
> >>lazy_mmu_prot_update(entry);
> >
> >with latest git and this patch there is no corruption !
> >
> I've not run a torrent app here recently.  Should this patch be applied to 
> a plain 2.6-20-rc1 before I do run azureas or similar apps?

depends on what the blue frog does, if it uses MAP_SHARED like rtorrent
does then yeah, probably. This patch really should not be the final one,
I'm currently still trying to wrap my head around the issue. That said,
it should be safe to use :-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

bug: crash in adummy_init()

[Ingo Molnar]

crash in adummy_init() - allyesconfig bootup.

Ingo

>
Calling initcall 0xc1eb1f7e: adummy_init+0x0/0xb9()
adummy: version 1.0
swapper/1[CPU#0]: BUG in kref_get at lib/kref.c:32
 [] show_trace_log_lvl+0x34/0x4a
 [] show_trace+0x2c/0x2e
 [] dump_stack+0x2b/0x2d
 [] __WARN_ON+0x63/0x75
 [] kref_get+0x31/0x3c
 [] kobject_get+0x1c/0x22
 [] class_get+0x1d/0x2d
 [] class_device_add+0x52/0x45c
 [] class_device_register+0x1d/0x21
 [] atm_register_sysfs+0x5a/0xbf
 [] atm_dev_register+0x1e3/0x245
 [] adummy_init+0x72/0xb9
 [] init+0x178/0x451
 [] kernel_thread_helper+0x7/0x10
 ===
BUG: unable to handle kernel NULL pointer dereference at virtual address 
0064
 printing eip:
c01e318f
*pde = 01fd4001
stopped custom tracer.
Oops:  [#1]
PREEMPT SMP 
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246   (2.6.19.1-rt16 #495)
EIP is at create_dir+0x14/0x1e4
eax: f76d1374   ebx: f76d1374   ecx: 0008   edx: 
esi: f76d1440   edi: fffe   ebp: f7c1ae98   esp: f7c1ae78
ds: 007b   es: 007b   ss: 0068   preempt: 0001
Process swapper (pid: 1, ti=f7c1a000 task=f7c2ec50 task.ti=f7c1a000)
Stack: 0001 c13db5aa c1900e70 0246 f7c1aea0 f76d1370 f76d1440 fffe 
   f7c1aeb8 c01e33da f76d1370  f76d1374 f7c1aeb0  f76d1370 
   f7c1aee0 c04f0611 f76d1370 c19bfb14 c1900e68 c1bfeb14 f7c1aef0 f76d1368 
Call Trace:
 [] show_trace_log_lvl+0x34/0x4a
 [] show_stack_log_lvl+0xa9/0xb9
 [] show_registers+0x1f5/0x290
 [] die+0x1de/0x2db
 [] do_page_fault+0x5a3/0x68c
 [] error_code+0x39/0x40
 [] sysfs_create_dir+0x7b/0x96
 [] kobject_add+0xcd/0x187
 [] class_device_add+0xb5/0x45c
 [] class_device_register+0x1d/0x21
 [] atm_register_sysfs+0x5a/0xbf
 [] atm_dev_register+0x1e3/0x245
 [] adummy_init+0x72/0xb9
 [] init+0x178/0x451
 [] kernel_thread_helper+0x7/0x10
 ===
Code: 9f ac 00 00 00 c7 87 a4 00 00 00 fc 2b 82 c1 83 c4 0c 5b 5e 5f 5d c3 55 
89 e5 57 56 53 83 ec 14 e8 73 bc f3 ff 8b 55 0c 8b 5d 10 <8b> 42 64 89 df 05 cc 
00 00 00 e8 ab 89 1f 01 31 c0 83 c9 ff f2 
EIP: [] create_dir+0x14/0x1e4 SS:ESP 0068:f7c1ae78
 <0>Kernel panic - not syncing: Attempted to kill init!
 [] show_trace_log_lvl+0x34/0x4a
 [] show_trace+0x2c/0x2e
 [] dump_stack+0x2b/0x2d
 [] panic+0x67/0x124
 [] do_exit+0xb8/0x9ed
 [] die+0x2d3/0x2db
 [] do_page_fault+0x5a3/0x68c
 [] error_code+0x39/0x40
 [] sysfs_create_dir+0x7b/0x96
 [] kobject_add+0xcd/0x187
 [] class_device_add+0xb5/0x45c
 [] class_device_register+0x1d/0x21
 [] atm_register_sysfs+0x5a/0xbf
 [] atm_dev_register+0x1e3/0x245
 [] adummy_init+0x72/0xb9
 [] init+0x178/0x451
 [] kernel_thread_helper+0x7/0x10
 ===
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Robert P. J. Day]

On Mon, 18 Dec 2006, Stefan Richter wrote:

> Robert P. J. Day wrote:

> [...]
> > in any event, as i mentioned earlier, i'm just trying to find a
> > way to make the menu entries more obvious and more easily
> > selectable, without having to enter each submenu to see what it
> > represents.
> [...]
>
> Yes, this and the points you made in the other post are definitely
> valid.

this is a long-term suggestion, but the easiest solution might be to
introduce a new kbuild directive:  "selectablemenu" or something like
that, with a form similar to:

=
selectablemenu ISDN
bool "ISDN support"

config ...
config ...
config ...

endmenu
=

  the top level entry would be just a yes/no toggle as to whether you
want that support in general, and the internal entries would represent
the submenu and all of them would *automatically* depend on the top
config entry (in this case, ISDN).  and the "help" entry could be
available from that top-level entry without having to enter the
submenu. as opposed to what you need to do now.

  i'm guessing that structure would be sufficient for 90% of the
current menu layouts.  just a thought.

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IO-APIC + timer doesn't work (was: Linux 2.6.20-rc1)

[Tobias Diedrich]

Tobias Diedrich wrote:

> I can also report, that updating the BIOS to version 0609 (released
> last week or so, also adds the long-missing HPET support) also makes
> the problem go away since the first testcase then already works.
> I'm currently running with the BIOS downgraded to version 0402.

In case someone is interested, here is the diff between the dmesg
from a boot with version 0402 and version 0609:

(Changelogs for BIOS releases would be nice, all they say on the
ASUS homepage is "support for new processors"...)

--- dmesg-notimes-20061218-2.6.20-rc1-bios-0402 2006-12-18 16:27:36.0 
+0100
+++ dmesg-notimes-20061218-2.6.20-rc1-bios-0609-works   2006-12-18 
16:27:45.0 +0100
@@ -13,14 +13,15 @@
 Entering add_active_range(0, 0, 159) 0 entries of 256 used
 Entering add_active_range(0, 256, 261856) 1 entries of 256 used
 end_pfn_map = 1048576
-DMI 2.3 present.
-ACPI: RSDP (v000 Nvidia) @ 0x000f7ce0
-ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x3fee3040
-ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x3fee30c0
-ACPI: SSDT (v001 PTLTD  POWERNOW 0x0001  LTP 0x0001) @ 
0x3feec2c0
-ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x3feec400
-ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x3feec200
-ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 
0x
+DMI 2.4 present.
+ACPI: RSDP (v002 Nvidia) @ 0x000f7b70
+ACPI: XSDT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 
0x3fee30c0
+ACPI: FADT (v003 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 
0x3feec5c0
+ACPI: SSDT (v001 PTLTD  POWERNOW 0x0001  LTP 0x0001) @ 
0x3feec7c0
+ACPI: HPET (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x0098) @ 
0x3feec900
+ACPI: MCFG (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 
0x3feec980
+ACPI: MADT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 
0x3feec700
+ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x0300) @ 
0x
 Entering add_active_range(0, 0, 159) 0 entries of 256 used
 Entering add_active_range(0, 256, 261856) 1 entries of 256 used
 Zone PFN ranges:
@@ -37,8 +38,6 @@
   DMA32 zone: 3524 pages used for memmap
   DMA32 zone: 254236 pages, LIFO batch:31
   Normal zone: 0 pages used for memmap
-Nvidia board detected. Ignoring ACPI timer override.
-If you got timer trouble try acpi_use_timer_override
 ACPI: PM-Timer IO Port: 0x1008
 ACPI: Local APIC address 0xfee0
 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
@@ -48,13 +47,17 @@
 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
 IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
+ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
 ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
 ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
+ACPI: IRQ0 used by override.
+ACPI: IRQ2 used by override.
 ACPI: IRQ9 used by override.
 ACPI: IRQ14 used by override.
 ACPI: IRQ15 used by override.
 Setting APIC routing to flat
+ACPI: HPET id: 0x10de8201 base: 0xfefff000
 Using ACPI (MADT) for SMP configuration information
 mapped APIC to ff5fd000 (fee0)
 mapped IOAPIC to ff5fc000 (fec0)
@@ -72,8 +75,8 @@
 netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
 Initializing CPU#0
 PID hash table entries: 4096 (order: 12, 32768 bytes)
-time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
-time.c: Detected 2009.284 MHz processor.
+time.c: Using 25.00 MHz WALL HPET GTOD HPET/TSC timer.
+time.c: Detected 2009.513 MHz processor.
 Console: colour VGA+ 80x60
 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
 Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
@@ -82,7 +85,7 @@
 Aperture too small (32 MB)
 No AGP bridge found
 Memory: 1025340k/1047424k available (3252k kernel code, 21452k reserved, 1468k 
data, 200k init)
-Calibrating delay using timer specific routine.. 4022.20 BogoMIPS (lpj=6701126)
+Calibrating delay using timer specific routine.. 4023.46 BogoMIPS (lpj=6703148)
 Mount-cache hash table entries: 256
 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
 CPU: L2 Cache: 512K (64 bytes/line)
@@ -93,12 +96,11 @@
 ESR value after enabling vector: , after 0004
 ENABLING IO-APIC IRQs
 init IO_APIC IRQs
- IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not 
connected.
-..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled<3> (clear_IO_APIC_pin 
not called)<3> .. failed
-..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled<3> .. works
+ IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not 
connected.
+..TIMER: try

Re: GPL only modules

[Dave Neuer]

On 12/17/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:


Linking does have one thing that it implies: it's maybe a bit "closer"
relationship between the parts than "mkisofs" implies. So there is
definitely a higher _correlation_ between "derived work" and "linking",
but it's really a correlation, not a causal relationship.

But it wasn't the "act of linking" that caused
that to happen, but simply the fact that they were part of a bigger whole,
and were meaningless apart from each other.


I think this is the key, both with libraries and w/ your book example
below; the concept of independant "meaning." If your code doesn't do
whatever it is supposed to do _unless_ it is linked with _my_ code,
then it seems fairly clear that your code is derivative of mine, just
as your sequel to my novel (or your pages added onto my book) don't
"mean" anything if someone hasn't read mine.



Think of this in the sense of a book. Does binding pages together create a
"derived work"? Not always: you can have anthologies (which are
*aggregations* of works with *independent* copyright), and the binding of
pages together didn't really do anything to the independent pieces. But
clearly, if you're talking about individual pages in one story, then each
individual page is not an independent work in itself.


Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IO-APIC + timer doesn't work

[Eric W. Biederman]

Tobias Diedrich <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Could you try removing the clear_IO_APIC_pin from try_io_apic_pin.
>> 
>> This isn't a complete fix but I believe for your hardware it will
>> fix the problem and it points at what the real fix is.  
>> 
>> Not properly programming the io_apic for the case we want to test.
>
> Yes, this works:

Thanks.  The bug is simply that the new code doesn't setup the
ioapic for the cases it intends to test.  But it does clear out
the original programming.  So if the normal good case doesn't work the
code is going to have problems.


> I can also report, that updating the BIOS to version 0609 (released
> last week or so, also adds the long-missing HPET support) also makes
> the problem go away since the first testcase then already works.
> I'm currently running with the BIOS downgraded to version 0402.

Nice to hear, so this is clearly a software setup problem in the BIOS.

Andi do you think you could address this problem?

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)

[Rafael J. Wysocki]

Hi,

On Monday, 18 December 2006 12:20, Jiri Slaby wrote:
> Hi.
> 
> I got this oops while suspending:
> [  309.366557] Disabling non-boot CPUs ...
> [  309.386563] CPU 1 is now offline
> [  309.387625] CPU1 is down
> [  309.387704] Stopping tasks ... done.
> [  310.030991] Shrinking memory... -<0>divide error:  [#1]
> [  310.456669] SMP
> [  310.456814] last sysfs file:
> /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions
> [  310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 
> cdrom
> [  310.457259] CPU:0
> [  310.457260] EIP:0060:[]Not tainted VLI
> [  310.457261] EFLAGS: 00210246   (2.6.20-rc1-mm1 #207)
> [  310.457478] EIP is at shrink_slab+0x9e/0x169

Looks like we have a problem with slab shrinking here.

Could you please use gdb to check what exactly is at shrink_slab+0x9e?

> [  310.457548] eax:    ebx:    ecx:    edx: 
> [  310.457623] esi:    edi: c18fe500   ebp: f7b3fe3c   esp: f7b3fe08
> [  310.457696] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> [  310.457772] Process swsusp (pid: 3243, ti=f7b3e000 task=f756f030
> task.ti=f7b3e000)
> [  310.457845] Stack: c175d8a0 c175daa0 c175db00   c053cec0
> 45ec 00d0
> [  310.458286]  1179 1179  f7b3fe94
> c0151445 0001
> [  310.458723]f7b3fe64 1df1 0002 0001 0001 00038000
> 0c79 117b
> [  310.459199] Call Trace:
> [  310.459334]  [] show_trace_log_lvl+0x1a/0x30
> [  310.459450]  [] show_stack_log_lvl+0xa5/0xca
> [  310.459562]  [] show_registers+0x1d3/0x2b8
> [  310.459673]  [] die+0x121/0x243
> [  310.459781]  [] do_trap+0x76/0x9c
> [  310.459892]  [] do_divide_error+0x94/0x9e
> [  310.460001]  [] error_code+0x7c/0x84
> [  310.460113]  [] shrink_all_memory+0x211/0x2eb
> [  310.460225]  [] swsusp_shrink_memory+0x187/0x196
> [  310.460335]  [] prepare_processes+0x35/0xc8
> [  310.460446]  [] pm_suspend_disk+0xd/0x16f
> [  310.460558]  [] enter_state+0x129/0x19b
> [  310.460668]  [] state_store+0xa3/0xac
> [  310.460777]  [] subsys_attr_store+0x20/0x25
> [  310.460889]  [] sysfs_write_file+0x97/0xd8
> [  310.460998]  [] vfs_write+0x8b/0x149
> [  310.461108]  [] sys_write+0x3d/0x64
> [  310.461216]  [] syscall_call+0x7/0xb
> [  310.461328]  ===
> [  310.461397] Code: 31 c0 ff 17 89 c3 8b 45 e4 31 d2 f7 77 0c f7 e3 89 45 d8 
> 89
> 55 dc 89 d1 89 c6 31 d2 85 c9 74 09 89 c8 31 d2 f7 75 f0 89 c1 89 f0  75 
> f0
> 89 ca 89 45 d8 89 55 dc 8b 45 d8 03 47 10 89 47 10 85
> [  310.464079] EIP: [] shrink_slab+0x9e/0x169 SS:ESP 0068:f7b3fe08
> [  310.464228]
> 
> swsusp script is something like this:
> echo platform > /sys/power/disk
> echo disk > /sys/power/state
> 
> regards,

Greetings,
Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
- Stephen King
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)

[Stefan Richter]

Gene Heskett wrote:
> On Sunday 17 December 2006 20:05, Stefan Richter wrote:
>>What's missing in our implementation is that the use count of ohci1394
>>goes up too once a "high-level driver" uses resources of a host driven
>>by ohci1394.
> 
> This needs some tlc then I assume?

Yes. It's now logged at http://bugzilla.kernel.org/show_bug.cgi?id=7701
and will probably stay there until I do something about it myself.

>>The FireWire stack has three layers: Low level (ohci1394 and pcilynx;
>>control the host bus adapter),
> The hardware

Yes, or more precisely the built-in hardware, not hardware at the other
end of the wire.

>>mid level (the ieee1394 core)
> which I assume (fuggly word) steers the high level stuff to the right 
> entry points in the hardware handler?

Yes. It implements common management functionality and makes actions
like "write into a register of a remote node" or "receive a stream into
a buffer" independent of the actual host adapter --- or at least that
was the intent when Linux' FireWire stack was designed. Years ago there
was actually another driver for a non-OHCI host adapter chip from
Adaptec; and there is a mostly functional but unmaintained out-of-tree
driver for a non-OHCI/ non-PCI adapter from Texas Instruments (TI GP2Lynx).

IOW the ieee1394 core provides a platform to stick application-level
drivers (protocol drivers) like for DV, IPv4 networking, SBP-2 storage
on top of it without having to care of how particular host adapter chips
are programmed. raw1394 basically extends ieee1394 to stick userspace
drivers on it.

But as mentioned, this layering is partly violated in the actual
implementation. Also, the ieee1394 core is itself needlessly dependent
on a PCI kernel API, making it harder for embedded developers to add
their own low-level drivers than it ought to be. (So I was told; I
actually rarely hear from embedded development projects.)
-- 
Stefan Richter
-=-=-==- ==-- =--=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.19 file content corruption on ext3

[Gene Heskett]

On Monday 18 December 2006 10:32, Peter Zijlstra wrote:
[...]
>>
>> I've not run a torrent app here recently.  Should this patch be
>> applied to a plain 2.6-20-rc1 before I do run azureas or similar apps?
>
>depends on what the blue frog does, if it uses MAP_SHARED like rtorrent
>does then yeah, probably. This patch really should not be the final one,
>I'm currently still trying to wrap my head around the issue. That said,
>it should be safe to use :-)
>
Thanks, I'll do it.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/