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

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

Today's topics:

* KVM: x86: Kick VCPU outside PIC lock again - 4 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/07450b580f5cc563?hl=en
* Regulators: pcap-regulator - clean up driver data after removal - 4 messages,
1 author
http://groups.google.com/group/linux.kernel/t/9b85fe4e35c44d4b?hl=en
* gpiolib: make names array and its values const - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/64774e8fa15a19f2?hl=en
* security: fix error return path in ima_inode_alloc - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0e3efe5f4e097445?hl=en
* QUERY: Inclusion of header files in kernel header files - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/ba3ac3785a23053b?hl=en
* [resend] unusual_devs.h: Fix capacity for SL11R-IDE 2.6c - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/43adc56e5b6831bd?hl=en
* Regulators: fixed - annotate probe and remove methods - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8f3f33cbcc66f2b6?hl=en
* linux-next: build warning after merge of the ext3 tree - 2 messages, 1
author
http://groups.google.com/group/linux.kernel/t/1ff025ba8a648a40?hl=en
* enhance sysfs rfkill interface - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b45b314e4885cc6a?hl=en
* powerpc: implement arch_scale_smt_power for Power7 - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/891f3a14ac88e3fb?hl=en
* supress uid comparison test if core output files are pipes - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/755d4f35ceb69b4d?hl=en
* nfs: use 2*rsize readahead size - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0ded33f7779e13c7?hl=en
* Irish 2010 Grant Winner - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2d968f08f9bd8fa8?hl=en
* : input: add support for VirtualBox touchscreen emulation to the Lifebook
driver - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/36b703b3286dcd72?hl=en
* tuntap with tun_no_pi and X25 question - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f3bea71da0cc010e?hl=en

==============================================================================
TOPIC: KVM: x86: Kick VCPU outside PIC lock again
http://groups.google.com/group/linux.kernel/t/07450b580f5cc563?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Feb 24 2010 2:30 am
From: Jan Kiszka

Avi Kivity wrote:
> On 02/24/2010 12:13 PM, Jan Kiszka wrote:
>>
>>> I see. Won't we hit the same issue when we call pic functions from
>>> atomic context during the guest entry sequence?
>>>
>>>
>> If there are such call paths, for sure. What concrete path(s) do you
>> have in mind?
>>
>>
>
> vcpu_enter_guest() -> inject_pending_event() ->
> kvm_cpu_{has,get}_interrupt() -> various pic functions if you're unlucky.

But do they kick anyone or just check/pull information? Never saw any
warnings during my tests last year (granted: with older -rt and kvm
versions).

Jan

--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
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 4 ==
Date: Wed, Feb 24 2010 2:40 am
From: Jan Kiszka

Avi Kivity wrote:
> On 02/24/2010 12:22 PM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>
>>> On 02/24/2010 12:13 PM, Jan Kiszka wrote:
>>>
>>>>
>>>>> I see. Won't we hit the same issue when we call pic functions from
>>>>> atomic context during the guest entry sequence?
>>>>>
>>>>>
>>>>>
>>>> If there are such call paths, for sure. What concrete path(s) do you
>>>> have in mind?
>>>>
>>>>
>>>>
>>> vcpu_enter_guest() -> inject_pending_event() ->
>>> kvm_cpu_{has,get}_interrupt() -> various pic functions if you're unlucky.
>>>
>> But do they kick anyone or just check/pull information?
>
> Probably not, kicking should be a side effect (or rather the main
> effect) of queueing an interrupt, not dequeuing it.
>
>> Never saw any
>> warnings during my tests last year (granted: with older -rt and kvm
>> versions).
>>
>
> Well, most guests kill the pic early on. Will apply the patch.
>

I think it needs some extension: pic_irq_request should only schedule a
wake up on a rising edge of the PIC output.

Jan

== 3 of 4 ==
Date: Wed, Feb 24 2010 2:50 am
From: Avi Kivity

On 02/24/2010 12:28 PM, Jan Kiszka wrote:
> Jan Kiszka wrote:
>
>> Avi Kivity wrote:
>>
>>> On 02/24/2010 12:13 PM, Jan Kiszka wrote:
>>>
>>>>
>>>>
>>>>> I see. Won't we hit the same issue when we call pic functions from
>>>>> atomic context during the guest entry sequence?
>>>>>
>>>>>
>>>>>
>>>> If there are such call paths, for sure. What concrete path(s) do you
>>>> have in mind?
>>>>
>>>>
>>>>
>>> vcpu_enter_guest() -> inject_pending_event() ->
>>> kvm_cpu_{has,get}_interrupt() -> various pic functions if you're unlucky.
>>>
>> But do they kick anyone or just check/pull information? Never saw any
>> warnings during my tests last year (granted: with older -rt and kvm
>> versions).
>>
> Mmh, they could if there is> 1 IRQ pending. Guess this just never
> triggered in real life due to typical APIC use and low IRQ load during
> PIC times in my tests.
>

We could just ignore the wakeup in this path. It's called in vcpu
context, so obviously the vcpu is awake and kicking it will only hurt
your feet.

Longer term, we should clear up this mess. One possible path is to move
the pic/lapic/injection stuff out of the the critical section, and use
vcpu->requests to close the race between querying the pic/lapic and
entering the guest.

--
error compiling committee.c: too many arguments to function

--
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/

== 4 of 4 ==
Date: Wed, Feb 24 2010 3:50 am
From: Jan Kiszka

