Re: [2.6 patch] remove smbfs

On Wed, 30 Jan 2008 19:30:55 -0600 "Steve French" <[EMAIL PROTECTED]> wrote: > On Jan 30, 2008 7:13 PM, Jeff Layton <[EMAIL PROTECTED]> wrote: > > On Thu, 31 Jan 2008 02:47:17 +0200 > > > > > > > In addition, cifs cannot completely replace smbfs atm. > > > > > > > Even todays sold NAS-boxes

Re: questions on NAPI processing latency and dropped network packets

On Tue, 15 Jan 2008 08:47:07 -0600 "Chris Friesen" <[EMAIL PROTECTED]> wrote: > Jarek Poplawski wrote: > > > IMHO, checking this with a current stable, which probably you are going > > to do some day, anyway, should be 100% acceptable: giving some input to > > netdev, while still working for

Re: questions on NAPI processing latency and dropped network packets

On Tue, 15 Jan 2008 08:47:07 -0600 Chris Friesen [EMAIL PROTECTED] wrote: Jarek Poplawski wrote: IMHO, checking this with a current stable, which probably you are going to do some day, anyway, should be 100% acceptable: giving some input to netdev, while still working for yourself.

Re: Trailing periods in kernel messages

On Sat, 22 Dec 2007 15:04:16 +0100 Benny Amorsen <[EMAIL PROTECTED]> wrote: > It is a bit of a mystery why the kernel is ordering me to initialize > the current offset of xfs_file_readdir though. I don't know how to do > that, so I guess it's lucky that I don't use XFS. Who knows what would >

Re: Trailing periods in kernel messages

On Sat, 22 Dec 2007 15:04:16 +0100 Benny Amorsen [EMAIL PROTECTED] wrote: It is a bit of a mystery why the kernel is ordering me to initialize the current offset of xfs_file_readdir though. I don't know how to do that, so I guess it's lucky that I don't use XFS. Who knows what would happen if

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

On Wed, 19 Dec 2007 21:11:11 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: > Hello. > > Radoslaw Szkodzinski (AstralStorm) wrote: > > Actually, who needs to create device nodes? Just prohibit everyone from > > creating them, except "installer" and "

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

On Wed, 19 Dec 2007 21:11:11 +0900 Tetsuo Handa [EMAIL PROTECTED] wrote: Hello. Radoslaw Szkodzinski (AstralStorm) wrote: Actually, who needs to create device nodes? Just prohibit everyone from creating them, except installer and udev personality. This means removing CAP_MKNOD

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

On Mon, 17 Dec 2007 16:30:54 +1030 David Newall <[EMAIL PROTECTED]> wrote: > Tetsuo Handa wrote: > > If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...] > > Bob can't do that. Only root can. Not even root can, if you remove him the capability. Only udev can. (which

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

On Mon, 17 Dec 2007 16:05:31 +0300 Al Boldi <[EMAIL PROTECTED]> wrote: > Indan Zupancic wrote: > > On Mon, December 17, 2007 01:40, Tetsuo Handa wrote: > > I think you can better spend your time on read-only bind mounts. > > That would be too coarse. > Actually, who needs to create device

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

On Mon, 17 Dec 2007 16:05:31 +0300 Al Boldi [EMAIL PROTECTED] wrote: Indan Zupancic wrote: On Mon, December 17, 2007 01:40, Tetsuo Handa wrote: I think you can better spend your time on read-only bind mounts. That would be too coarse. Actually, who needs to create device nodes? Just

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

On Mon, 17 Dec 2007 16:30:54 +1030 David Newall [EMAIL PROTECTED] wrote: Tetsuo Handa wrote: If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...] Bob can't do that. Only root can. Not even root can, if you remove him the capability. Only udev can. (which possibly

Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks

On Mon, 3 Dec 2007 14:29:56 +0100 > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > feedback about an impending catastrophy has been duly noted > > > > The point was less about an impending catastrophe, but more of a > > timebomb ticking until the next widely used release. I think I know why

Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks

