linux-ext4 - Re: [PATCH 1/1] mm: change inlined allocation helpers to account at the call site

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Zg7dmp5VJkm1nLRM@casper.infradead.org>
Date: Thu, 4 Apr 2024 18:04:26 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: akpm@...ux-foundation.org, joro@...tes.org, will@...nel.org,
	trond.myklebust@...merspace.com, anna@...nel.org, arnd@...db.de,
	herbert@...dor.apana.org.au, davem@...emloft.net, jikos@...nel.org,
	benjamin.tissoires@...hat.com, tytso@....edu, jack@...e.com,
	dennis@...nel.org, tj@...nel.org, cl@...ux.com,
	jakub@...udflare.com, penberg@...nel.org, rientjes@...gle.com,
	iamjoonsoo.kim@....com, vbabka@...e.cz, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, iommu@...ts.linux.dev,
	linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-acpi@...r.kernel.org, acpica-devel@...ts.linux.dev,
	linux-arch@...r.kernel.org, linux-crypto@...r.kernel.org,
	bpf@...r.kernel.org, linux-input@...r.kernel.org,
	linux-ext4@...r.kernel.org, linux-mm@...ck.org,
	netdev@...r.kernel.org, linux-security-module@...r.kernel.org,
	kent.overstreet@...ux.dev
Subject: Re: [PATCH 1/1] mm: change inlined allocation helpers to account at
 the call site

On Thu, Apr 04, 2024 at 09:54:04AM -0700, Suren Baghdasaryan wrote:
> +++ b/include/linux/dma-fence-chain.h
> @@ -86,10 +86,7 @@ dma_fence_chain_contained(struct dma_fence *fence)
>   *
>   * Returns a new struct dma_fence_chain object or NULL on failure.
>   */
> -static inline struct dma_fence_chain *dma_fence_chain_alloc(void)
> -{
> -	return kmalloc(sizeof(struct dma_fence_chain), GFP_KERNEL);
> -};
> +#define dma_fence_chain_alloc()	kmalloc(sizeof(struct dma_fence_chain), GFP_KERNEL)

You've removed some typesafety here.  Before, if I wrote:

	struct page *page = dma_fence_chain_alloc();

the compiler would warn me that I've done something stupid.  Now it
can't tell.  Suggest perhaps:

#define dma_fence_chain_alloc()						  \
	(struct dma_fence_chain *)kmalloc(sizeof(struct dma_fence_chain), \
						GFP_KERNEL)

but maybe there's a better way of doing that.  There are a few other
occurrences of the same problem in this monster patch.

> +++ b/include/linux/hid_bpf.h
> @@ -149,10 +149,7 @@ static inline int hid_bpf_connect_device(struct hid_device *hdev) { return 0; }
>  static inline void hid_bpf_disconnect_device(struct hid_device *hdev) {}
>  static inline void hid_bpf_destroy_device(struct hid_device *hid) {}
>  static inline void hid_bpf_device_init(struct hid_device *hid) {}
> -static inline u8 *call_hid_bpf_rdesc_fixup(struct hid_device *hdev, u8 *rdesc, unsigned int *size)
> -{
> -	return kmemdup(rdesc, *size, GFP_KERNEL);
> -}
> +#define call_hid_bpf_rdesc_fixup(_hdev, _rdesc, _size) kmemdup(_rdesc, *(_size), GFP_KERNEL)

here

> -static inline handle_t *jbd2_alloc_handle(gfp_t gfp_flags)
> -{
> -	return kmem_cache_zalloc(jbd2_handle_cache, gfp_flags);
> -}
> +#define jbd2_alloc_handle(_gfp_flags)	kmem_cache_zalloc(jbd2_handle_cache, _gfp_flags)

here

> +++ b/include/linux/skmsg.h
> @@ -410,11 +410,8 @@ void sk_psock_stop_verdict(struct sock *sk, struct sk_psock *psock);
>  int sk_psock_msg_verdict(struct sock *sk, struct sk_psock *psock,
>  			 struct sk_msg *msg);
>  
> -static inline struct sk_psock_link *sk_psock_init_link(void)
> -{
> -	return kzalloc(sizeof(struct sk_psock_link),
> -		       GFP_ATOMIC | __GFP_NOWARN);
> -}
> +#define sk_psock_init_link()	\
> +		kzalloc(sizeof(struct sk_psock_link), GFP_ATOMIC | __GFP_NOWARN)

here

... I kind of gave up at this point.  You'll want to audit for yourself
anyway ;-)