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 61beee6c76e5
On Tue, Jan 14, 2014 at 1:51 PM, Peter Zijlstra pet...@infradead.org 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
On Tue, Jan 14, 2014 at 02:17:55PM +0100, Geert Uytterhoeven wrote:
On Tue, Jan 14, 2014 at 1:51 PM, Peter Zijlstra pet...@infradead.org 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
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 performance)
On Tue, Jan 14, 2014 at 4:15 PM, H. Peter Anvin h...@zytor.com 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
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 h...@zytor.com 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
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 code, but
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
Because USER_DS
CC linux-arch
https://lkml.org/lkml/2013/12/11/141
On Tue, Jan 14, 2014 at 5:19 PM, H. Peter Anvin h...@zytor.com 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
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
>
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
(futex:
On 01/07/2014 02:00 PM, Stephen Rothwell wrote:
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/mm/numa.c between commit f3d815cb854b ("x86/mm/numa: Fix 32-bit
kernel NUMA boot") from the tip tree and commit 1459be89954e ("x86: get
pg_data_t's memory from
On 01/07/2014 02:00 PM, Stephen Rothwell wrote:
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/mm/numa.c between commit f3d815cb854b (x86/mm/numa: Fix 32-bit
kernel NUMA boot) from the tip tree and commit 1459be89954e (x86: get
pg_data_t's memory from
On Sat, Nov 09, 2013 at 10:20:58AM +1100, Stephen Rothwell wrote:
> Hi Josh,
>
> On Fri, 8 Nov 2013 10:58:12 -0800 Josh Triplett wrote:
> >
> > Won't splitting the Makefile change into a separate commit break
> > bisection, in particular if you have the changes adding inlines but you
> > also
Hi Josh,
On Fri, 8 Nov 2013 10:58:12 -0800 Josh Triplett wrote:
>
> Won't splitting the Makefile change into a separate commit break
> bisection, in particular if you have the changes adding inlines but you
> also compile in lglock.o? Shouldn't this be squashed into the merge
> itself, keeping
On Fri, Nov 08, 2013 at 06:48:05PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in
> kernel/Makefile between commits 60fc28746a7b ("locking: Move the spinlock
> code to kernel/locking/") and cd4d241d57c9 ("locking: Move the
On Fri, Nov 08, 2013 at 06:48:05PM +1100, Stephen Rothwell wrote:
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
kernel/Makefile between commits 60fc28746a7b (locking: Move the spinlock
code to kernel/locking/) and cd4d241d57c9 (locking: Move the lglocks
code
Hi Josh,
On Fri, 8 Nov 2013 10:58:12 -0800 Josh Triplett j...@joshtriplett.org wrote:
Won't splitting the Makefile change into a separate commit break
bisection, in particular if you have the changes adding inlines but you
also compile in lglock.o? Shouldn't this be squashed into the merge
On Sat, Nov 09, 2013 at 10:20:58AM +1100, Stephen Rothwell wrote:
Hi Josh,
On Fri, 8 Nov 2013 10:58:12 -0800 Josh Triplett j...@joshtriplett.org wrote:
Won't splitting the Makefile change into a separate commit break
bisection, in particular if you have the changes adding inlines but you
101 - 119 of 119 matches
Mail list logo