On Mon, 3 Dec 2007 10:55:01 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > On Sun, Dec 02, 2007 at 04:59:13PM -0800, Arjan van de Ven wrote: > > On Mon, 3 Dec 2007 01:07:41 +0100 > > Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > > This patch will likely work against that by breaking error paths.

Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks

On Mon, 3 Dec 2007 10:55:01 +0100 Andi Kleen [EMAIL PROTECTED] wrote: On Sun, Dec 02, 2007 at 04:59:13PM -0800, Arjan van de Ven wrote: On Mon, 3 Dec 2007 01:07:41 +0100 Andi Kleen [EMAIL PROTECTED] wrote: This patch will likely work against that by breaking error paths. it won't

Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks

On Mon, 3 Dec 2007 14:29:56 +0100 * Andi Kleen [EMAIL PROTECTED] wrote: feedback about an impending catastrophy has been duly noted The point was less about an impending catastrophe, but more of a timebomb ticking until the next widely used release. I think I know why Andi is so

Re: Is it possible to give the user the option to cancel forkbombs?

On Sat, 17 Nov 2007 09:55:01 -0800 Dane Mutters <[EMAIL PROTECTED]> wrote: > I don't know if this is at all feasible, but is it possible to have a > mechanism that would detect a fork bomb in progress and either stop the > fork, or allow the user to cancel the operation? For example, are there >

Re: Is it possible to give the user the option to cancel forkbombs?

On Sat, 17 Nov 2007 09:55:01 -0800 Dane Mutters [EMAIL PROTECTED] wrote: I don't know if this is at all feasible, but is it possible to have a mechanism that would detect a fork bomb in progress and either stop the fork, or allow the user to cancel the operation? For example, are there any

Re: Possibility to adjust the only-root-can-bind-to-port-under-1024 limit

On Tue, 20 Nov 2007 17:09:35 +0100 Mikael Ståldal <[EMAIL PROTECTED]> wrote: > Hello. > > > The proper way to enable port <= 1024 binding support is adding > > CAP_NET_BIND_SERVICE > > to the process capability set, e.g. by using file-system capabilities. > > Is file-system capabilites part

Re: Possibility to adjust the only-root-can-bind-to-port-under-1024 limit

On Tue, 20 Nov 2007 11:14:59 +0100 Mikael Ståldal <[EMAIL PROTECTED]> wrote: > In Linux you have to be root in order to listen to TCP or UDP ports below > 1024 (the > well-known ports). As far as I know, this limit is hardcoded in the kernel. > > In some cases, this limit do more harm than

Re: Possibility to adjust the only-root-can-bind-to-port-under-1024 limit

On Tue, 20 Nov 2007 11:14:59 +0100 Mikael Ståldal [EMAIL PROTECTED] wrote: In Linux you have to be root in order to listen to TCP or UDP ports below 1024 (the well-known ports). As far as I know, this limit is hardcoded in the kernel. In some cases, this limit do more harm than good, so

Re: Possibility to adjust the only-root-can-bind-to-port-under-1024 limit

On Tue, 20 Nov 2007 17:09:35 +0100 Mikael Ståldal [EMAIL PROTECTED] wrote: Hello. The proper way to enable port = 1024 binding support is adding CAP_NET_BIND_SERVICE to the process capability set, e.g. by using file-system capabilities. Is file-system capabilites part of the stable

Re: [poll] Is the megafreeze development model broken?

