On Sat, 4 Mar 2017 11:35:51 +0900
Masami Hiramatsu wrote:
> On Sat, 4 Mar 2017 09:49:11 +0900
> Masami Hiramatsu wrote:
>
> > On Thu, 2 Mar 2017 23:25:06 +0530
> > "Naveen N. Rao" wrote:
> >
> > > We indicate support for accepting sym+offset with kretprobes through a
> > > line in ftrace REA
On Sat, 4 Mar 2017 11:35:51 +0900
Masami Hiramatsu wrote:
> On Sat, 4 Mar 2017 09:49:11 +0900
> Masami Hiramatsu wrote:
>
> > On Thu, 2 Mar 2017 23:25:06 +0530
> > "Naveen N. Rao" wrote:
> >
> > > We indicate support for accepting sym+offset with kretprobes through a
> > > line in ftrace REA
On Sat, 4 Mar 2017 09:49:11 +0900
Masami Hiramatsu wrote:
> On Thu, 2 Mar 2017 23:25:06 +0530
> "Naveen N. Rao" wrote:
>
> > We indicate support for accepting sym+offset with kretprobes through a
> > line in ftrace README. Parse the same to identify support and choose the
> > appropriate forma
On Thu, Mar 2, 2017 at 10:48 AM, Dmitry V. Levin wrote:
> On Thu, Mar 02, 2017 at 10:22:18AM -0500, Carlos O'Donell wrote:
>> On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann wrote:
>> > On Sun, Feb 26, 2017 at 2:01 AM, Dmitry V. Levin wrote:
>> >> Include (guarded by #ifndef __KERNEL__) to fix a
On Thu, 2 Mar 2017 23:25:07 +0530
"Naveen N. Rao" wrote:
> perf now uses an offset from _text/_stext for kretprobes if the kernel
> supports it, rather than the actual function name. As such, let's choose
> the LEP for powerpc ABIv2 so as to ensure the probe gets hit. Do it only
> if the kernel
On Thu, 2 Mar 2017 23:25:06 +0530
"Naveen N. Rao" wrote:
> We indicate support for accepting sym+offset with kretprobes through a
> line in ftrace README. Parse the same to identify support and choose the
> appropriate format for kprobe_events.
Could you give us an example of this change here?
On Thu, 2 Mar 2017 23:25:05 +0530
"Naveen N. Rao" wrote:
> Simplify and separate out the ftrace README scanning logic into a
> separate helper. This is used subsequently to scan for all patterns of
> interest and to cache the result.
>
> Since we are only interested in availability of probe arg
Hello,
On Sun, 19 Feb 2017 15:37:15 +0530
"Aneesh Kumar K.V" wrote:
> We update the hash linux page table layout such that we can support
> 512TB. But we limit the TASK_SIZE to 128TB. We can switch to 128TB by
> default without conditional because that is the max virtual address
> supported by o
Hello,
On Sun, 19 Feb 2017 15:37:16 +0530
"Aneesh Kumar K.V" wrote:
> This structure definition need not be in a header since this is used
> only by slice.c file. So move it to slice.c. This also allow us to
> use SLICE_NUM_HIGH instead of 512 and also helps in getting rid of
> one BUILD_BUG_ON(
On 3/3/2017 7:27 AM, Jiri Slaby wrote:
There is code duplicated over all architecture's headers for
futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
and comparison of the result.
Remove this duplication and leave up to the arches only the needed
assembly which is now in arc
On Fri, Mar 03, 2017 at 01:27:10PM +0100, Jiri Slaby wrote:
> There is code duplicated over all architecture's headers for
> futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
> and comparison of the result.
>
> Remove this duplication and leave up to the arches only the needed
On 03/02/2017 10:01 PM, Michael Ellerman wrote:
Paul Clarke writes:
On 03/02/2017 12:33 AM, Michael Ellerman wrote:
Paul Clarke writes:
On 02/02/2017 12:22 AM, Benjamin Herrenschmidt wrote:
This adds AUX vectors for the L1I,D, L2 and L3 cache levels
providing for each cache level the size o
There is code duplicated over all architecture's headers for
futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
and comparison of the result.
Remove this duplication and leave up to the arches only the needed
assembly which is now in arch_futex_atomic_op_inuser.
Note that s390
Laurent Dufour writes:
> Kindly ping...
On my list for 4.12, but still dealing with the mess that is 4.11.
Will review it in the next few weeks, unless someone else beats me to it
... ;)
cheers
Abdul Haleem writes:
> Hi,
>
> Reboot fails for PowerPC machine running RHEL7.3 (3.10.0-514.el7)
> following these messages:
>
> SGI XFS with ACLs, security attributes, no debug enabled
> XFS (dm-0): Mounting V5 Filesystem
> FS (dm-0): Starting recovery (logdev: internal)
> XFS (dm-0): Metadata c
Hi,
Reboot fails for PowerPC machine running RHEL7.3 (3.10.0-514.el7)
following these messages:
SGI XFS with ACLs, security attributes, no debug enabled
XFS (dm-0): Mounting V5 Filesystem
FS (dm-0): Starting recovery (logdev: internal)
XFS (dm-0): Metadata corruption detected at 0x6000382100b
16 matches
Mail list logo