> > On 08/03/2017 09:59 AM, Wen Yang wrote:
> > From: Jiang Biao <jiang.biao2@xxxxxxxxxx>
> >
> > When order is -1 or too big, *1UL << order* will be 0, which will
> > cause divide error like this,
> >
> > divide error: 0000 [#1] SMP
> > Call Trace:
>> [<ffffffff81168423>] compaction_suitable+0x63/0xc0
>> ...
> The trace seems to be from an old and non-mainline kernel, as it's the
> same as you reported here:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=196555
>
> In current mainline it seems to me that all callers of
> __fragmentation_index() will only do so with a valid order.
>
> I wouldn't mind making a non-hotpath code more robust, but probably in a
> more obvious and self-reporting/documented way e.g. something like
>
> if (WARN_ON_ONCE(order >= MAX_ORDER))
> return 0;
>
> > {
> > unsigned long requested = 1UL << order;
> >
> > + if (!requested)
> > + return 0;
>
> Seems the indentation is broken here (spaces vs tabs).
I'll fix that.
> >
> > When order is -1 or too big, *1UL << order* will be 0, which will
> > cause divide error like this,
> >
> > divide error: 0000 [#1] SMP
> > Call Trace:
>> [<ffffffff81168423>] compaction_suitable+0x63/0xc0
>> ...
> The trace seems to be from an old and non-mainline kernel, as it's the
> same as you reported here:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=196555
>
> In current mainline it seems to me that all callers of
> __fragmentation_index() will only do so with a valid order.
>
> I wouldn't mind making a non-hotpath code more robust, but probably in a
> more obvious and self-reporting/documented way e.g. something like
>
> if (WARN_ON_ONCE(order >= MAX_ORDER))
> return 0;
>
yes, I noticed that, I'll send a new patch for that.
> > {
> > unsigned long requested = 1UL << order;
> >
> > + if (!requested)
> > + return 0;
>
> Seems the indentation is broken here (spaces vs tabs).
I'll fix that.