Oh, sorry I misunderstood, I thought you are suggesting introducing a
new mutex for these counters.
With the existing mf_mutex, I don't think atomic is really necessary.
I will just leave them as unsigned long.
Thanks for the clarification.
On Wed, Jan 18, 2023 at 10:40 PM HORIGUCHI NAOYA(堀口 直也)
<naoya.horiguchi@xxxxxxx> wrote:
>
> On Wed, Jan 18, 2023 at 03:05:21PM -0800, Jiaqi Yan wrote:
> > On Tue, Jan 17, 2023 at 1:03 AM HORIGUCHI NAOYA(堀口 直也)
> > <naoya.horiguchi@xxxxxxx> wrote:
> > >
> > > On Mon, Jan 16, 2023 at 12:16:13PM -0800, Andrew Morton wrote:
> > > > On Mon, 16 Jan 2023 19:39:01 +0000 Jiaqi Yan <jiaqiyan@xxxxxxxxxx> wrote:
> > > ...
> > > > > @@ -1227,6 +1227,39 @@ static struct page_state error_states[] = {
> > > > > #undef slab
> > > > > #undef reserved
> > > > >
> > > > > +static void update_per_node_mf_stats(unsigned long pfn,
> > > > > + enum mf_result result)
> > > > > +{
> > > > > + int nid = MAX_NUMNODES;
> > > > > + struct memory_failure_stats *mf_stats = NULL;
> > > > > +
> > > > > + nid = pfn_to_nid(pfn);
> > > > > + if (unlikely(nid < 0 || nid >= MAX_NUMNODES)) {
> > > > > + WARN_ONCE(1, "Memory failure: pfn=%#lx, invalid nid=%d", pfn, nid);
> > > > > + return;
> > > > > + }
> > > > > +
> > > > > + mf_stats = &NODE_DATA(nid)->mf_stats;
> > > > > + switch (result) {
> > > > > + case MF_IGNORED:
> > > > > + ++mf_stats->pages_ignored;
> > > >
> > > > What is the locking here, to prevent concurrent increments?
> > >
> > > mf_mutex should prevent the race.
> >
> > Since we are only incrementing these counters, I wonder if it makes
> > sense to convert them into atomic_long_t (encapsulated inside
> > memory_failure_stats) and do atomic_long_add, instead of introducing a
> > struct mutex?
>
> I thought that all callers of action_result() (which is an only caller of
> update_per_node_mf_stats()) are called with holding mf_mutex at the
> beginning of memory_failure(), so the concurrent increments should not
> happen on the new counters. But writing counters with atomic type/API is
> fine to me.
>
> Thanks,
> Naoya Horiguchi
