linux-kernel - Re: Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20191209174307.23698-1-sj38.park@gmail.com>
Date:   Mon,  9 Dec 2019 18:43:07 +0100
From:   SeongJae Park <sj38.park@...il.com>
To:     will@...nel.org
Cc:     SeongJae Park <sj38.park@...il.com>,
        Jonathan Corbet <corbet@....net>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-doc <linux-doc@...r.kernel.org>, notify@...nel.org,
        SeongJae Park <sjpark@...zon.de>
Subject: Re: Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()

On Mon, 9 Dec 2019 17:06:34 +0000 Will Deacon <will@...nel.org> wrote:

>On Mon, Dec 09, 2019 at 09:00:57AM -0800, Paul E. McKenney wrote:
>> On Mon, Dec 09, 2019 at 09:44:33AM +0000, Will Deacon wrote:
>> > On Fri, Dec 06, 2019 at 02:51:56PM -0800, Paul E. McKenney wrote:
>> > > On Fri, Dec 06, 2019 at 11:38:22PM +0100, SeongJae Park wrote:
>> > > > On Fri, Dec 6, 2019 at 11:08 PM Paul E. McKenney <paulmck@...nel.org> wrote:
>> > > > > But since Jon seems to be taking these in his capacity and Documentation
>> > > > > maintainer, could you please resend CCing him?  If we have these changes
>> > > > > scattered across too many trees, someone is going to get confused,
>> > > > > and it probably will be me.  ;-)
>> > > >
>> > > > Agreed, CC-ing Jon to this mail.  That said, this is a followup of Will's
>> > > > patch[1] and the patch is also not queued in Jon's tree.  So, I would like to
>> > > > hear Will's opinion either, if possible.
>> > > >
>> > > > [1]  https://lore.kernel.org/lkml/20191108170120.22331-10-will@kernel.org/
>> > >
>> > > Ah, this one got caught out in the conversion from .html to .rst.
>> > >
>> > > I did get an ack on one of those, and thus queued it.  I clearly need to
>> > > take another look at Will's series, and thank you for the reminder!
>> >
>> > I was planning to include this in the next posting of my series, but I was
>> > waiting for the merge window to close first. Now that we have -rc1, I'll
>> > post it this week, although the patches are also queued up in my tree here
>> > [1] (warning -- rebasing development branch).
>> >
>> > I'll leave the patches that are unrelated to smp_read_barrier_depends() to
>> > Paul and Jon, unless they indicate a preference to the contrary.
>>
>> I don't know about Jon, but I might need a reminder as to which patches
>> those are.  ;-)
>
>https://lore.kernel.org/lkml/20191121234125.28032-1-sj38.park@gmail.com
>
>...but it actually looks like Jon picked those all up, so I think we're good.
>
>SeongJae -- please shout if we've missed something (the link above, plus
>this patch).

Sorry for making things too complicated.  So, below is the timeline:

2019-11-08
----------

Will posted a patchset containing a patch removing references to
[smp_]read_barrier_depends() from memory-barriers.txt.
https://lore.kernel.org/lkml/20191108170120.22331-1-will@kernel.org/

2019-11-21
----------

I posted a translation of the patch (patchset 1):
https://lore.kernel.org/lkml/20191121193209.15687-1-sj38.park@gmail.com/

2019-11-22
----------

I posted another patchset for the Korean translations (patchset 2):
https://lore.kernel.org/linux-doc/20191121234125.28032-1-sj38.park@gmail.com/

2019-11-26
----------

Paul queued the `patchset 1` and `patchset 2`.  He also asked me to
get a review from other Korean, if possible:
https://lore.kernel.org/lkml/20191126222004.GV2889@paulmck-ThinkPad-P72/

Same day, Jon queued the `patchset 2` (not `patchset 1`) and noticed the
conflict.  Paul dropped both `patchset 1` and `patchset 2` from his tree.
Maybe this is the start of the confusion.

2019-11-29
----------

I got a review results from another Korean for both patchset 1 and patchset 2.
Because patchset 1 has already merged in Linus's tree, I made another patchset
containing fix of the patchset 1 (patchset 1-1):
https://lore.kernel.org/linux-doc/20191129182823.8710-1-sjpark@amazon.de/

Because patchset 2 is not merged in any tree, I made and posted the second
version of the patchset 2 (patchset 2-1):
https://lore.kernel.org/lkml/20191129180837.7233-1-sjpark@amazon.de/


So, patchset 1 is already merged by Jon, and patchset 2 is abandoned.
Patchset 1-1 is waiting for Jon's review, and patchset 2-1 is merged in Will's
tree.  Will would send the patchset 2-1 with his patches again in near future.

Sorry again for introducing messy confusion and hope this to finally make
things clear.  If you have any problem, please let me know.


>
>Will