twitter: linux.kernel - 25 new messages in 17 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* sched: cpuacct: Use bigger percpu counter batch values for stats counters -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bfd515678506951b?hl=en
* x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/fc4cba69013002ea?hl=en
* of/gpio: Add support for two-stage registration for the of_gpio_chips - 3
messages, 1 author
http://groups.google.com/group/linux.kernel/t/150c1d8d8e5ef0e4?hl=en
* HDA Intel Audio hang on boot - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a0ad5b25d979d11d?hl=en
* sysfs_ops show vector: size of buffer not required? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8aafe8a10e8404cc?hl=en
* starting emacs makes lockdep warning - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/b92a5fcdc20fcbff?hl=en
* : Networking - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/4455bf72dfef25ac?hl=en
* perf lock: New subcommand "perf lock", for analyzing lock statistics - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/d907e7c6d5011cd0?hl=en
* twl4030 threaded_irq support - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
* tracing: move static old_tracer to trace_iterator - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dba98385ce9b900d?hl=en
* markup_oops.pl: add options to improve cross-sompilation environments - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a94bf88dc8c7132f?hl=en
* Revert "perf record: Intercept all events" - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/017068de93596929?hl=en
* oprofile fixes for v2.6.33 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2915761a5b76e9c7?hl=en
* PCI host bridge windows ignored (works with pci=use_crs) - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/8dc02ff411331726?hl=en
* measureing kernel & application boottime's - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2727ea96aab221a5?hl=en
* OOM-Killer kills too much with 2.6.32.2 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3f7afc452c078f22?hl=en
* futex() on vdso makes process unkillable - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/771496d6192e598e?hl=en

==============================================================================
TOPIC: sched: cpuacct: Use bigger percpu counter batch values for stats
counters
http://groups.google.com/group/linux.kernel/t/bfd515678506951b?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 10:40 pm
From: Andrew Morton

On Tue, 26 Jan 2010 11:47:15 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> On Tuesday 26 January 2010 04:44 AM, Andrew Morton wrote:
> > On Mon, 18 Jan 2010 15:41:42 +1100
> > Anton Blanchard <anton@samba.org> wrote:
> >
> >> When CONFIG_VIRT_CPU_ACCOUNTING and CONFIG_CGROUP_CPUACCT are enabled we can
> >> call cpuacct_update_stats with values much larger than percpu_counter_batch.
> >> This means the call to percpu_counter_add will always add to the global count
> >> which is protected by a spinlock and we end up with a global spinlock in
> >> the scheduler.
> >
> > When one looks at the end result:
> >
> > : static void cpuacct_update_stats(struct task_struct *tsk,
> > : enum cpuacct_stat_index idx, cputime_t val)
> > : {
> > : struct cpuacct *ca;
> > : int batch;
> > :
> > : if (unlikely(!cpuacct_subsys.active))
> > : return;
> > :
> > : rcu_read_lock();
> > : ca = task_ca(tsk);
> > :
> > : batch = min_t(long, percpu_counter_batch * cputime_one_jiffy, INT_MAX);
> > : do {
> > : __percpu_counter_add(&ca->cpustat[idx], val, batch);
> > : ca = ca->parent;
> > : } while (ca);
> > : rcu_read_unlock();
> > : }
> >
> > the code (which used to be quite obvious) becomes pretty unobvious. In
> > fact it looks quite wrong.
> >
> > Shouldn't there be a comment there explaining wtf is going on?
>
> Andrew,
>
> I guess a lot of the changelog and comments are in the email history,

Not a very useful location for it!

> Why does it look quite wrong to you?

Because it computes the correct value and then if it's larger than
INT_MAX, it inexplicably assigns INT_MAX to it, giving a wrong result!

Does that code actually work, btw? percpu_counter_batch has type `int'
and cputime_one_jiffy has type `int' so their product has type `int'.
So by the time min_t performs its comparison, the upper 32 bits of the
product are already lost.

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

==============================================================================
TOPIC: x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll
http://groups.google.com/group/linux.kernel/t/fc4cba69013002ea?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 10:40 pm
From: Borislav Petkov

Hi,

On Mon, Jan 25, 2010 at 02:19:15PM +0100, Andi Kleen wrote:
> > Because this is one thing that has been bugging us for a long time. We
> > don't have a centralized smart utility with lots of small subcommands
> > like perf or git, if you like, which can dump you the whole or parts
>
> PC configuration is all in dmidecode, CPU/node information in lscpu
> these days (part of utils-linux)
>
> The dmidecode information could be perhaps presented nicer, but
> I don't think we need any fundamental new tools.

Uuh, dmidecode doesn't even start to look usable in my book because you
have to rely on BIOS vendors to fill out the information for you. Here
are some assorted excerpts from dmidecode on my machines:

1. Incomplete info:

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: System manufacturer
Product Name: System Product Name
Version: System Version
Serial Number: System Serial Number
UUID: 201EE116-055E-DD11-8B0E-002215FDB1C6
Wake-up Type: Power Switch
SKU Number: To Be Filled By O.E.M.
Family: To Be Filled By O.E.M.

2. Wrong(!) info:

Handle 0x0007, DMI type 7, 19 bytes
Cache Information
Socket Designation: L3-Cache
Configuration: Enabled, Not Socketed, Level 3
Operational Mode: Varies With Memory Address
Location: Internal
Installed Size: 6144 KB
Maximum Size: 6144 KB
Supported SRAM Types:
Pipeline Burst
Installed SRAM Type: Pipeline Burst
Speed: Unknown

why?

Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 4-way Set-associative

how is my L3 4-way set-associative and how do they come up with that???

[ by the way, it says the same on my old P4 box' L2 so this could mean
anything besides the actual cache assoc. ]

Here's what the dmidecode manpage says:

"...

BUGS
More often than not, information contained in the DMI tables is
inaccurate, incomplete or simply wrong.
...
"

so I guess I'm not the only one :)

In the end, even if the info were correct, it is still not nearly enough
for all the information you might need from a system. So you end up
pulling a dozen of different tools just to get the info you need. So
yes, I really do think we need a tool to get do the job done right and
on any system. And this tool should be distributed with the kernel
sources like perf is, so that you don't have to jump through hoops to
pull the stuff (Esp. if you have to build everything everytime like
Andreas does :)).

