http://permalink.gmane.org/gmane.linux.kernel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.kernel/741795 D'oh! Overlooking the obvious! Thanks Roland. Michael Kerrisk 2008-10-08T02:50:34 http://permalink.gmane.org/gmane.linux.kernel/741793 Hmm yes I did see that. It's not too similar, as it focuses on re-keying an existing element into the same hash table. ddds can't do that kind of thing (the underlying data structure isn't visible to the algorithm, so it can't exactly modify data structures in-place), although in another sense it is more general because the transfer function could transfer items into another hash table and re-key them as it goes (if it did that, it could probably use Josh's "atomic" re-keying algorithm too). But largely it does seem like they are orthogonal (if I'm reading rcuhashbash correctly). Nick Piggin 2008-10-08T02:48:13 http://permalink.gmane.org/gmane.linux.kernel/741791 Hi Lai, Hrm ? Have a good look at the macro __trace_mark() in include/linux/marker.h, you'll see that __mark_empty_function is referenced. Have you tested this against code with declared markers ? This second change is correct. marker_probe_cb is referenced by __trace_mark(), but not marker_probe_cb_noarg, which is only connected when non-empty format string is found by the registration function in marker.c. Same as comment above. This one is ok. So overall, if you could check why you have not hit any problem when removing __mark_empty_function, that would be great. The only reason I see is that you had no markers in your kernel test code. Mathieu Mathieu Desnoyers 2008-10-08T02:43:25 http://permalink.gmane.org/gmane.linux.kernel/741785 when the second, third... probe is registered, its format is not checked, this patch fix it. Signed-off-by: Lai Jiangshan <laijs< at >cn.fujitsu.com> --- diff --git a/kernel/marker.c b/kernel/marker.c index 4440a09..1196a6b 100644 --- a/kernel/marker.c +++ b/kernel/marker.c < at >< at > -651,11 +651,17 < at >< at > int marker_probe_register(const char *name, const char *format, entry = get_marker(name); if (!entry) { entry = add_marker(name, format); -if (IS_ERR(entry)) { +if (IS_ERR(entry)) ret = PTR_ERR(entry); -goto end; -} +} else if (format) { +if (!entry->format) +ret = marker_set_format(&entry, format); +else if (strcmp(entry->format, format)) +ret = -EPERM; } +if (ret) +goto end; + /* * If we detect that a call_rcu is pending for this marker, * make sure it's executed now. Lai Jiangshan 2008-10-08T02:23:36 http://permalink.gmane.org/gmane.linux.kernel/741784 __mark_empty_function() and marker_probe_cb_noarg() should not be seen by outer code. this patch remove them. Signed-off-by: Lai Jiangshan <laijs< at >cn.fujitsu.com> --- diff --git a/include/linux/marker.h b/include/linux/marker.h index 1290653..f4d4d28 100644 --- a/include/linux/marker.h +++ b/include/linux/marker.h < at >< at > -132,12 +132,8 < at >< at > static inline void __printf(1, 2) ___mark_check_format(const char *fmt, ...) ___mark_check_format(format, ## args);\ } while (0) -extern marker_probe_func __mark_empty_function; - extern void marker_probe_cb(const struct marker *mdata, void *call_private, ...); -extern void marker_probe_cb_noarg(const struct marker *mdata, -void *call_private, ...); /* * Connect a probe to a marker. diff --git a/kernel/marker.c b/kernel/marker.c index 7d1faec..4440a09 100644 --- a/kernel/marker.c +++ b/kernel/marker.c < at >< at > -81,11 +81,10 < at >< at > static struct hlist_head marker_table[MARKER_TABLE_SIZE]; * though the function pointer change and the marker enabling are two distinct Lai Jiangshan 2008-10-08T02:23:25 http://permalink.gmane.org/gmane.linux.kernel/741781 Greg I want to thank you for working with me and making time to do this even though you are not a fan of what I am doing and generally keeping this on a technical basis. I do appreciate it, even if I am frustrated right now, and feeling like the bar has been set impossibly hight. Eric Eric W. Biederman 2008-10-08T01:29:57 http://permalink.gmane.org/gmane.linux.kernel/741779 On Tue, 07 Oct 2008 17:49:49 +0200 Andrea Righi <righi.andrea< at >gmail.com> wrote: Hmm... I agree to "5"... like this ? == prvoides - vm.dirty_ratio (1/100) - vm.dirty_ratio_percentmille(1/100,000, pcm) and allow #echo 0.05 > vm/dirty_ratio #cat vm/dirty_ratio 0 #cat vm/dirty_ratio_percentmille 500 == Thanks, -Kame KAMEZAWA Hiroyuki 2008-10-08T01:16:42 http://permalink.gmane.org/gmane.linux.kernel/741778 Hi Philip, On Sat, Oct 13, 2007 at 12:12:53PM -0700, Philip Langdale wrote: It was a pleasure talking to you yesterday. As I promised, here is the revision of your patch that I would like to commit to the next branch and I would appreciate if you could give it a try. The changes from the version you sent to me include hiding all uglies in drivers/input and also adding compat handling for the force feedback effects. Sorry for sitting on it for so long. Dmitry Torokhov 2008-10-08T01:15:43 http://permalink.gmane.org/gmane.linux.kernel/741776 I just did not want to do that on the road. I do not see any difference with regard to timer wiring or hpet behavior (hpet is disabled in BIOS, hpet=force causes hang) with the latest (F.12) BIOS. Dmitry Torokhov 2008-10-08T01:07:53 http://permalink.gmane.org/gmane.linux.kernel/741775 So in next_tid which is essentially what we would be doing. I grab the rcu_lock. Check something to see if the task I have is still on the list, if it is then I know the next is valid until the end of the rcu grace period. Then I follow the next pointer, and grab the lock again. rcu is pain to get right but at least it is localized pain. I don't think we can make it work but I think we need to exhaust that avenue before saying that the VFS has to change. Eric Eric W. Biederman 2008-10-08T00:58:34 http://permalink.gmane.org/gmane.linux.kernel/741774 Hi Yanping, Correct. However, I haven't seen this behavior cause any trouble. Do you know any case? So, if nobody feel awful, I don't interest it so much ;) KOSAKI Motohiro 2008-10-08T00:59:13 http://permalink.gmane.org/gmane.linux.kernel/741773 Something got corrupted? Your patch contains a mailbox with another version of the patch. -Andi Andi Kleen 2008-10-08T00:54:16 http://permalink.gmane.org/gmane.linux.kernel/741770 Quick review, not very deep (as in just Linux interfaces not design) This description is not very helpful for someone who doesn't know what tboot is. There should be at least a short paragraph here describing what it is Better more. That should be in some include Having that much debug output by default is not nice. Passing pointers around as unsigned long is not nice. In general GFP_ATOMIC is nasty and should be avoided if possible. Instead of allocating something here you could just use the list_head in struct page Is there any reason you cannot use the generic pgalloc.h allocators? Is it only for tracking the pages? Why not track it using the page tables? Or insert it into the list (if you really need one, i'm not sure what the list is actually good for) based on the page tables after the fact. That would avoid the ifdefery and clean this function up greatly. Avoid magic numbers like this. Why not just use a C indirect function call? This could be much shorter with just an array lo Andi Kleen 2008-10-08T00:52:41 http://permalink.gmane.org/gmane.linux.kernel/741769 Possibly. Tejun and I looked at it a while ago and could not see any problems that you could trigger by having multiple superblocks share the same inodes but there might be some. I don't like that aspect of it any more than Al does, I just haven't found an alternative that works, nor have I seen a suggestion that is better. And my point is that compared to the other bugs Al found in sysfs my contribution is miniscule and minor, and pretty much fixed at this point. Do I have to rewrite all of sysfs to the point where Al can not find bugs in it before I can merge my changes? If that is the standard while it seems ridiculous I can work with it. I need something i can work with. As Serge said. The problem is very simply that with the network namespaces we create devices in different namespaces that have the same name. lo being the first one we hit. It wasn't my idea to export them to sysfs but it has happened. We need a way to put those devices in sysfs that doesn't break sysfs and is in some form Eric W. Biederman 2008-10-08T00:39:05 http://permalink.gmane.org/gmane.linux.kernel/741768 No, wait. Why would you want to do such a thing in the first place? ick. I agree with Tejun here, what's this whole network namespace stuff, what problems is it trying to solve and what are its goals? thanks, greg k-h Greg KH 2008-10-08T00:38:34 http://permalink.gmane.org/gmane.linux.kernel/741765 On Tue, 7 Oct 2008 17:01:03 -0700 Andrew Morton <akpm< at >linux-foundation.org> wrote: Sad.. just for information. I used... - 3 fixes to git-x86.patch. - 1 fix to patches/usb-usb-remove-warn-macro-from-usbh.patch - 1 fix to patches/autofs4-add-miscellaneous-device-for-ioctls-fix-fix-3.patch Maybe some are fixed. Merged one is here. == Index: mmotm-2.6.27-rc8+/arch/x86/kernel/process_64.c =================================================================== --- mmotm-2.6.27-rc8+.orig/arch/x86/kernel/process_64.c +++ mmotm-2.6.27-rc8+/arch/x86/kernel/process_64.c < at >< at > -86,31 +86,6 < at >< at > void exit_idle(void) __exit_idle(); } -#ifdef CONFIG_HOTPLUG_CPU -DECLARE_PER_CPU(int, cpu_state); - -#include <asm/nmi.h> -/* We halt the CPU with physical CPU hotplug */ -static inline void play_dead(void) -{ -idle_task_exit(); -c1e_remove_cpu(raw_smp_processor_id()); - -mb(); -/* Ack it */ -__get_cpu_var(cpu_state) = CPU_DEAD; - -local_irq_disable(); -/* mask all interrupts, flush any and all caches, and halt */ - KAMEZAWA Hiroyuki 2008-10-08T00:34:04 http://permalink.gmane.org/gmane.linux.kernel/741762 Yeah, the diffstat tells the story. Erk, good point. Suckage. OK, idea #2. Let's just always have a kstopmachine thread running on every online cpu. Is there a sane way to reuse the workqueue threads for this? Thanks, Rusty. Rusty Russell 2008-10-08T00:27:04 http://permalink.gmane.org/gmane.linux.kernel/741761 Hello, Eric W. Biederman wrote: Hmmm... I'm probably missing something (and being lazy) but how does it guarantee the validity of the next pointer after dropping the rcu lock? Yeah, if we can make sysfs behave like other distributed filesystems, it would be great. :-) Thanks. Tejun Heo 2008-10-08T00:20:35 http://permalink.gmane.org/gmane.linux.kernel/741759 I ran into a bit of flapping with my init.d acct lately, and in tracing why, I noticed that there seems to be absolutely no way that the kernel exposes to show that it's running any accounting. Could we expose acct_list in sysfs or procfs, as uid:0, gid:0, perms 0600? Robin H. Johnson 2008-10-07T23:53:31 http://permalink.gmane.org/gmane.linux.kernel/741757 Quoting Greg KH (greg< at >kroah.com): Because : So at least we'd have to do something to allow creation of 'duplicate' devices in different namespaces. It might be fine if we just ended up with /sys/devices/virtual/net/lo, if created in a child net namespace, be named /sys/devices/virtual/net/lo.childXYZ. Then userspace can mount -t tmpfs none /sys/class/net and ln -s /sys/devices/virtual/net/lo.childXYZ /sys/class/net/lo. -serge Serge E. Hallyn 2008-10-08T00:12:03 http://permalink.gmane.org/gmane.linux.kernel/741756 There is srcu and there is the trick of grabbing the reference count on the current sysfs_dirent over the filldir and dropping the rcu lock (which works for proc). To cut down on lock overhead from user space accesses that works. Well there are more cases than dnotify, there is the renaming of directories in sysfs, although rare that I think get awkward if we use revalidation. I'm still not certain how we can get the lock ordering so it doesn't cause us problems. I will look at revalidation and what the other distributed filesystems are doing and see if that might work. If it doesn't we need refactor the VFS locking. Eric Eric W. Biederman 2008-10-08T00:04:15 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel