twitter: linux.kernel - 26 new messages in 19 topics

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

Today's topics:

* fix PHY polling system blocking - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a5c4ee686a904ad8?hl=en
* tomoyo: fix potential use after free - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5aee8e6d91b51c22?hl=en
* x86, mm: NX protection for kernel data - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f443973b61e7d544?hl=en
* perf probe: Fix need_dwarf flag if lazy matching is used - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/e91e1a43a96a8da5?hl=en
* x86,perf: Unmask LVTPC only if we have APIC supported - 4 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/135e9bd4a046877d?hl=en
* perf probe: Fix probe_point buffer overrun - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2b4d1caaa5816f29?hl=en
* 2.6.34-rc1 on zaurus: does it boot for you? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9dda0b137e5b6299?hl=en
* ring-buffer: Move disabled check into preempt disable section - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/80be419461f7c3fe?hl=en
* x86, k8 nb: Fix boot crash: enable k8_northbridges unconditionally on AMD
systems - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/23fd80db0655edba?hl=en
* Dream: Hook up trackball to drivers/staging interface - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/af079670f595439f?hl=en
* rename new rfkill sysfs knobs - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3a650f3bf132f923?hl=en
* fix MTD CFI/LPDDR flash driver huge latency bug - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/4359a015959d85f4?hl=en
* Fix a rare memory leak in kobject_set_name_vargs - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/64016ca9a80aedb5?hl=en
* Staging: comedi: dt3000: fixed some coding style issues - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/91b0150dae4d6de2?hl=en
* Possible bug in eeepc-laptop.c - EeePC 900 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/684e290393017980?hl=en
* allow retrieving entries with trailing dots - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/57d334aba1b16975?hl=en
* KOBJECTS: kref.h incorrectly describes itself as kref.c. - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/7b43ff9d5e39526f?hl=en
* exec: Rediff wrecked bits of usermodehelper overhaul - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/df8a377e74e7a001?hl=en
* scary warning in atags.c -- 2.6.34-rc1 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d6037575a1394d99?hl=en

==============================================================================
TOPIC: fix PHY polling system blocking
http://groups.google.com/group/linux.kernel/t/a5c4ee686a904ad8?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Mar 13 2010 4:00 am
From: Stefani Seibold

Am Freitag, den 12.03.2010, 14:42 -0800 schrieb Andrew Morton:
> On Sat, 06 Mar 2010 17:50:58 +0100
> Stefani Seibold <stefani@seibold.net> wrote:
>
> > This patch fix the PHY poller, which can block the whole system. On a
> > Freescale PPC 834x this result in a delay of 450 us due the slow
> > communication with the PHY chip.
> >
> > For PHY chips without interrupts, the status of the ethernet will be
> > polled every 2 sec. The poll function will read some register of the MII
> > PHY. The time between the sending the MII_READ_COMMAND and receiving the
> > result is more the 100 us on a PPC 834x.
> >
> > The patch modifies the poller a lit bit. Only a link status state change
> > will result in a successive detection of the connection type. The poll
> > cycle on the other hand will be increased to every seconds.
>
> You didn't tell us how many seconds. That would be important?
>

The old implementation would poll the PHC every 2 seconds, the new one
once per second.

> > Together this patch will prevent a blocking of nearly 400 us every two
> > seconds of the whole system on a PPC 834x.
> >
>
> I can't say that I really understand what you did - what functionality
> did we lose?
>

There is not real drawback, only the detection of a connection type
change without unplugging the cable will not work. But this is more an
esoteric use case.

> Would it not be better to extend the phy state machine a bit? When we
> detect the link status change, issue the MII command then arm the
> delayed-work timer to expire in a millisecond, then go in next time and
> read the result?
>
> That might require fancy locking to prevent other threads of control
> from going in and mucking up the MII state. Possibly leave phydev_lock
> held across that millisecond to keep other people away?
>

You are right, that would be the best solution. But i am currently busy,
so this a fast interim solution ;-) It was also my approach, because it
the PHY communication in the most cases very slow. Maybe i will do this
in the near future.

> >
> > ...
> >
> > diff -u -N -r -p linux-2.6.33.orig/drivers/net/phy/phy.c linux-2.6.33/drivers/net//phy/phy.c
> > --- linux-2.6.33.orig/drivers/net/phy/phy.c 2010-02-24 19:52:17.000000000 +0100
> > +++ linux-2.6.33/drivers/net//phy/phy.c 2010-02-28 22:53:14.725464101 +0100
>
> erp, your weird patch headers ("//") broke my seven-year-old script.
> But I fixed it!
>

Sorry, my fault. But now you have a better script.

> > @@ -871,9 +871,8 @@ void phy_state_machine(struct work_struc
> > case PHY_RUNNING:
> > /* Only register a CHANGE if we are
> > * polling */
> > - if (PHY_POLL == phydev->irq)
> > - phydev->state = PHY_CHANGELINK;
> > - break;
> > + if (PHY_POLL != phydev->irq)
> > + break;
> > case PHY_CHANGELINK:
> > err = phy_read_status(phydev);
> >
> > diff -u -N -r -p linux-2.6.33.orig/drivers/net/phy/phy_device.c linux-2.6.33/drivers/net//phy/phy_device.c
> > --- linux-2.6.33.orig/drivers/net/phy/phy_device.c 2010-02-24 19:52:17.000000000 +0100
> > +++ linux-2.6.33/drivers/net//phy/phy_device.c 2010-02-28 22:53:14.726464145 +0100
> > @@ -161,7 +161,7 @@ struct phy_device* phy_device_create(str
> > dev->speed = 0;
> > dev->duplex = -1;
> > dev->pause = dev->asym_pause = 0;
> > - dev->link = 1;
> > + dev->link = 0;
> > dev->interface = PHY_INTERFACE_MODE_GMII;
> >
> > dev->autoneg = AUTONEG_ENABLE;
> > @@ -694,10 +694,16 @@ int genphy_update_link(struct phy_device
> > if (status < 0)
> > return status;
> >
> > - if ((status & BMSR_LSTATUS) == 0)
> > + if ((status & BMSR_LSTATUS) == 0) {
> > + if (phydev->link==0)
> > + return 1;
> > phydev->link = 0;
> > - else
> > + }
> > + else {
> > + if (phydev->link==1)
> > + return 1;
> > phydev->link = 1;
> > + }
>
> Please don't invent new coding styles. scripts/checkpatch.pl is here
> to help.
>
>

Will be fixed!

--
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: Sat, Mar 13 2010 5:00 am
From: Stefani Seibold

This patch fix the PHY poller, which can block the whole system. PHY
access are normaly not very fast, since there are serial attached.

For PHY chips without interrupts, the status of the ethernet will be
polled every 2 sec. The poll function will read some register of the MII
PHY. The time between the sending the MII_READ_COMMAND and receiving the
result could be very long (>100us).

For example:

On a Freescale PPC 834x this result in a delay of 450 us due the slow
communication with the PHY chip. The time between the sending the
MII_READ_COMMAND and receiving the result is more the 100 us on this
controller.

The patch modifies the poller a lit bit. Only a link status state change
will result in a successive detection of the connection type. The poll
cycle on the other hand will be increased to one every seconds.

All in all this patch will prevent a blocking of f.e nearly 400 us every
two seconds of the whole system on a PPC 834x.

There is not real drawback, only the detection of a connection type
change without unplugging the cable will not work. But this is more an
esoteric use case.

The patch is against kernel 2.6.33. Please merge it.

Signed-off-by: Stefani Seibold <stefani@seibold.net>
---
phy.c | 5 ++---
phy_device.c | 11 ++++++++---
2 files changed, 10 insertions(+), 6 deletions(-)

diff -u -N -r -p linux-2.6.33.orig/drivers/net/phy/phy.c linux-2.6.33/drivers/net/phy/phy.c
--- linux-2.6.33.orig/drivers/net/phy/phy.c 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6.33/drivers/net/phy/phy.c 2010-02-28 22:53:14.725464101 +0100
@@ -871,9 +871,8 @@ void phy_state_machine(struct work_struc
case PHY_RUNNING:
/* Only register a CHANGE if we are
* polling */
- if (PHY_POLL == phydev->irq)
- phydev->state = PHY_CHANGELINK;
- break;
+ if (PHY_POLL != phydev->irq)
+ break;
case PHY_CHANGELINK:
err = phy_read_status(phydev);

diff -u -N -r -p linux-2.6.33.orig/drivers/net/phy/phy_device.c linux-2.6.33/drivers/net/phy/phy_device.c
--- linux-2.6.33.orig/drivers/net/phy/phy_device.c 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6.33/drivers/net/phy/phy_device.c 2010-02-28 22:53:14.726464145 +0100
@@ -161,7 +161,7 @@ struct phy_device* phy_device_create(str
dev->speed = 0;
dev->duplex = -1;
dev->pause = dev->asym_pause = 0;
- dev->link = 1;
+ dev->link = 0;
dev->interface = PHY_INTERFACE_MODE_GMII;

dev->autoneg = AUTONEG_ENABLE;
@@ -694,10 +694,15 @@ int genphy_update_link(struct phy_device
if (status < 0)
return status;

- if ((status & BMSR_LSTATUS) == 0)
+ if ((status & BMSR_LSTATUS) == 0) {
+ if (phydev->link == 0)
+ return 1;
phydev->link = 0;
- else
+ } else {
+ if (phydev->link == 1)
+ return 1;
phydev->link = 1;
+ }

return 0;
}

==============================================================================
TOPIC: tomoyo: fix potential use after free
http://groups.google.com/group/linux.kernel/t/5aee8e6d91b51c22?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 13 2010 4:10 am
From: Tetsuo Handa

Dan Carpenter wrote:

> The original code returns a freed pointer. This function is expected to
> return NULL on errors.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>

Oh, thank you.
James, please send this patch to 2.6.34-rc1 .

Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

> diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c
> index ff51f10..ef89947 100644
> --- a/security/tomoyo/common.c
> +++ b/security/tomoyo/common.c
> @@ -886,6 +886,7 @@ static struct tomoyo_profile *tomoyo_find_or_assign_new_profile(const unsigned
> ptr = kmalloc(sizeof(*ptr), GFP_KERNEL);
> if (!tomoyo_memory_ok(ptr)) {
> kfree(ptr);
> + ptr = NULL;
> goto ok;
> }
> for (i = 0; i < TOMOYO_MAX_CONTROL_INDEX; i++)
--
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, mm: NX protection for kernel data
http://groups.google.com/group/linux.kernel/t/f443973b61e7d544?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 13 2010 4:20 am
From: matthieu castet

Hi,

> > looking for c17ebdb8 in system.map points to a location in pgd_lock:
> > ============================================
> > $grep c17ebd System.map
> > c17ebd68 d bios_check_work
> > c17ebda8 d highmem_pages
> > c17ebdac D pgd_lock
> > c17ebdc8 D pgd_list
> > c17ebdd0 D show_unhandled_signals
> > c17ebdd4 d cpa_lock
> > c17ebdf0 d memtype_lock
> > ============================================
> >
> > I've looked at the lock debugging and could not find any place that
> > would look like an attempt to execute data. This would lead me to
> > think that calling set_memory_nx from kernel_init somehow confuses the
> > lock debugging subsystem, or set_memory_nx does not change page
> > attributes in a safe manner (for example when a lock is stored inside
> > the page whose attributes are being changed).
>
> I've done some extra debugging and it really does look like the crash
> happens when we are setting NX on a large page which has pgd_lock
> inside it.
>
> Here is a trace of printk's that I added to troubleshoot this issue:
> =========================
> [ 3.072003] try_preserve_large_page - enter
> [ 3.073185] try_preserve_large_page - address: 0xc1600000
> [ 3.074513] try_preserve_large_page - 2M page
> [ 3.075606] try_preserve_large_page - about to call static_protections
> [ 3.076000] try_preserve_large_page - back from static_protections
> [ 3.076000] try_preserve_large_page - past loop
> [ 3.076000] try_preserve_large_page - new_prot != old_prot
> [ 3.076000] try_preserve_large_page - the address is aligned and
> the number of pages covers the full range
> [ 3.076000] try_preserve_large_page - about to call __set_pmd_pte
> [ 3.076000] __set_pmd_pte - enter
> [ 3.076000] __set_pmd_pte - address: 0xc1600000
> [ 3.076000] __set_pmd_pte - about to call
> set_pte_atomic(*0xc18c0058(low=0x16001e3, high=0x0), (low=0x16001e1,
> high=0x80000000))
> [lock-up here]
> =========================
>

This may be stupid but :

0xc1600000 2MB page is in 0xc1600000-0xc1800000 range. pgd_lock (0xc17ebdac) seems to be in that range.

You change attribute from (low=0x16001e3, high=0x0) to (low=0x16001e1, high=0x80000000). IE you set
NX bit (bit 63), but you also clear R/W bit (bit 2). So the page become read only, but you are using a lock
inside this page that need RW access. So you got a page fault.

Now I don't know what should be done.
Is that normal we set the page RO ?

Matthieu
--
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 probe: Fix need_dwarf flag if lazy matching is used
http://groups.google.com/group/linux.kernel/t/e91e1a43a96a8da5?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 13 2010 4:30 am
From: tip-bot for Masami Hiramatsu

Commit-ID: fc6ceea045031658d0b59af562369eae980b4370
Gitweb: http://git.kernel.org/tip/fc6ceea045031658d0b59af562369eae980b4370
Author: Masami Hiramatsu <mhiramat@redhat.com>
AuthorDate: Fri, 12 Mar 2010 18:22:24 -0500
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sat, 13 Mar 2010 08:32:22 +0100

perf probe: Fix need_dwarf flag if lazy matching is used

Set need_dwarf if lazy matching pattern is specified, because
lazy matching requires real source path for which we must use
debuginfo.

Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
Cc: systemtap <systemtap@sources.redhat.com>
Cc: DLE <dle-develop@lists.sourceforge.net>
LKML-Reference: <20100312232224.2017.54550.stgit@localhost6.localdomain6>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
tools/perf/util/probe-event.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 53181db..7c004b6 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -242,7 +242,7 @@ void parse_perf_probe_event(const char *str, struct probe_point *pp,

/* Parse probe point */
parse_perf_probe_probepoint(argv[0], pp);
- if (pp->file || pp->line)
+ if (pp->file || pp->line || pp->lazy_line)
*need_dwarf = true;

/* Copy arguments and ensure return probe has no C argument */
--
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,perf: Unmask LVTPC only if we have APIC supported
http://groups.google.com/group/linux.kernel/t/135e9bd4a046877d?hl=en
==============================================================================

== 1 of 4 ==
Date: Sat, Mar 13 2010 4:30 am
From: Ingo Molnar

* Cyrill Gorcunov <gorcunov@openvz.org> wrote:

> Ingo reported
> |
> | There's a build failure on -tip with the P4 driver, on UP 32-bit, if
> | PERF_EVENTS is enabled but UP_APIC is disabled:
> |
> | arch/x86/built-in.o: In function `p4_pmu_handle_irq':
> | perf_event.c:(.text+0xa756): undefined reference to `apic'
> | perf_event.c:(.text+0xa76e): undefined reference to `apic'
> |
>
> So we have to unmask LVTPC only if we're configured to have one.
>
> Reported-by: Ingo Molnar <mingo@elte.hu>
> CC: Lin Ming <ming.m.lin@intel.com>
> CC: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
> ---
> arch/x86/kernel/cpu/perf_event_p4.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux-2.6.git/arch/x86/kernel/cpu/perf_event_p4.c
> =====================================================================
> --- linux-2.6.git.orig/arch/x86/kernel/cpu/perf_event_p4.c
> +++ linux-2.6.git/arch/x86/kernel/cpu/perf_event_p4.c
> @@ -365,8 +365,10 @@ static int p4_pmu_handle_irq(struct pt_r
> }
>
> if (handled) {
> +#ifdef CONFIG_X86_LOCAL_APIC
> /* p4 quirk: unmask it again */
> apic_write(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED);
> +

twitter

Saturday, March 13, 2010

linux.kernel - 26 new messages in 19 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts