[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65d5832090c5b_1ada2029473@iweiny-mobl.notmuch>
Date: Tue, 20 Feb 2024 20:59:12 -0800
From: Ira Weiny <ira.weiny@...el.com>
To: Dan Williams <dan.j.williams@...el.com>, Ira Weiny <ira.weiny@...el.com>,
"Rafael J. Wysocki" <rafael@...nel.org>, Jonathan Cameron
<jonathan.cameron@...wei.com>, Smita Koralahalli
<Smita.KoralahalliChannabasappa@....com>
CC: <linux-acpi@...r.kernel.org>, <linux-cxl@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, Dan Carpenter <dan.carpenter@...aro.org>,
"Ira Weiny" <ira.weiny@...el.com>
Subject: RE: [PATCH v2] acpi/ghes: Prevent sleeping with spinlock held
Dan Williams wrote:
> Ira Weiny wrote:
[snip]
> >
> > - guard(rwsem_read)(&cxl_cper_rw_sem);
> > - if (cper_callback)
> > - cper_callback(event_type, rec);
>
> Given a work function can be set atomically there is no need to create /
> manage a registration lock. Set a 'struct work' instance to a CXL
> provided routine on cxl_pci module load and restore it to a nop function
> + cancel_work_sync() on cxl_pci module exit.
Ok I'll look into this.
>
> > + wi = kmalloc(sizeof(*wi), GFP_ATOMIC);
>
> The system is already under distress trying to report an error it should
> not dip into emergency memory reserves to report errors. Use a kfifo()
> similar to how memory_failure_queue() avoids memory allocation in the
> error reporting path.
I have a question on ghes_proc() [ghes_do_proc()]. Can they be called by
2 threads at the same time? It seems like there could be multiple
platform devices which end up queueing into the single kfifo. So either
there needs to be a kfifo per device or synchronization with multiple
writers.
Ira
Powered by blists - more mailing lists