Re: [PATCH RFC 31/35] crypto: remove nth_page() usage within SG entry
Linus Torvalds <[email protected]>
| Newsgroups | com.zx2c4.lists.wireguard,dev.linux.lists.iommu,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.io-uring,org.kernel.vger.kvm,org.kernel.vger.linux-crypto,org.kernel.vger.linux-ide,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-mips,org.kernel.vger.linux-mmc,org.kernel.vger.linux-s390,org.kernel.vger.linux-scsi,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <CAHk-=wjGzyGPgqKDNXM6_2Puf7OJ+DQAXMg5NgtSASN8De1roQ@mail.gmail.com> |
On Thu, 21 Aug 2025 at 16:08, David Hildenbrand <[email protected]> wrote: > > - page = nth_page(page, offset >> PAGE_SHIFT); > + page += offset / PAGE_SIZE; Please keep the " >> PAGE_SHIFT" form. Is "offset" unsigned? Yes it is, But I had to look at the source code to make sure, because it wasn't locally obvious from the patch. And I'd rather we keep a pattern that is "safe", in that it doesn't generate strange code if the value might be a 's64' (eg loff_t) on 32-bit architectures. Because doing a 64-bit shift on x86-32 is like three cycles. Doing a 64-bit signed division by a simple constant is something like ten strange instructions even if the end result is only 32-bit. And again - not the case *here*, but just a general "let's keep to one pattern", and the shift pattern is simply the better choice. Linus