linux-kernel - Re: [PATCH v5 1/2] printk: Add console owner and waiter logic to load balance console writes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45bc7a00-2f7f-3319-bfed-e7b9cd7a8571@lge.com>
Date:   Fri, 19 Jan 2018 11:37:13 +0900
From:   Byungchul Park <byungchul.park@....com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        akpm@...ux-foundation.org, linux-mm@...ck.org,
        Cong Wang <xiyou.wangcong@...il.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Mel Gorman <mgorman@...e.de>, Michal Hocko <mhocko@...nel.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jan Kara <jack@...e.cz>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        rostedt@...e.goodmis.org,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Tejun Heo <tj@...nel.org>, Pavel Machek <pavel@....cz>,
        linux-kernel@...r.kernel.org, kernel-team@....com
Subject: Re: [PATCH v5 1/2] printk: Add console owner and waiter logic to load
 balance console writes

On 1/19/2018 12:21 AM, Steven Rostedt wrote:
> On Thu, 18 Jan 2018 13:01:46 +0900
> Byungchul Park <byungchul.park@....com> wrote:
> 
>>> I disagree. It is like a spinlock. You can say a spinlock() that is
>>> blocked is also waiting for an event. That event being the owner does a
>>> spin_unlock().
>>
>> That's exactly what I was saying. Excuse me but, I don't understand
>> what you want to say. Could you explain more? What do you disagree?
> 
> I guess I'm confused at what you are asking for then.

Sorry for not enough explanation. What I asked you for is:

    1. Relocate acquire()s/release()s.
    2. So make it simpler and remove unnecessary one.
    3. So make it look like the following form,
       because it's a thing simulating "wait and event".

       A context
       ---------
       lock_map_acquire(wait); /* Or lock_map_acquire_read(wait) */
                               /* "Read" one is better though..    */

       /* A section, we suspect a wait for an event might happen. */
       ...

       lock_map_release(wait);

       The place actually doing the wait
       ---------------------------------
       lock_map_acquire(wait);
       lock_map_release(wait);

       wait_for_event(wait); /* Actually do the wait */

Honestly, you used acquire()s/release()s as if they are cross-
release stuff which mainly handles general waits and events,
not only things doing "acquire -> critical area -> release".
But that's not in the mainline at the moment.

>>> I find your way confusing. I'm simulating a spinlock not a wait for
>>> completion. A wait for completion usually initiates something then
>>
>> I used the word, *event* instead of *completion*. wait_for_completion()
>> and complete() are just an example of a pair of waiter and event.
>> Lock and unlock can also be another example, too.
>>
>> Important thing is that who waits and who triggers the event. Using the
>> pair, we can achieve various things, for examples:
>>
>>      1. Synchronization like wait_for_completion() does.
>>      2. Control exclusively entering into a critical area.
>>      3. Whatever.
>>
>>> waits for it to complete. This is trying to get into a critical area
>>> but another task is currently in it. It's simulating a spinlock as far
>>> as I can see.
>>
>> Anyway it's an example of "waiter for an event, and the event".
>>
>> JFYI, spinning or sleeping does not matter. Those are just methods to
          ^
          whether spining or sleeping doesn't matter.

>> achieve a wait. I know you're not talking about this though. It's JFYI.
> 
> OK, if it is just FYI.

Actually, the last paragraph is JFYI tho.

> -- Steve
> 
> 
> 

-- 
Thanks,
Byungchul