Re: forced umount?
Pekka J Enberg wrote: We never want to _abort_ pending updates only pending reads. So, even with revoke(), we need to be careful which is why we do do_fsync() in generic_revoke_file() to make sure pending updates are flushed before we declare the inode revoked. But, I haven't looked at forced unmount that much so there may be other issues I am not aware of. For the purposes of this thread we _do_ want to abort pending updates to force the system to give up on a broken block device rather than block a bunch of tasks in the D state forever. - 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: forced umount?
Pekka J Enberg wrote: We never want to _abort_ pending updates only pending reads. So, even with revoke(), we need to be careful which is why we do do_fsync() in generic_revoke_file() to make sure pending updates are flushed before we declare the inode revoked. But, I haven't looked at forced unmount that much so there may be other issues I am not aware of. For the purposes of this thread we _do_ want to abort pending updates to force the system to give up on a broken block device rather than block a bunch of tasks in the D state forever. - 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: forced umount?
On Mon, 26 Mar 2007, Phillip Susi wrote: > Is this revoke system supported for the filesystem as a whole? I thought it > was just to force specific files closed, not the whole filesystem. What if > the filesystem itself has pending IO to say, update inodes or block bitmaps? > Can these be aborted? We never want to _abort_ pending updates only pending reads. So, even with revoke(), we need to be careful which is why we do do_fsync() in generic_revoke_file() to make sure pending updates are flushed before we declare the inode revoked. But, I haven't looked at forced unmount that much so there may be other issues I am not aware of. Pekka - 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: forced umount?
Is this revoke system supported for the filesystem as a whole? I thought it was just to force specific files closed, not the whole filesystem. What if the filesystem itself has pending IO to say, update inodes or block bitmaps? Can these be aborted? Pekka Enberg wrote: FYI, the revoke implementation have since been changed to follow the badfs-style approach of the forced unmount patches. However, there are some problems with the forced unmount patches that are now fixed in the revoke implementation: - You can't use munmap() to take down shared memory mappings because the application can accidentally remap something completely different to that region. - The ->f_light bits slow down other fget_light() users and there's a race between fcheck_files() and set_f_light(). - The operation can live-lock if a malicious process keeps forking. The revoke implementation solves this by revoking in two passes: (1) take down the descriptors and (2) take down the actual inodes. Pekka - 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: forced umount?
On Sun, Mar 18, 2007 at 08:16:19PM +0100, Arjan van de Ven wrote: > On Fri, 2007-03-16 at 23:06 -0500, Mike Snitzer wrote: > > I'm interested in understanding the state of Linux with regard to > > _really_ forcing a filesystem to unmount. > > > > There is a (stale) project at OSDL that has various implementations: > > http://developer.osdl.org/dev/fumount/ > > > the problem with the people who say they want forced umount is.. that > most of the time they either want > 1) get rid of the namespace entry > or > 2) want to stop any and all IO to a certain device/partition > > 1) is already supported with lazy umount (umount -l) > for 2), it's not forced umount that they want, it's really an IO > disconnect (which scsi supports btw in 2.6 kernels). Could please tell me more about this IO disconnect? How to trigger it etc, any pointers welcome. thanks, -- pozsy - 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: forced umount?
On Sun, Mar 18, 2007 at 08:16:19PM +0100, Arjan van de Ven wrote: On Fri, 2007-03-16 at 23:06 -0500, Mike Snitzer wrote: I'm interested in understanding the state of Linux with regard to _really_ forcing a filesystem to unmount. There is a (stale) project at OSDL that has various implementations: http://developer.osdl.org/dev/fumount/ the problem with the people who say they want forced umount is.. that most of the time they either want 1) get rid of the namespace entry or 2) want to stop any and all IO to a certain device/partition 1) is already supported with lazy umount (umount -l) for 2), it's not forced umount that they want, it's really an IO disconnect (which scsi supports btw in 2.6 kernels). Could please tell me more about this IO disconnect? How to trigger it etc, any pointers welcome. thanks, -- pozsy - 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: forced umount?
Is this revoke system supported for the filesystem as a whole? I thought it was just to force specific files closed, not the whole filesystem. What if the filesystem itself has pending IO to say, update inodes or block bitmaps? Can these be aborted? Pekka Enberg wrote: FYI, the revoke implementation have since been changed to follow the badfs-style approach of the forced unmount patches. However, there are some problems with the forced unmount patches that are now fixed in the revoke implementation: - You can't use munmap() to take down shared memory mappings because the application can accidentally remap something completely different to that region. - The -f_light bits slow down other fget_light() users and there's a race between fcheck_files() and set_f_light(). - The operation can live-lock if a malicious process keeps forking. The revoke implementation solves this by revoking in two passes: (1) take down the descriptors and (2) take down the actual inodes. Pekka - 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: forced umount?
On Mon, 26 Mar 2007, Phillip Susi wrote: Is this revoke system supported for the filesystem as a whole? I thought it was just to force specific files closed, not the whole filesystem. What if the filesystem itself has pending IO to say, update inodes or block bitmaps? Can these be aborted? We never want to _abort_ pending updates only pending reads. So, even with revoke(), we need to be careful which is why we do do_fsync() in generic_revoke_file() to make sure pending updates are flushed before we declare the inode revoked. But, I haven't looked at forced unmount that much so there may be other issues I am not aware of. Pekka - 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: forced umount?
On Mar 18 2007 14:13, Matthew Wilcox wrote: > >Equally, if one has one's ogg collection stored on said NFS server, the >ogg player will be in uninterruptible sleep while holding the sound device >open, preventing other applications from making sounds. Only if you have - a card with no hardware mixing or - using the obsolete OSS :) Jan -- - 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: forced umount?
On 3/18/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: On Fri, 2007-03-16 at 23:06 -0500, Mike Snitzer wrote: > I'm interested in understanding the state of Linux with regard to > _really_ forcing a filesystem to unmount. > > There is a (stale) project at OSDL that has various implementations: > http://developer.osdl.org/dev/fumount/ the problem with the people who say they want forced umount is.. that most of the time they either want 1) get rid of the namespace entry or 2) want to stop any and all IO to a certain device/partition 1) is already supported with lazy umount (umount -l) for 2), it's not forced umount that they want, it's really an IO disconnect (which scsi supports btw in 2.6 kernels). So.. depending on which of the 2 you are, it's there. Just it's not called "forced umount". I'd be interested to know more about the IO disconnect support. Do you have any pointers on what interfaces are exposed to trigger such an event? The problem I'd like to solve is this: A mounted blockdevice is considered "bad". Given the device is "bad" I don't care about flushing any outstanding IO. I'd like the ability to purge that blockdevice from the system; dropping all IOs on the floor. This would have to include invalidating inodes and more no? Ultimately the superblock would need to be released too right? Would this happen for free with IO disconnect? Does IO disconnect reliably and cleanly sever all associations a mounted blockdevice has with Linux? - 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: forced umount?
On Sun, Mar 18, 2007 at 08:16:19PM +0100, Arjan van de Ven wrote: > the problem with the people who say they want forced umount is.. that > most of the time they either want > 1) get rid of the namespace entry > or > 2) want to stop any and all IO to a certain device/partition There is a third component - they want to deliver a fatal signal to all processes which are waiting on IO to that sb. My scenario here is a machine with an NFS mount of a server which has gone down. Cronjobs which scan the whole filesystem (eg updatedb) soon pile up sleeping on access. Equally, if one has one's ogg collection stored on said NFS server, the ogg player will be in uninterruptible sleep while holding the sound device open, preventing other applications from making sounds. It's desirable to be able to kill these apps dead, and the usual suggestion of 'mount it soft,intr' isn't the greatest idea (and somewhat hard to change after the fact). I remember Linus suggesting a sleeping state between UNINTERRUPTIBLE and INTERRUPTIBLE which would be FATAL_SIGNALS_ONLY. The usual problem (of short reads) isn't a problem if the task is only going to die when it receives them. Has anyone investigated this in any detail? Perhaps I'll take a look at doing it next week. - 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: forced umount?
On Fri, 2007-03-16 at 23:06 -0500, Mike Snitzer wrote: > I'm interested in understanding the state of Linux with regard to > _really_ forcing a filesystem to unmount. > > There is a (stale) project at OSDL that has various implementations: > http://developer.osdl.org/dev/fumount/ the problem with the people who say they want forced umount is.. that most of the time they either want 1) get rid of the namespace entry or 2) want to stop any and all IO to a certain device/partition 1) is already supported with lazy umount (umount -l) for 2), it's not forced umount that they want, it's really an IO disconnect (which scsi supports btw in 2.6 kernels). So.. depending on which of the 2 you are, it's there. Just it's not called "forced umount". - 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: forced umount?
On Fri, 2007-03-16 at 23:06 -0500, Mike Snitzer wrote: I'm interested in understanding the state of Linux with regard to _really_ forcing a filesystem to unmount. There is a (stale) project at OSDL that has various implementations: http://developer.osdl.org/dev/fumount/ the problem with the people who say they want forced umount is.. that most of the time they either want 1) get rid of the namespace entry or 2) want to stop any and all IO to a certain device/partition 1) is already supported with lazy umount (umount -l) for 2), it's not forced umount that they want, it's really an IO disconnect (which scsi supports btw in 2.6 kernels). So.. depending on which of the 2 you are, it's there. Just it's not called forced umount. - 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: forced umount?
On Sun, Mar 18, 2007 at 08:16:19PM +0100, Arjan van de Ven wrote: the problem with the people who say they want forced umount is.. that most of the time they either want 1) get rid of the namespace entry or 2) want to stop any and all IO to a certain device/partition There is a third component - they want to deliver a fatal signal to all processes which are waiting on IO to that sb. My scenario here is a machine with an NFS mount of a server which has gone down. Cronjobs which scan the whole filesystem (eg updatedb) soon pile up sleeping on access. Equally, if one has one's ogg collection stored on said NFS server, the ogg player will be in uninterruptible sleep while holding the sound device open, preventing other applications from making sounds. It's desirable to be able to kill these apps dead, and the usual suggestion of 'mount it soft,intr' isn't the greatest idea (and somewhat hard to change after the fact). I remember Linus suggesting a sleeping state between UNINTERRUPTIBLE and INTERRUPTIBLE which would be FATAL_SIGNALS_ONLY. The usual problem (of short reads) isn't a problem if the task is only going to die when it receives them. Has anyone investigated this in any detail? Perhaps I'll take a look at doing it next week. - 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: forced umount?
On 3/18/07, Arjan van de Ven [EMAIL PROTECTED] wrote: On Fri, 2007-03-16 at 23:06 -0500, Mike Snitzer wrote: I'm interested in understanding the state of Linux with regard to _really_ forcing a filesystem to unmount. There is a (stale) project at OSDL that has various implementations: http://developer.osdl.org/dev/fumount/ the problem with the people who say they want forced umount is.. that most of the time they either want 1) get rid of the namespace entry or 2) want to stop any and all IO to a certain device/partition 1) is already supported with lazy umount (umount -l) for 2), it's not forced umount that they want, it's really an IO disconnect (which scsi supports btw in 2.6 kernels). So.. depending on which of the 2 you are, it's there. Just it's not called forced umount. I'd be interested to know more about the IO disconnect support. Do you have any pointers on what interfaces are exposed to trigger such an event? The problem I'd like to solve is this: A mounted blockdevice is considered bad. Given the device is bad I don't care about flushing any outstanding IO. I'd like the ability to purge that blockdevice from the system; dropping all IOs on the floor. This would have to include invalidating inodes and more no? Ultimately the superblock would need to be released too right? Would this happen for free with IO disconnect? Does IO disconnect reliably and cleanly sever all associations a mounted blockdevice has with Linux? - 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: forced umount?
On Mar 18 2007 14:13, Matthew Wilcox wrote: Equally, if one has one's ogg collection stored on said NFS server, the ogg player will be in uninterruptible sleep while holding the sound device open, preventing other applications from making sounds. Only if you have - a card with no hardware mixing or - using the obsolete OSS :) Jan -- - 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: forced umount?
On 3/17/07, Mike Snitzer <[EMAIL PROTECTED]> wrote: Thanks for the heads up; its good to see that Pekka Enberg's work has continued. I actually stumbled onto that line of work earlier while searching for more info on Tigran Aivazian's forced unmount (badfs) patches: http://lwn.net/Articles/192632/ FYI, the revoke implementation have since been changed to follow the badfs-style approach of the forced unmount patches. However, there are some problems with the forced unmount patches that are now fixed in the revoke implementation: - You can't use munmap() to take down shared memory mappings because the application can accidentally remap something completely different to that region. - The ->f_light bits slow down other fget_light() users and there's a race between fcheck_files() and set_f_light(). - The operation can live-lock if a malicious process keeps forking. The revoke implementation solves this by revoking in two passes: (1) take down the descriptors and (2) take down the actual inodes. Pekka - 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: forced umount?
On 3/17/07, Mike Snitzer [EMAIL PROTECTED] wrote: Thanks for the heads up; its good to see that Pekka Enberg's work has continued. I actually stumbled onto that line of work earlier while searching for more info on Tigran Aivazian's forced unmount (badfs) patches: http://lwn.net/Articles/192632/ FYI, the revoke implementation have since been changed to follow the badfs-style approach of the forced unmount patches. However, there are some problems with the forced unmount patches that are now fixed in the revoke implementation: - You can't use munmap() to take down shared memory mappings because the application can accidentally remap something completely different to that region. - The -f_light bits slow down other fget_light() users and there's a race between fcheck_files() and set_f_light(). - The operation can live-lock if a malicious process keeps forking. The revoke implementation solves this by revoking in two passes: (1) take down the descriptors and (2) take down the actual inodes. Pekka - 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: forced umount?
On 3/16/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: Mike Snitzer wrote: > Is this forced umount work even considered worthwhile by the greater > Linux community? Is anyone actively working on this? Have a look at all the discussion about revoke/frevoke on lkml over the last week or two. Thanks for the heads up; its good to see that Pekka Enberg's work has continued. I actually stumbled onto that line of work earlier while searching for more info on Tigran Aivazian's forced unmount (badfs) patches: http://lwn.net/Articles/192632/ Mike - 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: forced umount?
On Saturday 17 March 2007, Mike Snitzer wrote: >I'm interested in understanding the state of Linux with regard to >_really_ forcing a filesystem to unmount. > >There is a (stale) project at OSDL that has various implementations: >http://developer.osdl.org/dev/fumount/ > >Its fairly clear that these efforts (e.g. badfs patches) haven't been >given serious consideration for upstream inclusion. Do others see >value in the ability to _reliably_ force a umount by having Linux >discard all IOs, open files, dirty inode buffers, etc of a "bad" >blockdevice? The goal is to not impact the availability or integrity >of Linux while doing so. > >Is this forced umount work even considered worthwhile by the greater >Linux community? Is anyone actively working on this? Having been 'caught out' on this subject more than a few times, usually by shutting down a remotely located box that was mounted via smb or cifs, and found the only way to get sanity back to the rest of the system was a hard reset of every other box that was also sharing that mount, I would think this is a worthwhile project. Take that as a yes vote, from somebody who isn't franchised to vote on it in the first place, I'm just a user, usually playing the part of the canary in the coal mine. >Mike -- 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) QOTD: "There may be no excuse for laziness, but I'm sure looking." - 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: forced umount?
Mike Snitzer wrote: > Is this forced umount work even considered worthwhile by the greater > Linux community? Is anyone actively working on this? Have a look at all the discussion about revoke/frevoke on lkml over the last week or two. 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/
forced umount?
I'm interested in understanding the state of Linux with regard to _really_ forcing a filesystem to unmount. There is a (stale) project at OSDL that has various implementations: http://developer.osdl.org/dev/fumount/ Its fairly clear that these efforts (e.g. badfs patches) haven't been given serious consideration for upstream inclusion. Do others see value in the ability to _reliably_ force a umount by having Linux discard all IOs, open files, dirty inode buffers, etc of a "bad" blockdevice? The goal is to not impact the availability or integrity of Linux while doing so. Is this forced umount work even considered worthwhile by the greater Linux community? Is anyone actively working on this? Mike - 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/
forced umount?
I'm interested in understanding the state of Linux with regard to _really_ forcing a filesystem to unmount. There is a (stale) project at OSDL that has various implementations: http://developer.osdl.org/dev/fumount/ Its fairly clear that these efforts (e.g. badfs patches) haven't been given serious consideration for upstream inclusion. Do others see value in the ability to _reliably_ force a umount by having Linux discard all IOs, open files, dirty inode buffers, etc of a bad blockdevice? The goal is to not impact the availability or integrity of Linux while doing so. Is this forced umount work even considered worthwhile by the greater Linux community? Is anyone actively working on this? Mike - 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: forced umount?
Mike Snitzer wrote: Is this forced umount work even considered worthwhile by the greater Linux community? Is anyone actively working on this? Have a look at all the discussion about revoke/frevoke on lkml over the last week or two. 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: forced umount?
On Saturday 17 March 2007, Mike Snitzer wrote: I'm interested in understanding the state of Linux with regard to _really_ forcing a filesystem to unmount. There is a (stale) project at OSDL that has various implementations: http://developer.osdl.org/dev/fumount/ Its fairly clear that these efforts (e.g. badfs patches) haven't been given serious consideration for upstream inclusion. Do others see value in the ability to _reliably_ force a umount by having Linux discard all IOs, open files, dirty inode buffers, etc of a bad blockdevice? The goal is to not impact the availability or integrity of Linux while doing so. Is this forced umount work even considered worthwhile by the greater Linux community? Is anyone actively working on this? Having been 'caught out' on this subject more than a few times, usually by shutting down a remotely located box that was mounted via smb or cifs, and found the only way to get sanity back to the rest of the system was a hard reset of every other box that was also sharing that mount, I would think this is a worthwhile project. Take that as a yes vote, from somebody who isn't franchised to vote on it in the first place, I'm just a user, usually playing the part of the canary in the coal mine. Mike -- 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) QOTD: There may be no excuse for laziness, but I'm sure looking. - 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: forced umount?
On 3/16/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Mike Snitzer wrote: Is this forced umount work even considered worthwhile by the greater Linux community? Is anyone actively working on this? Have a look at all the discussion about revoke/frevoke on lkml over the last week or two. Thanks for the heads up; its good to see that Pekka Enberg's work has continued. I actually stumbled onto that line of work earlier while searching for more info on Tigran Aivazian's forced unmount (badfs) patches: http://lwn.net/Articles/192632/ Mike - 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/
