Tuesday, January 26, 2010

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

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

linux.kernel@googlegroups.com

Today's topics:

* markup_oops.pl: add options to improve cross-sompilation environments - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/a94bf88dc8c7132f?hl=en
* dmaengine: fix memleak in dma_async_device_unregister - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/81e0c4a8db24d3a9?hl=en
* regulator: trivial: fix typos in user-visible Kconfig text - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/395977c92c91343c?hl=en
* starting emacs makes lockdep warning - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b92a5fcdc20fcbff?hl=en
* ftrace: unify arch_syscall_addr() implementations - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f483b618b805fe50?hl=en
* Staging:IIO: New ABI - 4 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/67848cebe4d912bf?hl=en
* 2.6.32 seemed to have broken nVidia MCP7A sata controller - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/63ce09c784f6b76d?hl=en
* [PATCH]Add support for more the 8 streams - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b92fae9ef14a7df2?hl=en
* input: MXC: add mxc-keypad driver to support the Keypad Port present in the
mxc application processors family. - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/c30e442c913811eb?hl=en
* Provide ways of crashing the kernel through debugfs - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/6fe510f7d559ec5f?hl=en
* tsl2550: Move form i2c/chips to als and update interfaces - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/3e3fbb748bf4dd03?hl=en
* UBIFS assert failed in ubifs_dirty_inode - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/838d13a27418fece?hl=en
* Hyperthreading on Core i7s: To use or not to use? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/185addf08bbc650e?hl=en
* twl4030 threaded_irq support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
* kgdb,clocksource: Prevent kernel hang in kernel debugger - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
* gpio_keys and how PXA27x sets gpio_set_wake() (was Re: sharp c-3000 aka
spitz: fix warn_on introduced in 2.6.32-rc1) - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/337ac495cfb9a0e2?hl=en

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

== 1 of 1 ==
Date: Tues, Jan 26 2010 1:30 am
From: Hui Zhu


Hi Américo,

On Tue, Jan 26, 2010 at 17:15, Américo Wang <xiyou.wangcong@gmail.com> wrote:
> On Tue, Jan 26, 2010 at 5:13 PM, Hui Zhu <hui.zhu@windriver.com> wrote:
>>
>> What do you think about it?
>>
>> And I changed the other part according to your mail.
>
>
> It looks fine for me now, I assume you already tested it.

It was tested. :)

>
>
>>
>> Best regards,
>> Hui
>>
>> 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>
>>
>
> Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
>

Thanks,
Hui
--
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: dmaengine: fix memleak in dma_async_device_unregister
http://groups.google.com/group/linux.kernel/t/81e0c4a8db24d3a9?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 1:30 am
From: Anatolij Gustschin


While debugging a dma driver I noticed a memleak after
unloading the driver module.

Caught by kmemleak.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Maciej Sosnowski <maciej.sosnowski@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>

---
drivers/dma/dmaengine.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 6f51a0a..e7a3230 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -826,6 +826,7 @@ void dma_async_device_unregister(struct dma_device *device)
chan->dev->chan = NULL;
mutex_unlock(&dma_list_mutex);
device_unregister(&chan->dev->device);
+ free_percpu(chan->local);
}
}
EXPORT_SYMBOL(dma_async_device_unregister);
--
1.6.2.5

--
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: regulator: trivial: fix typos in user-visible Kconfig text
http://groups.google.com/group/linux.kernel/t/395977c92c91343c?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 1:40 am
From: Mark Brown


On 26 Jan 2010, at 04:14, Alex Chiang <achiang@hp.com> wrote:

> Fix Kconfig text for some Wolfson Micro devices.
>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Signed-off-by: Alex Chiang <achiang@hp.com>

Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

> ---
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index 262f62e..c565e0d 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -91,14 +91,14 @@ config REGULATOR_WM831X
> of PMIC devices.
>
> config REGULATOR_WM8350
> - tristate "Wolfson Microelectroncis WM8350 AudioPlus PMIC"
> + tristate "Wolfson Microelectronics WM8350 AudioPlus PMIC"
> depends on MFD_WM8350
> help
> This driver provides support for the voltage and current
> regulators
> of the WM8350 AudioPlus PMIC.
>
> config REGULATOR_WM8400
> - tristate "Wolfson Microelectroncis WM8400 AudioPlus PMIC"
> + tristate "Wolfson Microelectronics WM8400 AudioPlus PMIC"
> depends on MFD_WM8400
> help
> This driver provides support for the voltage regulators of the
--
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 1 ==
Date: Tues, Jan 26 2010 1:40 am
From: Américo Wang


On Tue, Jan 26, 2010 at 5:14 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Américo Wang <xiyou.wangcong@gmail.com> writes:
>
>> On Tue, Jan 26, 2010 at 3:45 PM, KOSAKI Motohiro
>> <kosaki.motohiro@jp.fujitsu.com> wrote:
>>> Hi
>>>
>>>> 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
>>>
>>
>> Yeah, this seems reasonable for me, but not sure if this is the best fix.
>
> That or tweak __f_setown to use irqsave/irqrestore variants for it's
> locks, __f_setown is already atomic.  I prefer that direction because the
> code is just a little simpler.
>

Oh, very good advice!

Patch is below.

-------------->
Commit 703625118 causes a lockdep warning:

[ INFO: possible irq lock inversion dependency detected ]
2.6.33-rc5 #77
---------------------------------------------------------
emacs/1609 just changed the state of lock:
(&(&tty->ctrl_lock)->rlock){+.....}, at: [<ffffffff8127c648>]
tty_fasync+0xe8/0x190
but this lock took another, HARDIRQ-unsafe lock in the past:
(&(&sighand->siglock)->rlock){-.....}

This is due to we use write_lock_irq() in __f_setown() which turns
the IRQ on in write_unlock_irq(), causes this warning.

Switch it ot write_lock_irqsave() and write_unlock_irqrestore(),
as suggested by Eric.

Reported-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>

----

==============================================================================
TOPIC: ftrace: unify arch_syscall_addr() implementations
http://groups.google.com/group/linux.kernel/t/f483b618b805fe50?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 1:40 am
From: Mike Frysinger


Most implementations of arch_syscall_addr() are the same, so create a
default version in common code and move the one piece that differs (the
syscall table) to asm/syscall.h. New arch ports don't have to waste
time copying & pasting this simple function.

The s390/sparc versions need to be different, so document why.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Paul Mundt <lethal@linux-sh.org>
---
v3
- move sys_call_table[] decl to asm/syscall.h
- unify everyone's arch_syscall_addr() again
- mention right tracehook requirements

Documentation/trace/ftrace-design.txt | 5 ++---
arch/s390/include/asm/syscall.h | 7 +++++++
arch/s390/kernel/ftrace.c | 10 ----------
arch/sh/include/asm/syscall.h | 2 ++
arch/sh/kernel/ftrace.c | 9 ---------
arch/sparc/include/asm/syscall.h | 7 +++++++
arch/sparc/kernel/ftrace.c | 11 -----------
arch/x86/include/asm/syscall.h | 2 ++
arch/x86/kernel/ftrace.c | 10 ----------
include/linux/ftrace.h | 6 ++++++
kernel/trace/trace_syscalls.c | 5 +++++
11 files changed, 31 insertions(+), 43 deletions(-)

diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt
index 6a5a579..f1f81af 100644
--- a/Documentation/trace/ftrace-design.txt
+++ b/Documentation/trace/ftrace-design.txt
@@ -238,11 +238,10 @@ HAVE_SYSCALL_TRACEPOINTS

You need very few things to get the syscalls tracing in an arch.

+- Support HAVE_ARCH_TRACEHOOK (see arch/Kconfig).
- Have a NR_syscalls variable in <asm/unistd.h> that provides the number
of syscalls supported by the arch.
-- Implement arch_syscall_addr() that resolves a syscall address from a
- syscall number.
-- Support the TIF_SYSCALL_TRACEPOINT thread flags
+- Support the TIF_SYSCALL_TRACEPOINT thread flags.
- Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace
in the ptrace syscalls tracing path.
- Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
diff --git a/arch/s390/include/asm/syscall.h b/arch/s390/include/asm/syscall.h
index e0a73d3..8429686 100644
--- a/arch/s390/include/asm/syscall.h
+++ b/arch/s390/include/asm/syscall.h
@@ -15,6 +15,13 @@
#include <linux/sched.h>
#include <asm/ptrace.h>

+/*
+ * The syscall table always contains 32 bit pointers since we know that the
+ * address of the function to be called is (way) below 4GB. So the "int"
+ * type here is what we want [need] for both 32 bit and 64 bit systems.
+ */
+extern const unsigned int sys_call_table[];
+
static inline long syscall_get_nr(struct task_struct *task,
struct pt_regs *regs)
{
diff --git a/arch/s390/kernel/ftrace.c b/arch/s390/kernel/ftrace.c
index 5a82bc6..9e69449 100644
--- a/arch/s390/kernel/ftrace.c
+++ b/arch/s390/kernel/ftrace.c
@@ -200,13 +200,3 @@ out:
return parent;
}

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home


Real Estate