lkml.org 
[lkml]   [2020]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 2/2] printk: use the lockless ringbuffer
    From
    Date
    在 2020年02月14日 21:50, John Ogness 写道:
    > Hi Lianbo,
    >
    > On 2020-02-14, lijiang <lijiang@redhat.com> wrote:
    >>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
    >>> index 1ef6f75d92f1..d0d24ee1d1f4 100644
    >>> --- a/kernel/printk/printk.c
    >>> +++ b/kernel/printk/printk.c
    >>> @@ -1062,21 +928,16 @@ void log_buf_vmcoreinfo_setup(void)
    >>> {
    >>> VMCOREINFO_SYMBOL(log_buf);
    >>> VMCOREINFO_SYMBOL(log_buf_len);
    >>
    >> I notice that the "prb"(printk tb static) symbol is not exported into
    >> vmcoreinfo as follows:
    >>
    >> + VMCOREINFO_SYMBOL(prb);
    >>
    >> Should the "prb"(printk tb static) symbol be exported into vmcoreinfo?
    >> Otherwise, do you happen to know how to walk through the log_buf and
    >> get all kernel logs from vmcore?
    >
    > You are correct. This will need to be exported as well so that the
    > descriptors can be accessed. (log_buf is only the pure human-readable

    Really agree, and I guess that there may be more structures and their offsets
    to be exported, for example: struct prb_desc_ring, struct prb_data_ring, and
    struct prb_desc, etc.

    This makes sure that tools(such as makedumpfile and crash) can appropriately
    access them.

    > text.) I am currently hacking the crash tool to see exactly what needs
    > to be made available in order to access all the data of the ringbuffer.
    >
    It makes sense and avoids exporting unnecessary symbols and offsets.

    Thanks.
    Lianbo


    > John Ogness
    >

    \
     
     \ /
      Last update: 2020-02-15 05:17    [W:5.457 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site