Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/x86/mm/init_64.c
between commit:
d9f6e12fb0b7 ("x86: Fix various typos in comments")
from the tip tree and commit:
68f7bf6e7e98 ("x86/vmemmap: drop handling of 4K unaligned vmemmap range")
from the akpm-c
On Fri, Dec 11, 2020 at 07:56:54PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> mm/gup.c
>
> between commit:
>
> 2a4a06da8a4b ("mm/gup: Provide gup_get_pte() more generic")
>
> from the tip tree and commit:
>
> 1eb
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/gup.c
between commit:
2a4a06da8a4b ("mm/gup: Provide gup_get_pte() more generic")
from the tip tree and commit:
1eb2fe862a51 ("mm/gup: combine put_compound_head() and unpin_user_page()")
from the akpm-curre
On Fri, Nov 27 2020 at 13:54, Andy Shevchenko wrote:
>> 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.
On Fri, Nov 27, 2020 at 06:39:24PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> include/linux/kernel.h
>
> between commit:
>
> 74d862b682f5 ("sched: Make migrate_disable/enable() independent of RT")
>
> from the tip t
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/highmem.c
between commits:
298fa1ad5571 ("highmem: Provide generic variant of kmap_atomic*")
5fbda3ecd14a ("sched: highmem: Store local kmaps in task struct")
from the tip tree and commit:
72d22a0d0e86 ("m
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/kernel.h
between commit:
74d862b682f5 ("sched: Make migrate_disable/enable() independent of RT")
from the tip tree and commit:
761ace49e56f ("kernel.h: Split out mathematical helpers")
from the a
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/mm.h
between commit:
95bb7c42ac8a ("mm: Add 'mprotect' hook to struct vm_operations_struct")
from the tip tree and commit:
6dd8e5dab7c1 ("mremap: don't allow MREMAP_DONTUNMAP on special_mappings a
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/arc/Kconfig
between commit:
39cac191ff37 ("arc/mm/highmem: Use generic kmap atomic implementation")
from the tip tree and commit:
b41c56d2a9e6 ("arc: use FLATMEM with freeing of unused memory map instead o
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/sched.h
between commit:
d741bf41d7c7 ("kprobes: Remove kretprobe hash")
from the tip tree and commit:
faf4ffbfd1c5 ("fs/buffer.c: add debug print for __getblk_gfp() stall problem")
from the akpm-
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
lib/cpumask.c
between commit:
1abdfe706a57 ("lib: Restrict cpumask_local_spread to houskeeping CPUs")
from the tip tree and commit:
6f7ee3fd63c9 ("lib: optimize cpumask_local_spread()")
from the akpm-current t
Hi all,
On Mon, 25 May 2020 21:04:43 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/x86/mm/tlb.c
>
> between commit:
>
> 83ce56f712af ("x86/mm: Refactor cond_ibpb() to support other use cases")
>
> from the tip tree and com
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/x86/include/asm/efi.h
between commit:
9b47c5275614 ("efi/libstub: Add definitions for console input and events")
from the tip tree and patch:
"mm: reorder includes after introduction of linux/pgtable.h"
f
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/swap.c
between commit:
b01b2141 ("mm/swap: Use local_lock for protection")
from the tip tree and commit:
48c1ce8726a7 ("mm: fold and remove lru_cache_add_anon() and
lru_cache_add_file()")
from the akpm
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/sched.h
between commits:
5567d11c21a1 ("x86/mce: Send #MC singal from task work")
from the tip tree and commit:
e87f27165be1 ("fs/buffer.c: add debug print for __getblk_gfp() stall problem")
from
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
fs/squashfs/decompressor_multi_percpu.c
between commit:
fd56200a16c7 ("squashfs: Make use of local lock in multi_cpu decompressor")
from the tip tree and commit:
5697b27554f3 ("squashfs-migrate-from-ll_rw_block
On Mon, 2020-05-25 at 21:04 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/x86/mm/tlb.c
>
> between commit:
>
> 83ce56f712af ("x86/mm: Refactor cond_ibpb() to support other use cases")
>
> from the tip tree and com
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/x86/mm/tlb.c
between commit:
83ce56f712af ("x86/mm: Refactor cond_ibpb() to support other use cases")
from the tip tree and commit:
36c8e34d03a1 ("x86/mm: remove vmalloc faulting")
from the akpm-current t
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
kernel/kprobes.c
between commit:
4fdd88877e52 ("kprobes: Lock kprobe_mutex while showing kprobe_blacklist")
from the tip tree and commit:
71294f4f8167 ("kernel/kprobes.c: convert to use DEFINE_SEQ_ATTRIBUTE mac
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
lib/debugobjects.c
between commit:
d5f34153e526 ("debugobjects: Move printk out of db->lock critical sections")
from the tip tree and commit:
8b6b497dfb11 ("lib/debugobjects.c: move printk out of db lock critic
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/vmalloc.c
between commit:
bade3b4bdcdb ("mm/vmalloc.c: refactor __vunmap() to avoid duplicated call to
find_vm_area()")
from the tip tree and commit:
868b104d7379 ("mm/vmalloc: Add flag for freeing of speci
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/sched.h
between commit:
15917dc02841 ("sched: Remove stale PF_MUTEX_TESTER bit")
from the tip tree and commit:
ca299cb98649 ("mm/cma: add PF flag to force non cma alloc")
from the akpm-current tr
On Mon, 20 Aug 2018 14:32:22 +1000 Stephen Rothwell
wrote:
> Today's linux-next merge of the akpm-current tree got conflicts in:
>
> fs/proc/kcore.c
> include/linux/kcore.h
>
> between commit:
>
> 6855dc41b246 ("x86: Add entry trampolines to kcore")
>
> from the tip tree and commits:
>
Hi Andrew,
Today's linux-next merge of the akpm-current tree got conflicts in:
fs/proc/kcore.c
include/linux/kcore.h
between commit:
6855dc41b246 ("x86: Add entry trampolines to kcore")
from the tip tree and commits:
4eb27c275abf ("fs/proc/kcore.c: use __pa_symbol() for KCORE_TEXT lis
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
fs/ocfs2/filecheck.c
between commit:
e24e960c7fe2 ("sched/wait, fs/ocfs2: Convert wait_on_atomic_t() usage to the
new wait_var_event() API")
from the tip tree and commit:
5a5b76d17dc4 ("ocfs2: add kobject f
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
kernel/fork.c
between commit:
5e28fd0b5fdb ("arch: Allow arch_dup_mmap() to fail")
from the tip tree and commit:
120bd8608675 ("include/linux/sched/mm.h: uninline mmdrop_async(), etc")
from the akpm-current
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
kernel/softirq.c
between commit:
f71b74bca637 ("irq/softirqs: Use lockdep to assert IRQs are disabled/enabled")
from the tip tree and commit:
275f9389fa4e ("kmemcheck: rip it out")
from the akpm-current tre
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/x86/mm/kasan_init_64.c
between commit:
12a8cc7fcf54 ("x86/kasan: Use the same shadow offset for 4- and 5-level
paging")
from the tip tree and commit:
3af83426c380 ("x86/kasan: add and use kasan_map_pop
On 08/22/2017 08:57 AM, Stephen Rothwell wrote:
> Hi Andrew,
Hi,
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> init/main.c
>
> between commit:
>
> caba4cbbd27d ("debugobjects: Make kmemleak ignore debug objects")
>
> from the tip tree and commit:
>
> 50a7dc
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
init/main.c
between commit:
caba4cbbd27d ("debugobjects: Make kmemleak ignore debug objects")
from the tip tree and commit:
50a7dc046b58 ("mm, page_ext: move page_ext_init() after
page_alloc_init_late()")
On Mon, Aug 14, 2017 at 09:57:23PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 14, 2017 at 05:38:39PM +0900, Minchan Kim wrote:
> > memory-barrier.txt always scares me. I have read it for a while
> > and IIUC, it seems semantic of spin_unlock(&same_pte) would be
> > enough without some memory-barrie
Peter Zijlstra wrote:
> On Mon, Aug 14, 2017 at 05:07:19AM +, Nadav Amit wrote:
So I'm not entirely clear about this yet.
How about:
CPU0CPU1
tlb_gather_mmu()
On Mon, Aug 14, 2017 at 05:38:39PM +0900, Minchan Kim wrote:
> memory-barrier.txt always scares me. I have read it for a while
> and IIUC, it seems semantic of spin_unlock(&same_pte) would be
> enough without some memory-barrier inside mm_tlb_flush_nested.
Indeed, see the email I just send. Its bo
On Mon, Aug 14, 2017 at 05:07:19AM +, Nadav Amit wrote:
> >> So I'm not entirely clear about this yet.
> >>
> >> How about:
> >>
> >>
> >>CPU0CPU1
> >>
> >>tlb_gather_mmu()
> >>
> >>lock
On Mon, Aug 14, 2017 at 12:09:14PM +0900, Minchan Kim wrote:
> @@ -446,9 +450,7 @@ void tlb_finish_mmu(struct mmu_gather *tlb,
>*
>*/
> bool force = mm_tlb_flush_nested(tlb->mm);
> -
> arch_tlb_finish_mmu(tlb, start, end, force);
> - dec_tlb_flush_pending(tlb->mm);
>
Hi Nadav,
On Mon, Aug 14, 2017 at 05:07:19AM +, Nadav Amit wrote:
< snip >
> For some reason (I would assume intentional), all the examples here first
> “do not modify” the PTE, and then modify it - which is not an “interesting”
> case. However, based on what I understand on the memory barrie
On Mon, Aug 14, 2017 at 05:07:19AM +, Nadav Amit wrote:
< snip >
> Minchan, as for the solution you proposed, it seems to open again a race,
> since the “pending” indication is removed before the actual TLB flush is
> performed.
Oops, you're right!
Minchan Kim wrote:
> On Sun, Aug 13, 2017 at 02:50:19PM +0200, Peter Zijlstra wrote:
>> On Sun, Aug 13, 2017 at 06:06:32AM +, Nadav Amit wrote:
however mm_tlb_flush_nested() is a mystery, it appears to care about
anything inside the range. For now rely on it doing at least _a_ PTL
>
On Sun, Aug 13, 2017 at 02:50:19PM +0200, Peter Zijlstra wrote:
> On Sun, Aug 13, 2017 at 06:06:32AM +, Nadav Amit wrote:
> > > however mm_tlb_flush_nested() is a mystery, it appears to care about
> > > anything inside the range. For now rely on it doing at least _a_ PTL
> > > lock instead of t
Hi Peter,
On Fri, Aug 11, 2017 at 04:04:50PM +0200, Peter Zijlstra wrote:
>
> Ok, so I have the below to still go on-top.
>
> Ideally someone would clarify the situation around
> mm_tlb_flush_nested(), because ideally we'd remove the
> smp_mb__after_atomic() and go back to relying on PTL alone.
On Sun, Aug 13, 2017 at 06:06:32AM +, Nadav Amit wrote:
> > however mm_tlb_flush_nested() is a mystery, it appears to care about
> > anything inside the range. For now rely on it doing at least _a_ PTL
> > lock instead of taking _the_ PTL lock.
>
> It does not care about “anything” inside the
Peter Zijlstra wrote:
>
> Ok, so I have the below to still go on-top.
>
> Ideally someone would clarify the situation around
> mm_tlb_flush_nested(), because ideally we'd remove the
> smp_mb__after_atomic() and go back to relying on PTL alone.
>
> This also removes the pointless smp_mb__before
Ok, so I have the below to still go on-top.
Ideally someone would clarify the situation around
mm_tlb_flush_nested(), because ideally we'd remove the
smp_mb__after_atomic() and go back to relying on PTL alone.
This also removes the pointless smp_mb__before_atomic()
---
Subject: mm: Fix barriers
Hi Ingo,
On Fri, 11 Aug 2017 14:44:25 +0200 Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Fri, Aug 11, 2017 at 01:56:07PM +0200, Ingo Molnar wrote:
> > > I've done a minimal conflict resolution merge locally. Peter, could you
> > > please
> > > double check my resolution, in:
> >
* Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 01:56:07PM +0200, Ingo Molnar wrote:
> > I've done a minimal conflict resolution merge locally. Peter, could you
> > please
> > double check my resolution, in:
> >
> > 040cca3ab2f6: Merge branch 'linus' into locking/core, to resolve conflict
On Fri, Aug 11, 2017 at 01:56:07PM +0200, Ingo Molnar wrote:
> I've done a minimal conflict resolution merge locally. Peter, could you
> please
> double check my resolution, in:
>
> 040cca3ab2f6: Merge branch 'linus' into locking/core, to resolve conflicts
That merge is a bit wonky, but not t
* Stephen Rothwell wrote:
> Hi Peter,
>
> On Fri, 11 Aug 2017 11:34:49 +0200 Peter Zijlstra
> wrote:
> >
> > On Fri, Aug 11, 2017 at 05:53:26PM +1000, Stephen Rothwell wrote:
> > >
> > > Today's linux-next merge of the akpm-current tree got conflicts in:
> > >
> > > include/linux/mm_types
Hi Peter,
On Fri, 11 Aug 2017 11:34:49 +0200 Peter Zijlstra wrote:
>
> On Fri, Aug 11, 2017 at 05:53:26PM +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the akpm-current tree got conflicts in:
> >
> > include/linux/mm_types.h
> > mm/huge_memory.c
> >
> > between commit:
On Fri, Aug 11, 2017 at 11:34:49AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 05:53:26PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the akpm-current tree got conflicts in:
> >
> > include/linux/mm_types.h
> > mm/huge_memory.c
> >
> > between co
On Fri, Aug 11, 2017 at 05:53:26PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got conflicts in:
>
> include/linux/mm_types.h
> mm/huge_memory.c
>
> between commit:
>
> 8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()
Hi all,
Today's linux-next merge of the akpm-current tree got conflicts in:
include/linux/mm_types.h
mm/huge_memory.c
between commit:
8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")
from the tip tree and commits:
16af97dc5a89 ("mm: migrate: prevent racy access
On Wed, Apr 12 2017, Vlastimil Babka wrote:
> On 12.4.2017 8:46, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> Today's linux-next merge of the akpm-current tree got conflicts in:
>>
>> drivers/block/nbd.c
>> drivers/scsi/iscsi_tcp.c
>> net/core/dev.c
>> net/core/sock.c
>>
>> between commi
On 12.4.2017 8:46, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got conflicts in:
>
> drivers/block/nbd.c
> drivers/scsi/iscsi_tcp.c
> net/core/dev.c
> net/core/sock.c
>
> between commit:
>
> 717a94b5fc70 ("sched/core: Remove 'task' parame
Hi Andrew,
Today's linux-next merge of the akpm-current tree got conflicts in:
drivers/block/nbd.c
drivers/scsi/iscsi_tcp.c
net/core/dev.c
net/core/sock.c
between commit:
717a94b5fc70 ("sched/core: Remove 'task' parameter and rename
tsk_restore_flags() to current_restore_flags()")
f
Hi all,
Today's linux-next merge of the akpm-current tree got conflicts in:
arch/x86/include/asm/atomic.h
arch/x86/include/asm/atomic64_64.h
between commits:
a9ebf306f52c ("locking/atomic: Introduce atomic_try_cmpxchg()")
e6790e4b5d5e ("locking/atomic/x86: Use atomic_try_cmpxchg()")
fr
Hi all,
Today's linux-next merge of the akpm-current tree got conflicts in:
arch/cris/include/asm/Kbuild
arch/m32r/include/asm/Kbuild
arch/parisc/include/asm/Kbuild
arch/score/include/asm/Kbuild
between commit:
b672592f0221 ("sched/cputime: Remove generic asm headers")
from the tip t
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/memcontrol.c
between commit:
308167fcb330 ("mm/memcg: Convert to hotplug state machine")
from the tip tree and commit:
2558c318449d ("mm: memcontrol: use special workqueue for creating per-memcg
caches")
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/x86/include/asm/thread_info.h
between commit:
609c19a385c8 ("x86/ptrace: Stop setting TS_COMPAT in ptrace code")
from the tip tree and commit:
58f9594bd42f ("signal: consolidate {TS,TLF}_RESTORE_SIGMASK
Hi,
On 06/15/2016 07:23 AM, Stephen Rothwell wrote:
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
ipc/sem.c
between commit:
33ac279677dc ("locking/barriers: Introduce smp_acquire__after_ctrl_dep()")
from the tip tree and commit:
a1c58ea067cb ("ipc
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
ipc/sem.c
between commit:
33ac279677dc ("locking/barriers: Introduce smp_acquire__after_ctrl_dep()")
from the tip tree and commit:
a1c58ea067cb ("ipc/sem.c: Fix complex_count vs. simple op race")
from the a
* Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> include/linux/efi.h
>
> between commit:
>
> 2c23b73c2d02 ("Ard Biesheuvel ")
>
> from the tip tree and commit:
>
> 9f2c36a7b097 ("include/linux/efi.h: redefine type, co
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/efi.h
between commit:
2c23b73c2d02 ("Ard Biesheuvel ")
from the tip tree and commit:
9f2c36a7b097 ("include/linux/efi.h: redefine type, constant, macro from
generic code")
from the akpm-curre
Hi Andrew,
Today's linux-next merge of the akpm-current tree got conflicts in:
arch/x86/boot/Makefile
arch/x86/boot/compressed/Makefile
arch/x86/entry/vdso/Makefile
arch/x86/kernel/Makefile
arch/x86/realmode/rm/Makefile
drivers/firmware/efi/libstub/Makefile
between commit:
c0dd671
On Fri, 26 Feb 2016 16:07:12 +1100 Stephen Rothwell
wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> mm/mprotect.c
>
> between commit:
>
> 62b5f7d013fc ("mm/core, x86/mm/pkeys: Add execute-only protection keys
> support")
>
> from the tip
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/mprotect.c
between commit:
62b5f7d013fc ("mm/core, x86/mm/pkeys: Add execute-only protection keys
support")
from the tip tree and commit:
aff3915ff831 ("mm/mprotect.c: don't imply PROT_EXEC on non-exec f
On 19 February 2016 at 05:09, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/x86/mm/extable.c
>
> between commit:
>
> 548acf19234d ("x86/mm: Expand the exception table logic to allow new
> handling options")
>
> from the
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/x86/mm/extable.c
between commit:
548acf19234d ("x86/mm: Expand the exception table logic to allow new handling
options")
from the tip tree and commit:
f1cd2c09ff09 ("x86/extable: use generic search and
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/x86/mm/pgtable.c
between commit:
d6ccc3ec9525 ("x86/paravirt: Remove paravirt ops pmd_update[_defer] and
pte_update_defer")
from the tip tree and commit:
275461f0db1f ("x86, thp: remove infrastructure
Hi Andrew,
Today's linux-next merge of the akpm-current tree got conflicts in:
Documentation/filesystems/proc.txt
fs/proc/array.c
fs/proc/base.c
between commit:
b2f73922d119 ("fs/proc, core/debug: Don't expose absolute kernel addresses
via wchan")
from the tip tree and commit:
f01d
Hi Andrew,
On Wed, Sep 9, 2015 at 1:21 AM, Andrew Morton wrote:
> New syscalls are rather a pain, both from the patch-monkeying POV and
> also because nobody knows what the syscall numbers will be until
> everything lands in mainline. Oh well, it doesn't happen often and
> it's easy stuff.
One
On Tue, 8 Sep 2015 16:03:23 -0700 Linus Torvalds
wrote:
> On Tue, Sep 8, 2015 at 3:56 PM, Stephen Rothwell
> wrote:
> >
> > I have been applying that patch I sent to you to -next for some time.
> > I guess I expected Andrew to pick it up when he rebased his patch
> > series before submitting i
On Tue, Sep 8, 2015 at 3:56 PM, Stephen Rothwell wrote:
>
> I have been applying that patch I sent to you to -next for some time.
> I guess I expected Andrew to pick it up when he rebased his patch
> series before submitting it to you. These things sometimes slip
> through the cracks.
I suspect
Hi Linus,
On Tue, 8 Sep 2015 11:11:25 -0700 Linus Torvalds
wrote:
>
> On Mon, Sep 7, 2015 at 4:35 PM, Stephen Rothwell
> wrote:
> >
> > The below patch was missed when the userfaultfd stuff and the x86 changes
> > were merged. I have repeated the patch in the clear below.
>
> When forwarding
On Mon, Sep 7, 2015 at 4:35 PM, Stephen Rothwell wrote:
>
> The below patch was missed when the userfaultfd stuff and the x86 changes
> were merged. I have repeated the patch in the clear below.
When forwarding patches, please add your sign-off. I can see (and
apply) the original in this thread,
Hi Linus,
On Wed, 29 Jul 2015 19:12:56 +0200 Andrea Arcangeli wrote:
>
> On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
> > -359 i386userfaultfd sys_userfaultfd
> > ++374 i386userfaultfd sys_userfaultfd
>
> Do I understand correctly
On Wed, Jul 29, 2015 at 08:46:10PM +0200, Thomas Gleixner wrote:
> On Wed, 29 Jul 2015, Andy Lutomirski wrote:
> > -tip people: want to assign Andrea a pair of syscall numbers?
>
> Sure, just send a patch
Awesome, I just sent the patch to register the syscall against -tip
with the usual plac
On Thu, 30 Jul 2015, Stephen Rothwell wrote:
> Hi Andrea,
>
> On Wed, 29 Jul 2015 19:12:56 +0200 Andrea Arcangeli
> wrote:
> >
> > On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
> > > -359 i386userfaultfd sys_userfaultfd
> > > ++374 i386userfaultfd
Hi Andrea,
On Wed, 29 Jul 2015 19:12:56 +0200 Andrea Arcangeli wrote:
>
> On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
> > -359 i386userfaultfd sys_userfaultfd
> > ++374 i386userfaultfd sys_userfaultfd
>
> Do I understand correctl
On Wed, 29 Jul 2015, Andy Lutomirski wrote:
> On Wed, Jul 29, 2015 at 10:12 AM, Andrea Arcangeli
> wrote:
> > Hello Stephen,
> >
> > On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
> >> -359 i386userfaultfd sys_userfaultfd
> >> ++374 i386userfaultfd
On Wed, Jul 29, 2015 at 10:12 AM, Andrea Arcangeli wrote:
> Hello Stephen,
>
> On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
>> -359 i386userfaultfd sys_userfaultfd
>> ++374 i386userfaultfd sys_userfaultfd
>
> Do I understand correctly the sysca
Hello Stephen,
On Tue, Jul 28, 2015 at 04:00:15PM +1000, Stephen Rothwell wrote:
> -359 i386userfaultfd sys_userfaultfd
> ++374 i386userfaultfd sys_userfaultfd
Do I understand correctly the syscall number of userfaultfd for x86
32bit has just changed from 359 to 3
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/x86/entry/syscalls/syscall_32.tbl
between commit:
9dea5dc921b5 ("x86/entry/syscalls: Wire up 32-bit direct socket calls")
from the tip tree and commit:
0a36ab281187 ("userfaultfd: activate syscall")
f
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/Kconfig between commit 6471b825c41e ("x86/kconfig: Reorganize
arch feature Kconfig select's") from the tip tree and commits
be853e68c4b2 ("x86: mm: enable deferred struct page initialisation on
x86-64") and 84e
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
drivers/rtc/rtc-mc13xxx.c between commit 0307b0d77a08
("drivers/rtc/mc13xxx: Update driver to address y2038/y2106 issues")
from the tip tree and commit 219451fa4da4 ("drivers/rtc/rtc-mc13xxx.c:
fix obfuscated and wrong
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
drivers/rtc/class.c between commit 0fa88cb4b82b ("time, drivers/rtc:
Don't bother with rtc_resume() for the nonstop clocksource") from the
tip tree and commit df9d6ec42558 ("rtc: restore alarm after resume")
from the ak
On Mon, 17 Mar 2014 10:36:02 +0100 Peter Zijlstra wrote:
> On Mon, Mar 17, 2014 at 08:31:24PM +1100, Stephen Rothwell wrote:
> > Hi Andrew,
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in
> > kernel/locking/Makefile between commit fb0527bd5ea9 ("locking/mutexes:
> > I
On Mon, Mar 17, 2014 at 08:31:24PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in
> kernel/locking/Makefile between commit fb0527bd5ea9 ("locking/mutexes:
> Introduce cancelable MCS lock for adaptive spinning") from the tree and
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
kernel/locking/Makefile between commit fb0527bd5ea9 ("locking/mutexes:
Introduce cancelable MCS lock for adaptive spinning") from the tree and
commit 4dc0fe493027 ("lglock: map to spinlock when !CONFIG_SMP") from the
a
On Tue, Jan 14, 2014 at 5:32 PM, Geert Uytterhoeven
wrote:
> https://lkml.org/lkml/2013/12/11/141
>
> On Tue, Jan 14, 2014 at 5:19 PM, H. Peter Anvin wrote:
>> On 01/14/2014 05:17 AM, Geert Uytterhoeven wrote:
This seems terribly broken, the *futex_value*() ops should not need
that
CC linux-arch
https://lkml.org/lkml/2013/12/11/141
On Tue, Jan 14, 2014 at 5:19 PM, H. Peter Anvin wrote:
> On 01/14/2014 05:17 AM, Geert Uytterhoeven wrote:
>>>
>>> This seems terribly broken, the *futex_value*() ops should not need
>>> that; they are supposed to access userspace without any of
On 01/14/2014 05:17 AM, Geert Uytterhoeven wrote:
>>
>> This seems terribly broken, the *futex_value*() ops should not need
>> that; they are supposed to access userspace without any of that.
>
> Why don't they need set_fs(USER_DS)?
>
> Gr{oetje,eeting}s,
>
> Geert
Becau
On 01/14/2014 07:41 AM, Peter Zijlstra wrote:
>>>
>>> I am *guessing* that m68k is has get_fs() == KERNEL_DS at the point that
>>> futex_init() is called. This would seem a bit of a peculiarity to m68k,
>>> and as such it would seem like it would be better for it to belong in
>>> the m68k-specific
On Tue, Jan 14, 2014 at 04:20:36PM +0100, Geert Uytterhoeven wrote:
> On Tue, Jan 14, 2014 at 4:15 PM, H. Peter Anvin wrote:
> > On 01/14/2014 04:51 AM, Peter Zijlstra wrote:
> >> On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
> >>> Hi Andrew,
> >>>
> >>> Today's linux-next merg
On Tue, Jan 14, 2014 at 4:15 PM, H. Peter Anvin wrote:
> On 01/14/2014 04:51 AM, Peter Zijlstra wrote:
>> On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
>>> Hi Andrew,
>>>
>>> Today's linux-next merge of the akpm-current tree got a conflict in
>>> kernel/futex.c between commit a
On 01/14/2014 04:51 AM, Peter Zijlstra wrote:
> On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> Today's linux-next merge of the akpm-current tree got a conflict in
>> kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
>> size for better p
On Tue, Jan 14, 2014 at 02:17:55PM +0100, Geert Uytterhoeven wrote:
> On Tue, Jan 14, 2014 at 1:51 PM, Peter Zijlstra wrote:
> > On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
> >> Today's linux-next merge of the akpm-current tree got a conflict in
> >> kernel/futex.c between co
On Tue, Jan 14, 2014 at 1:51 PM, Peter Zijlstra wrote:
> On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
>> Today's linux-next merge of the akpm-current tree got a conflict in
>> kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
>> size for better performa
On Tue, Jan 14, 2014 at 03:53:31PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in
> kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
> size for better performance") from the tip tree and commit 61beee6c76
On Tue, 2014-01-14 at 15:53 +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in
> kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
> size for better performance") from the tip tree and commit 61beee6c76e5
> ("
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
kernel/futex.c between commit a52b89ebb6d4 ("futexes: Increase hash table
size for better performance") from the tip tree and commit 61beee6c76e5
("futex: switch to USER_DS for futex test") from the akpm-current tree.
1 - 100 of 107 matches
Mail list logo
