linux-kernel - Re: [syzbot] BUG: sleeping function called from invalid context in __might

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5073833.kmqaQDgJIs@localhost.localdomain>
Date:   Tue, 16 Nov 2021 12:35:27 +0100
From:   "Fabio M. De Francesco" <fmdefrancesco@...il.com>
To:     Marco Elver <elver@...gle.com>
Cc:     syzkaller-bugs@...glegroups.com,
        syzbot <syzbot+5f47a8cea6a12b77a876@...kaller.appspotmail.com>,
        gregkh@...uxfoundation.org, jirislaby@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [syzbot] BUG: sleeping function called from invalid context in __might_resched

On Tuesday, November 16, 2021 11:24:54 AM CET Marco Elver wrote:
> On Tue, 16 Nov 2021 at 08:57, Fabio M. De Francesco
> <fmdefrancesco@...il.com> wrote:
> [...]
> > I think that this is more readable and comprehensible.
> >
> > Therefore, if I'm not wrong, Marco's "!preemptible()", that is "if (!
> > (preempt_count() == 0 && !irqs_disabled())", might be rewritten to an 
easier
> > to understand "if (preempt_count() || irqs_disabled())".
> >
> > Am I wrong? Let's test it...
> 
> It's right, but why not use preemptible()? The definition of
> preemptible() might change and then you'd have to fix the code again.
> 
> I actually find (preempt_count() || irqs_disabled()) tells me less of
> what your intent here is vs. just writing !preemptible().
> 
You are right :)

If we have a macro, there must be a good reason behind its existence. So 
let's use it. 

For I didn't know that we have that macro, I had to read its definition. Then 
I had to understand what means the negation of its parts. It was a bit 
difficult to understand, so I thought that open coding if we have preemption 
disabled or irqs disabled was easier to understand.

But now I see that, as said, if we have an API we should use it.

I'm preparing a patch and give you proper credit for suggestions.

Thanks,

Fabio M. De Francesco