> > 1. We need to notify userspace, as you've said earlier, and not scan
> > the syslog all the time. And EDAC, although decoding the correctable
>
> mcelog never scanned the syslog all the time. This is just
> EDAC misdesign.

Oh yes, EDAC has the edac-utils too which access /sysfs files but even
so, it is suboptimal and we really need a single interface/output
channel/whatever you call a beast like that to reliably transfer human
readable hw error info to userspace and/or network. And this has to be
pushed from kernel space outwards as early as the gravity of the error
suggests, IMO.

> But yes syslog is exactly the wrong interface for these kinds of errors.

Agreed completely.

> > 2. Also another very good point you had is go into maintenance mode by
> > throttling or even suspend all uspace processes and start a restricted
> > maintenance shell after an MCE happens. This should be done based on the
>
> When you have a unrecoverable MCE this is not safe because you
> can't write anything to disk (and usually the system is unstable
> and will crash soon) because there are uncontained errors somewhere
> in the hardware. The most important thing to do in this situation
> is to *NOT* write anything to disk (and that is the reason
> why the hardware raised the unrecoverable MCE in the first place)
> Having a shell without being able to write to disk doesn't make sense.

Hmm, not necessarily. First of all, not all UC errors are absolutely
valid reasons to panic the machine. Imagine, for example, you encounter
(as unlikely as it might be) a multibit error during L1 data cache
scrubbing which hasn't been consumed yet. Now, technically, no data
corruption has taken place yet so you can easily start the shell on
another core which doesn't have that datum in its cache, decode the
error for the user to see what it was and even allow her/him to poweroff
the machine properly.

Or imagine you have a L2 TLB multimatch - also UC but you can still
invalidate the two entries, maybe kill the processes that have caused
those mappings and start the shell.

So no, not all UC errors have to absolutely cause data corruption and
you can still prepare for a clean exit by warning the user that her/his
data might be compromized and whether (s)he wants to write to disk or
poweroff the machine immediately SysRq-O style.

And even if an UC causes data corruption, panicking the system doesn't
mean that the error has been contained. Nothing can assure you that by
the time do_machine_check() has run the corrupted data hasn't left the
CPU core and landed in another core's cache (maybe even on a different
node) and then on disk through an outstanding write request. That's why
we syncflood the HT links on certain error types since an MCE is not
enough to stop that propagation.

