* [PATCH v1 1/1] crypto/pcrypt: Do not use isolated CPUs for callback @ 2022-10-04 6:25 Leonardo Bras 2022-10-05 12:57 ` Marcelo Tosatti 0 siblings, 1 reply; 6+ messages in thread From: Leonardo Bras @ 2022-10-04 6:25 UTC (permalink / raw) To: Steffen Klassert, Herbert Xu, David S. Miller, mtosatti Cc: Leonardo Bras, linux-crypto, linux-kernel Currently pcrypt_aead_init_tfm() will pick callback cpus (ctx->cb_cpu) from any online cpus. Later padata_reorder() will queue_work_on() the chosen cb_cpu. This is undesired if the chosen cb_cpu is listed as isolated (i.e. using isolcpus=... kernel parameter), since the work queued will interfere with the workload on the isolated cpu. Make sure isolated cpus are not used for pcrypt. Signed-off-by: Leonardo Bras <leobras@redhat.com> --- crypto/pcrypt.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c index 9d10b846ccf73..9017d08c91a8d 100644 --- a/crypto/pcrypt.c +++ b/crypto/pcrypt.c @@ -16,6 +16,7 @@ #include <linux/kobject.h> #include <linux/cpu.h> #include <crypto/pcrypt.h> +#include <linux/sched/isolation.h> static struct padata_instance *pencrypt; static struct padata_instance *pdecrypt; @@ -175,13 +176,16 @@ static int pcrypt_aead_init_tfm(struct crypto_aead *tfm) struct pcrypt_instance_ctx *ictx = aead_instance_ctx(inst); struct pcrypt_aead_ctx *ctx = crypto_aead_ctx(tfm); struct crypto_aead *cipher; + struct cpumask non_isolated; + + cpumask_and(&non_isolated, cpu_online_mask, housekeeping_cpumask(HK_TYPE_DOMAIN)); cpu_index = (unsigned int)atomic_inc_return(&ictx->tfm_count) % - cpumask_weight(cpu_online_mask); + cpumask_weight(&non_isolated); - ctx->cb_cpu = cpumask_first(cpu_online_mask); + ctx->cb_cpu = cpumask_first(&non_isolated); for (cpu = 0; cpu < cpu_index; cpu++) - ctx->cb_cpu = cpumask_next(ctx->cb_cpu, cpu_online_mask); + ctx->cb_cpu = cpumask_next(ctx->cb_cpu, &non_isolated); cipher = crypto_spawn_aead(&ictx->spawn); -- 2.37.3 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v1 1/1] crypto/pcrypt: Do not use isolated CPUs for callback 2022-10-04 6:25 [PATCH v1 1/1] crypto/pcrypt: Do not use isolated CPUs for callback Leonardo Bras @ 2022-10-05 12:57 ` Marcelo Tosatti 2022-10-07 21:42 ` Leonardo Brás 0 siblings, 1 reply; 6+ messages in thread From: Marcelo Tosatti @ 2022-10-05 12:57 UTC (permalink / raw) To: Leonardo Bras Cc: Steffen Klassert, Herbert Xu, David S. Miller, linux-crypto, linux-kernel On Tue, Oct 04, 2022 at 03:25:37AM -0300, Leonardo Bras wrote: > Currently pcrypt_aead_init_tfm() will pick callback cpus (ctx->cb_cpu) > from any online cpus. Later padata_reorder() will queue_work_on() the > chosen cb_cpu. > > This is undesired if the chosen cb_cpu is listed as isolated (i.e. using > isolcpus=... kernel parameter), since the work queued will interfere with > the workload on the isolated cpu. > > Make sure isolated cpus are not used for pcrypt. > > Signed-off-by: Leonardo Bras <leobras@redhat.com> > --- > crypto/pcrypt.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c > index 9d10b846ccf73..9017d08c91a8d 100644 > --- a/crypto/pcrypt.c > +++ b/crypto/pcrypt.c > @@ -16,6 +16,7 @@ > #include <linux/kobject.h> > #include <linux/cpu.h> > #include <crypto/pcrypt.h> > +#include <linux/sched/isolation.h> > > static struct padata_instance *pencrypt; > static struct padata_instance *pdecrypt; > @@ -175,13 +176,16 @@ static int pcrypt_aead_init_tfm(struct crypto_aead *tfm) > struct pcrypt_instance_ctx *ictx = aead_instance_ctx(inst); > struct pcrypt_aead_ctx *ctx = crypto_aead_ctx(tfm); > struct crypto_aead *cipher; > + struct cpumask non_isolated; > + > + cpumask_and(&non_isolated, cpu_online_mask, housekeeping_cpumask(HK_TYPE_DOMAIN)); Since certain systems do not use isolcpus=domain, so please use a flag that is setup by nohz_full=, for example HK_FLAG_MISC: static int __init housekeeping_nohz_full_setup(char *str) { unsigned long flags; flags = HK_FLAG_TICK | HK_FLAG_WQ | HK_FLAG_TIMER | HK_FLAG_RCU | HK_FLAG_MISC | HK_FLAG_KTHREAD; return housekeeping_setup(str, flags); } __setup("nohz_full=", housekeeping_nohz_full_setup); Also, shouldnt you use cpumask_t ? Looks good otherwise. Thanks! > > cpu_index = (unsigned int)atomic_inc_return(&ictx->tfm_count) % > - cpumask_weight(cpu_online_mask); > + cpumask_weight(&non_isolated); > > - ctx->cb_cpu = cpumask_first(cpu_online_mask); > + ctx->cb_cpu = cpumask_first(&non_isolated); > for (cpu = 0; cpu < cpu_index; cpu++) > - ctx->cb_cpu = cpumask_next(ctx->cb_cpu, cpu_online_mask); > + ctx->cb_cpu = cpumask_next(ctx->cb_cpu, &non_isolated); > > cipher = crypto_spawn_aead(&ictx->spawn); > > -- > 2.37.3 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1 1/1] crypto/pcrypt: Do not use isolated CPUs for callback 2022-10-05 12:57 ` Marcelo Tosatti @ 2022-10-07 21:42 ` Leonardo Brás 2022-10-11 18:20 ` Leonardo Brás 0 siblings, 1 reply; 6+ messages in thread From: Leonardo Brás @ 2022-10-07 21:42 UTC (permalink / raw) To: Marcelo Tosatti Cc: Steffen Klassert, Herbert Xu, David S. Miller, linux-crypto, linux-kernel On Wed, 2022-10-05 at 09:57 -0300, Marcelo Tosatti wrote: > On Tue, Oct 04, 2022 at 03:25:37AM -0300, Leonardo Bras wrote: > > Currently pcrypt_aead_init_tfm() will pick callback cpus (ctx->cb_cpu) > > from any online cpus. Later padata_reorder() will queue_work_on() the > > chosen cb_cpu. > > > > This is undesired if the chosen cb_cpu is listed as isolated (i.e. using > > isolcpus=... kernel parameter), since the work queued will interfere with > > the workload on the isolated cpu. > > > > Make sure isolated cpus are not used for pcrypt. > > > > Signed-off-by: Leonardo Bras <leobras@redhat.com> > > --- > > crypto/pcrypt.c | 10 +++++++--- > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c > > index 9d10b846ccf73..9017d08c91a8d 100644 > > --- a/crypto/pcrypt.c > > +++ b/crypto/pcrypt.c > > @@ -16,6 +16,7 @@ > > #include <linux/kobject.h> > > #include <linux/cpu.h> > > #include <crypto/pcrypt.h> > > +#include <linux/sched/isolation.h> > > > > static struct padata_instance *pencrypt; > > static struct padata_instance *pdecrypt; > > @@ -175,13 +176,16 @@ static int pcrypt_aead_init_tfm(struct crypto_aead *tfm) > > struct pcrypt_instance_ctx *ictx = aead_instance_ctx(inst); > > struct pcrypt_aead_ctx *ctx = crypto_aead_ctx(tfm); > > struct crypto_aead *cipher; > > + struct cpumask non_isolated; > > + > > + cpumask_and(&non_isolated, cpu_online_mask, housekeeping_cpumask(HK_TYPE_DOMAIN)); > > Since certain systems do not use isolcpus=domain, so please use a flag > that is setup by nohz_full=, for example HK_FLAG_MISC: > > static int __init housekeeping_nohz_full_setup(char *str) > { > unsigned long flags; > > flags = HK_FLAG_TICK | HK_FLAG_WQ | HK_FLAG_TIMER | HK_FLAG_RCU | > HK_FLAG_MISC | HK_FLAG_KTHREAD; > > return housekeeping_setup(str, flags); > } > __setup("nohz_full=", housekeeping_nohz_full_setup); Oh, sure. Since we are talking about WorkQueues, I think it makes sense to pick HK_FLAG_WQ. > > Also, shouldnt you use cpumask_t ?/ Yeah, I think so. I was quick to choose the 'struct cpumask' because all functions would operate in this variable type, but yeah, I think it makes sense to have this variable being opaque here. > > Looks good otherwise. > > Thanks! Thank you for reviewing! Leo > > > > > > cpu_index = (unsigned int)atomic_inc_return(&ictx->tfm_count) % > > - cpumask_weight(cpu_online_mask); > > + cpumask_weight(&non_isolated); > > > > - ctx->cb_cpu = cpumask_first(cpu_online_mask); > > + ctx->cb_cpu = cpumask_first(&non_isolated); > > for (cpu = 0; cpu < cpu_index; cpu++) > > - ctx->cb_cpu = cpumask_next(ctx->cb_cpu, cpu_online_mask); > > + ctx->cb_cpu = cpumask_next(ctx->cb_cpu, &non_isolated); > > > > cipher = crypto_spawn_aead(&ictx->spawn); > > > > -- > > 2.37.3 > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1 1/1] crypto/pcrypt: Do not use isolated CPUs for callback 2022-10-07 21:42 ` Leonardo Brás @ 2022-10-11 18:20 ` Leonardo Brás 2022-11-01 17:35 ` Marcelo Tosatti 0 siblings, 1 reply; 6+ messages in thread From: Leonardo Brás @ 2022-10-11 18:20 UTC (permalink / raw) To: Marcelo Tosatti Cc: Steffen Klassert, Herbert Xu, David S. Miller, linux-crypto, linux-kernel On Fri, 2022-10-07 at 18:42 -0300, Leonardo Brás wrote: > On Wed, 2022-10-05 at 09:57 -0300, Marcelo Tosatti wrote: > > On Tue, Oct 04, 2022 at 03:25:37AM -0300, Leonardo Bras wrote: > > > Currently pcrypt_aead_init_tfm() will pick callback cpus (ctx->cb_cpu) > > > from any online cpus. Later padata_reorder() will queue_work_on() the > > > chosen cb_cpu. > > > > > > This is undesired if the chosen cb_cpu is listed as isolated (i.e. using > > > isolcpus=... kernel parameter), since the work queued will interfere with > > > the workload on the isolated cpu. > > > > > > Make sure isolated cpus are not used for pcrypt. > > > > > > Signed-off-by: Leonardo Bras <leobras@redhat.com> > > > --- > > > crypto/pcrypt.c | 10 +++++++--- > > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > > > diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c > > > index 9d10b846ccf73..9017d08c91a8d 100644 > > > --- a/crypto/pcrypt.c > > > +++ b/crypto/pcrypt.c > > > @@ -16,6 +16,7 @@ > > > #include <linux/kobject.h> > > > #include <linux/cpu.h> > > > #include <crypto/pcrypt.h> > > > +#include <linux/sched/isolation.h> > > > > > > static struct padata_instance *pencrypt; > > > static struct padata_instance *pdecrypt; > > > @@ -175,13 +176,16 @@ static int pcrypt_aead_init_tfm(struct crypto_aead *tfm) > > > struct pcrypt_instance_ctx *ictx = aead_instance_ctx(inst); > > > struct pcrypt_aead_ctx *ctx = crypto_aead_ctx(tfm); > > > struct crypto_aead *cipher; > > > + struct cpumask non_isolated; > > > + > > > + cpumask_and(&non_isolated, cpu_online_mask, housekeeping_cpumask(HK_TYPE_DOMAIN)); > > > > Since certain systems do not use isolcpus=domain, so please use a flag > > that is setup by nohz_full=, for example HK_FLAG_MISC: > > > > static int __init housekeeping_nohz_full_setup(char *str) > > { > > unsigned long flags; > > > > flags = HK_FLAG_TICK | HK_FLAG_WQ | HK_FLAG_TIMER | HK_FLAG_RCU | > > HK_FLAG_MISC | HK_FLAG_KTHREAD; > > > > return housekeeping_setup(str, flags); > > } > > __setup("nohz_full=", housekeeping_nohz_full_setup); > > Oh, sure. > Since we are talking about WorkQueues, I think it makes sense to pick > HK_FLAG_WQ. > > > > > Also, shouldnt you use cpumask_t ?/ > > Yeah, I think so. > I was quick to choose the 'struct cpumask' because all functions would operate > in this variable type, but yeah, I think it makes sense to have this variable > being opaque here. In fact, it seems neither 'struct cpumask' nor 'cpumask_t' are recommended to be used allocated in the stack, due to the large size it can get (up to 1kB). At include/linux/cpumask.h we have: 'cpumask_var_t: struct cpumask for stack usage' which should work better at least for init functions like this. In other cases, I see 'static cpumask_t' being used to avoid the allocation overhead, but it's probably due to the functions being called in very specific scenarios. It could mean trouble if multiple cpus try to use it at once. What do you recommend on it? Best regards, Leo > > > > > Looks good otherwise. > > > > Thanks! > > Thank you for reviewing! > > Leo > > > > > > > > > > > cpu_index = (unsigned int)atomic_inc_return(&ictx->tfm_count) % > > > - cpumask_weight(cpu_online_mask); > > > + cpumask_weight(&non_isolated); > > > > > > - ctx->cb_cpu = cpumask_first(cpu_online_mask); > > > + ctx->cb_cpu = cpumask_first(&non_isolated); > > > for (cpu = 0; cpu < cpu_index; cpu++) > > > - ctx->cb_cpu = cpumask_next(ctx->cb_cpu, cpu_online_mask); > > > + ctx->cb_cpu = cpumask_next(ctx->cb_cpu, &non_isolated); > > > > > > cipher = crypto_spawn_aead(&ictx->spawn); > > > > > > -- > > > 2.37.3 > > > > > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1 1/1] crypto/pcrypt: Do not use isolated CPUs for callback 2022-10-11 18:20 ` Leonardo Brás @ 2022-11-01 17:35 ` Marcelo Tosatti 2022-11-02 2:09 ` Leonardo Bras Soares Passos 0 siblings, 1 reply; 6+ messages in thread From: Marcelo Tosatti @ 2022-11-01 17:35 UTC (permalink / raw) To: Leonardo Brás Cc: Steffen Klassert, Herbert Xu, David S. Miller, linux-crypto, linux-kernel On Tue, Oct 11, 2022 at 03:20:39PM -0300, Leonardo Brás wrote: > On Fri, 2022-10-07 at 18:42 -0300, Leonardo Brás wrote: > > On Wed, 2022-10-05 at 09:57 -0300, Marcelo Tosatti wrote: > > > On Tue, Oct 04, 2022 at 03:25:37AM -0300, Leonardo Bras wrote: > > > > Currently pcrypt_aead_init_tfm() will pick callback cpus (ctx->cb_cpu) > > > > from any online cpus. Later padata_reorder() will queue_work_on() the > > > > chosen cb_cpu. > > > > > > > > This is undesired if the chosen cb_cpu is listed as isolated (i.e. using > > > > isolcpus=... kernel parameter), since the work queued will interfere with > > > > the workload on the isolated cpu. > > > > > > > > Make sure isolated cpus are not used for pcrypt. > > > > > > > > Signed-off-by: Leonardo Bras <leobras@redhat.com> > > > > --- > > > > crypto/pcrypt.c | 10 +++++++--- > > > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c > > > > index 9d10b846ccf73..9017d08c91a8d 100644 > > > > --- a/crypto/pcrypt.c > > > > +++ b/crypto/pcrypt.c > > > > @@ -16,6 +16,7 @@ > > > > #include <linux/kobject.h> > > > > #include <linux/cpu.h> > > > > #include <crypto/pcrypt.h> > > > > +#include <linux/sched/isolation.h> > > > > > > > > static struct padata_instance *pencrypt; > > > > static struct padata_instance *pdecrypt; > > > > @@ -175,13 +176,16 @@ static int pcrypt_aead_init_tfm(struct crypto_aead *tfm) > > > > struct pcrypt_instance_ctx *ictx = aead_instance_ctx(inst); > > > > struct pcrypt_aead_ctx *ctx = crypto_aead_ctx(tfm); > > > > struct crypto_aead *cipher; > > > > + struct cpumask non_isolated; > > > > + > > > > + cpumask_and(&non_isolated, cpu_online_mask, housekeeping_cpumask(HK_TYPE_DOMAIN)); > > > > > > Since certain systems do not use isolcpus=domain, so please use a flag > > > that is setup by nohz_full=, for example HK_FLAG_MISC: > > > > > > static int __init housekeeping_nohz_full_setup(char *str) > > > { > > > unsigned long flags; > > > > > > flags = HK_FLAG_TICK | HK_FLAG_WQ | HK_FLAG_TIMER | HK_FLAG_RCU | > > > HK_FLAG_MISC | HK_FLAG_KTHREAD; > > > > > > return housekeeping_setup(str, flags); > > > } > > > __setup("nohz_full=", housekeeping_nohz_full_setup); > > > > Oh, sure. > > Since we are talking about WorkQueues, I think it makes sense to pick > > HK_FLAG_WQ. > > > > > > > > Also, shouldnt you use cpumask_t ?/ > > > > Yeah, I think so. > > I was quick to choose the 'struct cpumask' because all functions would operate > > in this variable type, but yeah, I think it makes sense to have this variable > > being opaque here. > > In fact, it seems neither 'struct cpumask' nor 'cpumask_t' are recommended to be > used allocated in the stack, due to the large size it can get (up to 1kB). > > At include/linux/cpumask.h we have: > 'cpumask_var_t: struct cpumask for stack usage' > which should work better at least for init functions like this. > > In other cases, I see 'static cpumask_t' being used to avoid the allocation > overhead, but it's probably due to the functions being called in very specific > scenarios. It could mean trouble if multiple cpus try to use it at once. > > What do you recommend on it? Sorry for the delay. I suppose allocating and freeing is OK in this context, since its initialization time and not a hot path? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1 1/1] crypto/pcrypt: Do not use isolated CPUs for callback 2022-11-01 17:35 ` Marcelo Tosatti @ 2022-11-02 2:09 ` Leonardo Bras Soares Passos 0 siblings, 0 replies; 6+ messages in thread From: Leonardo Bras Soares Passos @ 2022-11-02 2:09 UTC (permalink / raw) To: Marcelo Tosatti Cc: Steffen Klassert, Herbert Xu, David S. Miller, linux-crypto, linux-kernel On Tue, Nov 1, 2022 at 2:42 PM Marcelo Tosatti <mtosatti@redhat.com> wrote: > > On Tue, Oct 11, 2022 at 03:20:39PM -0300, Leonardo Brás wrote: > > On Fri, 2022-10-07 at 18:42 -0300, Leonardo Brás wrote: > > > On Wed, 2022-10-05 at 09:57 -0300, Marcelo Tosatti wrote: > > > > On Tue, Oct 04, 2022 at 03:25:37AM -0300, Leonardo Bras wrote: > > > > > Currently pcrypt_aead_init_tfm() will pick callback cpus (ctx->cb_cpu) > > > > > from any online cpus. Later padata_reorder() will queue_work_on() the > > > > > chosen cb_cpu. > > > > > > > > > > This is undesired if the chosen cb_cpu is listed as isolated (i.e. using > > > > > isolcpus=... kernel parameter), since the work queued will interfere with > > > > > the workload on the isolated cpu. > > > > > > > > > > Make sure isolated cpus are not used for pcrypt. > > > > > > > > > > Signed-off-by: Leonardo Bras <leobras@redhat.com> > > > > > --- > > > > > crypto/pcrypt.c | 10 +++++++--- > > > > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > > > > > > > diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c > > > > > index 9d10b846ccf73..9017d08c91a8d 100644 > > > > > --- a/crypto/pcrypt.c > > > > > +++ b/crypto/pcrypt.c > > > > > @@ -16,6 +16,7 @@ > > > > > #include <linux/kobject.h> > > > > > #include <linux/cpu.h> > > > > > #include <crypto/pcrypt.h> > > > > > +#include <linux/sched/isolation.h> > > > > > > > > > > static struct padata_instance *pencrypt; > > > > > static struct padata_instance *pdecrypt; > > > > > @@ -175,13 +176,16 @@ static int pcrypt_aead_init_tfm(struct crypto_aead *tfm) > > > > > struct pcrypt_instance_ctx *ictx = aead_instance_ctx(inst); > > > > > struct pcrypt_aead_ctx *ctx = crypto_aead_ctx(tfm); > > > > > struct crypto_aead *cipher; > > > > > + struct cpumask non_isolated; > > > > > + > > > > > + cpumask_and(&non_isolated, cpu_online_mask, housekeeping_cpumask(HK_TYPE_DOMAIN)); > > > > > > > > Since certain systems do not use isolcpus=domain, so please use a flag > > > > that is setup by nohz_full=, for example HK_FLAG_MISC: > > > > > > > > static int __init housekeeping_nohz_full_setup(char *str) > > > > { > > > > unsigned long flags; > > > > > > > > flags = HK_FLAG_TICK | HK_FLAG_WQ | HK_FLAG_TIMER | HK_FLAG_RCU | > > > > HK_FLAG_MISC | HK_FLAG_KTHREAD; > > > > > > > > return housekeeping_setup(str, flags); > > > > } > > > > __setup("nohz_full=", housekeeping_nohz_full_setup); > > > > > > Oh, sure. > > > Since we are talking about WorkQueues, I think it makes sense to pick > > > HK_FLAG_WQ. > > > > > > > > > > > Also, shouldnt you use cpumask_t ?/ > > > > > > Yeah, I think so. > > > I was quick to choose the 'struct cpumask' because all functions would operate > > > in this variable type, but yeah, I think it makes sense to have this variable > > > being opaque here. > > > > In fact, it seems neither 'struct cpumask' nor 'cpumask_t' are recommended to be > > used allocated in the stack, due to the large size it can get (up to 1kB). > > > > At include/linux/cpumask.h we have: > > 'cpumask_var_t: struct cpumask for stack usage' > > which should work better at least for init functions like this. > > > > In other cases, I see 'static cpumask_t' being used to avoid the allocation > > overhead, but it's probably due to the functions being called in very specific > > scenarios. It could mean trouble if multiple cpus try to use it at once. > > > > What do you recommend on it? > > Sorry for the delay. I suppose allocating and freeing is OK in this context, since > its initialization time and not a hot path? Yeah, it makes sense this way. I will allocate as suggested! (Unless my other change gets in, so this new variable and a lot of overhead can be avoided.) Thanks Marcelo! ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-11-02 2:11 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-04 6:25 [PATCH v1 1/1] crypto/pcrypt: Do not use isolated CPUs for callback Leonardo Bras 2022-10-05 12:57 ` Marcelo Tosatti 2022-10-07 21:42 ` Leonardo Brás 2022-10-11 18:20 ` Leonardo Brás 2022-11-01 17:35 ` Marcelo Tosatti 2022-11-02 2:09 ` Leonardo Bras Soares Passos
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 NNTP newsgroup(s).