On Mon, 2012-10-08 at 18:57 +0530, Viresh Kumar wrote:
> On 8 October 2012 18:16, Andy Shevchenko
> wrote:
> > On Mon, 2012-10-08 at 16:19 +0530, Viresh Kumar wrote:
> >> > First of all it will export IP-block relevant functions to the kernel
> >> > namespace. I think it is not a good idea to pol
Based on commit: e66131cee501ee720b7b58a4b87073b8fbaaaba6
Not testing videobuf_dvb_get_frontend output may cause OOPS if it return
NULL. This patch fixes this issue.
The semantic patch that found this issue is(http://coccinelle.lip6.fr/):
//
@@
identifier i,a,b;
statement S, S2;
@@
i = videobuf_
On Tue, Oct 30, 2012 at 11:13:34AM +0530, Laxman Dewangan wrote:
> On Tuesday 30 October 2012 12:44 AM, Stephen Warren wrote:
> >I think it depends on DMAENGINE, not the specific driver now, doesn't it?
> Taking example from the mfd, we depends on particular driver, not
> from the core driver.
>
On Tuesday, October 30, 2012 03:28:45 PM Aaron Lu wrote:
> On Mon, Oct 29, 2012 at 10:11:20AM +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > If the caller of acpi_bus_set_power() already has a pointer to the
> > struct acpi_device object corresponding to the device in questio
Konrad Rzeszutek Wilk wrote:
>>> +config XEN_ACPI_PAD_STUB
>>> + bool
>>> + depends on XEN_DOM0 && X86_64 && ACPI
>>> + default n
>>> +
>>
>> This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native
>> pad would successfully registerred, and then mwait #UD (we would
>> revert df88b
On 30 October 2012 20:35, Andy Shevchenko
wrote:
> On Mon, 2012-10-08 at 18:57 +0530, Viresh Kumar wrote:
>> I do agree, we must have as less routines in kernel namespace as possible.
>> But not at the price of over complexity of stuff which isn't required.
>
> I didn't see the complexity you are
Hi,
On Tue, Oct 30, 2012 at 02:07:15PM +, Mark Brown wrote:
> On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote:
> > On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
>
> > > We need some place to put the SoC integration; power domains seem like
> > > the obvious place to
On 10/20/2012 01:29 AM, Mel Gorman wrote:
> I'm travelling at the moment so apologies that I have not followed up on
> this. My problem is still the same with the patch - it changes more
> headers than is necessary and it is sparsemem specific. At minimum, try
> the suggestion of
>
> if (!early_p
On Tue, Sep 11, 2012 at 12:10:18AM +0300, Michael S. Tsirkin wrote:
> > On the plus side, having an exit taken here on each page turns out to
> > be relatively cheap, as the vmexit from the page fault should be
> > faster to process as it is fully handled within the host kernel.
> >
> > Perhaps so
Fix crypto api for 3.6.4-rt10 (broken only in realtime patchset)
In peterz-srcu-crypto-chain.patch the blocking notifier is changed
to srcu notifier and added initialization to module init fucntion.
Later, in crypto-make-core-static-and-init-scru-early.patch, is that
initialization added also to
On Tue, 30 Oct 2012 12:20:32 + Mel Gorman wrote:
> ...
Useful testing - thanks. Did I miss the description of what
autonumabench actually does? How representitive is it of real-world
things?
> I also expect autonuma is continually scanning where as schednuma is
> reacting to some other e
On Sat, 27 Oct 2012, Thomas Gleixner wrote:
> Correct this by extending the arguments of unfreeze_partials with the
> target cpu number and use per_cpu_ptr instead of this_cpu_ptr.
Passing the kmem_cache_cpu pointer instead simplifies this a bit and avoid
a per_cpu_ptr operations. That reduces co
On Fri, 26 Oct 2012, JoonSoo Kim wrote:
> 2012/10/25 Christoph Lameter :
> > On Wed, 24 Oct 2012, Pekka Enberg wrote:
> >
> >> So I hate this patch with a passion. We don't have any fastpaths in
> >> mm/slab_common.c nor should we. Those should be allocator specific.
> >
> > I have similar thought
Work claiming semantics require this operation
to be SMP-safe.
So we want a strict ordering between the data we
want the work to handle and the flags that describe
the work state such that either we claim and we enqueue
the work that will see our data or we fail the claim
but the CPU where the wor
The IRQ_WORK_BUSY flag is set right before we execute the
work. Once this flag value is set, the work enters a
claimable state again.
This is necessary because if we want to enqueue a work but we
fail the claim, we want to ensure that the CPU where that work
is still pending will see and handle th
Hi,
The first patch is extracted from my printk patches, with changelog
reworked. The second patch is an addition.
And I still wonder if cpu_relax() is enough to prevent the compiler
from correctly reloading work->flags in irq_work_sync() loop.
Do we need ACCESS_ONCE()?
Thanks.
Frederic Weisbec
On Tue, Oct 30, 2012 at 3:05 PM, Steven Rostedt wrote:
> On Tue, 2012-10-30 at 14:51 +, Will Newton wrote:
>> Scan any text section whose name begins with ".text." so
>> we will find all the functions in a kernel built with
>> -ffunction-sections.
>
> A couple of things.
>
> First, I'm very pa
On 10/30/2012 07:31 PM, Christoph Lameter wrote:
> On Fri, 26 Oct 2012, JoonSoo Kim wrote:
>
>> 2012/10/25 Christoph Lameter :
>>> On Wed, 24 Oct 2012, Pekka Enberg wrote:
>>>
So I hate this patch with a passion. We don't have any fastpaths in
mm/slab_common.c nor should we. Those should
Hi!
> >> * buffered write (1GB file), 4KByte write
> >
> > Ok, f2fs is bit faster on desktop PC and a bit slower on S3. Good.
> >
> >
> >> * write + fsync (100MB file), 4KByte write
> >
> > Ok, random access on VFAT is a lot faster on S3 (and only very
> > a bit on PC). Any idea why results ar
On Tue, 30 Oct 2012, Ming Lei wrote:
> >> +bool pm_runtime_get_memalloc_noio(struct device *dev)
> >> +{
> >> + bool ret;
> >> + spin_lock_irq(&dev->power.lock);
> >> + ret = dev->power.memalloc_noio_resume;
> >> + spin_unlock_irq(&dev->power.lock);
> >> + return ret;
> >> +}
>
On Tue, 2012-10-30 at 16:32 +0800, Charles Wang wrote:
> calc_load_exit_idle depends on updated jiffies, so you shouldn't move
> this before tick_do_update_jiffies64.
OK, so it should be moved to the end of the if block. Note, that was a
change I made, as that function was added since Frederic d
On Tue, Oct 30, 2012 at 5:19 PM, Viresh Kumar wrote:
> On 30 October 2012 20:35, Andy Shevchenko
> wrote:
>> On Mon, 2012-10-08 at 18:57 +0530, Viresh Kumar wrote:
> For me i don't agree with your approach. So, its a NACK.
Point taken.
> However if Arnd/Vinod or You can give me some strong poin
On 10/29/2012 11:49 AM, Michael S. Tsirkin wrote:
Orphaning frags for zero copy skbs needs to allocate data in atomic
context so is has a chance to fail. If it does we currently discard
the skb which is safe, but we don't report anything to the caller,
so it can not recover by e.g. disabling zero
On Mon, Oct 29, 2012 at 09:01:40PM -0700, Dmitry Torokhov wrote:
> Hi Greg,
>
> On Mon, Oct 29, 2012 at 07:10:58PM -0700, Greg KH wrote:
> > On Mon, Oct 29, 2012 at 06:03:42PM -0700, George Zhang wrote:
> > > +/*
> > > + * Releases the VMCI context. If this is the last reference to
> > > + * the c
This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
("xen PVonHVM: move shared_info to MMIO before kexec").
Currently kexec in a PVonHVM guest fails with a triple fault because the
new kernel overwrites the shared info page. The exact failure depends on
the size of the kernel image. This
On 10/29/2012 11:49 AM, Michael S. Tsirkin wrote:
It seems that to avoid deadlocks it is enough to poll vq before
we are going to use the last buffer. This should be faster than
c70aa540c7a9f67add11ad3161096fb95233aa2e.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/net.c | 12 +++
On Mon, Oct 29, 2012 at 09:07:44PM -0700, Dmitry Torokhov wrote:
> Hi Greg,
>
> On Mon, Oct 29, 2012 at 07:19:38PM -0700, Greg KH wrote:
> > On Mon, Oct 29, 2012 at 06:03:28PM -0700, George Zhang wrote:
> > > drivers/misc/Kconfig |1
> > > drivers/misc/Makefile
On Mon, Oct 29, 2012 at 09:15:22PM -0700, Dmitry Torokhov wrote:
> On Mon, Oct 29, 2012 at 07:23:47PM -0700, Greg KH wrote:
> > On Mon, Oct 29, 2012 at 06:04:15PM -0700, George Zhang wrote:
> > > +static int __init vmci_core_init(void)
> > > +{
> > > + int result;
> > > +
> > > + result = vmci_ctx_
On Mon, Oct 29, 2012 at 09:58:21PM -0700, Dmitry Torokhov wrote:
> On Mon, Oct 29, 2012 at 07:24:46PM -0700, Greg KH wrote:
> > On Mon, Oct 29, 2012 at 06:04:27PM -0700, George Zhang wrote:
> > > +/*
> > > + * Releases the given VMCISubscription.
> > > + * Fires the destroy event if the reference c
On Mon, Oct 29, 2012 at 10:01:52PM -0700, Dmitry Torokhov wrote:
> On Mon, Oct 29, 2012 at 07:26:05PM -0700, Greg KH wrote:
> > On Mon, Oct 29, 2012 at 06:04:27PM -0700, George Zhang wrote:
> > > +static void event_signal_destroy(struct kref *kref)
> > > +{
> > > + struct vmci_subscription *entry =
On Tue, Oct 30, 2012 at 11:47:45AM -0400, Vlad Yasevich wrote:
> On 10/29/2012 11:49 AM, Michael S. Tsirkin wrote:
> >It seems that to avoid deadlocks it is enough to poll vq before
> > we are going to use the last buffer. This should be faster than
> >c70aa540c7a9f67add11ad3161096fb95233aa2e.
>
On Mon, Oct 29, 2012 at 10:20:16PM -0700, Dmitry Torokhov wrote:
> On Mon, Oct 29, 2012 at 07:29:05PM -0700, Greg KH wrote:
> > On Mon, Oct 29, 2012 at 06:04:58PM -0700, George Zhang wrote:
> > > +static struct vmci_resource *vmci_resource_lookup(struct vmci_handle
> > > handle)
> > > +{
> > > + s
On Tue, Oct 30, 2012 at 11:44:16AM -0400, Vlad Yasevich wrote:
> On 10/29/2012 11:49 AM, Michael S. Tsirkin wrote:
> >Orphaning frags for zero copy skbs needs to allocate data in atomic
> >context so is has a chance to fail. If it does we currently discard
> >the skb which is safe, but we don't rep
On Tue, 2012-10-30 at 16:34 +0100, Frederic Weisbecker wrote:
> Hi,
> And I still wonder if cpu_relax() is enough to prevent the compiler
> from correctly reloading work->flags in irq_work_sync() loop.
> Do we need ACCESS_ONCE()?
You mean this loop:
flags = work->flags & ~IRQ_WORK_PENDING
On Tue, 2012-10-30 at 16:35 +0100, Frederic Weisbecker wrote:
> Work claiming semantics require this operation
> to be SMP-safe.
>
> So we want a strict ordering between the data we
> want the work to handle and the flags that describe
> the work state such that either we claim and we enqueue
> th
Em Tue, Oct 30, 2012 at 08:45:28AM -0600, David Ahern escreveu:
> On 10/30/12 1:24 AM, Namhyung Kim wrote:
> >On Mon, 29 Oct 2012 10:31:41 -0600, David Ahern wrote:
> >>stdio based implementations of ui_ based functions for the python
> >>library. Needed for patch 3 - consolidating open counter
On Tuesday, October 30, 2012 08:46:52 AM Greg KH wrote:
> On Mon, Oct 29, 2012 at 09:01:40PM -0700, Dmitry Torokhov wrote:
> > Hi Greg,
> >
> > On Mon, Oct 29, 2012 at 07:10:58PM -0700, Greg KH wrote:
> > > On Mon, Oct 29, 2012 at 06:03:42PM -0700, George Zhang wrote:
> > > > +/*
> > > > + * Relea
On Tue, Oct 30, 2012 at 05:16:42PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 02:07:15PM +, Mark Brown wrote:
> > > and all of that SoC-specific detail is already hidden behind power
> > > domains, runtime PM, pinctrl, clk API, regulator framework, etc.
> > That's all getting rather
HW chaining is currently broken in imx-dma. It can be easily reproduced doing
intensive accesses to a external MMC card and checking how the file system
is corrupted.
Preventing the driver to use HW chaining solves these issues.
Signed-off-by: Javier Martin
---
drivers/dma/imx-dma.c |5 ++-
On Tuesday, October 30, 2012 08:50:41 AM Greg KH wrote:
> On Mon, Oct 29, 2012 at 10:01:52PM -0700, Dmitry Torokhov wrote:
> > On Mon, Oct 29, 2012 at 07:26:05PM -0700, Greg KH wrote:
> > > On Mon, Oct 29, 2012 at 06:04:27PM -0700, George Zhang wrote:
> > > > +static void event_signal_destroy(struc
On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern wrote:
>
> Okay, I see your point. But acquiring the lock here doesn't solve the
> problem. Suppose a thread is about to reset a USB mass-storage device.
> It acquires the lock and sees that the noio flag is clear. But before
> it can issue the rese
Hello!
This patch series contains documentation updates as follows:
1. Fix a broken example in memory-barriers.txt.
2. Fix a paper title in RTFP.txt. (Courtesy of Dhaval Giani.)
3. Mention kfree_rcu() in the whatisRCU.txt section covering
call_rcu(), and fix example code. (
The XenPVHVM extensions have not been tested much on very old
hypervisors. At least Xen 3.4 gets some testing with the pvops kernel.
Require at least Xen 3.4 for the PVonHVM extensions. If an older
hypervisor is detected the extensions will be disabled and the guest
will only see emulated hardware
On Tue, 2012-10-30 at 15:35 +, Will Newton wrote:
> On Tue, Oct 30, 2012 at 3:05 PM, Steven Rostedt wrote:
> > On Tue, 2012-10-30 at 14:51 +, Will Newton wrote:
> >> Scan any text section whose name begins with ".text." so
> >> we will find all the functions in a kernel built with
> >> -ff
From: "Paul E. McKenney"
This commit fixes a broken example of overlapping stores in the
Documentation/memory-barriers.txt file.
Reported-by: Nikunj A Dadhania
Signed-off-by: Paul E. McKenney
---
Documentation/memory-barriers.txt |9 +
1 files changed, 5 insertions(+), 4 deletions
From: "Paul E. McKenney"
The approach for mixing RCU and reference counting listed in the RCU
documentation only describes one possible approach. This approach can
result in failure on the read side, which is nice if you want fresh data,
but not so good if you want simple code. This commit ther
From: Kees Cook
Mention kfree_rcu() in the call_rcu() section. Additionally fix the
example code for list replacement that used the wrong structure element.
Signed-off-by: Kees Cook
Signed-off-by: Paul E. McKenney
---
Documentation/RCU/listRCU.txt |2 +-
Documentation/RCU/whatisRCU.txt
On Tuesday, October 30, 2012 08:51:59 AM Greg KH wrote:
> On Mon, Oct 29, 2012 at 10:20:16PM -0700, Dmitry Torokhov wrote:
> > On Mon, Oct 29, 2012 at 07:29:05PM -0700, Greg KH wrote:
> > > On Mon, Oct 29, 2012 at 06:04:58PM -0700, George Zhang wrote:
> > > > +static struct vmci_resource *vmci_reso
>>> On 30.10.12 at 16:47, Olaf Hering wrote:
> This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
> ("xen PVonHVM: move shared_info to MMIO before kexec").
>
> Currently kexec in a PVonHVM guest fails with a triple fault because the
> new kernel overwrites the shared info page. The exac
On Sat, Oct 27, 2012 at 08:33:18AM -0400, Jeff Layton wrote:
> Signed-off-by: Jeff Layton
> ---
> fs/namei.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 7c9bb50..467b9f1 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -
On Wed, Oct 31, 2012 at 12:00 AM, Ming Lei wrote:
>
> Looks the simplest approach is to handle the noio flag thing at the start and
> end of rpm_resume.
Sorry, that doesn't work, runtime_suspend need that too because memory
allocation with block I/O might deadlock when doing I/O on the same devic
From: Dhaval Giani
Trying to go through the history of RCU (not for the weak
minded) led me to search for a non-existent paper.
Correct it to the actual reference
Signed-off-by: Dhaval Giani
Cc: Peter Zijlstra
Signed-off-by: Paul E. McKenney
---
Documentation/RCU/RTFP.txt |2 +-
1 files
On Tue, Oct 30, 2012 at 08:48:01AM -0700, Greg KH wrote:
> On Mon, Oct 29, 2012 at 09:07:44PM -0700, Dmitry Torokhov wrote:
> > Hi Greg,
> >
> > On Mon, Oct 29, 2012 at 07:19:38PM -0700, Greg KH wrote:
> > > On Mon, Oct 29, 2012 at 06:03:28PM -0700, George Zhang wrote:
> > > > drivers/misc/Kconfi
On Sun, Oct 28, 2012 at 03:57:12PM -0500, danielfsan...@att.net wrote:
> Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
> creating compile-time errors required a little trickery.
> BUILD_BUG{,_ON} uses this attribute when available to generate
> compile-time errors, but also
This is a Chinese translated version of
Documentation/arm/kernel_user_helpers.txt
Signed-off-by: Fu Wei
---
Documentation/zh_CN/arm/kernel_user_helpers.txt | 285 +++
1 file changed, 285 insertions(+)
create mode 100644 Documentation/zh_CN/arm/kernel_user_helpers.txt
diff
On Wednesday 31 October 2012 00:00:56 Ming Lei wrote:
> On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern
> wrote:
>
> >
> > Okay, I see your point. But acquiring the lock here doesn't solve the
> > problem. Suppose a thread is about to reset a USB mass-storage device.
> > It acquires the lock and
* Omar Ramirez Luna [121030 05:20]:
> Tony,
>
> On 29 October 2012 12:52, Tony Lindgren wrote:
> >> --- /dev/null
> >> +++ b/include/linux/platform_data/omap_mailbox.h
> >> @@ -0,0 +1,105 @@
> >
> > This file should only contain pure platform data needed
> > by the core omap code to pass to the
2012/10/30 Steven Rostedt :
> On Tue, 2012-10-30 at 16:34 +0100, Frederic Weisbecker wrote:
>> Hi,
>
>> And I still wonder if cpu_relax() is enough to prevent the compiler
>> from correctly reloading work->flags in irq_work_sync() loop.
>> Do we need ACCESS_ONCE()?
>
> You mean this loop:
>
>
On Tue, Oct 30, 2012 at 8:29 AM, Michael S. Tsirkin wrote:
> On Tue, Sep 11, 2012 at 12:10:18AM +0300, Michael S. Tsirkin wrote:
>> > On the plus side, having an exit taken here on each page turns out to
>> > be relatively cheap, as the vmexit from the page fault should be
>> > faster to process a
On Tue, 2012-10-30 at 16:35 +0100, Frederic Weisbecker wrote:
> The IRQ_WORK_BUSY flag is set right before we execute the
> work. Once this flag value is set, the work enters a
> claimable state again.
>
> This is necessary because if we want to enqueue a work but we
> fail the claim, we want to e
On Tue, Oct 30, 2012 at 09:18:07AM -0700, Dmitry Torokhov wrote:
> > > I think that even if we had a special directory for vmci having network
> > > drivers in Dave's realm and pvscsi in James's is best option, so the new
> > > directory would contain vmci and the balloon driver (vsock will go into
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> From: "Paul E. McKenney"
>
> The approach for mixing RCU and reference counting listed in the RCU
> documentation only describes one possible approach. This approach can
> result in failure on the read side, which is nice if you want fresh
On Tue, Oct 30, Jan Beulich wrote:
> >>> On 30.10.12 at 16:47, Olaf Hering wrote:
> > This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
> > ("xen PVonHVM: move shared_info to MMIO before kexec").
> >
> > Currently kexec in a PVonHVM guest fails with a triple fault because the
> > new
On Tue, Oct 30, 2012 at 12:53:06AM -0400, Mark Lord wrote:
> On 12-10-29 07:03 PM, Greg Kroah-Hartman wrote:
> > On Mon, Oct 29, 2012 at 07:00:54PM -0400, Mark Lord wrote:
> >> There's something else very wrong when going from 3.4.9 to 3.4.16.
> >> I've done it on two machines here, one the AMD-450
On Tue, 30 Oct 2012 12:14:29 -0400
"J. Bruce Fields" wrote:
> On Sat, Oct 27, 2012 at 08:33:18AM -0400, Jeff Layton wrote:
> > Signed-off-by: Jeff Layton
> > ---
> > fs/namei.c | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/namei.c b/fs/namei.c
From: Lai Jiangshan
In old days, we had two different API sets for dynamic-allocated per-CPU
data and DEFINE_PER_CPU()-defined per_cpu data, and because SRCU used
dynamic-allocated per-CPU data, its srcu_struct structures cannot be
declared statically. This commit therefore introduces DEFINE_SRC
From: Lai Jiangshan
Use DEFINE_STATIC_SRCU() to simplify the rcutorture.c SRCU test code.
Signed-off-by: Lai Jiangshan
Reviewed-by: Josh Triplett
Signed-off-by: Paul E. McKenney
---
kernel/rcutorture.c | 41 ++---
1 files changed, 6 insertions(+), 35 del
From: Lai Jiangshan
Lai Jiangshan rewrote SRCU, so this commit ensures that he gets his
proper share of blame^Wcredit.
Signed-off-by: Lai Jiangshan
Signed-off-by: Paul E. McKenney
---
include/linux/srcu.h |2 ++
kernel/srcu.c|2 ++
2 files changed, 4 insertions(+), 0 deletions
From: "Paul E. McKenney"
Because grace-period initialization is carried out by a separate
kthread, it might happen on a different CPU than the one that
had the callback needing a grace period -- which is where the
callback acceleration needs to happen.
Fortunately, rcu_start_gp() holds the root
From: "Paul E. McKenney"
Several new rcutorture module parameters have been added, but are not
printed to the console at the beginning and end of tests, which makes
it difficult to reproduce a prior test. This commit therefore adds
these new module parameters to the list printed at the beginning
Hello!
This patch series contains SRCU changes allowing srcu_structs to be
statically initialized. The patches are as follows:
1. Add Lai Jiangshan as author for srcu.c and srcu.h.
(Courtesy Lia Jiangshan.)
2. Export process_srcu() so that the initialization macro may
b
From: "Paul E. McKenney"
The list_for_each_continue_rcu() macro is no longer used, so this commit
removes it. The list_for_each_entry_continue_rcu() macro should be
used instead.
Signed-off-by: Paul E. McKenney
---
Documentation/RCU/checklist.txt | 17 -
Documentation/RCU/wh
From: "Paul E. McKenney"
The RCU CPU stall warning timeout has defaulted to 60 seconds for
some years, with almost no false positives. This commit therefore
reduces the default to 21 seconds, slightly shorter than the new
soft-lockup timeout.
Signed-off-by: Paul E. McKenney
---
lib/Kconfig.de
From: Lai Jiangshan
Because process_srcu() will be used in DEFINE_SRCU(), which is a macro
that could be expanded pretty much anywhere, it can no longer be static.
Note that process_srcu() is still internal to srcu.h.
Signed-off-by: Lai Jiangshan
Signed-off-by: Paul E. McKenney
---
include/li
From: "Paul E. McKenney"
This commit explicitly states the memory-ordering properties of the
RCU grace-period primitives. Although these properties were in some
sense implied by the fundmental property of RCU ("a grace period must
wait for all pre-existing RCU read-side critical sections to comp
Hello!
This patch contains fixes as follows:
1. Reinstate a grace-period acceleration that permits invoking
the first callback registered on an idle system in one grace
period rather than two. The previous version of this acceleration
was invalidated by the new grace
From: "Paul E. McKenney"
Commit 29c00b4a1d9e27 (rcu: Add event-tracing for RCU callback
invocation) added a regression in rcu_do_batch()
Under stress, RCU is supposed to allow to process all items in queue,
instead of a batch of 10 items (blimit), but an integer overflow makes
the effective limi
On Sun, Oct 28, 2012 at 03:57:13PM -0500, danielfsan...@att.net wrote:
> When __CHECKER__ is defined, we disable all of the BUILD_BUG.* macros.
> However, BUILD_BUG_ON was evaluating to nothing in this case, and we
> want (0) since this is a function-like macro that will be followed by a
> semicolo
>>> On 30.10.12 at 17:30, Olaf Hering wrote:
> On Tue, Oct 30, Jan Beulich wrote:
>
>> >>> On 30.10.12 at 16:47, Olaf Hering wrote:
>> > This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
>> > ("xen PVonHVM: move shared_info to MMIO before kexec").
>> >
>> > Currently kexec in a PVonH
On Tue, Oct 30, 2012 at 7:40 AM, Colin King wrote:
> From: Colin Ian King
>
> Passing a NULL id causes a NULL pointer deference in writers
> such as erst_writer and efi_pstore_write because they expect
> to update this id. Pass a dummy id instead.
>
> This avoids a cascade of oopses caused when
Hello!
This patch series adds updates to RCU's CPU stall warning capability,
with patches as follows:
1. For architectures without NMI-based stack-dump capability,
have the current CPU remotely access the stalled CPU's stack
to dump it.
2. Include the number of the last
From: "Paul E. McKenney"
The RCU CPU stall warnings rely on trigger_all_cpu_backtrace() to
do NMI-based dump of the stack traces of all CPUs. Unfortunately, a
number of architectures do not implement trigger_all_cpu_backtrace(), in
which case RCU falls back to just dumping the stack of the runni
From: "Paul E. McKenney"
This commit causes the last grace period started and completed to be
printed on RCU CPU stall warning messages in order to aid diagnosis.
Signed-off-by: Paul E. McKenney
Signed-off-by: Paul E. McKenney
---
kernel/rcutree.c |8 +---
1 files changed, 5 insertion
From: "Paul E. McKenney"
Tiny RCU has historically omitted RCU CPU stall warnings in order to
reduce memory requirements, however, lack of these warnings caused
Thomas Gleixner some debugging pain recently. Therefore, this commit
adds RCU CPU stall warnings to tiny RCU if RCU_TRACE=y. This keep
From: "Paul E. McKenney"
In theory, if a grace period manages to get started despite there being
no callbacks on any of the CPUs, all CPUs could go into dyntick-idle
mode, so that the grace period would never end. This commit updates
the RCU CPU stall warning messages to detect this condition by
From: "hongbo.zhang"
V2->V3 Changes:
1. Moved the previous "[PATCH V2 2/6] Thermal: make sure cpufreq cooling
register after cpufreq driver" from generic cpu cooling layer to ST-Ericsson
driver, thus only 5 patches in total in V3 patch set.
2. Update ST-Ericsson thermal driver due to review com
From: "hongbo.zhang"
The curly bracket should be aligned with corresponding if else statements.
Signed-off-by: hongbo.zhang
Reviewed-by: Viresh Kumar
---
drivers/thermal/cpu_cooling.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/t
From: "hongbo.zhang"
In the while loop for counting cpu frequencies, if table[i].frequency equals
CPUFREQ_ENTRY_INVALID, index i won't be increased, so this leads to an endless
loop, what's more the index i cannot be referred as cpu frequencies number if
there is CPUFREQ_ENTRY_INVALID case.
Sign
From: "hongbo.zhang"
This diver is based on the thermal management framework in thermal_sys.c. A
thermal zone device is created with the trip points to which cooling devices
can be bound, the current cooling device is cpufreq, e.g. CPU frequency is
clipped down to cool the CPU, and other cooling
From: "hongbo.zhang"
This patch adds device tree properties for ST-Ericsson DB8500 thermal driver,
also adds the platform data to support the old fashion.
Signed-off-by: hongbo.zhang
---
arch/arm/boot/dts/dbx5x0.dtsi | 14 +
arch/arm/boot/dts/snowball.dts | 31
From: "hongbo.zhang"
Problem of using this list is that the cpufreq_get_max_state callback will be
called when register cooling device by thermal_cooling_device_register, but
this list isn't ready at this moment. What's more, there is no need to maintain
such a list, we can get cpufreq_cooling_de
On Wed, 31 Oct 2012, Ming Lei wrote:
> On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern
> wrote:
>
> >
> > Okay, I see your point. But acquiring the lock here doesn't solve the
> > problem. Suppose a thread is about to reset a USB mass-storage device.
> > It acquires the lock and sees that the no
From: "Paul E. McKenney"
The _cpu_down() function invoked as part of the CPU-hotplug offlining
process currently invokes __stop_machine(), which is slow and inflicts
substantial real-time latencies on the entire system. This patch
substitutes stop_cpus() for __stop_machine() in order to improve
From: "Paul E. McKenney"
This commit causes rcutorture to print the errno if cpu_down() fails
when the rcutorture "verbose" module parameter is specified.
Signed-off-by: Paul E. McKenney
Signed-off-by: Paul E. McKenney
---
kernel/rcutorture.c |9 -
1 files changed, 8 insertions(+)
From: "Paul E. McKenney"
This commit adds the counters to rcu_state and updates them in
synchronize_rcu_expedited() to provide the data needed for debugfs
tracing.
Signed-off-by: Paul E. McKenney
Signed-off-by: Paul E. McKenney
---
kernel/rcutree.c | 18 +++---
kernel/rcutree.h
Hello!
This patch series provides further updates to RCU's interaction with
CPU hotplug. The individual patches are as follows:
1. Fix an obsolete comment describing ->onofflock.
2. Make rcutorture print the errno from cpu_down() failure if
the "verbose" module parameter is spe
From: "Paul E. McKenney"
Tracing (debugfs) of expedited RCU primitives is required, which in turn
requires that the relevant data be located where the tracing code can find
it, not in its current static global variables in kernel/rcutree.c.
This commit therefore moves sync_sched_expedited_started
From: "Paul E. McKenney"
In the old days, _rcu_barrier() acquired ->onofflock to exclude
rcu_send_cbs_to_orphanage(), which allowed the latter to avoid memory
barriers in callback handling. However, _rcu_barrier() recently started
doing get_online_cpus() to lock out CPU-hotplug operations entire
From: "Paul E. McKenney"
The ->onofflock field in the rcu_state structure at one time synchronized
CPU-hotplug operations for RCU. However, its scope has decreased over time
so that it now only protects the lists of orphaned RCU callbacks. This
commit therefore renames it to ->orphan_lock to re
On Tue, Oct 30, 2012 at 08:28:10AM -0700, Andrew Morton wrote:
>
> On Tue, 30 Oct 2012 12:20:32 + Mel Gorman wrote:
>
> > ...
>
> Useful testing - thanks. Did I miss the description of what
> autonumabench actually does? How representitive is it of real-world
> things?
>
It's not repres
201 - 300 of 832 matches
Mail list logo
