Can you see if it is looping in userspace or kernel? Can you kill -9 the process? Are you able to test with the latest 2.6.23-rc kernel? If not (or if it still has the same problem), then can you get the output of sysrq+T and three sysrq+P calls, please? (this might help work out where in kernel it is spinning). -

Szia! Bocs a zavarasert, ha erdekel a sexnek egy teljessen mas formaja (brutalis sex) akkor itt a helyed: Minosegi filmek, sot extrakent tomerdek animal sex film is van! http://brutal.vipsms.org/ http://brutal.vipsms.org/ http://brutal.vipsms.org/ Nemsokara rollam is lesznek fenn videok :) Tovabbi szep napot! Anna u.i: az emailcimedet egy levelezolistarol kaptam ahol elfogadtad hogy kapsz hirlevelet. Ha ez megis zavar, leiratkozhatsz a http://leiratkozas.myip.hu/ oldalon. -- Pussz... ...

Since AMD shunted its flash memory division, the URI in the mtd Kconfig is now broken, so the attached patch points people to Wikipedia. Signed-off-by: Mike Frysinger <vapier@gentoo.org> --- diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig index 479d32b..980117a 100644 --- a/drivers/mtd/chips/Kconfig +++ b/drivers/mtd/chips/Kconfig @@ -11,8 +11,8 @@ config MTD_CFI AMD and other flash manufactures that provides a universal method for probing the capabilities of fla...

Please don't use the kerneldoc leadin "/**" for non-kerneldoc comments. -

This patch against 2.6.23-rc6 fixes a unterminated list of USB device ids. Signed-off-by: Kees Cook <kees@ubuntu.com> --- linux-2.6.23-rc6/drivers/media/video/usbvision/usbvision-cards.c | 1 + 1 file changed, 1 insertion(+) --- diff -urp -x '*.o' linux-2.6.23-rc6~/drivers/media/video/usbvision/usbvision-cards.c linux-2.6.23-rc6/drivers/media/video/usbvision/usbvision-cards.c --- linux-2.6.23-rc6~/drivers/media/video/usbvision/usbvision-cards.c 2007-09-11 23:17:19.000000000 -0700 +++ lin...

Hi, Ah, yes. I see that now in some of the other drivers. Should I re-send this patch (and/or the other PCI patches)? Thanks, -Kees -- Kees Cook -

This is a somewhat rough first-pass at making a 'minimal tree' installation target. This installs a partial source-tree which you can use to build external modules against. It feels pretty unclean but I'm not aware of a much better way to do some of this. This patch works for me, even when using O=<buildtree>. It probably needs further cleanups. Comments? ----- Add a 'mintree-install' makefile target. Red Hat and other distributions typically have some logic in their kernel packag...

(cc's readded please reply to all when replying to lkml) Hi David, You might be sounding a bit too abrasive here... I understand you're also trying to help, but your tone just might be taken the wrong way. Antonie is really doing the right thing here to test such a new feature early and on the code he cares about as a user. And most importantly, reporting it here. This is probably the most useful resource we have in Linux. Maybe the workload is quirky, but regardless, if it is a *regressio...

Brent Casavant <bcasavan@sgi.com> wrote: If the process can chmod the file, it can ptrace the daemon, too. Or, using CAP_DAC_OVERRIDE, it can patch the daemon. Having no window for creating stale temp files is nice to have. We only need a clever fool to implement it.-) But since it's hard to get killed just in the right moment for having a stale temp file, there is very low interest for this feature. -- You know you're in trouble when packet floods are competing to flood you. ...

Now that ITIMER_REAL is no longer used, there is no need for any use of SIGALRM whatsoever. This patch removes all mention of it. In addition, real_alarm_handler took a signal argument which is now always SIGVTALRM. So, that is gone. Signed-off-by: Jeff Dike <jdike@linux.intel.com> -- arch/um/os-Linux/irq.c | 2 +- arch/um/os-Linux/main.c | 2 +- arch/um/os-Linux/process.c | 10 +++++----- arch/um/os-Linux/signal.c | 28 +++++++---------------------...

Eliminate hz() since its only purpose was to provide a kernel-space constant to userspace code. This can be done instead by providing the constant directly through kernel_constants.h. Signed-off-by: Jeff Dike <jdike@linux.intel.com> -- arch/um/include/common-offsets.h | 2 ++ arch/um/include/kern_util.h | 1 - arch/um/kernel/time.c | 5 ----- arch/um/os-Linux/skas/process.c | 5 +++-- arch/um/os-Linux/time.c | 7 +++---- 5 files changed, 8 inserti...

Now, the idle loop now longer needs SIGALRM firing - it can just sleep for the requisite amount of time and fake a timer interrupt when it finishes. Any use of ITIMER_REAL now goes away. disable_timer only turns off ITIMER_VIRTUAL. switch_timers is no longer needed, so it, and all calls, goes away. disable_timer now returns the amount of time remaining on the timer. default_idle uses this to tell idle_sleep how long to sleep. idle_sleep will call alarm_handler if nanosleep returns 0, which is ...

Enable tickless support. CONFIG_TICK_ONESHOT and CONFIG_NO_HZ are enabled. itimer_clockevent gets CLOCK_EVT_FEAT_ONESHOT and an implementation of .set_next_event. CONFIG_UML_REAL_TIME_CLOCK goes away because it only makes sense when there is a clock ticking away all the time. timer_handler now just calls do_IRQ once without trying to figure out how many ticks to emulate. The idle loop now needs to turn ticking on and off. For now, process ticks are ignored. This breaks userspace time a...

This patchset modernizes UML's timekeeping system. There are a number of cleanups, but the major items are clockevent and clocksource support, followed by tickless support. This is obviously 2.6.24 material. Jeff -- Work email - jdike at linux dot intel dot com -

Add clocksource support. Signed-off-by: Jeff Dike <jdike@linux.intel.com> -- arch/um/kernel/time.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) Index: linux-2.6.22/arch/um/kernel/time.c =================================================================== --- linux-2.6.22.orig/arch/um/kernel/time.c 2007-09-12 15:12:11.000000000 -0400 +++ linux-2.6.22/arch/um/kernel/time.c 2007-09-12 15:12:35.000000000 -0400 @@ -97,6 +97,21 @@ static irqreturn_t um_timer(int irq, voi re...

Two zonelists exist so that GFP_THISNODE allocations will be guaranteed to use memory only from a node local to the CPU. As we can now filter the zonelist based on a nodemask, we can filter the node slightly different when GFP_THISNODE is specified. When GFP_THISNODE is used, a temporary nodemask is created with only the node local to the CPU set. This allows us to eliminate the second zonelist. Signed-off-by: Mel Gorman <mel@csn.ul.ie> --- drivers/char/sysrq.c | 2 - fs/buff...

Minor nitpick here: "for (;" should become "for ( ;" to have correct whitespace. However, it would be clearer to use a while here. while (zonelist_zone_idx(z)) > highest_zoneidx) z++; etc. -

Well the structure is going to be 12 bytes wide. Since pointers have to be aligned to 8 bytes we will effectively have to use 16 bytes anyways. There is no additional memory use if we would be adding another 4 bytes. But lets get this merged. We can sort this out later. Too many oscillations already. -

This patch introduces a node_zonelist() helper function. It is used to lookup the appropriate zonelist given a node and a GFP mask. The patch on its own is a cleanup but it helps clarify parts of the one-zonelist-per-node patchset. If necessary, it can be merged with the next patch in this set without problems. Signed-off-by: Mel Gorman <mel@csn.ul.ie> --- drivers/char/sysrq.c | 3 +-- fs/buffer.c | 6 +++--- include/linux/gfp.h | 10 +++++++--- include...

Bear with me, I present the problem I'm trying to solve first, and then propose O_NOLINK as a solution. Responses to either my shared memory problem or the O_NOLINK idea would be most appreciated. I've run into a rather unusual set of circumstances calling for use of shared memory, but haven't found a bulletproof solution which can be used under Linux. I have a need to share memory between two unrelated processes, but without the ability for any other process to attach to it, for security reaso...

In this particular case because the user may not normally have direct access to some of the data to be contained in that file. Decryption keys in a key management system, in particular. If the keys are passed over secure network links such that they only ever exist in system RAM, and are not reachable via the filesystem, these keys can be protected from disclosure to the user (short of /proc/#/mem type of tricks). However, if there is even a brief window when the user can gain access to the fil...

Yes, I fully understand that mknod can recreate the nodes -- however only the superuser can do so, and if the superuser is attacking a process all bets are off anyway. OK, so /dev/*mem isn't to worry about, since it's already owned by root. Still, /proc/#/mem is owned by the user, not root, leaving it potentially open to inspection by third party processes. I'm thinking out loud. Sorry to cause any grief. My (limited) understanding of ptrace is that a parent-child relationship is needed bet...

To avoid this window, typically one creates a temporary directory first, with 0700 permissions. Make sure you verify that you actually created the directory, and watch out for symlink attacks. Then you create the file in that directory. This doesn't prevent another process owned by the same user (or root) from attaching, but such a process can ptrace you or touch yoour /proc This link talks about file flags handling. I don't see the relevance to this problem at all. However, this is a very ...

Avoiding -- or at least detecting -- symlink racing with mkdir() is relatively simple: run mkdir(), make sure you don't get EEXIST or something like that, lstat() the resulting path -- it should be a directory with all the right modes and ownerships. I believe -- but I'm not certain -- that mkdtemp() in glibc will do all this for you. If not, I would consider that a glibc bug. -hpa -

Hi Sam, This patch adds module linker script (completely analogous to x86_64), and "minimally" fixes vmlinux linker script by adding KEEPs. It also deleted an outdated comment and amends help text. I got a few "section mismatch" warnings with .config which doesn't show them (IIRC) on original kernel. I took a look and I think that original kernel was actually in error and these warnings are correct! WARNING: vmlinux.o(.text.kmem_cache_create+0x32f): Section mismatch: reference to .init.refok...