On Fri, 19 Apr 2013, Joe Perches wrote:
> @@ -966,11 +934,13 @@ static int realtek_cr_autosuspend_setup(struct us_data
> *us)
> static void realtek_cr_destructor(void *extra)
> {
> struct rts51x_chip *chip = (struct rts51x_chip *)extra;
> -
> - US_DEBUGP("%s: <---\n", __func__);
> +
On Wed, 12 Jun 2013, Michal Hocko wrote:
> > > > > > > Reported-by: Reported-by: azurIt
> >
> > Ok, so the key here is that azurIt was able to reliably reproduce this
> > issue and now it has been resurrected after seven months of silence since
> > that thread. I also notice that azurIt isn't
ang Yanfei
Acked-by: David Rientjes
--
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 http://www.tux.org/lkml/
On Wed, 12 Jun 2013, Michal Hocko wrote:
> The patch is a big improvement with a minimum code overhead. Blocking
> any task which sits on top of an unpredictable amount of locks is just
> broken. So regardless how many users are affected we should merge it and
> backport to stable trees. The probl
On Wed, 12 Jun 2013, Michal Hocko wrote:
> But the objective is to handle oom deadlocks gracefully and you cannot
> possibly miss those as they are, well, _deadlocks_.
That's not at all the objective, the changelog quite explicitly states
this is a deadlock as the result of userspace having disa
On Thu, 13 Jun 2013, Michal Hocko wrote:
> > Right now it appears that that number of users is 0 and we're talking
> > about a problem that was reported in 3.2 that was released a year and a
> > half ago. The rules of inclusion in stable also prohibit such a change
> > from being backported, s
On Thu, 13 Jun 2013, Michal Hocko wrote:
> > That's not at all the objective, the changelog quite explicitly states
> > this is a deadlock as the result of userspace having disabled the oom
> > killer so that its userspace oom handler can resolve the condition and it
> > being unresponsive or u
On Fri, 14 Jun 2013, Kamezawa Hiroyuki wrote:
> Reading your discussion, I think I understand your requirements.
> The problem is that I can't think you took into all options into
> accounts and found the best way is this new oom_delay. IOW, I can't
> convice oom-delay is the best way to handle yo
On Fri, 14 Jun 2013, Christoph Lameter wrote:
> > It's possible to avoid such problems (or at least to make them less
> > probable)
> > by avoiding direct compaction. If it's not possible to allocate a contiguous
> > page without compaction, slub will fall back to order 0 page(s). In this
> > ca
On Sat, 15 Jun 2013, Zhang Yanfei wrote:
> From: Zhang Yanfei
>
> Since we have an unlikely for the "current_order >= pageblock_order / 2"
> test above, adding an unlikely for this "current_order >= pageblock_order"
> test seems more appropriate.
>
I don't understand the justification at all,
On Sun, 16 Jun 2013, Rusty Russell wrote:
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 79e451a..f9b9cd7 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -288,7 +288,7 @@ enum oom_scan_t oom_scan_process_thread(struct
> task_struct *task,
>
> /*
> * Simple selection loop. We ch
On Tue, 4 Jun 2013, Michal Hocko wrote:
> > I'm not sure a userspace oom notifier would want to keep a
> > preallocated buffer around that is mlocked in memory for all possible
> > lengths of this file.
>
> Well, an oom handler which allocates memory under the same restricted
> memory doesn't mak
On Wed, 5 Jun 2013, Michal Hocko wrote:
> > For the aforementioned reason that we give users the ability to manipulate
> > their own memcg trees and userspace is untrusted. Their oom notifiers
> > cannot be run as root, not only because of security but also because it
> > would not properly is
On Wed, 5 Jun 2013, Johannes Weiner wrote:
> Since '1c0fe6e mm: invoke oom-killer from page fault', page fault
> handlers should not directly kill faulting tasks in an out of memory
> condition.
I have no objection to the patch, but there's no explanation given here
why exiting with a kill shoul
On Wed, 5 Jun 2013, Johannes Weiner wrote:
> The memcg OOM handling is incredibly fragile because once a memcg goes
> OOM, one task (kernel or userspace) is responsible for resolving the
> situation.
Not sure what this means. Are you referring to the case where the memcg
is disabled from oom ki
On Wed, 5 Jun 2013, Johannes Weiner wrote:
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index ff7b40d..d169a8d 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -187,10 +187,6 @@ struct mem_cgroup_per_node {
> struct mem_cgroup_per_zone zoneinfo[MAX_NR_ZONES];
> };
>
> -st
rs are supposed to call
> to invoke the OOM killer and let it pick the right task to kill.
> Convert the remaining architectures over to this hook.
>
> To have the previous behavior of simply taking out the faulting task
> the vm.oom_kill_allocating_task sysctl can be set to 1.
>
s OOM waitqueue or just
>restart the fault. The OOM victim can no longer get stuck on any
>lock a sleeping task may hold.
>
> While reworking the OOM routine, also remove a needless OOM waitqueue
> wakeup when invoking the killer. Only uncharges and limit increases,
> things
ver hit it.
Perhaps the answer is solely the stacktraces in your changelog, so I'd be
happy to review that separately from my patch.
> > > Reported-by: Reported-by: azurIt
> > > Debugged-by: Michal Hocko
> > > Reported-by: David Rientjes
> >
> &g
On Mon, 17 Jun 2013, Zhang Yanfei wrote:
> > I don't understand the justification at all, current_order being unlikely
> > greater than or equal to pageblock_order / 2 doesn't imply at all that
> > it's unlikely that current_order is greater than or equal to
> > pageblock_order.
> >
>
> hmmm.
On Mon, 17 Jun 2013, Roman Gushchin wrote:
> > FWIW, there were some compaction locking related patches merged
> > around 3.7. See 2a1402aa044b55c2d30ab0ed9405693ef06fb07c and follow ups.
>
> Thanks, Michal.
> I've already tried to backport some of those patches, but it didn't help
> (may be it w
2
> is 4. For the first eight iterations, it's guaranteed that
> current_order >= pageblock_order / 2 if it even gets that far!
>
> So just remove the unlikely(), it's completely bogus.
>
> Suggested-by: David Rientjes
> Signed-off-by: Zhang Yanfei
Acked-by:
On Tue, 18 Jun 2013, Alex Thorlton wrote:
> Thanks for your input, however, I believe the method of using a malloc
> hook falls apart when it comes to static binaries, since we wont' have
> any shared libraries to hook into. Although using a malloc hook is a
> perfectly suitable solution for most
On Wed, 19 Jun 2013, Robin Holt wrote:
> The convenience being that many batch schedulers have added cpuset
> support. They create the cpuset's and configure them as appropriate
> for the job as determined by a mixture of input from the submitting
> user but still under the control of the adminis
On Fri, 14 Jun 2013, David Rientjes wrote:
> Even with all of the above (which is not actually that invasive of a
> patch), I still think we need memory.oom_delay_millisecs. I probably made
> a mistake in describing what that is addressing if it seems like it's
> trying to a
On Wed, 19 Jun 2013, Robin Holt wrote:
> cpusets was not for NUMA. It has no preference for "nodes" or anything like
> that. It was for splitting a machine into layered smaller groups. Usually,
> we see one cpuset with contains the batch scheduler. The batch scheduler then
> creates cpusets fo
On Thu, 20 Jun 2013, Mike Galbraith wrote:
> > I'm suspecting that you're referring to enlarged rss because of
> > khugepaged's max_ptes_none and because you're abusing the purpose of
> > cpusets for containerization.
>
> Why is containerization an abuse? What's wrong with renting out chunks
>
oom delay has expired, all
future oom kills in that memcg will continue without incurring any delay.
When a memory.oom_delay_millisecs is set for a cgroup, it is propagated
to all children memcg as well and is inherited when a new memcg is
created.
Signed-off-by: David Rientjes
---
Documentat
On Thu, 30 May 2013, Michal Hocko wrote:
> > Completely disabling the oom killer for a memcg is problematic if
> > userspace is unable to address the condition itself, usually because it
> > is unresponsive.
>
> Isn't this a bug in the userspace oom handler? Why is it unresponsive? It
> shouldn'
On Fri, 31 May 2013, Michal Hocko wrote:
> I have always discouraged people from running oom handler in the same
> memcg (or even in the same hierarchy).
>
We allow users to control their own memcgs by chowning them, so they must
be run in the same hierarchy if they want to run their own usersp
On Fri, 31 May 2013, Michal Hocko wrote:
> > We allow users to control their own memcgs by chowning them, so they must
> > be run in the same hierarchy if they want to run their own userspace oom
> > handler. There's nothing in the kernel that prevents that and the user
> > has no other option
On Fri, 31 May 2013, Andrew Morton wrote:
> > Admins may set the oom killer delay using the new interface:
> >
> > # echo 6 > memory.oom_delay_millisecs
> >
> > This will defer oom killing to the kernel only after 60 seconds has
> > elapsed by putting the task to sleep for 60 seconds.
>
On Sat, 1 Jun 2013, Michal Hocko wrote:
> > Users obviously don't have the ability to attach processes to the root
> > memcg. They are constrained to their own subtree of memcgs.
>
> OK, I assume those groups are generally untrusted, right? So you cannot
> let them register their oom handler ev
On Mon, 3 Jun 2013, Johannes Weiner wrote:
> > It's not necessarily harder if you assign the userspace oom handlers to
> > the root of your subtree with access to more memory than the children.
> > There is no "inability" to write a proper handler, but when you have
> > dozens of individual us
On Mon, 3 Jun 2013, Michal Hocko wrote:
> > What do you suggest when you read the "tasks" file and it returns -ENOMEM
> > because kmalloc() fails because the userspace oom handler's memcg is also
> > oom?
>
> That would require that you track kernel allocations which is currently
> done only f
On Mon, 24 Jun 2013, Wanpeng Li wrote:
> This patch shares s_next and s_stop between slab and slub.
>
Just about the entire kernel includes slab.h, so I think you'll need to
give these slab-specific names instead of exporting "s_next" and "s_stop"
to everybody.
--
To unsubscribe from this list
On Mon, 10 Jun 2013, Michal Hocko wrote:
> > > > I don't think you yet understand the problem, which is probably my
> > > > fault.
> > > > I'm not insisting this be implemented in the kernel, I'm saying it's
> > > > not
> > > > possible to do it in userspace.
> > >
> > > Because you still
On Thu, 6 Jun 2013, Johannes Weiner wrote:
> > Could you point me to those bug reports? As far as I know, we have never
> > encountered them so it would be surprising to me that we're running with a
> > potential landmine and have seemingly never hit it.
>
> Sure thing: https://lkml.org/lkml/2
On Tue, 11 Jun 2013, Christoph Lameter wrote:
> > I think that leaving the warning makes sense to catch similar
> > things which are actually bugs - we had a similar issue with
> > /dev/kmsg (if I remember correctly) which actually pointed to
> > a bug.
>
> Right. Requesting an allocation larger
On Tue, 11 Jun 2013, Alex Thorlton wrote:
> This patch adds the ability to control THPs on a per cpuset basis. Please see
> the additions to Documentation/cgroups/cpusets.txt for more information.
>
What's missing from both this changelog and the documentation you point to
is why this change i
On Tue, 25 Jun 2013, Kamezawa Hiroyuki wrote:
> Considering only memcg, bypassing all charge-limit-check will work.
> But as you say, that will not work against global-oom.
I think it will since we have per-zone memory reserves that can be
bypassed in the page allocator, not to the level of PF_M
On Thu, 27 Jun 2013, Roman Gushchin wrote:
> > They certainly aren't enough, the kernel you're running suffers from a
> > couple different memory compaction issues that were fixed in 3.7. I
> > couldn't sympathize with your situation more, I faced the same issue
> > because of thp and not slub (w
On Thu, 21 Mar 2013, Ingo Molnar wrote:
> > Index: linux/mm/page_alloc.c
> > ===
> > --- linux.orig/mm/page_alloc.c 2013-03-18 10:52:11.510988843 -0500
> > +++ linux/mm/page_alloc.c 2013-03-18 10:52:14.214931348 -0500
> > @@ -4
FIG_MFD_CORE anytime CONFIG_MFD_CROS_EC is enabled.
Signed-off-by: David Rientjes
---
drivers/mfd/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -23,6 +23,7 @@ config MFD_88PM860X
On Thu, 21 Mar 2013, Herbert Xu wrote:
> > This patch adds CONFIG_PM_SLEEP to suspend/resume functions to fix
> > the following build warning when CONFIG_PM_SLEEP is not selected.
> >
> > drivers/char/hw_random/exynos-rng.c:147:12: warning:
> > 'exynos_rng_runtime_suspend' defined but not used [
On Fri, 22 Mar 2013, CAI Qian wrote:
> Starting to see those on 3.8.4 (never saw in 3.8.2) stable kernel on a few
> systems
> during LTP run,
>
> [11297.597242] BUG: unable to handle kernel paging request at
> fffe
> [11297.598022] IP: [] kmem_cache_alloc+0x68/0x1e0
Is this repea
.c:167:8: error:
> 'exynos_rng_runtime_suspend' undeclared here (not in a function)
> drivers/char/hw_random/exynos-rng.c:167:8: error: 'exynos_rng_runtime_resume'
> undeclared here (not in a function)
>
> Signed-off-by: Jingoo Han
> Reported-by: David Rientjes
> Cc: Herbert Xu
On Sat, 23 Mar 2013, KOSAKI Motohiro wrote:
> > --- linux.orig/mm/page_alloc.c 2013-03-19 16:09:03.736450861 -0500
> > +++ linux/mm/page_alloc.c 2013-03-22 17:07:43.895405617 -0500
> > @@ -4161,10 +4161,23 @@ int __meminit __early_pfn_to_nid(unsigne
> > {
> > unsigned long start_pf
On Mon, 25 Mar 2013, Andrew Morton wrote:
> > Um, defining them in a __meminit function places them in .meminit.data
> > already.
>
> I wish it did, but it doesn't.
>
$ objdump -t mm/page_alloc.o | grep last_start_pfn
0240 l O .meminit.data 0008 last_start_pfn.3434
On Mon, 12 Aug 2013, Mark Rutland wrote:
> > static void __init msm_smp_prepare_cpus(unsigned int max_cpus)
> > {
> > + int cpu, map;
> > + unsigned int flags = 0;
> > +
> > + for_each_present_cpu(cpu) {
> > + map = cpu_logical_map(cpu);
> > + if (map > ARRAY_SIZE(cold_
falls back to
using regular pages and only count thp_fault_alloc when a hugepage has
actually been faulted.
Signed-off-by: David Rientjes
---
mm/huge_memory.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
--- a/mm/huge_memory.c
+++
falls back to
using regular pages and only count thp_fault_alloc when a hugepage has
actually been faulted.
Signed-off-by: David Rientjes
---
mm/huge_memory.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
--- a/mm/huge_memory.c
On Wed, 21 Aug 2013, Kirill A. Shutemov wrote:
> David Rientjes wrote:
> > Currently, thp_fault_fallback in vmstat only gets incremented if a
> > hugepage allocation fails. If current's memcg hits its limit or the page
> > fault handler returns an error, it is
On Tue, 6 Aug 2013, Alex Thorlton wrote:
> I've gotten my hands on some of the benchmarks/code that were used to
> originally uncover the performance issues we're seeing. I'm currently
> trying to separate out the performance issues that are being caused by
> the kernel code from issues involving
On Fri, 1 Mar 2013, li guang wrote:
> can anyone help to merge these patches?
> or any other comments?
>
If you run scripts/get_maintainer.pl on your series, it will point you to
the relevant parties.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Fri, 1 Mar 2013, Michal Hocko wrote:
> I have already asked about it in the original thread but didn't get any
> answer. How can we get a soft lockup when all implementations of show_mem
> call touch_nmi_watchdog?
>
Feel free to do s/soft lockups/irqs being disabled for an extremely long
tim
drivers/usb/gadget/configfs.c: In function 'configfs_do_nothing':
drivers/usb/gadget/configfs.c:733:2: error: implicit declaration of
function '__WARN'
Reported-by: Randy Dunlap
Signed-off-by: David Rientjes
---
drivers/usb/gadget/configfs.c | 4 ++--
1 fi
On Wed, 27 Mar 2013, Kent Overstreet wrote:
> Nope - looks like __WARN() doesn't exist if CONFIG_BUG=n, whoops.
>
> Adding this to the queue:
>
> commit 796c213186b850b3e6e8d5fd5799b0fd74721ea3
> Author: Kent Overstreet
> Date: Wed Mar 27 12:47:45 2013 -0700
>
> bcache: Use WARN_ONCE() i
.
This patch truncates the string to the first TASK_COMM_LEN bytes and
returns the bytes written as the length of the string written so the
second write() is suppressed.
$ cat /proc/$$/comm
abcdefghijklmno
Signed-off-by: David Rientjes
---
fs/proc/base.c | 5 ++---
1 fi
On Mon, 8 Apr 2013, Toshi Kani wrote:
> > So we don't need this new code if CONFIG_MEMORY_HOTPLUG=n? If so, can
> > we please arrange for it to not be present if the user doesn't need it?
>
> Good point! Yes, since the new function is intended for memory
> hot-delete and is only called from __r
werpc, including x86). remove_memory_block()
becomes static since it is not referenced outside of
drivers/base/memory.c.
Build tested on x86 and powerpc with CONFIG_MEMORY_HOTREMOVE both enabled
and disabled.
Signed-off-by: David Rientjes
---
arch/powerpc/platforms/pseries/hotplug-memory.c
ly while the resource_lock is
> held.
>
> Signed-off-by: Toshi Kani
> Reviewed-by: Yasuaki Ishimatsu
Acked-by: David Rientjes
--
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
On Mon, 8 Apr 2013, Toshi Kani wrote:
> Added release_mem_region_adjustable(), which releases a requested
> region from a currently busy memory resource. This interface
> adjusts the matched memory resource accordingly even if the
> requested region does not match exactly but still fits into.
>
On Thu, 11 Apr 2013, Srivatsa S. Bhat wrote:
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index ede2749..2489042 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -948,9 +948,7 @@ extern struct zone *next_zone(struct zone *zone);
> for (zone = (fir
cked-by: Konstantin Khlebnikov
> Acked-by: Michal Hocko
> Reviewed-by: Rik van Riel
> Acked-by: KOSAKI Motohiro
> Cc: sta...@vger.kernel.org
Acked-by: David Rientjes
Stable for 3.7+.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
: KOSAKI Motohiro
> Cc: sta...@vger.kernel.org
Acked-by: David Rientjes
Stable for 2.6.34+.
--
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 http://www.tux.org/lkml/
r hwpoisoned ones.
>
> ChangeLog v5:
> - improve comment and description.
>
> ChangeLog v4:
> - move is_swap_page() to right place.
>
> ChangeLog v3:
> - add comment about using is_swap_pte()
>
> Signed-off-by: Naoya Horiguchi
> Cc: sta...@vger.kern
On Wed, 10 Apr 2013, Toshi Kani wrote:
> > I'll switch it to GFP_ATOMIC. Which is horridly lame but the
> > allocation is small and alternatives are unobvious.
>
> Great! Again, thanks for the update!
release_mem_region_adjustable() allocates at most one struct resource, so
why not do kmalloc
ceed as it was the case
> with release_mem_region(). release_mem_region(), which is defined
> to __release_region(), emits a warning message and returns no error
> since a void function.
>
> Signed-off-by: Toshi Kani
> Reviewed-by : Yasuaki Ishimatsu
Acked-by: David Rientjes
On Wed, 10 Apr 2013, KOSAKI Motohiro wrote:
> >Just for the record. It should be stable for 3.7+ since (314e51b98)
> >becuase then have lost VM_RESERVED check which used to stop hugetlb
> >mappings.
Ah, that's subtle, thanks for pointing it out. Andrew, please annotate
this only for 3.7+.
--
To
On Wed, 10 Apr 2013, Rasmus Villemoes wrote:
> In madvise(), there doesn't seem to be any reason for taking the
> ¤t->mm->mmap_sem before start and len_in have been
> validated. Incidentally, this removes the need for the out: label.
>
>
> Signed-off-by: Rasmu
On Tue, 30 Apr 2013, Vincent Stehlé wrote:
> diff --git a/include/linux/memory.h b/include/linux/memory.h
> index 73817af..85c31a8 100644
> --- a/include/linux/memory.h
> +++ b/include/linux/memory.h
> @@ -137,7 +137,7 @@ enum mem_add_context { BOOT, HOTPLUG };
> #define register_hotmemory_notifi
On Mon, 29 Apr 2013, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix build error when CONFIG_PROC_FS is not enabled:
> (remove duplicated line)
>
> include/linux/proc_fs.h:58:20: error: redefinition of 'proc_set_size'
> include/linux/proc_fs.h:51:20: note: previous definition of 'proc_set_size
nclude/linux/tty.h: In function 'proc_tty_unregister_driver':
> include/linux/tty.h:699:54: error: parameter name omitted
>
> Signed-off-by: Randy Dunlap
Acked-by: David Rientjes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
On Tue, 30 Apr 2013, Andrew Morton wrote:
> > > diff --git a/include/linux/memory.h b/include/linux/memory.h
> > > index 73817af..85c31a8 100644
> > > --- a/include/linux/memory.h
> > > +++ b/include/linux/memory.h
> > > @@ -137,7 +137,7 @@ enum mem_add_context { BOOT, HOTPLUG };
> > > #define re
On Wed, 1 May 2013, Cliff Wickman wrote:
> Index: linux/mm/pagewalk.c
> ===
> --- linux.orig/mm/pagewalk.c
> +++ linux/mm/pagewalk.c
> @@ -127,22 +127,6 @@ static int walk_hugetlb_range(struct vm_
> return 0;
> }
>
> -static
On Wed, 1 May 2013, Robert Love wrote:
> Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into the
> shrinker code from within ashmem. Just bail out, avoiding a deadlock. This is
> fine, as ashmem cache pruning is advisory anyhow.
>
> Signed-off-by: Robert Love
Any reason n
On Wed, 1 May 2013, Shawn Bohrer wrote:
> I've got two compute clusters with around 350 machines each which are
> running kernels based off of 3.1.9 (Yes I realize this is ancient by
> todays standards). All of the machines run a 'find' command once an
> hour on one of the mounted XFS filesystems
On Wed, 1 May 2013, Shawn Bohrer wrote:
> Correct it doesn't and I can't prove the find command is not making
> progress, however these finds normally complete in under 15 min and
> we've let the stuck ones run for days. Additionally if this was just
> contention I'd expect to see multiple thread
On Wed, 1 May 2013, Cliff Wickman wrote:
> > > @@ -200,28 +184,46 @@ int walk_page_range(unsigned long addr,
> > >
> > > pgd = pgd_offset(walk->mm, addr);
> > > do {
> > > - struct vm_area_struct *vma;
> > > + struct vm_area_struct *vma = NULL;
> > >
> > > next =
On Tue, 30 Apr 2013, tip-bot for Borislav Petkov wrote:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 15b5cef..1d053dc 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -633,6 +633,45 @@ config KVM_GUEST
> underlying device model, the host provides the guest with
>
On Wed, 1 May 2013, Yann E. MORIN wrote:
> > When CONFIG_SND=m and CONFIG_SND_AC97_CODEC=m and
> > CONFIG_VIDEO_STK1160=y
> > CONFIG_VIDEO_STK1160_AC97=y
> >
> > drivers/built-in.o: In function `stk1160_ac97_register':
> > (.text+0x122706): undefined reference to `snd_card_create'
> > drivers/bui
On Wed, 1 May 2013, Randy Dunlap wrote:
> >>> When CONFIG_SND=m and CONFIG_SND_AC97_CODEC=m and
> >>> CONFIG_VIDEO_STK1160=y
> >>> CONFIG_VIDEO_STK1160_AC97=y
> >>>
> >>> drivers/built-in.o: In function `stk1160_ac97_register':
> >>> (.text+0x122706): undefined reference to `snd_card_create'
> >>>
On Wed, 1 May 2013, Borislav Petkov wrote:
> ---
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e8fff2f4ecb7..4f8ef85b0633 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -389,7 +389,8 @@ config X86_VSMP
> bool "ScaleMP vSMP"
> select HYPERVISOR_GUEST
>
On Wed, 1 May 2013, Borislav Petkov wrote:
> > warning: (KVM_GUEST_COMMON_OPTIONS) selects VIRTIO_NET which has unmet
> > direct dependencies (NETDEVICES && NET_CORE && VIRTIO)
> >
> > and
> >
> > warning: (KVM_GUEST_COMMON_OPTIONS && AMD_IOMMU) selects PCI_MSI which has
> > unmet direct depen
On Wed, 1 May 2013, Borislav Petkov wrote:
> $ make allnoconfig
> HOSTCC scripts/basic/fixdep
> SHIPPED scripts/kconfig/zconf.tab.c
> SHIPPED scripts/kconfig/zconf.lex.c
> HOSTCC scripts/kconfig/conf.o
> SHIPPED scripts/kconfig/zconf.hash.c
> HOSTCC scripts/kconfig/zconf.tab.o
> H
On Wed, 1 May 2013, Cody P Schafer wrote:
> All updaters of pgdat size (spanned_pages, start_pfn, and
> present_pages) currently also hold lock_memory_hotplug() (in addition
> to pgdat_resize_lock()).
>
> Document this and make holding of that lock a requirement on the update
> side for now, but
On Wed, 1 May 2013, Cody P Schafer wrote:
> Signed-off-by: Cody P Schafer
Acked-by: David Rientjes
--
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/majord
On Wed, 1 May 2013, Cody P Schafer wrote:
> Signed-off-by: Cody P Schafer
Nack, pgdat_resize_unlock() is unnecessary if irqs are known to be
disabled.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Wed, 1 May 2013, Cody P Schafer wrote:
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index a221fac..0bdca10 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -915,6 +915,7 @@ static void node_states_set_node(int node, struct
> memory_notify *arg)
>
> int __ref
On Thu, 2 May 2013, Borislav Petkov wrote:
> Ok, so let's step back a bit here: I've added this option with the idea
> to have it as a shortcut so that you don't go search for every commodity
> option when you want to boot the kernel as a kvm guest. Currently I have
> it in all.config when doing r
On Wed, 1 May 2013, Cody P Schafer wrote:
> They are also initialized at boot without pgdat_resize_lock(), if we consider
> boot time, quite a few of the statements on when locking is required are
> wrong.
>
> That said, you are correct that it is not strictly required to hold
> lock_memory_hotpl
On Wed, 1 May 2013, Cody P Schafer wrote:
> > > Signed-off-by: Cody P Schafer
> >
> > Nack, pgdat_resize_unlock() is unnecessary if irqs are known to be
> > disabled.
> >
>
> All this patch does is is indicate that rather than using node_size_lock
> directly (as it won't be around without CONF
On Wed, 1 May 2013, Cody P Schafer wrote:
> Guaranteed to be stable means that if I'm a reader and pgdat_resize_lock(),
> node_present_pages had better not change at all until I pgdat_resize_unlock().
>
> If nothing needs this guarantee, we should change the rules of
> pgdat_resize_lock(). I play
On Thu, 2 May 2013, Borislav Petkov wrote:
> > It means your patch is incomplete.
>
> I'll gladly test and ack a patch which makes it complete.
>
> Simple exercises in rhetoric about what does and what doesn't make sense
> means a rat's ass to me. You need to show me a *real* use case which you
On Thu, 2 May 2013, Borislav Petkov wrote:
> See, we could've saved ourselves all the bullshit if you had started
> with the above.
>
I had thought
warning: (KVM_GUEST_COMMON_OPTIONS && AMD_IOMMU) selects PCI_MSI which has
unmet direct dependencies (PCI && ARCH_SUPPORTS_MSI)
was obvious.
>
On Thu, 2 May 2013, Ingo Molnar wrote:
> > It's an allnoconfig with HYPERVISOR_GUEST, PARAVIRT, KVM_GUEST, and
> > KVM_GUEST_COMMON_OPTIONS enabled.
>
> Please send a specific .config instead, with which you see warnings or
> build failures.
>
Attached from my earlier email to Borislav on lkm
On Thu, 2 May 2013, tip-bot for Borislav Petkov wrote:
> Commit-ID: 7e0320e733eec67e40d2b53e438d9971f079862d
> Gitweb: http://git.kernel.org/tip/7e0320e733eec67e40d2b53e438d9971f079862d
> Author: Borislav Petkov
> AuthorDate: Fri, 26 Apr 2013 11:51:40 +0200
> Committer: H. Peter Anvin
On Thu, 2 May 2013, H. Peter Anvin wrote:
> Let's drop this one for right now. I need to queue up some actual
> urgent fixes...
>
Sounds good. I think what you eluded to earlier, a "select" that resolves
dependencies on the symbols it enables, would be the best way to implement
something lik
On Wed, 1 May 2013, David Rientjes wrote:
> > Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed into
> > the
> > shrinker code from within ashmem. Just bail out, avoiding a deadlock. This
> > is
> > fine, as ashmem cache pruning is
401 - 500 of 3171 matches
Mail list logo
