On 03/01/2017 12:02 PM, Jason Baron wrote:
On 03/01/2017 11:40 AM, David Daney wrote:
On 02/28/2017 10:34 PM, Michael Ellerman wrote:
Jason Baron writes:
...
I also checked all the other .ko files and they were properly aligned.
So I think this should hopefully work, and
On 03/01/2017 12:02 PM, Jason Baron wrote:
On 03/01/2017 11:40 AM, David Daney wrote:
On 02/28/2017 10:34 PM, Michael Ellerman wrote:
Jason Baron writes:
...
I also checked all the other .ko files and they were properly aligned.
So I think this should hopefully work, and I like that its
On 03/01/2017 11:40 AM, David Daney wrote:
> On 02/28/2017 10:34 PM, Michael Ellerman wrote:
>> Jason Baron writes:
>> ...
>>> I also checked all the other .ko files and they were properly aligned.
>>> So I think this should hopefully work, and I like that its not a
>>>
On 03/01/2017 11:40 AM, David Daney wrote:
> On 02/28/2017 10:34 PM, Michael Ellerman wrote:
>> Jason Baron writes:
>> ...
>>> I also checked all the other .ko files and they were properly aligned.
>>> So I think this should hopefully work, and I like that its not a
>>> per-arch fix.
>>>
>>>
On 02/28/2017 10:34 PM, Michael Ellerman wrote:
Jason Baron writes:
...
I also checked all the other .ko files and they were properly aligned.
So I think this should hopefully work, and I like that its not a
per-arch fix.
Sachin, sorry to bother you again, but I'm hoping
On 02/28/2017 10:34 PM, Michael Ellerman wrote:
Jason Baron writes:
...
I also checked all the other .ko files and they were properly aligned.
So I think this should hopefully work, and I like that its not a
per-arch fix.
Sachin, sorry to bother you again, but I'm hoping you can try David's
> I also checked all the other .ko files and they were properly aligned. So I
> think this should hopefully work, and I like that its not a per-arch fix.
>
> Sachin, sorry to bother you again, but I'm hoping you can try David's latest
> patch to scripts/module-common.lds, just to test in your
> I also checked all the other .ko files and they were properly aligned. So I
> think this should hopefully work, and I like that its not a per-arch fix.
>
> Sachin, sorry to bother you again, but I'm hoping you can try David's latest
> patch to scripts/module-common.lds, just to test in your
Jason Baron writes:
...
> I also checked all the other .ko files and they were properly aligned.
> So I think this should hopefully work, and I like that its not a
> per-arch fix.
>
> Sachin, sorry to bother you again, but I'm hoping you can try David's
> latest patch to
Jason Baron writes:
...
> I also checked all the other .ko files and they were properly aligned.
> So I think this should hopefully work, and I like that its not a
> per-arch fix.
>
> Sachin, sorry to bother you again, but I'm hoping you can try David's
> latest patch to
On 02/28/2017 11:05 AM, David Daney wrote:
On 02/28/2017 10:39 AM, Jason Baron wrote:
[...]
I suspect that the alignment of the __jump_table section in the .ko
files is not correct, and you are seeing some sort of problem due to
that.
Hi,
Yes, if you look at the trace that Sachin sent
On 02/28/2017 11:05 AM, David Daney wrote:
On 02/28/2017 10:39 AM, Jason Baron wrote:
[...]
I suspect that the alignment of the __jump_table section in the .ko
files is not correct, and you are seeing some sort of problem due to
that.
Hi,
Yes, if you look at the trace that Sachin sent
On 02/28/2017 03:15 PM, David Daney wrote:
On 02/28/2017 11:34 AM, Jason Baron wrote:
On 02/28/2017 02:22 PM, David Daney wrote:
On 02/28/2017 11:05 AM, David Daney wrote:
On 02/28/2017 10:39 AM, Jason Baron wrote:
[...]
I suspect that the alignment of the __jump_table section in the
On 02/28/2017 03:15 PM, David Daney wrote:
On 02/28/2017 11:34 AM, Jason Baron wrote:
On 02/28/2017 02:22 PM, David Daney wrote:
On 02/28/2017 11:05 AM, David Daney wrote:
On 02/28/2017 10:39 AM, Jason Baron wrote:
[...]
I suspect that the alignment of the __jump_table section in the
On 02/28/2017 10:39 AM, Jason Baron wrote:
On 02/28/2017 01:16 PM, David Daney wrote:
On 02/28/2017 08:21 AM, Steven Rostedt wrote:
On Tue, 28 Feb 2017 10:25:46 +0530
Sachin Sant wrote:
File: ./net/ipv4/xfrm4_input.o
[12] __jump_table PROGBITS
On 02/28/2017 10:39 AM, Jason Baron wrote:
On 02/28/2017 01:16 PM, David Daney wrote:
On 02/28/2017 08:21 AM, Steven Rostedt wrote:
On Tue, 28 Feb 2017 10:25:46 +0530
Sachin Sant wrote:
File: ./net/ipv4/xfrm4_input.o
[12] __jump_table PROGBITS 000639
18
On 02/28/2017 11:34 AM, Jason Baron wrote:
On 02/28/2017 02:22 PM, David Daney wrote:
On 02/28/2017 11:05 AM, David Daney wrote:
On 02/28/2017 10:39 AM, Jason Baron wrote:
[...]
I suspect that the alignment of the __jump_table section in the .ko
files is not correct, and you are seeing
On 02/28/2017 11:34 AM, Jason Baron wrote:
On 02/28/2017 02:22 PM, David Daney wrote:
On 02/28/2017 11:05 AM, David Daney wrote:
On 02/28/2017 10:39 AM, Jason Baron wrote:
[...]
I suspect that the alignment of the __jump_table section in the .ko
files is not correct, and you are seeing
On 02/28/2017 02:22 PM, David Daney wrote:
> On 02/28/2017 11:05 AM, David Daney wrote:
>> On 02/28/2017 10:39 AM, Jason Baron wrote:
>>>
> [...]
I suspect that the alignment of the __jump_table section in the .ko
files is not correct, and you are seeing some sort of problem due to
On 02/28/2017 02:22 PM, David Daney wrote:
> On 02/28/2017 11:05 AM, David Daney wrote:
>> On 02/28/2017 10:39 AM, Jason Baron wrote:
>>>
> [...]
I suspect that the alignment of the __jump_table section in the .ko
files is not correct, and you are seeing some sort of problem due to
On 02/28/2017 08:21 AM, Steven Rostedt wrote:
On Tue, 28 Feb 2017 10:25:46 +0530
Sachin Sant wrote:
File: ./net/ipv4/xfrm4_input.o
[12] __jump_table PROGBITS 000639 18 18 WAM
0 0 1
File: ./net/ipv4/udplite.o
File:
On 02/28/2017 08:21 AM, Steven Rostedt wrote:
On Tue, 28 Feb 2017 10:25:46 +0530
Sachin Sant wrote:
File: ./net/ipv4/xfrm4_input.o
[12] __jump_table PROGBITS 000639 18 18 WAM
0 0 1
File: ./net/ipv4/udplite.o
File: ./net/ipv4/xfrm4_output.o
[ 9]
On 02/28/2017 01:16 PM, David Daney wrote:
On 02/28/2017 08:21 AM, Steven Rostedt wrote:
On Tue, 28 Feb 2017 10:25:46 +0530
Sachin Sant wrote:
File: ./net/ipv4/xfrm4_input.o
[12] __jump_table PROGBITS 000639
18 18 WAM 0 0 1
On 02/28/2017 01:16 PM, David Daney wrote:
On 02/28/2017 08:21 AM, Steven Rostedt wrote:
On Tue, 28 Feb 2017 10:25:46 +0530
Sachin Sant wrote:
File: ./net/ipv4/xfrm4_input.o
[12] __jump_table PROGBITS 000639
18 18 WAM 0 0 1
File: ./net/ipv4/udplite.o
On Tue, 28 Feb 2017 10:25:46 +0530
Sachin Sant wrote:
> File: ./net/ipv4/xfrm4_input.o
> [12] __jump_table PROGBITS 000639 18 18
> WAM 0 0 1
> File: ./net/ipv4/udplite.o
> File: ./net/ipv4/xfrm4_output.o
> [ 9] __jump_table
On Tue, 28 Feb 2017 10:25:46 +0530
Sachin Sant wrote:
> File: ./net/ipv4/xfrm4_input.o
> [12] __jump_table PROGBITS 000639 18 18
> WAM 0 0 1
> File: ./net/ipv4/udplite.o
> File: ./net/ipv4/xfrm4_output.o
> [ 9] __jump_table PROGBITS
> Thanks for the suggestion! I would like to see if this resolves the ppc issue
> we had. I'm attaching a powerpc patch based on your suggestion. Hopefully,
> Sachin can try it.
>
> Thanks,
>
I tried this patch. It does not fix the warning.
[ 11.709071] mount (2956) used greatest stack
> Thanks for the suggestion! I would like to see if this resolves the ppc issue
> we had. I'm attaching a powerpc patch based on your suggestion. Hopefully,
> Sachin can try it.
>
> Thanks,
>
I tried this patch. It does not fix the warning.
[ 11.709071] mount (2956) used greatest stack
On 02/27/2017 02:36 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 14:21:21 -0800
David Daney wrote:
See attached for mips. It seems to do the right thing.
I leave it as an exercise to the reader to fix the other architectures.
Consult your own binutils experts
On 02/27/2017 02:36 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 14:21:21 -0800
David Daney wrote:
See attached for mips. It seems to do the right thing.
I leave it as an exercise to the reader to fix the other architectures.
Consult your own binutils experts to verify that what I say is
On 02/27/2017 02:50 PM, Jason Baron wrote:
On 02/27/2017 05:45 PM, David Daney wrote:
On 02/27/2017 02:36 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 14:21:21 -0800
David Daney wrote:
See attached for mips. It seems to do the right thing.
I leave it as an
On 02/27/2017 02:50 PM, Jason Baron wrote:
On 02/27/2017 05:45 PM, David Daney wrote:
On 02/27/2017 02:36 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 14:21:21 -0800
David Daney wrote:
See attached for mips. It seems to do the right thing.
I leave it as an exercise to the reader to fix
On Mon, 27 Feb 2017 11:59:50 -0800
David Daney wrote:
> For me the size is not the important issue, it is the alignment of the
> struct jump_entry entries in the table. I don't understand how your
> patch helps, and I cannot Acked-by unless I understand what is
On Mon, 27 Feb 2017 11:59:50 -0800
David Daney wrote:
> For me the size is not the important issue, it is the alignment of the
> struct jump_entry entries in the table. I don't understand how your
> patch helps, and I cannot Acked-by unless I understand what is being
> done and can see that
On 02/27/2017 01:06 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 11:59:50 -0800
David Daney wrote:
For me the size is not the important issue, it is the alignment of the
struct jump_entry entries in the table. I don't understand how your
patch helps, and I cannot
On 02/27/2017 01:06 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 11:59:50 -0800
David Daney wrote:
For me the size is not the important issue, it is the alignment of the
struct jump_entry entries in the table. I don't understand how your
patch helps, and I cannot Acked-by unless I
On Mon, 27 Feb 2017 14:45:37 -0800
David Daney wrote:
> On 02/27/2017 02:36 PM, Steven Rostedt wrote:
> > On Mon, 27 Feb 2017 14:21:21 -0800
> > David Daney wrote:
> >
> >> See attached for mips. It seems to do the right thing.
> >>
> >>
On Mon, 27 Feb 2017 14:45:37 -0800
David Daney wrote:
> On 02/27/2017 02:36 PM, Steven Rostedt wrote:
> > On Mon, 27 Feb 2017 14:21:21 -0800
> > David Daney wrote:
> >
> >> See attached for mips. It seems to do the right thing.
> >>
> >> I leave it as an exercise to the reader to fix the
On 02/27/2017 05:45 PM, David Daney wrote:
On 02/27/2017 02:36 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 14:21:21 -0800
David Daney wrote:
See attached for mips. It seems to do the right thing.
I leave it as an exercise to the reader to fix the other
On 02/27/2017 05:45 PM, David Daney wrote:
On 02/27/2017 02:36 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 14:21:21 -0800
David Daney wrote:
See attached for mips. It seems to do the right thing.
I leave it as an exercise to the reader to fix the other architectures.
Consult your own
On Mon, 27 Feb 2017 14:21:21 -0800
David Daney wrote:
> See attached for mips. It seems to do the right thing.
>
> I leave it as an exercise to the reader to fix the other architectures.
>
> Consult your own binutils experts to verify that what I say is true.
It
On Mon, 27 Feb 2017 14:21:21 -0800
David Daney wrote:
> See attached for mips. It seems to do the right thing.
>
> I leave it as an exercise to the reader to fix the other architectures.
>
> Consult your own binutils experts to verify that what I say is true.
It may still just be safer to
On 02/27/2017 02:09 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 13:41:13 -0800
David Daney wrote:
On 02/27/2017 01:06 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 11:59:50 -0800
David Daney wrote:
For me the size is not the
On 02/27/2017 02:09 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 13:41:13 -0800
David Daney wrote:
On 02/27/2017 01:06 PM, Steven Rostedt wrote:
On Mon, 27 Feb 2017 11:59:50 -0800
David Daney wrote:
For me the size is not the important issue, it is the alignment of the
struct jump_entry
On Mon, 27 Feb 2017 13:41:13 -0800
David Daney wrote:
> On 02/27/2017 01:06 PM, Steven Rostedt wrote:
> > On Mon, 27 Feb 2017 11:59:50 -0800
> > David Daney wrote:
> >
> >> For me the size is not the important issue, it is the alignment of
On Mon, 27 Feb 2017 13:41:13 -0800
David Daney wrote:
> On 02/27/2017 01:06 PM, Steven Rostedt wrote:
> > On Mon, 27 Feb 2017 11:59:50 -0800
> > David Daney wrote:
> >
> >> For me the size is not the important issue, it is the alignment of the
> >> struct jump_entry entries in the table. I
On 02/27/2017 11:18 AM, Jason Baron wrote:
On 02/27/2017 01:57 PM, David Daney wrote:
On 02/27/2017 10:49 AM, Jason Baron wrote:
The core jump_label code makes use of the 2 lower bits of the
static_key::[type|entries|next] field. Thus, ensure that the jump_entry
table is at least 4-byte
On 02/27/2017 11:18 AM, Jason Baron wrote:
On 02/27/2017 01:57 PM, David Daney wrote:
On 02/27/2017 10:49 AM, Jason Baron wrote:
The core jump_label code makes use of the 2 lower bits of the
static_key::[type|entries|next] field. Thus, ensure that the jump_entry
table is at least 4-byte
On 02/27/2017 01:57 PM, David Daney wrote:
On 02/27/2017 10:49 AM, Jason Baron wrote:
The core jump_label code makes use of the 2 lower bits of the
static_key::[type|entries|next] field. Thus, ensure that the jump_entry
table is at least 4-byte aligned.
[...]
diff --git
On 02/27/2017 01:57 PM, David Daney wrote:
On 02/27/2017 10:49 AM, Jason Baron wrote:
The core jump_label code makes use of the 2 lower bits of the
static_key::[type|entries|next] field. Thus, ensure that the jump_entry
table is at least 4-byte aligned.
[...]
diff --git
On 02/27/2017 10:49 AM, Jason Baron wrote:
The core jump_label code makes use of the 2 lower bits of the
static_key::[type|entries|next] field. Thus, ensure that the jump_entry
table is at least 4-byte aligned.
[...]
diff --git a/arch/mips/include/asm/jump_label.h
On 02/27/2017 10:49 AM, Jason Baron wrote:
The core jump_label code makes use of the 2 lower bits of the
static_key::[type|entries|next] field. Thus, ensure that the jump_entry
table is at least 4-byte aligned.
[...]
diff --git a/arch/mips/include/asm/jump_label.h
The core jump_label code makes use of the 2 lower bits of the
static_key::[type|entries|next] field. Thus, ensure that the jump_entry
table is at least 4-byte aligned.
Reported-and-tested-by: Sachin Sant
Cc: Steven Rostedt
Cc: Ingo Molnar
The core jump_label code makes use of the 2 lower bits of the
static_key::[type|entries|next] field. Thus, ensure that the jump_entry
table is at least 4-byte aligned.
Reported-and-tested-by: Sachin Sant
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc:
54 matches
Mail list logo