linux-mediatek.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] dma-buf: dma-heap: Add a size check for allocation
@ 2021-12-27  9:47 guangming.cao
  0 siblings, 0 replies; 7+ messages in thread
From: guangming.cao @ 2021-12-27  9:47 UTC (permalink / raw)
  To: Sumit Semwal, Benjamin Gaignard, Liam Mark, Laura Abbott,
	Brian Starkey, John Stultz, Christian König,
	Matthias Brugger, open list:DMA-BUF HEAPS FRAMEWORK,
	open list:DMA-BUF HEAPS FRAMEWORK,
	moderated list:DMA-BUF HEAPS FRAMEWORK, open list,
	moderated list:ARM/Mediatek SoC support,
	moderated list:ARM/Mediatek SoC support
  Cc: Bo Song, Libo Kang, jianjiao zeng, mingyuan ma, Yunfei Wang,
	wsd_upstream, Guangming

From: Guangming <Guangming.Cao@mediatek.com>

Add a size check for allcation since the allocation size is
always less than the total DRAM size.

Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
---
v2: 1. update size limitation as total_dram page size.
    2. update commit message
---
 drivers/dma-buf/dma-heap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 56bf5ad01ad5..e39d2be98d69 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
 	struct dma_buf *dmabuf;
 	int fd;
 
