lkml.org 
[lkml]   [2019]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC PATCH v4 4/9] printk-rb: initialize new descriptors as invalid
    Date
    On 2019-08-20, Petr Mladek <pmladek@suse.com> wrote:
    >> Initialize never-used descriptors as permanently invalid so there
    >
    > The word "permanently" is confusing. It suggests that it will
    > never ever be valid again. I would just remove the word.

    Agreed.

    >> is no risk of the descriptor unexpectedly being determined as
    >> valid due to dataring head overflowing/wrapping.
    >
    > Please, provide more details about the solved race.

    OK.

    > Is it because some reader could have reference to an invalid
    > (reused) descriptor?

    Yes, but not because it is reused. If a writer succeeded in reserving a
    descriptor, but failed to reserve a datablock, that (invalid) descriptor
    is put on the committed list (see fA). By setting the lpos values to
    something that could _never_ be valid, there is no risk of the
    descriptor suddenly becoming valid due to head overflowing.

    My RFCv2 did not account for this and instead invalid descriptors just
    held on to whatever lpos values they last had. Although they are invalid
    at that moment, if not set to something "permanently" invalid, those
    values could become valid again. We talked about that here[0].

    > Can be these invalid descriptors be member of the list?

    Yes (as Sergey shows in his followup post). Readers see them as invalid
    and treat them as dropped records.

    > Also it might be worth to mention where is the check that might
    > detect such invalid descriptors and what will be the consequences.
    > Well, this might be clear from the race description.

    The check itself is not special. However, readers do have to be aware of
    and correctly handle the case of invalid descriptors on the list. I will
    find an appropriate place to document this.

    John Ogness

    [0] https://lkml.kernel.org/r/20190624140948.l7ekcmz5ser3zfr2@pathway.suse.cz

    \
     
     \ /
      Last update: 2019-08-21 07:58    [W:4.054 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site