This RFC patch disables preemption between modifying lock->owner and
locking/unlocking the mutex lock. This prevents situations where the owner
can preempt between those 2 operations, which causes optimistic spinners to
be unable to check if lock->owner is not on CPU. As mentioned in the
thread
Before a thread attempts mutex spin on owner, it is first added to a queue
using an MCS lock so that only 1 thread spins on owner at a time. However, when
the spinner is queued, it is unable to check if it needs to reschedule and
will remain on the queue. This could cause the spinner to spin
The mutex_can_spin_on_owner() function should also return false if the
task needs to be rescheduled to avoid entering the MCS queue when it
needs to reschedule.
Signed-off-by: Jason Low
---
kernel/locking/mutex.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git
drivers/char/ipmi/ipmi_si_intf.c: In function 'ipmi_parisc_probe':
drivers/char/ipmi/ipmi_si_intf.c:2752:2: error: 'rv' undeclared (first use in
this function)
drivers/char/ipmi/ipmi_si_intf.c:2752:2: note: each undeclared identifier is
reported only once for each function it appears in
The mutex->spin_mlock was introduced in order to ensure that only 1 thread
spins for lock acquisition at a time to reduce cache line contention. When
lock->owner is NULL and the lock->count is still not 1, the spinner(s) will
continually release and obtain the lock->spin_mlock. This can generate
On Tue, Jan 28, 2014 at 10:46:18AM -0800, bseg...@google.com wrote:
> > @@ -4734,7 +4729,7 @@ static void migrate_tasks(unsigned int d
> > if (rq->nr_running == 1)
> > break;
> >
> > - next = pick_next_task(rq);
> > + next = pick_next_task(rq,
On Mon, 2014-01-27 at 20:09 +0800, Fengguang Wu wrote:
> Hi Dave,
>
> On Wed, Jan 15, 2014 at 11:18:27AM +1100, Dave Chinner wrote:
> > On Thu, Jan 09, 2014 at 10:57:15AM +0800, Fengguang Wu wrote:
> > > Hi Dave,
> > >
> > > As you suggested, I added tests for ext4 and btrfs, the results are
> >
On Tue, Jan 28, 2014 at 01:36:28PM -0500, Santosh Shilimkar wrote:
> + Gryagorii,
> On Tuesday 28 January 2014 01:22 PM, Russell King - ARM Linux wrote:
> > On Tue, Jan 28, 2014 at 12:23:02PM -0500, Santosh Shilimkar wrote:
> >> On Tuesday 28 January 2014 12:12 PM, Yinghai Lu wrote:
> >>> Index:
Am 28.01.2014 18:56, schrieb Linus Torvalds:
> On Tue, Jan 28, 2014 at 9:52 AM, Richard Weinberger wrote:
>>
>> x/10i schedule+0x45 works.
>
> Ok, so it's just list that is braindamaged. Maybe it wants a
> *(schedule+0x45) or something. I dunno. You can obviously get the hex
> number from just
Event channels driver needs to be initialized very early. Until now, Xen
initialization was done after all CPUs was bring up.
We can safely move the initialization to an early initcall.
Also use a cpu notifier to:
- Register the VCPU when the CPU is prepared
- Enable event channel IRQ
> I'm trying it now. But it takes a while for me to reproduce, and even
> longer to be sure the problem has gone away. So anything you hear from
> me within a week will be bad news.
Well, it's been a week, and: good news!
I'd still wish for some review by someone who really understands this
Add the trivial support necessary to get hardware breakpoints
working for GDB on ARMv8 simulators running in AArch32 mode.
Acked-by: Will Deacon
Signed-off-by: Christopher Covington
---
v3: assume for now that ARMv9 and later will update FSR
v2: modify debug_exception_updates_fsr
These should have been octal
Signed-off-by: Joe Perches
---
drivers/iommu/omap-iommu-debug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index d97fbe4..80fffba 100644
---
Peter Zijlstra writes:
> In order to avoid having to do put/set on a whole cgroup hierarchy
> when we context switch, push the put into pick_next_task() so that
> both operations are in the same function. Further changes then allow
> us to possibly optimize away redundant work.
>
>
On 01/26/2014 03:50 PM, Yinghai Lu wrote:
> assign_irq_vector will stop before first_system_vector.
> also it will not vector that is set in used_vectors.
>
> used_vectors is used to track non per_cpu irq_vector in vector_irq.
> It include first 32 exception [0,1f) and system vector near 0xfe.
This 444 should have been octal.
Signed-off-by: Joe Perches
---
drivers/fmc/fmc-write-eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fmc/fmc-write-eeprom.c b/drivers/fmc/fmc-write-eeprom.c
index 30e451e..1f107fb 100644
--- a/drivers/fmc/fmc-write-eeprom.c
Hi Linus,
Please pull the following Ceph updates from
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus
This is a big batch. From Ilya we have:
- rbd support for more than ~250 mapped devices (now uses same scheme
that SCSI does for device major/minor
On Tue, Jan 28, 2014 at 06:26:23PM +, Christopher Covington wrote:
> Add the trivial support necessary to get hardware breakpoints
> working for GDB on ARMv8 simulators running in AArch32 mode.
>
> Signed-off-by: Christopher Covington
> ---
>
> v2: modify debug_exception_updates_fsr
>
>
On Mon, Jan 27, 2014 at 6:30 PM, David Cohen
wrote:
> Hi Bjorn,
>
> On Mon, Jan 27, 2014 at 05:52:30PM -0700, Bjorn Helgaas wrote:
>> On Mon, Dec 16, 2013 at 1:07 PM, David Cohen
>> wrote:
>> > This code was partially based on Mark Brown's previous work.
>> >
>> > Signed-off-by: David Cohen
>>
In the presence of memoryless nodes, numa_node_id()/cpu_to_node() will
return the current CPU's NUMA node, but that may not be where we expect
to allocate from memory from. Instead, we should use
numa_mem_id()/cpu_to_mem(). On one ppc64 system with a memoryless Node
0, this ends up saving nearly
Thanks Michel!
Acked-by: Mike Waychison
On Tue, Jan 28, 2014 at 5:06 AM, Michel Lespinasse wrote:
> Two small fixes for google firmware drivers.
>
> The patches are against v3.13; I am proposing this for inclusion to v3.14.
>
> Michel Lespinasse (2):
> firmware: fix google/gsmi duplicate
+ Gryagorii,
On Tuesday 28 January 2014 01:22 PM, Russell King - ARM Linux wrote:
> On Tue, Jan 28, 2014 at 12:23:02PM -0500, Santosh Shilimkar wrote:
>> On Tuesday 28 January 2014 12:12 PM, Yinghai Lu wrote:
>>> Index: linux-2.6/include/linux/bootmem.h
>>>
2014/1/28 Ben Hutchings :
> On Mon, 2014-01-27 at 19:34 +0400, Alexey Charkov wrote:
>> 2014/1/27 Ben Hutchings :
>> > On Mon, 2014-01-27 at 15:51 +0400, Alexey Charkov wrote:
>> >> This should make the driver usable with VIA/WonderMedia ARM-based
>> >> Systems-on-Chip integrated Rhine III
On Tue, Jan 28, 2014 at 01:48:28PM +0800, xinhui.pan wrote:
> From: "xinhui.pan"
>
> i2c_dw_pci_runtime_idle should return -EBUSY rather than zero if it do
> success.
I don't understand...
> Otherwise rpm_idle will call pm_suspend again and that may cause
> pm_schedule_suspend delay
2014/1/27 Rob Herring :
> On Mon, Jan 27, 2014 at 5:51 AM, Alexey Charkov wrote:
>> This should make the driver usable with VIA/WonderMedia ARM-based
>> Systems-on-Chip integrated Rhine III adapters. Note that these
>> are always in MMIO mode, and don't have any known EEPROM.
>>
>> Signed-off-by:
On 01/27/2014 11:01 PM, Ren Qiaowei wrote:
>
> Yes. Though all non-MPX threads are slowed down, the whole process
> benefit from MPX.
>
> Anyway, HPA suggest these syscalls, which use MMU notifier, should be
> not needed, we can do what they do in userspace runtime. What do you
> think about it?
Add the trivial support necessary to get hardware breakpoints
working for GDB on ARMv8 simulators running in AArch32 mode.
Signed-off-by: Christopher Covington
---
v2: modify debug_exception_updates_fsr
arch/arm/include/asm/hw_breakpoint.h | 1 +
arch/arm/kernel/hw_breakpoint.c | 3 ++-
On Tue, Jan 28, 2014 at 12:23:02PM -0500, Santosh Shilimkar wrote:
> On Tuesday 28 January 2014 12:12 PM, Yinghai Lu wrote:
> > Index: linux-2.6/include/linux/bootmem.h
> > ===
> > --- linux-2.6.orig/include/linux/bootmem.h
> > +++
On 28/01/14 09:31, Peter Zijlstra wrote:
>> Exactly. I can remember also a huge period might be harmful, because with it
>> even a tiny utilization may lead to a big runtime that starves the whole non
>> RT tasks for a significant time.
>
> Another way to solve that is with explicit slack time
This should have been octal.
Signed-off-by: Joe Perches
---
arch/powerpc/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 86a63de..30a42e2 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@
On Tue, 28 Jan 2014, Julien Grall wrote:
> On 01/28/2014 05:46 PM, Stefano Stabellini wrote:
> > On Tue, 28 Jan 2014, Julien Grall wrote:
> +static int xen_cpu_notification(struct notifier_block *self,
> +unsigned long action,
> +
This patch makes the necessary changes at the x86 architecture
specific layer to enable the use of queue spinlock for x86-64. As
x86-32 machines are typically not multi-socket. The benefit of queue
spinlock may not be apparent. So queue spinlock is not enabled.
Currently, there is some
v2->v3:
- Simplify the code by using numerous mode only without an unfair option.
- Use the latest smp_load_acquire()/smp_store_release() barriers.
- Move the queue spinlock code to kernel/locking.
- Make the use of queue spinlock the default for x86-64 without user
configuration.
-
This patch introduces a new queue spinlock implementation that can
serve as an alternative to the default ticket spinlock. Compared with
the ticket spinlock, this queue spinlock should be almost as fair as
the ticket spinlock. It has about the same speed in single-thread and
it can be much faster
On 28.01.2014 10:48, Tomi Valkeinen wrote:
I made a somewhat hacky quickfix for beagle. Applying that and the
clk-divider from the link above makes things work for me. However, as I
said, the issue with n900 might be different, but it'd be interesting to
hear if it has any effect.
Tomi
On Tue, Jan 28, 2014 at 09:24:13AM -0800, David Cohen wrote:
> On Tue, Jan 28, 2014 at 10:49:37AM -0600, Felipe Balbi wrote:
> > On Tue, Jan 28, 2014 at 04:50:57PM +0800, xinhui.pan wrote:
> > > From: "xinhui.pan"
> > >
> > > intel_gpio_runtime_idle should return correct error code if it do
If I boot a kernel that is built on
commit 1b17366d695c8ab03f98d0155357e97a427e1dce
Merge: d12de1e 7179ba5
Author: Linus Torvalds
Date: Mon Jan 27 21:11:26 2014 -0800
Merge branch 'next' of
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc
it boots .
But if I boot with
commit
On Tue, 28 Jan 2014 18:16:34 +0100
Peter Zijlstra wrote:
> Here's a set that seems to work properly and hopefully adresses all previously
> raised issues.
>
> Daniel, I'm sorry, the idle_stamp thing wandered back over to fair.c :-)
>
> I did test the fair bits, including bandwidth (although
On 01/28/2014 05:46 PM, Stefano Stabellini wrote:
> On Tue, 28 Jan 2014, Julien Grall wrote:
+static int xen_cpu_notification(struct notifier_block *self,
+ unsigned long action,
+ void *hcpu)
+{
+ int cpu = (long)hcpu;
introduce get_cmdline() for retreiving the value of a processes
proc/self/cmdline value.
Acked-by: David Rientjes
Acked-by: Stephen Smalley
Signed-off-by: William Roberts
---
include/linux/mm.h |1 +
mm/util.c | 48
2 files
Re-factor proc_pid_cmdline() to use get_cmdline() helper
from mm.h.
Acked-by: David Rientjes
Acked-by: Stephen Smalley
Signed-off-by: William Roberts
---
fs/proc/base.c | 36 ++--
1 file changed, 2 insertions(+), 34 deletions(-)
diff --git a/fs/proc/base.c
During an audit event, cache and print the value of the process's
cmdline value (proc//cmdline). This is useful in situations
where processes are started via fork'd virtual machines where the
comm field is incorrect. Often times, setting the comm field still
is insufficient as the comm width is
I tested for a regression using the patched kernel with the nohz=off
command line option...
On Mon, Jan 13, 2014 at 10:15:18AM -0800, John Stultz wrote:
> On 01/13/2014 09:51 AM, Richard Cochran wrote:
> >
> > - Linux 3.12.7-nohz-plain-20140106nohz-plain.log
> > - Linux
On Tue, Jan 28, 2014 at 9:52 AM, Richard Weinberger wrote:
>
> x/10i schedule+0x45 works.
Ok, so it's just list that is braindamaged. Maybe it wants a
*(schedule+0x45) or something. I dunno. You can obviously get the hex
number from just doing "p schedule+0x45" and then do that.
Whatever. I
Am 28.01.2014 18:35, schrieb Linus Torvalds:
> On Tue, Jan 28, 2014 at 9:24 AM, Richard Weinberger wrote:
>>
>> Hmm, my gdb does not like that notion.
>>
>> (gdb) list schedule+0x45
>> Function "schedule+0x45" not defined.
>
> I don't have a debug build, so maybe it's something specific to gdb
>
On Tue, Jan 28, 2014 at 10:33:03AM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven
>
> This reverts commit e120cc0dcf2880a4c5c0a6cb27b655600a1cfa1d.
>
> It causes a NULL pointer dereference with drivers using the generic
> spi_transfer_one_message(), which always calls
>
On Tue, 28 Jan 2014, Julien Grall wrote:
> >> +static int xen_cpu_notification(struct notifier_block *self,
> >> + unsigned long action,
> >> + void *hcpu)
> >> +{
> >> + int cpu = (long)hcpu;
> >> +
> >> + switch (action) {
> >> + case
Thomas,
On Fri, Jan 10, 2014 at 01:34:30PM -0500, Jason Cooper wrote:
> On Wed, Dec 11, 2013 at 12:50:37PM -0500, Jason Cooper wrote:
> > On Sun, Dec 01, 2013 at 12:29:14PM -0500, Jason Cooper wrote:
> > > Here's an mvebu driver we've had on the ML for a while, and it's been in
> > > -next for 5
blkback bug fixes for memory leaks (patches 1 and 2) and a race
(patch 3).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Hi Mark,
On Tue, Jan 28, 2014 at 4:15 PM, Mark Brown wrote:
> On Tue, Jan 28, 2014 at 02:31:32PM +0530, Manish Badarkhe wrote:
>> On Tue, Jan 28, 2014 at 2:25 PM, Heiko Stübner wrote:
>
>> > I don't have a strong opinion on this and others are most likely more
>> > qualified
>> > to have a
I've at least identified two possible memory leaks in blkback, both
related to the shutdown path of a VBD:
- blkback doesn't wait for any pending purge work to finish before
cleaning the list of free_pages. The purge work will call
put_free_pages and thus we might end up with pages being
Move the call to xen_blkif_put after we have freed the request,
otherwise we have a race between the release of the request and the
cleanup done in xen_blkif_free.
Signed-off-by: Roger Pau Monné
Cc: Konrad Rzeszutek Wilk
Cc: David Vrabel
Cc: Boris Ostrovsky
Cc: Matt Rushton
Cc: Matt Wilson
From: Matt Rushton
Currently shrink_free_pagepool() is called before the pages used for
persistent grants are released via free_persistent_gnts(). This
results in a memory leak when a VBD that uses persistent grants is
torn down.
Cc: Konrad Rzeszutek Wilk
Cc: "Roger Pau Monné"
Cc: Ian
On 01/27/2014 01:17 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.13.1 release.
There are 10 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
From: Daniel Lezcano
The cpu parameter passed to idle_balance is not needed as it could
be retrieved from the struct rq.
Cc: alex@linaro.org
Cc: pet...@infradead.org
Cc: mi...@kernel.org
Signed-off-by: Daniel Lezcano
Signed-off-by: Peter Zijlstra
---
kernel/sched/core.c |2 +-
On Tue, 2014-01-28 at 13:17 +0100, Geert Uytterhoeven wrote:
> On Tue, Jan 28, 2014 at 1:04 PM, Ingo Molnar wrote:
> > * Geert Uytterhoeven wrote:
> >> On Sun, Jan 26, 2014 at 9:25 PM, Ingo Molnar wrote:
> >> > * Ingo Molnar wrote:
> >> >> * Linus Torvalds wrote:
> >> >> > On Sun, Jan 26,
On 01/28/2014 05:13 PM, Stefano Stabellini wrote:
> On Tue, 28 Jan 2014, Julien Grall wrote:
>> Event channels driver needs to be initialized very early. Until now, Xen
>> initialization was done after all CPUs was bring up.
>>
>> We can safely move the initialization to an early initcall.
>>
>>
Slightly easier code flow, no functional changes.
Signed-off-by: Peter Zijlstra
---
kernel/sched/fair.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2567,10 +2567,10 @@ static void __clear_buddies_last(struct
Track depth in cgroup tree, this is useful for things like
find_matching_se() where you need to get to a common parent of two
sched entities.
Keeping the depth avoids having to calculate it on the spot, which
saves a number of possible cache-misses.
Signed-off-by: Peter Zijlstra
---
From: Daniel Lezcano
The scheduler main function 'schedule()' checks if there are no more tasks
on the runqueue. Then it checks if a task should be pulled in the current
runqueue in idle_balance() assuming it will go to idle otherwise.
But the idle_balance() releases the rq->lock in order to
From: Daniel Lezcano
The idle_balance modifies the idle_stamp field of the rq, making this
information to be shared across core.c and fair.c. As we can know if the
cpu is going to idle or not with the previous patch, let's encapsulate the
idle_stamp information in core.c by moving it up to the
Here's a set that seems to work properly and hopefully adresses all previously
raised issues.
Daniel, I'm sorry, the idle_stamp thing wandered back over to fair.c :-)
I did test the fair bits, including bandwidth (although not very
extensively).
I did not test the dl/rt bits, Steve do you have
The idle post_schedule hook is just a vile waste of time, furthermore
it appears unneeded, move the idle_enter_fair() call into
pick_next_task_idle().
Cc: Daniel Lezcano
Cc: Vincent Guittot
Cc: alex@linaro.org
Cc: mi...@kernel.org
Cc: Steven Rostedt
Signed-off-by: Peter Zijlstra
---
Since commit 2f36825b1 ("sched: Next buddy hint on sleep and preempt
path") it is likely we pick a new task from the same cgroup, doing a put
and then set on all intermediate entities is a waste of time, so try to
avoid this.
Measured using:
mount nodev /cgroup -t cgroup -o cpu
cd /cgroup
In order to avoid having to do put/set on a whole cgroup hierarchy
when we context switch, push the put into pick_next_task() so that
both operations are in the same function. Further changes then allow
us to possibly optimize away redundant work.
Signed-off-by: Peter Zijlstra
---
On Tue, Jan 28, 2014 at 9:24 AM, Richard Weinberger wrote:
>
> Hmm, my gdb does not like that notion.
>
> (gdb) list schedule+0x45
> Function "schedule+0x45" not defined.
I don't have a debug build, so maybe it's something specific to gdb
actually seeing type information and then being
This patch both merged idle_balance() and pre_schedule() and pushes
both of them into pick_next_task().
Conceptually pre_schedule() and idle_balance() are rather similar,
both are used to pull more work onto the current CPU.
We cannot however first move idle_balance() into pre_schedule_fair()
From: Dave Hansen
This patch:
commit 309381feaee564281c3d9e90fbca8963bb7428ad
Author: Sasha Levin
Date: Thu Jan 23 15:52:54 2014 -0800
Subject: mm: dump page when hitting a VM_BUG_ON using VM_BUG_ON_PAGE
added a bunch of VM_BUG_ON_PAGE() calls. But, most of
Am 28.01.2014 18:12, schrieb Linus Torvalds:
> On Tue, Jan 28, 2014 at 9:05 AM, Ingo Molnar wrote:
>>
>> Well, I often use the hex numbers to look them up and disassemble them
>> in a vmlinux via gdb and 'list *0x1234123412341234' - where the
>> vmlinux has no debuginfo. (Debuginfo takes longer
On Tuesday 28 January 2014 12:12 PM, Yinghai Lu wrote:
> On Tue, Jan 28, 2014 at 7:30 AM, Kevin Hilman wrote:
>> > On Tue, Jan 28, 2014 at 12:02 AM, Olof Johansson wrote:
>>> >> Hi,
>>> >>
>>> >> On Fri, Jan 24, 2014 at 11:11 AM, Yinghai Lu wrote:
>>> The new memblock_virt APIs are used to
-off-by: David Dajun Chen
---
This patch is relative to linux-next repository tag next-20140128
The bug that this patch fixes affects two components of DA9052 namely:
WATCHDOG - the first kick will work but sebsequent ones will not
thus the will timeout at 2 x interval.
REGULATORS
On Tuesday 28 January 2014 12:18 PM, Russell King - ARM Linux wrote:
> On Tue, Jan 28, 2014 at 09:12:27AM -0800, Yinghai Lu wrote:
>> On Tue, Jan 28, 2014 at 7:30 AM, Kevin Hilman wrote:
>>> Like Olof, I noticed multiple boot failures on various ARM boards.
>>> I've confirmed that reverting the
On Wed, Jan 8, 2014 at 7:43 PM, Ville Syrjälä
wrote:
>
> The log looks fairly clear to me:
>
> 1. initially panel fitter is enabled on pipe B, and pipe B is outputting
>to LVDS and VGA. Border is enabled.
> 2. pipe A gets enabled outputting to LVDS. This will overwrite the
>LVDS border
On Tue, Jan 28, 2014 at 10:49:37AM -0600, Felipe Balbi wrote:
> On Tue, Jan 28, 2014 at 04:50:57PM +0800, xinhui.pan wrote:
> > From: "xinhui.pan"
> >
> > intel_gpio_runtime_idle should return correct error code if it do fail.
> > make it more correct even though -EBUSY is the most possible
On Tue, Jan 28, 2014 at 9:05 AM, Ingo Molnar wrote:
>
> Well, I often use the hex numbers to look them up and disassemble them
> in a vmlinux via gdb and 'list *0x1234123412341234' - where the
> vmlinux has no debuginfo. (Debuginfo takes longer to build so I
> generally build without it.)
Why
On 01/28, Al Viro wrote:
>
> On Tue, Jan 28, 2014 at 05:38:08PM +0100, Oleg Nesterov wrote:
> > On 01/28, Al Viro wrote:
> > >
> > > On Mon, Jan 27, 2014 at 06:39:31PM +0100, Oleg Nesterov wrote:
> > > > On 01/27, Al Viro wrote:
> > > > >
> > > > > Why is _TIF_UPROBE *not* a part
> > > > > of
On Tue, Jan 28, 2014 at 09:12:27AM -0800, Yinghai Lu wrote:
> On Tue, Jan 28, 2014 at 7:30 AM, Kevin Hilman wrote:
> > Like Olof, I noticed multiple boot failures on various ARM boards.
> > I've confirmed that reverting the arch/arm part of this patch makes
> > them all happily booting again.
>
This bit of information is in the Kconfig help text:
Note the boot CPU will still be kept outside the range to
handle the timekeeping duty.
However neither the variable NO_HZ_FULL_ALL, or the prompt
convey this important detail, so lets add it to the prompt
to make it more explicitly obvious
On Thu, 23 Jan 2014 17:29:07 -0600
Darren Etheridge wrote:
> > @@ -896,9 +897,9 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> > * TDA19988 requires high-active sync at input stage,
> > * so invert low-active sync provided by master encoder here
> > */
> > - if
On Tue, 28 Jan 2014, Julien Grall wrote:
> Event channels driver needs to be initialized very early. Until now, Xen
> initialization was done after all CPUs was bring up.
>
> We can safely move the initialization to an early initcall.
>
> Also use a cpu notifier to:
> - Register the VCPU
On Tue, Jan 28, 2014 at 7:30 AM, Kevin Hilman wrote:
> On Tue, Jan 28, 2014 at 12:02 AM, Olof Johansson wrote:
>> Hi,
>>
>> On Fri, Jan 24, 2014 at 11:11 AM, Yinghai Lu wrote:
>>> The new memblock_virt APIs are used to replaced old bootmem API.
>>>
>>> We need to allocate page below 4G for
On 01/26/2014 05:06 AM, Wang Nan wrote:
When BUILD_SRC contains a tailing '/', the file name used in compiling command
will contain '//', and it then goes to .o's debuginfo, confuses debugedit:
https://bugzilla.redhat.com/show_bug.cgi?id=304121
This patch uses realpath to makesure srctree and
Here are some small AF_RXRPC fixes.
(1) Fix a place where a spinlock is taken conditionally but is released
unconditionally.
(2) Fix a double-free that happens when cleaning up on a checksum error.
(3) Fix handling of CHECKSUM_PARTIAL whilst delivering messages to userspace.
David
---
Hi Stephan,
On Tue, Jan 28, 2014 at 10:11 PM, Stephen Warren wrote:
> On 01/27/2014 08:12 PM, Manish Badarkhe wrote:
>> Update the code to use devm_* API so that driver core will manage
>> resources.
>
> I'm not sure why this patch is sent to linux-te...@vger.kernel.org; it
> seems nothing to do
* Linus Torvalds wrote:
> On Tue, Jan 28, 2014 at 8:30 AM, H. Peter Anvin wrote:
> >
> > I don't think there is any way to not break anything... we're
> > introducing a new kind of object ("normalized kernel pointer") here.
>
> I suspect we could just drop the addresses entirely if we have a
Instead of "#ifdef CONFIG_OF" use "IS_ENABLED(CONFIG_OF)"
option for DT code to avoid if-deffery in code.
Signed-off-by: Manish Badarkhe
---
Changes since V1:
1.Updated code to use "IS_ENABLED" during retrieval
of platform/DT data.
Changes since V2:
1.Updated code as per Dmitry's comment to
On Tue, Jan 28, 2014 at 8:30 AM, H. Peter Anvin wrote:
>
> I don't think there is any way to not break anything... we're
> introducing a new kind of object ("normalized kernel pointer") here.
I suspect we could just drop the addresses entirely if we have a
symbolic version. It's not like the hex
On Tue, Jan 28, 2014 at 04:50:57PM +0800, xinhui.pan wrote:
> From: "xinhui.pan"
>
> intel_gpio_runtime_idle should return correct error code if it do fail.
> make it more correct even though -EBUSY is the most possible return value.
>
> Signed-off-by: bo.he
> Signed-off-by: xinhui.pan
> ---
On Tue, Jan 28, 2014 at 05:38:08PM +0100, Oleg Nesterov wrote:
> On 01/28, Al Viro wrote:
> >
> > On Mon, Jan 27, 2014 at 06:39:31PM +0100, Oleg Nesterov wrote:
> > > On 01/27, Al Viro wrote:
> > > >
> > > > Why is _TIF_UPROBE *not* a part
> > > > of _TIF_DO_NOTIFY_MASK, for example?
> > >
> > >
On 01/28, Al Viro wrote:
>
> On Mon, Jan 27, 2014 at 06:39:31PM +0100, Oleg Nesterov wrote:
> > On 01/27, Al Viro wrote:
> > >
> > > Why is _TIF_UPROBE *not* a part
> > > of _TIF_DO_NOTIFY_MASK, for example?
> >
> > Yes, please see another email. That is why uprobe_deny_signal()
> > sets
Good day kernel hackers,
when trying out which events are recognised by xev
to adjust my xbindkeysrc, I noticed that various keys
are incorrectly recognised on this machine:
- mute button on the side returns "f", should be xf86audiomute
- fn + f4 returns f4, should be "Lock" (if we have
Hi Jiri,
On 28 January 2014 14:04, Jiri Olsa wrote:
> On Fri, Jan 17, 2014 at 01:27:53PM +0100, Jean Pihet wrote:
>> Hi Jiri,
>>
>> Let me start on it next week. Is that OK?
>>
>> Thx for the reminder, I had not entirely forgotten it though ;p
> hi,
> rebased patchset to latest acme's perf/core
Hi,
Thanks for the patch :)
On Tue, Jan 28, 2014 at 04:50:57PM +0800, xinhui.pan wrote:
> From: "xinhui.pan"
>
> intel_gpio_runtime_idle should return correct error code if it do fail.
> make it more correct even though -EBUSY is the most possible return value.
>
> Signed-off-by: bo.he
>
On 01/27/2014 08:12 PM, Manish Badarkhe wrote:
> Update the code to use devm_* API so that driver core will manage
> resources.
I'm not sure why this patch is sent to linux-te...@vger.kernel.org; it
seems nothing to do with Tegra (or Samsung or OMAP for that matter).
--
To unsubscribe from this
On 01/28, Rakib Mullick wrote:
>
> As an alternative of using curr_target we can use get_nr_thread() count
We do not even need get_nr_thread() if we want to kill curr_target,
> @@ -961,21 +962,16 @@ static void complete_signal(int sig, struct task_struct
> *p, int group)
>*/
>
Hi,
On Tue, Jan 28, 2014 at 05:32:30PM +0200, Heikki Krogerus wrote:
> On Mon, Jan 27, 2014 at 10:05:20AM -0600, Felipe Balbi wrote:
> > > Why would you need to know if the PHY drivers are needed or not
> > > explicitly in your controller driver?
> >
> > because, one way or another, they all do
The following changes since commit d0abafac8c9162f39c4f6b2f8141b772a09b3770:
ext4: fix bigalloc regression (2014-01-06 14:00:23 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/ext4_for_linus
for you to fetch changes up to
On Thu, Jan 23, 2014 at 02:41:59PM -0500, Boris Ostrovsky wrote:
> 32-bit only.
Ok, I think I know what happens. Can you try this one (I missed doing
this on 32-bit and 64-bit does it, which would explain why it didn't
explode there):
---
diff --git a/arch/x86/kernel/cpu/microcode/amd_early.c
On 14-01-27 10:13 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2014-01-22 at 19:38 -0500, Paul Gortmaker wrote:
>
>> Thanks, it was a great help as it uncovered a few issues in fringe arch
>> that I didn't have toolchains for, and I've fixed all of those up.
>>
>> I've noticed that powerpc has
On 01/28/2014 08:25 AM, Richard Weinberger wrote:
>
> I fear both solutions will break various scripts.
> For example scripts/markup_oops.pl looks for \[\<([a-z0-9]+)\>\].
>
I don't think there is any way to not break anything... we're
introducing a new kind of object ("normalized kernel
301 - 400 of 1194 matches
Mail list logo
