[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75Vcy3dHRu8Wb2KZ=xK7adz=-P-iuRTeR8vOWzHzZL9uFeg@mail.gmail.com>
Date: Sat, 28 Jun 2025 22:52:02 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Abdelrahman Fekry <abdelrahmanfekry375@...il.com>
Cc: andy@...nel.org, hdegoede@...hat.com, mchehab@...nel.org,
sakari.ailus@...ux.intel.com, gregkh@...uxfoundation.org,
linux-kernel-mentees@...ts.linux.dev, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, linux-staging@...ts.linux.dev,
skhan@...uxfoundation.com, dan.carpenter@...aro.org
Subject: Re: [PATCH] staging: media: atomisp: Fix premature setting of
HMM_BO_DEVICE_INITED flag
On Sat, Jun 28, 2025 at 8:26 AM Abdelrahman Fekry
<abdelrahmanfekry375@...il.com> wrote:
>
> The HMM_BO_DEVICE_INITED flag was being set in hmm_bo_device_init()
> before key initialization steps like kmem_cache_create(),
> kmem_cache_alloc(), and __bo_init().
>
> This means that if any of these steps fail, the flag remains set,
> misleading other parts of the driver (e.g. hmm_bo_alloc())
> into thinking the device is initialized. This could lead
> to undefined behavior or invalid memory use.
Nice. Can you make some fault injection (temporary by modifying the
code to always fail, for example) and actually prove this in practice?
If so, the few (important) lines from the given Oops would be nice to
have here.
> Additionally, since __bo_init() is called from inside
> hmm_bo_device_init() after the flag was already set, its internal
> check for HMM_BO_DEVICE_INITED is redundant.
>
> - Move the flag assignment to the end after all allocations succeed.
> - Remove redundant check of the flag inside __bo_init()
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists