linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH] crypto: lib/chacha20poly1305 - Set SG_MITER_ATOMIC unconditionally
Date: Tue, 15 Sep 2020 10:08:53 +0300	[thread overview]
Message-ID: <CAMj1kXFU7fkUgfPPqOVzTeVrJPm0RUPG4dd9WGiVt6yhmGaEag@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wie0Kb-+XOZNasoay7AKCaQ8Ew8=LyvWTBeiPXC3v2GSA@mail.gmail.com>

On Tue, 15 Sep 2020 at 09:56, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Sep 14, 2020 at 11:45 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > I mean, I did find one case that didn't set it (cb710-mmc.c), but
> > pattern-matching to the other mmc cases, that one looks like it
> > _should_ have set the atomic flag like everybody else did.
>
> Oh, and immediately after sending that out I notice
> nvmet_bdev_execute_rw(), which does seem to make allocations inside
> that sg_miter loop.
>
> So those non-atomic cases do clearly exist.
>
> It does make the case for why kmap_atomic() wants to have the
> debugging code. It will "just work" on 64-bit to do it wrong, because
> the address doesn't become invalid just because you sleep or get
> rescheduled. But then the code that every developer tests (since
> developers tend to run on good hardware) might be completely broken on
> bad old hardware.
>

If we want code that is optimal on recent hardware, and yet still
correct on older 32-bit hardware, kmap() is definitely a better choice
here than kmap_atomic(), since it is a no-op on !HIGHMEM, and
tolerates sleeping on 32-bit. /That/ is why I wrote the code this way.

The problem is of course that kmap() itself might sleep.

So I would argue that the semantics in the name of kmap_atomic() are
not about the fact that it starts a non-preemptible section, but that
it can be *called from* a non-preemptible section. And starting a
non-preemptible section is unnecessary on !HIGHMEM, and should be
avoided if possible.

> Maybe we could hide it behind a debug option, at least.
>
> Or, alterantively, introduce a new "debug_preempt_count" that doesn't
> actually disable preemption, but warns about actual sleeping
> operations..
>
>              Linus

  parent reply	other threads:[~2020-09-15  7:10 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200914204209.256266093@linutronix.de>
     [not found] ` <20200914204441.579902354@linutronix.de>
2020-09-15 16:10   ` [patch 06/13] locking/bitspinlock: Clenaup PREEMPT_COUNT leftovers Will Deacon
     [not found] ` <20200914204441.375753691@linutronix.de>
2020-09-15 16:11   ` [patch 04/13] lockdep: " Will Deacon
     [not found] ` <CAHk-=win80rdof8Pb=5k6gT9j_v+hz-TQzKPVastZDvBe9RimQ@mail.gmail.com>
2020-09-15 17:25   ` [patch 00/13] preempt: Make preempt count unconditional Paul E. McKenney
     [not found]   ` <871rj4owfn.fsf@nanos.tec.linutronix.de>
     [not found]     ` <CAHk-=wj0eUuVQ=hRFZv_nY7g5ZLt7Fy3K7SMJL0ZCzniPtsbbg@mail.gmail.com>
     [not found]       ` <CAHk-=wjOV6f_ddg+QVCF6RUe+pXPhSR2WevnNyOs9oT+q2ihEA@mail.gmail.com>
2020-09-15  3:30         ` [PATCH] crypto: lib/chacha20poly1305 - Set SG_MITER_ATOMIC unconditionally Herbert Xu
2020-09-15  6:03           ` Ard Biesheuvel
2020-09-15  6:40             ` Herbert Xu
2020-09-15  6:45           ` Linus Torvalds
2020-09-15  6:55             ` Linus Torvalds
2020-09-15  7:05               ` Herbert Xu
2020-09-15  7:10                 ` Ard Biesheuvel
2020-09-15  9:34                 ` Thomas Gleixner
2020-09-15 10:02                   ` Ard Biesheuvel
2020-09-15 10:05                     ` Herbert Xu
2020-09-15 10:08                       ` Ard Biesheuvel
2020-09-15 10:10                         ` Herbert Xu
2020-09-15 19:04                           ` Thomas Gleixner
2020-09-15  7:08               ` Ard Biesheuvel [this message]
2020-09-15  6:20         ` [patch 00/13] preempt: Make preempt count unconditional Ard Biesheuvel
     [not found]           ` <20200915062253.GA26275@gondor.apana.org.au>
2020-09-15  6:39             ` Linus Torvalds
2020-09-15  7:24               ` Thomas Gleixner
2020-09-15 17:29                 ` Linus Torvalds
2020-09-15  8:39       ` Thomas Gleixner
2020-09-15 17:35         ` Linus Torvalds
2020-09-15 19:57           ` Thomas Gleixner
2020-09-16 18:34             ` Linus Torvalds
2020-09-16  7:37           ` Daniel Vetter
2020-09-16 15:29             ` Paul E. McKenney
2020-09-16 18:32               ` Linus Torvalds
2020-09-16 20:43                 ` Paul E. McKenney
2020-09-17  6:38                 ` Ard Biesheuvel
2020-09-16 20:29               ` Daniel Vetter
2020-09-16 20:58                 ` Paul E. McKenney
2020-09-16 21:43                   ` Daniel Vetter
2020-09-16 22:39                     ` Paul E. McKenney
2020-09-17  7:52                       ` Daniel Vetter
2020-09-17 16:28                         ` Paul E. McKenney
2020-09-29  8:19                     ` Michal Hocko
2020-09-29  8:19                       ` Michal Hocko
2020-09-29  8:20                       ` Michal Hocko
2020-09-29  8:21                       ` Michal Hocko
2020-09-29  8:23                       ` Michal Hocko
2020-09-29  9:00                       ` Daniel Vetter
2020-09-29 14:54                         ` Michal Hocko
2020-09-16 19:23     ` Matthew Wilcox
2020-09-16 20:48       ` Paul E. McKenney
     [not found] ` <20200914204441.268144917@linutronix.de>
2020-09-16 10:56   ` [patch 03/13] preempt: Clenaup PREEMPT_COUNT leftovers Valentin Schneider
     [not found] ` <20200914204441.794954043@linutronix.de>
2020-09-16 10:56   ` [patch 08/13] sched: " Valentin Schneider

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMj1kXFU7fkUgfPPqOVzTeVrJPm0RUPG4dd9WGiVt6yhmGaEag@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).