[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2024101335-turbulent-smelting-00f2@gregkh>
Date: Sun, 13 Oct 2024 17:07:45 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: "Usyskin, Alexander" <alexander.usyskin@...el.com>
Cc: "Weil, Oren jer" <oren.jer.weil@...el.com>,
Tomas Winkler <tomasw@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [char-misc-next] mei: use kvmalloc for read buffer
On Sun, Oct 13, 2024 at 02:22:27PM +0000, Usyskin, Alexander wrote:
> > -----Original Message-----
> > From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > Sent: Sunday, October 13, 2024 3:14 PM
> > To: Usyskin, Alexander <alexander.usyskin@...el.com>
> > Cc: Weil, Oren jer <oren.jer.weil@...el.com>; Tomas Winkler
> > <tomasw@...il.com>; linux-kernel@...r.kernel.org
> > Subject: Re: [char-misc-next] mei: use kvmalloc for read buffer
> >
> > On Sun, Oct 13, 2024 at 02:53:14PM +0300, Alexander Usyskin wrote:
> > > Read buffer is allocated according to max message size,
> > > reported by the firmware and may reach 64K in systems
> > > with pxp client.
> > > Contiguous 64k allocation may fail under memory pressure.
> > > Read buffer is used as in-driver message storage and
> > > not required to be contiguous.
> > > Use kvmalloc to allow kernel to allocate non-contiguous
> > > memory in this case.
> > >
> > > Signed-off-by: Alexander Usyskin <alexander.usyskin@...el.com>
> > > ---
> > > drivers/misc/mei/client.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > What about this thread:
> > https://lore.kernel.org/all/20240813084542.2921300-1-
> > rohiagar@...omium.org/
> >
> > No attribution for the reporter? Does it solve their problem?
> >
> This patch is a result from non-public bug report on ChromeOS.
Then make that bug report public as it was discussed in public already :)
> > Also, where is this memory pressure coming from, what is the root cause
> > and what commit does this fix? Stable backports needed? Anything else?
> >
> The ChromeOS is extremely short on memory by design and can trigger
> this situation very easily.
So normal allocations are failing? That feels wrong, what caused this?
> I do not think that this patch fixes any commit - the problematic code exists
> from the earliest versions of this driver.
> As this problem reproduced only on ChromeOS I believe that no need
> in wide backport, the ChromeOS can cherry-pick the patch.
> From your experience, is this the right strategy?
No.
Powered by blists - more mailing lists