> > 3. All the hw events like correctable ECCs should be thresholded so that
> > all errors exceeding a preset threshold (below that is normal operation
>
> Agreed. Corrected errors without thresholds are useless (that is one
> of the main reasons why syslog is a bad idea for them)
>
> See also my plumbers presentation on the topic:
>
> http://halobates.de/plumbers-error.pdf
>
> One key part is that for most interesting reactions to thresholds
> you need user space, kernel space is too limited.
>
> My current direction was implementing this in mcelog which
> maintains threshold counters and already does a couple of direct (user
> based) threshold reactions, like offlining cores and pages and reporting
> short user friendly error summaries when thresholds are exceeded.

Yep, sounds good.

> Longer term I hope to move to a more generic (user) error infrastructure
> that handles more kinds of errors. This needs some infrastructure
> work, but not too much.

Yep, I think this is something we should definitely talk about since our
error reporting right now needs a bunch of work to even start becoming
really usable.

> > The current decoding needs more loving too since now it says something
> > like the following:
>
> Yes, see the slide set above on thoughts how a good error looks like.
>
> The big problem with EDAC currently is that it neither gives
> the information actually needed (like mainboard labels), but gives
> a lot of irrelevant low level information.

Yes, I'm very well aware of that. I'm currently working on a solution.
It's just an idea now but I might be able to read DIMM configuration
on the SPD ROM on the DIMM along with their labels and position on the
motherboard in order to be able to pinpoint the correct DIMM... Stay
tuned...

> And since it's kernel
> based it cannot do most of the interesting reactions. And it doesn't
> have a usable interface to add user events.
>
> And yes having all that crap in syslog is completely useless, unless
> you're debugging code.

So basically, IMHO we need:

1. Resilient error reporting that reliably pushes decoded error info to
userspace and/or network. That one might be tricky to do but we'll get
there.

2. Error severity grading and acting upon each type accordingly. This
might need to be vendor-specific.

3. Proper error format suiting all types of errors.

4. Vendor-specific hooks where it is needed for in-kernel handling of
certain errors (L3 cache index disable, for example).

5. Error thresholding, representation, etc all done in userspace (maybe
even on a different machine).

6. Last but not least, and maybe this is wishful thinking, a good tool
to dump hwinfo from the kernel. We do a great job of detecting that info
already - we should do something with it, at least report it...

Let's see what the others think.

Thanks.

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

==============================================================================
TOPIC: of/gpio: Add support for two-stage registration for the of_gpio_chips
http://groups.google.com/group/linux.kernel/t/150c1d8d8e5ef0e4?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 25 2010 10:50 pm
From: David Brownell

On Monday 25 January 2010, Anton Vorontsov wrote:
> With this patch there are two ways to register OF GPIO controllers:
>
> 1. Allocating the of_gpio_chip structure and passing the
> &of_gc->gc pointer to the gpiochip_add. (Can use container_of
> to convert the gpio_chip to the of_gpio_chip.)
>
> 2. Allocating and registering the gpio_chip structure separately
> from the of_gpio_chip. (Since two allocations are separate,
> container_of won't work.)
>
> As time goes by we'll kill the first option.

Why have two options, instead of just the first/simpler one??

== 2 of 3 ==
Date: Mon, Jan 25 2010 10:50 pm
From: David Brownell

On Monday 25 January 2010, Anton Vorontsov wrote:
>
> +config GPIOLIB_NOTIFIER
> +       bool
> +       help
> +        This symbol is selected by subsystems that need to handle GPIO
> +        chips addition and removal. E.g., this is used for the
> +        OpenFirmware bindings.
> +

I'm no huge fan of notifiers, but I suppose they have their place.

However ... I don't see a lot of win to making this optional. Just
inline the little two blocking_notifier_call_chain() calls directly,
making this a *LOT* simpler.

- Dave

== 3 of 3 ==
Date: Mon, Jan 25 2010 10:50 pm
From: David Brownell

On Monday 25 January 2010, Anton Vorontsov wrote:
> With the new OF GPIO infrastructure it's much easier to handle I2C
> GPIO controllers, i.e. now drivers don't have to deal with the
> OF-specific bits.

Good, that's how it should have been done in the first place. :)

Of course, there's still the question of how to get driver-specific
configuration data into the driver...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: HDA Intel Audio hang on boot
http://groups.google.com/group/linux.kernel/t/a0ad5b25d979d11d?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 25 2010 10:50 pm
From: Takashi Iwai

At Tue, 26 Jan 2010 00:59:15 +0000,
Sid Boyce wrote:
>
> On 25/01/10 21:55, Takashi Iwai wrote:
> > At Mon, 25 Jan 2010 22:54:23 +0100,
> > I wrote:
> >>
> >> At Mon, 25 Jan 2010 22:39:02 +0100,
> >> Rafael J. Wysocki wrote:
> >>>
> >>> On Monday 25 January 2010, Sid Boyce wrote:
> >>>> On 15/01/10 01:24, Sid Boyce wrote:
> >>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get
> >>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio
> >>>> is not disabled in the BIOS.
> >>>
> >>> I guess we should let Takashi know.
> >>
> >> Thanks.
> >>
> >>>>> tindog:~ # uname -r
> >>>>> 2.6.33-rc4-smp
> >>>>> On 2.6.32-git1 which boots, hwinfo shows:-
> >>>>> oss.card_id = 'HDA NVidia'
> >>>>> oss.card_id = 'HDA NVidia'
> >>>>> oss.card_id = 'HDA NVidia'
> >>>>> alsa.card_id = 'HDA NVidia'
> >>>>> alsa.card_id = 'HDA NVidia'
> >>>>> alsa.card_id = 'HDA NVidia'
> >>>>> alsa.card_id = 'HDA NVidia'
> >>>>> info.product = 'HDA NVidia ALSA hardware specific Device'
> >>>>> alsa.card_id = 'HDA NVidia'
> >>>>> info.product = 'HDA NVidia ALSA Control Device'
> >>>>> alsa.card_id = 'HDA NVidia'
> >>>>> info.product = 'HDA NVidia Sound Card'
> >>>>> sound.card_id = 'HDA NVidia'
> >>>>> info.linux.driver = 'HDA Intel'
> >>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel
> >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> >>>>> HDA Intel: module = snd_hda_intel
> >>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel"
> >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> >>>>> HDA Intel: module = snd_hda_intel
> >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> >>>>> HDA Intel: module = snd_hda_intel
> >>>>> E: DRIVER=HDA Intel
> >>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level,
> >>>>> low) -> IRQ 22
> >>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64
> >>>>> Driver: "HDA Intel"
> >>
> >> What I'd try first is to pass enable_msi=0 option.
> >
> > Just to be sure -- it's an option for snd-hda-intel module.
> >
> >
> > Takashi
> >
>
> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command
> line, still locks up as before.

OK, are you sure that the lock-up happens at snd-hda-intel module?
How about blacklist it once?

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

== 2 of 2 ==
Date: Mon, Jan 25 2010 11:00 pm
From: Takashi Iwai

At Tue, 26 Jan 2010 07:40:03 +0100,
I wrote:
>
> At Tue, 26 Jan 2010 00:59:15 +0000,
> Sid Boyce wrote:
> >
> > On 25/01/10 21:55, Takashi Iwai wrote:
> > > At Mon, 25 Jan 2010 22:54:23 +0100,
> > > I wrote:
> > >>
> > >> At Mon, 25 Jan 2010 22:39:02 +0100,
> > >> Rafael J. Wysocki wrote:
> > >>>
> > >>> On Monday 25 January 2010, Sid Boyce wrote:
> > >>>> On 15/01/10 01:24, Sid Boyce wrote:
> > >>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get
> > >>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio
> > >>>> is not disabled in the BIOS.
> > >>>
> > >>> I guess we should let Takashi know.
> > >>
> > >> Thanks.
> > >>
> > >>>>> tindog:~ # uname -r
> > >>>>> 2.6.33-rc4-smp
> > >>>>> On 2.6.32-git1 which boots, hwinfo shows:-
> > >>>>> oss.card_id = 'HDA NVidia'
> > >>>>> oss.card_id = 'HDA NVidia'
> > >>>>> oss.card_id = 'HDA NVidia'
> > >>>>> alsa.card_id = 'HDA NVidia'
> > >>>>> alsa.card_id = 'HDA NVidia'
> > >>>>> alsa.card_id = 'HDA NVidia'
> > >>>>> alsa.card_id = 'HDA NVidia'
> > >>>>> info.product = 'HDA NVidia ALSA hardware specific Device'
> > >>>>> alsa.card_id = 'HDA NVidia'
> > >>>>> info.product = 'HDA NVidia ALSA Control Device'
> > >>>>> alsa.card_id = 'HDA NVidia'
> > >>>>> info.product = 'HDA NVidia Sound Card'
> > >>>>> sound.card_id = 'HDA NVidia'
> > >>>>> info.linux.driver = 'HDA Intel'
> > >>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel
> > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> > >>>>> HDA Intel: module = snd_hda_intel
> > >>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel"
> > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> > >>>>> HDA Intel: module = snd_hda_intel
> > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> > >>>>> HDA Intel: module = snd_hda_intel
> > >>>>> E: DRIVER=HDA Intel
> > >>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level,
> > >>>>> low) -> IRQ 22
> > >>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64
> > >>>>> Driver: "HDA Intel"
> > >>
> > >> What I'd try first is to pass enable_msi=0 option.
> > >
> > > Just to be sure -- it's an option for snd-hda-intel module.
> > >
> > >
> > > Takashi
> > >
> >
> > I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command
> > line,

Oh, I overlooked this text. Of course, this can't work :)

"modprobe..." isn't for the kernel command line but for modprobe
configs, usually specified in /etc/modprobe.d/* file.

And... is this report for 2.6.32 or for 2.6.33?
If it's with 2.6.32, enable_msi=1 may help instead.

==============================================================================
TOPIC: sysfs_ops show vector: size of buffer not required?
http://groups.google.com/group/linux.kernel/t/8aafe8a10e8404cc?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 10:50 pm
From: Himanshu Chauhan

On Mon, Jan 25, 2010 at 08:36:46PM -0800, Greg KH wrote:
> On Sun, Jan 24, 2010 at 01:11:18PM +0530, Himanshu Chauhan wrote:
> > Hi All,
> >
> > The sysfs_ops's show vector doesn't have a size of the
> > buffer given to the vector, while store on the other hand
> > has. What is the rationale behind it?
>
> If you need to check the size, you are doing something wrong.
>
> Seriously, that is the reason. A sysfs file should be a single value,
> which will never overflow the buffer.
>
I was talking in context of usb/ip's show_status. It writes a lot of data
into this buffer. Which seems to over flow the buffer. But anyways, I
will check if it can be reduced or at least be splitted into differnt
device attributes.

BTW, Greg, Did you take a look at other patches I had sent? Are are worth or
I need rework?

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

==============================================================================
TOPIC: starting emacs makes lockdep warning
http://groups.google.com/group/linux.kernel/t/b92a5fcdc20fcbff?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 25 2010 11:00 pm
From: Al Viro

On Tue, Jan 26, 2010 at 02:24:30PM +0800, Am??rico Wang wrote:
> On Tue, Jan 26, 2010 at 2:07 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Tue, Jan 26, 2010 at 02:01:12PM +0800, Am??rico Wang wrote:
> >
> >> I agree, it seems that patch is useless, since we already
> >> do lock_kernel() before calling __f_setown()...
> >
> > What's to prevent pid from being freed under us? ??BKL won't...
> >
>
> Hmm, I don't fully understand the race here. If it is used to protect
> 'pid' which we get from 'tty->pgrp' or 'current', in the former case,
> it is protected by 'tty->ctrl_lock', in the later case, it doesn't need
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Without that patch it isn't.

> the lock. So it's not necessary to protect 'pid' by 'tty->crtl_lock'.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Mon, Jan 25 2010 11:50 pm
From: KOSAKI Motohiro

> On Tue, Jan 26, 2010 at 02:01:12PM +0800, Am??rico Wang wrote:
>
> > I agree, it seems that patch is useless, since we already
> > do lock_kernel() before calling __f_setown()...
>
> What's to prevent pid from being freed under us? BKL won't...

I don't understand this issue at all. so, this is stupid dumb question.
Why can't we write following code?

enum pid_type type;
struct pid *pid;
if (!waitqueue_active(&tty->read_wait))
tty->minimum_to_wake = 1;
spin_lock_irqsave(&tty->ctrl_lock, flags);
if (tty->pgrp) {
pid = tty->pgrp;
type = PIDTYPE_PGID;
} else {
pid = task_pid(current);
type = PIDTYPE_PID;
}
get_pid(pid) // insert here
spin_unlock_irqrestore(&tty->ctrl_lock, flags);
retval = __f_setown(filp, pid, type, 0);
put_pid(pid) // insert here

==============================================================================
TOPIC: : Networking
http://groups.google.com/group/linux.kernel/t/4455bf72dfef25ac?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 25 2010 11:00 pm
From: Jarek Poplawski

On Tue, Jan 26, 2010 at 06:33:26AM +0000, Jarek Poplawski wrote:
> David, I hope I miss something, but there seem to be older things too:
> ...
> > Jarek Poplawski (1):
> > ax25: netrom: rose: Fix timer oopses

Hmm... Probably OK! I'm glad I missed it only waited longer.

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

== 2 of 3 ==
Date: Mon, Jan 25 2010 11:20 pm
From: David Miller

From: Jarek Poplawski <jarkao2@gmail.com>
Date: Tue, 26 Jan 2010 06:33:26 +0000

> On 26-01-2010 01:56, David Miller wrote:
>> are available in the git repository at:
>>
>> master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
>
> David, I hope I miss something, but there seem to be older things too:
> ...
>> Jarek Poplawski (1):
>> ax25: netrom: rose: Fix timer oopses

That was commited on January 16th.

commit d00c362f1b0ff54161e0a42b4554ac621a9ef92d
Author: Jarek Poplawski <jarkao2@gmail.com>
Date: Sat Jan 16 01:04:04 2010 -0800

ax25: netrom: rose: Fix timer oopses

Wrong ax25_cb refcounting in ax25_send_frame() and by its callers can
cause timer oopses (first reported with 2.6.29.6 kernel).

Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14905

Reported-by: Bernard Pidoux <bpidoux@free.fr>
Tested-by: Bernard Pidoux <bpidoux@free.fr>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

And I haven't sent a pull request to Linus since around
January 13th
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 3 ==
Date: Mon, Jan 25 2010 11:40 pm
From: Jarek Poplawski

On Mon, Jan 25, 2010 at 11:17:35PM -0800, David Miller wrote:
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Tue, 26 Jan 2010 06:33:26 +0000
>
> > On 26-01-2010 01:56, David Miller wrote:
> >> are available in the git repository at:
> >>
> >> master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
> >
> > David, I hope I miss something, but there seem to be older things too:
> > ...
> >> Jarek Poplawski (1):
> >> ax25: netrom: rose: Fix timer oopses
>
> That was commited on January 16th.
>
> commit d00c362f1b0ff54161e0a42b4554ac621a9ef92d
> Author: Jarek Poplawski <jarkao2@gmail.com>
> Date: Sat Jan 16 01:04:04 2010 -0800
...
> And I haven't sent a pull request to Linus since around
> January 13th

Right! (I was mislead a bit by the numbered list at the beginning.;-)

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

==============================================================================
TOPIC: perf lock: New subcommand "perf lock", for analyzing lock statistics
http://groups.google.com/group/linux.kernel/t/d907e7c6d5011cd0?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 11:10 pm
From: Hitoshi Mitake

On Mon, Jan 25, 2010 at 23:48, Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, 2010-01-25 at 23:15 +0900, Hitoshi Mitake wrote:
>>
>> As Peter told, this patch series depends on lockdep.
>> But, checking dependency and tracing lock events are
>> essentially different things. So I think dividing these is possible.
>
> Still you need quite a lot of instrumentation at the actual lock sites,
> not something you'd want to have on your production machine.
>
>> But, perf depends on debugfs.
>> I don't know about production box well,
>> does your production box turns on debugfs?
>> It seems that debugfs is not a thing for production box...
>
> debugfs isn't a problem to have.

I didn't know that, thanks Peter and Greg!

>
>> And I'm interesting in in-kernel histogram of locks.
>> Is there requirement of it?
>> I have some ideas (not done yet, completely).
>
> No real concrete ideas yet.. One possibility is to add a range,
> bucket_size tuple to perf_event_attr and store the histrogram in the
> mmap() area instead of samples.
>
> One difficulty is how to specify what to make that histogram over.
>
> Anyway, its all open still..
>
>
>

I think my previous patch will helpful for this purpose,
http://lkml.org/lkml/2009/12/13/16
# This patch is too dangerous and too incomplete, please don't use!

I think distributing numerical IDs for lock instances makes things easily.
Distributing IDs means that kernel can know where the lock instances are.
Updating information of ID should be triggered by:

1) booting
Lock defined by DEFINE_SPINLOCK(), DEFINE_RWLOCK(), etc can be
corrected into specific section and initialized.
Like the way of event_trace_init() in kernel/trace/trace_events.c

2) loading/unloading modules
Lock defined by DEFINE_SPINLOCK(), DEFINE_RWLOCK(), etc can be in .ko files.
So hooking module loading or unloading will be required.

3) calling spin_lock_init(), rwlock_init(), etc...

It seems that difficulty of drawing histogram came from the running kernel's
lack of knowledge about where the lock instances are, isn't it?

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

==============================================================================
TOPIC: twl4030 threaded_irq support
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 25 2010 11:20 pm
From: David Brownell

On Monday 14 December 2009, Felipe Balbi wrote:
> move twl4030 children to threaded irq.
>
> Felipe Balbi (4):
> input: keyboard: twl4030: move to request_threaded_irq
> input: misc: twl4030: move to request_threaded_irq
> rtc: twl4030: move to request_threaded_irq
> usb: otg: twl4030: move to request_threaded_irq

But nothing in drivers/mfd ... the entry to the whole stack?

Did the threaded IRQ stuff ever get set up so that the top
level IRQ thread didn't have to hand off to another thread
each time? (That's how the current stuff works. One thread
calling out to each handler.)

If so, I'd like to see that be used here, rather than needlessly
spend all those pages on mostly-unused stacks.

>
> drivers/input/keyboard/twl4030_keypad.c | 11 ++---------
> drivers/input/misc/twl4030-pwrbutton.c | 12 +-----------
> drivers/rtc/rtc-twl4030.c | 10 +---------
> drivers/usb/otg/twl4030-usb.c | 10 +---------
> 4 files changed, 5 insertions(+), 38 deletions(-)
>
>

== 2 of 2 ==
Date: Mon, Jan 25 2010 11:50 pm
From: David Brownell

On Monday 25 January 2010, David Brownell wrote:
> Did the threaded IRQ stuff ever get set up so that the top
> level IRQ thread didn't have to hand off to another thread
> each time? (That's how the current stuff works. One thread
> calling out to each handler.)

Yes: set_irq_nested_thread(). Looks like the toplevel IRQ
demux (in drivers/mfd/twl*irq*c) should use that, along with
the ONESHOT flag and (eventually) bus_lock stuff.

All the key parts that were missing a few years ago now seem
to be present. But, not yet in use here. :)

- Dave

==============================================================================
TOPIC: tracing: move static old_tracer to trace_iterator
http://groups.google.com/group/linux.kernel/t/dba98385ce9b900d?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 11:30 pm
From: Lai Jiangshan

static old_tracer is global for all processes.

So there is a potential bug when:
current_trace and static old_tracer are changed by other processes,
current_trace and static old_tracer are match with each other.
but *iter->trace and *current_trace are not match.

This patch move old_tracer to trace_iterator, and make it not global.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 3ca9485..925897e 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -47,6 +47,7 @@ struct trace_entry {
*/
struct trace_iterator {
struct trace_array *tr;
+ struct tracer *old_tracer;
struct tracer *trace;
void *private;
int cpu_file;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 5314c90..bbb2229 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1667,7 +1667,6 @@ static void tracing_iter_reset(struct trace_iterator *iter, int cpu)
static void *s_start(struct seq_file *m, loff_t *pos)
{
struct trace_iterator *iter = m->private;
- static struct tracer *old_tracer;
int cpu_file = iter->cpu_file;
void *p = NULL;
loff_t l = 0;
@@ -1675,8 +1674,8 @@ static void *s_start(struct seq_file *m, loff_t *pos)

/* copy the tracer to avoid using a global lock all around */
mutex_lock(&trace_types_lock);
- if (unlikely(old_tracer != current_trace && current_trace)) {
- old_tracer = current_trace;
+ if (unlikely(iter->old_tracer != current_trace && current_trace)) {
+ iter->old_tracer = current_trace;
*iter->trace = *current_trace;
}
mutex_unlock(&trace_types_lock);
@@ -3080,7 +3079,6 @@ tracing_read_pipe(struct file *filp, char __user *ubuf,
size_t cnt, loff_t *ppos)
{
struct trace_iterator *iter = filp->private_data;
- static struct tracer *old_tracer;
ssize_t sret;

/* return any leftover data */
@@ -3092,8 +3090,8 @@ tracing_read_pipe(struct file *filp, char __user *ubuf,

/* copy the tracer to avoid using a global lock all around */
mutex_lock(&trace_types_lock);
- if (unlikely(old_tracer != current_trace && current_trace)) {
- old_tracer = current_trace;
+ if (unlikely(iter->old_tracer != current_trace && current_trace)) {
+ iter->old_tracer = current_trace;
*iter->trace = *current_trace;
}
mutex_unlock(&trace_types_lock);
@@ -3242,15 +3240,14 @@ static ssize_t tracing_splice_read_pipe(struct file *filp,
.ops = &tracing_pipe_buf_ops,
.spd_release = tracing_spd_release_pipe,
};
- static struct tracer *old_tracer;
ssize_t ret;
size_t rem;
unsigned int i;

/* copy the tracer to avoid using a global lock all around */
mutex_lock(&trace_types_lock);
- if (unlikely(old_tracer != current_trace && current_trace)) {
- old_tracer = current_trace;
+ if (unlikely(iter->old_tracer != current_trace && current_trace)) {
+ iter->old_tracer = current_trace;
*iter->trace = *current_trace;
}
mutex_unlock(&trace_types_lock);

==============================================================================
TOPIC: markup_oops.pl: add options to improve cross-sompilation environments
http://groups.google.com/group/linux.kernel/t/a94bf88dc8c7132f?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 25 2010 11:30 pm
From: Hui Zhu

Américo Wang:
> On Tue, Jan 26, 2010 at 11:11 AM, Hui Zhu <hui.zhu@windriver.com> wrote:
>> Sorry guys, the prev mail still have some format trouble. I send a new mail
>> for it.
>> +}
>> +
>> +if ($vmlinux_name ne "") {
>> + $vmlinux_name = $ARGV[$#ARGV];
>> +}
>
> Why not using the Perl module 'Getopt' to do this?
>
Hi Américo,

Thanks for remind me about it. The following patch use Getopt.

The markup_oops.pl have 3 troubles to support cross-compiler environment:
1. It use objdump directly.
2. It use modinfo to get the message of module.
3. It use hex function that cannot support 64-bit number in 32-bit arch.

This patch add 3 options to markup_oops.pl:
1. -c CROSS_COMPILE Specify the prefix used for toolchain.
2. -m MODULE_DIRNAME Specify the module directory name.
3. Change hex function to Math::BigInt->from_hex.

After this patch, parse the x8664 oops in x86, we can:
cat amd64m | perl ~/kernel/tmp/m.pl -c /home/teawater/kernel/bin/x8664- -m ./e.ko vmlinux

Thanks,
Hui

Signed-off-by: Hui Zhu <teawater@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: ozan@pardus.org.tr
Cc: Matthew Wilcox <willy@linux.intel.com>

---
scripts/markup_oops.pl | 45 +++++++++++++++++++++++++++++++++++----------
1 file changed, 35 insertions(+), 10 deletions(-)

--- a/scripts/markup_oops.pl
+++ b/scripts/markup_oops.pl
@@ -2,6 +2,7 @@

use File::Basename;
use Math::BigInt;
+use Getopt::Long;

# Copyright 2008, Intel Corporation
#
@@ -15,7 +16,17 @@ use Math::BigInt;
# Arjan van de Ven <arjan@linux.intel.com>

-my $vmlinux_name = $ARGV[0];
+my $cross_compile = "";
+my $vmlinux_name = "";
+my $modulefile = "";
+
+# Get options
+Getopt::Long::GetOptions(
+ 'cross_compile|c=s' => \$cross_compile,
+ 'modulefile|m=s' => \$modulefile,
+ 'help|h' => \&usage,
+);
+my $vmlinux_name = $ARGV[$#ARGV];
if (!defined($vmlinux_name)) {
my $kerver = `uname -r`;
chomp($kerver);
@@ -23,6 +34,7 @@ if (!defined($vmlinux_name)) {
print "No vmlinux specified, assuming $vmlinux_name\n";
}
my $filename = $vmlinux_name;
+
#
# Step 1: Parse the oops to find the EIP value
#
@@ -177,26 +189,26 @@ my $decodestart = Math::BigInt->from_hex
my $decodestop = Math::BigInt->from_hex("0x$target") + 8192;
if ($target eq "0") {
print "No oops found!\n";
- print "Usage: \n";
- print " dmesg | perl scripts/markup_oops.pl vmlinux\n";
- exit;
+ usage();
}

# if it's a module, we need to find the .ko file and calculate a load offset
if ($module ne "") {
- my $modulefile = `modinfo $module | grep '^filename:' | awk '{ print \$2 }'`;
- chomp($modulefile);
+ if ($modulefile eq "") {
+ my $modulefile = `modinfo $module | grep '^filename:' | awk '{ print \$2 }'`;
+ chomp($modulefile);
+ }
$filename = $modulefile;
if ($filename eq "") {
print "Module .ko file for $module not found. Aborting\n";
exit;
}
# ok so we found the module, now we need to calculate the vma offset
- open(FILE, "objdump -dS $filename |") || die "Cannot start objdump";
+ open(FILE, $cross_compile."objdump -dS $filename |") || die "Cannot start objdump";
while (<FILE>) {
if ($_ =~ /^([0-9a-f]+) \<$function\>\:/) {
my $fu = $1;
- $vmaoffset = hex($target) - hex($fu) - hex($func_offset);
+ $vmaoffset = Math::BigInt->from_hex("0x$target") - Math::BigInt->from_hex("0x$fu") - Math::BigInt->from_hex("0x$func_offset");
}
}
close(FILE);
@@ -212,7 +224,7 @@ sub InRange {
my ($address, $target) = @_;
my $ad = "0x".$address;
my $ta = "0x".$target;
- my $delta = hex($ad) - hex($ta);
+ my $delta = Math::BigInt->from_hex($ad) - Math::BigInt->from_hex($ta);

if (($delta > -4096) && ($delta < 4096)) {
return 1;
@@ -225,7 +237,7 @@ sub InRange {
# first, parse the input into the lines array, but to keep size down,
# we only do this for 4Kb around the sweet spot

-open(FILE, "objdump -dS --adjust-vma=$vmaoffset --start-address=$decodestart --stop-address=$decodestop $filename |") || die "Cannot start objdump";
+open(FILE, $cross_compile."objdump -dS --adjust-vma=$vmaoffset --start-address=$decodestart --stop-address=$decodestop $filename |") || die "Cannot start objdump";

while (<FILE>) {
my $line = $_;
@@ -344,3 +356,16 @@ while ($i < $finish) {
$i = $i +1;
}

+sub usage {
+ print <<EOT;
+Usage:
+ dmesg | perl $0 [OPTION] [VMLINUX]
+
+OPTION:
+ -c, -cross_compile CROSS_COMPILE Specify the prefix used for toolchain.
+ -m, -modulefile MODULE_DIRNAME Specify the module directory name.
+ -h, -help Help.
+EOT
+ exit;
+}
+

== 2 of 2 ==
Date: Tues, Jan 26 2010 12:00 am
From: Américo Wang

On Tue, Jan 26, 2010 at 3:38 PM, Hui Zhu <hui.zhu@windriver.com> wrote:
> Américo Wang:
>>
>> On Tue, Jan 26, 2010 at 11:11 AM, Hui Zhu <hui.zhu@windriver.com> wrote:
>>>
>>> Sorry guys, the prev mail still have some format trouble. I send a new
>>> mail
>>> for it.
>>> +}
>>> +
>>> +if ($vmlinux_name ne "") {
>>> + $vmlinux_name = $ARGV[$#ARGV];
>>> +}
>>
>> Why not using the Perl module 'Getopt' to do this?
>>
> Hi Américo,
>
> Thanks for remind me about it. The following patch use Getopt.
>
> The markup_oops.pl have 3 troubles to support cross-compiler environment:
> 1. It use objdump directly.
> 2. It use modinfo to get the message of module.
> 3. It use hex function that cannot support 64-bit number in 32-bit arch.
>
> This patch add 3 options to markup_oops.pl:
> 1. -c CROSS_COMPILE Specify the prefix used for toolchain.
> 2. -m MODULE_DIRNAME Specify the module directory name.
> 3. Change hex function to Math::BigInt->from_hex.
>
> After this patch, parse the x8664 oops in x86, we can:
> cat amd64m | perl ~/kernel/tmp/m.pl -c /home/teawater/kernel/bin/x8664- -m
> ./e.ko vmlinux
>
> Thanks,
> Hui
>
> Signed-off-by: Hui Zhu <teawater@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Arjan van de Ven <arjan@linux.intel.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: ozan@pardus.org.tr
> Cc: Matthew Wilcox <willy@linux.intel.com>
>
> ---
> scripts/markup_oops.pl | 45 +++++++++++++++++++++++++++++++++++----------
> 1 file changed, 35 insertions(+), 10 deletions(-)
>
> --- a/scripts/markup_oops.pl
> +++ b/scripts/markup_oops.pl
> @@ -2,6 +2,7 @@
>
> use File::Basename;
> use Math::BigInt;
> +use Getopt::Long;
>
> # Copyright 2008, Intel Corporation
> #
> @@ -15,7 +16,17 @@ use Math::BigInt;
> # Arjan van de Ven <arjan@linux.intel.com>
>
>
> -my $vmlinux_name = $ARGV[0];
> +my $cross_compile = "";
> +my $vmlinux_name = "";
> +my $modulefile = "";
> +
> +# Get options
> +Getopt::Long::GetOptions(
> + 'cross_compile|c=s' => \$cross_compile,

Please make it "cross-compile", because underline is not common
in command line, so "--cross_compile" is worse than "--cross-compile".

> + 'modulefile|m=s' => \$modulefile,

"module" should be enough to express the meaning, I think.

> + 'help|h' => \&usage,
> +);
> +my $vmlinux_name = $ARGV[$#ARGV];
> if (!defined($vmlinux_name)) {
> my $kerver = `uname -r`;
> chomp($kerver);
> @@ -23,6 +34,7 @@ if (!defined($vmlinux_name)) {
> print "No vmlinux specified, assuming $vmlinux_name\n";
> }
> my $filename = $vmlinux_name;
> +

Adding this empty line probably is not what you really want.

> #
> # Step 1: Parse the oops to find the EIP value
> #

{snip}

>
> +sub usage {
> + print <<EOT;
> +Usage:
> + dmesg | perl $0 [OPTION] [VMLINUX]
> +
> +OPTION:
> + -c, -cross_compile CROSS_COMPILE Specify the prefix used for
> toolchain.
> + -m, -modulefile MODULE_DIRNAME Specify the module directory name.
> + -h, -help Help.
> +EOT
> + exit;
> +}
> +

GNU style is preferred here, please use "--foo" instead of "-foo".

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

==============================================================================
TOPIC: Revert "perf record: Intercept all events"
http://groups.google.com/group/linux.kernel/t/017068de93596929?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 11:30 pm
From: Hitoshi Mitake

On Mon, Jan 25, 2010 at 23:57, Arnaldo Carvalho de Melo
<acme@infradead.org> wrote:
> Em Mon, Jan 25, 2010 at 11:47:40PM +0900, Hitoshi Mitake escreveu:
>> On Mon, Jan 25, 2010 at 11:23, Arnaldo Carvalho de Melo
>> <acme@infradead.org> wrote:
>> > Em Fri, Jan 22, 2010 at 10:39:13PM +0900, Hitoshi Mitake escreveu:
>> >> This reverts commit f5a2c3dce03621b55f84496f58adc2d1a87ca16f.
>> >>
>> >> This patch is required for making "perf lock rec" work.
>> >> The commit f5a2c3dce0 changes write_event() of builtin-record.c .
>> >> And changed write_event() sometimes doesn't stop with perf lock rec.
>> >>
>> >> I'm researching what makes write_event() loop infinity,
>> >> and noticed that there are some events with event_t->header.size == 0.
>> >> But the detail of the problem,
>> >> like kind of these events, isn't clear...
>> >>
>> >> If you know something related to this problem,
>> >> could you tell me, Arnaldo?
>> >
>> > Well, this will have to wait for somebody to remove the need for
>> > intercepting those events, reverting this patch fixes your tool while
>> > breaking others that then won't catch all the events.
>>
>> Yes, this patch is too egoistic thing and temporary solution.
>> I have to consider and modify 'perf lock'.
>
> Hey, don't get me wrong, the situation is fragile, either way something
> will get broken and that isn't your fault, its just that we need some
> sensible and non racy way to inject the buildids at 'perf record' time.

Thanks for correcting my misunderstand :)

>
> The way I did it, long ago, intercepting events in 'perf record' to
> build a DSO list to then at 'perf record' exit to insert a table at the
> perf.data file header looks too intrusive now, so we need some other way
> that doesn't have this problem and its not racy.

I see. I'll look some other way, too.
Or if you find it, could you tell me?

>
>> > I'll get 'perf regtest' out with some initial tests then try to get some
>> > proposal for injecting the buildid, if found in a DSO, via
>> > PERF_RECORD_MMAP, lets see how this goes...
>>
>> What does "DSO" mean? Sorry, I'm not good at English...
>
> As Peter said, anything that that is on an executable MMAP.

I understood :) Thanks, Peter and Arnaldo.

==============================================================================
TOPIC: oprofile fixes for v2.6.33
http://groups.google.com/group/linux.kernel/t/2915761a5b76e9c7?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 11:30 pm
From: Andrew Morton

On Mon, 25 Jan 2010 20:29:22 +0100 Robert Richter <robert.richter@amd.com> wrote:

> Suravee Suthikulpanit (1):
> oprofile/x86: fix crash when profiling more than 28 events

Did you consider a cc:stable on this one?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: PCI host bridge windows ignored (works with pci=use_crs)
http://groups.google.com/group/linux.kernel/t/8dc02ff411331726?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 11:30 pm
From: jeff@jgarrett.org (Jeff Garrett)

On Sun, Jan 24, 2010 at 11:04:38PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.32. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15124
> Subject : PCI host bridge windows ignored (works with pci=use_crs)
> Submitter : Jeff Garrett <jeff@jgarrett.org>
> Date : 2010-01-13 5:37 (12 days old)
> References : http://marc.info/?l=linux-kernel&m=126336296600307&w=4
> Handled-By : Yinghai Lu <yinghai@kernel.org>
> Bjorn Helgaas <bjorn.helgaas@hp.com>

This regression should still be listed. No patch to test yet.

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

==============================================================================
TOPIC: measureing kernel & application boottime's
http://groups.google.com/group/linux.kernel/t/2727ea96aab221a5?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 11:50 pm
From: Linus Walleij

2010/1/23 Shivdas Gujare <shivdas.tech@gmail.com>:

> I am trying to measure kernel boottime along with measuring
> application process start time on ARM V6 platform.
> Because of few reasons, I have to stick to kernel 2.6.25(can't upgrade
> it to latest).
(...)
> Also, Is there any best method to measure application start time
> (except bootchart, can't use it)?

Upgrade anyway. Seriously. It's for your own good. The best way to get
a bootchart without bootchart is to backport bootchart to kernel 2.6.25
and then the best strategy to do that is likely to upgrade to kernel 2.6.32
and rename it 2.6.25 and say it's a backport of the entire 2.6.32 to 2.6.25 :-P

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

==============================================================================
TOPIC: OOM-Killer kills too much with 2.6.32.2
http://groups.google.com/group/linux.kernel/t/3f7afc452c078f22?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:00 am
From: A Rojas

KOSAKI Motohiro wrote:

>
> Hi all,
>
> Strangely, all reproduce machine are x86_64 with Intel i915. but I don't
> have any solid evidence.

Hi,
I have the same issue in i686 (intel i915 too)

==============================================================================
TOPIC: futex() on vdso makes process unkillable
http://groups.google.com/group/linux.kernel/t/771496d6192e598e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:00 am
From: Peter Zijlstra

On Tue, 2010-01-26 at 11:41 +0900, KOSAKI Motohiro wrote:
> > Peter Zijlstra wrote:
> > > On Mon, 2010-01-25 at 16:27 +0900, KOSAKI Motohiro wrote:
> > <snip>
> > >> Futex should work both file anon anon. however I personally think
> > >> vdso is not file nor anon. it is special mappings. nobody defined
> > >> futex spec on special mappings. (yes, undefined).
> > >>
> > >> Personally, I think EINVAL or EFAULT are best result of vdso futexing, like as
> > >> futexing againt kernel address. but I guess another person have another thinking.
> > >>
> > >> I'd like to hear futex folks's opinion.
> > >
> > > Well, my opinion is we should remove the vdso, its ugly as hell :-)
> > >
> > > But I think it would make most sense to extend its definition in the
> > > direction of it being a file (for all intents and purposes its a special
> > > DSO -- which unfortunately isn't present in any filesystem).
> > >
> > > [ For all intents and purposes processes can already communicate through
> > > futexes on the libc space, so being able to do so through the vsdo
> > > really doesn't add anything ]
> > >
> > > So the problem is that the VDSO pages do not have a page->mapping
> > > because they lack the actual filesystem part of files, so even if (with
> > > the recent zero-page patch from Kosaki-san) you make private COWs of the
> > > VDSO, you'll get stuck in that loop.
> > >
> > > So the prettiest solution is to simply place the vdso in an actual
> > > filesystem and slowly migrate towards letting userspace map it as a
> > > regular DSO -- /sys/lib{32,64}/libkernel.so like.
> > >
> > > [ that has the bonus of getting rid of install_special_mapping() ]
> > >
> > > The ugly solution is special casing the vdso in get_futex_key().
> >
> > I like the creating-a-real-file solution. However, for now (and for
> > stable), I think Kosaki's suggestion of EINVAL or EFAULT is a good
> > stop-gap. EINVAL might play the best with existing glibc implementations.
>
> May I confirm your mention?
>
> If we can accept EFAULT, we don't need any change. my previous futex patch
> already did. because 1) VDSO is alwasys read-only mapped 2) write mode
> get_user_pages_fast() against read-only pte/vma return EFAULT.
>
> Current linus and stable tree don't cause Mark's original problem. instead, just
> return EFAULT. (Well, I'm sorry. my previous mail was unclear. I wrote v2.6.31 test
> result)
>
> If you can't accept EFAULT, we need to add vdso specific logic into get_futex_key().
> Is this your intention?

Oh, right you are, I mixed up the force and write arguments. Yes I tihnk
we're good.

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Tuesday, January 26, 2010

linux.kernel - 25 new messages in 17 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts