Re: Oops in audit_copy_inode

2012-08-03 Thread Miklos Szeredi 
Eric Paris  writes:

> I believe this was already found and fixed:
>
> https://lkml.org/lkml/2012/7/25/259
>
> Which was pulled by Linus in:
>
> 3134f37e931d75931bdf6d4eacd82a3fd26eca7c

Okay, yes.  I was actually CC-d on that, but missed the email.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in audit_copy_inode

2012-08-03 Thread Miklos Szeredi 
Eric Paris epa...@redhat.com writes:

 I believe this was already found and fixed:

 https://lkml.org/lkml/2012/7/25/259

 Which was pulled by Linus in:

 3134f37e931d75931bdf6d4eacd82a3fd26eca7c

Okay, yes.  I was actually CC-d on that, but missed the email.

Thanks,
Miklos
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in audit_copy_inode

2012-08-02 Thread Eric Paris 
I believe this was already found and fixed:

https://lkml.org/lkml/2012/7/25/259

Which was pulled by Linus in:

3134f37e931d75931bdf6d4eacd82a3fd26eca7c

-Eric

On Wed, 2012-08-01 at 18:11 +0200, Miklos Szeredi wrote:
> Hi Peter,
> 
> Thanks for the report.
> 
> Here's a patch.  I haven't tested it but I'm pretty confident that it
> fixes the bug.
> 
> Thanks,
> Miklos
> 
> 
> Subject: vfs: fix audit_inode on negative dentry
> From: Miklos Szeredi 
> 
> Peter Moody reported an oops in audit_copy_inode() and bisected it to commit
> 7157486541 (vfs: do_last(): common slow lookup).
> 
> The problem is that audit_inode() in do_last() is called with a negative 
> dentry.
> 
> Previously the non-O_CREAT case didn't call audit_inode() here, but now both
> O_CREAT and non-O_CREAT opens are handled by the same code.
> 
> I really have no idea why this audit_inode() is needed here at all but am 
> afaid
> to remove this for fear of breaking audit somehow.  So just fix this case by
> checking for a negative dentry.
> 
> Reported-by: Peter Moody 
> Signed-off-by: Miklos Szeredi 
> CC: sta...@vger.kernel.org
> ---
>  fs/namei.c |   10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> Index: linux-2.6/fs/namei.c
> ===
> --- linux-2.6.orig/fs/namei.c 2012-08-01 17:47:28.0 +0200
> +++ linux-2.6/fs/namei.c  2012-08-01 17:49:26.0 +0200
> @@ -2607,10 +2607,12 @@ static int do_last(struct nameidata *nd,
>   goto finish_open_created;
>   }
>  
> - /*
> -  * It already exists.
> -  */
> - audit_inode(pathname, path->dentry);
> + if (path->dentry->d_inode) {
> + /*
> +  * It already exists.
> +  */
> + audit_inode(pathname, path->dentry);
> + }
>  
>   /*
>* If atomic_open() acquired write access it is dropped now due to
> 
> 


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

Re: Oops in audit_copy_inode

2012-08-02 Thread Eric Paris 
I believe this was already found and fixed:

https://lkml.org/lkml/2012/7/25/259

Which was pulled by Linus in:

3134f37e931d75931bdf6d4eacd82a3fd26eca7c

-Eric

On Wed, 2012-08-01 at 18:11 +0200, Miklos Szeredi wrote:
 Hi Peter,
 
 Thanks for the report.
 
 Here's a patch.  I haven't tested it but I'm pretty confident that it
 fixes the bug.
 
 Thanks,
 Miklos
 
 
 Subject: vfs: fix audit_inode on negative dentry
 From: Miklos Szeredi mszer...@suse.cz
 
 Peter Moody reported an oops in audit_copy_inode() and bisected it to commit
 7157486541 (vfs: do_last(): common slow lookup).
 
 The problem is that audit_inode() in do_last() is called with a negative 
 dentry.
 
 Previously the non-O_CREAT case didn't call audit_inode() here, but now both
 O_CREAT and non-O_CREAT opens are handled by the same code.
 
 I really have no idea why this audit_inode() is needed here at all but am 
 afaid
 to remove this for fear of breaking audit somehow.  So just fix this case by
 checking for a negative dentry.
 
 Reported-by: Peter Moody pmo...@google.com
 Signed-off-by: Miklos Szeredi mszer...@suse.cz
 CC: sta...@vger.kernel.org
 ---
  fs/namei.c |   10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)
 
 Index: linux-2.6/fs/namei.c
 ===
 --- linux-2.6.orig/fs/namei.c 2012-08-01 17:47:28.0 +0200
 +++ linux-2.6/fs/namei.c  2012-08-01 17:49:26.0 +0200
 @@ -2607,10 +2607,12 @@ static int do_last(struct nameidata *nd,
   goto finish_open_created;
   }
  
 - /*
 -  * It already exists.
 -  */
 - audit_inode(pathname, path-dentry);
 + if (path-dentry-d_inode) {
 + /*
 +  * It already exists.
 +  */
 + audit_inode(pathname, path-dentry);
 + }
  
   /*
* If atomic_open() acquired write access it is dropped now due to
 
 


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

Re: Oops in audit_copy_inode

2012-08-01 Thread Peter Moody 
On Wed, Aug 1, 2012 at 9:11 AM, Miklos Szeredi  wrote:
> Hi Peter,
>
> Thanks for the report.
>
> Here's a patch.  I haven't tested it but I'm pretty confident that it
> fixes the bug.
>
> Thanks,
> Miklos

Ack. I can confirm that I don't Oops with this patch.

Thanks!

Cheers,
peter

-- 
Peter Moody  Google
Security Engineer  pgp:0xC3410038
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in audit_copy_inode

2012-08-01 Thread Miklos Szeredi 
Hi Peter,

Thanks for the report.

Here's a patch.  I haven't tested it but I'm pretty confident that it
fixes the bug.

Thanks,
Miklos


Subject: vfs: fix audit_inode on negative dentry
From: Miklos Szeredi 

Peter Moody reported an oops in audit_copy_inode() and bisected it to commit
7157486541 (vfs: do_last(): common slow lookup).

The problem is that audit_inode() in do_last() is called with a negative dentry.

Previously the non-O_CREAT case didn't call audit_inode() here, but now both
O_CREAT and non-O_CREAT opens are handled by the same code.

I really have no idea why this audit_inode() is needed here at all but am afaid
to remove this for fear of breaking audit somehow.  So just fix this case by
checking for a negative dentry.

Reported-by: Peter Moody 
Signed-off-by: Miklos Szeredi 
CC: sta...@vger.kernel.org
---
 fs/namei.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

Index: linux-2.6/fs/namei.c
===
--- linux-2.6.orig/fs/namei.c   2012-08-01 17:47:28.0 +0200
+++ linux-2.6/fs/namei.c2012-08-01 17:49:26.0 +0200
@@ -2607,10 +2607,12 @@ static int do_last(struct nameidata *nd,
goto finish_open_created;
}
 
-   /*
-* It already exists.
-*/
-   audit_inode(pathname, path->dentry);
+   if (path->dentry->d_inode) {
+   /*
+* It already exists.
+*/
+   audit_inode(pathname, path->dentry);
+   }
 
