Re: Integration of SCST in the mainstream Linux kernel
On Mon, 2008-02-04 at 22:43 +, Alan Cox wrote: > > better. So for example, I personally suspect that ATA-over-ethernet is way > > better than some crazy SCSI-over-TCP crap, but I'm biased for simple and > > low-level, and against those crazy SCSI people to begin with. > > Current ATAoE isn't. It can't support NCQ. A variant that did NCQ and IP > would probably trash iSCSI for latency if nothing else. But ATAoE is boring because it's not IP. Which means no routing, firewalls, tunnels, congestion control, etc. NBD and iSCSI (for all its hideous growths) can take advantage of these things. -- Mathematics is the supreme nostalgia of our time. -- 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: Integration of SCST in the mainstream Linux kernel
On Mon, 2008-02-04 at 16:24 -0800, Linus Torvalds wrote: > > On Mon, 4 Feb 2008, Matt Mackall wrote: > > > > But ATAoE is boring because it's not IP. Which means no routing, > > firewalls, tunnels, congestion control, etc. > > The thing is, that's often an advantage. Not just for performance. > > > NBD and iSCSI (for all its hideous growths) can take advantage of these > > things. > > .. and all this could equally well be done by a simple bridging protocol > (completely independently of any AoE code). > > The thing is, iSCSI does things at the wrong level. It *forces* people to > use the complex protocols, when it's a known that a lot of people don't > want it. I frankly think NBD is at a pretty comfortable level. It's internally very simple (and hardware-agnostic). And moderately easy to do in silicon. But I'm not going to defend iSCSI. I worked on the first implementation (what became the Cisco iSCSI driver) and I have no love for iSCSI at all. It should have been (and started out as) a nearly trivial encapsulation of SCSI over TCP much like ATA over Ethernet but quickly lost the plot when committees got ahold of it. -- Mathematics is the supreme nostalgia of our time. -- 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.24-mm1] TCP/IPv6 connect() oopses at twothirdsMD4Transform()
On Mon, 2008-02-04 at 17:36 -0800, Andrew Morton wrote: > On Tue, 05 Feb 2008 10:28:43 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: > > > Hello. > > > > Kernel config is at http://I-love.SAKURA.ne.jp/tmp/config-2.6.24-mm1 > > > > 2.6.24 works fine. > err, Matt? random: revert braindamage that snuck into checkpatch cleanup Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> diff -r 50a6e531a9f2 drivers/char/random.c --- a/drivers/char/random.c Mon Feb 04 20:23:02 2008 -0600 +++ b/drivers/char/random.c Mon Feb 04 20:28:08 2008 -0600 @@ -1306,7 +1306,7 @@ * Rotation is separate from addition to prevent recomputation */ #define ROUND(f, a, b, c, d, x, s) \ - (a += f(b, c, d) + in[x], a = (a << s) | (a >> (32 - s))) + (a += f(b, c, d) + x, a = (a << s) | (a >> (32 - s))) #define K1 0 #define K2 013240474631UL #define K3 015666365641UL -- Mathematics is the supreme nostalgia of our time. -- 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] [RESENDING] netconsole: register cmdline netconsole configs to configfs
On Mon, 2008-02-11 at 18:08 +0900, Joonwoo Park wrote: > This patch intorduces cmdline netconsole configs to register to > configfs > with dynamic netconsole. Satyam Sharma who designed shiny dynamic > reconfiguration for netconsole, mentioned about this issue already. > (http://lkml.org/lkml/2007/7/29/360) > But I think, without separately managing of two kind of netconsole > target > objects, it's possible by using config_group instead of > config_item in the netconsole_target and default_groups feature of > configfs. > > Patch was tested with configuration creation/destruction by kernel and > module. > And it makes possible to enable/disable, modify and review netconsole > target configs from cmdline. I'm afraid I'm going to have to leave review of this to someone who is clueful about configfs. But it seems reasonable. -- Mathematics is the supreme nostalgia of our time. -- 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] slob: fix linking for user mode linux
On Tue, 2008-02-12 at 00:32 +0200, Pekka J Enberg wrote: > From: Pekka Enberg <[EMAIL PROTECTED]> > > UML has some header magic that expects a non-inline __kmalloc() function to be > available. Fixes the following link time errors: > > arch/um/drivers/built-in.o: In function `kmalloc': > /home/penberg/linux-2.6/arch/um/include/um_malloc.h:14: undefined reference > to `__kmalloc' > /home/penberg/linux-2.6/arch/um/include/um_malloc.h:14: undefined reference > to `__kmalloc' > /home/penberg/linux-2.6/arch/um/include/um_malloc.h:14: undefined reference > to `__kmalloc' > /home/penberg/linux-2.6/arch/um/include/um_malloc.h:14: undefined reference > to `__kmalloc' > /home/penberg/linux-2.6/arch/um/include/um_malloc.h:14: undefined reference > to `__kmalloc' > arch/um/drivers/built-in.o:/home/penberg/linux-2.6/arch/um/include/um_malloc.h:14: > more undefined references to `__kmalloc' follow Can someone explain why the magic is needed (and preferably capture it in a comment somewhere sensible)? I took a peek at this and have no idea what's going on. -- Mathematics is the supreme nostalgia of our time. -- 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] x86 (Linux Tiny): configure out support for some processors
On Mon, 2008-02-11 at 16:54 -0800, H. Peter Anvin wrote: > Matt Mackall wrote: > > On Mon, 2008-02-11 at 15:01 -0800, H. Peter Anvin wrote: > >> Matt Mackall wrote: > >>> Best would be to have no ifdefs and do it all with linker magic, of > >>> course. But that's trickier. > >>> > >> I concur with this, definitely. > > > > Ok, so let's come up with a plan. We can: > > > > a) use weak symbols, ala cond_syscall > > b) use a special section > > c) use early_init code (is it early enough?) > > c) have some sort of registration list > > > > Having a generic cond_call of some sort might be nice for this sort of > > thing. > > > > c) is out, because this has to be executed after the early generic code > and before the late generic code. > > b) would be my first choice, and yes, it would be a good thing to have a > generalized mechanism for this. For the registrant, it's pretty easy: > just add a macro that adds a pointer to a named section. We then need a > way to get the base address and length of each such section in order to > be able to execute each function in sequence. I like the idea of making a generalized hook section. But this is a bit burdensome for Michael's little patch (unless you have time to whip something up) so I think we should probably explore it separately. -- Mathematics is the supreme nostalgia of our time. -- 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] x86 (Linux Tiny): configure out support for some processors
On Mon, 2008-02-11 at 15:01 -0800, H. Peter Anvin wrote: > Matt Mackall wrote: > > > > Best would be to have no ifdefs and do it all with linker magic, of > > course. But that's trickier. > > > > I concur with this, definitely. Ok, so let's come up with a plan. We can: a) use weak symbols, ala cond_syscall b) use a special section c) use early_init code (is it early enough?) c) have some sort of registration list Having a generic cond_call of some sort might be nice for this sort of thing. -- Mathematics is the supreme nostalgia of our time. -- 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] Configure out DMI scanning code v2 (Linux Tiny)
On Tue, 2008-02-12 at 10:04 +0100, Thomas Petazzoni wrote: > Turn CONFIG_DMI into a selectable option if EMBEDDED is defined, in > order to be able to remove the DMI table scanning code if it's not > needed, and then reduce the kernel code size. > > With CONFIG_DMI (i.e before) : > >textdata bss dec hex filename > 1076076 128656 98304 1303036 13e1fc vmlinux > > Without CONFIG_DMI (i.e after) : > >textdata bss dec hex filename > 1068092 126308 98304 1292704 13b9a0 vmlinux > > Result: > >textdata bss dec hex filename > -7984 -2348 0 -10332 -285c vmlinux > > The new option appears in "Processor type and features", only when > CONFIG_EMBEDDED is defined. > > This patch is part of the Linux Tiny project, and is based on previous > work done by Matt Mackall <[EMAIL PROTECTED]>. > > Signed-off-by: Thomas Petazzoni <[EMAIL PROTECTED]> Thanks for working on this. Acked-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. -- 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] Configure out doublefault exception handler (Linux Tiny)
On Tue, 2008-02-12 at 15:00 +0100, Thomas Petazzoni wrote: > Hi Sam, > > Le Tue, 12 Feb 2008 14:04:28 +0100, > Sam Ravnborg <[EMAIL PROTECTED]> a écrit : > > > We already have this in arch/x86/Kconfig.debug: > > Oops, my usual "find . -name Kconfig" missed it. Thanks for pointing it > out! The fact that you didn't have to add any makefile bits should have been a hint. > > It may need a small update if this is valid for both 32 and 64 bit. > > Doesn't seem so: there's only a doublefault_32.c, no doublefault_64.c. > However, I don't know the details of x86_64. I bet there's some doublefault-handling code hiding somewhere. It's not the sort of thing it'd make sense to take out of the architecture. -- Mathematics is the supreme nostalgia of our time. -- 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] make swap_pte_to_pagemap_entry() static
On Wed, 2008-02-13 at 23:30 +0200, Adrian Bunk wrote: > This patch makes the needlessly global swap_pte_to_pagemap_entry() > static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Thanks. Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. -- 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] Configure out doublefault exception handler (Linux Tiny)
On Fri, 2008-02-15 at 19:04 +0100, Andi Kleen wrote: > > do when it does". There's very little point in having this sort of code > > in a mass-market camera, phone, DVR, TV, etc. (of which there are > > Do any of them run with a x86 CPU? Yes. The last PVR I worked on was just such a device, as was the very first device I put Linux on (1.2 era). There are several families of x86 CPUs targeted at embedded so this shouldn't be a surprise. -- Mathematics is the supreme nostalgia of our time. -- 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] Configure out doublefault exception handler (Linux Tiny)
On Fri, 2008-02-15 at 13:00 +0100, Andi Kleen wrote:
> Matt Mackall <[EMAIL PROTECTED]> writes:
> >
> > I bet there's some doublefault-handling code hiding somewhere. It's not
> > the sort of thing it'd make sense to take out of the architecture.
>
> The big question is if it makes sense taking out of a kernel at all.
> I still think the answer is no.
>
> Or have you considered replacing die() and show_trace() etc. with a single
> panic("the tiny gods say this won't happen") yet? That would be roughly
> equivalent.
It's not a matter of "won't happen" so much as "not a damn thing we can
do when it does". There's very little point in having this sort of code
in a mass-market camera, phone, DVR, TV, etc. (of which there are
already millions running Linux). These devices have no console and
basically zero serviceability beyond firmware upgrades. If taking these
vestigial debugging features out means we can cram in more features that
consumers can actually see and will pay for, that's precisely what's
going to happen.
--
Mathematics is the supreme nostalgia of our time.
--
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/
arch/x86/mm/ioremap unification grew by 10x
In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In 2.6.25-rc1, the unified ioremap.o is 20.8k. -- Mathematics is the supreme nostalgia of our time. -- 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: arch/x86/mm/ioremap unification grew by 10x
On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote: > On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote: > > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In > > 2.6.25-rc1, the unified ioremap.o is 20.8k. > > Just an observation - 17 commits touches said file after > the unification (at least in latest -linus). Correction: those numbers should be halved. So we're going from .9k to 10.4k. -- Mathematics is the supreme nostalgia of our time. -- 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: arch/x86/mm/ioremap unification grew by 10x
On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote: > On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote: > > On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote: > > > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In > > > 2.6.25-rc1, the unified ioremap.o is 20.8k. > > > > Just an observation - 17 commits touches said file after > > the unification (at least in latest -linus). > > Correction: those numbers should be halved. So we're going from .9k to > 10.4k. And here's most of the cause: 02b8 0124 T early_ioremap 1000 1000 t bm_pte 2000 0004 T early_ioremap_debug static __initdata pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __attribute__((aligned(PAGE_SIZE))); Double ouch. First, this isn't in BSS. Second, even though it's initdata, the alignment slop won't get recovered. Don't we have a special section for page-aligned crap so it doesn't waste most of two pages? -- Mathematics is the supreme nostalgia of our time. -- 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] x86 : relocate uninitialized variable in init DATA section into init BSS section
On Thu, 2008-02-21 at 10:53 +0100, Ingo Molnar wrote: > * Huang, Ying <[EMAIL PROTECTED]> wrote: > > > > > -int __initdata early_ioremap_debug; > > > > +int __initbss early_ioremap_debug; > > > > > > will we get some sort of build error if we accidentally do: > > > > > >int __initbss early_ioremap_debug = 1; > > > > > > ? > > > > I tested it just now, and there is no build error. > > well, that's bad. We'd silently ignore the " = 1" and boot up with that > value at 0, right? At minimum we need some really prominent build-time > _errors_ (i.e. aborted builds) if this ever happens. But ideally, > shouldnt this whole thing be done at link time? Couldnt the linker sort > the variables that are zero initialized into the right section, and move > this constant maintenance pressure off the programmer's shoulder? I'm not sure if it's possible currently. But it might be possible to instead tag objects as "init" with an attribute other than section and then move such objects into init sections "by hand" late in the build. -- Mathematics is the supreme nostalgia of our time. -- 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 RFC] random: Account for entropy loss due to overwrites
On Mon, 2012-08-13 at 10:26 -0700, H. Peter Anvin wrote: > From: "H. Peter Anvin" > > When we write entropy into a non-empty pool, we currently don't > account at all for the fact that we will probabilistically overwrite > some of the entropy in that pool. Technically, no, nothing is overwritten. The key fact is that the mixing function is -reversible-. Thus, even if you mix in known data, you can't learn anything about the state and thus can't destroy any of the existing entropy. But you are correct, mixing new actual entropy is not purely additive (with saturation). For that to happen, we'd need an input mixing function with perfect maximal cascading. Instead we effectively cascade across somewhere between 6 and 64 bits. So the truth lies somewhere between linear and your exponential estimate (which would be the case for mixing a single bit into the pool with XOR), but much closer to linear due to combinatoric expansion. On the other hand, I don't think this sort of thing matters at all. There is so much more fundamentally wrong with even trying to do entropy accounting in the first place that these sorts of details don't even matter. Instead we should stop fooling ourselves and just drop the pretense of accounting entirely. Now that we've got a much richer set of inputs, I think the time is ripe... but of course, I'm no longer the maintainer. -- Mathematics is the supreme nostalgia of our time. -- 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: blackfin compile error
On Wed, 2008-02-06 at 17:18 +0200, Adrian Bunk wrote:
> Commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773 broke blackfin:
>
> <-- snip -->
>
> ...
> CC mm/vmscan.o
> In file included from
> /home/bunk/linux/kernel-2.6/git/linux-2.6/mm/vmscan.c:44:
> /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h: In
> function 'is_swap_pte':
> /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: error:
> implicit declaration of function 'pte_none'
> /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: error:
> implicit declaration of function 'pte_present'
> make[2]: *** [mm/vmscan.o] Error 1
This suggests that no one's tried to compile -mm on Blackfin since
before September, I think.
Is there somewhere more appropriate to move it? I can't find one.
Failing that, we can wrap it in CONFIG_MMU, I suppose.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
diff -r 50a6e531a9f2 include/linux/swapops.h
--- a/include/linux/swapops.h Mon Feb 04 20:23:02 2008 -0600
+++ b/include/linux/swapops.h Wed Feb 06 10:21:32 2008 -0600
@@ -42,11 +42,13 @@
return entry.val & SWP_OFFSET_MASK(entry);
}
+#ifdef CONFIG_MMU
/* check whether a pte points to a swap entry */
static inline int is_swap_pte(pte_t pte)
{
return !pte_none(pte) && !pte_present(pte) && !pte_file(pte);
}
+#endif
/*
* Convert the arch-dependent pte representation of a swp_entry_t into an
--
Mathematics is the supreme nostalgia of our time.
--
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] stub out is_swap_pte for !MMU
On Fri, 2008-02-08 at 15:02 -0500, Mike Frysinger wrote:
> With commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773, swap_pte() was moved
> into view of both MMU and !MMU, but uses functions only provided by MMU.
> Here we stub out the function for !MMU ports.
I'm not sure if this is right compared to my original patch. Does it
ever make sense to ask "is this pte a swap entry?" on a machine with no
MMU? Presumably this also means it has no ptes too, right? In which
case, it's better to comment the whole function out. Then when someone
tries to ask the above meaningless question, they get a compile error
rather than a meaningless answer.
> Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
> ---
> include/linux/swapops.h |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
> index 7bf2d14..e6b54f7 100644
> --- a/include/linux/swapops.h
> +++ b/include/linux/swapops.h
> @@ -45,7 +45,11 @@ static inline pgoff_t swp_offset(swp_entry_t entry)
> /* check whether a pte points to a swap entry */
> static inline int is_swap_pte(pte_t pte)
> {
> +#ifdef CONFIG_MMU
> return !pte_none(pte) && !pte_present(pte) && !pte_file(pte);
> +#else
> + return 0;
> +#endif
> }
>
> /*
--
Mathematics is the supreme nostalgia of our time.
--
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] stub out is_swap_pte for !MMU
On Fri, 2008-02-08 at 16:25 -0500, Mike Frysinger wrote:
> On Friday 08 February 2008, Matt Mackall wrote:
> > On Fri, 2008-02-08 at 15:02 -0500, Mike Frysinger wrote:
> > > With commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773, swap_pte() was
> > > moved into view of both MMU and !MMU, but uses functions only provided by
> > > MMU. Here we stub out the function for !MMU ports.
> >
> > I'm not sure if this is right compared to my original patch. Does it
> > ever make sense to ask "is this pte a swap entry?" on a machine with no
> > MMU? Presumably this also means it has no ptes too, right? In which
> > case, it's better to comment the whole function out. Then when someone
> > tries to ask the above meaningless question, they get a compile error
> > rather than a meaningless answer.
>
> honestly, doesnt matter to me since none of the code that currently utilizes
> this function is used in no-mmu context. if you want to just put the whole
> thing in CONFIG_MMU, then go for it.
Here it is again, I'll leave it up to Andrew:
Fix compile error on nommu for is_swap_pte
Does it ever make sense to ask "is this pte a swap entry?" on a machine
with no MMU? Presumably this also means it has no ptes too, right? In
which case, it's better to comment the whole function out. Then when
someone tries to ask the above meaningless question, they get a compile
error rather than a meaningless answer.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
diff -r 50a6e531a9f2 include/linux/swapops.h
--- a/include/linux/swapops.h Mon Feb 04 20:23:02 2008 -0600
+++ b/include/linux/swapops.h Fri Feb 08 15:38:01 2008 -0600
@@ -42,11 +42,13 @@
return entry.val & SWP_OFFSET_MASK(entry);
}
+#ifdef CONFIG_MMU
/* check whether a pte points to a swap entry */
static inline int is_swap_pte(pte_t pte)
{
return !pte_none(pte) && !pte_present(pte) && !pte_file(pte);
}
+#endif
/*
* Convert the arch-dependent pte representation of a swp_entry_t into an
--
Mathematics is the supreme nostalgia of our time.
--
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] x86 (Linux Tiny): configure out support for some processors
On Fri, 2008-02-08 at 23:47 +0100, Michael Opdenacker wrote:
> This patch against x86/mm tries to revive an original patch
> from Matt Mackall which didn't get merged at that time. It makes
> it possible to disable support code for some processors. This can
> be useful to support only the exact processor type used
> in a given system.
>
> I may have made wrong assumptions with the code handling
> force_mwait. As force_mwait is only declared in
> arch/x86/kernel/cpu/amd.c, which is only compiled
> when CONFIG_X86_32 is set, I thought it was safe
> to make the code depend on CONFIG_CPU_SUP_AMD,
> but I could be wrong.
>
> Your comments are more than welcome! To make the code
> cleaner, I could use empty inline functions instead
> of ifdef's, as suggested in Documentation/SubmittingPatches.
Please include the output of size with all these options on and off.
> diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
> index dabdbef..8f9a123 100644
> --- a/arch/x86/kernel/process_32.c
> +++ b/arch/x86/kernel/process_32.c
> @@ -287,8 +287,10 @@ static void mwait_idle(void)
>
> static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c)
> {
> +#ifdef CONFIG_CPU_SUP_AMD
> if (force_mwait)
> return 1;
> +#endif
Probably makes sense to move force_mwait (one word) here and eliminate
these ifdefs.
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index 347a8cd..812bfa0 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -211,12 +211,14 @@ static void __init kernel_physical_mapping_init(pgd_t
> *pgd_base)
> }
> }
>
> +#ifdef CONFIG_CPU_SUP_INTEL
> static inline int page_kills_ppro(unsigned long pagenr)
> {
> if (pagenr >= 0x7 && pagenr <= 0x7003F)
> return 1;
> return 0;
> }
> +#endif
> /*
> * devmem_is_allowed() checks to see if /dev/mem access to a certain address
> @@ -287,7 +289,11 @@ static void __meminit free_new_highpage(struct page
> *page)
>
> void __init add_one_highpage_init(struct page *page, int pfn, int bad_ppro)
> {
> - if (page_is_ram(pfn) && !(bad_ppro && page_kills_ppro(pfn))) {
> + if (page_is_ram(pfn)
> +#ifdef CONFIG_CPU_SUP_INTEL
> + && !(bad_ppro && page_kills_ppro(pfn))
> +#endif
Yuck. A better way to do this is move the bad_ppro check into
page_kills_ppro and then ifdef out -the body- of the inline.
> @@ -592,7 +598,11 @@ void __init mem_init(void)
> #ifdef CONFIG_FLATMEM
> BUG_ON(!mem_map);
> #endif
> +#ifdef CONFIG_CPU_SUP_INTEL
> bad_ppro = ppro_with_ram_bug();
> +#else
> + bad_ppro = 0;
> +#endif
Again, move the storage for this, let it get initialized to zero
automatically, and initialize it in the CPU-specific code (if ordering
allows).
--
Mathematics is the supreme nostalgia of our time.
--
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] stub out is_swap_pte for !MMU
On Fri, 2008-02-08 at 14:05 -0800, Andrew Morton wrote:
> On Fri, 08 Feb 2008 15:41:42 -0600
> Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > Fix compile error on nommu for is_swap_pte
> >
> > Does it ever make sense to ask "is this pte a swap entry?" on a machine
> > with no MMU? Presumably this also means it has no ptes too, right? In
> > which case, it's better to comment the whole function out. Then when
> > someone tries to ask the above meaningless question, they get a compile
> > error rather than a meaningless answer.
> >
> > Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
> >
> > diff -r 50a6e531a9f2 include/linux/swapops.h
> > --- a/include/linux/swapops.h Mon Feb 04 20:23:02 2008 -0600
> > +++ b/include/linux/swapops.h Fri Feb 08 15:38:01 2008 -0600
> > @@ -42,11 +42,13 @@
> > return entry.val & SWP_OFFSET_MASK(entry);
> > }
> >
> > +#ifdef CONFIG_MMU
> > /* check whether a pte points to a swap entry */
> > static inline int is_swap_pte(pte_t pte)
> > {
> > return !pte_none(pte) && !pte_present(pte) && !pte_file(pte);
> > }
> > +#endif
> >
>
> Seems contradictory. Is there _really_ a compilation error at present?
> The changelog seems to imply otherwise and no compiler error output is
> quoted and it all compiled OK for me on nommu superh.
Sorry, here's the compile error from the original thread (where the
original copy of the above patch was posted).
...
CC mm/vmscan.o
In file included from
/home/bunk/linux/kernel-2.6/git/linux-2.6/mm/vmscan.c:44:
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h: In function
'is_swap_pte':
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: error:
implicit declaration of function 'pte_none'
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/swapops.h:48: error:
implicit declaration of function 'pte_present'
make[2]: *** [mm/vmscan.o] Error 1
--
Mathematics is the supreme nostalgia of our time.
--
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] x86 (Linux Tiny): configure out support for some processors
On Mon, 2008-02-11 at 23:42 +0100, Michael Opdenacker wrote:
> /* Specific CPU type init functions */
> -int intel_cpu_init(void);
> -int amd_init_cpu(void);
> -int cyrix_init_cpu(void);
> -int nsc_init_cpu(void);
> -int centaur_init_cpu(void);
> -int transmeta_init_cpu(void);
> -int nexgen_init_cpu(void);
> -int umc_init_cpu(void);
> +
> +#ifdef CONFIG_CPU_SUP_INTEL
> +int __cpuinit __ppro_with_ram_bug(void);
> +static inline int __cpuinit ppro_with_ram_bug(void)
> +{
> + return __ppro_with_ram_bug();
> +}
I know Ingo said to do this, but I think he was flat-out wrong. If the
tradeoff is between having a dozen ifdefs contained in a single function
in one .c file vs wrapping a dozen function in a .h file, I say stick
them in the .c file.
Best would be to have no ifdefs and do it all with linker magic, of
course. But that's trickier.
Now the patch is 90% fiddling with wrappers and it's impossible to find
the interesting bits anymore..
--
Mathematics is the supreme nostalgia of our time.
--
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] Configure out DMI scanning code
On Mon, 2008-02-11 at 17:58 +0100, Thomas Petazzoni wrote: > Hi, > > The enclosed patch allows to remove the DMI scanning code when > CONFIG_EMBEDDED is defined. It's basically the dma_blacklist patch of > Linux-Tiny ported to 2.6.25-rc1, with the required modifications. It > allows to remove ~10k from the kernel code/data size. Looks ok. Please preserve original authorship (ie me) in some fashion in your description. > On top of this patch, I've tested if removing the big dmi tables in the > code (for example in arch/x86/kernel/reboot.c) would allow to make more > space optimizations. However, it seems that simply defining > dmi_check_system() to an empty static inlined function already allows > gcc to optimize out the dmi tables, because there are not present in > the code. Is that possible, or is my understanding incorrect ? That's possible with modern gccs, yes. -- Mathematics is the supreme nostalgia of our time. -- 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] dmi: Feed DMI table to /dev/random driver
On Fri, 2012-07-20 at 13:15 -0700, Tony Luck wrote: > Send the entire DMI (SMBIOS) table to the /dev/random driver to > help seed its pools. > > Signed-off-by: Tony Luck > --- > > This looks a useful addition to your /dev/random series. There are > lots of platform specific goodies in this table (BIOS version, system > serial number and UUID, count and version number of processors, DIMM > slot population and serial numbers, etc.) > > On the system I tested the patch on the table is 9866 bytes. Is it > OK to dump that much into add_device_randomness() in one shot? Yes, that's fine. We should also consider doing something similar with various bus enumerations (PCI, USB, SCSI) and hotplug, we might pick up similar goodies. Also, we should feed in the OF device tree on platforms that use it. -- Mathematics is the supreme nostalgia of our time. -- 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: [PATCH 01/10] random: make 'add_interrupt_randomness()' do something sane
On Fri, 2012-07-06 at 12:52 -0400, Theodore Ts'o wrote:
> On Fri, Jul 06, 2012 at 09:24:00AM -0700, Linus Torvalds wrote:
> > On Fri, Jul 6, 2012 at 6:01 AM, Theodore Ts'o wrote:
> > > What in the world is "fast count"? I've grepped for it,
> > > and I can't find it.
> >
> > It's your own fast-pool counter that Matt was talking about.
>
> When he said "check it against HZ", it confused me, since there's no
> way to compare it against HZ. But yes, I can certainly not give any
> credit for entropy if __IRQF_TIMER is set, or keep track of whether
> the previous interrupt had __IRQF_TIMER set in its descriptor. That's
> simple enough.
>
> I thought he was saying there was some way to distinguish between
> interrupts triggered by the clock interrupt versus other devices on
> the same irq channel --- and I couldn't figure out any to do that in
> an architecture independent way.
Sorry.. offline for the weekend.
Let me restate:
- on some architectures, we will call into the RNG on timer interrupts
- this is generally desirable, as most time sources are asynchronous to
sched_clock() and thus a source of entropy
- we also want to keep conditional checks like IRQF_TIMER off the fast
path
- but on systems where the timer interrupt is the primary time source,
we may get effectively no entropy when the system is quiescent
- so we should check the fast pool count against HZ before crediting
- but even then, we still should mix the fast pool
Something like:
add_some_randomness(...) /* always mix */
if (fast_pool->count > HZ) {
fast_pool->count = 0;
credit_entropy_pool(...); /* only credit when we've got > HZ events */
}
That should be safe on all systems.
--
Mathematics is the supreme nostalgia of our time.
--
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: [RFC][PATCH] make /proc/pid/pagemap work with huge pages and return page size
(sorry for the delay, travelling)
On Wed, 2008-02-20 at 14:57 +0100, Hans Rosenfeld wrote:
> The current code for /proc/pid/pagemap does not work with huge pages (on
> x86). The code will make no difference between a normal pmd and a huge
> page pmd, trying to parse the contents of the huge page as ptes. Another
> problem is that there is no way to get information about the page size a
> specific mapping uses.
>
> Also, the current way the "not present" and "swap" bits are encoded in
> the returned pfn isn't very clean, especially not if this interface is
> going to be extended.
Fair.
> I propose to change /proc/pid/pagemap to return a pseudo-pte instead of
> just a raw pfn. The pseudo-pte will contain:
>
> - 58 bits for the physical address of the first byte in the page, even
> less bits would probably be sufficient for quite a while
>
> - 4 bits for the page size, with 0 meaning native page size (4k on x86,
> 8k on alpha, ...) and values 1-15 being specific to the architecture
> (I used 1 for 2M, 2 for 4M and 3 for 1G for x86)
>
> - a "swap" bit indicating that a not present page is paged out, with the
> physical address field containing page file number and block number
> just like before
>
> - a "present" bit just like in a real pte
This is ok-ish, but I can't say I like it much. Especially the page size
field.
But I don't really have many ideas here. Perhaps having a bit saying
"this entry is really a continuation of the previous one". Then any page
size can be trivially represented. This might also make the code on both
sides simpler?
> By shortening the field for the physical address, some more interesting
> information could be included, like read/write permissions and the like.
> The page size could also be returned directly, 6 bits could be used to
> express any page shift in a 64 bit system, but I found the encoded page
> size more useful for my specific use case.
>
>
> The attached patch changes the /proc/pid/pagemap code to use such a
> pseudo-pte. The huge page handling is currently limited to 2M/4M pages
> on x86, 1G pages will need some more work. To keep the simple mapping of
> virtual addresses to file index intact, any huge page pseudo-pte is
> replicated in the user buffer to map the equivalent range of small
> pages.
>
> Note that I had to move the pmd_pfn() macro from asm-x86/pgtable_64.h to
> asm-x86/pgtable.h, it applies to both 32 bit and 64 bit x86.
>
> Other architectures will probably need other changes to support huge
> pages and return the page size.
>
> I think that the definition of the pseudo-pte structure and the page
> size codes should be made available through a header file, but I didn't
> do this for now.
>
> Signed-Off-By: Hans Rosenfeld <[EMAIL PROTECTED]>
>
> ---
> fs/proc/task_mmu.c | 68 +
> include/asm-x86/pgtable.h|2 +
> include/asm-x86/pgtable_64.h |1 -
> 3 files changed, 50 insertions(+), 21 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 49958cf..58af588 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -527,16 +527,23 @@ struct pagemapread {
> char __user *out, *end;
> };
>
> -#define PM_ENTRY_BYTES sizeof(u64)
> -#define PM_RESERVED_BITS3
> -#define PM_RESERVED_OFFSET (64 - PM_RESERVED_BITS)
> -#define PM_RESERVED_MASK(((1LL< PM_RESERVED_OFFSET)
> -#define PM_SPECIAL(nr) (((nr) << PM_RESERVED_OFFSET) | PM_RESERVED_MASK)
> -#define PM_NOT_PRESENT PM_SPECIAL(1LL)
> -#define PM_SWAP PM_SPECIAL(2LL)
> -#define PM_END_OF_BUFFER1
> -
> -static int add_to_pagemap(unsigned long addr, u64 pfn,
> +struct ppte {
> + uint64_t paddr:58;
> + uint64_t psize:4;
> + uint64_t swap:1;
> + uint64_t present:1;
> +};
> +
> +#ifdef CONFIG_X86
> +#define PM_PSIZE_1G 3
> +#define PM_PSIZE_4M 2
> +#define PM_PSIZE_2M 1
> +#endif
> +
> +#define PM_ENTRY_BYTES sizeof(struct ppte)
> +#define PM_END_OF_BUFFER 1
> +
> +static int add_to_pagemap(unsigned long addr, struct ppte ppte,
> struct pagemapread *pm)
> {
> /*
> @@ -545,13 +552,13 @@ static int add_to_pagemap(unsigned long addr, u64 pfn,
>* the pfn.
>*/
> if (pm->out + PM_ENTRY_BYTES >= pm->end) {
> - if (copy_to_user(pm->out, &pfn, pm->end - pm->out))
> + if (copy_to_user(pm->out, &ppte, pm->end - pm->out))
> return -EFAULT;
> pm->out = pm->end;
> return PM_END_OF_BUFFER;
> }
>
> - if (put_user(pfn, pm->out))
> + if (copy_to_user(pm->out, &ppte, sizeof(ppte)))
> return -EFAULT;
> pm->out += PM_ENTRY_BYTES;
> return 0;
> @@ -564,7 +571,7 @@ static int pagemap_pte_hole(unsigned long start, unsigned
> long end,
> unsigned long addr;
> int err = 0;
> for (addr = start; addr < end; addr += PAGE_SIZE) {
> - err = add_to_pa
Re: [RFC] [PATCH] x86: Use ELF section to list CPU vendor specific code (Linux Tiny)
On Fri, 2008-02-15 at 12:00 +0100, Thomas Petazzoni wrote:
> Hi,
>
> Le Mon, 11 Feb 2008 16:54:30 -0800,
> "H. Peter Anvin" <[EMAIL PROTECTED]> a écrit :
>
> > b) would be my first choice, and yes, it would be a good thing to
> > have a generalized mechanism for this. For the registrant, it's
> > pretty easy: just add a macro that adds a pointer to a named
> > section. We then need a way to get the base address and length of
> > each such section in order to be able to execute each function in
> > sequence.
>
> You'll find below a tentative patch that implements this. Tuple
> (vendor, pointer to cpu_dev structure) are stored in a
> x86cpuvendor.init section of the kernel, which is then read by the
> generic CPU code in arch/x86/kernel/cpu/common.c to fill the cpu_devs[]
> function.
This is not quite what Peter and I were thinking of, I think. It's not
at all generic. How about a section that simply contains a set of
function pointers, a macro to add things to that section, and a function
that calls all the pointers in that section. Eg:
CALLBACK_SECTION(init_cpu_amd, "cpuvendor.init");
invoke_callback_section("cpuvendor.init");
..which would give us a generic facility we could use in various places.
--
Mathematics is the supreme nostalgia of our time.
--
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 /proc/pid/pagemap work with huge pages and return page size
On Sat, 2008-02-23 at 00:06 -0800, Andrew Morton wrote:
> On Wed, 20 Feb 2008 14:57:43 +0100 "Hans Rosenfeld" <[EMAIL PROTECTED]> wrote:
>
> > The current code for /proc/pid/pagemap does not work with huge pages (on
> > x86). The code will make no difference between a normal pmd and a huge
> > page pmd, trying to parse the contents of the huge page as ptes. Another
> > problem is that there is no way to get information about the page size a
> > specific mapping uses.
> >
> > Also, the current way the "not present" and "swap" bits are encoded in
> > the returned pfn isn't very clean, especially not if this interface is
> > going to be extended.
> >
> > I propose to change /proc/pid/pagemap to return a pseudo-pte instead of
> > just a raw pfn. The pseudo-pte will contain:
> >
> > - 58 bits for the physical address of the first byte in the page, even
> > less bits would probably be sufficient for quite a while
> >
> > - 4 bits for the page size, with 0 meaning native page size (4k on x86,
> > 8k on alpha, ...) and values 1-15 being specific to the architecture
> > (I used 1 for 2M, 2 for 4M and 3 for 1G for x86)
> >
> > - a "swap" bit indicating that a not present page is paged out, with the
> > physical address field containing page file number and block number
> > just like before
> >
> > - a "present" bit just like in a real pte
> >
> > By shortening the field for the physical address, some more interesting
> > information could be included, like read/write permissions and the like.
> > The page size could also be returned directly, 6 bits could be used to
> > express any page shift in a 64 bit system, but I found the encoded page
> > size more useful for my specific use case.
> >
> >
> > The attached patch changes the /proc/pid/pagemap code to use such a
> > pseudo-pte. The huge page handling is currently limited to 2M/4M pages
> > on x86, 1G pages will need some more work. To keep the simple mapping of
> > virtual addresses to file index intact, any huge page pseudo-pte is
> > replicated in the user buffer to map the equivalent range of small
> > pages.
> >
> > Note that I had to move the pmd_pfn() macro from asm-x86/pgtable_64.h to
> > asm-x86/pgtable.h, it applies to both 32 bit and 64 bit x86.
> >
> > Other architectures will probably need other changes to support huge
> > pages and return the page size.
> >
> > I think that the definition of the pseudo-pte structure and the page
> > size codes should be made available through a header file, but I didn't
> > do this for now.
> >
>
> If we're going to do this, we need to do it *fast*. Once 2.6.25 goes out
> our hands are tied.
>
> That means talking with the maintainers of other hugepage-capable
> architectures.
>
> > +struct ppte {
> > + uint64_t paddr:58;
> > + uint64_t psize:4;
> > + uint64_t swap:1;
> > + uint64_t present:1;
> > +};
>
> This is part of the exported kernel interface and hence should be in a
> header somewhere, shouldn't it? The old stuff should have been too.
I think we're better off not using bitfields here.
> u64 is a bit more conventional than uint64_t, and if we move this to a
> userspace-visible header then __u64 is the type to use, I think. Although
> one would expect uint64_t to be OK as well.
>
> > +#ifdef CONFIG_X86
> > +#define PM_PSIZE_1G 3
> > +#define PM_PSIZE_4M 2
> > +#define PM_PSIZE_2M 1
> > +#endif
>
> No, we should factor this correctly and get the CONFIG_X86 stuff out of here.
Perhaps my "continuation bit" idea.
> Matt? Help?
Did my previous message make it out? This is probably my last message
for 24+ hours.
--
Mathematics is the supreme nostalgia of our time.
--
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] x86: Use ELF section to list CPU vendor specific code (Linux Tiny)
On Mon, 2008-02-25 at 09:29 +0100, Thomas Petazzoni wrote:
> Le Sat, 23 Feb 2008 10:43:37 +0800,
> Matt Mackall <[EMAIL PROTECTED]> a écrit :
>
> > This is not quite what Peter and I were thinking of, I think. It's not
> > at all generic. How about a section that simply contains a set of
> > function pointers, a macro to add things to that section, and a
> > function that calls all the pointers in that section. Eg:
> >
> > CALLBACK_SECTION(init_cpu_amd, "cpuvendor.init");
> > invoke_callback_section("cpuvendor.init");
> >
> > ..which would give us a generic facility we could use in various
> > places.
>
> I see. Probably doable. How would it work in the LD script file ? Your
> mechanism allows to specify any section name, but AFAIK, the sections
> must be explicitly listed in the kernel LD script in order to be
> included in the final kernel image. Am I missing something ?
I can't see any way to avoid it, but we can leave it to future
generations to come up with something more clever.
--
Mathematics is the supreme nostalgia of our time.
--
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] x86: Use ELF section to list CPU vendor specific code (Linux Tiny)
On Mon, 2008-02-25 at 18:53 +0100, Thomas Petazzoni wrote:
> Le Mon, 25 Feb 2008 09:03:12 -0800,
> Matt Mackall <[EMAIL PROTECTED]> a écrit :
>
> > > > This is not quite what Peter and I were thinking of, I think.
> > > > It's not at all generic. How about a section that simply contains
> > > > a set of function pointers, a macro to add things to that
> > > > section, and a function that calls all the pointers in that
> > > > section. Eg:
> > > >
> > > > CALLBACK_SECTION(init_cpu_amd, "cpuvendor.init");
> > > > invoke_callback_section("cpuvendor.init");
> > > >
> > > > ..which would give us a generic facility we could use in various
> > > > places.
> > >
> > > I see. Probably doable. How would it work in the LD script file ?
> > > Your mechanism allows to specify any section name, but AFAIK, the
> > > sections must be explicitly listed in the kernel LD script in order
> > > to be included in the final kernel image. Am I missing something ?
> >
> > I can't see any way to avoid it, but we can leave it to future
> > generations to come up with something more clever.
>
> After a quick look at the LD documentation, it seems that wildcards are
> supported in the input section names of the linker script. So that the
> CALLBACK_SECTION() macro could add the function pointer to a section
> named:
>
>gcm. ## name
>
> (gcm standing for "generic callback mechanism") and then, in the linker
> script, do:
>
>*(gcm.*)
>
> I'm going to try that.
Sounds great! But I'd rather the base name be "callback" so it'll be
obvious what it is when people dump section names.
--
Mathematics is the supreme nostalgia of our time.
--
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] configfs, a filesystem for userspace-driven kernel object configuration
On Sun, Apr 03, 2005 at 12:57:28PM -0700, Joel Becker wrote:
> Folks,
> I humbly submit configfs. With configfs, a configfs
> config_item is created via an explicit userspace operation: mkdir(2).
> It is destroyed via rmdir(2). The attributes appear at mkdir(2) time,
> and can be read or modified via read(2) and write(2). readdir(3)
> queries the list of items and/or attributes.
> The lifetime of the filesystem representation is completely
> driven by userspace. The lifetime of the objects themselves are managed
> by a kref, but at rmdir(2) time they disappear from the filesystem.
> configfs is not intended to replace sysfs or procfs, merely to
> coexist with them.
> An interface in /proc where the API is:
>
> # echo "create foo 1 3 0x00013" > /proc/mythingy
>
> or an ioctl(2) interface where the API is:
>
> struct mythingy_create {
> char *name;
> int index;
> int count;
> unsigned long address;
> }
>
> do_create {
> mythingy_create = {"foo", 1, 3, 0x0013};
> return ioctl(fd, MYTHINGY_CREATE, &mythingy_create);
> }
>
> becomes this in configfs:
>
> # cd /config/mythingy
> # mkdir foo
> # echo 1 > foo/index
> # echo 3 > foo/count
> # echo 0x00013 > foo/address
>
> Instead of a binary blob that's passed around or a cryptic
> string that has to be formatted just so, configfs provides an interface
> that's completely scriptable and navigable.
How does the kernel know when to actually create the object?
--
Mathematics is the supreme nostalgia of our time.
-
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: Coding style: mixed-case
On Wed, Apr 06, 2005 at 03:29:21AM +0200, Kenneth Aafl?y wrote: > Hi, > > while reading Documentation/CodingStyle for the nth time, I realized that I > had > read some conflicting coding style in some patch posted to the linux-kernel > mailing-list; in include/linux/page-flags.h, there is a lot of defines that > are > apparently frowned upon: > > HOWEVER, while mixed-case names are frowned upon, descriptive names for > global variables are a must. To call a global function "foo" is a > shooting offense. > > Are those an exception to the rule or would for example > PF_LOCKED/pf_locked be a nice replacement for PageLocked? While there may be reasons why mixed case is suboptimal, the real reason is that it's hard to keep track of which style is used where. It's annoying and error-prone to have to remember the naming format for everything in addition to its name. As most things are in a standard style, things are made easier by having every piece of new code follow that style and let us slowly approach uniformity. If you posted a patch for pf_locked() and friends (and note that it's lowercase to match function-like usage), you'd probably find some enthusiasts and some naysayers. Most of the naysayers would object on the grounds of "it ain't broke", but if someone were to do it as part of a series of more substantial clean-ups, it'd likely be accepted. -- Mathematics is the supreme nostalgia of our time. - 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: /dev/random problem on 2.6.12-rc1
On Thu, Apr 07, 2005 at 05:36:59PM +0200, Simon Derr wrote: > > > On Thu, 7 Apr 2005, Yura Pakhuchiy wrote: > > > On Thu, 2005-04-07 at 14:40 +0200, Patrice Martinez wrote: > > > When using a machine with a 2612-rc 1kernel, I encounter problems > > > reading /dev/random: > > > it simply nevers returns anything, and the process is blocked in the > > > read... > > > The easiest way to see it is to type: > > > od < /dev/random > > > > > > Any idea? > > > > Because, /dev/random use user input, mouse movements and other things to > > generate next random number. Use /dev/urandom if you want version that > > will never block your machine. > > > > Read "man 4 random" for details. > > > Something changed since previous versions of the kernel, I guess. > Running `find /usr | wc' on a ssh session generates both network and disk > activity, and you should not expect any other kind of input on a networked > server. FYI, network activity only generates entropy on a very small subset of NICs, and probably not the one you're using. This is good, as network activity is assumed passively observable/timable. > Anyway, still zero bytes coming from /dev/random, for the few minutes I > waited. Are you and Patrice both experiencing this on the same machine? What was the last kernel that was known to work for you? Do you see the contents of /proc/sys/kernel/random/entropy_avail change over time? Are there any other entropy consumers on your machine? -- Mathematics is the supreme nostalgia of our time. - 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] update maintainer for /dev/random
Ted has agreed to let me take over as maintainer of /dev/random and friends. I've gone ahead and added a line to his entry in CREDITS. Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> Index: mm/drivers/char/random.c === --- mm.orig/drivers/char/random.c 2005-04-06 13:41:34.0 -0700 +++ mm/drivers/char/random.c2005-04-07 14:13:23.0 -0700 @@ -1,7 +1,7 @@ /* * random.c -- A strong random number generator * - * Version 1.89, last modified 19-Sep-99 + * Copyright Matt Mackall <[EMAIL PROTECTED]>, 2003, 2004, 2005 * * Copyright Theodore Ts'o, 1994, 1995, 1996, 1997, 1998, 1999. All * rights reserved. Index: mm/MAINTAINERS === --- mm.orig/MAINTAINERS 2005-04-06 13:42:21.0 -0700 +++ mm/MAINTAINERS 2005-04-07 14:13:23.0 -0700 @@ -1914,6 +1914,11 @@ M: [EMAIL PROTECTED] L: linux-kernel@vger.kernel.org S: Maintained +RANDOM NUMBER DRIVER +P: Matt Mackall +M: [EMAIL PROTECTED] +S: Maintained + REAL TIME CLOCK DRIVER P: Paul Gortmaker M: [EMAIL PROTECTED] Index: mm/CREDITS === --- mm.orig/CREDITS 2005-04-06 13:42:09.0 -0700 +++ mm/CREDITS 2005-04-07 14:13:25.0 -0700 @@ -3299,6 +3299,7 @@ D: Author of the new e2fsck D: Author of job control and system call restart code D: Author of ramdisk device driver D: Author of loopback device driver +D: Author of /dev/random driver S: MIT Room E40-343 S: 1 Amherst Street S: Cambridge, Massachusetts 02139 -- Mathematics is the supreme nostalgia of our time. - 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] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU
On Tue, Apr 05, 2005 at 08:10:27PM -0700, Randy.Dunlap wrote: > There is a fairly up-to-date dontdiff file available at > http://developer.osdl.org/rddunlap/doc/dontdiff-osdl Can we stash a copy in Documentation? -- Mathematics is the supreme nostalgia of our time. - 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: /dev/random problem on 2.6.12-rc1
On Fri, Apr 08, 2005 at 08:56:51AM +0200, Simon Derr wrote: > On Thu, 7 Apr 2005, Matt Mackall wrote: > > > On Thu, Apr 07, 2005 at 05:36:59PM +0200, Simon Derr wrote: > > > > > > > > > On Thu, 7 Apr 2005, Yura Pakhuchiy wrote: > > > > > > > On Thu, 2005-04-07 at 14:40 +0200, Patrice Martinez wrote: > > > > > When using a machine with a 2612-rc 1kernel, I encounter problems > > > > > reading /dev/random: > > > > > it simply nevers returns anything, and the process is blocked in the > > > > > read... > > > > > The easiest way to see it is to type: > > > > > od < /dev/random > > > > > > > > > > Any idea? > > > > > > > > Because, /dev/random use user input, mouse movements and other things to > > > > generate next random number. Use /dev/urandom if you want version that > > > > will never block your machine. > > > > > > > > Read "man 4 random" for details. > > > > > > > Something changed since previous versions of the kernel, I guess. > > > Running `find /usr | wc' on a ssh session generates both network and disk > > > activity, and you should not expect any other kind of input on a networked > > > server. > > > Oops, the command is actually "find /usr | xargs wc", witch causes lots of > disk activity. > > > FYI, network activity only generates entropy on a very small subset of > > NICs, and probably not the one you're using. This is good, as network > > activity is assumed passively observable/timable. > Offtopic, but why isn't the policy the same for all NICs ? The policy is the same, it just hasn't been implemented. SA_RANDOM is scheduled for abolishment. > > > Anyway, still zero bytes coming from /dev/random, for the few minutes I > > > waited. > > > > Are you and Patrice both experiencing this on the same machine? > Both IA-64, but that's the only common point. > > > What > > was the last kernel that was known to work for you? Do you see the > > contents of /proc/sys/kernel/random/entropy_avail change over time? > > Are there any other entropy consumers on your machine? > None that I am aware of. > > I run: > # dd if=/dev/random bs=1 count=1 | od strace the dd process, please. This works fine here. > Another shell: > # lsof /dev/random > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME > dd 1496 root0r CHR1,8 99952 /dev/random > > Now, find /usr | xargs wc running in background. > > About /proc/sys/kernel/random/entropy_avail: > (5 second refresh interval) That may not be sufficient resolution. The upper layers will pull from it whenever it rises above 64 and bash it back down to within 7 bits of 0. What does it do when no one is reading from it? -- Mathematics is the supreme nostalgia of our time. - 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: buggy ia64_fls() ? (was Re: /dev/random problem on 2.6.12-rc1)
On Fri, Apr 08, 2005 at 02:12:04PM +0200, Simon Derr wrote: > I enabled the debug messages in random.c and I think I found the problem > lying in the IA64 version of fls(). Good catch. > It turns out that the generic and IA64 versions of fls() disagree: > > (output from a small test program) > > x ia64_fls(x) generic_fls(x) > > i=-1, t=0, ia64: -65535 et generic:0 > i=0, t=1, ia64: 0 et generic:1 > i=1, t=2, ia64: 1 et generic:2 > i=2, t=4, ia64: 2 et generic:3 > i=3, t=8, ia64: 3 et generic:4 Well PPC at least sez: /* * fls: find last (most-significant) bit set. * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32. */ And that agrees with the generic code (used by x86). So I think IA64 is probably wrong here indeed. It's amazing that the other users of fls don't blow up spectacularly. > I tried to fix it with an ia64 version that would give the same result as > the generic version, but the kernel did not boot, I guess some functions > rely on the ""broken"" ia64_fls() behaviour. > > So I just changed fls() to use generic_fls() instead of ia64_fls(). If the "fixed" version didn't boot, how did the "alternate fixed" version boot? -- Mathematics is the supreme nostalgia of our time. - 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/8] correctly name the Shell sort
On Fri, Apr 08, 2005 at 11:52:10AM -0400, Horst von Brand wrote: > [EMAIL PROTECTED] said: > > > As per http://www.nist.gov/dads/HTML/shellsort.html, this should be > > referred to as a Shell sort. Shell-Metzner is a misnomer. > > > Signed-off-by: Daniel Dickman <[EMAIL PROTECTED]> > > Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> > > Why not use the sort routine from lib/sort.c? Because the groups are not in an array. They're in a bunch of page-sized blocks and the indexing function knows how to look at the index block and make everything look like an array from the point of view of the shell sort. I couldn't come up with a clean way to handle it. -- Mathematics is the supreme nostalgia of our time. - 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/3] cifs: md5 cleanup - functions
On Mon, Apr 11, 2005 at 10:11:39PM +0200, Jesper Juhl wrote: > > Function names and return types on same line - conform to established > fs/cifs/ style. > > Patch is also available at: > http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_md5-funct.patch I think the right thing to do here is what I did with the SHA1 code from random.c: put the favorite implementation in lib/ and replace the cryptoapi and CIFS implementations (and any other users) with it. If you feel like tackling this, let me know, it's been on my todo list for a while. -- Mathematics is the supreme nostalgia of our time. - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
On Tue, Apr 12, 2005 at 03:21:15PM -0500, Kilau, Scott wrote: > Hi Greg, all, > > > Ok, but wasn't it possible to get those additional things added to the > > main kernel serial core, which would then provide everything that > Digi's > > customers are accustomed to? > > Yes, it is my intention in the future to add support for the needed > information, > probably at the /sys level. > The key is to be able to get at the tty information without > having to open up the tty/port. > > Again, I understand why you required the changes in JSM, > IBM didn't need DPA support, so I had no problem with removing the > support. > > However, neither IBM nor Digi wants this thread's patch to be applied, > and yet Christoph wants to do it, completely out of spite, to break our > out-of-tree open source driver. The problem is that your "out-of-tree open source driver" is an inadequate solution. Out of tree drivers are a pain for users, developers, and distributors. As such, we make very little allowance for their concerns, especially when they stand in the way of improving things that _are_ in the kernel. The proposed patch makes the in-tree driver work for hardware that it didn't before which is a net good for our users. The ball is now in your court: replace it with an acceptable version of your driver in a timely fashion. Saying you'll get around to it some day when you're done supporting 2.4 is not timely. Nor does it serve your users. Alternately, provide a good reason not to include said patch without reference to might-as-well-not-exist-as-far-as-we're-concerned out of tree drivers or the similarly irrelevant wishes of nebulous corporate entities. -- Mathematics is the supreme nostalgia of our time. - 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
On Tue, Apr 12, 2005 at 04:46:10PM -0500, Kilau, Scott wrote: > Hi Matt, > > The ball is in my court, because my wishes as a copyright holder are not > being honored. > > Which is the right of Christoph because of the GPL, but it sure doesn't > help the end > users of said product. > Your claim that you are trying to "help" end users is bogus and just > plain wrong. Your end users do not benefit from drivers that are not well integrated with the kernel. If a user has to jump through hoops to make their hardware work (including downloading extra drivers, etc.), that is not a benefit. Case in point: the patch in question _came from an end user_. We've now got 12 years experience in the headaches of out of tree drivers (binary or not) as users, developers, and distributors, and we're sick of it. We're not supporting that approach any more, they don't exist as far as we're concerned until they're candidates for merger. Your hardware is no exception. > > As such, we make very little allowance > > for their concerns, especially when they stand in > > the way of improving things that _are_ in the kernel. > > How is shipping a stripped down version of the driver, by yanking things > our customers want, improving the "things that are in the kernel"? End users do not benefit from bad interfaces. This may seem in conflict with the above, but it's not. One of the main benefits of kernel integration is that the trouble spots get sorted out and the interfaces get cleaned up. This is good for everyone. Feel free to resubmit those features when they're done right. This is what your customers want, whether they know it yet or not. Anything else is a stopgap. > When the user installs my driver with all the extra features that our > customers > really want, I will simply check to see if jsm.ko exists, and ask the > user if I > can blow away the jsm.ko module. And the rest of us make a note to not get Digi hardware because we're sick of these out of tree drivers and the unspeakable hacks they generally contain in the name of special features. -- Mathematics is the supreme nostalgia of our time. - 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: Re: more git updates..
On Tue, Apr 12, 2005 at 06:10:27PM -0700, Linus Torvalds wrote: > > > On Wed, 13 Apr 2005, Andrea Arcangeli wrote: > > > > I wasn't suggesting to use CVS. I meant that for a newly developed SCM, > > the CVS/SCCS format as storage may be more appealing than the current > > git format. > > Go wild. I did mine in six days, and you've been whining about other > peoples SCM's for three years. I wrote a hack to do efficient delta storage with O(1) seeks for lookup and append last week, I believe it's been integrated into the latest Bazaar-NG. I expect it'll give better compression and performance than BK. Of course it ends up being O(revisions) for modifications or insertions (but that is probably a non-issue for the SCM models we're looking at). The git model is obviously very different, but I worry about the slop space implied. With 200k file revision and an average of 2k slop per file, that's 400MB of slop, or almost the size of an equivalent delta compressed kernel repo. Now if you can assume that blobs never change and are never deleted, you can simply append them all onto a log, and then index them with a separate file containing an htree of (sha1, offset, length) or the like. Since the key is already a strong hash, this is an excellent match and avoids rehashing in the kernel's directory lookup. And it'll save an inode, a directory entry, and about half a data block per entry. "Open" will also be cheaper as there's no per-revision inode to grab. I could hack on this if you think it fits with the git model, otherwise I'll go back to my other experiments.. -- Mathematics is the supreme nostalgia of our time. - 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: Fortuna
On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote: > Ahh. Thanks Herbert. > > Matt, > > Any insight on how to test syn cookies and the other network stuff in > random.c? My patch is attached, but I havn't tested that part yet. For starters, this is not against anything like a current random.c. A great number of cleanups have been done. Syncookies are perhaps best tested with printk of the cookie ingredients in the generation and check steps. -- Mathematics is the supreme nostalgia of our time. - 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: more git updates..
On Thu, Apr 14, 2005 at 01:42:11AM +0200, Krzysztof Halasa wrote: > Matt Mackall <[EMAIL PROTECTED]> writes: > > > Now if you can assume that blobs never change and are never deleted, > > you can simply append them all onto a log, and then index them with a > > separate file containing an htree of (sha1, offset, length) or the > > like. > > That mean a problem with rsync, though. I believe 200k inodes is a problem for rsync too. But we can simply grab the remote htree, do a tree compare, find the ranges of the remote file we need, sort and merge the ranges, and then pull them. That will surely trounce rsync. -- Mathematics is the supreme nostalgia of our time. - 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 encrypted swsusp 1/3] core functionality
On Thu, Apr 14, 2005 at 01:46:02AM +0200, Pavel Machek wrote: > On ??t 14-04-05 09:39:04, Herbert Xu wrote: > > On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote: > > > > > > > The ssh keys are *encrypted* in the swap when dmcrypt is used. > > > > When the swap runs over dmcrypt all writes including those from > > > > swsusp are encrypted. > > > > > > Andreas is right. They are encrypted in swap, but they should not be > > > there at all. And they are encrypted by key that is still available > > > after resume. Bad. > > > > The dmcrypt swap can only be unlocked by the user with a passphrase, > > which is analogous to how you unlock your ssh private key stored > > on the disk using a passphrase. > > Once more: > > Andreas' implementation destroys the key during resume. This solution is all wrong. If you want security of the suspend image while "suspended", encrypt with dm-crypt. If you want security of the swap image after resume, zero out the portion of swap used. If you want both, do both. You could even just zero out those regions which were mlocked at suspend. If it wasn't mlocked, it might be on swap already anyway. Re-implementing dm-crypt for this purpose is ridiculous. -- Mathematics is the supreme nostalgia of our time. - 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: Fortuna
On Wed, Apr 13, 2005 at 08:26:47PM -0400, Jean-Luc Cooke wrote: > On Wed, Apr 13, 2005 at 05:09:39PM -0700, Matt Mackall wrote: > > On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote: > > > Ahh. Thanks Herbert. > > > > > > Matt, > > > > > > Any insight on how to test syn cookies and the other network stuff in > > > random.c? My patch is attached, but I havn't tested that part yet. > > > > For starters, this is not against anything like a current random.c. A > > great number of cleanups have been done. > > You caught me. :) > > Last I proposed Fortuna for /dev/random it nearly got me drawn and quarterd. It still might. Ted and I are as yet unconvince that the Fortuna approach is superior. While it may have some good properties, it lacks some that random.c has, particularly robustness in the face of failure of crypto primitives. > So I've left it as a kenrel config option, leaving the current random.c > alone. I thought this was a way to make everyone happy. Duplicated code rarely does that. At any rate, you ought to review the changes (there've been 40+ patches recently). There are a number of bug fixes in there and quite a bit of cleanup. Syncookies in particular no longer live in random.c. -- Mathematics is the supreme nostalgia of our time. - 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 encrypted swsusp 1/3] core functionality
On Thu, Apr 14, 2005 at 11:04:39AM +0200, Rafael J. Wysocki wrote: > Hi, > > On Thursday, 14 of April 2005 10:08, Herbert Xu wrote: > > On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote: > > > > > > > This solution is all wrong. > > > > > > > > If you want security of the suspend image while "suspended", encrypt > > > > with dm-crypt. If you want security of the swap image after resume, > > > > zero out the portion of swap used. If you want both, do both. > > > > Pavel, you're not answering our questions. > > > > How is the proposed patch any more secure compared to swsusp over dmcrypt? > > It is for different purpose. It is to prevent swsusp from leaving a readable > memory snapshot on the disk _after_ resume, even if the resume has _failed_ > (ie if you encrypt the image during suspend and then destroy the key after > reading the image during resume, you don't need to zero out the swap > partition, > which you can't do anyway if the resume has failed). IOW, please treat it as > a more sophisticated method of zeroing out the swap partition. :-) What is this resume failed case? If it means the machine has crashed during resume, then so what? The key is not on disk in the clear -ever- in the dm-crypt case. If the attacker gets to poke around in the memory contents of the crashed machine for the key (or the partially loaded suspend image). If it means we fell back to a normal boot, normal boot can simply dd over the swap at boot, generate a new ephemeral swap key, or whatever. > Arguably, using dm-crypt is more secure, but it is also more > complicated from the Joe User POV. IMHO we should not force users to > set up dm-crypt, remember passwords etc., to get some basic > security. Any sensible solution here is going to require remembering passwords. And arguably anywhere the user needs encrypted suspend, they'll want encrypted swap as well. -- Mathematics is the supreme nostalgia of our time. - 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 encrypted swsusp 1/3] core functionality
On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote: > Matt Mackall wrote: > > > Any sensible solution here is going to require remembering passwords. > > And arguably anywhere the user needs encrypted suspend, they'll want > > encrypted swap as well. > > But after entering the password and resuming, the encrypted swap is > accessible again and my ssh-key may be lying around in it, right? No. Because it's been zeroed in the resume process. > So we would need to zero out the suspend image in swap to prevent the > retrieval of this data from the running machine (imagine a > remote-root-hole). > > Zeroing out the suspend image means "write lots of megabytes to the > disk" which takes a lot of time. Zero only the mlocked regions. This should take essentially no time at all. Swsusp knows which these are because they have to be mlocked after resume as well. If it's not mlocked, it's liable to be swapped out anyway. Again: Use dm-crypt swap with password prompt to handle "stolen while suspended" Zero out mlocked regions on resume for "stolen while running". Reinitialize swap or use a different swap session keys for "booting without resume". There are more refinements here, like generating session keys per boot for swap. We want to do this anyway. We can encrypt the session key with the user password for suspend purposes. Booting without resume loses the old (encrypted) session key. But this is all solvable without resorting to yet another encrypted block device scheme. Such a scheme shouldn't even be considered until all the other options are thoroughly explored. Any scheme that's encrypting the suspend image and then storing the key in the clear is either obviously broken or obviously doesn't actually need encryption. -- Mathematics is the supreme nostalgia of our time. - 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 encrypted swsusp 1/3] core functionality
On Thu, Apr 14, 2005 at 10:18:12PM +0200, Pavel Machek wrote: > Hi! > > > > So we would need to zero out the suspend image in swap to prevent the > > > retrieval of this data from the running machine (imagine a > > > remote-root-hole). > > > > > > Zeroing out the suspend image means "write lots of megabytes to the > > > disk" which takes a lot of time. > > > > Zero only the mlocked regions. This should take essentially no time at > > all. Swsusp knows which these are because they have to be mlocked > > I believe this is tricky to implement. You are free to produce patch, > and if that patch is nicer/simpler than Anreas's code, I may consider > it. If I understand swsusp correctly, we can simply set a bit in the pbe struct to indicate that it's a locked page. This can be done by walking the vma list attached to the page's address space with vma_prio_tree_foreach() and checking the vma->vm_flags with VM_LOCKED. Analogous to what the swapout code does. We can either do this in data_write() or preferably higher (copy_data?) when we have the pfn handy. The lock bit can be stashed in bit 0 of pbe->address, among other places. Then in data_read, we check the bit and zero the source. As I'm not about to actually use swsusp any time soon, someone else is invited to implement the above. Should take about 10-20 lines. -- Mathematics is the supreme nostalgia of our time. - 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 encrypted swsusp 1/3] core functionality
On Thu, Apr 14, 2005 at 03:11:53PM -0700, Andy Isaacson wrote: > On Thu, Apr 14, 2005 at 12:53:52PM -0700, Matt Mackall wrote: > > On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote: > > > Matt Mackall wrote: > > > > Any sensible solution here is going to require remembering passwords. > > > > And arguably anywhere the user needs encrypted suspend, they'll want > > > > encrypted swap as well. > > > > > > But after entering the password and resuming, the encrypted swap is > > > accessible again and my ssh-key may be lying around in it, right? > > > > No. Because it's been zeroed in the resume process. > > Zeroing the entire swsusp region is a big job, especially if you want to > do it in a FIPS-conformant manner. Hard to test that you've done it > right and not missed any bits. > > Much much easier to securely erase just the key storage. > > And unless I'm missing something, you meant to say "it will have been > zeroed" (after the patch under discussion is merged), right? The > current state of the art (as of 2.6.12-rc2) is that mlocked regions are > written to the swsusp region and may linger there indefinitely after > resume. I was referring not to the current implementation but to an ideal solution. Which is: - use dm-crypt for swap and suspend - overwrite mlocked regions on resume - use per-boot session keys for the swap partition - password protect the session key on suspend This doesn't have great FIPS-secure deletion properties if the attacker can steal the box after resume but while it's still running (though it's not too bad). As we currently have no solution for protecting the in-memory ssh-agent, as opposed to the one in the suspend image, this attack vector is not all that important. A much more likely vector is stealing the laptop while it's suspended. And the encrypted swsusp patch has -zero- security here: it writes the key in the header in the clear. It's rather odd that everyone's hung up on the "box rooted after resume" attack and completely ignoring the much more common "stole my laptop" attack. -- Mathematics is the supreme nostalgia of our time. - 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] sched: fix never executed code due to expression always false
On Fri, Apr 15, 2005 at 10:23:11AM +1000, Nick Piggin wrote: > Jesper Juhl wrote: > > > > >As per this patch perhaps? : > > > > Thanks. I'll make sure it gets to the right place if nobody picks it up. Perhaps this ought to be wrapped up in sched_clock_before() or some such. -- Mathematics is the supreme nostalgia of our time. - 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 encrypted swsusp 1/3] core functionality
On Fri, Apr 15, 2005 at 11:44:06AM +0200, Andreas Steinmetz wrote: > Matt Mackall wrote: > > Zero only the mlocked regions. This should take essentially no time at > > all. Swsusp knows which these are because they have to be mlocked > > after resume as well. If it's not mlocked, it's liable to be swapped > > out anyway. > > Nitpicking: > What happens if the disk decides to relocate a close to failing sector > containing mlocked data during resume zeroing? This just means that > there will be sensitive data around on the disk that can't be zeroed > out anymore but which might be recovered by specialized > companies/institutions. > Encrypting these data in the first place reduces this problem to a > single potentially problematic sector. Well that's what the dmcrypt phase is for. -- Mathematics is the supreme nostalgia of our time. - 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: Fortuna
On Fri, Apr 15, 2005 at 12:22:25PM -0400, Jean-Luc Cooke wrote: > And the argument that "random.c doesn't rely on the strength of crypto > primitives" is kinda lame, though I see where you're coming from. random.c's > entropy mixing and output depends on the (endian incorrect) SHA-1 > implementation hard coded in that file to be pre-image resistant. If that > fails (and a few other things) then it's broken. You really ought to look at the _current_ implementation. There is no SHA1 code in random.c. -- Mathematics is the supreme nostalgia of our time. - 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/
[ANNOUNCE] Kernel Mentors Project
Perhaps the hardest part of becoming a kernel developer is submitting your first major feature. There are technical and social hurdles to overcome and the process can be daunting to someone who is new to the community. Thus, I'm proposing an informal project to get experienced developers to mentor new developers and coach them on the best ways to get their code ready for submission. Developers will submit a description of their project and its current state as well as pointer to the code to the kernel-mentors mailing list. Mentors will pick for themselves which projects and developers they'd like to work with and offer their assistance. The mentor will help the developer get their code accepted by: - reviewing the code and suggesting how to improve it further - acquainting the developer with best practices for code submission - letting the developer know what to expect in the submission process For their part, new developers will be expected to use the feedback they're given productively and eventually get their code merged! The project list is at [EMAIL PROTECTED] with a web interface at: http://selenic.com/mailman/listinfo/kernel-mentors If you're interested in helping out, come join us. -- Mathematics is the supreme nostalgia of our time. - 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: Fortuna
On Sat, Apr 16, 2005 at 10:05:55AM -, [EMAIL PROTECTED] wrote: > MErging e-mails, first from [EMAIL PROTECTED]: > > You really ought to look at the _current_ implementation. There is no > > SHA1 code in random.c. > > So I'm imagining the call to sha_transform() in 2.6.12-rc2's > extract_buf()? The SHA1 code has been moved to lib/sha1.c, so there's > no SHA1 code *lexically* in random.c, but that's a facile response; > it's a cryptologically meaningless change. No, it's exactly to the point: he's forked random.c before a large set of changes that he needs to be aware of. The SHA1 code is now shared by cryptolib and obviously no longer suffers from the (non-existent) weakness he referenced. -- Mathematics is the supreme nostalgia of our time. - 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: Fortuna
On Sat, Apr 16, 2005 at 05:16:22PM -, [EMAIL PROTECTED] wrote: > > "How does the entropy estimator measure entropy of the event?" becomes a > > crucial concern here. What if, by your leading example, there is 1/2 bit > > of entropy in each event? Will the estimator even account for 1/2 bits? > > Or will it see each event as 3 bits of entropy? How much of a margin > > of error can we tolerate? > > H'm... the old code *used* to handle fractional bits, but the new code > seems to round down to the nearest bit. May have to get fixed to > handle low-rate inputs. I don't believe that was ever true, though it can fairly trivially be added. JLC, please note that entropy estimation is much more conservative now than it was a month ago. > As for margin of error, any persistent entropy overestimate is Bad. > a 6-fold overestimate is disastrous. > > What we can do is refuse to drain the main pool below, say, 128 bits of > entropy. Then we're safe against any *occasional* overestimates > as long as they don't add up to 128 bits. I've been moving in that direction already, most of the infrastructure is already in place. > > /dev/random will output once it has at least 160 bits of entropy > > (iirc), 1/2 bit turning into 3 bits would mean that 160bits of output > > it effectively only 27 bits worth of true entropy (again, assuming the > > catastrophic reseeder and output function don't waste entropy). > > > > It's a lot of "ifs" for my taste. > > /dev/random will output once it has as many bits of entropy as you're > asking for. If you do a 20-byte read, it'll output once it has 160 > bits. If you do a 1-byte read, it'll output once it has 8 bits. That's not quite right. It needs 8 bits in the relevant output pool. Failing that, it needs 64 bits in the input pool to reseed the output pool. In the case of /dev/urandom, it needs 128 bits in the input pool, it always leaves enough for /dev/random to reseed. -- Mathematics is the supreme nostalgia of our time. - 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/
Mercurial SCM v0.6b released
Mercurial is a clean, scalable, distributed SCM designed to meet the needs of large projects like the Linux kernel. It's only been two weeks since the last release, but development has been rapid and I've gotten numerous requests to push out a new release. You can download it at: http://selenic.com/mercurial/release/mercurial-0.6b.tar.gz A Linux kernel repository synced with Linus' tree and with history back to 2.4.0 is available at: http://www.kernel.org/hg/ More information available at: http://selenic.com/mercurial/ What's new: improved ui new clone command replaces mkdir+init+pull+update new revert command add range support and -p option to log to show patches tags command now supports local tags improved push and pull better exception and signal handling improved option parsing support for user-defined hooks (aka triggers) performance updates even faster import of large sets of patches faster delta generation faster annotate faster status and ignore improved web interface more conformant and compatible HTML output built-in RSS feeds better tags handling fast multiple keyword search portability work support for Windows is nearly complete should easily compile and install on any modern UNIX comes with RPM spec file and script and more doc and help updates improved test suite numerous bug fixes and cleanups Many thanks to all the people that contributed to this release with code and testing! -- Mathematics is the supreme nostalgia of our time. - 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] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 10:36:31AM -0400, Steven Rostedt wrote: > Looking at the netpoll routines, I noticed that the find_skb could > lockup if the memory is low. This is because the allocations are > called with GFP_ATOMIC (since this is in interrupt context) and if > it fails, it will continue to fail. This is just by observing the > code, I didn't have this actually happen. So if this is not the > case, please let me know how it can get out. Otherwise, please > accept this patch. By netpoll_poll() tickling the driver enough to free the currently queued outgoing SKBs. Also note that by the time we're in this loop, we're ready to take desperate measures. We've already exhausted our private queue of SKBs so we have no alternative but to keep kicking the driver until something happens. The netpoll philosophy is to assume that its traffic is an absolute priority - it is better to potentially hang trying to deliver a panic message than to give up and crash silently. > Also, as Andi told me, the printk here would probably not show up > anyway if this happens with netconsole. That's fine. But in fact, it does show up occassionally - I've seen it. NAK'ed. -- Mathematics is the supreme nostalgia of our time. - 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: lockups with netconsole on e1000 on media insertion
On Fri, Aug 05, 2005 at 01:45:55PM +0200, Andi Kleen wrote: > John B?ckstrand <[EMAIL PROTECTED]> writes: > > > I've been trying to hunt down a hard lockup issue with some hardware > > of mine, but I've possibly hit a kernel bug instead. When using > > netconsole on my e1000, if I unplug the cable and then re-plug it, the > > machine locks up hard. It manages to print the "link up" message on > > the screen, but nothing after that. Now, I wonder if this is supposed > > to be so? I tried this on 4 different configurations, 2.6.13-rc5 and > > 2.6.12 with and without "noapic acpi=off", same result on all of > > them. I've tried with 1 and 3 other NICs in the machine at the same > > time. > > I ran into the same problem some time ago on e1000. The problem was > that if the link doesn't come up netconsole ends up waiting forever > for it. I still don't like this fix. Yes, you're right, it should eventually give up. But here it gives up way too easily - 5 could easily translate to 5 microseconds. This is analogous to giving up on serial transmit if CTS is down for 5 loops. I'd be much happier if there were some udelay or the like in here so that we're not giving up on such a short timeframe. -- Mathematics is the supreme nostalgia of our time. - 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] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 04:57:00PM -0400, Steven Rostedt wrote: > On Fri, 2005-08-05 at 13:01 -0700, Matt Mackall wrote: > > On Fri, Aug 05, 2005 at 10:36:31AM -0400, Steven Rostedt wrote: > > > Looking at the netpoll routines, I noticed that the find_skb could > > > lockup if the memory is low. This is because the allocations are > > > called with GFP_ATOMIC (since this is in interrupt context) and if > > > it fails, it will continue to fail. This is just by observing the > > > code, I didn't have this actually happen. So if this is not the > > > case, please let me know how it can get out. Otherwise, please > > > accept this patch. > > > > By netpoll_poll() tickling the driver enough to free the currently > > queued outgoing SKBs. > > I believe that the e1000 wont free up any outgoing packets since the > netpoll call doesn't seem to get to the e1000_clean_tx part of the > e1000_intr, otherwise the system wouldn't lock under the > netpoll_send_skb when one disconnects the wire and puts it back in. The > disconnect would lock it up anyway (with Andi's patch it now doesn't) > but since it won't come back up after the link is back up, there seems > to be something wrong with the e1000 netpoll driver. This is because > the e1000_netpoll doesn't seem to be cleaning up the tx buffer and start > the queue back up. That does seem like a driver problem. > > Also note that by the time we're in this loop, we're ready to take > > desperate measures. We've already exhausted our private queue of SKBs > > so we have no alternative but to keep kicking the driver until > > something happens. > > OK, the system is under heavy memory load and starts eating up the > netpoll packets. When the last packet is gone, and you have something > like the e1000 that doesn't clean up its packets with netpoll, then you > just locked up the system. > > The scary part of this loop is that if the netpoll doesn't come up with > the goods, its game over. Say we are at desperate measures but it could > be a case where we need to output more information and lockup here > before we can go out and free some memory. Realistically, we were probably going to crash anyway at this point as we're apparently failing to recycle SKBs. Netpoll generally must assume it won't get a second chance, as it's being called by things like oops() and panic() and used by things like kgdb. If netpoll fails, the box is dead anyway. > > The netpoll philosophy is to assume that its traffic is an absolute > > priority - it is better to potentially hang trying to deliver a panic > > message than to give up and crash silently. > > So even a long timeout would not do? So you don't even get a message to > the console? In general, there's no way to measure time here. And if we're using netconsole, what makes you think there's any other console? > > > Also, as Andi told me, the printk here would probably not show up > > > anyway if this happens with netconsole. > > > > That's fine. But in fact, it does show up occassionally - I've seen > > it. > > Then maybe what Andi told me is not true ;-) > > Oh, and did your machine crash when you saw it? Have you seen it with > the e1000 driver? No and no. Most of my own testing is done with tg3. -- Mathematics is the supreme nostalgia of our time. - 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] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 11:26:10PM +0200, Andi Kleen wrote: > On Fri, Aug 05, 2005 at 01:01:57PM -0700, Matt Mackall wrote: > > The netpoll philosophy is to assume that its traffic is an absolute > > priority - it is better to potentially hang trying to deliver a panic > > message than to give up and crash silently. > > That would be ok if netpoll was only used to deliver panics. But > it is not. It delivers all messages, and you cannot hang the > kernel during that. Actually even for panics it is wrong, because often > it is more important to reboot in a panic than (with a panic timeout) > to actually deliver the panic. That's needed e.g. in a failover cluster. > > If that was the policy it would be a quite dumb one and make netpoll > totally unsuitable for production use. I hope it is not. Suggest you rip __GFP_NOFAIL out of JBD before complaining about this. > Dave, can you please apply the timeout patch anyways? Yes, let's go right over the maintainer's objections almost immediately after he chimes into the thread. I'll spare the list the colorful language this inspires. -- Mathematics is the supreme nostalgia of our time. - 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: lockups with netconsole on e1000 on media insertion
On Fri, Aug 05, 2005 at 11:56:50PM +0200, Andi Kleen wrote: > > I still don't like this fix. Yes, you're right, it should eventually > > give up. But here it gives up way too easily - 5 could easily > > translate to 5 microseconds. This is analogous to giving up on serial > > transmit if CTS is down for 5 loops. > > > > I'd be much happier if there were some udelay or the like in here so > > that we're not giving up on such a short timeframe. > > Problem is that it could translate to a long aggregate delay > e.g. when the kernel tries to dump the backlog after console_init. > That is why I made the delay so short. But why are we in a hurry to dump the backlog on the floor? Why are we worrying about the performance of netpoll without the cable plugged in at all? We shouldn't be optimizing the data loss case. My primary concern here is that the loop have a non-negligible extent in time. 5 loops is effectively equal to none. I'd be very surprised if it was even enough for deglitching. With serial console, we do polled I/O that runs at the serial rate - milliseconds per line of output. > Longer delay would be possible, but then it would need some logic > to detect down links and don't delay on them and then retry later etc. > Would be all far more complicated. I think we could probably have subsequent failures be much shorter without too much added complexity. But I'm not sure it matters. -- Mathematics is the supreme nostalgia of our time. - 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] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 11:51:18PM +0200, Andi Kleen wrote: > > > If that was the policy it would be a quite dumb one and make netpoll > > > totally unsuitable for production use. I hope it is not. > > > > Suggest you rip __GFP_NOFAIL out of JBD before complaining about this. > > So you're suggesting we should become as bad at handling networking > errors as we are at handling IO errors? No, I'm suggesting that the machine will hang forever sometimes and no amount of patching up netpoll or JBD, etc. will fix that. A hardware watchdog is a requirement for robust failover anyway and if you think otherwise, you're dreaming. And for reference, both are examples of theoretical should-never-happen memory allocation failures. > > > Dave, can you please apply the timeout patch anyways? > > > > Yes, let's go right over the maintainer's objections almost > > immediately after he chimes into the thread. I'll spare the list the > > colorful language this inspires. > > Sure when the maintainer has a unreasonable position on something > I think that's justified. Yours in this case is clearly unreasonable. What's clear is that you didn't like my position from my very first post in this thread and immediately went for the nuclear option without even trying to discuss it. Are you even aware that the patch we're discussing here is for a problem that has yet to be observed and that Steven's initial analysis had missed a couple things? -- Mathematics is the supreme nostalgia of our time. - 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: lockups with netconsole on e1000 on media insertion
On Sat, Aug 06, 2005 at 01:51:22AM +0200, Andi Kleen wrote: > > But why are we in a hurry to dump the backlog on the floor? Why are we > > worrying about the performance of netpoll without the cable plugged in > > at all? We shouldn't be optimizing the data loss case. > > Because a system shouldn't stall for minutes (or forever like right now) > at boot just because the network cable isn't plugged in. Using netconsole without a network cable could well be classified as a serious configuration error. NFS also is a bit sluggish without a network cable. I've already agreed that forever is a problem. Can we work towards agreeing on a non-trivial timeout, please? -- Mathematics is the supreme nostalgia of our time. - 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] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 08:23:55PM -0400, Steven Rostedt wrote: > On Fri, 2005-08-05 at 14:28 -0700, Matt Mackall wrote: > > > > Netpoll generally must assume it won't get a second chance, as it's > > being called by things like oops() and panic() and used by things like > > kgdb. If netpoll fails, the box is dead anyway. > > But it is also being called by every printk in the kernel. What happens > when the printk that causes this lock up is not a panic but just some > info print. One would use netconsole when they turn on more verbose > printing, to keep the output fast, right? So if the system gets a > little memory tight, but not to the point of failing, this will cause a > lock up and no one would know why. This doesn't happen, or if it does, it happens far less often than genuine crashes. This can only happen when netpoll's burned through its entire pool of SKBs in a single interrupt and the card never releases them, despite repeated prodding. In other words, you'll get most of a dump out of the box, but you're probably screwed no matter what you do. Also note that _any_ printk can be the kernel's dying breath. This is why for both serial and video we do polled I/O to be sure we actually get our message out. Netconsole is no different. > If you need to really get the data out, then the design should be > changed. Have some return value showing the failure, check for > oops_in_progress or whatever, and try again after turning interrupts > back on, and getting to a point where the system can free up memory > (write to swap, etc). Just a busy loop without ever getting a skb is > just bad. Why, pray tell, do you think there will be a second chance after re-enabling interrupts? How does this work when we're panicking or oopsing where we most care? How does this work when the netpoll client is the kernel debugger and the machine is completely stopped because we're tracing it? As for busy loops, let me direct you to the "poll" part of the name. It is in fact the whole point. > > > So even a long timeout would not do? So you don't even get a message to > > > the console? > > > > In general, there's no way to measure time here. And if we're > > using netconsole, what makes you think there's any other console? > > Why assume that there isn't another console? The screen may be used > with netconsole, you just lose whatever has been scrolled too far. Yes, there may be another console, but we should by no means depend on that being the case. We should in fact assume it's not. > > > > > Also, as Andi told me, the printk here would probably not show up > > > > > anyway if this happens with netconsole. > > > > > > > > That's fine. But in fact, it does show up occassionally - I've seen > > > > it. > > > > > > Then maybe what Andi told me is not true ;-) > > > > > > Oh, and did your machine crash when you saw it? Have you seen it with > > > the e1000 driver? > > > > No and no. Most of my own testing is done with tg3. > > > > If you saw the message and the system didn't crash, then that's proof > that if the driver is not working properly, you would have lock up the > system, and the system was _not_ in a state that it _had_ to get the > message out. Let me be more precise. I've seen it in the middle of an oops dump, where it complained, then made further progress, and then died. In other words, the code works. And I've since upped the pool size. -- Mathematics is the supreme nostalgia of our time. - 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] netpoll can lock up on low memory.
On Sat, Aug 06, 2005 at 09:58:27AM +0200, Ingo Molnar wrote: > > btw., the current NR_SKBS 32 in netpoll.c seems quite low, especially > e1000 can have a whole lot more skbs queued at once. Might be more > robust to increase it to 128 or 256? Not sure that the card's queueing really makes a difference. It either eventually releases the queued SKBs or it doesn't. What's more important is that we be able to survive bursts like the output of sysrq-t. This seems to work already. -- Mathematics is the supreme nostalgia of our time. - 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] netpoll can lock up on low memory.
On Sat, Aug 06, 2005 at 05:57:20AM -0400, Steven Rostedt wrote: > On Sat, 2005-08-06 at 02:46 -0700, David S. Miller wrote: > > Can you guys stop peeing your pants over this, put aside > > your differences, and work on a mutually acceptable fix > > for these bugs? > > > > Much appreciated, thanks :-) > > In my last email, I stated that this discussion seems to have > demonstrated that the e1000 driver's netpoll is indeed broken, and needs > to be fixed. I submitted eariler a patch for this, but it's untested > and someone who owns an e1000 needs to try it. I've got your e1000 change in my queue and I'll try to test it tomorrow (realized I've got e1000 in my laptop). > As for all the netpoll issues, I'm satisfied with whatever you guys > decide. But I've seen lots of problems posted over the netpoll and > e1000, where people send in patches that do everything but fix the > e1000, and that's where I chimed in. Andi's patch looks like it fixes a related but slightly different problem. I'm working on a variant. And I'll try to make the skb allocation code eventually give up too. -- Mathematics is the supreme nostalgia of our time. - 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] fix make clean damaging hg repos
# HG changeset patch # User Matt Mackall <[EMAIL PROTECTED]> # Node ID d3e83cde10ebc2a570503c1ff9c4d9e8f37f4af9 # Parent 915766b005c1a990ea360affa0c025087e45c723 Keep make clean from deleting files in .hg Running 'make clean' was quietly deleting files in Mercurial kernel repositories matching '.*.d', which was corrupting the tags portions of the repository. Spotted and fixed by several people. Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> diff -r 915766b005c1 -r d3e83cde10eb Makefile --- a/Makefile Sat Aug 6 20:06:30 2005 +++ b/Makefile Tue Aug 9 04:08:06 2005 @@ -374,8 +374,8 @@ # Files to ignore in find ... statements -RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS -o -name .pc \) -prune -o -RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn --exclude CVS --exclude .pc +RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS -o -name .pc -o -name .hg \) -prune -o +RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn --exclude CVS --exclude .pc --exclude .hg # === # Rules shared between *config targets and build targets -- Mathematics is the supreme nostalgia of our time. - 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 6/8] netpoll: pre-fill skb pool
we could do one thing (see the patch below): i think it would be useful to fill up the netlogging skb queue straight at initialization time. Especially if netpoll is used for dumping alone, the system might not be in a situation to fill up the queue at the point of crash, so better be a bit more prepared and keep the pipeline filled. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> I've modified this to be called earlier - mpm Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> Index: l/net/core/netpoll.c === --- l.orig/net/core/netpoll.c 2005-08-08 23:00:48.0 -0500 +++ l/net/core/netpoll.c2005-08-11 01:50:31.0 -0500 @@ -724,6 +724,10 @@ int netpoll_setup(struct netpoll *np) npinfo->rx_np = np; spin_unlock_irqrestore(&npinfo->rx_lock, flags); } + + /* fill up the skb queue */ + refill_skbs(); + /* last thing to do is link it to the net device structure */ ndev->npinfo = npinfo; - 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 8/8] netpoll: remove unused variable
Remove unused variable Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> Index: l/net/core/netpoll.c === --- l.orig/net/core/netpoll.c 2005-08-11 01:32:01.0 -0500 +++ l/net/core/netpoll.c2005-08-11 01:49:37.0 -0500 @@ -356,7 +356,6 @@ static void arp_reply(struct sk_buff *sk unsigned char *arp_ptr; int size, type = ARPOP_REPLY, ptype = ETH_P_ARP; u32 sip, tip; - unsigned long flags; struct sk_buff *send_skb; struct netpoll *np = NULL; - 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 7/8] netpoll: fix initialization/NAPI race
This fixes a race during initialization with the NAPI softirq
processing by using an RCU approach.
This race was discovered when refill_skbs() was added to
the setup code.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: l/net/core/netpoll.c
===
--- l.orig/net/core/netpoll.c 2005-08-09 00:56:23.0 -0500
+++ l/net/core/netpoll.c2005-08-11 01:50:24.0 -0500
@@ -731,6 +731,9 @@ int netpoll_setup(struct netpoll *np)
/* last thing to do is link it to the net device structure */
ndev->npinfo = npinfo;
+ /* avoid racing with NAPI reading npinfo */
+ synchronize_rcu();
+
return 0;
release:
Index: l/include/linux/netpoll.h
===
--- l.orig/include/linux/netpoll.h 2005-08-09 00:56:23.0 -0500
+++ l/include/linux/netpoll.h 2005-08-11 01:33:42.0 -0500
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
struct netpoll;
@@ -61,25 +62,31 @@ static inline int netpoll_rx(struct sk_b
return ret;
}
-static inline void netpoll_poll_lock(struct net_device *dev)
+static inline void *netpoll_poll_lock(struct net_device *dev)
{
+ rcu_read_lock(); /* deal with race on ->npinfo */
if (dev->npinfo) {
spin_lock(&dev->npinfo->poll_lock);
dev->npinfo->poll_owner = smp_processor_id();
+ return dev->npinfo;
}
+ return NULL;
}
-static inline void netpoll_poll_unlock(struct net_device *dev)
+static inline void netpoll_poll_unlock(void *have)
{
- if (dev->npinfo) {
- dev->npinfo->poll_owner = -1;
- spin_unlock(&dev->npinfo->poll_lock);
+ struct netpoll_info *npi = have;
+
+ if (npi) {
+ npi->poll_owner = -1;
+ spin_unlock(&npi->poll_lock);
}
+ rcu_read_unlock();
}
#else
#define netpoll_rx(a) 0
-#define netpoll_poll_lock(a)
+#define netpoll_poll_lock(a) 0
#define netpoll_poll_unlock(a)
#endif
Index: l/net/core/dev.c
===
--- l.orig/net/core/dev.c 2005-08-09 00:56:23.0 -0500
+++ l/net/core/dev.c2005-08-11 01:34:08.0 -0500
@@ -1696,7 +1696,8 @@ static void net_rx_action(struct softirq
struct softnet_data *queue = &__get_cpu_var(softnet_data);
unsigned long start_time = jiffies;
int budget = netdev_budget;
-
+ void *have;
+
local_irq_disable();
while (!list_empty(&queue->poll_list)) {
@@ -1709,10 +1710,10 @@ static void net_rx_action(struct softirq
dev = list_entry(queue->poll_list.next,
struct net_device, poll_list);
- netpoll_poll_lock(dev);
+ have = netpoll_poll_lock(dev);
if (dev->quota <= 0 || dev->poll(dev, &budget)) {
- netpoll_poll_unlock(dev);
+ netpoll_poll_unlock(have);
local_irq_disable();
list_del(&dev->poll_list);
list_add_tail(&dev->poll_list, &queue->poll_list);
@@ -1721,7 +1722,7 @@ static void net_rx_action(struct softirq
else
dev->quota = dev->weight;
} else {
- netpoll_poll_unlock(dev);
+ netpoll_poll_unlock(have);
dev_put(dev);
local_irq_disable();
}
-
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 3/8] netpoll: e1000 netpoll tweak
Suggested by Steven Rostedt, matches his patch included in e100. Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> Index: l/drivers/net/e1000/e1000_main.c === --- l.orig/drivers/net/e1000/e1000_main.c 2005-08-06 17:36:32.0 -0500 +++ l/drivers/net/e1000/e1000_main.c2005-08-06 17:55:01.0 -0500 @@ -3789,6 +3789,7 @@ e1000_netpoll(struct net_device *netdev) struct e1000_adapter *adapter = netdev_priv(netdev); disable_irq(adapter->pdev->irq); e1000_intr(adapter->pdev->irq, netdev, NULL); + e1000_clean_tx_irq(adapter); enable_irq(adapter->pdev->irq); } #endif - 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 2/8] netpoll: deadlock bugfix
This fixes an obvious deadlock in the netpoll code. netpoll_rx takes the npinfo->rx_lock. netpoll_rx is also the only caller of arp_reply (through __netpoll_rx). As such, it is not necessary to take this lock. Signed-off-by: Jeff Moyer <[EMAIL PROTECTED]> Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> Index: l/net/core/netpoll.c === --- l.orig/net/core/netpoll.c 2005-08-06 17:47:48.0 -0500 +++ l/net/core/netpoll.c2005-08-06 17:47:49.0 -0500 @@ -353,11 +353,8 @@ static void arp_reply(struct sk_buff *sk struct sk_buff *send_skb; struct netpoll *np = NULL; - spin_lock_irqsave(&npinfo->rx_lock, flags); if (npinfo->rx_np && npinfo->rx_np->dev == skb->dev) np = npinfo->rx_np; - spin_unlock_irqrestore(&npinfo->rx_lock, flags); - if (!np) return; - 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 0/8] netpoll: various bugfixes
This patch series cleans up a few outstanding bugs in netpoll: - two bugfixes from Jeff Moyer's netpoll bonding - a tweak to e1000's netpoll stub - timeout handling for e1000 with carrier loss - prefilling SKBs at init - a fix-up for a race discovered in initialization - an unused variable warning This patch set was tested over repeated rebooting with both tg3 and e1000 and random cable disconnection, with and without SMP and preempt. Please apply. - 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 1/8] netpoll: rx_flags bugfix
Initialize npinfo->rx_flags. The way it stands now, this will have random garbage, and so will incur a locking penalty even when an rx_hook isn't registered and we are not active in the netpoll polling code. Signed-off-by: Jeff Moyer <[EMAIL PROTECTED]> Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> --- linux-2.6.12/net/core/netpoll.c.orig2005-07-01 14:02:56.039174635 -0400 +++ linux-2.6.12/net/core/netpoll.c 2005-07-01 14:03:16.688739508 -0400 @@ -639,6 +639,7 @@ int netpoll_setup(struct netpoll *np) if (!npinfo) goto release; + npinfo->rx_flags = 0; npinfo->rx_np = NULL; npinfo->poll_lock = SPIN_LOCK_UNLOCKED; npinfo->poll_owner = -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/
[PATCH 4/8] netpoll: netpoll_send_skb simplify
Minor netpoll_send_skb restructuring
Restructure to avoid confusing goto and move some bits out of the
retry loop.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: l/net/core/netpoll.c
===
--- l.orig/net/core/netpoll.c 2005-08-07 15:15:48.0 -0500
+++ l/net/core/netpoll.c2005-08-07 16:59:27.0 -0500
@@ -248,14 +248,14 @@ static void netpoll_send_skb(struct netp
int status;
struct netpoll_info *npinfo;
-repeat:
- if(!np || !np->dev || !netif_running(np->dev)) {
+ if (!np || !np->dev || !netif_running(np->dev)) {
__kfree_skb(skb);
return;
}
- /* avoid recursion */
npinfo = np->dev->npinfo;
+
+ /* avoid recursion */
if (npinfo->poll_owner == smp_processor_id() ||
np->dev->xmit_lock_owner == smp_processor_id()) {
if (np->drop)
@@ -265,29 +265,31 @@ repeat:
return;
}
- spin_lock(&np->dev->xmit_lock);
- np->dev->xmit_lock_owner = smp_processor_id();
+ while (1) {
+ spin_lock(&np->dev->xmit_lock);
+ np->dev->xmit_lock_owner = smp_processor_id();
+
+ /*
+* network drivers do not expect to be called if the queue is
+* stopped.
+*/
+ if (netif_queue_stopped(np->dev)) {
+ np->dev->xmit_lock_owner = -1;
+ spin_unlock(&np->dev->xmit_lock);
+ netpoll_poll(np);
+ continue;
+ }
- /*
-* network drivers do not expect to be called if the queue is
-* stopped.
-*/
- if (netif_queue_stopped(np->dev)) {
+ status = np->dev->hard_start_xmit(skb, np->dev);
np->dev->xmit_lock_owner = -1;
spin_unlock(&np->dev->xmit_lock);
- netpoll_poll(np);
- goto repeat;
- }
-
- status = np->dev->hard_start_xmit(skb, np->dev);
- np->dev->xmit_lock_owner = -1;
- spin_unlock(&np->dev->xmit_lock);
+ /* success */
+ if(!status)
+ return;
- /* transmit busy */
- if(status) {
+ /* transmit busy */
netpoll_poll(np);
- goto repeat;
}
}
-
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 3/8] netpoll: e1000 netpoll tweak
[corrected akpm's address] On Fri, Aug 12, 2005 at 12:02:03PM -0700, John Ronciak wrote: > Sorry this reply was to go to the whole list but only made it to Matt. > > The e1000_intr() routine already calls e1000_clean_tx_irq(). So > what's the point of this patch? Am I missing something? Here is Steven's original analysis: http://lkml.org/lkml/2005/8/5/116 It looked plausible, but I didn't dig much deeper. > > Index: l/drivers/net/e1000/e1000_main.c > > === > > --- l.orig/drivers/net/e1000/e1000_main.c 2005-08-06 > > 17:36:32.0 -0500 > > +++ l/drivers/net/e1000/e1000_main.c2005-08-06 17:55:01.0 -0500 > > @@ -3789,6 +3789,7 @@ e1000_netpoll(struct net_device *netdev) > > struct e1000_adapter *adapter = netdev_priv(netdev); > > disable_irq(adapter->pdev->irq); > > e1000_intr(adapter->pdev->irq, netdev, NULL); > > + e1000_clean_tx_irq(adapter); > > enable_irq(adapter->pdev->irq); > > } > > #endif -- Mathematics is the supreme nostalgia of our time. - 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 0/8] netpoll: various bugfixes
[corrected akpm's address] On Fri, Aug 12, 2005 at 07:21:51PM +0200, Olaf Hering wrote: > On Thu, Aug 11, Matt Mackall wrote: > > > This patch series cleans up a few outstanding bugs in netpoll: > > > > - two bugfixes from Jeff Moyer's netpoll bonding > > - a tweak to e1000's netpoll stub > > - timeout handling for e1000 with carrier loss > > - prefilling SKBs at init > > - a fix-up for a race discovered in initialization > > - an unused variable warning > > Matt, I have tested them, the sender doesnt lockup anymore. But a > task dump doesnt work, I get only the first task. This is on a 3GHz xeon > with tg3 card. Does the task dump work without patch 5/8 (add retry timeout)? I'll try testing it here. -- Mathematics is the supreme nostalgia of our time. - 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 0/8] netpoll: various bugfixes
On Fri, Aug 12, 2005 at 09:31:09PM +0200, Olaf Hering wrote: > On Fri, Aug 12, Matt Mackall wrote: > > > Does the task dump work without patch 5/8 (add retry timeout)? I'll > > try testing it here. > > I spoke to soon, worked once, after reboot not anymore. Will try to play > with individual patches. Does the task dump work for you, at least? Works flawlessly on e1000. Works on tg3 with serial console, but seems to cause trouble without. Haven't had time to dig deeper yet. -- Mathematics is the supreme nostalgia of our time. - 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] Fix nice range for RLIMIT NICE
Looks like I let this one slip through the cracks:
Make RLIMIT_NICE ranges consistent with getpriority(2)
As suggested by Michael Kerrisk <[EMAIL PROTECTED]>, make
RLIMIT_NICE consistent with getpriority before it becomes available in
released glibc.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Acked-by: Chris Wright <[EMAIL PROTECTED]>
Index: lhg/kernel/sched.c
===
--- lhg.orig/kernel/sched.c 2005-08-15 13:03:05.0 -0700
+++ lhg/kernel/sched.c 2005-08-15 13:09:21.0 -0700
@@ -3378,8 +3378,8 @@ EXPORT_SYMBOL(set_user_nice);
*/
int can_nice(const task_t *p, const int nice)
{
- /* convert nice value [19,-20] to rlimit style value [0,39] */
- int nice_rlim = 19 - nice;
+ /* convert nice value [19,-20] to rlimit style value [1,40] */
+ int nice_rlim = 20 - nice;
return (nice_rlim <= p->signal->rlim[RLIMIT_NICE].rlim_cur ||
capable(CAP_SYS_NICE));
}
--
Mathematics is the supreme nostalgia of our time.
-
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.12-rc2] revert fs/char_dev.c CONFIG_BASE_FULL change
On Sun, Apr 17, 2005 at 10:06:53AM -0700, David Brownell wrote: > I tracked down a regression in PCMCIA (and other software) to a > new bogus register_chrdev() behavior that got merged last month; > a patch from Matt Mackall that misbehaves. Thanks and sorry about that. I actually asked Linus to revert it right after Andrew pushed it to him, but I hadn't actually seen a problem report so I didn't pursue it. > This patch just reverts Matt's, restoring the previous behavior > but at the cost of about a Kbyte of static memory on 32bit CPUs. > Someday a Real Fix(tm) would be good. I've got a Real Fix (a refactor of block and chardev name registration), will need to wait for .12. > Signed-off-by: David Brownell <[EMAIL PROTECTED]> Acked-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - 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: 2.6 patch] drivers/char/random.c: #if 0 randomize_range
On Sun, Apr 17, 2005 at 10:15:37PM +0200, Adrian Bunk wrote:
> This patch #if 0's the unused global function randomize_range.
>
This is presumably for future work in process randomization. Arjan,
what's the status of this bit?
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> drivers/char/random.c |2 ++
> include/linux/random.h |1 -
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> --- linux-2.6.12-rc2-mm3-full/include/linux/random.h.old 2005-04-17
> 18:17:17.0 +0200
> +++ linux-2.6.12-rc2-mm3-full/include/linux/random.h 2005-04-17
> 18:17:23.0 +0200
> @@ -65,7 +65,6 @@
> #endif
>
> unsigned int get_random_int(void);
> -unsigned long randomize_range(unsigned long start, unsigned long end,
> unsigned long len);
>
> #endif /* __KERNEL___ */
>
> --- linux-2.6.12-rc2-mm3-full/drivers/char/random.c.old 2005-04-17
> 18:17:30.0 +0200
> +++ linux-2.6.12-rc2-mm3-full/drivers/char/random.c 2005-04-17
> 18:18:12.0 +0200
> @@ -1618,6 +1618,7 @@
> * a with size "len" starting at the return value is inside in the
> * area defined by [start, end], but is otherwise randomized.
> */
> +#if 0
> unsigned long
> randomize_range(unsigned long start, unsigned long end, unsigned long len)
> {
> @@ -1627,3 +1628,4 @@
> return 0;
> return PAGE_ALIGN(get_random_int() % range + start);
> }
> +#endif /* 0 */
--
Mathematics is the supreme nostalgia of our time.
-
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: Fortuna
[please reply to all when posting to lkml] On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote: > >First, a reminder that the design goal of /dev/random proper is > >information-theoretic security. That is, it should be secure against > >an attacker with infinite computational power. > > I am skeptical. > I have never seen any convincing evidence for this claim, > and I suspect that there are cases in which /dev/random fails > to achieve this standard. > > And it seems I am not the only one. See, e.g., Section 5.3 of: > http://eprint.iacr.org/2005/029 Unfortunately, this paper's analysis of /dev/random is so shallow that they don't even know what hash it's using. Almost all of section 5.3 is wrong (and was when I read it initially). -- Mathematics is the supreme nostalgia of our time. - 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/
Mercurial v0.1 - a minimal scalable distributed SCM
http://selenic.com/mercurial/ April 19, 2005 I've spent the past couple weeks working on a completely new proof-of-concept SCM. The goals: - to initially be as simple (and thereby hackable) as possible - to be as scalable as possible - to be memory, disk, and bandwidth efficient - to be able to do "clone/branch and pull/sync" style development It's still very early on, but I think I'm doing surprisingly well. Now that I've got something that actually does some interesting things if you poke at it right, I figure it's time to throw it out there. Here's what I've got so far: - O(1) file revision storage and retrieval with efficient delta compression - efficient append-only layout for rsync and http range protocols - bare bones commit, checkout, stat, history - working "clone/branch" and "pull/sync" functionality - functional enough to be self-hosting[1] - all in less than 600 lines of Python When I say "pull/sync" works, that means I can do: hg merge other-repo and it will pull all "changesets/deltas" that are in other-dir that I don't have, merge them into the changeset history graph, and do the same for all files changed for those deltas. It will call out to a user-specified merge tool like tkdiff for a proper 3-way merge with the nearest common ancestor in the case of conflicts. Right now, "cloning/branching" is simply a matter of "cp -al" or "rsync" (mercurial knows how to break hardlinks if needed). Some benchmarks from my laptop: - prepare for commit of Linux 2.6.10: ~1s - commit Linux 2.6.10: 27s - checkout Linux 2.6.10: 45s - full tree stat for added/changed/deleted files: <1s - local hardlink clone: 1.5s - empty merge between full trees: <.1s - trivial 3-way merge with changes to Makefile: ~1s Much thought has gone into what the best asymptotic performance can be for the various things an SCM has to do and the core algorithms and data structures here should scale relatively painlessly to arbitrary numbers of changesets, files, and file revisions. What remains to be done: - a halfway-usable command line tool - remote (network) repository support - diff generation - changelog entry editing - various manual interventions for merge - handle rename - handle rollback - all sorts of other error handling - all sorts of cleanup, packaging, documentation, testing... Sample usage: export HGMERGE=tkmerge # set a 3-way merge tool mkdir foo hg create# create a repository in .hg/ echo foo > Makefile hg add Makefile # add a file to the current changeset hg commit# commit files currently marked for add or delete hg history # show all changesets hg index Makefile# show change touch Makefile hg stat # find changed files cd ..; cp -al foo branch # make a branch hg merge ../branch-foo# sync changesets from a branch [1] though the repository format is still in flux -- Mathematics is the supreme nostalgia of our time. - 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/
Mercurial distributed SCM v0.2
This is my continuing attempt to make an SCM suitable for kernel hacking. It supports a distribution model similar to BK and Monotone but is orders of magnitude simpler than both (about 1k lines of code). http://selenic.com/mercurial/ New in this version: - much improved command line tool - installation instructions - commit log editing - experimental network pull support Some example usage: Setting up a Mercurial project: $ cd linux/ $ hg init # creates .hg $ hg status # show differences between repo and working dir $ hg addremove# add all unknown files and remove all missing files $ hg commit # commit all changes, edit changelog entry Mercurial commands: $ hg history # show changesets $ hg log Makefile # show commits per file $ hg checkout # check out the tip revision $ hg checkout # check out a specified changeset $ hg add foo # add a new file for the next commit $ hg remove bar # mark a file as removed Branching and merging: $ cd .. $ cp -al linux linux-work # create a new hardlink branch $ cd linux-work $ $ hg commit $ cd ../linux $ hg merge ../linux-work# pull changesets from linux-work Network support (highly experimental): # export your .hg directory as a directory on your webserver foo$ ln -s .hg ~/public_html/hg-linux # merge changes from a remote machine bar$ hg merge http://foo/~user/hg-linux This is just a proof of concept of grabbing byte ranges, and is not expected to perform well yet. -- Mathematics is the supreme nostalgia of our time. - 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 2.6.13-rc2
On Tue, Jul 05, 2005 at 09:32:34PM -0700, Linus Torvalds wrote: > > Ok, > -rc3 is pretty small, with the bulk of the diff being some defconfig > updates, and cleanup of xtensa (notably removal of another copy of zlib). Hmm. -rc2: in title, in tags, in makefile, in patch file name -rc3: in git commit message and in body of email -rc3 appears to be outvoted. -- Mathematics is the supreme nostalgia of our time. - 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: [swsusp] encrypt suspend data for easy wiping
On Mon, Jul 25, 2005 at 08:10:36PM -0700, Andrew Morton wrote: > Andreas Steinmetz <[EMAIL PROTECTED]> wrote: > > > > the attached patches are acked by Pavel and signed off by me > > OK, well I queued this up, without a changelog. Because you didn't send > one. Please do so. As it adds a new feature, quite a bit of info is > relevant. I don't like this patch. It reinvents a fair amount of dm_crypt and cryptoloop but badly. Further, the model of security it's using is silly. In case anyone hasn't noticed, it stores the password on disk in the clear. This is so it can erase it after resume and thereby make recovery of the suspend image hard. But laptops get stolen while they're suspended, not while they're up and running. And if your box is up and running and an attacker gains access, the contents of your suspend partition are the least of your worries. It makes no sense to expend any effort defending against this case, especially as it's liable to become a barrier to doing this right, namely with real dm_crypt encrypted swap. At the very least, this should be renamed SWSUSP_QUICK_WIPE and any mention of encryption should be taken out of the description so users don't mistakenly think it provides any sort of useful protection. -- Mathematics is the supreme nostalgia of our time. - 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: [swsusp] encrypt suspend data for easy wiping
On Wed, Jul 27, 2005 at 12:14:46AM +0200, Pavel Machek wrote: > Hi! > > > > > the attached patches are acked by Pavel and signed off by me > > > > > > OK, well I queued this up, without a changelog. Because you didn't send > > > one. Please do so. As it adds a new feature, quite a bit of info is > > > relevant. > > > > I don't like this patch. It reinvents a fair amount of dm_crypt and > > cryptoloop but badly. > > > > Further, the model of security it's using is silly. In case anyone > > hasn't noticed, it stores the password on disk in the clear. This is > > so it can erase it after resume and thereby make recovery of the > > suspend image hard. > > > > But laptops get stolen while they're suspended, not while they're up > > and running. And if your box is up and running and an attacker gains > > access, the contents of your suspend partition are the least of your > > worries. It makes no sense to expend any effort defending against this > > case, especially as it's liable to become a barrier to doing this > > right, namely with real dm_crypt encrypted swap. > > Well, "how long are my keys going to stay in swap after > swsusp"... that's pretty scary. Either they're likely in RAM _anyway_ and are thus already trivially accessible to the attacker (for things like dm_crypt or IPSEC or ssh-agent), or the application took care to zero them out, or the application has a security bug. There are about 4 attack cases, in order of likelihood: 1) An attacker steals your suspended laptop. He has access to all your suspended data. This patch gets us exactly nothing. 2) An attacker breaks into your machine remotely while you're using it. He has access to all your RAM, which if you're actually using it, very likely including the same IPSEC, dm_crypt, and ssh-agent keys as are saved on suspend. Further, he can trivially capture your keystrokes and thus capture any keys you use from that point forward. This patch gets us very close to nothing. 3) An attacker steals your unsuspended laptop. He has access to all your RAM, which in all likelihood includes your IPSEC, dm_crypt, and ssh-agent keys. Odds are good that he invokes swsusp by closing the laptop. This patch gets us very close to nothing. 4) You suspend your laptop between typing your GPG key password and hitting enter, thus leaving your password in memory when it would otherwise be cleared. Then you resume your laptop and hit enter, thus clearing the password from RAM but leaving it on the suspend partition. Then an attacker steals your machine (without re-suspending it!) and manages to recover the swsusp image which contains the password. But with this patch, he's foiled because the password is encrypted and the key's been erased! He's got all your other data though, including all the aforementioned long-lived keys. The right fix for case 1 is dm_crypt with a password prompt. The right fix for 2 is beyond the scope of this email, but probably begins with the letters s and e. The fix for 1 goes a long way towards fixing 3 as well, provided the attacker suspends your machine. And I claim that anyone who is paranoid enough to actually care about corner cases like 4 should damn well care about case 1 too, and should be more than willing to type a password on resume, otherwise they're just fooling themselves. Together with the fact that this reimplements dm_crypt functionality with an unreviewed and cryptographically naive replacement, I don't think this patch makes any sense at all. -- Mathematics is the supreme nostalgia of our time. - 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] NETCONSOLE must depend on INET
On Tue, Jul 19, 2005 at 02:01:04PM -0700, David S. Miller wrote: > From: Adrian Bunk <[EMAIL PROTECTED]> > Date: Tue, 19 Jul 2005 20:29:19 +0200 > > > NETCONSOLE=y and INET=n results in the following compile error: > > Also applied, thanks Adrian. I should have been cc:ed on this. This problem also exists in PKTGEN. And this fix is incorrect as neither is dependent on the IP part of the networking stack in any substantive way. The right fix is to make inet_aton available outside of CONFIG_INET (preferred) or making private copies of inet_aton. -- Mathematics is the supreme nostalgia of our time. - 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: [swsusp] encrypt suspend data for easy wiping
On Wed, Jul 27, 2005 at 01:12:49AM +0200, Pavel Machek wrote: > Hi! > > > > Well, "how long are my keys going to stay in swap after > > > swsusp"... that's pretty scary. > > > > Either they're likely in RAM _anyway_ and are thus already trivially > > accessible to the attacker (for things like dm_crypt or IPSEC or > > ssh-agent), or the application took care to zero them out, or the > > application has a security bug. > > > > There are about 4 attack cases, in order of likelihood: > > > > 1) An attacker steals your suspended laptop. He has access to all your > > suspended data. This patch gets us exactly nothing. > > Wrong. Without this Andreas' patch, he'll get access to your > half-a-year-old GPG passphrases, too. Ok, I'll revise that to "very close to nothing". See below. > > 2) An attacker breaks into your machine remotely while you're using > > it. He has access to all your RAM, which if you're actually using it, > > very likely including the same IPSEC, dm_crypt, and ssh-agent keys as > > are saved on suspend. Further, he can trivially capture your > > keystrokes and thus capture any keys you use from that point forward. > > This patch gets us very close to nothing. > > > > 3) An attacker steals your unsuspended laptop. He has access to all > > your RAM, which in all likelihood includes your IPSEC, dm_crypt, and > > ssh-agent keys. Odds are good that he invokes swsusp by closing the > > laptop. This patch gets us very close to nothing. > > > > 4) You suspend your laptop between typing your GPG key password and > > hitting enter, thus leaving your password in memory when it would > > otherwise be cleared. Then you resume your laptop and hit enter, thus > > clearing the password from RAM but leaving it on the suspend > > partition. Then an attacker steals your machine (without re-suspending > > it!) and manages to recover the swsusp image which contains the > > Why without resuspending it? Position of critical data in swap is > pretty much random. Typical swap partition sizes are about the same as RAM sizes. So the odds of any given thing in a previous suspend getting overwritten by the next one are high. > What I'm worried is: attacker steals your laptop after you were using > swsusp for half a year. Now your swap partition contains random pieces > of GPG keys you were using for last half a year. That's bad. And it's incredibly unlikely. Suspending while a supposedly short-lived key is in RAM should be rare. Surviving on disk after half a year of swapping and suspending should be negligible probability. It's not worth even thinking about when we have real suspended laptops getting stolen every day in REAL LIFE. Anyone who cares about your highly contrived case also cares about 1000 times more about the real life case of the stolen laptop. Otherwise they're fooling themselves. This code is bad. It attacks a very rare problem, gives its users (and apparently its authors) a false sense of security, reimplements dm_crypt functionality apparently without much attention to the subtleties of block device encryption and without serious review, and it stands in the way of doing things right. If we're going to encrypt the suspend image, let's do it right. Let's cover the real life cases and reuse code that's intended for this purpose. -- Mathematics is the supreme nostalgia of our time. - 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] NETCONSOLE must depend on INET
On Tue, Jul 26, 2005 at 04:32:02PM -0700, David S. Miller wrote: > From: Matt Mackall <[EMAIL PROTECTED]> > Date: Tue, 26 Jul 2005 16:20:43 -0700 > > > This problem also exists in PKTGEN. And this fix is incorrect as > > neither is dependent on the IP part of the networking stack in any > > substantive way. The right fix is to make inet_aton available outside > > of CONFIG_INET (preferred) or making private copies of inet_aton. > > Adrian posted a fix, you whine, that's why Adrian's fix > went in :-) Adrian's fix is the moral equivalent of throwing in a cast to shut up a compiler warning for a legitimate bug. > More seriously, please submit a version of whatever you > believe to be the more correct fix so it can be reviewed > and integrated. Do you have a preferred location to put this function or shall I invent one? -- Mathematics is the supreme nostalgia of our time. - 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] NETCONSOLE must depend on INET
[sch added to cc: as I think he's the effective pktgen maintainer]
On Tue, Jul 26, 2005 at 05:03:49PM -0700, David S. Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Tue, 26 Jul 2005 16:58:24 -0700
>
> > On Tue, Jul 26, 2005 at 04:32:02PM -0700, David S. Miller wrote:
> > > More seriously, please submit a version of whatever you
> > > believe to be the more correct fix so it can be reviewed
> > > and integrated.
> >
> > Do you have a preferred location to put this function or
> > shall I invent one?
>
> I actually can't wait to see where you're going to
> to put a function that transforms "IPV4 addresses"
> from ascii other than some place protected by CONFIG_INET.
> :-)
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 6cdd6f36d53678a016cfbf5ce667cbd91504d538
# Parent 75716ae25f9d87ee2a5ef7c4df2d8f86e0f3f762
Move in_aton from net/ipv4/utils.c to net/core/utils.c
Move in_aton to allow netpoll and pktgen to work without the rest of
the IPv4 stack. Fix whitespace and add comment for the odd placement.
Delete now-empty net/ipv4/utils.c
Re-enable netpoll/netconsole without CONFIG_INET
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
diff -r 75716ae25f9d -r 6cdd6f36d536 drivers/net/Kconfig
--- a/drivers/net/Kconfig Tue Jul 26 23:21:24 2005
+++ b/drivers/net/Kconfig Wed Jul 27 02:31:24 2005
@@ -2544,7 +2544,7 @@
config NETCONSOLE
tristate "Network console logging support (EXPERIMENTAL)"
- depends on NETDEVICES && INET && EXPERIMENTAL
+ depends on NETDEVICES && EXPERIMENTAL
---help---
If you want to log kernel messages over the network, enable this.
See for details.
diff -r 75716ae25f9d -r 6cdd6f36d536 net/core/utils.c
--- a/net/core/utils.c Tue Jul 26 23:21:24 2005
+++ b/net/core/utils.c Wed Jul 27 02:31:24 2005
@@ -23,9 +23,9 @@
#include
#include
+#include
#include
#include
-
/*
This is a maximally equidistributed combined Tausworthe generator
@@ -153,3 +153,38 @@
EXPORT_SYMBOL(net_random);
EXPORT_SYMBOL(net_ratelimit);
EXPORT_SYMBOL(net_srandom);
+
+/*
+ * Convert an ASCII string to binary IP.
+ * This is outside of net/ipv4/ because various code that uses IP addresses
+ * is otherwise not dependent on the TCP/IP stack.
+ */
+
+__u32 in_aton(const char *str)
+{
+ unsigned long l;
+ unsigned int val;
+ int i;
+
+ l = 0;
+ for (i = 0; i < 4; i++)
+ {
+ l <<= 8;
+ if (*str != '\0')
+ {
+ val = 0;
+ while (*str != '\0' && *str != '.')
+ {
+ val *= 10;
+ val += *str - '0';
+ str++;
+ }
+ l |= val;
+ if (*str != '\0')
+ str++;
+ }
+ }
+ return(htonl(l));
+}
+
+EXPORT_SYMBOL(in_aton);
diff -r 75716ae25f9d -r 6cdd6f36d536 net/ipv4/Makefile
--- a/net/ipv4/Makefile Tue Jul 26 23:21:24 2005
+++ b/net/ipv4/Makefile Wed Jul 27 02:31:24 2005
@@ -2,7 +2,7 @@
# Makefile for the Linux TCP/IP (INET) layer.
#
-obj-y := utils.o route.o inetpeer.o protocol.o \
+obj-y := route.o inetpeer.o protocol.o \
ip_input.o ip_fragment.o ip_forward.o ip_options.o \
ip_output.o ip_sockglue.o \
tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o \
diff -r 75716ae25f9d -r 6cdd6f36d536 net/ipv4/utils.c
--- a/net/ipv4/utils.c Tue Jul 26 23:21:24 2005
+++ /dev/null Wed Jul 27 02:31:24 2005
@@ -1,59 +0,0 @@
-/*
- * INETAn implementation of the TCP/IP protocol suite for the
LINUX
- * operating system. INET is implemented using the BSD Socket
- * interface as the means of communication with the user level.
- *
- * Various kernel-resident INET utility functions; mainly
- * for format conversion and debugging output.
- *
- * Version:$Id: utils.c,v 1.8 2000/10/03 07:29:01 anton Exp $
- *
- * Author: Fred N. van Kempen, <[EMAIL PROTECTED]>
- *
- * Fixes:
- * Alan Cox: verify_area check.
- * Alan Cox: removed old debugging.
- * Andi Kleen : add net_ratelimit()
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include
-#include
-#include
-
-/*
- * Convert an ASCII string to binary IP.
- */
-
Re: [2.6 patch] NETCONSOLE must depend on INET
On Wed, Jul 27, 2005 at 01:19:00PM -0700, David S. Miller wrote: > From: Matt Mackall <[EMAIL PROTECTED]> > Date: Tue, 26 Jul 2005 19:36:37 -0700 > > > # HG changeset patch > > # User [EMAIL PROTECTED] > > # Node ID 6cdd6f36d53678a016cfbf5ce667cbd91504d538 > > # Parent 75716ae25f9d87ee2a5ef7c4df2d8f86e0f3f762 > > Move in_aton from net/ipv4/utils.c to net/core/utils.c > > This patch doesn't apply, in the current 2.6.x GIT tree > NETCONSOLE does not depend on NETDEVICES. Odd, gitweb of Linus' tree seems to disagree. I see it depends on NETDEVICES && INET && EXPERIMENTAL. NETDEVICES has been there since the beginning of git history and according to my Mercurial import from BKCVS, it's been dependent on NETDEVICES since I first submitted it. -- Mathematics is the supreme nostalgia of our time. - 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 MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
On Wed, Jul 27, 2005 at 04:17:54PM +0200, Ingo Molnar wrote: > > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > The following patch makes the MAX_RT_PRIO and MAX_USER_RT_PRIO > > configurable from the make *config. This is more of a proposal since > > I'm not really sure where in Kconfig this would best fit. I don't see > > why these options shouldn't be user configurable without going into > > the kernel headers to change them. > > i'd not do this patch, mainly because the '100 priority levels' thing is > pretty much an assumption in lots of userspace code. The patch to make > it easier to redefine it is of course fine and was accepted, but i dont > think we want to make it explicit via .config. > > It's a bit like with the 3:1 split: you can redefine it easily via > include files, but it's not configurable via .config, because many > people would just play with it and would see things break. > > so unless there's really a desire from distributions to actually change > the 100 RT-prio levels (and i dont sense such a desire), we shouldnt do > this. The queues take a fairly substantial amount of memory. I've had an option for configuring this under CONFIG_EMBEDDED in the -tiny tree for quite some time. -- Mathematics is the supreme nostalgia of our time. - 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] random : prefetch the whole pool, not 1/4 of it
On Fri, Jul 29, 2005 at 12:26:11AM +0200, Eric Dumazet wrote: > Hi Matt > > Could you check this patch and apply it ? > > Thank you > > Eric > > [RANDOM] : prefetch the whole pool, not 1/4 of it, >(pool contains u32 words, not bytes) You probably want r->poolinfo->poolwords as wordmask is off by one? Please use "x * 4" rather than "x*4" too. > --- linux-2.6.13-rc3/drivers/char/random.c2005-07-13 06:46:46.0 > +0200 > +++ linux-2.6.13-rc3-ed/drivers/char/random.c 2005-07-29 00:11:24.0 > +0200 > @@ -469,7 +469,7 @@ > next_w = *in++; > > spin_lock_irqsave(&r->lock, flags); > - prefetch_range(r->pool, wordmask); > + prefetch_range(r->pool, wordmask*4); > input_rotate = r->input_rotate; > add_ptr = r->add_ptr; > -- Mathematics is the supreme nostalgia of our time. - 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: Broke nice range for RLIMIT NICE
On Thu, Jul 28, 2005 at 05:04:24PM +0200, Michael Kerrisk wrote:
> Hello Ingo,
>
> I'm guessing that it was you that added the RLIMIT_NICE resource
> limit in 2.6.12.
The original patch was from Chris Wright, but I did most of the
cheerleading for it.
> (A passing note to all kernel developers: when
> making changes that affect userland-kernel interfaces, please
> send me a man-pages patch, or at least a notification of the
> change, so that some information makes its way into the manual
> pages).
You might want to make an effort to make yourself more visible around
here. Most of us have no idea that anyone's actually trying to
maintain the manpages or who that might be.
> I started documenting RLIMIT_NICE and then noticed an
> inconsistency between the use of this limit and the nice
> value as manipulated by [sg]etpriority().
>
> This is the documentation I've drafted for RLIMIT_NICE
> in getrlimit.2:
>
>RLIMIT_NICE(since kernel 2.6.12)
> Specifies a ceiling to which the process nice
> value can be raised using setpriority(2) or
> nice(2). The actual ceiling for the nice value is
> calculated as 19 - rlim_cur.
> ^
>
> And recently I've redrafted the discussion of the nice value
> in getpriority.2 and it now reads:
>
> Since kernel 1.3.43 Linux has the range -20..19.
> Within the kernel, nice values are actually repre-
> sented using the corresponding range 40..1 (since
> negative numbers are error codes) and these are the
> values employed by the setpriority and getpriority
> system calls. The glibc wrapper functions for
> these system calls handle the translations between
> the user-land and kernel representations of the
> nicevalueaccordingtothe formula
> user_nice = 20 - kernel_nice.
>
>
> In other words, there is an off-by-one mismatch between
> these two interfaces: RLIMIT_NICE is expecting to deal
> with values in the range 39..0, while [gs]etpriority()
> works with the range 40..1.
>
> I suppose that glibc could paper over the cracks here in
> a wrapper for getrlimit(), but it seems more sensible
> to make RLIMIT_NICE consistent with [gs]etpriority() --
> i.e., change the RLIMIT_NICE interface in 2.6.13 before it
> sees wide use in userland. What do you think?
Well, it's easy enough to do, but some thought has to be given to the
corner cases. Specifically, does this do the right thing when the
rlimit is set to zero? I think it does, as the nice range is nicely
bound here:
nice = PRIO_TO_NICE(current->static_prio) + increment;
if (nice < -20)
nice = -20;
if (nice > 19)
nice = 19;
if (increment < 0 && !can_nice(current, nice))
return -EPERM;
And we allow task to do negative increment. Chris?
The other downside is, this obviously changes any existing configs
actually using this by one nice level..
Index: l/kernel/sched.c
===
--- l.orig/kernel/sched.c 2005-06-22 17:55:14.0 -0700
+++ l/kernel/sched.c2005-07-28 22:55:54.0 -0700
@@ -3231,8 +3231,8 @@ EXPORT_SYMBOL(set_user_nice);
*/
int can_nice(const task_t *p, const int nice)
{
- /* convert nice value [19,-20] to rlimit style value [0,39] */
- int nice_rlim = 19 - nice;
+ /* convert nice value [19,-20] to rlimit style value [1,40] */
+ int nice_rlim = 20 - nice;
return (nice_rlim <= p->signal->rlim[RLIMIT_NICE].rlim_cur ||
capable(CAP_SYS_NICE));
}
--
Mathematics is the supreme nostalgia of our time.
-
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 11/15] KGDB: KGDBoE I/O driver
On Fri, Jul 29, 2005 at 02:20:55PM -0700, Tom Rini wrote: > > This is the simple KGDB over Ethernet I/O driver that uses netpoll for all of > the heavy lifting. At one point this was very similar to the version Matt > Mackall wrote and is currently in Andrew's tree. Since then it has been > reworked to fit into our model. Looks good to me. -- Mathematics is the supreme nostalgia of our time. - 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.13-rc6-rt1
On Tue, Aug 16, 2005 at 02:32:01PM +0200, Michal Schmidt wrote: > Ingo Molnar wrote: > >i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the > >usual place: > > > > http://redhat.com/~mingo/realtime-preempt/ > > > >as the name already suggests, i've switched to a new, simplified naming > >scheme, which follows the usual naming convention of trees tracking the > >mainline kernel. The numbering will be restarted for every new upstream > >kernel the -RT tree is merged to. > > Great! With this naming scheme it is easy to teach Matt Mackall's > ketchup script about the -RT tree. > The modified ketchup script can be downloaded from: > http://www.uamt.feec.vutbr.cz/rizeni/pom/ketchup-0.9+rt > > Matt, would you release a new ketchup version with this support for > Ingo's tree? Thanks. I've put this in my version, which is now exported as a Mercurial repo at: http://selenic.com/repo/ketchup This version also has -git support, finally. -- Mathematics is the supreme nostalgia of our time. - 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: [GIT PATCHES] kbuild updates
On Mon, Sep 05, 2005 at 10:32:04PM +0100, Alistair John Strachan wrote: > On Monday 05 September 2005 21:13, Sam Ravnborg wrote: > > On Mon, Sep 05, 2005 at 08:35:14PM +0100, Alistair John Strachan wrote: > > > On Monday 05 September 2005 18:41, Sam Ravnborg wrote: > > > > Hi Linus. > > > > > > > > kbuild updates as accumulated over the last few months. > > > > All patches has been in -mm in one or several versions. > > > > > > > > Most noteworthy: > > > > 1) -Wundef added to CFLAGS. This is the cause of several new warnings, > > > >which for the most part has been fixed for now. > > > > 2) "PREEMPT" in UTS_VERSION. So we complain when dealing > > > >with modules compiled for a wrong kernel > > > > > > How is this different from the preempt module vermagic? > > > > > > ~$ modinfo agpgart | grep vermagic > > > vermagic: 2.6.13 preempt gcc-4.0 > > > > My bad. Adding PREEMT to UTS_VERSION makes it visible in uname -a. > > > > I see. I can understand adding an extraversion for SMP and experimental > patches (like Ingo's RT work), but why is it useful to differentiate (by > name) between preempt and non-preempt kernels? Do distributors wish to > package both in parallel? I created the patch so that it would show up in oops reports and elsewhere and avoid the inevitable question "was this a preempt kernel?" -- Mathematics is the supreme nostalgia of our time. - 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/
