All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: XueBing Chen <chenxb_99091@126.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lib/bsearch: add mutex protection for thread-safe binary search
Date: Thu, 16 Oct 2025 17:42:43 +0800	[thread overview]
Message-ID: <aPC-E1ZQhiLaBbWS@google.com> (raw)
In-Reply-To: <20251016090640.6331-1-chenxb_99091@126.com>

Hi XueBing,

On Thu, Oct 16, 2025 at 05:06:40PM +0800, XueBing Chen wrote:
> Replace the __inline_bsearch() wrapper with a full implementation
> that includes mutex protection to ensure thread safety when
> multiple threads call bsearch() concurrently.

Adding a global mutex lock here will introduce a performance penalty
for all users of bsearch(), even those who do not require this
protection.

If a specific user needs synchronization, shouldn't they be responsible
for implementing it? For example, by adding a lock around their call t
bsearch() or implementing the necessary locking within their compare
function.

> 
> The original implementation lacked synchronization, which could
> lead to race conditions in multi-threaded environments when
> accessing shared arrays or using non-atomic comparison functions.

Could you please provide more details on the specific race condition
you observed? What is the use case, and how does this race manifest?

A concrete example, a reproducer, or a link to a bug report would be
very helpful to understand the motivation for this change.

> 
> Signed-off-by: XueBing Chen <chenxb_99091@126.com>
> ---
>  lib/bsearch.c | 29 ++++++++++++++++++++++++++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/bsearch.c b/lib/bsearch.c
> index bf86aa66f..9a5a2e949 100644
> --- a/lib/bsearch.c
> +++ b/lib/bsearch.c
> @@ -1,9 +1,12 @@
> -// SPDX-License-Identifier: GPL-2.0-only
>  /*
>   * A generic implementation of binary search for the Linux kernel
>   *
>   * Copyright (C) 2008-2009 Ksplice, Inc.
>   * Author: Tim Abbott <tabbott@ksplice.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; version 2.

The addition of the full GPL-2 boilerplate text seems redundant and is
unrelated to the patch's functional change.

>   */
>  
>  #include <linux/export.h>
> @@ -28,9 +31,29 @@
>   * the key and elements in the array are of the same type, you can use
>   * the same comparison function for both sort() and bsearch().
>   */
> -void *bsearch(const void *key, const void *base, size_t num, size_t size, cmp_func_t cmp)
> +DEFINE_MUTEX(cmp_mutex);
> +void *bsearch(const void *key, const void *base, size_t num, size_t size,
> +	      int (*cmp)(const void *key, const void *elt))
>  {
> -	return __inline_bsearch(key, base, num, size, cmp);

This patch replaces the wrapper with a full implementation for the
exported bsearch(), but the inline version remains unlocked.

Why should the non-inline version have this protection while the inline
version does not? This creates an inconsistency.

> +	const char *pivot;
> +	int result;
> +
> +	while (num > 0) {
> +		pivot = base + (num >> 1) * size;
> +		mutex_lock(&cmp_mutex);
> +		result = cmp(key, pivot);
> +		mutex_unlock(&cmp_mutex);

If the intent is to protect a cmp function that is not re-entrant,
shouldn't the user who provides that cmp function be responsible for
adding the lock inside it?

Regards,
Kuan-Wei

> +		if (result == 0)
> +			return (void *)pivot;
> +
> +		if (result > 0) {
> +			base = pivot + size;
> +			num--;
> +		}
> +		num >>= 1;
> +	}
> +
> +	return NULL;
>  }
>  EXPORT_SYMBOL(bsearch);
>  NOKPROBE_SYMBOL(bsearch);
> -- 
> 2.17.1
> 
> 

  reply	other threads:[~2025-10-16  9:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-16  9:06 [PATCH] lib/bsearch: add mutex protection for thread-safe binary search XueBing Chen
2025-10-16  9:42 ` Kuan-Wei Chiu [this message]
2025-10-17  7:28 ` kernel test robot
2025-10-21  4:47 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aPC-E1ZQhiLaBbWS@google.com \
    --to=visitorckw@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chenxb_99091@126.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.