Re: [PATCH] Identify which executable object the userspace addressbelongs to. Store thread group leader id, and use it to lookup theaddress in the process's map. We could have looked up the addresson thread's map, but the thread might not exist by the time we arecalled. The process might not exist either, but if you are readingtrace_pipe, that is unlikely.

From: Ingo Molnar
Date: Thu Nov 06 2008 - 04:56:16 EST

Next message: Ingo Molnar: "Re: [PATCH 1/2] vmap: cope with vm_unmap_aliases beforevmalloc_init()"
Previous message: Avi Kivity: "Re: [PATCH 00/14] x86: disable virt on kdump and emergency_restart"
In reply to: Török Edwin: "Re: [PATCH] Identify which executable object the userspace addressbelongs to. Store thread group leader id, and use it to lookup the addressin the process's map. We could have looked up the address on thread's map,but the thread might not exist by the time we are called. The process mightnot exist either, but if you are reading trace_pipe, that is unlikely."
Next in thread: Christoph Hellwig: "Re: [PATCH] Identify which executable object the userspace addressbelongs to. Store thread group leader id, and use it to lookup theaddress in the process's map. We could have looked up the addresson thread's map, but the thread might not exist by the time we arecalled. The process might not exist either, but if you are readingtrace_pipe, that is unlikely."
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

* Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:

> On Mon, Nov 03, 2008 at 08:32:57AM +0100, Ingo Molnar wrote:
> > could you please help out with such a helper? This is really about
> > visualization, not to rely on it.
>
> Is this kindergarten? [...]

No, this is lkml where, if you decide to stand in the way of a patch,
you are supposed to back up your NAK's with a path out of that NAK.
Instead of forcing people into multiple email ping-pongs trying to
figure out what exactly the objections mean.

Look at the time flow of the mails:

| Nov 2 22:18:21 2008 # submission
| Nov 2 22:25:16 2008 # +7 minutes, NAK with no comment
|
| [ ~5 unnecessary mails ]
|
| Nov 4 20:09:13 20008 # +2 days, ACK

What was done was inefficent and unnecessary, it caused a hickup and
delay of 2 days in the workflow - at the point of the NAK it was
already known what the right solution is, it just was obscured behind
a moody reply. Such obstruction adds up and it simply does not scale
as a form of communication.

Nobody learned anything new compared to the case had the +7 minutes
reply included this information already.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/