* [PATCH] zswap: initialize entry->pool on same filled entry
@ 2024-03-21 23:53 Chris Li
2024-03-21 23:56 ` Yosry Ahmed
0 siblings, 1 reply; 8+ messages in thread
From: Chris Li @ 2024-03-21 23:53 UTC (permalink / raw
To: Andrew Morton
Cc: linux-kernel, linux-mm, Yosry Ahmed, Nhat Pham, Johannes Weiner,
Chengming Zhou, Chris Li
Current zswap will leave the entry->pool uninitialized if
the page is same filled. The entry->pool pointer can
contain data written by previous usage.
Initialize entry->pool to zero for the same filled zswap entry.
Signed-off-by: Chris Li <chrisl@kernel.org>
---
Per Yosry's suggestion to split out this clean up
from the zxwap rb tree to xarray patch.
https://lore.kernel.org/all/ZemDuW25YxjqAjm-@google.com/
---
mm/zswap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/zswap.c b/mm/zswap.c
index b31c977f53e9..f04a75a36236 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -1527,6 +1527,7 @@ bool zswap_store(struct folio *folio)
kunmap_local(src);
entry->length = 0;
entry->value = value;
+ entry->pool = 0;
atomic_inc(&zswap_same_filled_pages);
goto insert_entry;
}
---
base-commit: a824831a082f1d8f9b51a4c0598e633d38555fcf
change-id: 20240315-zswap-fill-f65f44574760
Best regards,
--
Chris Li <chrisl@kernel.org>
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] zswap: initialize entry->pool on same filled entry
2024-03-21 23:53 [PATCH] zswap: initialize entry->pool on same filled entry Chris Li
@ 2024-03-21 23:56 ` Yosry Ahmed
2024-03-22 0:41 ` Chris Li
2024-03-22 3:19 ` Johannes Weiner
0 siblings, 2 replies; 8+ messages in thread
From: Yosry Ahmed @ 2024-03-21 23:56 UTC (permalink / raw
To: Chris Li
Cc: Andrew Morton, linux-kernel, linux-mm, Nhat Pham, Johannes Weiner,
Chengming Zhou
On Thu, Mar 21, 2024 at 4:53 PM Chris Li <chrisl@kernel.org> wrote:
>
> Current zswap will leave the entry->pool uninitialized if
> the page is same filled. The entry->pool pointer can
> contain data written by previous usage.
>
> Initialize entry->pool to zero for the same filled zswap entry.
>
> Signed-off-by: Chris Li <chrisl@kernel.org>
> ---
> Per Yosry's suggestion to split out this clean up
> from the zxwap rb tree to xarray patch.
>
> https://lore.kernel.org/all/ZemDuW25YxjqAjm-@google.com/
> ---
> mm/zswap.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/zswap.c b/mm/zswap.c
> index b31c977f53e9..f04a75a36236 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -1527,6 +1527,7 @@ bool zswap_store(struct folio *folio)
> kunmap_local(src);
> entry->length = 0;
> entry->value = value;
> + entry->pool = 0;
This should be NULL.
That being said, I am working on a series that should make non-filled
entries not use a zswap_entry at all. So I think this cleanup is
unnecessary, especially that it is documented in the definition of
struct zswap_entry that entry->pool is invalid for same-filled
entries.
> atomic_inc(&zswap_same_filled_pages);
> goto insert_entry;
> }
>
> ---
> base-commit: a824831a082f1d8f9b51a4c0598e633d38555fcf
> change-id: 20240315-zswap-fill-f65f44574760
>
> Best regards,
> --
> Chris Li <chrisl@kernel.org>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] zswap: initialize entry->pool on same filled entry
2024-03-21 23:56 ` Yosry Ahmed
@ 2024-03-22 0:41 ` Chris Li
2024-03-22 3:19 ` Johannes Weiner
1 sibling, 0 replies; 8+ messages in thread
From: Chris Li @ 2024-03-22 0:41 UTC (permalink / raw
To: Yosry Ahmed
Cc: Andrew Morton, linux-kernel, linux-mm, Nhat Pham, Johannes Weiner,
Chengming Zhou
On Thu, Mar 21, 2024 at 4:56 PM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> On Thu, Mar 21, 2024 at 4:53 PM Chris Li <chrisl@kernel.org> wrote:
> >
> > Current zswap will leave the entry->pool uninitialized if
> > the page is same filled. The entry->pool pointer can
> > contain data written by previous usage.
> >
> > Initialize entry->pool to zero for the same filled zswap entry.
> >
> > Signed-off-by: Chris Li <chrisl@kernel.org>
> > ---
> > Per Yosry's suggestion to split out this clean up
> > from the zxwap rb tree to xarray patch.
> >
> > https://lore.kernel.org/all/ZemDuW25YxjqAjm-@google.com/
> > ---
> > mm/zswap.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/mm/zswap.c b/mm/zswap.c
> > index b31c977f53e9..f04a75a36236 100644
> > --- a/mm/zswap.c
> > +++ b/mm/zswap.c
> > @@ -1527,6 +1527,7 @@ bool zswap_store(struct folio *folio)
> > kunmap_local(src);
> > entry->length = 0;
> > entry->value = value;
> > + entry->pool = 0;
>
> This should be NULL.
>
> That being said, I am working on a series that should make non-filled
> entries not use a zswap_entry at all. So I think this cleanup is
> unnecessary, especially that it is documented in the definition of
> struct zswap_entry that entry->pool is invalid for same-filled
> entries.
It does not really hurt to initialize it. It is obviously correct if
we initialize it as well. One thing to consider is that, this pointer
can contain user space data if the page previously was map to user
space. Kdump typically doesn't save user space data. This
uninitialized value might let kdump contain user space data.
Chris
>
> > atomic_inc(&zswap_same_filled_pages);
> > goto insert_entry;
> > }
> >
> > ---
> > base-commit: a824831a082f1d8f9b51a4c0598e633d38555fcf
> > change-id: 20240315-zswap-fill-f65f44574760
> >
> > Best regards,
> > --
> > Chris Li <chrisl@kernel.org>
> >
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] zswap: initialize entry->pool on same filled entry
2024-03-21 23:56 ` Yosry Ahmed
2024-03-22 0:41 ` Chris Li
@ 2024-03-22 3:19 ` Johannes Weiner
2024-03-22 13:35 ` Chris Li
1 sibling, 1 reply; 8+ messages in thread
From: Johannes Weiner @ 2024-03-22 3:19 UTC (permalink / raw
To: Yosry Ahmed
Cc: Chris Li, Andrew Morton, linux-kernel, linux-mm, Nhat Pham,
Chengming Zhou
On Thu, Mar 21, 2024 at 04:56:05PM -0700, Yosry Ahmed wrote:
> On Thu, Mar 21, 2024 at 4:53 PM Chris Li <chrisl@kernel.org> wrote:
> >
> > Current zswap will leave the entry->pool uninitialized if
> > the page is same filled. The entry->pool pointer can
> > contain data written by previous usage.
> >
> > Initialize entry->pool to zero for the same filled zswap entry.
> >
> > Signed-off-by: Chris Li <chrisl@kernel.org>
> > ---
> > Per Yosry's suggestion to split out this clean up
> > from the zxwap rb tree to xarray patch.
> >
> > https://lore.kernel.org/all/ZemDuW25YxjqAjm-@google.com/
> > ---
> > mm/zswap.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/mm/zswap.c b/mm/zswap.c
> > index b31c977f53e9..f04a75a36236 100644
> > --- a/mm/zswap.c
> > +++ b/mm/zswap.c
> > @@ -1527,6 +1527,7 @@ bool zswap_store(struct folio *folio)
> > kunmap_local(src);
> > entry->length = 0;
> > entry->value = value;
> > + entry->pool = 0;
>
> This should be NULL.
>
> That being said, I am working on a series that should make non-filled
> entries not use a zswap_entry at all. So I think this cleanup is
> unnecessary, especially that it is documented in the definition of
> struct zswap_entry that entry->pool is invalid for same-filled
> entries.
Yeah I don't think it's necessary to initialize. The field isn't valid
when it's a same-filled entry, just like `handle` would contain
nonsense as it's unionized with value.
What would actually be safer is to make the two subtypes explicit, and
not have unused/ambiguous/overloaded members at all:
struct zswap_entry {
unsigned int length;
struct obj_cgroup *objcg;
};
struct zswap_compressed_entry {
struct zswap_entry entry;
struct zswap_pool *pool;
unsigned long handle;
struct list_head lru;
swp_entry_t swpentry;
};
struct zswap_samefilled_entry {
struct zswap_entry entry;
unsigned long value;
};
Then put zswap_entry pointers in the tree and use the appropriate
container_of() calls in just a handful of central places. This would
limit the the points where mistakes can be made, and suggests how the
code paths to handle them should split naturally.
Might be useful even with your series, since it disambiguates things
first, and separates the cleanup bits from any functional changes,
instead of having to do kind of everything at once...
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] zswap: initialize entry->pool on same filled entry
2024-03-22 3:19 ` Johannes Weiner
@ 2024-03-22 13:35 ` Chris Li
2024-03-22 17:11 ` Johannes Weiner
0 siblings, 1 reply; 8+ messages in thread
From: Chris Li @ 2024-03-22 13:35 UTC (permalink / raw
To: Johannes Weiner
Cc: Yosry Ahmed, Andrew Morton, linux-kernel, linux-mm, Nhat Pham,
Chengming Zhou
On Thu, Mar 21, 2024 at 8:19 PM Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> On Thu, Mar 21, 2024 at 04:56:05PM -0700, Yosry Ahmed wrote:
> > On Thu, Mar 21, 2024 at 4:53 PM Chris Li <chrisl@kernel.org> wrote:
> > >
> > > Current zswap will leave the entry->pool uninitialized if
> > > the page is same filled. The entry->pool pointer can
> > > contain data written by previous usage.
> > >
> > > Initialize entry->pool to zero for the same filled zswap entry.
> > >
> > > Signed-off-by: Chris Li <chrisl@kernel.org>
> > > ---
> > > Per Yosry's suggestion to split out this clean up
> > > from the zxwap rb tree to xarray patch.
> > >
> > > https://lore.kernel.org/all/ZemDuW25YxjqAjm-@google.com/
> > > ---
> > > mm/zswap.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/mm/zswap.c b/mm/zswap.c
> > > index b31c977f53e9..f04a75a36236 100644
> > > --- a/mm/zswap.c
> > > +++ b/mm/zswap.c
> > > @@ -1527,6 +1527,7 @@ bool zswap_store(struct folio *folio)
> > > kunmap_local(src);
> > > entry->length = 0;
> > > entry->value = value;
> > > + entry->pool = 0;
> >
> > This should be NULL.
> >
> > That being said, I am working on a series that should make non-filled
> > entries not use a zswap_entry at all. So I think this cleanup is
> > unnecessary, especially that it is documented in the definition of
> > struct zswap_entry that entry->pool is invalid for same-filled
> > entries.
>
> Yeah I don't think it's necessary to initialize. The field isn't valid
> when it's a same-filled entry, just like `handle` would contain
> nonsense as it's unionized with value.
>
> What would actually be safer is to make the two subtypes explicit, and
> not have unused/ambiguous/overloaded members at all:
>
> struct zswap_entry {
> unsigned int length;
> struct obj_cgroup *objcg;
> };
>
> struct zswap_compressed_entry {
> struct zswap_entry entry;
> struct zswap_pool *pool;
> unsigned long handle;
> struct list_head lru;
> swp_entry_t swpentry;
> };
>
> struct zswap_samefilled_entry {
> struct zswap_entry entry;
> unsigned long value;
> };
I think the 3 struct with embedded and container of is a bit complex,
because the state breaks into different struct members
How about:
struct zswap_entry {
unsigned int length;
struct obj_cgroup *objcg;
union {
struct /* compressed */ {
struct zswap_pool *pool;
unsigned long handle;
swp_entry_t swpentry;
struct list_head lru;
};
struct /* same filled */ {
unsigned long value;
};
};
};
That should have the same effect of the above three structures. Easier
to visualize the containing structure.
What do you say?
Chris
>
> Then put zswap_entry pointers in the tree and use the appropriate
> container_of() calls in just a handful of central places. This would
> limit the the points where mistakes can be made, and suggests how the
> code paths to handle them should split naturally.
>
> Might be useful even with your series, since it disambiguates things
> first, and separates the cleanup bits from any functional changes,
> instead of having to do kind of everything at once...
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] zswap: initialize entry->pool on same filled entry
2024-03-22 13:35 ` Chris Li
@ 2024-03-22 17:11 ` Johannes Weiner
2024-03-22 17:57 ` Chris Li
2024-03-22 18:58 ` Yosry Ahmed
0 siblings, 2 replies; 8+ messages in thread
From: Johannes Weiner @ 2024-03-22 17:11 UTC (permalink / raw
To: Chris Li
Cc: Yosry Ahmed, Andrew Morton, linux-kernel, linux-mm, Nhat Pham,
Chengming Zhou
On Fri, Mar 22, 2024 at 06:35:43AM -0700, Chris Li wrote:
> On Thu, Mar 21, 2024 at 8:19 PM Johannes Weiner <hannes@cmpxchg.org> wrote:
> >
> > On Thu, Mar 21, 2024 at 04:56:05PM -0700, Yosry Ahmed wrote:
> > > On Thu, Mar 21, 2024 at 4:53 PM Chris Li <chrisl@kernel.org> wrote:
> > > >
> > > > Current zswap will leave the entry->pool uninitialized if
> > > > the page is same filled. The entry->pool pointer can
> > > > contain data written by previous usage.
> > > >
> > > > Initialize entry->pool to zero for the same filled zswap entry.
> > > >
> > > > Signed-off-by: Chris Li <chrisl@kernel.org>
> > > > ---
> > > > Per Yosry's suggestion to split out this clean up
> > > > from the zxwap rb tree to xarray patch.
> > > >
> > > > https://lore.kernel.org/all/ZemDuW25YxjqAjm-@google.com/
> > > > ---
> > > > mm/zswap.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/mm/zswap.c b/mm/zswap.c
> > > > index b31c977f53e9..f04a75a36236 100644
> > > > --- a/mm/zswap.c
> > > > +++ b/mm/zswap.c
> > > > @@ -1527,6 +1527,7 @@ bool zswap_store(struct folio *folio)
> > > > kunmap_local(src);
> > > > entry->length = 0;
> > > > entry->value = value;
> > > > + entry->pool = 0;
> > >
> > > This should be NULL.
> > >
> > > That being said, I am working on a series that should make non-filled
> > > entries not use a zswap_entry at all. So I think this cleanup is
> > > unnecessary, especially that it is documented in the definition of
> > > struct zswap_entry that entry->pool is invalid for same-filled
> > > entries.
> >
> > Yeah I don't think it's necessary to initialize. The field isn't valid
> > when it's a same-filled entry, just like `handle` would contain
> > nonsense as it's unionized with value.
> >
> > What would actually be safer is to make the two subtypes explicit, and
> > not have unused/ambiguous/overloaded members at all:
> >
> > struct zswap_entry {
> > unsigned int length;
> > struct obj_cgroup *objcg;
> > };
> >
> > struct zswap_compressed_entry {
> > struct zswap_entry entry;
> > struct zswap_pool *pool;
> > unsigned long handle;
> > struct list_head lru;
> > swp_entry_t swpentry;
> > };
> >
> > struct zswap_samefilled_entry {
> > struct zswap_entry entry;
> > unsigned long value;
> > };
>
> I think the 3 struct with embedded and container of is a bit complex,
> because the state breaks into different struct members
That's kind of the point. They're different types that have their own
rules and code paths. The code as it is right now makes it seem like
they're almost the same. From the above you can see that they have
actually almost nothing in common (the bits in struct zswap_entry).
This would force the code to show the difference as well.
Depending on how Yosry's patches work out, this may or may not be
worth doing. It's just an idea that could help make it easier.
> How about:
>
> struct zswap_entry {
> unsigned int length;
> struct obj_cgroup *objcg;
> union {
> struct /* compressed */ {
> struct zswap_pool *pool;
> unsigned long handle;
> swp_entry_t swpentry;
> struct list_head lru;
> };
> struct /* same filled */ {
> unsigned long value;
> };
> };
> };
>
> That should have the same effect of the above three structures. Easier
> to visualize the containing structure.
I suppose it makes the struct a bit clearer when you directly look at
it, but I don't see how it would help with code clarity.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] zswap: initialize entry->pool on same filled entry
2024-03-22 17:11 ` Johannes Weiner
@ 2024-03-22 17:57 ` Chris Li
2024-03-22 18:58 ` Yosry Ahmed
1 sibling, 0 replies; 8+ messages in thread
From: Chris Li @ 2024-03-22 17:57 UTC (permalink / raw
To: Johannes Weiner
Cc: Yosry Ahmed, Andrew Morton, linux-kernel, linux-mm, Nhat Pham,
Chengming Zhou
On Fri, Mar 22, 2024 at 10:12 AM Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> On Fri, Mar 22, 2024 at 06:35:43AM -0700, Chris Li wrote:
> > On Thu, Mar 21, 2024 at 8:19 PM Johannes Weiner <hannes@cmpxchg.org> wrote:
> > >
> > > On Thu, Mar 21, 2024 at 04:56:05PM -0700, Yosry Ahmed wrote:
> > > > On Thu, Mar 21, 2024 at 4:53 PM Chris Li <chrisl@kernel.org> wrote:
> > > > >
> > > > > Current zswap will leave the entry->pool uninitialized if
> > > > > the page is same filled. The entry->pool pointer can
> > > > > contain data written by previous usage.
> > > > >
> > > > > Initialize entry->pool to zero for the same filled zswap entry.
> > > > >
> > > > > Signed-off-by: Chris Li <chrisl@kernel.org>
> > > > > ---
> > > > > Per Yosry's suggestion to split out this clean up
> > > > > from the zxwap rb tree to xarray patch.
> > > > >
> > > > > https://lore.kernel.org/all/ZemDuW25YxjqAjm-@google.com/
> > > > > ---
> > > > > mm/zswap.c | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/mm/zswap.c b/mm/zswap.c
> > > > > index b31c977f53e9..f04a75a36236 100644
> > > > > --- a/mm/zswap.c
> > > > > +++ b/mm/zswap.c
> > > > > @@ -1527,6 +1527,7 @@ bool zswap_store(struct folio *folio)
> > > > > kunmap_local(src);
> > > > > entry->length = 0;
> > > > > entry->value = value;
> > > > > + entry->pool = 0;
> > > >
> > > > This should be NULL.
> > > >
> > > > That being said, I am working on a series that should make non-filled
> > > > entries not use a zswap_entry at all. So I think this cleanup is
> > > > unnecessary, especially that it is documented in the definition of
> > > > struct zswap_entry that entry->pool is invalid for same-filled
> > > > entries.
> > >
> > > Yeah I don't think it's necessary to initialize. The field isn't valid
> > > when it's a same-filled entry, just like `handle` would contain
> > > nonsense as it's unionized with value.
> > >
> > > What would actually be safer is to make the two subtypes explicit, and
> > > not have unused/ambiguous/overloaded members at all:
> > >
> > > struct zswap_entry {
> > > unsigned int length;
> > > struct obj_cgroup *objcg;
> > > };
> > >
> > > struct zswap_compressed_entry {
> > > struct zswap_entry entry;
> > > struct zswap_pool *pool;
> > > unsigned long handle;
> > > struct list_head lru;
> > > swp_entry_t swpentry;
> > > };
> > >
> > > struct zswap_samefilled_entry {
> > > struct zswap_entry entry;
> > > unsigned long value;
> > > };
> >
> > I think the 3 struct with embedded and container of is a bit complex,
> > because the state breaks into different struct members
>
> That's kind of the point. They're different types that have their own
> rules and code paths. The code as it is right now makes it seem like
> they're almost the same. From the above you can see that they have
> actually almost nothing in common (the bits in struct zswap_entry).
Not sure about how you envision the different code paths look like.
> This would force the code to show the difference as well.
>
> Depending on how Yosry's patches work out, this may or may not be
> worth doing. It's just an idea that could help make it easier.
Agree, would need to see the actual code to reason about the minor difference.
>
> > How about:
> >
> > struct zswap_entry {
> > unsigned int length;
> > struct obj_cgroup *objcg;
> > union {
> > struct /* compressed */ {
> > struct zswap_pool *pool;
> > unsigned long handle;
> > swp_entry_t swpentry;
> > struct list_head lru;
> > };
> > struct /* same filled */ {
> > unsigned long value;
> > };
> > };
> > };
> >
> > That should have the same effect of the above three structures. Easier
> > to visualize the containing structure.
>
> I suppose it makes the struct a bit clearer when you directly look at
> it, but I don't see how it would help with code clarity.
Just curious, would changing the anonymous struct to the named struct
helps to address code clarity you have in mind?
It would go through entry->compressed.pool for example.
Chris
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] zswap: initialize entry->pool on same filled entry
2024-03-22 17:11 ` Johannes Weiner
2024-03-22 17:57 ` Chris Li
@ 2024-03-22 18:58 ` Yosry Ahmed
1 sibling, 0 replies; 8+ messages in thread
From: Yosry Ahmed @ 2024-03-22 18:58 UTC (permalink / raw
To: Johannes Weiner
Cc: Chris Li, Andrew Morton, linux-kernel, linux-mm, Nhat Pham,
Chengming Zhou
[..]
> > > What would actually be safer is to make the two subtypes explicit, and
> > > not have unused/ambiguous/overloaded members at all:
> > >
> > > struct zswap_entry {
> > > unsigned int length;
> > > struct obj_cgroup *objcg;
> > > };
> > >
> > > struct zswap_compressed_entry {
> > > struct zswap_entry entry;
> > > struct zswap_pool *pool;
> > > unsigned long handle;
> > > struct list_head lru;
> > > swp_entry_t swpentry;
> > > };
> > >
> > > struct zswap_samefilled_entry {
> > > struct zswap_entry entry;
> > > unsigned long value;
> > > };
> >
> > I think the 3 struct with embedded and container of is a bit complex,
> > because the state breaks into different struct members
>
> That's kind of the point. They're different types that have their own
> rules and code paths. The code as it is right now makes it seem like
> they're almost the same. From the above you can see that they have
> actually almost nothing in common (the bits in struct zswap_entry).
>
> This would force the code to show the difference as well.
>
> Depending on how Yosry's patches work out, this may or may not be
> worth doing. It's just an idea that could help make it easier.
I initially wanted to do something similar to splitting the structs
before not allocating an entry at all for same-filled pages, but I
ended up dropping it as the direct conversion was simple enough.
Anyway, I will post the patches some time next week (or today if I can
get around to test them). The discussion should be easier with code.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-03-22 18:58 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-21 23:53 [PATCH] zswap: initialize entry->pool on same filled entry Chris Li
2024-03-21 23:56 ` Yosry Ahmed
2024-03-22 0:41 ` Chris Li
2024-03-22 3:19 ` Johannes Weiner
2024-03-22 13:35 ` Chris Li
2024-03-22 17:11 ` Johannes Weiner
2024-03-22 17:57 ` Chris Li
2024-03-22 18:58 ` Yosry Ahmed
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).