On Wed, Nov 28, 2012 at 12:56:10PM +0100, Hans Verkuil wrote:
> On Wed 28 November 2012 12:45:37 Dan Carpenter wrote:
> > I wish people wouldn't submit big patches right before the merge
> > window opens... :/ It's better to let it sit in linux-next for a
> > couple weeks so people can mess with i
On Wed, Nov 28, 2012 at 04:25:32PM +0530, Prabhakar Lad wrote:
> From: Manjunath Hadli
>
> enable PPCR, enbale ISIF out on BCR and disable all events to
> get the correct operation from ISIF.
>
> Signed-off-by: Manjunath Hadli
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/platform/dav
On Wed, Nov 28, 2012 at 12:03 PM, Linus Torvalds
wrote:
>
> mmap() is in *no* way special. The exact same thing happens for
> regular read/write. Yet somehow the mmap code is special-cased, while
> the normal read-write code is not.
I just double-checked, because it's been a long time since I act
On Sat, Nov 17, 2012 at 4:47 AM, Pandarathil, Vijaymohan R
wrote:
> When an error is detected on a PCIe device which does not have an
> AER-aware driver, prevent AER infrastructure from reporting
> successful error recovery.
>
> This is because the report_error_detected() function that gets
> call
The cgroup_event_wake() function is called with the wait queue head
locked and it takes cgrp->event_list_lock. However, in cgroup_rmdir()
remove_wait_queue() was being called after taking
cgrp->event_list_lock. Correct the lock ordering by using a temporary
list to obtain the event list to remove
On Wed, Nov 28, 2012 at 9:50 AM, Konrad Rzeszutek Wilk
wrote:
>> /*
>> - * Iterate through E820 memory map and create direct mappings for only
>> E820_RAM
>> - * regions. We cannot simply create direct mappings for all pfns from
>> - * [0 to max_low_pfn) and [4GB to max_pfn) because of possible
Hi Prabhakar,
On Wed, Nov 28, 2012 at 04:25:33PM +0530, Prabhakar Lad wrote:
> From: Manjunath Hadli
>
> request_mem_region for VPSS_CLK_CTRL register and ioremap.
> and enable clocks appropriately.
>
> Signed-off-by: Manjunath Hadli
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/plat
On Tue, Nov 27, 2012 at 07:28:43PM +0100, Krzysztof Mazur wrote:
>
> While reviewing your br2684 patch I also found that some ATM drivers does
> not call ->pop() when ->send() fails, they should do:
>
> if (vcc->pop)
> vcc->pop(vcc, skb);
> else
> dev_kfree
On Wed, 28 Nov 2012, Michal Hocko wrote:
> From e21bb704947e9a477ec1df9121575c606dbfcb52 Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Wed, 28 Nov 2012 17:46:32 +0100
> Subject: [PATCH] memcg: do not trigger OOM from add_to_page_cache_locked
>
> memcg oom killer might deadlock if the proc
On Wednesday, November 28, 2012 06:27:50 PM Zdenek Kabelac wrote:
> Dne 28.11.2012 18:02, Linus Torvalds napsal(a):
> > On Wed, Nov 28, 2012 at 8:21 AM, Zdenek Kabelac wrote:
> >>
> >> I've opened https://bugzilla.kernel.org/show_bug.cgi?id=51071
> >> and attached picture there which is all I hav
On Fri, Nov 23, 2012 at 7:20 PM, Arnaldo Carvalho de Melo
wrote:
> Hi Ingo,
>
> Tested using a cross-compiler and directly on a Raspberry pi (ARM)
> with
> raspbian.
>
> Please consider pulling.
>
> - Arnaldo
>
> The following changes since commit 18423d3562f396206e0928a71177eeb2e
On Wed, 28 Nov 2012 14:51:59 + Tvrtko Ursulin
wrote:
> On Tuesday 27 November 2012 12:05:28 NeilBrown wrote:
> > On Sat, 24 Nov 2012 10:18:44 +0100 Torsten Kaiser
> >
> > wrote:
> > > After my system got stuck with 3.7.0-rc2 as reported in
> > > http://marc.info/?l=linux-kernel&m=1351422365
On Wed, Nov 28, 2012 at 11:50:25AM -0800, H. Peter Anvin wrote:
> From: "H. Peter Anvin"
>
> All 486+ CPUs support CMPXCHG, so remove the fallback 386 support
> code.
This commit message should say something about XADD and not about
CMPXCHG, right?
--
Regards/Gruss,
Boris.
--
To unsubscrib
Looks correct.
Vijay
> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Wednesday, November 28, 2012 12:15 PM
> To: Pandarathil, Vijaymohan R
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> linasveps...@gmail.com; Myron Stowe; Ortiz, Lance E;
On Wed, Nov 28, 2012 at 12:13 PM, Linus Torvalds
wrote:
>
> I dunno. Maybe there is some fundamental reason why the above is
> broken, but it seems to be a much simpler approach. Sure, you need to
> guarantee that the people who get the write-lock cannot possibly cause
> IO while holding it, but s
On Tue, 27 Nov 2012, Dave Jones wrote:
> Hugh,
>
> We had a user report hitting the BUG_ON at the end of shmem_evict_inode.
> I see in 3.7 you changed this to a WARN instead.
>
> Does the trace below match the one you described chasing in commit
> 0f3c42f522dc1ad7e27affc0a4aa8c790bce0a66 ?
The
[ Hmm. For some reason this seems to have never gone out, and was in
my drafts folder. If you get it twice, my bad ]
On Thu, Nov 22, 2012 at 12:57 AM, Dave Airlie wrote:
>
> Doh!, yes I picked wrong place to generate report from, okay here is
> one corresponding to what you saw,
You should never
> Should we test for >3?
>
> * precise_ip:
> *
> * 0 - SAMPLE_IP can have arbitrary skid
> * 1 - SAMPLE_IP must have constant skid
> * 2 - SAMPLE_IP requested to have 0 skid
> * 3 - SAMPLE_IP must have 0 skid
>
> Maybe it's not implemented in hw yet, but in
On Wed, 28 Nov 2012, Joseph Salisbury wrote:
> On 11/23/2012 08:11 AM, Norbert Warmuth wrote:
> > Thomas Gleixner writes:
> > > On Wed, 21 Nov 2012, Norbert Warmuth wrote:
> > > > 3.7-rc6 booted with nmi_watchdog=0 fails to suspend to RAM or
> > > > offline CPUs. It's reproducable with a KVM guest
On Wed, Nov 28, 2012 at 11:09 AM, Konrad Rzeszutek Wilk
wrote:
>> /*
>>* Remove any mappings which extend past the end of physical
>> - * memory from the boot time page table:
>> + * memory from the boot time page table.
>> + * In virtual address space, we should have
On Wed, 2012-11-28 at 19:28 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 09:54:43 AM Toshi Kani wrote:
> > > > > > > By using acpi_install_notify_handler(), each driver needs to walk
> > > > > > > through the entire ACPI namespace to find its associated ACPI
> > > > > > > devi
On Wed, Nov 28, 2012 at 11:50:30AM -0800, H. Peter Anvin wrote:
> From: "H. Peter Anvin"
>
> Simplify the implementation of sync_core() for the case where we may
> not have the CPUID instruction available.
>
> Signed-off-by: H. Peter Anvin
> ---
> arch/x86/include/asm/processor.h | 27
On Wed, 2012-11-28 at 21:18 +0100, Krzysztof Mazur wrote:
>
> +void vcc_pop_any(struct atm_vcc *vcc, struct sk_buff *skb)
> +{
> + if (vcc->pop)
> + vcc->pop(vcc, skb);
if (vcc && vcc->pop) perhaps?
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
On Wed, Nov 28, 2012 at 08:30:04PM +0100, Sylwester Nawrocki wrote:
> On 11/28/2012 01:22 PM, Dan Carpenter wrote:
> > In the end this is just a driver, and I don't especially care. But
> > it's like not just this one which makes me frustrated. I really
> > believe in linux-next and I think every
On Wed, 28 Nov 2012 11:50:28 -0800
"H. Peter Anvin" wrote:
> From: "H. Peter Anvin"
>
> All 486+ CPUs support WP in supervisor mode, so remove the fallback
> 386 support code.
This breaks the Nx586 support. Do we care: I doubt it 8)
--
To unsubscribe from this list: send the line "unsubscribe
On Tue, 27 Nov 2012, Mel Gorman wrote:
> On Tue, Nov 27, 2012 at 02:07:05PM +, Mel Gorman wrote:
> > On Tue, Nov 27, 2012 at 09:23:59PM +0800, Hillf Danton wrote:
> > > If we have to avoid migrating to a node that is nearly full, put page
> > > and return zero.
> > >
> > > Signed-off-by: Hillf
On Wed, Nov 28, 2012 at 12:32 PM, Linus Torvalds
wrote:
>
> Here is a *COMPLETELY* untested patch. Caveat emptor. It will probably
> do unspeakable things to your family and pets.
Btw, *if* this approach works, I suspect we could just switch the
bd_block_size_semaphore semaphore to be a regular r
On Wed, Nov 28, 2012 at 4:55 PM, Mauro Carvalho Chehab
wrote:
[...]
>
> There are 400+ patches pending today at patchwork. I doubt I'll have enough
> time for all of them, so, I'll skip cleanup patches like the above, in order
> to try to focus on bug fixes and patches that brings new functionalit
On 11/28/2012 10:43 PM, Michael Wolf wrote:
> On 11/27/2012 05:24 PM, Marcelo Tosatti wrote:
>> On Mon, Nov 26, 2012 at 02:36:24PM -0600, Michael Wolf wrote:
>>> In the case of where you have a system that is running in a
>>> capped or overcommitted environment the user may see steal time
>>> being
On Wed, Nov 28, 2012 at 11:47:51AM -0800, Yinghai Lu wrote:
> On Wed, Nov 28, 2012 at 11:35 AM, Konrad Rzeszutek Wilk
> wrote:
> >
> > Have done so. I really like how the top-down mechanism works. It is pretty
> > neat!
> >
> > Yinghai, I had mostly just comments about the patch descriptions - I
On 11/28/2012 09:54 AM, Peter Ujfalusi wrote:
> Hi Grant, Lars, Thierry,
>
> On 11/26/2012 04:46 PM, Grant Likely wrote:
>> You're effectively asking the pwm layer to behave like a gpio (which
>> is completely reasonable). Having a completely separate translation node
>> really doesn't make sense
On Wed, 2012-11-28 at 18:21 +1100, Alexey Kardashevskiy wrote:
> VFIO implements platform independent stuff such as
> a PCI driver, BAR access (via read/write on a file descriptor
> or direct mapping when possible) and IRQ signaling.
>
> The platform dependent part includes IOMMU initialization
>
On Wed, Nov 28, 2012 at 08:18:20PM +0100, Hans Verkuil wrote:
> but in this case it just seems to introduce a second
> merge window before the 'real' merge window.
>
I don't care about this driver, but I mean yes. That's the point of
linux-next.
I would say the standard rule is that it should s
On Wednesday, November 28, 2012 01:31:39 PM Toshi Kani wrote:
> On Wed, 2012-11-28 at 19:28 +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 28, 2012 09:54:43 AM Toshi Kani wrote:
> > > > > > > > By using acpi_install_notify_handler(), each driver needs to
> > > > > > > > walk
> > > > >
On Wed, Nov 28, 2012 at 10:58:32AM +0200, Vitalii Demianets wrote:
> On Wednesday 28 November 2012 00:43:41 Hans J. Koch wrote:
> >
> > Thanks, good catch, but why don't you simply do this:
> >
>
> Just a matter of personal preference.
Your patch: 1 files changed, 12 insertions(+), 4 deletions(
Quoting Mark Langsdorf (2012-11-28 08:18:35)
> On 11/28/2012 10:01 AM, Mike Turquette wrote:
> > Quoting Shawn Guo (2012-11-28 07:17:44)
> >> On Wed, Nov 28, 2012 at 10:58:02PM +0800, Shawn Guo wrote:
> >>> On Wed, Nov 28, 2012 at 07:16:12AM -0600, Mark Langsdorf wrote:
> I'd
> have to mo
On Wed, Nov 28, 2012 at 12:57 PM, Konrad Rzeszutek Wilk
wrote:
> On Wed, Nov 28, 2012 at 11:47:51AM -0800, Yinghai Lu wrote:
>> On Wed, Nov 28, 2012 at 11:35 AM, Konrad Rzeszutek Wilk
>> wrote:
>> >
>> > Have done so. I really like how the top-down mechanism works. It is pretty
>> > neat!
>> >
>
Hello, Greg.
On Wed, Nov 28, 2012 at 12:15:42PM -0800, Greg Thelen wrote:
> @@ -4276,6 +4276,7 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
> DEFINE_WAIT(wait);
> struct cgroup_event *event, *tmp;
> struct cgroup_subsys *ss;
> + struct list_head tmp_list;
LIST_HE
On Wed, Nov 28, 2012 at 10:29:29AM +0100, Cong Ding wrote:
> On Wed, Nov 28, 2012 at 1:37 AM, Hans J. Koch wrote:
> > On Wed, Nov 28, 2012 at 01:07:26AM +0100, Cong Ding wrote:
> >> On Wed, Nov 28, 2012 at 12:07 AM, Hans J. Koch wrote:
> >> > On Tue, Nov 27, 2012 at 07:29:32PM +0200, Vitalii Demi
On Tue, Nov 20, 2012 at 02:12:37PM +0100, Joerg Roedel wrote:
> Hi,
>
> here is the fourth version of the patch-set to improve the abstraction
> of interrupt remapping in the x86 core code. A more detailed description
> can be found in the original post at:
Are these patches available on some git
On 11/28/2012 02:33 PM, Lucas Stach wrote:
Am Mittwoch, den 28.11.2012, 15:17 +0200 schrieb Terje Bergström:
On 28.11.2012 01:00, Dave Airlie wrote:
We generally aim for the first, to stop the gpu from reading/writing
any memory it hasn't been granted access to,
the second is nice to have thou
> > > > > > > Consider the following case:
> > > > > > >
> > > > > > > We hotremove the memory device by SCI and unbind it from the
> > > > > > > driver at the same time:
> > > > > > >
> > > > > > > CPUa CPUb
> > > > > > > acpi_memory_device_notif
On Wed, Nov 28, 2012 at 11:37:23AM +0200, Vitalii Demianets wrote:
> On Wednesday 28 November 2012 02:37:50 Hans J. Koch wrote:
> >
> > In other words, the case of uioinfo AND pdev->dev.of_node both being NULL
> > is not handled properly and will have ugly results.
> >
>
> Moreover, the case of (u
On Wed, 28 Nov 2012 21:18:37 +0100
Krzysztof Mazur wrote:
> On Tue, Nov 27, 2012 at 07:28:43PM +0100, Krzysztof Mazur wrote:
> > I think that we should add atm_pop() function that does that and fix all
> > drivers.
> >
>
> I'm sending a patch that implements that idea.
>
> Currently we need tw
On Tue, Nov 20, 2012 at 02:12:37PM +0100, Joerg Roedel wrote:
> Hi,
>
> here is the fourth version of the patch-set to improve the abstraction
> of interrupt remapping in the x86 core code. A more detailed description
> can be found in the original post at:
>
> https://lkml.org/lkml/2012/
On Mon, Nov 26, 2012 at 03:19:07PM +0200, Terje Bergstrom wrote:
[...]
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index fb9a14e..94c861b 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2463,4 +2463,6 @@ config FB_SH_MOBILE_MERAM
> Up to 4 memory
On Wed, Nov 28, 2012 at 08:44:41PM +, David Woodhouse wrote:
> On Wed, 2012-11-28 at 21:18 +0100, Krzysztof Mazur wrote:
> >
> > +void vcc_pop_any(struct atm_vcc *vcc, struct sk_buff *skb)
> > +{
> > + if (vcc->pop)
> > + vcc->pop(vcc, skb);
>
> if (vcc && vcc->pop) perhap
2012/11/28 viresh kumar :
> On Wed, Nov 28, 2012 at 9:31 PM, viresh kumar wrote:
>> On Wed, Nov 28, 2012 at 5:22 PM, Rabin Vincent
>> Isn't something wrong here? For common clk case shouldn't
>> this be:
>>
>>> +#define clk_to_clk_core(clk) (&clk->clk)
>>> +#define clk_core_to_clk(core) (containe
On Wed, Nov 28, 2012 at 12:21:54PM +0400, Glauber Costa wrote:
> On 11/28/2012 07:17 AM, Dave Chinner wrote:
> > On Wed, Nov 28, 2012 at 01:13:11AM +, Chris Wilson wrote:
> >> On Wed, 28 Nov 2012 10:14:44 +1100, Dave Chinner
> >> wrote:
> >>> +/*
> >>> + * XXX: (dchinner) This is one of the w
On Wed, Nov 28, 2012 at 08:30:04PM +0100, Sylwester Nawrocki wrote:
> On 11/28/2012 01:22 PM, Dan Carpenter wrote:
> > In the end this is just a driver, and I don't especially care. But
> > it's like not just this one which makes me frustrated. I really
> > believe in linux-next and I think every
On Wed, 28 Nov 2012, Linus Torvalds wrote:
> On Wed, Nov 28, 2012 at 12:03 PM, Linus Torvalds
> wrote:
> >
> > mmap() is in *no* way special. The exact same thing happens for
> > regular read/write. Yet somehow the mmap code is special-cased, while
> > the normal read-write code is not.
>
> I
On Wed, 2012-11-28 at 18:18 +1100, Alexey Kardashevskiy wrote:
> This patch initializes IOMMU groups based on the IOMMU
> configuration discovered during the PCI scan on POWERNV
> (POWER non virtualized) platform. The IOMMU groups are
> to be used later by VFIO driver (PCI pass through).
>
> It al
On Wed, 2012-11-28 at 22:09 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 01:31:39 PM Toshi Kani wrote:
> > On Wed, 2012-11-28 at 19:28 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, November 28, 2012 09:54:43 AM Toshi Kani wrote:
> > > > > > > > > By using acpi_install_not
On Wed, Nov 28 2012, Tejun Heo wrote:
> Hello, Greg.
>
> On Wed, Nov 28, 2012 at 12:15:42PM -0800, Greg Thelen wrote:
>> @@ -4276,6 +4276,7 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
>> DEFINE_WAIT(wait);
>> struct cgroup_event *event, *tmp;
>> struct cgroup_subsys *ss
Signed-off-by: Tejun Heo
---
kernel/cpuset.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index b017887..a423774 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2412,17 +2412,6 @@ int __cpuset_node_allowed_hardwall(int node, gfp_t
gfp_m
Add CS_ONLINE which is set from css_online() and cleared from
css_offline(). This will enable using generic cgroup iterator while
allowing decoupling cpuset from cgroup internal locking.
Signed-off-by: Tejun Heo
---
kernel/cpuset.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(
Instead of iterating cgroup->children directly, introduce and use
cpuset_for_each_child() which wraps cgroup_for_each_child() and
performs online check. As it uses the generic iterator, it requires
RCU read locking too.
As cpuset is currently protected by cgroup_mutex, non-online cpusets
aren't v
> 1. use firmware information
> According to ACPI spec 5.0, SRAT table has memory affinity structure
> and the structure has Hot Pluggable Filed. See "5.2.16.2 Memory
> Affinity Structure". If we use the information, we might be able to
> specify movable memory by firmware. For example, if
CPU / memory hotplug path currently grabs cgroup_mutex from hotplug
event notifications. As other places nest the other way around, we
end up with lockdep warning attached below.
We want to keep cgroup_mutex outer to most locks including hotplug
ones. Break the circular dependency by handling ho
cpuset is scheduled to be decoupled from cgroup_lock which will make
configuration updates race with task migration. Any config update
will be allowed to happen between ->can_attach() and ->attach(). If
such config update removes either all cpus or mems, by the time
->attach() is called, the cond
Supposedly for historical reasons, cpuset depends on cgroup core for
locking. It depends on cgroup_mutex in cgroup callbacks and grabs
cgroup_mutex from other places where it wants to be synchronized.
This is majorly messy and highly prone to introducing circular locking
dependency especially beca
cpuset is scheduled to be decoupled from cgroup_lock which will make
hotplug handling race with task migration. cpus or mems will be
allowed to go offline between ->can_attach() and ->attach(). If
hotplug takes down all cpus or mems of a cpuset while attach is in
progress, ->attach() may end up p
On Wednesday, November 28, 2012 02:02:48 PM Toshi Kani wrote:
> > > > > > > > Consider the following case:
> > > > > > > >
> > > > > > > > We hotremove the memory device by SCI and unbind it from the
> > > > > > > > driver at the same time:
> > > > > > > >
> > > > > > > > CPUa
cpuset_hotplug_workfn() has been invoking cpuset_propagate_hotplug()
directly to propagate hotplug updates to !root cpusets; however, this
has the following problems.
* cpuset locking is scheduled to be decoupled from cgroup_mutex,
cgroup_mutex will be unexported, and cgroup_attach_task() will d
The function isn't that hot, the overhead of missing the fast exit is
low, the test itself depends heavily on cgroup internals, and it's
gonna be a hindrance when trying to decouple cpuset locking from
cgroup core. Remove the fast exit path.
Signed-off-by: Tejun Heo
---
kernel/cpuset.c | 8
cpuset_can_attach() prepare global variables cpus_attach and
cpuset_attach_nodemask_{to|from} which are used by cpuset_attach().
There is no reason to prepare in cpuset_can_attach(). The same
information can be accessed from cpuset_attach().
Move the prepartion logic from cpuset_can_attach() to c
Reorganize hotplug path to prepare for async hotplug handling.
* Both CPU and memory hotplug handlings are collected into a single
function - cpuset_handle_hotplug(). It doesn't take any argument
but compares the current setttings of top_cpuset against what's
actually available to determine
get_online_cpus() is already nested inside cgroup_mutex from memcg
when it's registering cpu notifiers. Also, in generall, we want to
make cgroup_mutex one of the outermost locks and be able to use
get_online_cpus() and friends from cgroup methods.
Currently, cpuset avoids nesting get_online_cpus
Add cpuset_css_on/offline() and rearrange css init/exit such that,
* Allocation and clearing to the default values happen in css_alloc().
Allocation now uses kzalloc().
* Config inheritance and registration happen in css_online().
* css_offline() undoes what css_online() did.
* css_free() fre
Hello, guys.
Depending on cgroup core locking - cgroup_mutex - is messy and makes
cgroup prone to locking dependency problems. The current code already
has lock dependency loop - memcg nests get_online_cpus() inside
cgroup_mutex. cpuset the other way around.
Regardless of the locking details, w
On 11/28/2012 01:34 PM, Luck, Tony wrote:
>>
>> 2. use boot option
>> This is our proposal. New boot option can specify memory range to use
>> as movable memory.
>
> Isn't this just moving the work to the user? To pick good values for the
> movable areas, they need to know how the memory lines
Em Wed, Nov 28, 2012 at 08:04:36PM +0100, Andi Kleen escreveu:
> > > +static void str_append(char **s, int *len, const char *a)
> > > +{
> > > + int olen = *s ? strlen(*s) : 0;
> > > + int nlen = olen + strlen(a) + 1;
> > > + if (*len < nlen) {
> > > + *len = *len * 2;
> > > + if (*
On Wed, Nov 28, 2012 at 04:20:01PM -0500, chas williams - CONTRACTOR wrote:
> On Wed, 28 Nov 2012 21:18:37 +0100
> Krzysztof Mazur wrote:
>
> > On Tue, Nov 27, 2012 at 07:28:43PM +0100, Krzysztof Mazur wrote:
> > > I think that we should add atm_pop() function that does that and fix all
> > > dri
Em 28-11-2012 11:19, David Howells escreveu:
Cesar Eduardo Barros wrote:
Several headers were moved or split to uapi/.
I was going to wait to do this till all the bits have got upstream. Several
are still wending their way through maintainer trees. Feel free to send your
patch to Linus wit
On Wed, 2012-11-28 at 22:40 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 02:02:48 PM Toshi Kani wrote:
> > > > > > > > > Consider the following case:
> > > > > > > > >
> > > > > > > > > We hotremove the memory device by SCI and unbind it from the
> > > > > > > > > driver at t
We are going to map ram only in patch:
x86, mm: Only direct map addresses that are marked as E820_RAM
so range under max_low_pfn_mapped, ranges between 4g and max_pfn_mapped
could have holes in them and the holes will not be mapped.
Use pfn_range_is_mapped() to check if the range is mappe
32bit kmap mapping needs pages to be used for low to high.
At this point those pages are still from pgt_buf_* from BRK, so it is
ok now.
But we want to move early_ioremap_page_table_range_init() out of
init_memory_mapping() and only call it one time later, that will
make page_table_range_init/page_
Page table area are pre-mapped now after
x86, mm: setup page table in top-down
x86, mm: Remove early_memremap workaround for page table accessing on
64bit
mapping_pagetable_reserve is not used anymore, so remove it.
Also remove operation in mask_rw_pte(), as modified allow_low_pa
They are almost same except 64 bit need to handle after_bootmem case.
Add mm_internal.h to make that alloc_low_page() only to be accessible
from arch/x86/mm/init*.c
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/mm/init.c| 34 +++
instead of shifting end to get that.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/mm/init.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index dd4e98d..079dce4 100644
--- a/arch/
Now NO_BOOTMEM version free_all_bootmem_node() does not really
do free_bootmem at all, and it only call
register_page_bootmem_info_node instead.
That is confusing, try to kill that free_all_bootmem_node().
Before that, this patch will remove calling of free_all_bootmem_node()
We add register_pag
Now NO_BOOTMEM version free_all_bootmem_node() does not really
do free_bootmem at all, and it only call register_page_bootmem_info_node
for online nodes instead.
That is confusing.
We can kill that free_all_bootmem_node(), after we kill two callings
in x86 and sparc.
Signed-off-by: Yinghai Lu
R
it is only used in arch/x86/mm/init*.c
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/mm/mm_internal.h |2 ++
include/linux/mm.h|1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/mm_internal.h b/arch/x86/mm/mm_internal.h
i
On Wednesday, November 28, 2012 02:23:23 PM Toshi Kani wrote:
> On Wed, 2012-11-28 at 22:09 +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 28, 2012 01:31:39 PM Toshi Kani wrote:
> > > On Wed, 2012-11-28 at 19:28 +0100, Rafael J. Wysocki wrote:
> > > > On Wednesday, November 28, 2012 09:
Use list_del_init() rather than list_del() to remove events from
cgrp->event_list. No functional change. This is just defensive
coding.
Signed-off-by: Greg Thelen
---
kernel/cgroup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
i
They are only for mm/init*.c.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/include/asm/init.h | 16 +++-
arch/x86/mm/mm_internal.h |7 +++
2 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/init.h b/arch/x86
Also change it to static.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/include/asm/page_types.h |1 -
arch/x86/kernel/setup.c |1 -
arch/x86/mm/init.c|2 ++
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86
Also change them to static.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/include/asm/init.h |4
arch/x86/mm/init.c |6 +++---
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/init.h b/arch/x86/include/asm/init
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/mm/init_32.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 0ae1ba8..322ee56 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@
to replace own inline version for those roundup and rounddown.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/mm/init.c | 30 --
1 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
inde
The cgroup_event_wake() function is called with the wait queue head
locked and it takes cgrp->event_list_lock. However, in cgroup_rmdir()
remove_wait_queue() was being called after taking
cgrp->event_list_lock. Correct the lock ordering by using a temporary
list to obtain the event list to remove
after_bootmem has different meaning in 32bit and 64bit.
32bit: after bootmem is ready
64bit: after bootmem is distroyed
Let's merget them make 32bit the same as 64bit.
for 32bit, it is mixing alloc_bootmem_pages, and alloc_low_page under
after_bootmem is set or not set.
alloc_boot
to replace own inline version for shifting.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/mm/init.c | 44 ++--
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index d3f
Get pgt_buf early from BRK, and use it to map PMD_SIZE from top at first.
Then use mapped pages to map more ranges below, and keep looping until
all pages get mapped.
alloc_low_page will use page from BRK at first, after that buffer is used
up, will use memblock to find and reserve pages for page
Now init_memory_mapping is called two times, later will be called for every
ram ranges in following patch:
x86, mm: Only direct map addresses that are marked as E820_RAM
Could put all related init_mem calling together and out of setup.c.
Actually, it reverts commit 1e7
x86: Exclu
From: Jacob Shin
Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and
[ 4GB - max_pfn_mapped ) were always direct mapped, to now look up
pfn_mapped ranges instead.
-v2: change applying sequence to keep git bisecting working.
so add dummy pfn_range_is_mapped(). - Yinghai L
On 32bit, before patch:
x86, mm: Only direct map addresses that are marked as E820_RAM
we only call early_ioremap_page_table_rabge_init() one time.
Now, we are calling that during every init_memory_mapping if we have holes
under max_low_pfn.
We should only call it one time after all ran
On Wed, Nov 28, 2012 at 01:50:45PM -0800, Greg Thelen wrote:
> Use list_del_init() rather than list_del() to remove events from
> cgrp->event_list. No functional change. This is just defensive
> coding.
>
> Signed-off-by: Greg Thelen
Applied 1-2 to cgroup/for-3.8. Thanks!
--
tejun
--
To uns
From: Stefano Stabellini
Add link for more information
279b706 x86,xen: introduce x86_init.mapping.pagetable_reserve
-v2: updated to commets from hpa to include commit name.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/mm/init.c |9 +
1 files
Put it in mm/init.c, and call it from probe_page_mask().
init_mem_mapping is calling probe_page_mask at first.
So calling sequence is not changed.
Signed-off-by: Yinghai Lu
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/kernel/setup.c | 15 +--
arch/x86/mm/init.c | 12
401 - 500 of 820 matches
Mail list logo
