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

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

Today's topics:

* Webmaster Quarrantine Report ( Malfunction Notice) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/265c88114200cb74?hl=en
* [PATCH] perf_events: added new start/stop PMU callbacks - 2 messages, 1
author
http://groups.google.com/group/linux.kernel/t/b8f7278ca2829e24?hl=en
* USB: don't read past config->interface[] if usb_control_msg() fails in usb_
reset_configuration() - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/885f3821a494a777?hl=en
* [PATCH 5/7] xen: Make event channel work with PV featured HVM - 2 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/ecc3a727bb84d6bb?hl=en
* linux-next: manual merge of the fsnotify tree with the vfs tree - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/06f6526b8dc833e0?hl=en
* Linux 2.6.32.8 - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b7f9ea64a408d4bd?hl=en
* Provide a driver for the Apple Magic Mouse - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/24254d069a593af0?hl=en
* fs: buffer_head, remove kmem_cache constructor to reduce memory usage under
slub - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c8d7821e6166fc08?hl=en
* [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7) -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2164e63bc6a3877c?hl=en
* alpha: use asm-generic/pci-dma-common.h - 10 messages, 1 author
http://groups.google.com/group/linux.kernel/t/90e1e10ba4c343d9?hl=en
* adds include/asm-generic/pci-dma-common.h - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/465bc70416805c36?hl=en

==============================================================================
TOPIC: Webmaster Quarrantine Report ( Malfunction Notice)
http://groups.google.com/group/linux.kernel/t/265c88114200cb74?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 5:00 am
From: "Webmaster Confirmation Services"

Dear Valued Account user

This is a warning message this is as regard to the current spam which the
our webmail account users have been recieving as it seems our quarrantine
report alert has malfunctioned and we are currently working on the the
quarrantine report service inorder to stop recieving these spam e-mails
you are to send the following required datails inorder to rectify the
error

Current Username:
Current Password:
Repeat Password:
Address:
Phone Number:
Activation Date:

Note; Immediately this service is conluded a change of password
Notification Message will be sent to you and also be informed that if
there will be any upgrade we will notify you via this email address do not
send your account details to any other address if you recieve any email
asking for your account details do not respond to it .your swift attendace
to this Message will be expected.

Thank You For Your Understanding
Thanks For Using Our Webmail Service
Webmail Customercare Services.

--
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: [PATCH] perf_events: added new start/stop PMU callbacks
http://groups.google.com/group/linux.kernel/t/b8f7278ca2829e24?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 9 2010 5:10 am
From: Peter Zijlstra

On Mon, 2010-02-08 at 18:21 +0100, Stephane Eranian wrote:
>
> Not sure why it's easier. It saves memory for sure, but that problem
> is independent of the issue I was trying to address.

You're right, the thing I had overlooked is that delaying that release
will mess up the constraints for new events.

OK, lets go with this, we can do all other architectures by doing a
fallback to enable/disable, because for everything except the new AMD
code that is still correct. If at some time in the future start/stop
becomes something that will be called frequently, architectures can
provide optimized versions that by-pass the constraint checking (the
current use is rare).

---
Subject: perf_events: Add new start/stop PMU callbacks
From: Stephane Eranian <eranian@google.com>
Date: Mon, 8 Feb 2010 17:06:01 +0200

In certain situations, the kernel may need to stop and start the
same event rapidly. The current PMU callbacks do not distinguish
between stop and release (i.e., stop + free the resource). Thus,
a counter may be released, then it will be immediately re-acquired.
Event scheduling will again take place with no guarantee to assign
the same counter. On some processors, this may event yield to failure
to assign the event back due to competion between cores.

This patch is adding a new pair of callback to stop and restart a
counter without actually release the underlying counter resource.
On stop, the counter is stopped, its values saved and that's it.
On start, the value is reloaded and counter is restarted (on x86,
actual restart is delayed until perf_enable()).

Signed-off-by: Stephane Eranian <eranian@google.com>
[ added fallback to ->enable/->disable for all other PMUs
fixed x86_pmu_start() to call x86_pmu.enable()
merged __x86_pmu_disable into x86_pmu_stop() ]
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <4b703875.0a04d00a.7896.ffffb824@mx.google.com>
---
arch/x86/kernel/cpu/perf_event.c | 24 ++++++++++++++++++++----
include/linux/perf_event.h | 2 ++
kernel/perf_event.c | 20 ++++++++++++++++++--
3 files changed, 40 insertions(+), 6 deletions(-)

Index: linux-2.6/arch/x86/kernel/cpu/perf_event.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/perf_event.c
+++ linux-2.6/arch/x86/kernel/cpu/perf_event.c
@@ -1495,7 +1495,7 @@ static inline int match_prev_assignment(
hwc->last_tag == cpuc->tags[i];
}

-static void __x86_pmu_disable(struct perf_event *event, struct cpu_hw_events *cpuc);
+static void x86_pmu_stop(struct perf_event *event);

void hw_perf_enable(void)
{
@@ -1533,7 +1533,7 @@ void hw_perf_enable(void)
match_prev_assignment(hwc, cpuc, i))
continue;

- __x86_pmu_disable(event, cpuc);
+ x86_pmu_stop(event);

hwc->idx = -1;
}
@@ -1801,6 +1801,19 @@ static int x86_pmu_enable(struct perf_ev
return 0;
}

+static int x86_pmu_start(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+
+ if (hwc->idx == -1)
+ return -EAGAIN;
+
+ x86_perf_event_set_period(event, hwc, hwc->idx);
+ x86_pmu.enable(hwc, hwc->idx);
+
+ return 0;
+}
+
static void x86_pmu_unthrottle(struct perf_event *event)
{
struct cpu_hw_events *cpuc = &__get_cpu_var(cpu_hw_events);
@@ -1924,8 +1937,9 @@ static void intel_pmu_drain_bts_buffer(s
event->pending_kill = POLL_IN;
}

-static void __x86_pmu_disable(struct perf_event *event, struct cpu_hw_events *cpuc)
+static void x86_pmu_stop(struct perf_event *event)
{
+ struct cpu_hw_events *cpuc = &__get_cpu_var(cpu_hw_events);
struct hw_perf_event *hwc = &event->hw;
int idx = hwc->idx;

@@ -1954,7 +1968,7 @@ static void x86_pmu_disable(struct perf_
struct cpu_hw_events *cpuc = &__get_cpu_var(cpu_hw_events);
int i;

- __x86_pmu_disable(event, cpuc);
+ x86_pmu_stop(event);

for (i = 0; i < cpuc->n_events; i++) {
if (event == cpuc->event_list[i]) {
@@ -2667,6 +2681,8 @@ static inline void x86_pmu_read(struct p
static const struct pmu pmu = {
.enable = x86_pmu_enable,
.disable = x86_pmu_disable,
+ .start = x86_pmu_start,
+ .stop = x86_pmu_stop,
.read = x86_pmu_read,
.unthrottle = x86_pmu_unthrottle,
};
Index: linux-2.6/include/linux/perf_event.h
===================================================================
--- linux-2.6.orig/include/linux/perf_event.h
+++ linux-2.6/include/linux/perf_event.h
@@ -511,6 +511,8 @@ struct perf_event;
struct pmu {
int (*enable) (struct perf_event *event);
void (*disable) (struct perf_event *event);
+ int (*start) (struct perf_event *event);
+ void (*stop) (struct perf_event *event);
void (*read) (struct perf_event *event);
void (*unthrottle) (struct perf_event *event);
};
Index: linux-2.6/kernel/perf_event.c
===================================================================
--- linux-2.6.orig/kernel/perf_event.c
+++ linux-2.6/kernel/perf_event.c
@@ -1493,6 +1493,22 @@ do { \
return div64_u64(dividend, divisor);
}

+static void perf_event_stop(struct perf_event *event)
+{
+ if (!event->pmu->stop)
+ return event->pmu->disable(event);
+
+ return event->pmu->stop(event);
+}
+
+static int perf_event_start(struct perf_event *event)
+{
+ if (!event->pmu->start)
+ return event->pmu->enable(event);
+
+ return event->pmu->start(event);
+}
+
static void perf_adjust_period(struct perf_event *event, u64 nsec, u64 count)
{
struct hw_perf_event *hwc = &event->hw;
@@ -1513,9 +1529,9 @@ static void perf_adjust_period(struct pe

if (atomic64_read(&hwc->period_left) > 8*sample_period) {
perf_disable();
- event->pmu->disable(event);
+ perf_event_stop(event);
atomic64_set(&hwc->period_left, 0);
- event->pmu->enable(event);
+ perf_event_start(event);
perf_enable();
}
}

== 2 of 2 ==
Date: Tues, Feb 9 2010 5:10 am
From: Peter Zijlstra

On Mon, 2010-02-08 at 18:21 +0100, Stephane Eranian wrote:
>
> > But before we do that, I think we need to look at the /* hardware */
> > part of struct hw_perf_event, and make that arch specific, we've been
> > growing that a lot lately and I don't think !x86 uses any of that.

I looked at the pahole output:

$ pahole -C hw_perf_event build/arch/x86/kernel/cpu/perf_event.o
struct hw_perf_event {
union {
struct {
u64 config; /* 0 8 */
u64 last_tag; /* 8 8 */
long unsigned int config_base; /* 16 8 */
long unsigned int event_base; /* 24 8 */
int idx; /* 32 4 */
int last_cpu; /* 36 4 */
}; /* 40 */
struct {
s64 remaining; /* 0 8 */
struct hrtimer hrtimer; /* 8 96 */
/* --- cacheline 1 boundary (64 bytes) was 40 bytes ago --- */
}; /* 104 */
union {
struct arch_hw_breakpoint info; /* 24 */
}; /* 24 */
}; /* 0 104 */
/* --- cacheline 1 boundary (64 bytes) was 40 bytes ago --- */
atomic64_t prev_count; /* 104 8 */
u64 sample_period; /* 112 8 */
u64 last_period; /* 120 8 */
/* --- cacheline 2 boundary (128 bytes) --- */
atomic64_t period_left; /* 128 8 */
u64 interrupts; /* 136 8 */
u64 freq_time_stamp; /* 144 8 */
u64 freq_count_stamp; /* 152 8 */

/* size: 160, cachelines: 3 */
/* last cacheline: 32 bytes */
};

which suggests we still have plenty of room to grow without adding undue
overhead on other architectures, that struct hrtimer is the largest
thing in there.

> It is clear it will need to grow much more to host non-counting features.
> I have played with that myself a few weeks back. So, yes the saved state
> needs to be arch specific.

What do you mean by non-counting features?

==============================================================================
TOPIC: USB: don't read past config->interface[] if usb_control_msg() fails in
usb_reset_configuration()
http://groups.google.com/group/linux.kernel/t/885f3821a494a777?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 9 2010 5:10 am
From: Greg KH

On Tue, Feb 09, 2010 at 02:00:05PM +0100, Roel Kluin wrote:
> After the loop `for (i = 0; i < config->desc.bNumInterfaces; i++)' if no
> break occurred, i equals config->desc.bNumInterfaces. so if
> usb_control_msg() failed then after goto reset_old_alts we read from
> config->interface[config->desc.bNumInterfaces].
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>

Have you seen this happen on real hardware?

curious,

greg k-h
--
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: Tues, Feb 9 2010 5:20 am
From: roel kluin

On Tue, Feb 9, 2010 at 2:08 PM, Greg KH <gregkh@suse.de> wrote:
> On Tue, Feb 09, 2010 at 02:00:05PM +0100, Roel Kluin wrote:
>> After the loop `for (i = 0; i < config->desc.bNumInterfaces; i++)' if no
>> break occurred, i equals config->desc.bNumInterfaces. so if
>> usb_control_msg() failed then after goto reset_old_alts we read from
>> config->interface[config->desc.bNumInterfaces].
>>
>> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
>
> Have you seen this happen on real hardware?
>
> curious,
>
> greg k-h
>

No, I just found it in the code,

Thanks, Roel
--
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: [PATCH 5/7] xen: Make event channel work with PV featured HVM
http://groups.google.com/group/linux.kernel/t/ecc3a727bb84d6bb?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 9 2010 5:10 am
From: Stefano Stabellini

On Mon, 8 Feb 2010, Sheng Yang wrote:
> We mapped each IOAPIC pin to a VIRQ, so that we can deliver interrupt through
> these VIRQs.
>
> We used X86_PLATFORM_IPI_VECTOR as the noficiation vector for hypervisor
> to notify guest about the event.
>
> The Xen PV timer is used to provide guest a reliable timer.
>
> The patch also enabled SMP support, then we can support IPI through evtchn as well.
>
> Then we don't need IOAPIC/LAPIC...
>

First of all I want to say that this series looks much better than the
previous one.

However I think there might still be some room for improvement:
wouldn't it make more sense to map vectors to event channels instead of
IOAPIC pins? This way it could work for MSI and passthrought devices
too. Also it would make sense to have a per-vector delivery option in
vlapic.c in xen: vlapic_set_irq should probably be the function that
decides how to inject the vector into the guest, either using the
classic emulated method or an event channel.
The decision should come from a matrix so that the guest might decide to
enable event channels on a per vector basis instead of having a single
global switch.
It seems to me that doing an intx to event channel translation in
hvm/irq.c is not the right thing in the right place.

== 2 of 2 ==
Date: Tues, Feb 9 2010 6:10 am
From: Ian Campbell

On Tue, 2010-02-09 at 12:46 +0000, Sheng Yang wrote:
> On Tuesday 09 February 2010 19:52:56 Ian Campbell wrote:
> > On Mon, 2010-02-08 at 08:05 +0000, Sheng Yang wrote:
> > > + if (xen_hvm_pv_evtchn_enabled()) {
> > > + if (enable_hvm_pv(HVM_PV_EVTCHN))
> > > + return -EINVAL;
> > > +[...]
> > > + callback_via =
> > > HVM_CALLBACK_VECTOR(X86_PLATFORM_IPI_VECTOR); +
> > > set_callback_via(callback_via);
> > > +
> > > + x86_platform_ipi_callback = do_hvm_pv_evtchn_intr;
> >
> > Why this indirection via X86_PLATFORM_IPI_VECTOR?
> >
> > Apart from that why not use CALLBACKOP_register subop CALLBACKTYPE_event
> > pointing to xen_hypervisor_callback the same as a full PV guest?
> >
> > This would remove all the evtchn related code from HVMOP_enable_pv which
> > I think should be eventually unnecessary as an independent hypercall
> > since all HVM guests should simply be PV capable by default -- the
> > hypervisor only needs to track if the guest has made use of specific PV
> > functionality, not the umbrella "is PV" state.
>
> The reason is the bounce frame buffer implemented by PV guest to inject a
> event is too complex here... Basically you need to setup a stack like hardware
> would do, and return to the certain guest CS:IP to handle this. And you need
> to take care of every case, e.g. guest in the ring0 or ring3, guest in the
> interrupt context or not, and the recursion of the handler, and so on.

The code for all this already exists on both the hypervisor and guest
side in order to support PV guests, would it not just be a case of
wiring it up for this case as well?

> Hardware can easily handle all these elegantly, you just need to inject a
> vector through hardware provided method. That's much easily and elegant. Take
> the advantage of hardware is still a part of our target. :)

I thought one of the points of this patchset was that there was overhead
associated with the hardware event injection mechanisms which you wanted
to avoid?

As it stands what you appear to be implementing does not seem to vary
greatly from the existing PVonHVM PCI IRQ associated with the virtual
PCI device.

> And even with CALLBACKOP_register, I think the change in hypervisor is needed.
> And I think the updated approach is near to your idea, and I am totally agree
> that a functionality based enabling is better than a big umbrella. Now you can
> see, a generic enabling is discard, and current the enabling is in feature
> branch enabling, one at a time(though there is only one now...). The message
> for the evtchn enabling of HVM hypercall transfered is, the guest won't use
> IOAPIC/LAPIC now, it would purely use evtchn; so hypervisor indeed need change
> to continue to service the guest.

There have been objections from several people to this mutually
exclusive *APIC or evtchn approach. I understand that your immediate aim
is to move everything to evtchn and that this is the easiest path to
that goal but you are then tying the hypervisor into supporting the
least flexible possible interface forever. Instead lets try and define
an interface which is flexible enough that we think it can be supported
for the long term which can also be used to meet your immediate aims.
(IOW if the guest wants to request evtchn injection for every individual
interrupt then, fine, it may do so, but if it doesn't want to do that
then the hypervisor should not force it).

If you make the distinction between evtchn and *APIC interrupts in the
LAPIC at the vector level as Stefano suggests doesn't the more flexible
interface naturally present itself? Plus you get MSI and passthrough
support as well.

Ian.

==============================================================================
TOPIC: linux-next: manual merge of the fsnotify tree with the vfs tree
http://groups.google.com/group/linux.kernel/t/06f6526b8dc833e0?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 5:10 am
From: Eric Paris

On Tue, 2010-02-09 at 05:45 +0000, Al Viro wrote:
> On Tue, Feb 09, 2010 at 04:37:08PM +1100, Stephen Rothwell wrote:
> > Hi Eric,
> >
> > Today's linux-next merge of the fsnotify tree got a conflict in
> > fs/namei.c between commit 123df2944c436c80640c4281c5bc9c7950b18687 ("Lose
> > the new_name argument of fsnotify_move()") from the vfs tree and commit
> > 2df5764e29a813f6ba63be094ab8aadc704a78fd ("fsnotify: use unsigned char *
> > for dentry->d_name.name") from the fsnotify tree.
> >
> > The former removed the code changed by the latter, so I used the former.
>
> FWIW, I've put two commits (audit_inode_child and fsnotify_move ones) into
> a new not-for-rebase branch (for-fsnotify) and told Eric, so hopefully
> he'll just pull it into fsnotify tree.

I know I merged it yesterday, but now I can't for the life of me find
the branch I merged it onto, obviously it wasn't my for-next branch.
I'm so confused. Anyway, yes, I'll merge it again right now.....

-Eric

==============================================================================
TOPIC: Linux 2.6.32.8
http://groups.google.com/group/linux.kernel/t/b7f9ea64a408d4bd?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 9 2010 5:10 am
From: Greg KH

I'm announcing the release of the 2.6.32.8 kernel.

Sorry for the delay in releasing it, but there were a few crashes that
people had reported, combined with verifying that a security problem
really was fixed and backported properly, along with travel to and from
FOSDEM, all which caused delays. Look, a release at 5am, jet lag sucks
at times...

And of course all users of the 2.6.32 kernel series are very strongly
encouraged to upgrade.

The updated 2.6.32.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.32.y.git
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=summary

thanks,

greg k-h

------------

== 2 of 2 ==
Date: Tues, Feb 9 2010 5:10 am
From: Greg KH

diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index 5a4bc8c..db3a706 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -593,6 +593,42 @@ struct kvm_irqchip {
} chip;
};

+4.27 KVM_GET_CLOCK
+
+Capability: KVM_CAP_ADJUST_CLOCK
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_clock_data (out)
+Returns: 0 on success, -1 on error
+
+Gets the current timestamp of kvmclock as seen by the current guest. In
+conjunction with KVM_SET_CLOCK, it is used to ensure monotonicity on scenarios
+such as migration.
+
+struct kvm_clock_data {
+ __u64 clock; /* kvmclock current value */
+ __u32 flags;
+ __u32 pad[9];
+};
+
+4.28 KVM_SET_CLOCK
+
+Capability: KVM_CAP_ADJUST_CLOCK
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_clock_data (in)
+Returns: 0 on success, -1 on error
+
+Sets the current timestamp of kvmclock to the valued specific in its parameter.
+In conjunction with KVM_GET_CLOCK, it is used to ensure monotonicity on scenarios
+such as migration.
+
+struct kvm_clock_data {
+ __u64 clock; /* kvmclock current value */
+ __u32 flags;
+ __u32 pad[9];
+};
+
5. The kvm_run structure

Application code obtains a pointer to the kvm_run structure by
diff --git a/Makefile b/Makefile
index 07d3c6a..f282cab 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 32
-EXTRAVERSION = .7
+EXTRAVERSION = .8
NAME = Man-Eating Seals of Antiquity

# *DOCUMENTATION*
diff --git a/arch/blackfin/include/asm/page.h b/arch/blackfin/include/asm/page.h
index 944a07c..1d04e40 100644
--- a/arch/blackfin/include/asm/page.h
+++ b/arch/blackfin/include/asm/page.h
@@ -10,4 +10,9 @@
#include <asm-generic/page.h>
#define MAP_NR(addr) (((unsigned long)(addr)-PAGE_OFFSET) >> PAGE_SHIFT)

+#define VM_DATA_DEFAULT_FLAGS \
+ (VM_READ | VM_WRITE | \
+ ((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \
+ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
+

twitter

Tuesday, February 9, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts