Re: [PATCH] padata: Honor the caller's alignment in case of chunk_size 0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/21/24 17:02, Kamlesh Gurudasani wrote:
In the case where we are forcing the ps.chunk_size to be at least 1,
we are ignoring the caller's alignment.

Move the forcing of ps.chunk_size to be at least 1 before rounding it
up to caller's alignment, so that caller's alignment is honored.

While at it, use max() to force the ps.chunk_size to be at least 1 to
improve readability.

Fixes: 6d45e1c948a8 ("padata: Fix possible divide-by-0 panic in padata_mt_helper()")
Signed-off-by: Kamlesh Gurudasani <kamlesh@xxxxxx>
---
  kernel/padata.c | 12 ++++--------
  1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/kernel/padata.c b/kernel/padata.c
index 0fa6c2895460..d8a51eff1581 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -509,21 +509,17 @@ void __init padata_do_multithreaded(struct padata_mt_job *job)
/*
  	 * Chunk size is the amount of work a helper does per call to the
-	 * thread function.  Load balance large jobs between threads by
+	 * thread function. Load balance large jobs between threads by
  	 * increasing the number of chunks, guarantee at least the minimum
  	 * chunk size from the caller, and honor the caller's alignment.
+	 * Ensure chunk_size is at least 1 to prevent divide-by-0
+	 * panic in padata_mt_helper().
  	 */
  	ps.chunk_size = job->size / (ps.nworks * load_balance_factor);
  	ps.chunk_size = max(ps.chunk_size, job->min_chunk);
+	ps.chunk_size = max(ps.chunk_size, 1ul);
  	ps.chunk_size = roundup(ps.chunk_size, job->align);
- /*
-	 * chunk_size can be 0 if the caller sets min_chunk to 0. So force it
-	 * to at least 1 to prevent divide-by-0 panic in padata_mt_helper().`
-	 */
-	if (!ps.chunk_size)
-		ps.chunk_size = 1U;
-
  	list_for_each_entry(pw, &works, pw_list)
  		if (job->numa_aware) {
  			int old_node = atomic_read(&last_used_nid);

---
base-commit: b311c1b497e51a628aa89e7cb954481e5f9dced2
change-id: 20240822-max-93c17adc6457

LGTM, my only nit is the use of "1ul" which is less common and harder to read than "1UL" as the former one may be misread as a "lul" variable.

Acked-by:  Waiman Long <longman@xxxxxxxxxx>





[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux