Re: ipc/mqueue: release spinlock before freeing node_cache in mqueue_evict_inode()

Re: ipc/mqueue: release spinlock before freeing node_cache in mqueue_evict_inode()

[Al Viro]

On Fri, Jun 27, 2025 at 06:11:14PM +0530, ritu pal wrote:
> Hi,
> 
> Currently, mqueue_evict_inode() holds info->lock while freeing
> info->node_cache
> with kfree(). Although kfree() does not sleep, it may take a non-trivial
> amount
> of time, increasing the duration the spinlock is held and potentially
> impacting
> concurrency.

That spinlock is inside the inode in question; what exactly is going to be
on the other side of contention?  Note that none of the file methods
are going to run concurrent with that...

Re: ipc/mqueue: release spinlock before freeing node_cache in mqueue_evict_inode()

[ritu pal]

> That spinlock is inside the inode in question; what exactly is going to be
> on the other side of contention?  Note that none of the file methods
> are going to run concurrent with that...

Another thread that's waiting to acquire the spinlock to process the
next item in the mqueue.
This change reduces the hold time of "info->lock", since the kfree()
of the node_cache does not require a spinlock to be held.

On Fri, Jun 27, 2025 at 10:08 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Fri, Jun 27, 2025 at 06:11:14PM +0530, ritu pal wrote:
> > Hi,
> >
> > Currently, mqueue_evict_inode() holds info->lock while freeing
> > info->node_cache
> > with kfree(). Although kfree() does not sleep, it may take a non-trivial
> > amount
> > of time, increasing the duration the spinlock is held and potentially
> > impacting
> > concurrency.
>
> That spinlock is inside the inode in question; what exactly is going to be
> on the other side of contention?  Note that none of the file methods
> are going to run concurrent with that...

Re: ipc/mqueue: release spinlock before freeing node_cache in mqueue_evict_inode()

[Al Viro]

On Thu, Jul 03, 2025 at 01:34:39PM +0530, ritu pal wrote:
> > That spinlock is inside the inode in question; what exactly is going to be
> > on the other side of contention?  Note that none of the file methods
> > are going to run concurrent with that...
> 
> Another thread that's waiting to acquire the spinlock to process the
> next item in the mqueue.
> This change reduces the hold time of "info->lock", since the kfree()
> of the node_cache does not require a spinlock to be held.

Describe the call chain in that other thread, please.  If there is one,
you've got a UAF scenario.

ipc/mqueue: release spinlock before freeing node_cache in mqueue_evict_inode()

[ritu pal]

Currently, mqueue_evict_inode() holds info->lock while freeing info->node_cache
with kfree(). Although kfree() does not sleep, it may take a non-trivial amount
of time, increasing the duration the spinlock is held and potentially impacting
concurrency.

This change moves the kfree(info->node_cache) call outside the critical section,
releasing the spinlock before freeing memory. This reduces lock contention and
follows kernel best practices of minimising the time spent holding spinlocks,
especially around potentially slow operations.

No functional change intended.
Signed-off-by: Ritu Pal <ritupal888@gmail.com>
---
 ipc/mqueue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 82ed2d3c9846..897caf55e217 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -526,8 +526,8 @@ static void mqueue_evict_inode(struct inode *inode)
  spin_lock(&info->lock);
  while ((msg = msg_get(info)) != NULL)
  list_add_tail(&msg->m_list, &tmp_msg);
- kfree(info->node_cache);
  spin_unlock(&info->lock);
+ kfree(info->node_cache);

  list_for_each_entry_safe(msg, nmsg, &tmp_msg, m_list) {
  list_del(&msg->m_list);
--
2.39.5 (Apple Git-154)