Avi Kivity wrote:
> On 02/24/2010 12:28 PM, Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>
>>> Avi Kivity wrote:
>>>
>>>> On 02/24/2010 12:13 PM, Jan Kiszka wrote:
>>>>
>>>>>
>>>>>> I see. Won't we hit the same issue when we call pic functions from
>>>>>> atomic context during the guest entry sequence?
>>>>>>
>>>>>>
>>>>>>
>>>>> If there are such call paths, for sure. What concrete path(s) do you
>>>>> have in mind?
>>>>>
>>>>>
>>>>>
>>>> vcpu_enter_guest() -> inject_pending_event() ->
>>>> kvm_cpu_{has,get}_interrupt() -> various pic functions if you're unlucky.
>>>>
>>> But do they kick anyone or just check/pull information? Never saw any
>>> warnings during my tests last year (granted: with older -rt and kvm
>>> versions).
>>>
>> Mmh, they could if there is> 1 IRQ pending. Guess this just never
>> triggered in real life due to typical APIC use and low IRQ load during
>> PIC times in my tests.
>>
>
> We could just ignore the wakeup in this path. It's called in vcpu
> context, so obviously the vcpu is awake and kicking it will only hurt
> your feet.

Looking at kvm_vcpu_kick, this already happens: The wake queue is
checked for pending waiters (ie. non if waking ourself), and no IPI is
sent if we run on the same CPU like the VCPU is on. That explains why
this path is practically safe.

>
> Longer term, we should clear up this mess. One possible path is to move
> the pic/lapic/injection stuff out of the the critical section, and use
> vcpu->requests to close the race between querying the pic/lapic and
> entering the guest.
>

Sounds worthwhile as well.

Jan

==============================================================================
TOPIC: Regulators: pcap-regulator - clean up driver data after removal
http://groups.google.com/group/linux.kernel/t/9b85fe4e35c44d4b?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Feb 24 2010 2:40 am
From: Mark Brown

On Tue, Feb 23, 2010 at 11:38:33PM -0800, Dmitry Torokhov wrote:
> It is a good tone to reset driver data after unbinding the device.
>
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
--
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 4 ==
Date: Wed, Feb 24 2010 2:40 am
From: Mark Brown

On Tue, Feb 23, 2010 at 11:38:39PM -0800, Dmitry Torokhov wrote:
> It is a good tone to reset driver data after unbinding the device.
> Also set up drivers owner.
>
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

== 3 of 4 ==
Date: Wed, Feb 24 2010 3:00 am
From: Mark Brown

On Tue, Feb 23, 2010 at 11:37:44PM -0800, Dmitry Torokhov wrote:
> Instead of open-coding sysfs attribute group use canned solution.
> Also add __devinit/__devexit markups for probe and remove methods
> and use 'bool' where it makes sense.

== 4 of 4 ==
Date: Wed, Feb 24 2010 3:40 am
From: Mark Brown

On Tue, Feb 23, 2010 at 11:38:06PM -0800, Dmitry Torokhov wrote:
> Also move error handling in probe() out of line and do not bother
> to reset fields in structures that are about to be freed.
>
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

==============================================================================
TOPIC: gpiolib: make names array and its values const
http://groups.google.com/group/linux.kernel/t/64774e8fa15a19f2?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 2:40 am
From: Uwe Kleine-König

Hi David,

what do you think about these three patches? Should I resend?

Best regards
Uwe

The following changes since commit 6339204ecc2aa2067a99595522de0403f0854bb8:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../viro/vfs-2.6

are available in the git repository at:

git://git.pengutronix.de/git/ukl/linux-2.6.git gpiolib/names

Uwe Kleine-König (3):
gpiolib: make names array and its values const
gpiolib: a gpio is unsigned, so use %u to print it
gpiolib: document that names can contain printk format specifiers

drivers/gpio/gpiolib.c | 4 ++--
drivers/gpio/pca953x.c | 2 +-
include/asm-generic/gpio.h | 6 ++++--
include/linux/i2c/pca953x.h | 2 +-
4 files changed, 8 insertions(+), 6 deletions(-)
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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: security: fix error return path in ima_inode_alloc
http://groups.google.com/group/linux.kernel/t/0e3efe5f4e097445?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 2:40 am
From: Xiaotian Feng

If radix_tree_preload is failed in ima_inode_alloc, we don't need
radix_tree_preload_end because kernel is alread preempt enabled

Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
Cc: Mimi Zohar <zohar@us.ibm.com>
Cc: James Morris <jmorris@namei.org>
Cc: Eric Paris <eparis@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Amit K. Arora <amitarora@in.ibm.com>
---
security/integrity/ima/ima_iint.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/security/integrity/ima/ima_iint.c b/security/integrity/ima/ima_iint.c
index 0d83edc..2d4d05d 100644
--- a/security/integrity/ima/ima_iint.c
+++ b/security/integrity/ima/ima_iint.c
@@ -63,12 +63,11 @@ int ima_inode_alloc(struct inode *inode)
spin_lock(&ima_iint_lock);
rc = radix_tree_insert(&ima_iint_store, (unsigned long)inode, iint);
spin_unlock(&ima_iint_lock);
+ radix_tree_preload_end();
out:
if (rc < 0)
kmem_cache_free(iint_cache, iint);

- radix_tree_preload_end();
-
return rc;
}

--
1.6.6

==============================================================================
TOPIC: QUERY: Inclusion of header files in kernel header files
http://groups.google.com/group/linux.kernel/t/ba3ac3785a23053b?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 2:40 am
From: Clemens Ladisch

Theodore Tso wrote:
> Also, it's highly desirable that as much as possible multiple
> inclusion is fixed up at the same time you add extra #includes into
> header files. Protecting against multiple inclusion is critical,
> yes, but even with the protection against multiple inclusion, the
> header file has to get parsed a second time, and that slows down
> kernel compiles.

Multiple inclusion of a protected header does not hurt at all; gcc
detects that a header file uses #ifdef/

twitter

Wednesday, February 24, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts