Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH] mm/page-writeback.c: avoid potential division by zero
Date:   Wed, 1 Jan 2020 07:39:48 -0500
Message-Id: <230E8A87-2900-427B-9EA3-CC48B4DCA5FC@lca.pw>
References: <20200101093204.3592-1-wenyang@linux.alibaba.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        xlpang@linux.alibaba.com, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
In-Reply-To: <20200101093204.3592-1-wenyang@linux.alibaba.com>
To:     Wen Yang <wenyang@linux.alibaba.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jan 1, 2020, at 4:32 AM, Wen Yang <wenyang@linux.alibaba.com> wrote:
>=20
> The variables 'min', 'max' and 'bw' are unsigned long and
> do_div truncates them to 32 bits, which means it can test
> non-zero and be truncated to zero for division.
> Fix this issue by using div64_ul() instead.

How did you find out the issue? If it is caught by compilers, can you paste t=
he original warnings? Also, can you figure out which commit introduced the i=
ssue in the first place, so it could be backported to stable if needed?

>=20
> For the two variables 'numerator' and 'denominator',
> though they are declared as long, they should actually be
> unsigned long (according to the implementation of
> the fprop_fraction_percpu() function).