| Message ID | 20220427224924.592546-10-gpiccoli@igalia.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | The panic notifiers refactor | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Not a local patch, async |
Hi Guilherme, On 27/04/2022 23:49, Guilherme G. Piccoli wrote: > The panic notifier infrastructure executes registered callbacks when > a panic event happens - such callbacks are executed in atomic context, > with interrupts and preemption disabled in the running CPU and all other > CPUs disabled. That said, mutexes in such context are not a good idea. > > This patch replaces a regular mutex with a mutex_trylock safer approach; > given the nature of the mutex used in the driver, it should be pretty > uncommon being unable to acquire such mutex in the panic path, hence > no functional change should be observed (and if it is, that would be > likely a deadlock with the regular mutex). > > Fixes: 2227b7c74634 ("coresight: add support for CPU debug module") > Cc: Leo Yan <leo.yan@linaro.org> > Cc: Mathieu Poirier <mathieu.poirier@linaro.org> > Cc: Mike Leach <mike.leach@linaro.org> > Cc: Suzuki K Poulose <suzuki.poulose@arm.com> > Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> How would you like to proceed with queuing this ? I am happy either way. In case you plan to push this as part of this series (I don't see any potential conflicts) : Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
On 28/04/2022 05:11, Suzuki K Poulose wrote: > Hi Guilherme, > [...] > How would you like to proceed with queuing this ? I am happy > either way. In case you plan to push this as part of this > series (I don't see any potential conflicts) : > > Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Thanks for your review Suzuki, much appreciated! About your question, I'm not sure yet - in case the core changes would take a while (like if community find them polemic, require many changes, etc) I might split this series in 2 parts, the fixes part vs the improvements per se. Either way, a V2 is going to happen for sure, and in that moment, I'll let you know what I think it's best. But either way, any choice you prefer is fine by me as well (like if you want to merge it now or postpone to get merged in the future), this is not an urgent fix I think =) Cheers, Guilherme
On 28/04/2022 05:11, Suzuki K Poulose wrote: > Hi Guilherme, > > On 27/04/2022 23:49, Guilherme G. Piccoli wrote: >> The panic notifier infrastructure executes registered callbacks when >> a panic event happens - such callbacks are executed in atomic context, >> with interrupts and preemption disabled in the running CPU and all other >> CPUs disabled. That said, mutexes in such context are not a good idea. >> >> This patch replaces a regular mutex with a mutex_trylock safer approach; >> given the nature of the mutex used in the driver, it should be pretty >> uncommon being unable to acquire such mutex in the panic path, hence >> no functional change should be observed (and if it is, that would be >> likely a deadlock with the regular mutex). >> >> Fixes: 2227b7c74634 ("coresight: add support for CPU debug module") >> Cc: Leo Yan <leo.yan@linaro.org> >> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> >> Cc: Mike Leach <mike.leach@linaro.org> >> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> >> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> > > How would you like to proceed with queuing this ? I am happy > either way. In case you plan to push this as part of this > series (I don't see any potential conflicts) : > > Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Hi Suzuki, some other maintainers are taking the patches to their next branches for example. I'm working on V2, and I guess in the end would be nice to reduce the size of the series a bit. So, do you think you could pick this one for your coresight/next branch (or even for rc cycle, your call - this is really a fix)? This way, I won't re-submit this one in V2, since it's gonna be merged already in your branch. Thanks in advance, Guilherme
Hi On 09/05/2022 14:09, Guilherme G. Piccoli wrote: > On 28/04/2022 05:11, Suzuki K Poulose wrote: >> Hi Guilherme, >> >> On 27/04/2022 23:49, Guilherme G. Piccoli wrote: >>> The panic notifier infrastructure executes registered callbacks when >>> a panic event happens - such callbacks are executed in atomic context, >>> with interrupts and preemption disabled in the running CPU and all other >>> CPUs disabled. That said, mutexes in such context are not a good idea. >>> >>> This patch replaces a regular mutex with a mutex_trylock safer approach; >>> given the nature of the mutex used in the driver, it should be pretty >>> uncommon being unable to acquire such mutex in the panic path, hence >>> no functional change should be observed (and if it is, that would be >>> likely a deadlock with the regular mutex). >>> >>> Fixes: 2227b7c74634 ("coresight: add support for CPU debug module") >>> Cc: Leo Yan <leo.yan@linaro.org> >>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> >>> Cc: Mike Leach <mike.leach@linaro.org> >>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> >>> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> >> >> How would you like to proceed with queuing this ? I am happy >> either way. In case you plan to push this as part of this >> series (I don't see any potential conflicts) : >> >> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> > > Hi Suzuki, some other maintainers are taking the patches to their next > branches for example. I'm working on V2, and I guess in the end would be > nice to reduce the size of the series a bit. > > So, do you think you could pick this one for your coresight/next branch > (or even for rc cycle, your call - this is really a fix)? > This way, I won't re-submit this one in V2, since it's gonna be merged > already in your branch. I have queued this to coresight/next. Thanks Suzuki
On 09/05/2022 13:14, Suzuki K Poulose wrote: > [...]> > I have queued this to coresight/next. > > Thanks > Suzuki Thanks a lot Suzuki!
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c index 8845ec4b4402..1874df7c6a73 100644 --- a/drivers/hwtracing/coresight/coresight-cpu-debug.c +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c @@ -380,9 +380,10 @@ static int debug_notifier_call(struct notifier_block *self, int cpu; struct debug_drvdata *drvdata; - mutex_lock(&debug_lock); + /* Bail out if we can't acquire the mutex or the functionality is off */ + if (!mutex_trylock(&debug_lock)) + return NOTIFY_DONE; - /* Bail out if the functionality is disabled */ if (!debug_enable) goto skip_dump; @@ -401,7 +402,7 @@ static int debug_notifier_call(struct notifier_block *self, skip_dump: mutex_unlock(&debug_lock); - return 0; + return NOTIFY_DONE; } static struct notifier_block debug_notifier = {
The panic notifier infrastructure executes registered callbacks when a panic event happens - such callbacks are executed in atomic context, with interrupts and preemption disabled in the running CPU and all other CPUs disabled. That said, mutexes in such context are not a good idea. This patch replaces a regular mutex with a mutex_trylock safer approach; given the nature of the mutex used in the driver, it should be pretty uncommon being unable to acquire such mutex in the panic path, hence no functional change should be observed (and if it is, that would be likely a deadlock with the regular mutex). Fixes: 2227b7c74634 ("coresight: add support for CPU debug module") Cc: Leo Yan <leo.yan@linaro.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> --- drivers/hwtracing/coresight/coresight-cpu-debug.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)