On Mon, 12 Nov 2007 17:53:06 + (UTC) Tuomo Valkonen <[EMAIL PROTECTED]> wrote: > The complement of "open source" is not closed source, or at least > "source not available". (And I doubt it's even illegal to look at > source you have somehow got.) It includes so-called license-free > or

Re: [poll] Is the megafreeze development model broken?

On Mon, 12 Nov 2007 17:53:06 + (UTC) Tuomo Valkonen [EMAIL PROTECTED] wrote: The complement of open source is not closed source, or at least source not available. (And I doubt it's even illegal to look at source you have somehow got.) It includes so-called license-free or license-less

Re: 2.6.13-rc3-mm3 question

opment kernel. That's why my stable machine uses latest release kernel, and only after it's broken in by at least a week. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpexWeWujlaI.pgp Description: PGP signature

Re: 2.6.13-rc3-mm3 question

On Thu, 28 Jul 2005 10:55:51 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > It's there in the patch? Well, I didn't check there. Poor stupid me. > There are always glitches, I'm afraid. But there could be less build breakers at least. -- AstralStorm GPG Key ID = 0xD1F1

2.6.13-rc3-mm3 question

releasing a secret release just right before -mm in order to avoid problems like that MTRR problem? -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpxyt5wCmz3i.pgp Description: PGP signature

2.6.13-rc3-mm3 question

releasing a secret release just right before -mm in order to avoid problems like that MTRR problem? -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpxyt5wCmz3i.pgp Description: PGP signature

Re: 2.6.13-rc3-mm3 question

On Thu, 28 Jul 2005 10:55:51 -0700 Andrew Morton [EMAIL PROTECTED] wrote: It's there in the patch? Well, I didn't check there. Poor stupid me. There are always glitches, I'm afraid. But there could be less build breakers at least. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint

Re: 2.6.13-rc3-mm3 question

machine uses latest release kernel, and only after it's broken in by at least a week. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpexWeWujlaI.pgp Description: PGP signature

Re: MM kernels - how to keep on the bleeding edge?

n the directory above, -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpcNiBSpWL7C.pgp Description: PGP signature

Re: MM kernels - how to keep on the bleeding edge?

On Tue, 26 Jul 2005 16:11:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > All done - let me know if it needs anything else. > You got me with a tarball w/o a directory inside. Now I have to clean up the mess. Not the first time in life. I think I'll never learn. :) -- A

Re: MM kernels - how to keep on the bleeding edge?

Great! > The kernel.org propagation delay is a bit of a hassle. I could use > zip.com.au but I suspect they hate me enough already. > Right now the delay is about one hour. I can certainly live with that. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0

Re: MM kernels - how to keep on the bleeding edge?

compile, let alone run. > I could also send a notification to mm-commits when I do so. Would that > help? > Really, it would. Especially if it contained an up-to-date series file. I'd be very grateful. (And would test and fix it up some more.) -- AstralStorm GPG Key ID = 0xD1F10BA2

Re: MM kernels - how to keep on the bleeding edge?

ITA. I could use RSS to do this, but some patches may still hit the wrong folder. What's more it would create unnecessary network load. There are sometimes only a few minutes between "patch in -mm1" and "patch in -mm2". -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 9

MM kernels - how to keep on the bleeding edge?

available somewhere, but I can live with my mail reading script. (I'm not subscribed to the list at the time - my mailbox would blow up) -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpha6xwJWwph.pgp

MM kernels - how to keep on the bleeding edge?

available somewhere, but I can live with my mail reading script. (I'm not subscribed to the list at the time - my mailbox would blow up) -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpha6xwJWwph.pgp

Re: MM kernels - how to keep on the bleeding edge?

network load. There are sometimes only a few minutes between patch in -mm1 and patch in -mm2. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpGaiSKulH6J.pgp Description: PGP signature

Re: MM kernels - how to keep on the bleeding edge?

? Really, it would. Especially if it contained an up-to-date series file. I'd be very grateful. (And would test and fix it up some more.) -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can

Re: MM kernels - how to keep on the bleeding edge?

of a hassle. I could use zip.com.au but I suspect they hate me enough already. Right now the delay is about one hour. I can certainly live with that. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can

Re: MM kernels - how to keep on the bleeding edge?

On Tue, 26 Jul 2005 16:11:49 -0700 Andrew Morton [EMAIL PROTECTED] wrote: All done - let me know if it needs anything else. You got me with a tarball w/o a directory inside. Now I have to clean up the mess. Not the first time in life. I think I'll never learn. :) -- AstralStorm GPG Key

Re: MM kernels - how to keep on the bleeding edge?

, -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpcNiBSpWL7C.pgp Description: PGP signature

Re: [ck] Re: 2.6.12-ck3

TSC I think. The solution was to enable HPET and/or enable ACPI PM Timer. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpVqvtRPfcHf.pgp Description: PGP signature

Re: [ck] Re: 2.6.12-ck3

Timer. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpVqvtRPfcHf.pgp Description: PGP signature