/*
 * If atomic_open() acquired write access it is dropped now due to


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

Re: Oops in audit_copy_inode

2012-08-01 Thread Peter Moody 
This time with a cleaner Oops:

Pid: 2643, comm: cc1 Not tainted 3.5.0-rc6-at17+ #33 LENOVO 4291AK7/4291AK7
RIP: 0010:[]  [] audit_copy_inode+0x10/0x90
RSP: 0018:8801f88dfc58  EFLAGS: 00010282
RAX: 8801fb32 RBX: 8801f887c508 RCX: c7e8
RDX:  RSI: 8801f3f1d970 RDI: 8801f887c508
RBP: 8801f88dfc88 R08:  R09: 
R10: 0001 R11:  R12: 8801f3f1d970
R13: 8801f887c4a8 R14:  R15: 
FS: 7fd6b9473700() GS:88021520() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0040 CR3: 00020f6a3000 CR4: 000407e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process cc1 (pid: 2643, threadinfo 8801f88de000, task 8801fb32)
Stack:
 8161c6fe 8801f887c508 8801f3f1d970 8801f887c4a8
 8801f887c508 8801f3f1d970 8801f88dfcf8 810d237c
 810d22bb  8801f3f1d970 8801f4575e40
Call Trace:
[] ? mutex_unlock+0xe/0x10
[] __audit_inode+0x13c/0x2a0
[] ? __audit_inode+0x7b/0x2a0
[] do_last+0x7ac/0xa90
[] path_openat+0xd9/0x410
[] ? sched_clock_cpu+0xbd/0x110
[] ? native_sched_clock+0x13/0x80
[] ? sched_clock+0x9/0x10
[] do_filp_open+0x42/0xa0
[] ? _raw_spin_unlock+0x2b/0x40
[] ? alloc_fd+0xd2/0x120
[] do_sys_open+0xf8/0x1d0
[] ? __audit_syscall_entry+0xcc/0x310
[] sys_open+0x21/0x30
[] system_call_fastpath+0x16/0x1b
Code: 00 00 c7 45
cc 1f 00 00 00 e9 2c ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
55 48 89 e5 41 54 53 48 83 ec 20 66 66 66 66 90 <48> 8b 42 40 49 89 f4
48 8d 77 34 48 89 fb 48 89 47 18 48 8b 42
RIP [] audit_copy_inode+0x10/0x90
 RSP 
CR2: 0040
---[ end trace bcccee9a00e71a3b ]---


On Tue, Jul 31, 2012 at 4:02 PM, Peter Moody  wrote:
> I seem to have a reliable oops from 3.5.0-rc6 from Linus's tree. I've
> bisected it down to, I think, the following commit:
>
> 7157486541bffc0dfec912e21ae639b029dae3d3
>
> The Oops:
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.471368] Pid: 2643, comm:
> cc1 Not tainted 3.5.0-rc6-at17+ #33 LENOVO 4291AK7/4291AK7
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.472342] RIP:
> 0010:[]  []
> audit_copy_inode+0x10/0x90
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.473300] RSP:
> 0018:8801f88dfc58  EFLAGS: 00010282
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.474253] RAX:
> 8801fb32 RBX: 8801f887c508 RCX: c7e8
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.475210] RDX:
>  RSI: 8801f3f1d970 RDI: 8801f887c508
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.476172] RBP:
> 8801f88dfc88 R08:  R09: 
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.477138] R10:
> 0001 R11:  R12: 8801f3f1d970
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.478236] R13:
> 8801f887c4a8 R14:  R15: 
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.479218] FS:
> 7fd6b9473700() GS:88021520()
> knlGS:
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.480182] CS:  0010 DS: 
> ES:  CR0: 80050033
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.481143] CR2:
> 0040 CR3: 00020f6a3000 CR4: 000407e0
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.482142] DR0:
>  DR1:  DR2: 
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.483121] DR3:
>  DR6: 0ff0 DR7: 0400
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.484094] Process cc1 (pid:
> 2643, threadinfo 8801f88de000, task 8801fb32)
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.485070] Stack:
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.486030]  8161c6fe
> 8801f887c508 8801f3f1d970 8801f887c4a8
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.487011]  8801f887c508
> 8801f3f1d970 8801f88dfcf8 810d237c
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.487995]  810d22bb
>  8801f3f1d970 8801f4575e40
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.488981] Call Trace:
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.489957]
> [] ? mutex_unlock+0xe/0x10
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.490934]
> [] __audit_inode+0x13c/0x2a0
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.491927]
> [] ? __audit_inode+0x7b/0x2a0
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.492916]
> [] do_last+0x7ac/0xa90
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.493883]
> [] path_openat+0xd9/0x410
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.494852]
> [] ? sched_clock_cpu+0xbd/0x110
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.495817]
> [] ? native_sched_clock+0x13/0x80
> Jul 31 15:32:11 pmoody-x220 kernel: [  108.496774]
> [] ? sched_clock+0x9/0x10
> Jul 31 15:32:11 pmoody-x220 kernel: [

Re: Oops in audit_copy_inode

2012-08-01 Thread Peter Moody 
This time with a cleaner Oops:

Pid: 2643, comm: cc1 Not tainted 3.5.0-rc6-at17+ #33 LENOVO 4291AK7/4291AK7
RIP: 0010:[810cec30]  [810cec30] audit_copy_inode+0x10/0x90
RSP: 0018:8801f88dfc58  EFLAGS: 00010282
RAX: 8801fb32 RBX: 8801f887c508 RCX: c7e8
RDX:  RSI: 8801f3f1d970 RDI: 8801f887c508
RBP: 8801f88dfc88 R08:  R09: 
R10: 0001 R11:  R12: 8801f3f1d970
R13: 8801f887c4a8 R14:  R15: 
FS: 7fd6b9473700() GS:88021520() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0040 CR3: 00020f6a3000 CR4: 000407e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process cc1 (pid: 2643, threadinfo 8801f88de000, task 8801fb32)
Stack:
 8161c6fe 8801f887c508 8801f3f1d970 8801f887c4a8
 8801f887c508 8801f3f1d970 8801f88dfcf8 810d237c
 810d22bb  8801f3f1d970 8801f4575e40
Call Trace:
[8161c6fe] ? mutex_unlock+0xe/0x10
[810d237c] __audit_inode+0x13c/0x2a0
[810d22bb] ? __audit_inode+0x7b/0x2a0
[8117b44c] do_last+0x7ac/0xa90
[8117cad9] path_openat+0xd9/0x410
[81087f2d] ? sched_clock_cpu+0xbd/0x110
[8101a7a3] ? native_sched_clock+0x13/0x80
[8101a819] ? sched_clock+0x9/0x10
[8117cf32] do_filp_open+0x42/0xa0
[8161ed9b] ? _raw_spin_unlock+0x2b/0x40
[8118a2c2] ? alloc_fd+0xd2/0x120
[8116c2f8] do_sys_open+0xf8/0x1d0
[810d1a8c] ? __audit_syscall_entry+0xcc/0x310
[8116c3f1] sys_open+0x21/0x30
[81627529] system_call_fastpath+0x16/0x1b
Code: 00 00 c7 45
cc 1f 00 00 00 e9 2c ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
55 48 89 e5 41 54 53 48 83 ec 20 66 66 66 66 90 48 8b 42 40 49 89 f4
48 8d 77 34 48 89 fb 48 89 47 18 48 8b 42
RIP [810cec30] audit_copy_inode+0x10/0x90
 RSP 8801f88dfc58
CR2: 0040
---[ end trace bcccee9a00e71a3b ]---


On Tue, Jul 31, 2012 at 4:02 PM, Peter Moody pmo...@google.com wrote:
 I seem to have a reliable oops from 3.5.0-rc6 from Linus's tree. I've
 bisected it down to, I think, the following commit:

 7157486541bffc0dfec912e21ae639b029dae3d3

 The Oops:
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.471368] Pid: 2643, comm:
 cc1 Not tainted 3.5.0-rc6-at17+ #33 LENOVO 4291AK7/4291AK7
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.472342] RIP:
 0010:[810cec30]  [810cec30]
 audit_copy_inode+0x10/0x90
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.473300] RSP:
 0018:8801f88dfc58  EFLAGS: 00010282
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.474253] RAX:
 8801fb32 RBX: 8801f887c508 RCX: c7e8
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.475210] RDX:
  RSI: 8801f3f1d970 RDI: 8801f887c508
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.476172] RBP:
 8801f88dfc88 R08:  R09: 
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.477138] R10:
 0001 R11:  R12: 8801f3f1d970
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.478236] R13:
 8801f887c4a8 R14:  R15: 
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.479218] FS:
 7fd6b9473700() GS:88021520()
 knlGS:
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.480182] CS:  0010 DS: 
 ES:  CR0: 80050033
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.481143] CR2:
 0040 CR3: 00020f6a3000 CR4: 000407e0
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.482142] DR0:
  DR1:  DR2: 
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.483121] DR3:
  DR6: 0ff0 DR7: 0400
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.484094] Process cc1 (pid:
 2643, threadinfo 8801f88de000, task 8801fb32)
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.485070] Stack:
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.486030]  8161c6fe
 8801f887c508 8801f3f1d970 8801f887c4a8
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.487011]  8801f887c508
 8801f3f1d970 8801f88dfcf8 810d237c
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.487995]  810d22bb
  8801f3f1d970 8801f4575e40
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.488981] Call Trace:
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.489957]
 [8161c6fe] ? mutex_unlock+0xe/0x10
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.490934]
 [810d237c] __audit_inode+0x13c/0x2a0
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.491927]
 [810d22bb] ? __audit_inode+0x7b/0x2a0
 Jul 31 15:32:11 pmoody-x220 kernel: [  108.492916]
 [8117b44c] do_last+0x7ac/0xa90
 Jul 31 15:32:11

Re: Oops in audit_copy_inode

2012-08-01 Thread Miklos Szeredi 
Hi Peter,

Thanks for the report.

Here's a patch.  I haven't tested it but I'm pretty confident that it
fixes the bug.

Thanks,
Miklos


Subject: vfs: fix audit_inode on negative dentry
From: Miklos Szeredi mszer...@suse.cz

Peter Moody reported an oops in audit_copy_inode() and bisected it to commit
7157486541 (vfs: do_last(): common slow lookup).

The problem is that audit_inode() in do_last() is called with a negative dentry.

Previously the non-O_CREAT case didn't call audit_inode() here, but now both
O_CREAT and non-O_CREAT opens are handled by the same code.

I really have no idea why this audit_inode() is needed here at all but am afaid
to remove this for fear of breaking audit somehow.  So just fix this case by
checking for a negative dentry.

Reported-by: Peter Moody pmo...@google.com
Signed-off-by: Miklos Szeredi mszer...@suse.cz
CC: sta...@vger.kernel.org
---
 fs/namei.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

Index: linux-2.6/fs/namei.c
===
--- linux-2.6.orig/fs/namei.c   2012-08-01 17:47:28.0 +0200
+++ linux-2.6/fs/namei.c2012-08-01 17:49:26.0 +0200
@@ -2607,10 +2607,12 @@ static int do_last(struct nameidata *nd,
goto finish_open_created;
}
 
-   /*
-* It already exists.
-*/
-   audit_inode(pathname, path-dentry);
+   if (path-dentry-d_inode) {
+   /*
+* It already exists.
+*/
+   audit_inode(pathname, path-dentry);
+   }
 
/*
 * If atomic_open() acquired write access it is dropped now due to


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

Re: Oops in audit_copy_inode

2012-08-01 Thread Peter Moody 
On Wed, Aug 1, 2012 at 9:11 AM, Miklos Szeredi mszer...@suse.cz wrote:
 Hi Peter,

 Thanks for the report.

 Here's a patch.  I haven't tested it but I'm pretty confident that it
 fixes the bug.

 Thanks,
 Miklos

Ack. I can confirm that I don't Oops with this patch.

Thanks!

Cheers,
peter

-- 
Peter Moody  Google
Security Engineer  pgp:0xC3410038
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/