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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 Aug 2021 18:43:39 +0100 From: Matthew Wilcox <willy@...radead.org> To: Vlastimil Babka <vbabka@...e.cz> Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, linux-fsdevel@...r.kernel.org, Yu Zhao <yuzhao@...gle.com>, Christoph Hellwig <hch@....de>, David Howells <dhowells@...hat.com>, "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com> Subject: Re: [PATCH v14 011/138] mm/lru: Add folio LRU functions On Tue, Aug 10, 2021 at 06:01:16PM +0200, Vlastimil Babka wrote: > Actually looking at the git version, which has also this: > > static __always_inline void update_lru_size(struct lruvec *lruvec, > enum lru_list lru, enum zone_type zid, > - int nr_pages) > + long nr_pages) > { > > Why now and here? Some of the functions called from update_lru_size() > still take int so this looks arbitrary? I'm still a little freaked out about the lack of warning for: void f(long n); void g(unsigned int n) { f(-n); } so I've decided that the count of pages in a folio is always of type long. The actual number is positive, and currently it's between 1 and 1024 (inclusive on both bounds), so it's always going to be representable in an int. Narrowing it doesn't cause a bug, so we don't need to change nr_pages anywhere, but it does no harm to make functions take a long instead of an int (it may even cause slightly better code generation, based on the sample of functions I've looked at). Maybe changing update_lru_size() in this patch is wrong. I can drop it if you like.
Powered by blists - more mailing lists