+	if (len / PAGE_SIZE > totalram_pages())
+		return -EINVAL;
 	/*
 	 * Allocations from all heaps have to begin
 	 * and end on page boundaries.
-- 
2.17.1


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] dma-buf: dma-heap: Add a size check for allocation
  2022-01-05  6:36       ` guangming.cao
@ 2022-01-13 10:50         ` Sumit Semwal
  0 siblings, 0 replies; 7+ messages in thread
From: Sumit Semwal @ 2022-01-13 10:50 UTC (permalink / raw)
  To: guangming.cao
  Cc: christian.koenig, brian.starkey, benjamin.gaignard, bo.song,
	dri-devel, jianjiao.zeng, john.stultz, labbott, libo.kang,
	linaro-mm-sig, linux-arm-kernel, linux-kernel, linux-media,
	linux-mediatek, lmark, matthias.bgg, mingyuan.ma, wsd_upstream,
	yf.wang

Hello Guangming,

On Wed, 5 Jan 2022 at 12:05, <guangming.cao@mediatek.com> wrote:
>
> From: Guangming.Cao <guangming.cao@mediatek.com>
>
> On Tue, 2022-01-04 at 08:47 +0100, Christian K鰊ig wrote:
> > Am 03.01.22 um 19:57 schrieb John Stultz:
> > > On Mon, Dec 27, 2021 at 1:52 AM <guangming.cao@mediatek.com> wrote:
> > > > From: Guangming <Guangming.Cao@mediatek.com>
> > > >
> > >
> > > Thanks for submitting this!
> > >
> > > > Add a size check for allcation since the allocation size is
> > >
> > > nit: "allocation" above.
> > >
> > > > always less than the total DRAM size.
> > >
> > > In general, it might be good to add more context to the commit
> > > message
> > > to better answer *why* this change is needed rather than what the
> > > change is doing.  ie: What negative thing happens without this
> > > change?
> > > And so how does this change avoid or improve things?
> >
> > Completely agree, just one little addition: Could you also add this
> > why
> > as comment to the code?
> >
> > When we stumble over this five years from now it is absolutely not
> > obvious why we do this.
> >
> > Thanks,
> > Christian.
> >
> Thanks for your reply!
> I will update the related reason in the patch later.
>
> The reason for adding this check is that we met a case that the user
> sent an invalid size(It seems it's a negative value, MSB is 0xff, it's
> larger than DRAM size after convert it to size_t) to dma-heap to alloc
> memory, and this allocation was running on a process(such as "gralloc"
> on Android device) can't be killed by OOM flow, and we also couldn't
> find the related dmabuf in "dma_buf_debug_show" because the related
> dmabuf was not exported yet since the allocation is still on going.
>
> Since this invalid argument case can be prevented at dma-heap side, so,
> I added this size check, and moreover, to let debug it easily, I also
> added logs when size is bigger than a threshold we set in mtk system
> heap.
> If you think that print logs in dma-heap framework is better, I will
> update it in next version.
>
> If you have better solution(such as dump the size under allocating
> in "dma_buf_debug_show", which maybe need add global variable to record
> it), please kindly let me know.

Thank you for the patch!

I think just adding the reasoning above as the commit message and a
comment in the code should be enough for now; the debug parts may be
easy to add in case someone runs into issues.

> Thanks :)
> Guangming

Best,
Sumit.

>
> > >
> > >
> > > > Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
> > > > Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
> > > > ---
> > > > v2: 1. update size limitation as total_dram page size.
> > > >      2. update commit message
> > > > ---
> > > >   drivers/dma-buf/dma-heap.c | 2 ++
> > > >   1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-
> > > > heap.c
> > > > index 56bf5ad01ad5..e39d2be98d69 100644
> > > > --- a/drivers/dma-buf/dma-heap.c
> > > > +++ b/drivers/dma-buf/dma-heap.c
> > > > @@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct
> > > > dma_heap *heap, size_t len,
> > > >          struct dma_buf *dmabuf;
> > > >          int fd;
> > > >
> > > > +       if (len / PAGE_SIZE > totalram_pages())
> > > > +               return -EINVAL;
> > >
> > > This seems sane. I know ION used to have some 1/2 of memory cap to
> > > avoid unnecessary memory pressure on crazy allocations.
> > >
> > > Could you send again with an improved commit message?
> > >
> > > thanks
> > > -john
> >
> >



--
Thanks and regards,

Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] dma-buf: dma-heap: Add a size check for allocation
  2022-01-04  7:47     ` Christian König
  2022-01-04  8:44       ` Guangming.Cao
@ 2022-01-05  6:36       ` guangming.cao
  2022-01-13 10:50         ` Sumit Semwal
  1 sibling, 1 reply; 7+ messages in thread
From: guangming.cao @ 2022-01-05  6:36 UTC (permalink / raw)
  To: christian.koenig
  Cc: Brian.Starkey, benjamin.gaignard, bo.song, dri-devel,
	guangming.cao, jianjiao.zeng, john.stultz, labbott, libo.kang,
	linaro-mm-sig, linux-arm-kernel, linux-kernel, linux-media,
	linux-mediatek, lmark, matthias.bgg, mingyuan.ma, sumit.semwal,
	wsd_upstream, yf.wang

From: Guangming.Cao <guangming.cao@mediatek.com>

On Tue, 2022-01-04 at 08:47 +0100, Christian K鰊ig wrote:
> Am 03.01.22 um 19:57 schrieb John Stultz:
> > On Mon, Dec 27, 2021 at 1:52 AM <guangming.cao@mediatek.com> wrote:
> > > From: Guangming <Guangming.Cao@mediatek.com>
> > > 
> > 
> > Thanks for submitting this!
> > 
> > > Add a size check for allcation since the allocation size is
> > 
> > nit: "allocation" above.
> > 
> > > always less than the total DRAM size.
> > 
> > In general, it might be good to add more context to the commit
> > message
> > to better answer *why* this change is needed rather than what the
> > change is doing.  ie: What negative thing happens without this
> > change?
> > And so how does this change avoid or improve things?
> 
> Completely agree, just one little addition: Could you also add this
> why 
> as comment to the code?
> 
> When we stumble over this five years from now it is absolutely not 
> obvious why we do this.
> 
> Thanks,
> Christian.
> 
Thanks for your reply!
I will update the related reason in the patch later.

The reason for adding this check is that we met a case that the user
sent an invalid size(It seems it's a negative value, MSB is 0xff, it's
larger than DRAM size after convert it to size_t) to dma-heap to alloc
memory, and this allocation was running on a process(such as "gralloc"
on Android device) can't be killed by OOM flow, and we also couldn't
find the related dmabuf in "dma_buf_debug_show" because the related
dmabuf was not exported yet since the allocation is still on going.

Since this invalid argument case can be prevented at dma-heap side, so,
I added this size check, and moreover, to let debug it easily, I also
added logs when size is bigger than a threshold we set in mtk system
heap.
If you think that print logs in dma-heap framework is better, I will
update it in next version.

If you have better solution(such as dump the size under allocating
in "dma_buf_debug_show", which maybe need add global variable to record
it), please kindly let me know.
Thanks :)
Guangming

> > 
> > 
> > > Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
> > > Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
> > > ---
> > > v2: 1. update size limitation as total_dram page size.
> > >      2. update commit message
> > > ---
> > >   drivers/dma-buf/dma-heap.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-
> > > heap.c
> > > index 56bf5ad01ad5..e39d2be98d69 100644
> > > --- a/drivers/dma-buf/dma-heap.c
> > > +++ b/drivers/dma-buf/dma-heap.c
> > > @@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct
> > > dma_heap *heap, size_t len,
> > >          struct dma_buf *dmabuf;
> > >          int fd;
> > > 
> > > +       if (len / PAGE_SIZE > totalram_pages())
> > > +               return -EINVAL;
> > 
> > This seems sane. I know ION used to have some 1/2 of memory cap to
> > avoid unnecessary memory pressure on crazy allocations.
> > 
> > Could you send again with an improved commit message?
> > 
> > thanks
> > -john
> 
> 

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] dma-buf: dma-heap: Add a size check for allocation
  2022-01-04  7:47     ` Christian König
@ 2022-01-04  8:44       ` Guangming.Cao
  2022-01-05  6:36       ` guangming.cao
  1 sibling, 0 replies; 7+ messages in thread
From: Guangming.Cao @ 2022-01-04  8:44 UTC (permalink / raw)
  To: Christian König, John Stultz
  Cc: Sumit Semwal, Benjamin Gaignard, Liam Mark, Laura Abbott,
	Brian Starkey, Matthias Brugger,
	open list:DMA-BUF HEAPS FRAMEWORK,
	open list:DMA-BUF HEAPS FRAMEWORK,
	moderated list:DMA-BUF HEAPS FRAMEWORK, open list,
	moderated list:ARM/Mediatek SoC support,
	moderated list:ARM/Mediatek SoC support, Bo Song, Libo Kang,
	jianjiao zeng, mingyuan ma, Yunfei Wang, wsd_upstream

On Tue, 2022-01-04 at 08:47 +0100, Christian König wrote:
> Am 03.01.22 um 19:57 schrieb John Stultz:
> > On Mon, Dec 27, 2021 at 1:52 AM <guangming.cao@mediatek.com> wrote:
> > > From: Guangming <Guangming.Cao@mediatek.com>
> > > 
> > 
> > Thanks for submitting this!
> > 
> > > Add a size check for allcation since the allocation size is
> > 
> > nit: "allocation" above.
> > 
> > > always less than the total DRAM size.
> > 
> > In general, it might be good to add more context to the commit
> > message
> > to better answer *why* this change is needed rather than what the
> > change is doing.  ie: What negative thing happens without this
> > change?
> > And so how does this change avoid or improve things?
> 
> Completely agree, just one little addition: Could you also add this
> why 
> as comment to the code?
> 
> When we stumble over this five years from now it is absolutely not 
> obvious why we do this.
Thanks for your reply!
I will update the related reason in the patch later.

The reason for adding this check is that we met a case that the user
sent an invalid size(It seems it's a negative value, MSB is 0xff, it's
larger than DRAM size after convert it to size_t) to dma-heap to alloc
memory, and this allocation was running on a process(such as "gralloc"
on Android device) can't be killed by OOM flow, and we also couldn't
find the related dmabuf in "dma_buf_debug_show" because the related
dmabuf was not exported yet since the allocation is still on going.

Since this invalid argument case can be prevented at dma-heap side, so,
I added this size check, and moreover, to let debug it easily, I also
added logs when size is bigger than a threshold we set in mtk system
heap.
If you think that print logs in dma-heap framework is better, I will
update it in next version.

If you have better solution(such as dump the size under allocating
in "dma_buf_debug_show", which maybe need add global variable to record
it), please kindly let me know, thanks :)

> 
> Thanks,
> Christian.
> 
> > 
> > 
> > > Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
> > > Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
> > > ---
> > > v2: 1. update size limitation as total_dram page size.
> > >      2. update commit message
> > > ---
> > >   drivers/dma-buf/dma-heap.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-
> > > heap.c
> > > index 56bf5ad01ad5..e39d2be98d69 100644
> > > --- a/drivers/dma-buf/dma-heap.c
> > > +++ b/drivers/dma-buf/dma-heap.c
> > > @@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct
> > > dma_heap *heap, size_t len,
> > >          struct dma_buf *dmabuf;
> > >          int fd;
> > > 
> > > +       if (len / PAGE_SIZE > totalram_pages())
> > > +               return -EINVAL;
> > 
> > This seems sane. I know ION used to have some 1/2 of memory cap to
> > avoid unnecessary memory pressure on crazy allocations.
> > 
> > Could you send again with an improved commit message?
> > 
> > thanks
> > -john
> 
> 
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] dma-buf: dma-heap: Add a size check for allocation
  2022-01-03 18:57   ` John Stultz
@ 2022-01-04  7:47     ` Christian König
  2022-01-04  8:44       ` Guangming.Cao
  2022-01-05  6:36       ` guangming.cao
  0 siblings, 2 replies; 7+ messages in thread
From: Christian König @ 2022-01-04  7:47 UTC (permalink / raw)
  To: John Stultz, guangming.cao
  Cc: Sumit Semwal, Benjamin Gaignard, Liam Mark, Laura Abbott,
	Brian Starkey, Matthias Brugger,
	open list:DMA-BUF HEAPS FRAMEWORK,
	open list:DMA-BUF HEAPS FRAMEWORK,
	moderated list:DMA-BUF HEAPS FRAMEWORK, open list,
	moderated list:ARM/Mediatek SoC support,
	moderated list:ARM/Mediatek SoC support, Bo Song, Libo Kang,
	jianjiao zeng, mingyuan ma, Yunfei Wang, wsd_upstream

Am 03.01.22 um 19:57 schrieb John Stultz:
> On Mon, Dec 27, 2021 at 1:52 AM <guangming.cao@mediatek.com> wrote:
>> From: Guangming <Guangming.Cao@mediatek.com>
>>
> Thanks for submitting this!
>
>> Add a size check for allcation since the allocation size is
> nit: "allocation" above.
>
>> always less than the total DRAM size.
> In general, it might be good to add more context to the commit message
> to better answer *why* this change is needed rather than what the
> change is doing.  ie: What negative thing happens without this change?
> And so how does this change avoid or improve things?

Completely agree, just one little addition: Could you also add this why 
as comment to the code?

When we stumble over this five years from now it is absolutely not 
obvious why we do this.

Thanks,
Christian.

>
>
>> Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
>> Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
>> ---
>> v2: 1. update size limitation as total_dram page size.
>>      2. update commit message
>> ---
>>   drivers/dma-buf/dma-heap.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
>> index 56bf5ad01ad5..e39d2be98d69 100644
>> --- a/drivers/dma-buf/dma-heap.c
>> +++ b/drivers/dma-buf/dma-heap.c
>> @@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
>>          struct dma_buf *dmabuf;
>>          int fd;
>>
>> +       if (len / PAGE_SIZE > totalram_pages())
>> +               return -EINVAL;
> This seems sane. I know ION used to have some 1/2 of memory cap to
> avoid unnecessary memory pressure on crazy allocations.
>
> Could you send again with an improved commit message?
>
> thanks
> -john


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] dma-buf: dma-heap: Add a size check for allocation
  2021-12-27  9:51 ` [PATCH v2] dma-buf: dma-heap: Add a size check " guangming.cao
@ 2022-01-03 18:57   ` John Stultz
  2022-01-04  7:47     ` Christian König
  0 siblings, 1 reply; 7+ messages in thread
From: John Stultz @ 2022-01-03 18:57 UTC (permalink / raw)
  To: guangming.cao
  Cc: Sumit Semwal, Benjamin Gaignard, Liam Mark, Laura Abbott,
	Brian Starkey, Christian König, Matthias Brugger,
	open list:DMA-BUF HEAPS FRAMEWORK,
	open list:DMA-BUF HEAPS FRAMEWORK,
	moderated list:DMA-BUF HEAPS FRAMEWORK, open list,
	moderated list:ARM/Mediatek SoC support,
	moderated list:ARM/Mediatek SoC support, Bo Song, Libo Kang,
	jianjiao zeng, mingyuan ma, Yunfei Wang, wsd_upstream

On Mon, Dec 27, 2021 at 1:52 AM <guangming.cao@mediatek.com> wrote:
>
> From: Guangming <Guangming.Cao@mediatek.com>
>

Thanks for submitting this!

> Add a size check for allcation since the allocation size is

nit: "allocation" above.

> always less than the total DRAM size.

In general, it might be good to add more context to the commit message
to better answer *why* this change is needed rather than what the
change is doing.  ie: What negative thing happens without this change?
And so how does this change avoid or improve things?


> Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
> Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
> ---
> v2: 1. update size limitation as total_dram page size.
>     2. update commit message
> ---
>  drivers/dma-buf/dma-heap.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index 56bf5ad01ad5..e39d2be98d69 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
>         struct dma_buf *dmabuf;
>         int fd;
>
> +       if (len / PAGE_SIZE > totalram_pages())
> +               return -EINVAL;

This seems sane. I know ION used to have some 1/2 of memory cap to
avoid unnecessary memory pressure on crazy allocations.

Could you send again with an improved commit message?

thanks
-john

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH v2] dma-buf: dma-heap: Add a size check for allocation
  2021-12-17  9:41 [PATCH] dma-buf: dma-heap: Add a size limitation " guangming.cao
@ 2021-12-27  9:51 ` guangming.cao
  2022-01-03 18:57   ` John Stultz
  0 siblings, 1 reply; 7+ messages in thread
From: guangming.cao @ 2021-12-27  9:51 UTC (permalink / raw)
  To: Sumit Semwal, Benjamin Gaignard, Liam Mark, Laura Abbott,
	Brian Starkey, John Stultz, Christian König,
	Matthias Brugger, open list:DMA-BUF HEAPS FRAMEWORK,
	open list:DMA-BUF HEAPS FRAMEWORK,
	moderated list:DMA-BUF HEAPS FRAMEWORK, open list,
	moderated list:ARM/Mediatek SoC support,
	moderated list:ARM/Mediatek SoC support
  Cc: Bo Song, Libo Kang, jianjiao zeng, mingyuan ma, Yunfei Wang,
	wsd_upstream, Guangming

From: Guangming <Guangming.Cao@mediatek.com>

Add a size check for allcation since the allocation size is
always less than the total DRAM size.

Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
Signed-off-by: jianjiao zeng <jianjiao.zeng@mediatek.com>
---
v2: 1. update size limitation as total_dram page size.
    2. update commit message
---
 drivers/dma-buf/dma-heap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 56bf5ad01ad5..e39d2be98d69 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
 	struct dma_buf *dmabuf;
 	int fd;
 
+	if (len / PAGE_SIZE > totalram_pages())
+		return -EINVAL;
 	/*
 	 * Allocations from all heaps have to begin
 	 * and end on page boundaries.
-- 
2.17.1


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply related	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-01-13 10:51 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-27  9:47 [PATCH v2] dma-buf: dma-heap: Add a size check for allocation guangming.cao
  -- strict thread matches above, loose matches on Subject: below --
2021-12-17  9:41 [PATCH] dma-buf: dma-heap: Add a size limitation " guangming.cao
2021-12-27  9:51 ` [PATCH v2] dma-buf: dma-heap: Add a size check " guangming.cao
2022-01-03 18:57   ` John Stultz
2022-01-04  7:47     ` Christian König
2022-01-04  8:44       ` Guangming.Cao
2022-01-05  6:36       ` guangming.cao
2022-01-13 10:50         ` Sumit Semwal

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).