From: Alexander Potapenko <glider@google.com> To: Marco Elver <elver@google.com> Cc: Wolfram Sang <wsa@the-dreams.de>, Vegard Nossum <vegard.nossum@oracle.com>, Dmitry Vyukov <dvyukov@google.com>, Linux Memory Management List <linux-mm@kvack.org>, Al Viro <viro@zeniv.linux.org.uk>, Andreas Dilger <adilger.kernel@dilger.ca>, Andrew Morton <akpm@linux-foundation.org>, Andrey Konovalov <andreyknvl@google.com>, Andrey Ryabinin <aryabinin@virtuozzo.com>, Andy Lutomirski <luto@kernel.org>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Arnd Bergmann <arnd@arndb.de>, Christoph Hellwig <hch@infradead.org>, Christoph Hellwig <hch@lst.de>, "Darrick J. Wong" <darrick.wong@oracle.com>, David Miller <davem@davemloft.net>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, Eric Biggers <ebiggers@google.com>, Eric Dumazet <edumazet@google.com>, Eric Van Hensbergen <ericvh@gmail.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Harry Wentland <harry.wentland@amd.com>, Herbert Xu <herbert@gondor.apana.org.au>, Ilya Leoshkevich <iii@linux.ibm.com>, Ingo Molnar <mingo@elte.hu>, Jason Wang <jasowang@redhat.com>, Jens Axboe <axboe@kernel.dk>, Marek Szyprowski <m.szyprowski@samsung.com>, Mark Rutland <mark.rutland@arm.com>, "Martin K . Petersen" <martin.petersen@oracle.com>, Martin Schwidefsky <schwidefsky@de.ibm.com>, Matthew Wilcox <willy@infradead.org>, "Michael S. Tsirkin" <mst@redhat.com>, Michal Simek <monstr@monstr.eu>, Petr Mladek <pmladek@suse.com>, Qian Cai <cai@lca.pw>, Randy Dunlap <rdunlap@infradead.org>, Robin Murphy <robin.murphy@arm.com>, Sergey Senozhatsky <sergey.senozhatsky@gmail.com>, Steven Rostedt <rostedt@goodmis.org>, Takashi Iwai <tiwai@suse.com>, "Theodore Ts'o" <tytso@mit.edu>, Thomas Gleixner <tglx@linutronix.de>, Vasily Gorbik <gor@linux.ibm.com> Subject: Re: [PATCH RFC v3 10/36] kmsan: add KMSAN runtime Date: Thu, 19 Dec 2019 15:16:16 +0100 Message-ID: <CAG_fn=UR7bb1MS3gyceBhY588TuqYjTetd-M0pTgpOdqOL1q0Q@mail.gmail.com> (raw) In-Reply-To: <20191129160725.GA236510@google.com> > Could all these just be using '.macro .endm'? Done in v4 > > +__no_sanitize_memory > > +static inline unsigned long KMSAN_INIT_8(unsigned long value) > > +{ > > + return value; > > +} > > Should the above be __always_inline? No. __always_inline forces a non-instrumented function to be inlined into its instrumented caller, which results in the former being instrumented. I've updated the comment to reflect that. > Does it make sense to use u8, u16, u32, u64 here -- just in case it's > ported to other architectures in future? Done in v4. > > + default: \ > > + BUILD_BUG_ON(1); \ > > + } \ > > + __ret; \ > > + }) /**/ > > Is the /**/ needed? No, as long as we use .macro and .endm. > > It would be good to add doc comments to all API functions. Done in v4 > > +extern bool kmsan_ready; > > What does this variable mean. Would 'kmsan_enabled' be more accurate? I think kmsan_inited is a better name, if we want to change it at all. kmsan_enabled somewhat implies KMSAN can be disabled. > This is in include/linux -- do they need a KMSAN_ prefix to not clash > with other definitions? Done in v4. > > +#define KMSAN_PARAM_SIZE 800 > > + > > +#define PARAM_ARRAY_SIZE (KMSAN_PARAM_SIZE / sizeof(depot_stack_handle_t)) > > Similar here -- does it need a KMSAN_ prefix? Done in v4. > > +void kmsan_clear_page(void *page_addr); > > It would be good to have doc comments for each of them. Done in v4. > > + > > +KMSAN_SANITIZE := n > > +KCOV_INSTRUMENT := n > > Does KMSAN work together with UBSAN? In that case may this needs a > UBSAN_SANITIZE := n Done > > +#include <linux/stackdepot.h> > > +#include <linux/stacktrace.h> > > +#include <linux/types.h> > > +#include <linux/vmalloc.h> > > + > > +#include <linux/mmzone.h> > > Why the space above the mmzone.h include? Removed it, also fixed the include order for this file. > > +/* > > + * Some kernel asm() calls mention the non-existing |__force_order| variable > > + * in the asm constraints to preserve the order of accesses to control > > + * registers. KMSAN turns those mentions into actual memory accesses, therefore > > + * the variable is now required to link the kernel. > > + */ > > +unsigned long __force_order; > > Not sure if this is related, but when compiling with KMSAN I get > > ERROR: "__force_order" [drivers/misc/lkdtm/lkdtm.ko] undefined! > > with a default config with KMSAN selected. Added an EXPORT_SYMBOL to fix this. > > > +bool kmsan_ready; > > +#define KMSAN_STACK_DEPTH 64 > > +#define MAX_CHAIN_DEPTH 7 > > Should these defines be above the variable definitions? Done > > Why not just 'panic("%s: ...", __func__, ...)' ? > > If the BUG() should not be here, then maybe just WARN_ON? Replaced with panic(). > > + > > +/* > > + * TODO(glider): writing an initialized byte shouldn't zero out the origin, if > > + * the remaining three bytes are uninitialized. > > + */ > > What needs to be done to address the TODO? Just adding a comment is > fine (or if the TODO can be resolved that's also fine). Filed https://github.com/google/kmsan/issues/70 to track this. This isn't a showstopper. > > + if (checked && !metadata_is_contiguous(addr, size, META_ORIGIN)) { > > + kmsan_pr_locked("WARNING: not setting origin for %d bytes starting at %px, because the metadata is incontiguous\n", size, addr); > > + BUG(); > > Just panic? Done. > > +/* > > + * TODO(glider): this check shouldn't be performed for origin pages, because > > + * they're always accessed after the shadow pages. > > + */ > > What needs to be done to address the TODO? Just adding a comment is > fine (or if the TODO can be resolved that's also fine). Dropped the TODO. This is somewhat perfectionist. > > + if (origin_p) { > > + kmsan_pr_locked("Origin: %08x\n", *origin_p); > > + kmsan_print_origin(*origin_p); > > + } else { > > + kmsan_pr_locked("Origin: unavailable\n"); > > + } > > These repeated calls to kmsan_pr_locked seem unnecessary. There is > nothing ensuring atomicity of all these print calls w.r.t. reporting. Replaced them with pr_err(). > > +/* Stolen from kernel/printk/internal.h */ > > +#define PRINTK_SAFE_CONTEXT_MASK 0x3fffffff > > Is this used anywhere? No. Removed it. > > +/* Called by kmsan_report.c under a lock. */ > > +#define kmsan_pr_err(...) pr_err(__VA_ARGS__) > > Why is this macro needed? It's never redefined, so in the places it is > used, you can just use pr_err. For readability I would avoid unnecessary > aliases, but if there is a genuine reason this may be needed in future, > I would just add a comment. I've removed the macro. > > +/* Used in other places - doesn't require a lock. */ > > +#define kmsan_pr_locked(...) \ > > + do { \ > > + unsigned long flags; \ > > + spin_lock_irqsave(&report_lock, flags); \ > > + pr_err(__VA_ARGS__); \ > > + spin_unlock_irqrestore(&report_lock, flags); \ > > + } while (0) > > Is this macro needed? The only reason it sort of makes sense is to > serialize a report with other printing, but otherwise pr_err already > makes sure things are serialized properly. Yes, this was the intention. On the other hand, this lock doesn't prevent non-KMSAN code from messing up KMSAN reports, so it makes little sense. Maybe we can just keep the spinlock to separate the reports from each other. > > +enum KMSAN_BUG_REASON { > > + REASON_ANY = 0, > > + REASON_COPY_TO_USER = 1, > > + REASON_USE_AFTER_FREE = 2, > > + REASON_SUBMIT_URB = 3, > > +}; > > Is it required to explicitly assign constants to these? No. Removed the constants. > > +#define LEAVE_RUNTIME(irq_flags) \ > > + do { \ > > + this_cpu_dec(kmsan_in_runtime); \ > > + if (this_cpu_read(kmsan_in_runtime)) { \ > > + kmsan_pr_err("kmsan_in_runtime: %d\n", \ > > + this_cpu_read(kmsan_in_runtime)); \ > > + BUG(); \ > > + } \ > > + restart_nmi(); \ > > + local_irq_restore(irq_flags); \ > > + preempt_enable(); } while (0) > > Could these not be macros, and instead be static __always_inline > functions? Done > > +static void kmsan_context_exit(void) > > +{ > > + int level = this_cpu_read(kmsan_context_level) - 1; > > + > > + BUG_ON(level < 0); > > + this_cpu_write(kmsan_context_level, level); > > +} > > These are not preemption-safe. this_cpu_dec_return followed by the > BUG_ON should be sufficient. Similarly above and below (using > this_cpu_add_return) Good catch, thank you! > > +void kmsan_interrupt_exit(void) > > +{ > > + int in_interrupt = this_cpu_read(kmsan_in_interrupt); > > + > > + BUG_ON(!in_interrupt); > > + kmsan_context_exit(); > > + /* Can't check preempt_count() here, it may be zero. */ > > + this_cpu_write(kmsan_in_interrupt, in_interrupt - 1); > > +} > > +EXPORT_SYMBOL(kmsan_interrupt_exit); > > Why exactly does kmsan_in_interrupt need to be maintained here? I can't > see them being used anywhere else. Is it only for the BUG_ON? Yes, initially some consistency checks made sense. I think it's safe to delete them now. > > +void kmsan_softirq_exit(void) > > +{ > > + bool in_softirq = this_cpu_read(kmsan_in_softirq); > > + > > + BUG_ON(!in_softirq); > > + kmsan_context_exit(); > > + /* Can't check preempt_count() here, it may be zero. */ > > + this_cpu_write(kmsan_in_softirq, false); > > +} > > +EXPORT_SYMBOL(kmsan_softirq_exit); > > Same question here for kmsan_in_softirq. Ditto > > +void kmsan_nmi_exit(void) > > +{ > > + bool in_nmi = this_cpu_read(kmsan_in_nmi); > > + > > + BUG_ON(!in_nmi); > > + BUG_ON(preempt_count() & NMI_MASK); > > + kmsan_context_exit(); > > + this_cpu_write(kmsan_in_nmi, false); > > + > > +} > > +EXPORT_SYMBOL(kmsan_nmi_exit); > > And same question here for kmsan_in_nmi. Ditto. > > + > > +/* > > + * Record a range of memory for which the metadata pages will be created once > > + * the page allocator becomes available. > > + * TODO(glider): squash together ranges belonging to the same page. > > + */ > > What needs to be done to address the TODO? Just adding a comment is > fine (or if the TODO can be resolved that's also fine). Removed the TODO. There's a problem with non-contiguous pages which is tracked at https://github.com/google/kmsan/issues/71 > > + /* > > + * TODO(glider): alloc_node_data() in arch/x86/mm/numa.c uses > > + * sizeof(pg_data_t). > > + */ > > What needs to be done to address the TODO? Just adding a comment is > fine (or if the TODO can be resolved that's also fine). Resolved this (the code is actually correct) > > + > > + if (IN_RUNTIME()) { > > + /* > > + * TODO(glider): looks legit. depot_save_stack() may call > > + * free_pages(). > > + */ > > What needs to be done to address the TODO? Just adding a comment is > fine (or if the TODO can be resolved that's also fine). I've just dropped this if-clause. > > + return; > > + } > > + > > + ENTER_RUNTIME(irq_flags); > > + shadow = shadow_page_for(&page[0]); > > + origin = origin_page_for(&page[0]); > > + > > + /* TODO(glider): this is racy. */ > > Can this be fixed or does the race not matter -- in the latter case, > just remove the TODO and turn it into a NOTE or similar. It doesn't matter. Removed the comment. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
next prev parent reply index Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-22 11:25 [PATCH RFC v3 00/36] Add KernelMemorySanitizer infrastructure glider 2019-11-22 11:25 ` [PATCH RFC v3 01/36] stackdepot: check depot_index before accessing the stack slab glider 2019-11-27 14:22 ` Marco Elver 2019-11-22 11:25 ` [PATCH RFC v3 02/36] stackdepot: build with -fno-builtin glider 2019-11-27 14:22 ` Marco Elver 2019-11-22 11:25 ` [PATCH RFC v3 03/36] kasan: stackdepot: move filter_irq_stacks() to stackdepot.c glider 2019-11-27 14:22 ` Marco Elver 2019-11-27 14:56 ` Alexander Potapenko 2019-11-22 11:25 ` [PATCH RFC v3 04/36] stackdepot: reserve 5 extra bits in depot_stack_handle_t glider 2019-11-27 14:23 ` Marco Elver 2019-11-22 11:25 ` [PATCH RFC v3 05/36] kmsan: add ReST documentation glider 2019-11-27 14:22 ` Marco Elver 2019-12-03 12:42 ` Alexander Potapenko 2019-11-22 11:25 ` [PATCH RFC v3 06/36] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW glider 2019-11-27 14:48 ` Marco Elver 2019-12-03 12:57 ` Alexander Potapenko 2019-11-22 11:25 ` [PATCH RFC v3 07/36] kmsan: introduce __no_sanitize_memory and __SANITIZE_MEMORY__ glider 2019-11-28 13:13 ` Marco Elver 2019-11-29 16:09 ` Andrey Konovalov 2019-12-16 11:35 ` Alexander Potapenko 2019-11-22 11:25 ` [PATCH RFC v3 08/36] kmsan: reduce vmalloc space glider 2019-11-28 13:30 ` Marco Elver 2019-11-22 11:25 ` [PATCH RFC v3 09/36] kmsan: add KMSAN bits to struct page and struct task_struct glider 2019-11-28 13:44 ` Marco Elver 2019-11-28 14:05 ` Alexander Potapenko 2019-11-22 11:25 ` [PATCH RFC v3 10/36] kmsan: add KMSAN runtime glider 2019-11-24 19:44 ` Wolfram Sang 2019-11-25 9:14 ` Alexander Potapenko 2019-11-29 16:07 ` Marco Elver 2019-12-19 14:16 ` Alexander Potapenko [this message] 2019-12-02 15:39 ` Andrey Konovalov 2019-12-20 18:58 ` Alexander Potapenko 2019-12-03 14:34 ` Andrey Konovalov 2019-11-22 11:25 ` [PATCH RFC v3 11/36] kmsan: stackdepot: don't allocate KMSAN metadata for stackdepot glider 2019-11-29 14:52 ` Andrey Konovalov 2019-12-03 14:27 ` Alexander Potapenko 2019-11-22 11:25 ` [PATCH RFC v3 12/36] kmsan: define READ_ONCE_NOCHECK() glider 2019-12-02 10:03 ` Marco Elver 2019-12-03 12:45 ` Alexander Potapenko 2019-11-22 11:25 ` [PATCH RFC v3 13/36] kmsan: make READ_ONCE_TASK_STACK() return initialized values glider 2019-12-02 10:07 ` Marco Elver 2019-12-05 15:52 ` Alexander Potapenko 2019-11-22 11:25 ` [PATCH RFC v3 14/36] kmsan: x86: sync metadata pages on page fault glider 2019-11-22 11:26 ` [PATCH RFC v3 15/36] kmsan: add tests for KMSAN glider 2019-11-29 14:14 ` Andrey Konovalov 2019-12-05 14:30 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 16/36] crypto: kmsan: disable accelerated configs under KMSAN glider 2019-12-02 13:25 ` Marco Elver 2019-12-05 14:51 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 17/36] kmsan: x86: disable UNWINDER_ORC " glider 2019-12-02 13:30 ` Marco Elver 2019-11-22 11:26 ` [PATCH RFC v3 18/36] kmsan: disable LOCK_DEBUGGING_SUPPORT glider 2019-12-02 13:33 ` Marco Elver 2019-12-03 14:34 ` Alexander Potapenko 2019-12-03 15:00 ` Qian Cai 2019-12-03 15:14 ` Alexander Potapenko 2019-12-03 18:02 ` Qian Cai 2019-12-03 18:38 ` Steven Rostedt 2019-12-04 8:41 ` Alexander Potapenko 2019-12-04 12:22 ` Petr Mladek 2019-12-04 13:12 ` Qian Cai 2019-12-04 16:24 ` Alexander Potapenko 2019-12-04 18:03 ` Qian Cai 2019-11-22 11:26 ` [PATCH RFC v3 20/36] kmsan: x86: increase stack sizes in KMSAN builds glider 2019-12-02 14:31 ` Marco Elver 2019-11-22 11:26 ` [PATCH RFC v3 21/36] kmsan: disable KMSAN instrumentation for certain kernel parts glider 2019-11-29 15:07 ` Andrey Konovalov 2019-12-10 10:35 ` Alexander Potapenko 2019-12-10 12:38 ` Alexander Potapenko 2019-12-10 12:43 ` Qian Cai 2019-11-22 11:26 ` [PATCH RFC v3 22/36] kmsan: mm: call KMSAN hooks from SLUB code glider 2019-12-02 15:36 ` Marco Elver 2019-12-10 12:07 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 23/36] kmsan: call KMSAN hooks where needed glider 2019-11-26 10:17 ` Petr Mladek 2019-11-26 10:52 ` Alexander Potapenko 2019-11-29 16:21 ` Andrey Konovalov 2019-12-16 11:30 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 24/36] kmsan: disable instrumentation of certain functions glider 2019-11-29 14:59 ` Andrey Konovalov 2019-12-18 10:02 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 25/36] kmsan: unpoison |tlb| in arch_tlb_gather_mmu() glider 2019-11-29 15:08 ` Andrey Konovalov 2019-12-03 14:19 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 26/36] kmsan: use __msan_memcpy() where possible glider 2019-11-29 15:13 ` Andrey Konovalov 2019-12-05 15:46 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 27/36] kmsan: hooks for copy_to_user() and friends glider 2019-11-29 15:34 ` Andrey Konovalov 2019-12-05 16:00 ` Alexander Potapenko 2019-12-05 16:44 ` Andrey Konovalov 2019-12-11 14:22 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 28/36] kmsan: enable KMSAN builds glider 2019-11-29 15:55 ` Andrey Konovalov 2019-12-11 12:51 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 29/36] kmsan: handle /dev/[u]random glider 2019-11-22 11:26 ` [PATCH RFC v3 30/36] kmsan: virtio: check/unpoison scatterlist in vring_map_one_sg() glider 2019-11-22 11:26 ` [PATCH RFC v3 31/36] kmsan: disable strscpy() optimization under KMSAN glider 2019-12-02 15:51 ` Marco Elver 2019-12-02 16:23 ` Alexander Potapenko 2019-12-03 11:19 ` Alexander Potapenko 2019-12-03 11:24 ` Marco Elver 2019-12-03 11:27 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 32/36] kmsan: add iomap support glider 2019-12-03 12:50 ` Marco Elver 2019-12-03 14:07 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 33/36] kmsan: dma: unpoison memory mapped by dma_direct_map_page() glider 2019-11-22 11:26 ` [PATCH RFC v3 34/36] kmsan: disable physical page merging in biovec glider 2019-12-03 12:54 ` Marco Elver 2019-12-03 13:38 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 35/36] kmsan: ext4: skip block merging logic in ext4_mpage_readpages for KMSAN glider 2019-11-25 16:05 ` Robin Murphy 2019-11-25 17:03 ` Alexander Potapenko 2019-12-03 14:22 ` Marco Elver 2019-12-05 14:31 ` Alexander Potapenko 2019-11-22 11:26 ` [PATCH RFC v3 36/36] net: kasan: kmsan: support CONFIG_GENERIC_CSUM on x86, enable it for KASAN/KMSAN glider 2019-12-03 14:17 ` Marco Elver 2019-12-05 14:37 ` Alexander Potapenko 2019-11-29 14:39 ` [PATCH RFC v3 00/36] Add KernelMemorySanitizer infrastructure Marco Elver 2019-12-02 16:02 ` Alexander Potapenko
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='CAG_fn=UR7bb1MS3gyceBhY588TuqYjTetd-M0pTgpOdqOL1q0Q@mail.gmail.com' \ --to=glider@google.com \ --cc=adilger.kernel@dilger.ca \ --cc=akpm@linux-foundation.org \ --cc=andreyknvl@google.com \ --cc=ard.biesheuvel@linaro.org \ --cc=arnd@arndb.de \ --cc=aryabinin@virtuozzo.com \ --cc=axboe@kernel.dk \ --cc=cai@lca.pw \ --cc=darrick.wong@oracle.com \ --cc=davem@davemloft.net \ --cc=dmitry.torokhov@gmail.com \ --cc=dvyukov@google.com \ --cc=ebiggers@google.com \ --cc=edumazet@google.com \ --cc=elver@google.com \ --cc=ericvh@gmail.com \ --cc=gor@linux.ibm.com \ --cc=gregkh@linuxfoundation.org \ --cc=harry.wentland@amd.com \ --cc=hch@infradead.org \ --cc=hch@lst.de \ --cc=herbert@gondor.apana.org.au \ --cc=iii@linux.ibm.com \ --cc=jasowang@redhat.com \ --cc=linux-mm@kvack.org \ --cc=luto@kernel.org \ --cc=m.szyprowski@samsung.com \ --cc=mark.rutland@arm.com \ --cc=martin.petersen@oracle.com \ --cc=mingo@elte.hu \ --cc=monstr@monstr.eu \ --cc=mst@redhat.com \ --cc=pmladek@suse.com \ --cc=rdunlap@infradead.org \ --cc=robin.murphy@arm.com \ --cc=rostedt@goodmis.org \ --cc=schwidefsky@de.ibm.com \ --cc=sergey.senozhatsky@gmail.com \ --cc=tglx@linutronix.de \ --cc=tiwai@suse.com \ --cc=tytso@mit.edu \ --cc=vegard.nossum@oracle.com \ --cc=viro@zeniv.linux.org.uk \ --cc=willy@infradead.org \ --cc=wsa@the-dreams.de \ /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
Linux-mm Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \ linux-mm@kvack.org public-inbox-index linux-mm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kvack.linux-mm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git