Re: [PATCH v5 net-next 02/36] iov_iter: DDP copy to iter/pages
From: Christoph Hellwig <hch@infradead.org>
Date: 2021-07-22 13:41:14
Also in:
netdev
quoted hunk ↗ jump to hunk
+#ifdef CONFIG_ULP_DDP +size_t _ddp_copy_to_iter(const void *addr, size_t bytes, struct iov_iter *i); +#endif size_t _copy_from_iter(void *addr, size_t bytes, struct iov_iter *i); bool _copy_from_iter_full(void *addr, size_t bytes, struct iov_iter *i); size_t _copy_from_iter_nocache(void *addr, size_t bytes, struct iov_iter *i);@@ -145,6 +148,16 @@ size_t copy_to_iter(const void *addr, size_t bytes, struct iov_iter *i) return _copy_to_iter(addr, bytes, i); } +#ifdef CONFIG_ULP_DDP +static __always_inline __must_check +size_t ddp_copy_to_iter(const void *addr, size_t bytes, struct iov_iter *i) +{ + if (unlikely(!check_copy_size(addr, bytes, true))) + return 0; + return _ddp_copy_to_iter(addr, bytes, i); +} +#endif
There is no need to ifdef out externs with conditional implementations, or inlines using them.
+#ifdef CONFIG_ULP_DDP +static void ddp_memcpy_to_page(struct page *page, size_t offset, const char *from, size_t len)
Overly long line.
+ char *to = kmap_atomic(page); + + if (to + offset != from) + memcpy(to + offset, from, len); + + kunmap_atomic(to);
This looks completely bogus to any casual read, so please document why it makes sense. And no, a magic, unexplained ddp in the name does not count as explanation at all. Please think about a more useful name. Can this ever write to user page? If yes it needs a flush_dcache_page. Last but not least: kmap_atomic is deprecated except for the very rate use case where it is actually called from atomic context. Please use kmap_local_page instead.
+#ifdef CONFIG_CRYPTO_HASH + struct ahash_request *hash = hashp; + struct scatterlist sg; + size_t copied; + + copied = ddp_copy_to_iter(addr, bytes, i); + sg_init_one(&sg, addr, copied); + ahash_request_set_crypt(hash, &sg, NULL, copied); + crypto_ahash_update(hash); + return copied; +#else + return 0; +#endif
What is the point of this stub? To me it looks extremely dangerous. _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme