Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: l/gVGa17sM5qa3ga4hhBvy0b2nCYooC8+e8k8zPk3oEP6+N5feC+DJ6XGD3KkSTs3TD9V/FZUI
 M4z+3m+PzNnQ==
IronPort-SDR: ZgaIrmckF0JcL73H8IeXBynjPAIxVQgl3TYj/R0jJtGJy0Bs0pKADSeLxmbBjwd79XD8FTKvW5
 cRKL8dm/2pJw==
Date:   Wed, 26 May 2021 11:00:51 +0300
From:   Andy Shevchenko <andriy.shevchenko@intel.com>
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Trent Piepho <tpiepho@gmail.com>, linux-kernel@vger.kernel.org,
        andy@kernel.org, oskar@scara.com,
        Daniel Latypov <dlatypov@google.com>,
        Yiyuan Guo <yguoaz@gmail.com>
Subject: Re: [PATCH v2 1/2] lib/math/rational.c: Fix divide by zero
Message-ID: <YK4AM3J6W44GTKTA@smile.fi.intel.com>
References: <20210525144250.214670-1-tpiepho@gmail.com>
 <20210525144654.e41cb942a2804d08127ad48f@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210525144654.e41cb942a2804d08127ad48f@linux-foundation.org>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

On Tue, May 25, 2021 at 02:46:54PM -0700, Andrew Morton wrote:
> On Tue, 25 May 2021 07:42:49 -0700 Trent Piepho <tpiepho@gmail.com> wrote:
> 
> > If the input is out of the range of the allowed values, either larger
> > than the largest value or closer to zero than the smallest non-zero
> > allowed value, then a division by zero would occur.
> > 
> > In the case of input too large, the division by zero will occur on the
> > first iteration.  The best result (largest allowed value) will be found
> > by always choosing the semi-convergent and excluding the denominator
> > based limit when finding it.
> > 
> > In the case of the input too small, the division by zero will occur on
> > the second iteration.  The numerator based semi-convergent should not be
> > calculated to avoid the division by zero.  But the semi-convergent vs
> > previous convergent test is still needed, which effectively chooses
> > between 0 (the previous convergent) vs the smallest allowed fraction
> > (best semi-convergent) as the result.
> 
> Is there any known userspace workload which can trigger this?

Doubtfully.

What I can imagine (which also can be impossible) is to try on some UART
drivers that use this algorithm to ask crazy baud rates (much higher than the
clock). Sounds like a theoretical possibility is present, but practically
no one except bad hackers would do that (requires a special code to be written
in user space to select BOTHER with an arbitrary input in termios).

> IOW, should it be backported into -stable and fast-tracked into 5.13 or
> will a 5.14 merge suffice?

-- 
With Best Regards,
Andy Shevchenko