Hi Silviu,
* Silviu Popescu [2013-03-18 20:13:50 +0200]:
> On Mon, Mar 18, 2013 at 8:05 PM, Silviu Popescu
> wrote:
> > On Wed, Mar 13, 2013 at 11:31 AM, David Miller wrote:
> >> From: Silviu-Mihai Popescu
> >> Date: Tue, 12 Mar 2013 20:13:15 +0200
> >>
> >>> @@ -590,10 +590,7 @@ int __init b
On Mon, Mar 18, 2013 at 05:03:49PM +, Stephen Boyd wrote:
> On 03/17/13 07:28, Will Deacon wrote:
> > On Wed, Mar 13, 2013 at 01:32:01AM +, Stephen Boyd wrote:
> >> Some early versions of the Krait CPU design incorrectly indicate
> >> that they only support the UDIV and SDIV instructions in
Hi,
On Mon, Mar 18, 2013 at 10:16:56AM -0400, Alan Stern wrote:
> > > it would cause copious modification and duplication of ehci hcd
> > > driver. For example, there is no "configured_flag" register in
> > > fusbh200 controller, yet, ehci hcd driver accesses "configured_flag"
> > > in function eh
On Mon, 2013-03-18 at 09:43 -0700, Tejun Heo wrote:
> Hello, Steven.
>
> On Mon, Mar 18, 2013 at 12:30:43PM -0400, Steven Rostedt wrote:
> > If you happen to know the critical areas that require preemption to be
> > disabled for real, we can encapsulate them with:
> >
> > preempt_disable_rt()
Alex Williamson wrote:
>On Mon, 2013-03-18 at 18:20 +0100, Bjørn Mork wrote:
>> Alex Williamson writes:
>>
>> > At least for KVM the kernel fix is the addition of the vfio driver
>which
>> > gives us a non-sysfs way to do this. If this problem was found a
>few
>> > years later and we were read
On Mon, Mar 18, 2013 at 02:23:56PM -0400, Steven Rostedt wrote:
> On Mon, 2013-03-18 at 09:43 -0700, Tejun Heo wrote:
> > Hello, Steven.
> >
> > On Mon, Mar 18, 2013 at 12:30:43PM -0400, Steven Rostedt wrote:
> > > If you happen to know the critical areas that require preemption to be
> > > disabl
On Mon, Mar 18, 2013 at 01:08:07PM -0400, Steven Rostedt wrote:
> On Mon, 2013-03-18 at 09:43 -0700, Tejun Heo wrote:
>
> > Making gcwq locks disable preemption would be much safer / easier, but
> > if that's not desirable, anything touching gcwq->idle_list would be a
> > good place to start - wor
While attempting to upstream a patch to add the IDIV hwcap for
Krait processors, Will suggested we move the code to read the
ISAR0 register. This patchset does that and also works around
the early Krait CPU designs that don't follow the latest ARM ARM
for the ISAR0 register.
Stepan Moskovchenko (1
Don't advertise support for the SDIV/UDIV thumb instructions if
the kernel is not compiled with support for thumb userspace. This
is in line with how we remove the THUMB hwcap in these
configurations.
Acked-by: Will Deacon
Cc: Stepan Moskovchenko
Signed-off-by: Stephen Boyd
---
arch/arm/kernel
The ISAR0 register indicates support for the SDIV and UDIV
instructions in both the Thumb and ARM instruction set. Read the
register to detect the supported instructions and update the
elf_hwcap mask as appropriate. This is better than adding more
and more cpuid checks in proc-v7.S for each new cpu
From: Stepan Moskovchenko
Some early versions of the Krait CPU design incorrectly indicate
that they only support the UDIV and SDIV instructions in Thumb
mode when they actually support them in ARM and Thumb mode. It
seems that these CPUs follow the DDI0406B ARM ARM which has two
possible values
On Mon, Mar 18, 2013 at 10:50:21AM -0700, Casey Schaufler wrote:
> On 3/18/2013 10:05 AM, Vivek Goyal wrote:
> > On Fri, Mar 15, 2013 at 02:12:59PM -0700, Casey Schaufler wrote:
> >> On 3/15/2013 1:35 PM, Vivek Goyal wrote:
> >>> Create a new capability CAP_SIGNED which can be given to signed
> >>
On Mon, Mar 18, 2013 at 06:28:57PM +, Stephen Boyd wrote:
> From: Stepan Moskovchenko
>
> Some early versions of the Krait CPU design incorrectly indicate
> that they only support the UDIV and SDIV instructions in Thumb
> mode when they actually support them in ARM and Thumb mode. It
> seems
On 03/18/13 13:54, Alex Williamson wrote:
> On Mon, 2013-03-18 at 18:20 +0100, Bjørn Mork wrote:
>> Alex Williamson writes:
>>
>>> At least for KVM the kernel fix is the addition of the vfio driver which
>>> gives us a non-sysfs way to do this. If this problem was found a few
>>> years later and
On Mon, 2013-03-18 at 11:26 -0700, Tejun Heo wrote:
> > Hmm, the issue is that a "use to be" idle thread got migrated, and is
> > now being woken up by another worker. What can cause an established
> > worker to migrate without HOTPLUG being active?
>
> It doesn't. I think it's trying to wakeup
On Sun, Mar 17, 2013 at 09:48:46PM +, Will Deacon wrote:
> Due to all of the goodness being packed into today's kernels, the
> resulting image isn't as slim as it once was.
>
> In light of this, don't pass -msmall-data to the tools, which results in
> link failures due to impossible relocation
Hi Samuel,
On Wed, Feb 27, 2013 at 12:40 AM, Samuel Ortiz wrote:
> Hi Simon,
>
> On Tue, Feb 26, 2013 at 09:13:06PM -0800, Simon Glass wrote:
>> Hi Samuel,
>>
>> On Mon, Feb 25, 2013 at 2:08 PM, Simon Glass wrote:
>> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
>>
Cleanup. Now that we have f_inode/file_inode() we can use it instead
of ->f_mapping->host.
This should not make any difference for uprobes, but in theory this
change is more correct. We use this inode as a key, to compare it
with uprobe->inode set by uprobe_register(inode), and the caller uses
d_i
Sourav Poddar writes:
> OMAP_MAX_HSUART_PORTS is moved to omap_serial header file.
Why?
You started to explain it in the cover letter, but a full description
belongs here for the permanent git history.
Kevin
> Cc: Santosh Shilimkar
> Cc: Felipe Balbi
> Cc: Rajendra nayak
> Signed-off-by:
On 03/18/13 11:34, Will Deacon wrote:
> On Mon, Mar 18, 2013 at 06:28:57PM +, Stephen Boyd wrote:
>> From: Stepan Moskovchenko
>>
>> Some early versions of the Krait CPU design incorrectly indicate
>> that they only support the UDIV and SDIV instructions in Thumb
>> mode when they actually sup
2013/3/18 Rob Landley :
> On 03/18/2013 11:29:42 AM, Paul E. McKenney wrote:
> And really seems like it's kconfig help text?
It's more exhaustive than a Kconfig help. A Kconfig help text should
have the level of detail that describe the purpose and impact of a
feature, as well as some quick refere
On Mon, 18 Mar 2013, Felipe Balbi wrote:
> Hi,
>
> On Mon, Mar 18, 2013 at 10:16:56AM -0400, Alan Stern wrote:
> > > > it would cause copious modification and duplication of ehci hcd
> > > > driver. For example, there is no "configured_flag" register in
> > > > fusbh200 controller, yet, ehci hcd
On Mon, Mar 18, 2013 at 3:21 AM, Lin Feng wrote:
> Since add_range_with_merge() return the max none zero element of the array,
> it's
> suffice to use it to instruct clean_sort_range() to do the sort. Or the former
> assignment by add_range_with_merge() is nonsense because clean_sort_range()
> wi
On Mon, Mar 18, 2013 at 3:21 AM, Lin Feng wrote:
> For x86 PUD_SHIFT is 30 and PMD_SHIFT is 21, so the consequence of
> (PUD_SHIFT-PMD_SHIFT)/2 is 4. Update the comments to the code.
>
> Cc: Yinghai Lu
> Signed-off-by: Lin Feng
> ---
> arch/x86/mm/init.c | 2 +-
> 1 file changed, 1 insertion(+)
On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
>> > Just a datapoint -- I have put a trivial debugging patch in place, and it
>> > reveals that "nobody cared" for irq 16 happens long after last
>> >
>> > I915_WRITE(GMBUS4 + reg_offset, 0);
>>
On Mon, 2013-03-18 at 11:21 -0700, Tejun Heo wrote:
> I've been thinking about it and AFAICS the only way that BUG_ON()
> could trigger from preemption is if preemption happens while the
> idle_list head is becoming or stopping being empty.
> ie. pool->worklist is half updated so list_empty() isn'
On Mon, 2013-03-18 at 19:25 +0100, Bjørn Mork wrote:
> Alex Williamson wrote:
>
> >On Mon, 2013-03-18 at 18:20 +0100, Bjørn Mork wrote:
> >> Alex Williamson writes:
> >>
> >> > At least for KVM the kernel fix is the addition of the vfio driver
> >which
> >> > gives us a non-sysfs way to do this
On 03/18/2013 11:53 AM, Yinghai Lu wrote:
> On Mon, Mar 18, 2013 at 3:21 AM, Lin Feng wrote:
>> For x86 PUD_SHIFT is 30 and PMD_SHIFT is 21, so the consequence of
>> (PUD_SHIFT-PMD_SHIFT)/2 is 4. Update the comments to the code.
>>
>> Cc: Yinghai Lu
>> Signed-off-by: Lin Feng
>> ---
>> arch/x86
On Mon, Mar 18, 2013 at 8:33 AM, Vivek Goyal wrote:
> Thinking more about it, if ongoing DMA is an issue, then setting up
> software iotlb in those areas is also prone to being overwritten by
> those DMAs. Hence, reserving memory low where no DMA is setup by first
> kernel, seems somewhat safer.
On Wed, Mar 13, 2013 at 12:15:57PM +0100, Jiri Olsa wrote:
> On Tue, Mar 12, 2013 at 06:04:16PM +0100, Jiri Olsa wrote:
> > On Tue, Mar 12, 2013 at 05:24:50PM +0100, Peter Zijlstra wrote:
> > > Right you are..
> > >
> > > How about something like the below; using that 0 << -1 is still 0.
> >
> >
On Mon, Mar 18, 2013 at 02:57:30PM -0400, Steven Rostedt wrote:
> I like the theory, but it has one flaw. I agree that the update should
> be wrapped in preempt_disable() but since this bug happens on the same
> CPU, the state of the list will be the same when it was preempted to
> when it bugged.
This uses the resource_size() function instead of explicit computation.
Signed-off-by: Silviu-Mihai Popescu
---
drivers/staging/media/davinci_vpfe/dm365_ipipe.c |2 +-
drivers/staging/media/davinci_vpfe/dm365_isif.c|4 ++--
drivers/staging/media/davinci_vpfe/dm365_resizer.c |2
On Sun, Mar 17, 2013 at 3:38 PM, Prabhakar Lad
wrote:
> Hi,
>
> Thanks for the patch!
>
> did you build test this patch ? the above header file(ioport.h) is not
> required in all the
> above files which you included.
>
> Cheers,
> --Prabhakar Lad
Hi,
It would seem I was a bit overzealous. Indeed
On Mon, Mar 18, 2013 at 06:03:02PM +0100, Oleg Nesterov wrote:
> > Assume that's not happening, why would ptrace give me -ESRCH, yet
> > /proc//status would show me ptrace attached to the thread.
>
> And why do you think this should be explained by SIGKILL?
It's an assumption, if I knew before yo
On Mar 18, 2013, at 9:59 AM, Kumar Gala wrote:
>
> On Mar 17, 2013, at 10:48 AM, Sethi Varun-B16395 wrote:
>
+ guts_node = of_find_compatible_node(NULL, NULL,
+ "fsl,qoriq-device-config-1.0");
>>>
>>> This doesn't work for T4 or B4 device trees.
>>>
>> [Sethi
In -rt, most spin_locks() turn into mutexes. One of these spin_lock
conversions is performed on the workqueue gcwq->lock. When the idle
worker is worken, the first thing it will do is grab that same lock and
it too will block, possibly jumping into the same code, but because
nr_running would alread
On Mon, Mar 18, 2013 at 11:59 AM, H. Peter Anvin wrote:
> On 03/18/2013 11:53 AM, Yinghai Lu wrote:
>> On Mon, Mar 18, 2013 at 3:21 AM, Lin Feng wrote:
>>> For x86 PUD_SHIFT is 30 and PMD_SHIFT is 21, so the consequence of
>>> (PUD_SHIFT-PMD_SHIFT)/2 is 4. Update the comments to the code.
>>>
>>>
On 03/18/2013 08:33 AM, Vivek Goyal wrote:
>
> Thinking more about it, if ongoing DMA is an issue, then setting up
> software iotlb in those areas is also prone to being overwritten by
> those DMAs. Hence, reserving memory low where no DMA is setup by first
> kernel, seems somewhat safer.
>
Agre
Any comments from the ath9k folks?
On Sat, Mar 16, 2013 at 12:38:14PM -0400, Parag Warudkar wrote:
> During suspend below warning is seen when ath9k is active. Attached
> patch fixes the warning for me. Tested to work across few
> suspend-resume cycles.
>
>
> Mar 16 09:39:17 Parags-iMac kernel:
On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
> > > Just a datapoint -- I have put a trivial debugging patch in place, and it
> > > reveals that "nobody cared" for irq 16 happens long after last
> > >
> > > I915_WRITE(GMBUS4 + reg_o
On Mon, Mar 18, 2013 at 10:59:10AM -0400, Eduardo Valentin wrote:
> Even if the IRQ is not firing because it is ONE_SHOT and disable
> at INTC level, the IRQ handler must use spin_lock_irqsave.
> It is necessary to disable IRQs from the current
> CPU while it is holding a spin_lock which is need.
>
On 03/18/2013 12:13 PM, Yinghai Lu wrote:
>>
>> No, it doesn't. This is C, not elementary school Now I'm really bothered.
>>
>> The comment doesn't say *why* (PUD_SHIFT-PMD_SHIFT)/2 or any other
>> variant is correct, furthermore I suspect that the +1 is misplaced.
>> However, what is really need
On Mon, Mar 18, 2013 at 10:59:12AM -0400, Eduardo Valentin wrote:
> Because this driver will support also OMAP derivatives,
> this patch does a big rename inside this driver, so it
> better fits its usage.
>
It would be better to do a minimal move patch which just renames the
files and updated th
On Mon, Mar 18, 2013 at 04:56:02PM +0100, Jiri Kosina wrote:
> Okay, so I think that for 3.9 we want the patch below, and if eventually
> hardware root cause / workaround is found for GM45, we can have it merged
> later.
I'd prefer if we dig into this for a bit more. I've been traveling last
wee
On 3/18/2013 11:30 AM, Vivek Goyal wrote:
> On Mon, Mar 18, 2013 at 10:50:21AM -0700, Casey Schaufler wrote:
>> On 3/18/2013 10:05 AM, Vivek Goyal wrote:
>>> On Fri, Mar 15, 2013 at 02:12:59PM -0700, Casey Schaufler wrote:
On 3/15/2013 1:35 PM, Vivek Goyal wrote:
> Create a new capability
On Mon, 2013-03-18 at 12:06 -0700, Tejun Heo wrote:
> Me neither. Unfortunately, I'm out of ideas at the moment.
> Hmm... last year, there was a similar issue, I think it was in AMD
> cpufreq, which was caused by work function doing
> set_cpus_allowed_ptr(), so the idle worker was on the correct
On Mon, Mar 18, 2013 at 04:59:35PM +0100, Bjørn Mork wrote:
> Sergio Callegari writes:
>
> > This is just a short note to let you know that after installing 3.8.3,
> > display port stopped working on my laptop. Going back to 3.8.2 brought
> > it back to life.
> > This has been tested with the ubu
try_to_wake_up_local() should only be invoked to wake up another task
in the same runqueue and BUG_ON()s are used to enforce the rule.
Missing try_to_wake_up_local() can stall workqueue execution but such
stalls are likely to be finite either by another work item being
queued or the one blocked get
Hello, Linus.
Please pull from the following branch to receive Lai's patch to fix
highly unlikely but still possible workqueue stall during CPU
hotunplug.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-3.9-fixes
Thanks.
On Mon, Mar 18, 2013 at 03:16:01PM -0300, Gustavo Padovan wrote:
> Hi John,
>
> I put together 3 fixes intended for 3.9, there are support for two new devices
> and a NULL dereference fix in the SCO code.
>
> Please pull or let me know of any problem. Thanks!
>
> Gustavo
>
> ---
> The f
On Mon, 2013-03-18 at 12:22 -0700, Tejun Heo wrote:
> try_to_wake_up_local() should only be invoked to wake up another task
> in the same runqueue and BUG_ON()s are used to enforce the rule.
> Missing try_to_wake_up_local() can stall workqueue execution but such
> stalls are likely to be finite eit
On Mon, Mar 18, 2013 at 01:11:09AM +, Ben Hutchings wrote:
> On Tue, 2013-03-12 at 15:31 -0700, Greg Kroah-Hartman wrote:
> > 3.8-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Stéphane Marchesin
> >
> > commit 0920a48719f1ce
On 18-03-2013 15:16, Dan Carpenter wrote:
On Mon, Mar 18, 2013 at 10:59:10AM -0400, Eduardo Valentin wrote:
Even if the IRQ is not firing because it is ONE_SHOT and disable
at INTC level, the IRQ handler must use spin_lock_irqsave.
It is necessary to disable IRQs from the current
CPU while it is
On Mon, Mar 18, 2013 at 12:40:35PM -0700, Stéphane Marchesin wrote:
>
>
>
> On Mon, Mar 18, 2013 at 12:38 PM, Greg Kroah-Hartman <
> gre...@linuxfoundation.org> wrote:
>
> On Mon, Mar 18, 2013 at 01:11:09AM +, Ben Hutchings wrote:
> > On Tue, 2013-03-12 at 15:31 -0700, Greg Kroah-Ha
On Wed, Mar 13, 2013 at 07:54:01PM -0700, Tejun Heo wrote:
> On Wed, Mar 13, 2013 at 04:58:12PM -0700, Tejun Heo wrote:
> > This patch is on top of wq/for-3.10 e626761691 ("workqueue: implement
> > current_is_workqueue_rescuer()").
>
> Oops, forgot the git branch.
>
> git://git.kernel.org/pub/s
On Wed, Mar 13, 2013 at 07:57:18PM -0700, Tejun Heo wrote:
> and available in the following git branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git review-finer-locking
Applied to wq/for-3.10.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Mon, Mar 18, 2013 at 01:01:36PM -0400, David Miller wrote:
> From: "Michael S. Tsirkin"
> Date: Mon, 18 Mar 2013 13:20:03 +0200
>
> > The following changes since commit 8c6216d7f118a128678270824b6a1286a63863ca:
> >
> > Revert "ip_gre: make ipgre_tunnel_xmit() not parse network header as IP
On Mon, Mar 18, 2013 at 08:19:03PM +0100, Daniel Vetter wrote:
> On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
> > On Fri, 15 Mar 2013, Yinghai Lu wrote:
> >
> > > > Just a datapoint -- I have put a trivial debugging patch in place, and
> > > > it
> > > > reveals that "nobody cared
On Mon, Mar 18, 2013 at 03:38:38PM -0400, Eduardo Valentin wrote:
> On 18-03-2013 15:16, Dan Carpenter wrote:
> >On Mon, Mar 18, 2013 at 10:59:10AM -0400, Eduardo Valentin wrote:
> >>Even if the IRQ is not firing because it is ONE_SHOT and disable
> >>at INTC level, the IRQ handler must use spin_lo
On 03/18/2013 01:46:32 PM, Frederic Weisbecker wrote:
2013/3/18 Rob Landley :
> On 03/18/2013 11:29:42 AM, Paul E. McKenney wrote:
> And really seems like it's kconfig help text?
It's more exhaustive than a Kconfig help. A Kconfig help text should
have the level of detail that describe the purpo
On Mon, Mar 18, 2013 at 12:10:47PM -0700, H. Peter Anvin wrote:
> On 03/18/2013 08:33 AM, Vivek Goyal wrote:
> >
> > Thinking more about it, if ongoing DMA is an issue, then setting up
> > software iotlb in those areas is also prone to being overwritten by
> > those DMAs. Hence, reserving memory l
From: "Michael S. Tsirkin"
Date: Mon, 18 Mar 2013 21:54:43 +0200
> On Mon, Mar 18, 2013 at 01:01:36PM -0400, David Miller wrote:
>> From: "Michael S. Tsirkin"
>> Date: Mon, 18 Mar 2013 13:20:03 +0200
>>
>> > The following changes since commit
>> > 8c6216d7f118a128678270824b6a1286a63863ca:
>> >
Commit-ID: 66db3feb486c01349f767b98ebb10b0c3d2d021b
Gitweb: http://git.kernel.org/tip/66db3feb486c01349f767b98ebb10b0c3d2d021b
Author: CQ Tang
AuthorDate: Mon, 18 Mar 2013 11:02:21 -0400
Committer: H. Peter Anvin
CommitDate: Mon, 18 Mar 2013 11:32:03 -0700
x86-64: Fix the failure case
Em Tue, 26 Feb 2013 22:06:45 -0800
Andrey Smirnov escreveu:
> This patch adds all the functions used for exchanging commands with
> the chip.
Please run checkpatch.pl over those patches. There are a number of compliants
on those patches:
WARNING: externs should be avoided in .c files
#210: FILE
On Mon, Mar 18, 2013 at 11:05:26AM +0100, Daniel Vetter wrote:
> Hi Greg&all,
>
> So a recent stable backport to fix rc6 on ilk (which is disabled by
> default and with dubious power savings at best, unlike rc6 on snb and
> later) totally blew up all over the place:
> https://bugzilla.kernel.org/s
On Mar 18, 2013, at 8:47 AM, Sergey Gerasimov wrote:
> Signed-off-by: Sergey Gerasimov
> ---
> arch/powerpc/boot/dts/ib8315.dts | 490 +++
> arch/powerpc/configs/83xx/ib8315_defconfig | 2121
> arch/powerpc/platforms/83xx/Kconfig|7 +
> arch/p
On Thu, Mar 14, 2013 at 11:19:57PM +0100, Michael Leun wrote:
> Hello,
>
> On Thu, 14 Mar 2013 21:36:24 +0100
> Arkadiusz Miskiewicz wrote:
>
> > After upgrading from 3.8.2 to 3.8.3 I'm getting regression :
> [...]
> > 2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit
>
> I also
On Mon, 18 Mar 2013 10:51:54 +0800 "zhangwei(Jovi)"
wrote:
> +/* Needs a _much_ better name... */
> +#define FIX_SIZE(x) x) - 1) & PAGE_MASK) + PAGE_SIZE)
> +
Gad. That's the same as PAGE_ALIGN(), is it not?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Eric Wong wrote:
> Mathieu Desnoyers wrote:
> > I'm also not entirely sure why you need to add enum epoll_item_state
> > along with expensive atomic ops to compute the state. Wouldn't it be
> > enough to know in which queue the nodes are located ? If need be, you
> > could add new queues, e.g. o
Support 2M page allocations when memory is ballooned out of the
guest. Hyper-V Dynamic Memory protocol is optimized around the ability
to move memory in 2M chunks.
I have also included a patch to properly notify the host of permanent
hot-add failures.
In this version of the patches, I have added
This symbol would be used in the Hyper-V balloon driver to support 2M
allocations.
In this version of the patch, based on feedback from Michal Hocko
, I have updated the patch description.
Signed-off-by: K. Y. Srinivasan
---
mm/page_alloc.c |1 +
1 files changed, 1 insertions(+), 0 deletion
If memory hot-add fails with the error -EEXIST, then this is a permanent
failure. Notify the host of this information, so the host will not attempt
hot-add again. If the failure were a transient failure, host will attempt
a hot-add after some delay.
In this version of the patch, I have added some
On Hyper-V it will be very efficient to use 2M allocations in the guest as this
makes the ballooning protocol with the host that much more efficient. Hyper-V
uses page ranges (start pfn : number of pages) to specify memory being moved
around and with 2M pages this encoding can be very efficient. Ho
On Fri, Mar 15, 2013 at 4:35 PM, Vivek Goyal wrote:
> Do elf executable signature verification (if one is present). If signature
> is present, it should be valid. Validly signed files are given a capability
> CAP_SIGNED.
>
> If file is unsigned, it can execute but it does not get the capability
>
* Eric Wong (normalper...@yhbt.net) wrote:
> Mathieu Desnoyers wrote:
> > * Eric Wong (normalper...@yhbt.net) wrote:
> > > Eric Wong wrote:
> > > > I'm posting this lightly tested version since I may not be able to do
> > > > more testing/benchmarking until the weekend.
> > >
> > > Still lightly
On Mon, Mar 18, 2013 at 11:31:06AM -0400, Vlad Yasevich wrote:
> On 03/18/2013 11:25 AM, Eric Dumazet wrote:
> >On Mon, 2013-03-18 at 07:04 -0400, Neil Horman wrote:
> >
> >>I'm not sure why the process would never get back to the schedule, but
> >>looking
> >>at the sctp_remaddr_seq_show function
On Mon, Mar 18, 2013 at 04:23:11PM -0400, Josh Boyer wrote:
> On Fri, Mar 15, 2013 at 4:35 PM, Vivek Goyal wrote:
> > Do elf executable signature verification (if one is present). If signature
> > is present, it should be valid. Validly signed files are given a capability
> > CAP_SIGNED.
> >
> > I
On Mon, Mar 18, 2013 at 03:13:41PM -0400, John W. Linville wrote:
> Any comments from the ath9k folks?
>
> On Sat, Mar 16, 2013 at 12:38:14PM -0400, Parag Warudkar wrote:
> > During suspend below warning is seen when ath9k is active. Attached
> > patch fixes the warning for me. Tested to work acr
On 03/18/2013 04:32 PM, Neil Horman wrote:
On Mon, Mar 18, 2013 at 11:31:06AM -0400, Vlad Yasevich wrote:
On 03/18/2013 11:25 AM, Eric Dumazet wrote:
On Mon, 2013-03-18 at 07:04 -0400, Neil Horman wrote:
I'm not sure why the process would never get back to the schedule, but looking
at the sct
2013/3/18 Rob Landley :
> On 03/18/2013 01:46:32 PM, Frederic Weisbecker wrote:
>> I really think we want to keep all the detailed explanations from
>> Paul's doc. What we need is not a quick reference but a very detailed
>> documentation.
>
>
> It's much _longer_, I'm not sure it contains signific
On Mon, 2013-03-18 at 16:32 -0400, Neil Horman wrote:
> Vlads, right. We need to grab the rcu lock before the read lock, but we
> should
> probably use the rcu_read_lock_bh variant, since we're going to disable bottom
> halves anyway.
> Neil
rcu_read_lock_bh() and {local_bh_disable();rcu_read_l
On Wed, Mar 13, 2013 at 12:59:12PM +0800, Xiao Guangrong wrote:
> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> walk and zap all shadow pages one by one, also it need to zap all guest
> page's rmap and all shadow page's parent spte list. Particularly, things
> become wors
Hello!
This series contains the following changes to RCU documentation:
1. Make the bugginess of a code sample more apparent with
all-caps comments.
2. RCU documentation update based on review motivated by the
first commit.
From: "Paul E. McKenney"
This commit applies a few updates based on a quick review of the RCU
documentations.
Signed-off-by: Paul E. McKenney
---
Documentation/RCU/checklist.txt | 26 --
Documentation/RCU/lockdep.txt| 5 +
Documentation/RCU/rcubarrier.txt | 15
From: "Paul E. McKenney"
One of the code samples in whatisRCU.txt shows a bug, but someone scanning
the document quickly might mistake it for a valid use of RCU. Add some
screaming comments to help keep speed-readers on track.
Reported-by: Nathan Zimmer
Signed-off-by: Paul E. McKenney
Acked-b
Masami Hiramatsu writes:
> Thank you for reporting!!
Thanks for fixing these! I spent some time trying to automate the
process of finding sensitive functions and eventually resorted into
booting a kvm instance with a minimal initrd to test every single
function in a clean and reproducible environ
On Sat, 16 Mar 2013 17:54:47 + Al Viro wrote:
> On Sat, Mar 16, 2013 at 06:50:44AM -0700, Joe Perches wrote:
> > Instead of converting the 800 or so uses of seq_printf with
> > a constant format (without a % substitution) to seq_puts,
> > maybe there's another way to slightly speed up these o
On Mon, Mar 18, 2013 at 01:15:51PM -0700, Mike Turquette wrote:
> Quoting Ulf Hansson (2013-02-28 01:54:34)
> > On 28 February 2013 05:49, Mike Turquette wrote:
> > > @@ -703,10 +744,29 @@ int clk_enable(struct clk *clk)
> > > unsigned long flags;
> > > int ret;
> > >
> > > +
On Mon, 2013-03-18 at 13:35 +0800, Asias He wrote:
> On Sat, Mar 16, 2013 at 02:10:22AM +, Ben Hutchings wrote:
> > On Tue, 2013-03-12 at 15:44 -0700, Greg Kroah-Hartman wrote:
> > > 3.0-stable review patch. If anyone has any objections, please let me
> > > know.
> > >
> > >
This is the start of the stable review cycle for the 3.8.4 release.
There are 75 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 made by Wed Mar 20 21:04:55 UTC 2013.
Anything received
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: "Maxin B. John"
commit a0f11aceee531d444f58b939e6a537ee5e2b9cc5 upstream.
Fixes this build failure:
gcc -Wall -Wextra -g -lpthread -I../include -o testusb testusb.c
gcc -Wall -Wextra -g -lpthre
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Marcin Jurkowski
commit 9d1817cab2f030f6af360e961cc69bb1da8ad765 upstream.
On Sat, Mar 02, 2013 at 10:45:10AM +0100, Sven Geggus wrote:
> This is the bad commit I found doing git bisect:
> 04f4
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit 2a6e06b2aed6995af401dcd4feb5e79a0c7ea554 upstream.
Commit 1d9d8639c063 ("perf,x86: fix kernel crash with PEBS/BTS after
suspend/resume") fixed a crash when doing PEBS perf
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Mathias Krause
[ Upstream commit 29cd8ae0e1a39e239a3a7b67da1986add1199fc0 ]
The dcb netlink interface leaks stack memory in various places:
* perm_addr[] buffer is only filled at max with 12 o
This is the start of the stable review cycle for the 3.4.37 release.
There are 48 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 made by Wed Mar 20 21:07:59 UTC 2013.
Anything receive
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Wang YanQing
commit 8d2f8cd424ca0b99001f3ff4f5db87c4e525f366 upstream.
01:08.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O
Controller (rev 01)
Subsystem: Device [100
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Benjamin Herrenschmidt
commit 13938117a57f88a22f0df9722a5db7271fda85cd upstream.
Commit f5339277eb8d3aed37f12a27988366f68ab68930 accidentally removed
more than just iSeries bits and took out th
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Guillaume Nault
[ Upstream commit 8b82547e33e85fc24d4d172a93c796de1fefa81a ]
The sendmsg() syscall handler for PPPoL2TP doesn't decrease the socket
reference counter after successful transmiss
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Guo Chao
commit b1a6650406875b9097a032eed89af50682fe1160 upstream.
When loopdev is built as module and we pass an invalid parameter,
loop_init() will return directly without deregister misc dev
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit f8af75f3517a24838a36eb5797a1a3e60bf9e276 ]
Dave reported following crash :
general protection fault: [#1] SMP
CPU 2
Pid: 25407, comm: qemu-kvm Not tainted
401 - 500 of 926 matches
Mail list logo
