From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEBD443F084 for ; Sun, 19 Jul 2026 03:36:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784432204; cv=none; b=NVYd2aPFMu8iaW5cYsfWFpxCe6oxo27Mi2nm40W+Am+ETj/KRUDtPD/MVyScrJdY97R1PNqCL33l6pchQJ4wqioEGkkimOe0m2ylJuwBeSozOCeANkHsbxHJUFeMKV0Z6yeiela9LrLtsLiVkCBgd4K+YlQkvw8Ykcj/eeBspX8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784432204; c=relaxed/simple; bh=iTfmmDYFUihKDNR+naOjyZ++IqNK89Q9kjldH1m6wHk=; h=MIME-Version:Date:Content-Type:From:Message-ID:Subject:To:Cc: In-Reply-To:References; b=qm1K060tV3k1utJPqBHYPUDdQDM7GQwNyV7o2dgDCooYQxHQ2g+SGxp15VdsHCzpSb1GKhfQM2nKBoxFxEUiTdiaJqULZ2/QR9Xk3LF/7BHBjhk0P5NNOd/KcVYjKGYYpBC6MYgykjdE+zHmcWiCNfSIzxkthWGZN3nFbpOeuYg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Smu8g5i8; arc=none smtp.client-ip=91.218.175.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Smu8g5i8" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784432199; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sOu3XSBXTjt7lcz7DPTjN66BgAVWs0aBuKK3Ae/AHnA=; b=Smu8g5i88dBP8U7NxLrDAyHhlYtk0hBNP1veRtgg0L3yPhqhulxMHh/Gs+ewQIvhZfzF/+ Vm1HoRCxTiHrMEkgy1HXhqEZ/5M8TJq0fwMbIkkCa/XTtIX8V+vxjzD1GYCmEm9gDc9/i8 lSN1Y76ccQUjBVBXX7xwhduCeRnNXkA= Date: Sun, 19 Jul 2026 03:36:37 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Jackie Liu" Message-ID: <9df338a30f3fb369681f826fc92c850e50c406e1@linux.dev> TLS-Required: No Subject: Re: [PATCH] lib: cpu_rmap: reject zero-sized maps To: "Andrew Morton" Cc: linux-kernel@vger.kernel.org In-Reply-To: <20260717215642.9e4b74a29e0b3afa2ee45938@linux-foundation.org> References: <20260718042155.31020-1-liu.yun@linux.dev> <20260717215642.9e4b74a29e0b3afa2ee45938@linux-foundation.org> X-Migadu-Flow: FLOW_OUT 2026=E5=B9=B47=E6=9C=8818=E6=97=A5 12:56, "Andrew Morton" =E5=86=99=E5=88=B0: >=20 >=20On Sat, 18 Jul 2026 12:21:55 +0800 Jackie Liu wro= te: >=20 >=20>=20 >=20> From: Jackie Liu > >=20=20 >=20> alloc_cpu_rmap() assigns an object index to each possible CPU usin= g > > cpu % size. Passing zero therefore triggers a divide error instead o= f > > reporting that the map cannot be allocated. > >=20 >=20Is there any situation in which this is known to trigger? >=20 >=20>=20 >=20> Reject zero along with sizes that do not fit in the u16 map indices= . > >=20 >=20If passing zero is a caller bug then a divide-by-zero exception is a > fine way of reporting it. So I'm not seeing a need to make any change > here. > Thanks. I rechecked all in-tree callers and couldn't find a path which can legitimately pass zero. The size is either explicitly checked or derived from successfully allocated IRQ/RX queue counts, whose minimum is one. So zero would indeed indicate a caller bug. Please disregard this patch.