* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-07-25 4:08 Stephen Rothwell
2012-07-25 7:10 ` Ingo Molnar
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2012-07-25 4:08 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Lee Schermerhorn, Johannes Weiner,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in mm/migrate.c
between the tip tree and commit "mm: memcg: fix compaction/migration
failing due to memcg limits" from the akpm tree.
The commit 4783af477d3d ("mm: Migrate misplaced page") was removed (among
several others) from the tip tree since yesterday (and thus linux-next)
so the above akpm tree patch no longer applies.
I have dropped this patch form the akpm tree (and the following patches
as well:
mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits-checkpatch-fixes
mm: memcg: push down PageSwapCache check into uncharge entry functions
mm: memcg: only check for PageSwapCache when uncharging anon
mm: memcg: remove unneeded shmem charge type
mm: memcg: remove needless !mm fixup to init_mm when charging
)
Hopefully this doesn't cause other problems. I guess that they will need
rebasing depending on what gets merged via the tip tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-07-25 4:08 linux-next: manual merge of the akpm tree with the tip tree Stephen Rothwell
@ 2012-07-25 7:10 ` Ingo Molnar
2012-07-25 7:35 ` Johannes Weiner
0 siblings, 1 reply; 85+ messages in thread
From: Ingo Molnar @ 2012-07-25 7:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Lee Schermerhorn,
Johannes Weiner, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> mm/migrate.c between the tip tree and commit "mm: memcg: fix
> compaction/migration failing due to memcg limits" from the
> akpm tree.
>
> The commit 4783af477d3d ("mm: Migrate misplaced page") was
> removed (among several others) from the tip tree since
> yesterday (and thus linux-next) so the above akpm tree patch
> no longer applies.
>
> I have dropped this patch form the akpm tree (and the following patches
> as well:
> mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits-checkpatch-fixes
> mm: memcg: push down PageSwapCache check into uncharge entry functions
> mm: memcg: only check for PageSwapCache when uncharging anon
> mm: memcg: remove unneeded shmem charge type
> mm: memcg: remove needless !mm fixup to init_mm when charging
> )
>
> Hopefully this doesn't cause other problems. I guess that
> they will need rebasing depending on what gets merged via the
> tip tree.
Andrew, sorry about this last minute fallout: I felt that
sched/numa was still not fully cooked and did not want to hold
up the rest of the scheduler tree on that - nor did I want to
send an uncooked tree to Linus.
PeterZ posted another series of sched/numa patches two days ago
- once that is ready (probably after the merge window) it will
all reappear again, in a slightly different form. I could stick
the mm/ bits into a separate tree to make it easier for you.
Cross-discipline patches are hard - the other option would be to
let Linux NUMA scheduling continue to suck.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-07-25 7:10 ` Ingo Molnar
@ 2012-07-25 7:35 ` Johannes Weiner
2012-07-25 18:57 ` Andrew Morton
2012-07-26 7:03 ` Stephen Rothwell
0 siblings, 2 replies; 85+ messages in thread
From: Johannes Weiner @ 2012-07-25 7:35 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Andrew Morton, linux-next, linux-kernel,
Lee Schermerhorn, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
On Wed, Jul 25, 2012 at 09:10:44AM +0200, Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Andrew,
> >
> > Today's linux-next merge of the akpm tree got a conflict in
> > mm/migrate.c between the tip tree and commit "mm: memcg: fix
> > compaction/migration failing due to memcg limits" from the
> > akpm tree.
> >
> > The commit 4783af477d3d ("mm: Migrate misplaced page") was
> > removed (among several others) from the tip tree since
> > yesterday (and thus linux-next) so the above akpm tree patch
> > no longer applies.
> >
> > I have dropped this patch form the akpm tree (and the following patches
> > as well:
> > mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits-checkpatch-fixes
> > mm: memcg: push down PageSwapCache check into uncharge entry functions
> > mm: memcg: only check for PageSwapCache when uncharging anon
> > mm: memcg: remove unneeded shmem charge type
> > mm: memcg: remove needless !mm fixup to init_mm when charging
> > )
> >
> > Hopefully this doesn't cause other problems. I guess that
> > they will need rebasing depending on what gets merged via the
> > tip tree.
>
> Andrew, sorry about this last minute fallout: I felt that
> sched/numa was still not fully cooked and did not want to hold
> up the rest of the scheduler tree on that - nor did I want to
> send an uncooked tree to Linus.
>
> PeterZ posted another series of sched/numa patches two days ago
> - once that is ready (probably after the merge window) it will
> all reappear again, in a slightly different form. I could stick
> the mm/ bits into a separate tree to make it easier for you.
As this is unlikely to reappear in this merge window, the conflict
resolution is quite simple. All that's needed is remove the 3 hunks
from my patch that converted a user in Peter's patch to a new API. I
can resend the series if needed, but it's probably easier to just
remove the hunks against mm/migrate.c::migrate_misplaced_page():
@@ -1519,10 +1512,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
{
struct page *oldpage = page, *newpage;
struct address_space *mapping = page_mapping(page);
- struct mem_cgroup *mcg;
+ struct mem_cgroup *memcg;
unsigned int gfp;
int rc = 0;
- int charge = -ENOMEM;
VM_BUG_ON(!PageLocked(page));
VM_BUG_ON(page_mapcount(page));
@@ -1556,12 +1548,7 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
if (!trylock_page(newpage))
BUG(); /* new page should be unlocked!!! */
- // XXX hnaz, is this right?
- charge = mem_cgroup_prepare_migration(page, newpage, &mcg, gfp);
- if (charge == -ENOMEM) {
- rc = charge;
- goto out;
- }
+ mem_cgroup_prepare_migration(page, newpage, &memcg);
newpage->index = page->index;
newpage->mapping = page->mapping;
@@ -1581,11 +1568,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
page = newpage;
}
+ mem_cgroup_end_migration(memcg, oldpage, newpage, !rc);
out:
- if (!charge)
- mem_cgroup_end_migration(mcg, oldpage, newpage, !rc);
-
- if (oldpage != page)
+ if (oldpage != page)
put_page(oldpage);
if (rc) {
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-07-25 7:35 ` Johannes Weiner
@ 2012-07-25 18:57 ` Andrew Morton
2012-07-25 19:03 ` Ingo Molnar
2012-07-25 19:20 ` Johannes Weiner
2012-07-26 7:03 ` Stephen Rothwell
1 sibling, 2 replies; 85+ messages in thread
From: Andrew Morton @ 2012-07-25 18:57 UTC (permalink / raw)
To: Johannes Weiner
Cc: Ingo Molnar, Stephen Rothwell, linux-next, linux-kernel,
Lee Schermerhorn, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
On Wed, 25 Jul 2012 09:35:03 +0200
Johannes Weiner <hannes@cmpxchg.org> wrote:
> As this is unlikely to reappear in this merge window, the conflict
> resolution is quite simple. All that's needed is remove the 3 hunks
> from my patch that converted a user in Peter's patch to a new API. I
> can resend the series if needed, but it's probably easier to just
> remove the hunks against mm/migrate.c::migrate_misplaced_page():
>
> @@ -1519,10 +1512,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> {
> struct page *oldpage = page, *newpage;
> struct address_space *mapping = page_mapping(page);
> - struct mem_cgroup *mcg;
> + struct mem_cgroup *memcg;
> unsigned int gfp;
> int rc = 0;
> - int charge = -ENOMEM;
>
> VM_BUG_ON(!PageLocked(page));
> VM_BUG_ON(page_mapcount(page));
> @@ -1556,12 +1548,7 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> if (!trylock_page(newpage))
> BUG(); /* new page should be unlocked!!! */
>
> - // XXX hnaz, is this right?
> - charge = mem_cgroup_prepare_migration(page, newpage, &mcg, gfp);
> - if (charge == -ENOMEM) {
> - rc = charge;
> - goto out;
> - }
> + mem_cgroup_prepare_migration(page, newpage, &memcg);
>
> newpage->index = page->index;
> newpage->mapping = page->mapping;
> @@ -1581,11 +1568,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> page = newpage;
> }
>
> + mem_cgroup_end_migration(memcg, oldpage, newpage, !rc);
> out:
> - if (!charge)
> - mem_cgroup_end_migration(mcg, oldpage, newpage, !rc);
> -
> - if (oldpage != page)
> + if (oldpage != page)
> put_page(oldpage);
>
> if (rc) {
Yes, that worked out OK.
This means that if the above code reappears in linux-next or mainline,
the current copy of
mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch
will no longer update it, and I probably won't notice that omission.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-07-25 18:57 ` Andrew Morton
@ 2012-07-25 19:03 ` Ingo Molnar
2012-07-25 19:26 ` Andrew Morton
2012-07-25 19:20 ` Johannes Weiner
1 sibling, 1 reply; 85+ messages in thread
From: Ingo Molnar @ 2012-07-25 19:03 UTC (permalink / raw)
To: Andrew Morton
Cc: Johannes Weiner, Stephen Rothwell, linux-next, linux-kernel,
Lee Schermerhorn, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 25 Jul 2012 09:35:03 +0200
> Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> > As this is unlikely to reappear in this merge window, the conflict
> > resolution is quite simple. All that's needed is remove the 3 hunks
> > from my patch that converted a user in Peter's patch to a new API. I
> > can resend the series if needed, but it's probably easier to just
> > remove the hunks against mm/migrate.c::migrate_misplaced_page():
> >
> > @@ -1519,10 +1512,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> > {
> > struct page *oldpage = page, *newpage;
> > struct address_space *mapping = page_mapping(page);
> > - struct mem_cgroup *mcg;
> > + struct mem_cgroup *memcg;
> > unsigned int gfp;
> > int rc = 0;
> > - int charge = -ENOMEM;
> >
> > VM_BUG_ON(!PageLocked(page));
> > VM_BUG_ON(page_mapcount(page));
> > @@ -1556,12 +1548,7 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> > if (!trylock_page(newpage))
> > BUG(); /* new page should be unlocked!!! */
> >
> > - // XXX hnaz, is this right?
> > - charge = mem_cgroup_prepare_migration(page, newpage, &mcg, gfp);
> > - if (charge == -ENOMEM) {
> > - rc = charge;
> > - goto out;
> > - }
> > + mem_cgroup_prepare_migration(page, newpage, &memcg);
> >
> > newpage->index = page->index;
> > newpage->mapping = page->mapping;
> > @@ -1581,11 +1568,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> > page = newpage;
> > }
> >
> > + mem_cgroup_end_migration(memcg, oldpage, newpage, !rc);
> > out:
> > - if (!charge)
> > - mem_cgroup_end_migration(mcg, oldpage, newpage, !rc);
> > -
> > - if (oldpage != page)
> > + if (oldpage != page)
> > put_page(oldpage);
> >
> > if (rc) {
>
> Yes, that worked out OK.
>
> This means that if the above code reappears in linux-next or
> mainline, the current copy of
> mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch
> will no longer update it, and I probably won't notice that
> omission.
Did you plan to send Johannes's memcg bits to Linus in this
merge window? If yes then I'll delay pushing out anything that
might interfere.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-07-25 19:03 ` Ingo Molnar
@ 2012-07-25 19:26 ` Andrew Morton
2012-07-26 7:51 ` Ingo Molnar
2012-07-26 18:05 ` Andrew Morton
0 siblings, 2 replies; 85+ messages in thread
From: Andrew Morton @ 2012-07-25 19:26 UTC (permalink / raw)
To: Ingo Molnar
Cc: Johannes Weiner, Stephen Rothwell, linux-next, linux-kernel,
Lee Schermerhorn, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
On Wed, 25 Jul 2012 21:03:51 +0200
Ingo Molnar <mingo@kernel.org> wrote:
> > This means that if the above code reappears in linux-next or
> > mainline, the current copy of
> > mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch
> > will no longer update it, and I probably won't notice that
> > omission.
>
> Did you plan to send Johannes's memcg bits to Linus in this
> merge window?
Yes. I was kinda thinking of starting the bombing run on Monday but I
guess I could do the MM queue on Thursday.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-07-25 19:26 ` Andrew Morton
@ 2012-07-26 7:51 ` Ingo Molnar
2012-07-26 18:05 ` Andrew Morton
1 sibling, 0 replies; 85+ messages in thread
From: Ingo Molnar @ 2012-07-26 7:51 UTC (permalink / raw)
To: Andrew Morton
Cc: Johannes Weiner, Stephen Rothwell, linux-next, linux-kernel,
Lee Schermerhorn, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 25 Jul 2012 21:03:51 +0200
> Ingo Molnar <mingo@kernel.org> wrote:
>
> > > This means that if the above code reappears in linux-next or
> > > mainline, the current copy of
> > > mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch
> > > will no longer update it, and I probably won't notice that
> > > omission.
> >
> > Did you plan to send Johannes's memcg bits to Linus in this
> > merge window?
>
> Yes. I was kinda thinking of starting the bombing run on
> Monday but I guess I could do the MM queue on Thursday.
Ok, great, that simplifies things: we'll base any additional
sched/numa work on an upstream sha1 that has those bits
upstream. (-rc1, if upstream quality allows.)
Thanks,
Ingo
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-07-25 19:26 ` Andrew Morton
2012-07-26 7:51 ` Ingo Molnar
@ 2012-07-26 18:05 ` Andrew Morton
1 sibling, 0 replies; 85+ messages in thread
From: Andrew Morton @ 2012-07-26 18:05 UTC (permalink / raw)
To: Ingo Molnar, Johannes Weiner, Stephen Rothwell, linux-next,
linux-kernel, Lee Schermerhorn, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
On Wed, 25 Jul 2012 12:26:13 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 25 Jul 2012 21:03:51 +0200
> Ingo Molnar <mingo@kernel.org> wrote:
>
> > > This means that if the above code reappears in linux-next or
> > > mainline, the current copy of
> > > mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch
> > > will no longer update it, and I probably won't notice that
> > > omission.
> >
> > Did you plan to send Johannes's memcg bits to Linus in this
> > merge window?
>
> Yes. I was kinda thinking of starting the bombing run on Monday but I
> guess I could do the MM queue on Thursday.
Sorry, this didn't work out: there's still too much stuff which hasn't
gone into mainline yet (slab, NFS, others). Merging the MM code now
would involve a worrying amount of last-minute code rework and would
cause the owners of those trees to have to do last-minute rework as
well. This is why I always go last.
I'll take another look on Monday.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-07-25 18:57 ` Andrew Morton
2012-07-25 19:03 ` Ingo Molnar
@ 2012-07-25 19:20 ` Johannes Weiner
1 sibling, 0 replies; 85+ messages in thread
From: Johannes Weiner @ 2012-07-25 19:20 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, Stephen Rothwell, linux-next, linux-kernel,
Lee Schermerhorn, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
On Wed, Jul 25, 2012 at 11:57:13AM -0700, Andrew Morton wrote:
> On Wed, 25 Jul 2012 09:35:03 +0200
> Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> > As this is unlikely to reappear in this merge window, the conflict
> > resolution is quite simple. All that's needed is remove the 3 hunks
> > from my patch that converted a user in Peter's patch to a new API. I
> > can resend the series if needed, but it's probably easier to just
> > remove the hunks against mm/migrate.c::migrate_misplaced_page():
> >
> > @@ -1519,10 +1512,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> > {
> > struct page *oldpage = page, *newpage;
> > struct address_space *mapping = page_mapping(page);
> > - struct mem_cgroup *mcg;
> > + struct mem_cgroup *memcg;
> > unsigned int gfp;
> > int rc = 0;
> > - int charge = -ENOMEM;
> >
> > VM_BUG_ON(!PageLocked(page));
> > VM_BUG_ON(page_mapcount(page));
> > @@ -1556,12 +1548,7 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> > if (!trylock_page(newpage))
> > BUG(); /* new page should be unlocked!!! */
> >
> > - // XXX hnaz, is this right?
> > - charge = mem_cgroup_prepare_migration(page, newpage, &mcg, gfp);
> > - if (charge == -ENOMEM) {
> > - rc = charge;
> > - goto out;
> > - }
> > + mem_cgroup_prepare_migration(page, newpage, &memcg);
> >
> > newpage->index = page->index;
> > newpage->mapping = page->mapping;
> > @@ -1581,11 +1568,9 @@ migrate_misplaced_page(struct page *page, struct mm_struct *mm, int node)
> > page = newpage;
> > }
> >
> > + mem_cgroup_end_migration(memcg, oldpage, newpage, !rc);
> > out:
> > - if (!charge)
> > - mem_cgroup_end_migration(mcg, oldpage, newpage, !rc);
> > -
> > - if (oldpage != page)
> > + if (oldpage != page)
> > put_page(oldpage);
> >
> > if (rc) {
>
> Yes, that worked out OK.
>
> This means that if the above code reappears in linux-next or mainline,
> the current copy of
> mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits.patch
> will no longer update it, and I probably won't notice that omission.
The gfp_t argument was dropped from mem_cgroup_prepare_migration(), so
it'll blow up during compilation with CONFIG_NUMA=y.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-07-25 7:35 ` Johannes Weiner
2012-07-25 18:57 ` Andrew Morton
@ 2012-07-26 7:03 ` Stephen Rothwell
1 sibling, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-07-26 7:03 UTC (permalink / raw)
To: Johannes Weiner
Cc: Ingo Molnar, Andrew Morton, linux-next, linux-kernel,
Lee Schermerhorn, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]
Hi all,
On Wed, 25 Jul 2012 09:35:03 +0200 Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> On Wed, Jul 25, 2012 at 09:10:44AM +0200, Ingo Molnar wrote:
> >
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Today's linux-next merge of the akpm tree got a conflict in
> > > mm/migrate.c between the tip tree and commit "mm: memcg: fix
> > > compaction/migration failing due to memcg limits" from the
> > > akpm tree.
> > >
> > > The commit 4783af477d3d ("mm: Migrate misplaced page") was
> > > removed (among several others) from the tip tree since
> > > yesterday (and thus linux-next) so the above akpm tree patch
> > > no longer applies.
> > >
> > > I have dropped this patch form the akpm tree (and the following patches
> > > as well:
> > > mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits-checkpatch-fixes
> > > mm: memcg: push down PageSwapCache check into uncharge entry functions
> > > mm: memcg: only check for PageSwapCache when uncharging anon
> > > mm: memcg: remove unneeded shmem charge type
> > > mm: memcg: remove needless !mm fixup to init_mm when charging
> > > )
> > >
> > > Hopefully this doesn't cause other problems. I guess that
> > > they will need rebasing depending on what gets merged via the
> > > tip tree.
> >
> > Andrew, sorry about this last minute fallout: I felt that
> > sched/numa was still not fully cooked and did not want to hold
> > up the rest of the scheduler tree on that - nor did I want to
> > send an uncooked tree to Linus.
> >
> > PeterZ posted another series of sched/numa patches two days ago
> > - once that is ready (probably after the merge window) it will
> > all reappear again, in a slightly different form. I could stick
> > the mm/ bits into a separate tree to make it easier for you.
>
> As this is unlikely to reappear in this merge window, the conflict
> resolution is quite simple. All that's needed is remove the 3 hunks
> from my patch that converted a user in Peter's patch to a new API. I
> can resend the series if needed, but it's probably easier to just
> remove the hunks against mm/migrate.c::migrate_misplaced_page():
OK, so I have readded those patches to linux-next today with the
appropriate hunks removed. Except for
mm-memcg-fix-compaction-migration-failing-due-to-memcg-limits-checkpatch-fixes
which only touched the part of the file that no longer exists.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2020-05-29 10:57 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2020-05-29 10:57 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Mike Rapoport
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
arch/x86/xen/smp_pv.c
between commit:
66a07b44e765 ("x86/entry: Switch XEN/PV hypercall entry to IDTENTRY")
from the tip tree and patch:
"mm: introduce include/linux/pgtable.h"
from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index ae4d0f283df3..679d7e87a68b 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -26,7 +26,7 @@
#include <asm/paravirt.h>
#include <asm/desc.h>
-#include <asm/pgtable.h>
+#include <linux/pgtable.h>
#include <asm/idtentry.h>
#include <asm/cpu.h>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2020-05-29 10:49 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2020-05-29 10:49 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Qian Cai
[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
mm/swap.c
between commit:
b01b21419999 ("mm/swap: Use local_lock for protection")
from the tip tree and patch:
"mm/swap.c: annotate data races for lru_rotate_pvecs"
from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --git a/mm/swap.c b/mm/swap.c
index a8442ed0bb16..936d6b545217 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -620,7 +620,8 @@ void lru_add_drain_cpu(int cpu)
__pagevec_lru_add(pvec);
pvec = &per_cpu(lru_rotate.pvec, cpu);
- if (pagevec_count(pvec)) {
+ /* Disabling interrupts below acts as a compiler barrier. */
+ if (data_race(pagevec_count(pvec))) {
unsigned long flags;
/* No harm done if a racing interrupt already did this */
@@ -781,7 +782,7 @@ void lru_add_drain_all(void)
struct work_struct *work = &per_cpu(lru_add_drain_work, cpu);
if (pagevec_count(&per_cpu(lru_pvecs.lru_add, cpu)) ||
- pagevec_count(&per_cpu(lru_rotate.pvec, cpu)) ||
+ data_race(pagevec_count(&per_cpu(lru_rotate.pvec, cpu))) ||
pagevec_count(&per_cpu(lru_pvecs.lru_deactivate_file, cpu)) ||
pagevec_count(&per_cpu(lru_pvecs.lru_deactivate, cpu)) ||
pagevec_count(&per_cpu(lru_pvecs.lru_lazyfree, cpu)) ||
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2020-01-22 6:37 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2020-01-22 6:37 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Ard Biesheuvel, Steven Price
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
arch/x86/platform/efi/efi_64.c
between commit:
1f299fad1e31 ("efi/x86: Limit EFI old memory map to SGI UV machines")
from the tip tree and patch:
"x86: mm+efi: convert ptdump_walk_pgd_level() to take a mm_struct"
from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/platform/efi/efi_64.c
index e2accfe636bd,515eab388b56..000000000000
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@@ -470,10 -606,10 +470,10 @@@ void __init efi_runtime_update_mappings
void __init efi_dump_pagetable(void)
{
#ifdef CONFIG_EFI_PGT_DUMP
- if (efi_enabled(EFI_OLD_MEMMAP))
+ if (efi_have_uv1_memmap())
- ptdump_walk_pgd_level(NULL, swapper_pg_dir);
+ ptdump_walk_pgd_level(NULL, &init_mm);
else
- ptdump_walk_pgd_level(NULL, efi_mm.pgd);
+ ptdump_walk_pgd_level(NULL, &efi_mm);
#endif
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2019-02-13 6:49 Stephen Rothwell
2019-02-13 19:59 ` Andrew Morton
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2019-02-13 6:49 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Mark Rutland
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
scripts/atomic/check-atomics.sh
between commit:
4ad119545d78 ("locking/atomics: Check atomic headers with sha1sum")
from the tip tree and patch:
"scripts/atomic/check-atomics.sh: don't assume that scripts are executable"
from the akpm tree.
I fixed it up (this latter patch is now needed against the new
scripts/atomic/gen-atomics.sh instead) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2019-02-13 6:49 Stephen Rothwell
@ 2019-02-13 19:59 ` Andrew Morton
0 siblings, 0 replies; 85+ messages in thread
From: Andrew Morton @ 2019-02-13 19:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Linux Next Mailing List, Linux Kernel Mailing List, Mark Rutland
On Wed, 13 Feb 2019 17:49:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
> scripts/atomic/check-atomics.sh
>
> between commit:
>
> 4ad119545d78 ("locking/atomics: Check atomic headers with sha1sum")
>
> from the tip tree and patch:
>
> "scripts/atomic/check-atomics.sh: don't assume that scripts are executable"
>
> from the akpm tree.
>
> I fixed it up (this latter patch is now needed against the new
> scripts/atomic/gen-atomics.sh instead) and can carry the fix as
> necessary.
Thanks. I don't know why I've been carrying that fix for so long :(
Shall resend.
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2018-01-09 5:02 Stephen Rothwell
2018-01-09 10:36 ` Andy Shevchenko
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2018-01-09 5:02 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Andy Shevchenko, Andi Kleen, Darren Hart (VMware)
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
arch/x86/platform/intel-mid/device_libs/platform_bt.c
between commit:
9d0513d82f1a ("x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const"")
from the tip tree and patch:
"arch/x86/platform/intel-mid/device_libs/platform_bt.c: fix const confusion"
from the akpm tree.
I fixed it up (I dropped the akpm tree patch) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2018-01-09 5:02 Stephen Rothwell
@ 2018-01-09 10:36 ` Andy Shevchenko
0 siblings, 0 replies; 85+ messages in thread
From: Andy Shevchenko @ 2018-01-09 10:36 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andi Kleen,
Darren Hart (VMware)
On Tue, 2018-01-09 at 16:02 +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
> arch/x86/platform/intel-mid/device_libs/platform_bt.c
>
> between commit:
>
> 9d0513d82f1a ("x86/platform/intel-mid: Revert "Make 'bt_sfi_data'
> const"")
>
> from the tip tree and patch:
>
> "arch/x86/platform/intel-mid/device_libs/platform_bt.c: fix const
> confusion"
>
> from the akpm tree.
>
> I fixed it up (I dropped the akpm tree patch)
Yes, that is exactly what needs to be done.
Thanks!
Andrew, can you drop that patch from your quilt?
> and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but
> any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to
> consider
> cooperating with the maintainer of the conflicting tree to minimise
> any
> particularly complex conflicts.
>
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2017-10-16 18:48 Mark Brown
2017-10-16 20:01 ` Mark Brown
0 siblings, 1 reply; 85+ messages in thread
From: Mark Brown @ 2017-10-16 18:48 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
Hi Andrew,
Today's linux-next merge of (well, import of) the akpm tree got a
conflict in:
include/linux/sched/mm.h
between commit:
68e21be2916b35 ("sched/headers: Move task->mm handling methods to <linux/sched/mm.h>")
from the tip tree and commit:
d3a5cfa169959b ("include/linux/sched/mm.h: uninline mmdrop_async(), etc")
from the akpm tree.
I don't feel confident fixing this up, I'm trying to figure out how to
drop one of the commits but this script isn't the clearest in it's
intent.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2017-10-16 18:48 Mark Brown
@ 2017-10-16 20:01 ` Mark Brown
0 siblings, 0 replies; 85+ messages in thread
From: Mark Brown @ 2017-10-16 20:01 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]
On Mon, Oct 16, 2017 at 07:48:10PM +0100, Mark Brown wrote:
> I don't feel confident fixing this up, I'm trying to figure out how to
> drop one of the commits but this script isn't the clearest in it's
> intent.
OK, I might've figured it out or I might've made a terrible mess.
Either way it seems to pass a basic smoke test.
Later on in the merge process I also found additional conflicts,
including extensive conflicts which look like reformatting issues in
btrfs.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2017-04-12 7:08 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2017-04-12 7:08 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Laura Abbott
Hi Andrew,
Today's linux-next merge of the akpm tree got conflicts in:
arch/x86/mm/init.c
arch/x86/mm/ioremap.c
between commit:
66441bd3cfdc ("x86/boot/e820: Move asm/e820.h to asm/e820/api.h")
from the tip tree and patch:
"x86: use set_memory.h header"
from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/mm/init.c
index 2193799ca800,adbfb095bade..000000000000
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@@ -5,8 -5,8 +5,8 @@@
#include <linux/memblock.h>
#include <linux/bootmem.h> /* for max_low_pfn */
- #include <asm/cacheflush.h>
+ #include <asm/set_memory.h>
-#include <asm/e820.h>
+#include <asm/e820/api.h>
#include <asm/init.h>
#include <asm/page.h>
#include <asm/page_types.h>
diff --cc arch/x86/mm/ioremap.c
index e4f7b25df18e,1924c4ab8be5..000000000000
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@@ -14,8 -13,8 +14,8 @@@
#include <linux/vmalloc.h>
#include <linux/mmiotrace.h>
- #include <asm/cacheflush.h>
+ #include <asm/set_memory.h>
-#include <asm/e820.h>
+#include <asm/e820/api.h>
#include <asm/fixmap.h>
#include <asm/pgtable.h>
#include <asm/tlbflush.h>
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2017-03-31 5:44 Stephen Rothwell
2017-03-31 6:42 ` Peter Zijlstra
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2017-03-31 5:44 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andi Kleen
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
kernel/sched/fair.c
between commit:
0ccb977f4c80 ("sched/fair: Explicitly generate __update_load_avg() instances")
from the tip tree and patch:
"kernel/sched/fair.c: uninline __update_load_avg()"
from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/sched/fair.c
index 359dbc05a3b4,28a2bd8bfb67..000000000000
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@@ -2929,11 -2848,14 +2929,11 @@@ accumulate_sum(u64 delta, int cpu, stru
* load_avg = u_0` + y*(u_0 + u_1*y + u_2*y^2 + ... )
* = u_0 + u_1*y + u_2*y^2 + ... [re-labeling u_i --> u_{i+1}]
*/
- static __always_inline int
+ static int
-__update_load_avg(u64 now, int cpu, struct sched_avg *sa,
+___update_load_avg(u64 now, int cpu, struct sched_avg *sa,
unsigned long weight, int running, struct cfs_rq *cfs_rq)
{
- u64 delta, scaled_delta, periods;
- u32 contrib;
- unsigned int delta_w, scaled_delta_w, decayed = 0;
- unsigned long scale_freq, scale_cpu;
+ u64 delta;
delta = now - sa->last_update_time;
/*
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2017-03-31 5:44 Stephen Rothwell
@ 2017-03-31 6:42 ` Peter Zijlstra
2017-03-31 13:54 ` Andi Kleen
0 siblings, 1 reply; 85+ messages in thread
From: Peter Zijlstra @ 2017-03-31 6:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Linux-Next Mailing List, Linux Kernel Mailing List, Andi Kleen
On Fri, Mar 31, 2017 at 04:44:51PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
> kernel/sched/fair.c
>
> between commit:
>
> 0ccb977f4c80 ("sched/fair: Explicitly generate __update_load_avg() instances")
>
> from the tip tree and patch:
>
> "kernel/sched/fair.c: uninline __update_load_avg()"
>
> from the akpm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Argh!
Andrew, please drop that patch. And the x86 out-of-line of __atomic_add_unless().
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2017-03-31 6:42 ` Peter Zijlstra
@ 2017-03-31 13:54 ` Andi Kleen
2017-03-31 14:45 ` Peter Zijlstra
0 siblings, 1 reply; 85+ messages in thread
From: Andi Kleen @ 2017-03-31 13:54 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Linux-Next Mailing List,
Linux Kernel Mailing List
> Argh!
>
> Andrew, please drop that patch. And the x86 out-of-line of __atomic_add_unless().
Why dropping the second? Do you have something better?
On the first there were no 0day regressions, so at least basic performance
checking has been done.
-Andi
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2017-03-31 13:54 ` Andi Kleen
@ 2017-03-31 14:45 ` Peter Zijlstra
2017-03-31 16:02 ` Andi Kleen
0 siblings, 1 reply; 85+ messages in thread
From: Peter Zijlstra @ 2017-03-31 14:45 UTC (permalink / raw)
To: Andi Kleen
Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Linux-Next Mailing List,
Linux Kernel Mailing List
On Fri, Mar 31, 2017 at 06:54:48AM -0700, Andi Kleen wrote:
> > Argh!
> >
> > Andrew, please drop that patch. And the x86 out-of-line of __atomic_add_unless().
>
> Why dropping the second? Do you have something better?
The try_cmpxchg() patches save about half the text, and do not have the
out-of-line penalty as shown here:
https://lkml.kernel.org/r/20170322165144.dtidvvbxey7w5pbd@hirez.programming.kicks-ass.net
> On the first there were no 0day regressions, so at least basic performance
> checking has been done.
The first is superseded by much better patches in the scheduler tree.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2017-03-31 14:45 ` Peter Zijlstra
@ 2017-03-31 16:02 ` Andi Kleen
2017-03-31 17:48 ` Peter Zijlstra
0 siblings, 1 reply; 85+ messages in thread
From: Andi Kleen @ 2017-03-31 16:02 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Linux-Next Mailing List,
Linux Kernel Mailing List
On Fri, Mar 31, 2017 at 04:45:46PM +0200, Peter Zijlstra wrote:
> On Fri, Mar 31, 2017 at 06:54:48AM -0700, Andi Kleen wrote:
> > > Argh!
> > >
> > > Andrew, please drop that patch. And the x86 out-of-line of __atomic_add_unless().
> >
> > Why dropping the second? Do you have something better?
>
> The try_cmpxchg() patches save about half the text, and do not have the
> out-of-line penalty as shown here:
>
> https://lkml.kernel.org/r/20170322165144.dtidvvbxey7w5pbd@hirez.programming.kicks-ass.net
Where is the source for the benchmark?
Based on the description it sounds like it's testing atomic_inc(), which my patches
don't change.
BTW testing such things in tight loops is bad practice. If you run
them back to back the CPU pipeline has to do much more serialization,
which is usually not realistic and drastically overestimates
the overhead.
A better practice is to run some real workload. If you want to see
cycle counts you can look at LBR cycles, or PT cycles from sampling or tracing.
> > On the first there were no 0day regressions, so at least basic performance
> > checking has been done.
>
> The first is superseded by much better patches in the scheduler tree.
Which patches exactly? The new patches shrink the text too?
-Andi
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2017-03-31 16:02 ` Andi Kleen
@ 2017-03-31 17:48 ` Peter Zijlstra
0 siblings, 0 replies; 85+ messages in thread
From: Peter Zijlstra @ 2017-03-31 17:48 UTC (permalink / raw)
To: Andi Kleen
Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Linux-Next Mailing List,
Linux Kernel Mailing List
On Fri, Mar 31, 2017 at 09:02:42AM -0700, Andi Kleen wrote:
> On Fri, Mar 31, 2017 at 04:45:46PM +0200, Peter Zijlstra wrote:
> > On Fri, Mar 31, 2017 at 06:54:48AM -0700, Andi Kleen wrote:
> > > > Argh!
> > > >
> > > > Andrew, please drop that patch. And the x86 out-of-line of __atomic_add_unless().
> > >
> > > Why dropping the second? Do you have something better?
> >
> > The try_cmpxchg() patches save about half the text, and do not have the
> > out-of-line penalty as shown here:
> >
> > https://lkml.kernel.org/r/20170322165144.dtidvvbxey7w5pbd@hirez.programming.kicks-ass.net
>
> Where is the source for the benchmark?
In that email; heck marc.info even provides a downloadable link, you
don't even have to go find it in your local lkml archives.
> Based on the description it sounds like it's testing atomic_inc(),
> which my patches don't change.
Yes, reading is hard.
It tests:
lock incl
vs
call refcount_inc
vs
$inlined refcount_inc
And refcount_inc() is more complex than add_unless().
> BTW testing such things in tight loops is bad practice. If you run
> them back to back the CPU pipeline has to do much more serialization,
> which is usually not realistic and drastically overestimates
> the overhead.
>
> A better practice is to run some real workload. If you want to see
> cycle counts you can look at LBR cycles, or PT cycles from sampling or tracing.
Hey, at least I did benchmark it. You just waved your hands and are
causing extra work for other people.
> > > On the first there were no 0day regressions, so at least basic performance
> > > checking has been done.
> >
> > The first is superseded by much better patches in the scheduler tree.
>
> Which patches exactly? The new patches shrink the text too?
Try your local google foo; or look at the patch that conflicted, its
that one and the next.
In the end it comes down to -mm carrying patches against trees that are
maintained elsewhere without acks from said maintainers. I don't feel
bad about causing conflicts.
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2017-03-24 5:40 Stephen Rothwell
2017-03-24 8:05 ` Peter Zijlstra
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2017-03-24 5:40 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: linux-next, linux-kernel
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
arch/x86/include/asm/atomic.h
between commit:
e6790e4b5d5e ("locking/atomic/x86: Use atomic_try_cmpxchg()")
from the tip tree and patch:
"x86/atomic: move __arch_atomic_add_unless out of line"
from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --git a/arch/x86/lib/atomic.c b/arch/x86/lib/atomic.c
index 88c8372109f8..4b8f6b842be9 100644
--- a/arch/x86/lib/atomic.c
+++ b/arch/x86/lib/atomic.c
@@ -12,16 +12,11 @@
*/
int __arch_atomic_add_unless(atomic_t *v, int a, int u)
{
- int c, old;
- c = arch_atomic_read(v);
- for (;;) {
- if (unlikely(c == (u)))
+ int c = arch_atomic_read(v);
+ do {
+ if (unlikely(c == u))
break;
- old = arch_atomic_cmpxchg((v), c, c + (a));
- if (likely(old == c))
- break;
- c = old;
- }
+ } while (!atomic_try_cmpxchg(v, &c, c + a));
return c;
}
EXPORT_SYMBOL(__arch_atomic_add_unless);
^ permalink raw reply related [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2017-03-24 5:40 Stephen Rothwell
@ 2017-03-24 8:05 ` Peter Zijlstra
0 siblings, 0 replies; 85+ messages in thread
From: Peter Zijlstra @ 2017-03-24 8:05 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
linux-next, linux-kernel
On Fri, Mar 24, 2017 at 04:40:26PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
> arch/x86/include/asm/atomic.h
>
> between commit:
>
> e6790e4b5d5e ("locking/atomic/x86: Use atomic_try_cmpxchg()")
>
> from the tip tree and patch:
>
> "x86/atomic: move __arch_atomic_add_unless out of line"
>
> from the akpm tree.
Urgh, that patch shouldn't be in mm in any case. Also with the
try_cmpxchg() change, the text gain is reduced (about half).
Furthermore, micro-benchmarks show that turning cmpxchg loops like this
into a function makes them more expensive; see:
https://lkml.kernel.org/r/20170322165144.dtidvvbxey7w5pbd@hirez.programming.kicks-ass.net
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2016-03-10 5:28 Stephen Rothwell
2016-03-10 8:00 ` Ingo Molnar
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2016-03-10 5:28 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: linux-next, linux-kernel, Luis R. Rodriguez
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
drivers/gpu/drm/omapdrm/omap_gem.c
between commit:
f6e45661f9be ("dma, mm/pat: Rename dma_*_writecombine() to dma_*_wc()")
from the tip tree and patch:
"dma-mapping: rename dma_*_writecombine() to dma_*_wc()"
from the akpm tree.
These a basically the same patch, so I dropped the one from the akpm tree.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2016-03-10 5:28 Stephen Rothwell
@ 2016-03-10 8:00 ` Ingo Molnar
2016-03-10 20:38 ` Andrew Morton
0 siblings, 1 reply; 85+ messages in thread
From: Ingo Molnar @ 2016-03-10 8:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Luis R. Rodriguez
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
> drivers/gpu/drm/omapdrm/omap_gem.c
>
> between commit:
>
> f6e45661f9be ("dma, mm/pat: Rename dma_*_writecombine() to dma_*_wc()")
>
> from the tip tree and patch:
>
> "dma-mapping: rename dma_*_writecombine() to dma_*_wc()"
>
> from the akpm tree.
>
> These a basically the same patch, so I dropped the one from the akpm tree.
Andrew, what's your preference for merging it? I can drop it too.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2016-03-10 8:00 ` Ingo Molnar
@ 2016-03-10 20:38 ` Andrew Morton
0 siblings, 0 replies; 85+ messages in thread
From: Andrew Morton @ 2016-03-10 20:38 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Luis R. Rodriguez
On Thu, 10 Mar 2016 09:00:25 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Andrew,
> >
> > Today's linux-next merge of the akpm tree got a conflict in:
> >
> > drivers/gpu/drm/omapdrm/omap_gem.c
> >
> > between commit:
> >
> > f6e45661f9be ("dma, mm/pat: Rename dma_*_writecombine() to dma_*_wc()")
> >
> > from the tip tree and patch:
> >
> > "dma-mapping: rename dma_*_writecombine() to dma_*_wc()"
> >
> > from the akpm tree.
> >
> > These a basically the same patch, so I dropped the one from the akpm tree.
>
> Andrew, what's your preference for merging it? I can drop it too.
>
I've dropped the -mm copy. That's what I do in 99.99% of cases. Which
means that if the version which was in someone else's -next tree later
gets lost (happens sometimes), the patch is lost altogether.
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2016-02-09 4:50 Stephen Rothwell
2016-02-09 14:04 ` Matt Fleming
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2016-02-09 4:50 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: linux-next, linux-kernel, Robert Elliott, Andy Shevchenko, Matt Fleming
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
arch/x86/platform/efi/efi.c
between commit:
1e82b9479070 ("x86/efi: Show actual ending addresses in efi_print_memmap")
from the tip tree and commit:
e0532ef9f825 ("x86/efi: print size and base in binary units in efi_print_memmap")
from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/platform/efi/efi.c
index e80826e6f3a9,122584ec27ef..000000000000
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@@ -232,14 -241,14 +241,14 @@@ void __init efi_print_memmap(void
for (p = memmap.map, i = 0;
p < memmap.map_end;
p += memmap.desc_size, i++) {
- char buf[64];
+ efi_memory_desc_t *md = p;
+ u64 size = md->num_pages << EFI_PAGE_SHIFT;
+ char buf[64], buf3[32];
- md = p;
- pr_info("mem%02u: %s range=[0x%016llx-0x%016llx] (%lluMB)\n",
+ pr_info("mem%02u: %s range=[0x%016llx-0x%016llx] (%s)\n",
i, efi_md_typeattr_format(buf, sizeof(buf), md),
- md->phys_addr,
- md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) - 1,
- (md->num_pages >> (20 - EFI_PAGE_SHIFT)));
- md->phys_addr, md->phys_addr + size,
++ md->phys_addr, md->phys_addr + size -1,
+ efi_size_format(buf3, sizeof(buf3), size));
}
#endif /* EFI_DEBUG */
}
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2016-02-09 4:50 Stephen Rothwell
@ 2016-02-09 14:04 ` Matt Fleming
2016-02-09 14:07 ` Ingo Molnar
0 siblings, 1 reply; 85+ messages in thread
From: Matt Fleming @ 2016-02-09 14:04 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Robert Elliott,
Andy Shevchenko
On Tue, 09 Feb, at 03:50:24PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
> arch/x86/platform/efi/efi.c
>
> between commit:
>
> 1e82b9479070 ("x86/efi: Show actual ending addresses in efi_print_memmap")
>
> from the tip tree and commit:
>
> e0532ef9f825 ("x86/efi: print size and base in binary units in efi_print_memmap")
>
> from the akpm tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
I think Andrew agreed to drop this patch from his tree,
https://lkml.kernel.org/r/20160122151100.GA3747@codeblueprint.co.uk
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2016-02-09 14:04 ` Matt Fleming
@ 2016-02-09 14:07 ` Ingo Molnar
0 siblings, 0 replies; 85+ messages in thread
From: Ingo Molnar @ 2016-02-09 14:07 UTC (permalink / raw)
To: Matt Fleming
Cc: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel,
Robert Elliott, Andy Shevchenko
* Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Tue, 09 Feb, at 03:50:24PM, Stephen Rothwell wrote:
> > Hi Andrew,
> >
> > Today's linux-next merge of the akpm tree got a conflict in:
> >
> > arch/x86/platform/efi/efi.c
> >
> > between commit:
> >
> > 1e82b9479070 ("x86/efi: Show actual ending addresses in efi_print_memmap")
> >
> > from the tip tree and commit:
> >
> > e0532ef9f825 ("x86/efi: print size and base in binary units in efi_print_memmap")
> >
> > from the akpm tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
>
> I think Andrew agreed to drop this patch from his tree,
>
> https://lkml.kernel.org/r/20160122151100.GA3747@codeblueprint.co.uk
... and I tried to follow up on the original submission to still preserve this
change, as it's no doubt useful to produce easier to read bootup messages.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2015-06-09 14:12 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2015-06-09 14:12 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: linux-next, linux-kernel, Josh Triplett, Denys Vlasenko
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/entry/entry_64_compat.S between commit 7a5a9824c18f
("x86/asm/entry/32: Remove unnecessary optimization in stub32_clone")
from the tip tree and commit cfb3fabb5c2c ("x86: opt into
HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit") from the akpm tree.
I fixed it up (they had the same effect on this file, so I just used
the tip tree version) and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2015-04-08 8:49 Stephen Rothwell
2015-04-08 15:13 ` Ingo Molnar
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2015-04-08 8:49 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: linux-next, linux-kernel, Borislav Petkov
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/cpu/common.c between commit 6b51311c9765
("x86/asm/entry/64: Use a define for an invalid segment selector") from
the tip tree and commit f28c11e4b695 ("arch/x86/kernel/cpu/common.c:
fix warning") from the akpm tree.
I fixed it up (I just used the tip tree version) and can carry the fix
as necessary (no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2015-04-08 8:49 Stephen Rothwell
@ 2015-04-08 15:13 ` Ingo Molnar
2015-04-08 20:46 ` Andrew Morton
2015-04-08 21:57 ` Stephen Rothwell
0 siblings, 2 replies; 85+ messages in thread
From: Ingo Molnar @ 2015-04-08 15:13 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Borislav Petkov
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> arch/x86/kernel/cpu/common.c between commit 6b51311c9765
> ("x86/asm/entry/64: Use a define for an invalid segment selector") from
> the tip tree and commit f28c11e4b695 ("arch/x86/kernel/cpu/common.c:
> fix warning") from the akpm tree.
So f28c11e4b695 doesn't appear to be in linux-next as fetched a minute
ago:
triton:~/linux.trees.git> git log f28c11e4b695 --
fatal: bad revision 'f28c11e4b695'
triton:~/linux.trees.git> git describe
next-20150408
How am I supposed to fetch and interpret such sha1's?
Thanks,
Ingo
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2015-04-08 15:13 ` Ingo Molnar
@ 2015-04-08 20:46 ` Andrew Morton
2015-04-08 21:57 ` Stephen Rothwell
1 sibling, 0 replies; 85+ messages in thread
From: Andrew Morton @ 2015-04-08 20:46 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Borislav Petkov
On Wed, 8 Apr 2015 17:13:51 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Andrew,
> >
> > Today's linux-next merge of the akpm tree got a conflict in
> > arch/x86/kernel/cpu/common.c between commit 6b51311c9765
> > ("x86/asm/entry/64: Use a define for an invalid segment selector") from
> > the tip tree and commit f28c11e4b695 ("arch/x86/kernel/cpu/common.c:
> > fix warning") from the akpm tree.
>
> So f28c11e4b695 doesn't appear to be in linux-next as fetched a minute
> ago:
>
> triton:~/linux.trees.git> git log f28c11e4b695 --
> fatal: bad revision 'f28c11e4b695'
> triton:~/linux.trees.git> git describe
> next-20150408
>
> How am I supposed to fetch and interpret such sha1's?
Stephen didn't include the -mm patch so I guess that ID never was
included in -next.
For -mm patches the place to bookmark is
http://ozlabs.org/~akpm/mmotm/broken-out/.
This:
http://ozlabs.org/~akpm/mmotm/broken-out/arch-x86-kernel-cpu-commonc-fix-warning.patch
It sounds like the warning has now been fixed.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2015-04-08 15:13 ` Ingo Molnar
2015-04-08 20:46 ` Andrew Morton
@ 2015-04-08 21:57 ` Stephen Rothwell
1 sibling, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2015-04-08 21:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, linux-next, linux-kernel, Borislav Petkov
[-- Attachment #1: Type: text/plain, Size: 2402 bytes --]
Hi Ingo,
On Wed, 8 Apr 2015 17:13:51 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Today's linux-next merge of the akpm tree got a conflict in
> > arch/x86/kernel/cpu/common.c between commit 6b51311c9765
> > ("x86/asm/entry/64: Use a define for an invalid segment selector") from
> > the tip tree and commit f28c11e4b695 ("arch/x86/kernel/cpu/common.c:
> > fix warning") from the akpm tree.
>
> So f28c11e4b695 doesn't appear to be in linux-next as fetched a minute
> ago:
>
> triton:~/linux.trees.git> git log f28c11e4b695 --
> fatal: bad revision 'f28c11e4b695'
> triton:~/linux.trees.git> git describe
> next-20150408
>
> How am I supposed to fetch and interpret such sha1's?
Sorry, this was a special case. This was a patch in the part of
Andrew's series that gets rebased on top of the rest of linux-next each
day (as that part has dependencies on other things in linux-next). In
this case, the resolution was to drop the patch entirely as it had
become unnecessary.
This was it:
From: Andrew Morton <akpm@linux-foundation.org>
Subject: arch/x86/kernel/cpu/common.c: fix warning
x86_64 allnoconfig:
arch/x86/kernel/cpu/common.c: In function 'syscall_init':
arch/x86/kernel/cpu/common.c:1225: warning: right shift count >= width of type
Fixes: a76c7f4604937bc ("x86/asm/entry/64: Fold syscall32_cpu_init() into its sole user")
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/kernel/cpu/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/x86/kernel/cpu/common.c~arch-x86-kernel-cpu-commonc-fix-warning arch/x86/kernel/cpu/common.c
--- a/arch/x86/kernel/cpu/common.c~arch-x86-kernel-cpu-commonc-fix-warning
+++ a/arch/x86/kernel/cpu/common.c
@@ -1222,7 +1222,7 @@ void syscall_init(void)
wrmsrl_safe(MSR_IA32_SYSENTER_EIP, (u64)ia32_sysenter_target);
#else
wrmsrl(MSR_CSTAR, ignore_sysret);
- wrmsrl_safe(MSR_IA32_SYSENTER_CS, 0);
+ wrmsrl_safe(MSR_IA32_SYSENTER_CS, 0ULL);
wrmsrl_safe(MSR_IA32_SYSENTER_ESP, 0ULL);
wrmsrl_safe(MSR_IA32_SYSENTER_EIP, 0ULL);
#endif
_
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2014-03-21 6:45 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2014-03-21 6:45 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: linux-next, linux-kernel, Frederic Weisbecker, Mark Salter
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/include/asm/Kbuild between commit 073d8224d299 ("arch: Remove
stub cputime.h headers") from the tip tree and commit "x86: use generic
early_ioremap" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/include/asm/Kbuild
index 4acddc43ee0c,c98cd05d1cdf..000000000000
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@@ -5,5 -5,5 +5,6 @@@ genhdr-y += unistd_64.
genhdr-y += unistd_x32.h
generic-y += clkdev.h
+generic-y += cputime.h
+ generic-y += early_ioremap.h
generic-y += mcs_spinlock.h
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2014-01-13 6:17 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2014-01-13 6:17 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: linux-next, linux-kernel, Joe Perches
[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
kernel/softirq.c between commit c795eb55e740 ("sched/preempt, locking:
Rework local_bh_{dis,en}able()") from the tip tree and commit ("softirq:
use const char * const for softirq_to_name, whitespace neatening") from
the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc kernel/softirq.c
index e60c41d0087a,527520152ad2..000000000000
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@@ -138,10 -149,9 +138,9 @@@ void _local_bh_enable(void
WARN_ON_ONCE(in_irq());
__local_bh_enable(SOFTIRQ_DISABLE_OFFSET);
}
-
EXPORT_SYMBOL(_local_bh_enable);
-static inline void _local_bh_enable_ip(unsigned long ip)
+void __local_bh_enable_ip(unsigned long ip, unsigned int cnt)
{
WARN_ON_ONCE(in_irq() || irqs_disabled());
#ifdef CONFIG_TRACE_IRQFLAGS
@@@ -155,8 -165,8 +154,8 @@@
/*
* Keep preemption disabled until we are done with
* softirq processing:
- */
+ */
- preempt_count_sub(SOFTIRQ_DISABLE_OFFSET - 1);
+ preempt_count_sub(cnt - 1);
if (unlikely(!in_interrupt() && local_softirq_pending())) {
/*
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2013-04-23 7:17 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2013-04-23 7:17 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Frederic Weisbecker, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
kernel/posix-cpu-timers.c between commits a85721601ad2 ("posix_timers:
Kick full dynticks CPUs when a posix cpu timer is armed") and
555347f6c080 ("posix_timers: New API to prevent from stopping the tick
when timers are running") from the tip tree and commit "posix_cpu_timer:
consolidate expiry time type" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc kernel/posix-cpu-timers.c
index 84d5cb3,e5286b5..0000000
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@@ -155,22 -106,7 +108,22 @@@ static void bump_cpu_timer(struct k_iti
}
}
+/**
+ * task_cputime_zero - Check a task_cputime struct for all zero fields.
+ *
+ * @cputime: The struct to compare.
+ *
+ * Checks @cputime to see if all fields are zero. Returns true if all fields
+ * are zero, false if any field is nonzero.
+ */
+static inline int task_cputime_zero(const struct task_cputime *cputime)
+{
+ if (!cputime->utime && !cputime->stime && !cputime->sum_exec_runtime)
+ return 1;
+ return 0;
+}
+
- static inline cputime_t prof_ticks(struct task_struct *p)
+ static inline unsigned long long prof_ticks(struct task_struct *p)
{
cputime_t utime, stime;
@@@ -1408,8 -1312,8 +1354,8 @@@ void set_process_cpu_timer(struct task_
}
if (!*newval)
- return;
+ goto out;
- *newval += now.cpu;
+ *newval += now;
}
/*
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2013-02-14 4:33 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2013-02-14 4:33 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Kent Overstreet, Clark Williams,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
include/linux/sched.h between commit cf4aebc292fa ("sched: Move sched.h
sysctl bits into separate header") from the tip tree and commit "aio:
don't include aio.h in sched.h" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/sched.h
index fe38049,f0e3a11..0000000
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@@ -326,8 -339,23 +326,6 @@@ extern int mutex_spin_on_owner(struct m
struct nsproxy;
struct user_namespace;
- #include <linux/aio.h>
-
-/*
- * Default maximum number of active map areas, this limits the number of vmas
- * per mm struct. Users can overwrite this number by sysctl but there is a
- * problem.
- *
- * When a program's coredump is generated as ELF format, a section is created
- * per a vma. In ELF, the number of sections is represented in unsigned short.
- * This means the number of sections should be smaller than 65535 at coredump.
- * Because the kernel adds some informative sections to a image of program at
- * generating coredump, we need some margin. The number of extra sections is
- * 1-3 now and depends on arch. We use "5" as safe margin, here.
- */
-#define MAPCOUNT_ELF_CORE_MARGIN (5)
-#define DEFAULT_MAX_MAP_COUNT (USHRT_MAX - MAPCOUNT_ELF_CORE_MARGIN)
-
-extern int sysctl_max_map_count;
-
#ifdef CONFIG_MMU
extern void arch_pick_mmap_layout(struct mm_struct *mm);
extern unsigned long
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2013-02-14 4:25 Stephen Rothwell
2013-02-14 4:34 ` H. Peter Anvin
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2013-02-14 4:25 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Dagfinn Ilmari Mannsåker
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
kernel/timeconst.pl between commit 63a3f603413f ("timeconst.pl: Eliminate
Perl warning") from the tip tree and commit "timeconst.pl: remove
deprecated defined(@array)" from the akpm tree.
These both fix the same problem, I arbitrarily chose the akpm tree version.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2013-02-14 4:25 Stephen Rothwell
@ 2013-02-14 4:34 ` H. Peter Anvin
0 siblings, 0 replies; 85+ messages in thread
From: H. Peter Anvin @ 2013-02-14 4:34 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Thomas Gleixner,
Ingo Molnar, Peter Zijlstra, Dagfinn Ilmari Mannsåker
On 02/13/2013 08:25 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> kernel/timeconst.pl between commit 63a3f603413f ("timeconst.pl: Eliminate
> Perl warning") from the tip tree and commit "timeconst.pl: remove
> deprecated defined(@array)" from the akpm tree.
>
> These both fix the same problem, I arbitrarily chose the akpm tree version.
>
I should try to resurrect the bc version (which doesn't need the canning
junk, bc being the POSIX tool for arbitrary-precision arithmetic.)
There was an error on one of akpm's machines long ago which confused the
bcrap out of us, because bc hadn't changed, but recently someone pointed
to a bug in *make* (relating to pipes) from around that era which would
have explained (a) the failure, and (b) why it only hit one box even
though bc was the exact same version.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2013-02-04 7:00 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2013-02-04 7:00 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Yasuaki Ishimatsu
[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/mm/numa.c between commit 07f4207a305c ("x86-32, mm: Remove
reference to alloc_remap()") from the tip tree and commit "x86: get
pg_data_t's memory from other node" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/mm/numa.c
index a8483df,245a4ba..0000000
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@@ -209,22 -213,27 +209,21 @@@ static void __init setup_node_data(int
nid, start, end - 1);
/*
- * Allocate node data. Try remap allocator first, node-local
- * memory and then any node. Never allocate in DMA zone.
+ * Allocate node data. Try node-local memory and then any node.
+ * Never allocate in DMA zone.
*/
- nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
- nd = alloc_remap(nid, nd_size);
- if (nd) {
- nd_pa = __phys_addr_nodebug(nd);
- remapped = true;
- } else {
- nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
- if (!nd_pa) {
- pr_err("Cannot find %zu bytes in any node\n", nd_size);
- return;
- }
- nd = __va(nd_pa);
++ nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
+ if (!nd_pa) {
- pr_err("Cannot find %zu bytes in node %d\n",
- nd_size, nid);
++ pr_err("Cannot find %zu bytes in any node\n", nd_size);
+ return;
}
+ nd = __va(nd_pa);
/* report and initialize */
- printk(KERN_INFO " NODE_DATA [mem %#010Lx-%#010Lx]%s\n",
- nd_pa, nd_pa + nd_size - 1, remapped ? " (remapped)" : "");
+ printk(KERN_INFO " NODE_DATA [mem %#010Lx-%#010Lx]\n",
+ nd_pa, nd_pa + nd_size - 1);
tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
- if (!remapped && tnid != nid)
+ if (tnid != nid)
printk(KERN_INFO " NODE_DATA(%d) on node %d\n", nid, tnid);
node_data[nid] = nd;
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2013-01-28 12:29 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2013-01-28 12:29 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Shaohua Li, Wang YanQing,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 4939 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in kernel/smp.c between commit c7b798525b50 ("smp: Fix SMP function call empty cpu mask race") from the tip tree and commit "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" from the akpm tree.
I fixed it up (maybe - see below) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc kernel/smp.c
index 93e576e,51a81b0..0000000
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@@ -30,10 -21,8 +21,9 @@@ enum
};
struct call_function_data {
- struct call_single_data csd;
- atomic_t refs;
+ struct call_single_data __percpu *csd;
cpumask_var_t cpumask;
+ cpumask_var_t cpumask_ipi;
};
static DEFINE_PER_CPU_SHARED_ALIGNED(struct call_function_data, cfd_data);
@@@ -482,85 -397,39 +398,45 @@@ void smp_call_function_many(const struc
}
data = &__get_cpu_var(cfd_data);
- csd_lock(&data->csd);
-
- /* This BUG_ON verifies our reuse assertions and can be removed */
- BUG_ON(atomic_read(&data->refs) || !cpumask_empty(data->cpumask));
-
- /*
- * The global call function queue list add and delete are protected
- * by a lock, but the list is traversed without any lock, relying
- * on the rcu list add and delete to allow safe concurrent traversal.
- * We reuse the call function data without waiting for any grace
- * period after some other cpu removes it from the global queue.
- * This means a cpu might find our data block as it is being
- * filled out.
- *
- * We hold off the interrupt handler on the other cpu by
- * ordering our writes to the cpu mask vs our setting of the
- * refs counter. We assert only the cpu owning the data block
- * will set a bit in cpumask, and each bit will only be cleared
- * by the subject cpu. Each cpu must first find its bit is
- * set and then check that refs is set indicating the element is
- * ready to be processed, otherwise it must skip the entry.
- *
- * On the previous iteration refs was set to 0 by another cpu.
- * To avoid the use of transitivity, set the counter to 0 here
- * so the wmb will pair with the rmb in the interrupt handler.
- */
- atomic_set(&data->refs, 0); /* convert 3rd to 1st party write */
- data->csd.func = func;
- data->csd.info = info;
-
- /* Ensure 0 refs is visible before mask. Also orders func and info */
- smp_wmb();
-
- /* We rely on the "and" being processed before the store */
cpumask_and(data->cpumask, mask, cpu_online_mask);
cpumask_clear_cpu(this_cpu, data->cpumask);
- refs = cpumask_weight(data->cpumask);
/* Some callers race with other cpus changing the passed mask */
- if (unlikely(!refs)) {
- csd_unlock(&data->csd);
+ if (unlikely(!cpumask_weight(data->cpumask)))
return;
- }
+ /*
+ * After we put an entry into the list, data->cpumask
+ * may be cleared again when another CPU sends another IPI for
+ * a SMP function call, so data->cpumask will be zero.
+ */
+ cpumask_copy(data->cpumask_ipi, data->cpumask);
- raw_spin_lock_irqsave(&call_function.lock, flags);
- /*
- * Place entry at the _HEAD_ of the list, so that any cpu still
- * observing the entry in generic_smp_call_function_interrupt()
- * will not miss any other list entries:
- */
- list_add_rcu(&data->csd.list, &call_function.queue);
- /*
- * We rely on the wmb() in list_add_rcu to complete our writes
- * to the cpumask before this write to refs, which indicates
- * data is on the list and is ready to be processed.
- */
- atomic_set(&data->refs, refs);
- raw_spin_unlock_irqrestore(&call_function.lock, flags);
-
- /*
- * Make the list addition visible before sending the ipi.
- * (IPIs must obey or appear to obey normal Linux cache
- * coherency rules -- see comment in generic_exec_single).
- */
- smp_mb();
+ for_each_cpu(cpu, data->cpumask) {
+ struct call_single_data *csd = per_cpu_ptr(data->csd, cpu);
+ struct call_single_queue *dst =
+ &per_cpu(call_single_queue, cpu);
+ unsigned long flags;
+
+ csd_lock(csd);
+ csd->func = func;
+ csd->info = info;
+
+ raw_spin_lock_irqsave(&dst->lock, flags);
+ list_add_tail(&csd->list, &dst->list);
+ raw_spin_unlock_irqrestore(&dst->lock, flags);
+ }
/* Send a message to all CPUs in the map */
- arch_send_call_function_ipi_mask(data->cpumask);
+ arch_send_call_function_ipi_mask(data->cpumask_ipi);
- /* Optionally wait for the CPUs to complete */
- if (wait)
- csd_lock_wait(&data->csd);
+ if (wait) {
+ for_each_cpu(cpu, data->cpumask) {
+ struct call_single_data *csd =
+ per_cpu_ptr(data->csd, cpu);
+ csd_lock_wait(csd);
+ }
+ }
}
EXPORT_SYMBOL(smp_call_function_many);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-12-10 8:29 Stephen Rothwell
2012-12-10 10:46 ` Ingo Molnar
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2012-12-10 8:29 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Kirill A. Shutemov, Lee Schermerhorn,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in mm/mprotect.c
between commit ("2083d67027ad") from the tip tree and commit "thp:
change split_huge_page_pmd() interface" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc mm/mprotect.c
index b5be3f1,d74a6fb..0000000
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@@ -126,8 -89,8 +126,8 @@@ static inline unsigned long change_pmd_
next = pmd_addr_end(addr, end);
if (pmd_trans_huge(*pmd)) {
if (next - addr != HPAGE_PMD_SIZE)
- split_huge_page_pmd(vma->vm_mm, pmd);
+ split_huge_page_pmd(vma, addr, pmd);
- else if (change_huge_pmd(vma, pmd, addr, newprot)) {
+ else if (change_huge_pmd(vma, pmd, addr, newprot, prot_numa)) {
pages += HPAGE_PMD_NR;
continue;
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-12-10 8:29 Stephen Rothwell
@ 2012-12-10 10:46 ` Ingo Molnar
0 siblings, 0 replies; 85+ messages in thread
From: Ingo Molnar @ 2012-12-10 10:46 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Kirill A. Shutemov,
Lee Schermerhorn, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
hi Stephen,
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in mm/mprotect.c
> between commit ("2083d67027ad") from the tip tree and commit "thp:
> change split_huge_page_pmd() interface" from the akpm tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
I pre-checked linux-next on Friday, and the attached tarball
with updated akpm patches needed conflict resolutions.
0178-mm-mempolicy-remove-duplicate-code.patch can be dropped I
think.
Note that the merges are not tested though, so it's a JFYI.
Assuming the akpm tree still has roughly the same structure as
the last linux-next tree had.
Thanks,
Ingo
[-- Attachment #2: tip-merged-for-akpm.tar.gz --]
[-- Type: application/x-gzip, Size: 10652 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-12-10 8:25 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-12-10 8:25 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Kirill A. Shutemov, Lee Schermerhorn,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 2718 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/huge_memory.c between commit 2083d67027ad ("mm/mempolicy: Implement
change_prot_numa() in terms of change_protection()") from the tip, tree
and commit "thp: change_huge_pmd(): make sure we don't try to make a page
writable" from the akpm tree.
I fixed it up (I think - see below) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/migrate.h
index bcb5ddc,50d2974..0000000
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@@ -7,16 -7,13 +7,23 @@@
typedef struct page *new_page_t(struct page *, unsigned long private, int **);
+enum migrate_reason {
+ MR_COMPACTION,
+ MR_MEMORY_FAILURE,
+ MR_MEMORY_HOTPLUG,
+ MR_SYSCALL, /* also applies to cpusets */
+ MR_MEMPOLICY_MBIND,
+ MR_NUMA_MISPLACED,
+ MR_CMA
+};
+
+ /*
+ * Return values from addresss_space_operations.migratepage():
+ * - negative errno on page migration failure;
+ * - zero on page migration success;
+ */
+ #define MIGRATEPAGE_SUCCESS 0
+
#ifdef CONFIG_MIGRATION
extern void putback_lru_pages(struct list_head *l);
diff --cc mm/migrate.c
index c0afe60,c3724b6..0000000
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@@ -981,8 -977,7 +981,8 @@@ int migrate_pages(struct list_head *fro
case -EAGAIN:
retry++;
break;
- case 0:
+ case MIGRATEPAGE_SUCCESS:
+ nr_succeeded++;
break;
default:
/* Permanent failure */
@@@ -991,14 -986,8 +991,14 @@@
}
}
}
- rc = 0;
+ rc = nr_failed + retry;
out:
+ if (nr_succeeded)
+ count_vm_events(PGMIGRATE_SUCCESS, nr_succeeded);
+ if (nr_failed)
+ count_vm_events(PGMIGRATE_FAIL, nr_failed);
+ trace_mm_migrate_pages(nr_succeeded, nr_failed, mode, reason);
+
if (!swapwrite)
current->flags &= ~PF_SWAPWRITE;
diff --cc mm/huge_memory.c
index 2c4e4d4,28a368c..0000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -1352,17 -1433,8 +1352,18 @@@ int change_huge_pmd(struct vm_area_stru
if (__pmd_trans_huge_lock(pmd, vma) == 1) {
pmd_t entry;
entry = pmdp_get_and_clear(mm, addr, pmd);
- entry = pmd_modify(entry, newprot);
+ if (!prot_numa)
+ entry = pmd_modify(entry, newprot);
+ else {
+ struct page *page = pmd_page(*pmd);
+
+ /* only check non-shared pages */
+ if (page_mapcount(page) == 1 &&
+ !pmd_numa(*pmd)) {
+ entry = pmd_mknuma(entry);
+ }
+ }
+ BUG_ON(pmd_write(entry));
set_pmd_at(mm, addr, pmd, entry);
spin_unlock(&vma->vm_mm->page_table_lock);
ret = 1;
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-12-10 8:20 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-12-10 8:20 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, David Rientjes, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/mempolicy.c between commit d9f1eb872704 ("numa, mempolicy: Improve
CONFIG_NUMA_BALANCING=y OOM behavior") from the tip tree and commit "mm,
mempolicy: remove duplicate code" from the akpm tree.
I can't tell if the akpm tree patch is still relevant, so I dropped it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-12-10 8:11 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-12-10 8:11 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Rafael Aquini, Mel Gorman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got conflicts in mm/migrate.c
and include/linux/migrate.h between commits 070059b28578 ("mm/compaction:
Move migration fail/success stats to migrate.c") and 2d85cca46951
("mm/migrate: Add a tracepoint for migrate_pages") from the tip tree and
commit "mm: adjust address_space_operations.migratepage() return code"
from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/migrate.h
index bcb5ddc,50d2974..0000000
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@@ -7,16 -7,13 +7,23 @@@
typedef struct page *new_page_t(struct page *, unsigned long private, int **);
+enum migrate_reason {
+ MR_COMPACTION,
+ MR_MEMORY_FAILURE,
+ MR_MEMORY_HOTPLUG,
+ MR_SYSCALL, /* also applies to cpusets */
+ MR_MEMPOLICY_MBIND,
+ MR_NUMA_MISPLACED,
+ MR_CMA
+};
+
+ /*
+ * Return values from addresss_space_operations.migratepage():
+ * - negative errno on page migration failure;
+ * - zero on page migration success;
+ */
+ #define MIGRATEPAGE_SUCCESS 0
+
#ifdef CONFIG_MIGRATION
extern void putback_lru_pages(struct list_head *l);
diff --cc mm/migrate.c
index c0afe60,c3724b6..0000000
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@@ -981,8 -977,7 +981,8 @@@ int migrate_pages(struct list_head *fro
case -EAGAIN:
retry++;
break;
- case 0:
+ case MIGRATEPAGE_SUCCESS:
+ nr_succeeded++;
break;
default:
/* Permanent failure */
@@@ -991,14 -986,8 +991,14 @@@
}
}
}
- rc = 0;
+ rc = nr_failed + retry;
out:
+ if (nr_succeeded)
+ count_vm_events(PGMIGRATE_SUCCESS, nr_succeeded);
+ if (nr_failed)
+ count_vm_events(PGMIGRATE_FAIL, nr_failed);
+ trace_mm_migrate_pages(nr_succeeded, nr_failed, mode, reason);
+
if (!swapwrite)
current->flags &= ~PF_SWAPWRITE;
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-12-10 8:01 Stephen Rothwell
2012-12-10 11:13 ` Will Deacon
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2012-12-10 8:01 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Will Deacon, Mel Gorman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in mm/memory.c
between changes in commits from the tip tree and commit "mm: thp: set the
accessed flag for old pages on access fault" from the akpm tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc mm/memory.c
index 8022526,60201d5..0000000
--- a/mm/memory.c
+++ b/mm/memory.c
@@@ -3812,15 -3620,18 +3812,17 @@@ retry
pmd, flags);
} else {
pmd_t orig_pmd = *pmd;
- int ret = 0;
+ int ret;
barrier();
- if (pmd_trans_huge(orig_pmd) && !pmd_trans_splitting(orig_pmd)) {
+ if (pmd_trans_huge(orig_pmd)) {
+ unsigned int dirty = flags & FAULT_FLAG_WRITE;
+
- if (pmd_numa(vma, orig_pmd)) {
- do_huge_pmd_numa_page(mm, vma, address, pmd,
- flags, orig_pmd);
- }
+ if (pmd_numa(*pmd))
+ return do_huge_pmd_numa_page(mm, vma, address,
+ orig_pmd, pmd);
- if ((flags & FAULT_FLAG_WRITE) && !pmd_write(orig_pmd)) {
+ if (dirty && !pmd_write(orig_pmd)) {
ret = do_huge_pmd_wp_page(mm, vma, address, pmd,
orig_pmd);
/*
@@@ -3830,10 -3641,12 +3832,13 @@@
*/
if (unlikely(ret & VM_FAULT_OOM))
goto retry;
+ return ret;
+ } else {
+ huge_pmd_set_accessed(mm, vma, address, pmd,
+ orig_pmd, dirty);
}
- return ret;
+ return 0;
}
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-12-10 8:01 Stephen Rothwell
@ 2012-12-10 11:13 ` Will Deacon
0 siblings, 0 replies; 85+ messages in thread
From: Will Deacon @ 2012-12-10 11:13 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Mel Gorman,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Hi guys,
On Mon, Dec 10, 2012 at 08:01:39AM +0000, Stephen Rothwell wrote:
> Today's linux-next merge of the akpm tree got a conflict in mm/memory.c
> between changes in commits from the tip tree and commit "mm: thp: set the
> accessed flag for old pages on access fault" from the akpm tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
[...]
> diff --cc mm/memory.c
> index 8022526,60201d5..0000000
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@@ -3812,15 -3620,18 +3812,17 @@@ retry
> pmd, flags);
> } else {
> pmd_t orig_pmd = *pmd;
> - int ret = 0;
> + int ret;
>
> barrier();
> - if (pmd_trans_huge(orig_pmd) && !pmd_trans_splitting(orig_pmd)) {
> + if (pmd_trans_huge(orig_pmd)) {
This change worries me a bit wrt the huge_pmd_set_accessed function I
introduce below. Unfortunately, current -next doesn't seem to include it, so
I can't see whether do_huge_pmd_numa_page / do_huge_pmd_wp_page have been
changed to deal with the splitting or whether the check has been moved
earlier.
Will
> + unsigned int dirty = flags & FAULT_FLAG_WRITE;
> +
> - if (pmd_numa(vma, orig_pmd)) {
> - do_huge_pmd_numa_page(mm, vma, address, pmd,
> - flags, orig_pmd);
> - }
> + if (pmd_numa(*pmd))
> + return do_huge_pmd_numa_page(mm, vma, address,
> + orig_pmd, pmd);
>
> - if ((flags & FAULT_FLAG_WRITE) && !pmd_write(orig_pmd)) {
> + if (dirty && !pmd_write(orig_pmd)) {
> ret = do_huge_pmd_wp_page(mm, vma, address, pmd,
> orig_pmd);
> /*
> @@@ -3830,10 -3641,12 +3832,13 @@@
> */
> if (unlikely(ret & VM_FAULT_OOM))
> goto retry;
> + return ret;
> + } else {
> + huge_pmd_set_accessed(mm, vma, address, pmd,
> + orig_pmd, dirty);
> }
>
> - return ret;
> + return 0;
> }
> }
>
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-12-10 7:47 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-12-10 7:47 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Kirill A. Shutemov, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Mel Gorman
[-- Attachment #1: Type: text/plain, Size: 531 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/huge_memory.c between various commits from the tip tree and commit
"thp: fix update_mmu_cache_pmd() calls" from the akpm tree.
It appears that the shed/numa patches in the tip tree have been changed
in today's version of the tip tree and this akpm tree patch no longer
applies.
I dropped the akpm tree patch and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-11-15 6:32 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-11-15 6:32 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Kirill A. Shutemov
[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in mm/mprotect.c
between commit a9463d90124a ("mm: Count the number of pages affected in
change_protection()") from the tip tree and commit "thp: change
split_huge_page_pmd() interface" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc mm/mprotect.c
index 6ff2d5e,cbafe4b..0000000
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@@ -89,11 -83,9 +89,11 @@@ static inline unsigned long change_pmd_
next = pmd_addr_end(addr, end);
if (pmd_trans_huge(*pmd)) {
if (next - addr != HPAGE_PMD_SIZE)
- split_huge_page_pmd(vma->vm_mm, pmd);
+ split_huge_page_pmd(vma, addr, pmd);
- else if (change_huge_pmd(vma, pmd, addr, newprot))
+ else if (change_huge_pmd(vma, pmd, addr, newprot)) {
+ pages += HPAGE_PMD_NR;
continue;
+ }
/* fall through */
}
if (pmd_none_or_clear_bad(pmd))
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-10-01 14:22 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-10-01 14:22 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Mel Gorman, KOSAKI Motohiro
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/mempolicy.c between commit e9d5bc24d665 ("mm/mpol: Make mempolicy
home-node aware") from the tip tree and commit "mempolicy: fix a memory
corruption by refcount imbalance in alloc_pages_vma()" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc mm/mempolicy.c
index 6e2cd87,3c23d89..0000000
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@@ -1603,7 -1587,8 +1603,8 @@@ asmlinkage long compat_sys_mbind(compat
struct mempolicy *get_vma_policy(struct task_struct *task,
struct vm_area_struct *vma, unsigned long addr)
{
- struct mempolicy *pol = task->mempolicy;
+ struct mempolicy *pol = get_task_policy(task);
+ int got_ref;
if (vma) {
if (vma->vm_ops && vma->vm_ops->get_policy) {
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-09-27 7:15 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-09-27 7:15 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Gerald Schaefer
[-- Attachment #1: Type: text/plain, Size: 4824 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/huge_memory.c between commit 93c9d633bd9e ("93c9d633bd9e") from the
tip tree and commit "thp: introduce pmdp_invalidate()" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc mm/huge_memory.c
index 9267537,56f9443..0000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -1384,55 -1312,59 +1384,54 @@@ static int __split_huge_page_map(struc
spin_lock(&mm->page_table_lock);
pmd = page_check_address_pmd(page, mm, address,
PAGE_CHECK_ADDRESS_PMD_SPLITTING_FLAG);
- if (pmd) {
- pgtable = pgtable_trans_huge_withdraw(mm);
- pmd_populate(mm, &_pmd, pgtable);
-
- for (i = 0, haddr = address; i < HPAGE_PMD_NR;
- i++, haddr += PAGE_SIZE) {
- pte_t *pte, entry;
- BUG_ON(PageCompound(page+i));
- entry = mk_pte(page + i, vma->vm_page_prot);
- entry = maybe_mkwrite(pte_mkdirty(entry), vma);
- if (!pmd_write(*pmd))
- entry = pte_wrprotect(entry);
- else
- BUG_ON(page_mapcount(page) != 1);
- if (!pmd_young(*pmd))
- entry = pte_mkold(entry);
- pte = pte_offset_map(&_pmd, haddr);
- BUG_ON(!pte_none(*pte));
- set_pte_at(mm, haddr, pte, entry);
- pte_unmap(pte);
- }
+ if (!pmd)
+ goto unlock;
- smp_wmb(); /* make pte visible before pmd */
- /*
- * Up to this point the pmd is present and huge and
- * userland has the whole access to the hugepage
- * during the split (which happens in place). If we
- * overwrite the pmd with the not-huge version
- * pointing to the pte here (which of course we could
- * if all CPUs were bug free), userland could trigger
- * a small page size TLB miss on the small sized TLB
- * while the hugepage TLB entry is still established
- * in the huge TLB. Some CPU doesn't like that. See
- * http://support.amd.com/us/Processor_TechDocs/41322.pdf,
- * Erratum 383 on page 93. Intel should be safe but is
- * also warns that it's only safe if the permission
- * and cache attributes of the two entries loaded in
- * the two TLB is identical (which should be the case
- * here). But it is generally safer to never allow
- * small and huge TLB entries for the same virtual
- * address to be loaded simultaneously. So instead of
- * doing "pmd_populate(); flush_tlb_range();" we first
- * mark the current pmd notpresent (atomically because
- * here the pmd_trans_huge and pmd_trans_splitting
- * must remain set at all times on the pmd until the
- * split is complete for this pmd), then we flush the
- * SMP TLB and finally we write the non-huge version
- * of the pmd entry with pmd_populate.
- */
- pmdp_invalidate(vma, address, pmd);
- pmd_populate(mm, pmd, pgtable);
- ret = 1;
+ prot = pmd_pgprot(*pmd);
+ pgtable = pgtable_trans_huge_withdraw(mm);
+ pmd_populate(mm, &_pmd, pgtable);
+
+ for (i = 0, haddr = address; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
+ pte_t *pte, entry;
+
+ BUG_ON(PageCompound(page+i));
+ entry = mk_pte(page + i, prot);
+ entry = pte_mkdirty(entry);
+ if (!pmd_young(*pmd))
+ entry = pte_mkold(entry);
+ pte = pte_offset_map(&_pmd, haddr);
+ BUG_ON(!pte_none(*pte));
+ set_pte_at(mm, haddr, pte, entry);
+ pte_unmap(pte);
}
+
+ smp_wmb(); /* make ptes visible before pmd, see __pte_alloc */
+ /*
+ * Up to this point the pmd is present and huge.
+ *
+ * If we overwrite the pmd with the not-huge version, we could trigger
+ * a small page size TLB miss on the small sized TLB while the hugepage
+ * TLB entry is still established in the huge TLB.
+ *
+ * Some CPUs don't like that. See
+ * http://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum 383
+ * on page 93.
+ *
+ * Thus it is generally safer to never allow small and huge TLB entries
+ * for overlapping virtual addresses to be loaded. So we first mark the
+ * current pmd not present, then we flush the TLB and finally we write
+ * the non-huge version of the pmd entry with pmd_populate.
+ *
+ * The above needs to be done under the ptl because pmd_trans_huge and
+ * pmd_trans_splitting must remain set on the pmd until the split is
+ * complete. The ptl also protects against concurrent faults due to
+ * making the pmd not-present.
+ */
- set_pmd_at(mm, address, pmd, pmd_mknotpresent(*pmd));
- flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
++ pmdp_invalidate(vma, address, pmd);
+ pmd_populate(mm, pmd, pgtable);
+ ret = 1;
+
+unlock:
spin_unlock(&mm->page_table_lock);
return ret;
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-09-27 7:10 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-09-27 7:10 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Gerald Schaefer
[-- Attachment #1: Type: text/plain, Size: 4947 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/huge_memory.c between commit 93c9d633bd9e ("mm/thp: Preserve pgprot
across huge page split") from the tip tree and commit ("thp: remove
assumptions on pgtable_t type") from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc mm/huge_memory.c
index 6b176fe,a91bc3c..0000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -1416,55 -1312,60 +1384,55 @@@ static int __split_huge_page_map(struc
spin_lock(&mm->page_table_lock);
pmd = page_check_address_pmd(page, mm, address,
PAGE_CHECK_ADDRESS_PMD_SPLITTING_FLAG);
- if (pmd) {
- pgtable = pgtable_trans_huge_withdraw(mm);
- pmd_populate(mm, &_pmd, pgtable);
-
- for (i = 0, haddr = address; i < HPAGE_PMD_NR;
- i++, haddr += PAGE_SIZE) {
- pte_t *pte, entry;
- BUG_ON(PageCompound(page+i));
- entry = mk_pte(page + i, vma->vm_page_prot);
- entry = maybe_mkwrite(pte_mkdirty(entry), vma);
- if (!pmd_write(*pmd))
- entry = pte_wrprotect(entry);
- else
- BUG_ON(page_mapcount(page) != 1);
- if (!pmd_young(*pmd))
- entry = pte_mkold(entry);
- pte = pte_offset_map(&_pmd, haddr);
- BUG_ON(!pte_none(*pte));
- set_pte_at(mm, haddr, pte, entry);
- pte_unmap(pte);
- }
+ if (!pmd)
+ goto unlock;
- smp_wmb(); /* make pte visible before pmd */
- /*
- * Up to this point the pmd is present and huge and
- * userland has the whole access to the hugepage
- * during the split (which happens in place). If we
- * overwrite the pmd with the not-huge version
- * pointing to the pte here (which of course we could
- * if all CPUs were bug free), userland could trigger
- * a small page size TLB miss on the small sized TLB
- * while the hugepage TLB entry is still established
- * in the huge TLB. Some CPU doesn't like that. See
- * http://support.amd.com/us/Processor_TechDocs/41322.pdf,
- * Erratum 383 on page 93. Intel should be safe but is
- * also warns that it's only safe if the permission
- * and cache attributes of the two entries loaded in
- * the two TLB is identical (which should be the case
- * here). But it is generally safer to never allow
- * small and huge TLB entries for the same virtual
- * address to be loaded simultaneously. So instead of
- * doing "pmd_populate(); flush_tlb_range();" we first
- * mark the current pmd notpresent (atomically because
- * here the pmd_trans_huge and pmd_trans_splitting
- * must remain set at all times on the pmd until the
- * split is complete for this pmd), then we flush the
- * SMP TLB and finally we write the non-huge version
- * of the pmd entry with pmd_populate.
- */
- set_pmd_at(mm, address, pmd, pmd_mknotpresent(*pmd));
- flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
- pmd_populate(mm, pmd, pgtable);
- ret = 1;
+ prot = pmd_pgprot(*pmd);
- pgtable = get_pmd_huge_pte(mm);
++ pgtable = pgtable_trans_huge_withdraw(mm);
+ pmd_populate(mm, &_pmd, pgtable);
+
+ for (i = 0, haddr = address; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
+ pte_t *pte, entry;
+
+ BUG_ON(PageCompound(page+i));
+ entry = mk_pte(page + i, prot);
+ entry = pte_mkdirty(entry);
+ if (!pmd_young(*pmd))
+ entry = pte_mkold(entry);
+ pte = pte_offset_map(&_pmd, haddr);
+ BUG_ON(!pte_none(*pte));
+ set_pte_at(mm, haddr, pte, entry);
+ pte_unmap(pte);
}
+
+ smp_wmb(); /* make ptes visible before pmd, see __pte_alloc */
+ /*
+ * Up to this point the pmd is present and huge.
+ *
+ * If we overwrite the pmd with the not-huge version, we could trigger
+ * a small page size TLB miss on the small sized TLB while the hugepage
+ * TLB entry is still established in the huge TLB.
+ *
+ * Some CPUs don't like that. See
+ * http://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum 383
+ * on page 93.
+ *
+ * Thus it is generally safer to never allow small and huge TLB entries
+ * for overlapping virtual addresses to be loaded. So we first mark the
+ * current pmd not present, then we flush the TLB and finally we write
+ * the non-huge version of the pmd entry with pmd_populate.
+ *
+ * The above needs to be done under the ptl because pmd_trans_huge and
+ * pmd_trans_splitting must remain set on the pmd until the split is
+ * complete. The ptl also protects against concurrent faults due to
+ * making the pmd not-present.
+ */
+ set_pmd_at(mm, address, pmd, pmd_mknotpresent(*pmd));
+ flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
+ pmd_populate(mm, pmd, pgtable);
+ ret = 1;
+
+unlock:
spin_unlock(&mm->page_table_lock);
return ret;
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-09-27 7:04 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-09-27 7:04 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Xiao Guangrong
[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/huge_memory.c between commit 93c9d633bd9e ("mm/thp: Preserve pgprot
across huge page split") from the tip tree and commit "thp: merge page
pre-alloc in khugepaged_loop into khugepaged_do_scan" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc mm/huge_memory.c
index 5ab8c26,50bd2ac..0000000
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@@ -2307,11 -2240,43 +2307,41 @@@ static int khugepaged_wait_event(void
kthread_should_stop();
}
- static void khugepaged_do_scan(struct page **hpage)
+ static void khugepaged_alloc_sleep(void)
+ {
+ wait_event_freezable_timeout(khugepaged_wait, false,
+ msecs_to_jiffies(khugepaged_alloc_sleep_millisecs));
+ }
+
+ #ifndef CONFIG_NUMA
+ static struct page *khugepaged_alloc_hugepage(bool *wait)
+ {
+ struct page *hpage;
+
+ do {
+ hpage = alloc_hugepage(khugepaged_defrag());
+ if (!hpage) {
+ count_vm_event(THP_COLLAPSE_ALLOC_FAILED);
+ if (!*wait)
+ return NULL;
+
+ *wait = false;
+ khugepaged_alloc_sleep();
+ } else
+ count_vm_event(THP_COLLAPSE_ALLOC);
+ } while (unlikely(!hpage) && likely(khugepaged_enabled()));
+
+ return hpage;
+ }
+ #endif
+
+ static void khugepaged_do_scan(void)
{
+ struct page *hpage = NULL;
unsigned int progress = 0, pass_through_head = 0;
- unsigned int pages = khugepaged_pages_to_scan;
+ unsigned int pages = ACCESS_ONCE(khugepaged_pages_to_scan);
+ bool wait = true;
- barrier(); /* write khugepaged_pages_to_scan to local stack */
-
while (progress < pages) {
cond_resched();
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-09-27 6:57 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-09-27 6:57 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Lee Schermerhorn, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, KOSAKI Motohiro,
Mel Gorman
[-- Attachment #1: Type: text/plain, Size: 2858 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/mempolicy.c between commit 4d58c795f691 ("mm/mpol: Check for misplaced
page") from the tip tree and commit "mempolicy: fix refcount leak in
mpol_set_shared_policy()" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc mm/mempolicy.c
index a0eec0e,1763418..0000000
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@@ -2174,82 -2157,12 +2174,88 @@@ mpol_shared_policy_lookup(struct shared
return pol;
}
+/**
+ * mpol_misplaced - check whether current page node is valid in policy
+ *
+ * @page - page to be checked
+ * @vma - vm area where page mapped
+ * @addr - virtual address where page mapped
+ *
+ * Lookup current policy node id for vma,addr and "compare to" page's
+ * node id.
+ *
+ * Returns:
+ * -1 - not misplaced, page is in the right node
+ * node - node id where the page should be
+ *
+ * Policy determination "mimics" alloc_page_vma().
+ * Called from fault path where we know the vma and faulting address.
+ */
+int mpol_misplaced(struct page *page, struct vm_area_struct *vma, unsigned long addr)
+{
+ struct mempolicy *pol;
+ struct zone *zone;
+ int curnid = page_to_nid(page);
+ unsigned long pgoff;
+ int polnid = -1;
+ int ret = -1;
+
+ BUG_ON(!vma);
+
+ pol = get_vma_policy(current, vma, addr);
+ if (!(pol->flags & MPOL_F_MOF))
+ goto out;
+
+ switch (pol->mode) {
+ case MPOL_INTERLEAVE:
+ BUG_ON(addr >= vma->vm_end);
+ BUG_ON(addr < vma->vm_start);
+
+ pgoff = vma->vm_pgoff;
+ pgoff += (addr - vma->vm_start) >> PAGE_SHIFT;
+ polnid = offset_il_node(pol, vma, pgoff);
+ break;
+
+ case MPOL_PREFERRED:
+ if (pol->flags & MPOL_F_LOCAL)
+ polnid = numa_node_id();
+ else
+ polnid = pol->v.preferred_node;
+ break;
+
+ case MPOL_BIND:
+ /*
+ * allows binding to multiple nodes.
+ * use current page if in policy nodemask,
+ * else select nearest allowed node, if any.
+ * If no allowed nodes, use current [!misplaced].
+ */
+ if (node_isset(curnid, pol->v.nodes))
+ goto out;
+ (void)first_zones_zonelist(
+ node_zonelist(numa_node_id(), GFP_HIGHUSER),
+ gfp_zone(GFP_HIGHUSER),
+ &pol->v.nodes, &zone);
+ polnid = zone->node;
+ break;
+
+ default:
+ BUG();
+ }
+ if (curnid != polnid)
+ ret = polnid;
+out:
+ mpol_cond_put(pol);
+
+ return ret;
+}
+
+ static void sp_free(struct sp_node *n)
+ {
+ mpol_put(n->policy);
+ kmem_cache_free(sn_cache, n);
+ }
+
static void sp_delete(struct shared_policy *sp, struct sp_node *n)
{
pr_debug("deleting %lx-l%lx\n", n->start, n->end);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-09-27 6:49 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-09-27 6:49 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
include/linux/mm.h between commit 1dbd3d35fe64 ("mm/pgprot: Move the
pgprot_modify() fallback definition to mm.h") from the tip tree and
commit "mm, x86, pat: rework linear pfn-mmap tracking" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/mm.h
index 4adea2c,a66f646..0000000
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@@ -160,37 -160,6 +160,19 @@@ extern pgprot_t protection_map[16]
#define FAULT_FLAG_TRIED 0x40 /* second try */
/*
- * This interface is used by x86 PAT code to identify a pfn mapping that is
- * linear over entire vma. This is to optimize PAT code that deals with
- * marking the physical region with a particular prot. This is not for generic
- * mm use. Note also that this check will not work if the pfn mapping is
- * linear for a vma starting at physical address 0. In which case PAT code
- * falls back to slow path of reserving physical range page by page.
- */
- static inline int is_linear_pfn_mapping(struct vm_area_struct *vma)
- {
- return !!(vma->vm_flags & VM_PFN_AT_MMAP);
- }
-
- static inline int is_pfn_mapping(struct vm_area_struct *vma)
- {
- return !!(vma->vm_flags & VM_PFNMAP);
- }
-
- /*
+ * Some architectures (such as x86) may need to preserve certain pgprot
+ * bits, without complicating generic pgprot code.
+ *
+ * Most architectures don't care:
+ */
+#ifndef pgprot_modify
+static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
+{
+ return newprot;
+}
+#endif
+
+/*
* vm_fault is filled by the the pagefault handler and passed to the vma's
* ->fault function. The vma's ->fault is responsible for returning a bitmask
* of VM_FAULT_xxx flags that give details about how the fault was handled.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-07-27 3:50 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-07-27 3:50 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Yan, Zheng, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/cpu/perf_event_intel_uncore.h between commit 254298c726b9
("perf/x86: Add Intel Nehalem-EX uncore support") from the tip tree and
commit "arch/x86/kernel/cpu/perf_event_intel_uncore.h: make
UNCORE_PMU_HRTIMER_INTERVAL 64-bit" from the akpm tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/kernel/cpu/perf_event_intel_uncore.h
index f385189,d85c25d..0000000
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.h
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
@@@ -5,7 -5,9 +5,7 @@@
#include "perf_event.h"
#define UNCORE_PMU_NAME_LEN 32
- #define UNCORE_PMU_HRTIMER_INTERVAL (60 * NSEC_PER_SEC)
-#define UNCORE_BOX_HASH_SIZE 8
-
+ #define UNCORE_PMU_HRTIMER_INTERVAL (60LL * NSEC_PER_SEC)
#define UNCORE_FIXED_EVENT 0xff
#define UNCORE_PMC_IDX_MAX_GENERIC 8
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-05-21 8:29 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-05-21 8:29 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got conflicts in
arch/x86/syscalls/syscall_64.tbl and arch/x86/syscalls/syscall_32.tbl
between commit a2dae61eb839 ("sched/numa: Introduce sys_numa_{t,m}bind()")
from the tip tree and commit "syscalls, x86: add __NR_kcmp syscall"
from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/syscalls/syscall_32.tbl
index 38954c5,7a35a6e..0000000
--- a/arch/x86/syscalls/syscall_32.tbl
+++ b/arch/x86/syscalls/syscall_32.tbl
@@@ -355,5 -355,4 +355,6 @@@
346 i386 setns sys_setns
347 i386 process_vm_readv sys_process_vm_readv compat_sys_process_vm_readv
348 i386 process_vm_writev sys_process_vm_writev compat_sys_process_vm_writev
-349 i386 kcmp sys_kcmp
+349 i386 numa_mbind sys_numa_mbind compat_sys_numa_mbind
+350 i386 numa_tbind sys_numa_tbind compat_sys_numa_tbind
++351 i386 kcmp sys_kcmp
diff --cc arch/x86/syscalls/syscall_64.tbl
index 63c5285,f1dd014..0000000
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@@ -318,8 -318,7 +318,9 @@@
309 common getcpu sys_getcpu
310 64 process_vm_readv sys_process_vm_readv
311 64 process_vm_writev sys_process_vm_writev
-312 64 kcmp sys_kcmp
+312 64 numa_mbind sys_numa_mbind
+313 64 numa_tbind sys_numa_tbind
++314 64 kcmp sys_kcmp
#
# x32-specific system call numbers start at 512 to avoid cache impact
# for native 64-bit operation.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-05-21 8:04 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-05-21 8:04 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Oleg Nesterov, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in kernel/fork.c
between commit 0ea86208345b ("sched, mm: Rework sched_{fork,exec} node
assignment") from the tip tree and commit "task_work_add: generic
process-context callbacks" from the akpm tree.
Context changes. I fixed it up (I think - see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc kernel/fork.c
index 5642958,b33046e..0000000
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@@ -1419,6 -1420,8 +1419,7 @@@ static struct task_struct *copy_process
* We dont wake it up yet.
*/
p->group_leader = p;
- INIT_LIST_HEAD(&p->thread_group);
+ INIT_HLIST_HEAD(&p->task_works);
/* Now that the task is set up, run cgroup callbacks if
* necessary. We need to run them before the task is visible
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-05-21 7:59 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-05-21 7:59 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Bjorn Helgaas, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/trampoline.c between commit c9b77ccb52a5 ("x86, realmode:
Move ACPI wakeup to unified realmode code") from the tip tree and commit
"x86: print physical addresses consistently with other parts of kernel"
from the akpm tree.
The former removed (or moved) the code modified by the latter and removed
the file, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-03-27 4:57 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-03-27 4:57 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Alex Shi, Richard Weinberger,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
Hi all,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/process_64.c between commit 90e240142bd3 ("x86: Merge the
x86_32 and x86_64 cpu_idle() functions") from the tip tree and commit
54d16004d978 ("x86: use this_cpu_xxx to replace percpu_xxx funcs") from
the akpm tree.
The former moved the code to another file, so I did this change from the
latter (in enter_idle) to arch/x86/kernel/process.c.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-03-26 4:01 Stephen Rothwell
2012-03-26 5:20 ` Alex Shi
0 siblings, 1 reply; 85+ messages in thread
From: Stephen Rothwell @ 2012-03-26 4:01 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Suresh Siddha, Alex Shi
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
Hi all,
Today's linux-next merge of the akpm tree got a conflict in between
commit a6fca40f1d7f ("x86, tlb: Switch cr3 in leave_mm() only when
needed") from the tip tree and commit "x86: use this_cpu_xxx to replace
percpu_xxx funcs" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/mm/tlb.c
index 125bcad,e931db0..0000000
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@@ -61,13 -61,11 +61,13 @@@ static DEFINE_PER_CPU_READ_MOSTLY(int,
*/
void leave_mm(int cpu)
{
- struct mm_struct *active_mm = percpu_read(cpu_tlbstate.active_mm);
- if (percpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
++ struct mm_struct *active_mm = __this_cpu_read(cpu_tlbstate.active_mm);
+ if (__this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
BUG();
- cpumask_clear_cpu(cpu,
- mm_cpumask(__this_cpu_read(cpu_tlbstate.active_mm)));
- load_cr3(swapper_pg_dir);
+ if (cpumask_test_cpu(cpu, mm_cpumask(active_mm))) {
+ cpumask_clear_cpu(cpu, mm_cpumask(active_mm));
+ load_cr3(swapper_pg_dir);
+ }
}
EXPORT_SYMBOL_GPL(leave_mm);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-03-26 4:01 Stephen Rothwell
@ 2012-03-26 5:20 ` Alex Shi
0 siblings, 0 replies; 85+ messages in thread
From: Alex Shi @ 2012-03-26 5:20 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Suresh Siddha
On 03/26/2012 12:01 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in between
> commit a6fca40f1d7f ("x86, tlb: Switch cr3 in leave_mm() only when
> needed") from the tip tree and commit "x86: use this_cpu_xxx to replace
> percpu_xxx funcs" from the akpm tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Thanks!
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-03-08 6:32 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-03-08 6:32 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Philip A. Prindeville, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/Kconfig between commit da4e3302949f ("x86/geode/net5501: Add
platform driver for Soekris Engineering net5501") from the tip tree and
commit "geos: platform driver for Geos and Geos2 single-board computers"
from the akpm tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/Kconfig
index 97a7a56,a985f6b..0000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -2151,12 -2151,13 +2151,19 @@@ config ALI
Note: You have to set alix.force=1 for boards with Award BIOS.
+config NET5501
+ bool "Soekris Engineering net5501 System Support (LEDS, GPIO, etc)"
+ select GPIOLIB
+ ---help---
+ This option enables system support for the Soekris Engineering net5501.
+
+ config GEOS
+ bool "Traverse Technologies GEOS System Support (LEDS, GPIO, etc)"
+ select GPIOLIB
+ depends on DMI
+ ---help---
+ This option enables system support for the Traverse Technologies GEOS.
+
endif # X86_32
config AMD_NB
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-03-08 6:28 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-03-08 6:28 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Daniel Drake, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/platform/olpc/olpc-xo15-sci.c between commit d1f42e314c9c
("x86/olpc/xo15/sci: Enable lid close wakeup control") from the tip tree
and commit "x86, olpc-xo15-sci: enable lid close wakeup control through
sysfs" from the akpm tree.
I assume that these were meant to be the same patch, so I dropped the one
from the akpm tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-02-29 6:27 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-02-29 6:27 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Chris Metcalf
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in arch/x86/Kconfig between commit 0bf6276392e9 ("x32: Warn and disable rather than error if binutils too old") from the tip tree and commit "ipc: provide generic compat versions of IPC syscalls" from the akpm tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary,
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/Kconfig
index 3ccd69a,f50b52a..0000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -2221,7 -2221,8 +2221,8 @@@ config X86_X3
config COMPAT
def_bool y
- depends on IA32_EMULATION || X86_X32_ABI
+ depends on IA32_EMULATION || X86_X32
+ select ARCH_WANT_OLD_COMPAT_IPC
config COMPAT_FOR_U64_ALIGNMENT
def_bool COMPAT
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-02-28 4:52 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-02-28 4:52 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Jan Beulich, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Alex Shi
[-- Attachment #1: Type: text/plain, Size: 822 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/nmi_selftest.c between commit f0ba662a6e06 ("x86:
Properly _init-annotate NMI selftest code") from the tip tree and commit
"x86: use this_cpu_xxx to replace percpu_xxx funcs" from the akpm tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/kernel/nmi_selftest.c
index 2c39dcd,8aca005..0000000
--- a/arch/x86/kernel/nmi_selftest.c
+++ b/arch/x86/kernel/nmi_selftest.c
@@@ -12,7 -12,7 +12,8 @@@
#include <linux/smp.h>
#include <linux/cpumask.h>
#include <linux/delay.h>
+#include <linux/init.h>
+ #include <linux/percpu.h>
#include <asm/apic.h>
#include <asm/nmi.h>
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-02-27 5:53 Stephen Rothwell
2012-02-27 5:57 ` Cyrill Gorcunov
2012-02-27 6:01 ` H. Peter Anvin
0 siblings, 2 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-02-27 5:53 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Cyrill Gorcunov
[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/syscalls/syscall_64.tbl between commit
arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
__NR_kcmp syscall" from the akpm tree.
I fixed it up (see below) but did not know if this call should be marked
"common".
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/syscalls/syscall_64.tbl
index 4aecc7e,ac3066f..0000000
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@@ -304,50 -304,18 +304,51 @@@
295 64 preadv sys_preadv
296 64 pwritev sys_pwritev
297 64 rt_tgsigqueueinfo sys_rt_tgsigqueueinfo
-298 64 perf_event_open sys_perf_event_open
+298 common perf_event_open sys_perf_event_open
299 64 recvmmsg sys_recvmmsg
-300 64 fanotify_init sys_fanotify_init
-301 64 fanotify_mark sys_fanotify_mark
-302 64 prlimit64 sys_prlimit64
-303 64 name_to_handle_at sys_name_to_handle_at
-304 64 open_by_handle_at sys_open_by_handle_at
-305 64 clock_adjtime sys_clock_adjtime
-306 64 syncfs sys_syncfs
+300 common fanotify_init sys_fanotify_init
+301 common fanotify_mark sys_fanotify_mark
+302 common prlimit64 sys_prlimit64
+303 common name_to_handle_at sys_name_to_handle_at
+304 common open_by_handle_at sys_open_by_handle_at
+305 common clock_adjtime sys_clock_adjtime
+306 common syncfs sys_syncfs
307 64 sendmmsg sys_sendmmsg
-308 64 setns sys_setns
-309 64 getcpu sys_getcpu
+308 common setns sys_setns
+309 common getcpu sys_getcpu
310 64 process_vm_readv sys_process_vm_readv
311 64 process_vm_writev sys_process_vm_writev
+ 312 64 kcmp sys_kcmp
+#
+# x32-specific system call numbers start at 512 to avoid cache impact
+# for native 64-bit operation.
+#
+512 x32 rt_sigaction sys32_rt_sigaction
+513 x32 rt_sigreturn stub_x32_rt_sigreturn
+514 x32 ioctl compat_sys_ioctl
+515 x32 readv compat_sys_readv
+516 x32 writev compat_sys_writev
+517 x32 recvfrom compat_sys_recvfrom
+518 x32 sendmsg compat_sys_sendmsg
+519 x32 recvmsg compat_sys_recvmsg
+520 x32 execve stub_x32_execve
+521 x32 times compat_sys_times
+522 x32 rt_sigpending sys32_rt_sigpending
+523 x32 rt_sigtimedwait compat_sys_rt_sigtimedwait
+524 x32 rt_sigqueueinfo sys32_rt_sigqueueinfo
+525 x32 sigaltstack stub_x32_sigaltstack
+526 x32 timer_create compat_sys_timer_create
+527 x32 mq_notify compat_sys_mq_notify
+528 x32 kexec_load compat_sys_kexec_load
+529 x32 waitid compat_sys_waitid
+530 x32 set_robust_list compat_sys_set_robust_list
+531 x32 get_robust_list compat_sys_get_robust_list
+532 x32 vmsplice compat_sys_vmsplice
+533 x32 move_pages compat_sys_move_pages
+534 x32 preadv compat_sys_preadv64
+535 x32 pwritev compat_sys_pwritev64
+536 x32 rt_tgsigqueueinfo compat_sys_rt_tgsigqueueinfo
+537 x32 recvmmsg compat_sys_recvmmsg
+538 x32 sendmmsg compat_sys_sendmmsg
+539 x32 process_vm_readv compat_sys_process_vm_readv
+540 x32 process_vm_writev compat_sys_process_vm_writev
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-02-27 5:53 Stephen Rothwell
@ 2012-02-27 5:57 ` Cyrill Gorcunov
2012-02-27 6:02 ` H. Peter Anvin
2012-02-27 6:01 ` H. Peter Anvin
1 sibling, 1 reply; 85+ messages in thread
From: Cyrill Gorcunov @ 2012-02-27 5:57 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> arch/x86/syscalls/syscall_64.tbl between commit
> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
> __NR_kcmp syscall" from the akpm tree.
>
> I fixed it up (see below) but did not know if this call should be marked
> "common".
Hi Stephen, letme fetch both trees to figure out what this new column means.
Will ping back shortly. Thanks!
Cyrill
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-02-27 5:57 ` Cyrill Gorcunov
@ 2012-02-27 6:02 ` H. Peter Anvin
2012-02-27 6:05 ` Cyrill Gorcunov
0 siblings, 1 reply; 85+ messages in thread
From: H. Peter Anvin @ 2012-02-27 6:02 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Stephen Rothwell, Andrew Morton, linux-next, linux-kernel,
Thomas Gleixner, Ingo Molnar, Peter Zijlstra
On 02/26/2012 09:57 PM, Cyrill Gorcunov wrote:
> On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> Today's linux-next merge of the akpm tree got a conflict in
>> arch/x86/syscalls/syscall_64.tbl between commit
>> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
>> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
>> __NR_kcmp syscall" from the akpm tree.
>>
>> I fixed it up (see below) but did not know if this call should be marked
>> "common".
>
> Hi Stephen, letme fetch both trees to figure out what this new column means.
> Will ping back shortly. Thanks!
>
> Cyrill
Hi Cyrill,
"common" means the same entry point is used for x86-64 and x32.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-02-27 6:02 ` H. Peter Anvin
@ 2012-02-27 6:05 ` Cyrill Gorcunov
0 siblings, 0 replies; 85+ messages in thread
From: Cyrill Gorcunov @ 2012-02-27 6:05 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Stephen Rothwell, Andrew Morton, linux-next, linux-kernel,
Thomas Gleixner, Ingo Molnar, Peter Zijlstra
On Sun, Feb 26, 2012 at 10:02:11PM -0800, H. Peter Anvin wrote:
> On 02/26/2012 09:57 PM, Cyrill Gorcunov wrote:
> > On Mon, Feb 27, 2012 at 04:53:56PM +1100, Stephen Rothwell wrote:
> >> Hi Andrew,
> >>
> >> Today's linux-next merge of the akpm tree got a conflict in
> >> arch/x86/syscalls/syscall_64.tbl between commit
> >> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
> >> syscall/syscall_64.tbl") from the tip tree and commit "syscalls, x86: add
> >> __NR_kcmp syscall" from the akpm tree.
> >>
> >> I fixed it up (see below) but did not know if this call should be marked
> >> "common".
> >
> > Hi Stephen, letme fetch both trees to figure out what this new column means.
> > Will ping back shortly. Thanks!
> >
>
> Hi Cyrill,
>
> "common" means the same entry point is used for x86-64 and x32.
>
Ah, I see. Thanks for explanation, Peter! So it should be a "common" then.
Cyrill
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-02-27 5:53 Stephen Rothwell
2012-02-27 5:57 ` Cyrill Gorcunov
@ 2012-02-27 6:01 ` H. Peter Anvin
2012-02-27 6:19 ` Stephen Rothwell
1 sibling, 1 reply; 85+ messages in thread
From: H. Peter Anvin @ 2012-02-27 6:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Thomas Gleixner,
Ingo Molnar, Peter Zijlstra, Cyrill Gorcunov
On 02/26/2012 09:53 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in
> arch/x86/syscalls/syscall_64.tbl between commit
> arch/x86/syscalls/syscall_64.tbl ("x32: Add x32 system calls to
> syscall/syscall_64.tbl") from the tip tree and commit "syscalls,
> x86: add __NR_kcmp syscall" from the akpm tree.
>
> I fixed it up (see below) but did not know if this call should be
> marked "common".
It should be "common" (otherwise there would need to be an x32 variant
which would point to the compat version of the call, but in this case
even the i386 entry point goes straight to sys_kcmp.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the tip tree
2012-02-27 6:01 ` H. Peter Anvin
@ 2012-02-27 6:19 ` Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-02-27 6:19 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andrew Morton, linux-next, linux-kernel, Thomas Gleixner,
Ingo Molnar, Peter Zijlstra, Cyrill Gorcunov
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
Hi Peter,
On Sun, 26 Feb 2012 22:01:21 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> It should be "common" (otherwise there would need to be an x32 variant
> which would point to the compat version of the call, but in this case
> even the i386 entry point goes straight to sys_kcmp.)
Thanks, I will fix up the merge resolution tomorrow.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-02-27 5:44 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-02-27 5:44 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Chris Metcalf, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, H. J. Lu
[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/Kconfig between commit 5fd92e65a68b ("x32: Allow x32 to be
configured") from the tip tree and commit "ipc: provide generic compat
versions of IPC syscalls" from the akpm tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/Kconfig
index 14b78d7,6f6807d..0000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -2206,22 -2206,10 +2206,23 @@@ config IA32_AOU
---help---
Support old a.out binaries in the 32bit emulation.
+config X86_X32_ABI
+ bool "x32 ABI for 64-bit mode (EXPERIMENTAL)"
+ depends on X86_64 && IA32_EMULATION && EXPERIMENTAL && BROKEN
+ ---help---
+ Include code to run binaries for the x32 native 32-bit ABI
+ for 64-bit processors. An x32 process gets access to the
+ full 64-bit register file and wide data path while leaving
+ pointers at 32 bits for smaller memory footprint.
+
+ You will need a recent binutils (2.22 or later) with
+ elf32_x86_64 support enabled to compile a kernel with this
+ option set.
+
config COMPAT
def_bool y
- depends on IA32_EMULATION
+ depends on IA32_EMULATION || X86_X32_ABI
+ select ARCH_WANT_OLD_COMPAT_IPC
config COMPAT_FOR_U64_ALIGNMENT
def_bool COMPAT
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-02-27 5:33 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-02-27 5:33 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Alex Shi, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Linus
[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/include/asm/i387.h between commits 8546c008924d ("i387: Uninline
the generic FP helpers that we expose to kernel modules") and
1361b83a13d4 ("i387: Split up <asm/i387.h> into exported and internal
interfaces") from the tip tree and commit
"percpu-remove-percpu_xxx-functions-fix" from the akpm tree.
I applied the appropriate part of the latter patch to
arch/x86/include/asm/fpu-internal.h and arch/x86/kernel/i387.c (see below).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/x86/include/asm/fpu-internal.h b/arch/x86/include/asm/fpu-internal.h
index 5caaf43..e9801b4 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -290,14 +290,14 @@ static inline int __thread_has_fpu(struct task_struct *tsk)
static inline void __thread_clear_has_fpu(struct task_struct *tsk)
{
tsk->thread.fpu.has_fpu = 0;
- percpu_write(fpu_owner_task, NULL);
+ __this_cpu_write(fpu_owner_task, NULL);
}
/* Must be paired with a 'clts' before! */
static inline void __thread_set_has_fpu(struct task_struct *tsk)
{
tsk->thread.fpu.has_fpu = 1;
- percpu_write(fpu_owner_task, tsk);
+ __this_cpu_write(fpu_owner_task, tsk);
}
/*
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 7734bcb..32c3972 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -88,7 +88,7 @@ void kernel_fpu_begin(void)
__thread_clear_has_fpu(me);
/* We do 'stts()' in kernel_fpu_end() */
} else {
- percpu_write(fpu_owner_task, NULL);
+ __this_cpu_write(fpu_owner_task, NULL);
clts();
}
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-02-27 5:23 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-02-27 5:23 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Russell King - ARM Linux
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
kernel/irq/manage.c between commit b4bc724e82e8 ("genirq: Handle pending
irqs in irq_startup()") from the tip tree and commit "irqs: fix handling
of pending IRQs at request time" from the akpm tree.
It looks like the former is a superset of the latter, so I dropped the
latter.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2012-02-27 5:16 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2012-02-27 5:16 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Linus Torvalds, Alex Shi
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/include/asm/i387.h between commit 1361b83a13d4 ("i387: Split up
<asm/i387.h> into exported and internal interfaces") from the tip tree
and commit "x86-change-percpu_read_stable-to-this_cpu_read_stable-fix"
from the akpm tree.
The former commit moved the code to arch/x86/include/asm/fpu-internal.h,
so I applied the patch there (see below).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/x86/include/asm/fpu-internal.h b/arch/x86/include/asm/fpu-internal.h
index 4fa8815..5caaf43 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -344,7 +344,7 @@ typedef struct { int preload; } fpu_switch_t;
*/
static inline int fpu_lazy_restore(struct task_struct *new, unsigned int cpu)
{
- return new == percpu_read_stable(fpu_owner_task) &&
+ return new == this_cpu_read_stable(fpu_owner_task) &&
cpu == new->thread.fpu.last_cpu;
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2011-12-06 4:04 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2011-12-06 4:04 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Andi Kleen, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
kernel/Makefile between commit 029632fbb7b7 ("sched: Make separate
sched*.c translation units") from the tip tree and commit f7243fa71a4c
("brlocks/lglocks: clean up code") from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc kernel/Makefile
index 4363a41,d173c0c..0000000
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@@ -9,8 -9,9 +9,8 @@@ obj-y = fork.o exec_domain.o panic.
rcupdate.o extable.o params.o posix-timers.o \
kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \
hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o \
- notifier.o ksysfs.o sched_clock.o cred.o \
- async.o range.o
-obj-y += groups.o lglock.o
+ notifier.o ksysfs.o cred.o \
- async.o range.o groups.o
++ async.o range.o groups.o lglock.o
ifdef CONFIG_FUNCTION_TRACER
# Do not trace debug files and internal ftrace files
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
* linux-next: manual merge of the akpm tree with the tip tree
@ 2011-09-27 7:13 Stephen Rothwell
0 siblings, 0 replies; 85+ messages in thread
From: Stephen Rothwell @ 2011-09-27 7:13 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Yinghai Lu, Suresh Siddha,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 573 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got conflicts in
drivers/iommu/dmar.c and include/linux/dmar.h between commit 318fe7df9d84
("iommu: Move IOMMU specific code to intel-iommu.c") from the tip tree
and commit 432fb2751763 ("When do pci remove/rescan on system that have
more iommus, got") from the akpm tree.
The former moved that code the the latter cares about to another files.
I have dropped this patch from the akpm tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 85+ messages in thread
end of thread, other threads:[~2020-05-29 10:57 UTC | newest]
Thread overview: 85+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-25 4:08 linux-next: manual merge of the akpm tree with the tip tree Stephen Rothwell
2012-07-25 7:10 ` Ingo Molnar
2012-07-25 7:35 ` Johannes Weiner
2012-07-25 18:57 ` Andrew Morton
2012-07-25 19:03 ` Ingo Molnar
2012-07-25 19:26 ` Andrew Morton
2012-07-26 7:51 ` Ingo Molnar
2012-07-26 18:05 ` Andrew Morton
2012-07-25 19:20 ` Johannes Weiner
2012-07-26 7:03 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2020-05-29 10:57 Stephen Rothwell
2020-05-29 10:49 Stephen Rothwell
2020-01-22 6:37 Stephen Rothwell
2019-02-13 6:49 Stephen Rothwell
2019-02-13 19:59 ` Andrew Morton
2018-01-09 5:02 Stephen Rothwell
2018-01-09 10:36 ` Andy Shevchenko
2017-10-16 18:48 Mark Brown
2017-10-16 20:01 ` Mark Brown
2017-04-12 7:08 Stephen Rothwell
2017-03-31 5:44 Stephen Rothwell
2017-03-31 6:42 ` Peter Zijlstra
2017-03-31 13:54 ` Andi Kleen
2017-03-31 14:45 ` Peter Zijlstra
2017-03-31 16:02 ` Andi Kleen
2017-03-31 17:48 ` Peter Zijlstra
2017-03-24 5:40 Stephen Rothwell
2017-03-24 8:05 ` Peter Zijlstra
2016-03-10 5:28 Stephen Rothwell
2016-03-10 8:00 ` Ingo Molnar
2016-03-10 20:38 ` Andrew Morton
2016-02-09 4:50 Stephen Rothwell
2016-02-09 14:04 ` Matt Fleming
2016-02-09 14:07 ` Ingo Molnar
2015-06-09 14:12 Stephen Rothwell
2015-04-08 8:49 Stephen Rothwell
2015-04-08 15:13 ` Ingo Molnar
2015-04-08 20:46 ` Andrew Morton
2015-04-08 21:57 ` Stephen Rothwell
2014-03-21 6:45 Stephen Rothwell
2014-01-13 6:17 Stephen Rothwell
2013-04-23 7:17 Stephen Rothwell
2013-02-14 4:33 Stephen Rothwell
2013-02-14 4:25 Stephen Rothwell
2013-02-14 4:34 ` H. Peter Anvin
2013-02-04 7:00 Stephen Rothwell
2013-01-28 12:29 Stephen Rothwell
2012-12-10 8:29 Stephen Rothwell
2012-12-10 10:46 ` Ingo Molnar
2012-12-10 8:25 Stephen Rothwell
2012-12-10 8:20 Stephen Rothwell
2012-12-10 8:11 Stephen Rothwell
2012-12-10 8:01 Stephen Rothwell
2012-12-10 11:13 ` Will Deacon
2012-12-10 7:47 Stephen Rothwell
2012-11-15 6:32 Stephen Rothwell
2012-10-01 14:22 Stephen Rothwell
2012-09-27 7:15 Stephen Rothwell
2012-09-27 7:10 Stephen Rothwell
2012-09-27 7:04 Stephen Rothwell
2012-09-27 6:57 Stephen Rothwell
2012-09-27 6:49 Stephen Rothwell
2012-07-27 3:50 Stephen Rothwell
2012-05-21 8:29 Stephen Rothwell
2012-05-21 8:04 Stephen Rothwell
2012-05-21 7:59 Stephen Rothwell
2012-03-27 4:57 Stephen Rothwell
2012-03-26 4:01 Stephen Rothwell
2012-03-26 5:20 ` Alex Shi
2012-03-08 6:32 Stephen Rothwell
2012-03-08 6:28 Stephen Rothwell
2012-02-29 6:27 Stephen Rothwell
2012-02-28 4:52 Stephen Rothwell
2012-02-27 5:53 Stephen Rothwell
2012-02-27 5:57 ` Cyrill Gorcunov
2012-02-27 6:02 ` H. Peter Anvin
2012-02-27 6:05 ` Cyrill Gorcunov
2012-02-27 6:01 ` H. Peter Anvin
2012-02-27 6:19 ` Stephen Rothwell
2012-02-27 5:44 Stephen Rothwell
2012-02-27 5:33 Stephen Rothwell
2012-02-27 5:23 Stephen Rothwell
2012-02-27 5:16 Stephen Rothwell
2011-12-06 4:04 Stephen Rothwell
2011-09-27 7:13 Stephen Rothwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).