Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap

On Fri, Oct 16, 2020 at 12:04 PM John Stultz wrote: > > On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote: > > On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote: > > > @@ -393,6 +424,16 @@ static int system_heap_allocate(struct dma_heap > > > *heap, > > > /* just

Re: [PATCH v2 2/3] dma-buf: system_heap: Add pagepool support to system heap

On Wed, Jan 27, 2021 at 9:10 PM John Stultz wrote: > > On Wed, Jan 27, 2021 at 12:21 PM Daniel Mentz wrote: > > > > On Fri, Jan 22, 2021 at 7:47 PM John Stultz wrote: > > > +static int system_heap_clear_pages(struct page **pages, int num, > > > pgprot_t

Re: [PATCH v2 2/3] dma-buf: system_heap: Add pagepool support to system heap

On Fri, Jan 22, 2021 at 7:47 PM John Stultz wrote: > +static int system_heap_clear_pages(struct page **pages, int num, pgprot_t > pgprot) > +{ > + void *addr = vmap(pages, num, VM_MAP, pgprot); > + > + if (!addr) > + return -ENOMEM; > + memset(addr, 0, PAGE_SIZE *

Re: lib/genalloc

On Fri, Nov 2, 2018 at 1:55 PM Alexey Skidanov wrote: > > > > On 11/2/18 9:17 PM, Daniel Mentz wrote: > > On Thu, Nov 1, 2018 at 10:07 AM Alexey Skidanov > > wrote: > >> On 11/1/18 18:48, Stephen Bates wrote: > >>>>I use gen_poo

Re: lib/genalloc

On Fri, Nov 2, 2018 at 1:55 PM Alexey Skidanov wrote: > > > > On 11/2/18 9:17 PM, Daniel Mentz wrote: > > On Thu, Nov 1, 2018 at 10:07 AM Alexey Skidanov > > wrote: > >> On 11/1/18 18:48, Stephen Bates wrote: > >>>>I use gen_poo

Re: lib/genalloc

On Thu, Nov 1, 2018 at 10:07 AM Alexey Skidanov wrote: > On 11/1/18 18:48, Stephen Bates wrote: > >>I use gen_pool_first_fit_align() as pool allocation algorithm allocating > >>buffers with requested alignment. But if a chunk base address is not > >>aligned to the requested

Re: lib/genalloc

On Thu, Nov 1, 2018 at 10:07 AM Alexey Skidanov wrote: > On 11/1/18 18:48, Stephen Bates wrote: > >>I use gen_pool_first_fit_align() as pool allocation algorithm allocating > >>buffers with requested alignment. But if a chunk base address is not > >>aligned to the requested

Re: [PATCH v2] genalloc: Make the avail variable an atomic_long_t

On Thu, Oct 26, 2017 at 9:04 AM, <sba...@raithlin.com> wrote: > --- a/include/linux/genalloc.h > +++ b/include/linux/genalloc.h > @@ -32,6 +32,7 @@ > > #include > #include > +#include Do we still need #include ? For me, it compiles without it. Reviewed

Re: [PATCH v2] genalloc: Make the avail variable an atomic_long_t

On Thu, Oct 26, 2017 at 9:04 AM, wrote: > --- a/include/linux/genalloc.h > +++ b/include/linux/genalloc.h > @@ -32,6 +32,7 @@ > > #include > #include > +#include Do we still need #include ? For me, it compiles without it. Reviewed-by: Daniel Mentz

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

I found that genalloc is very slow for large chunk sizes because bitmap_find_next_zero_area has to grind through that entire bitmap. Hence, I recommend avoiding genalloc for large chunk sizes. I'm thinking how this would behave on a 32 bit ARM platform On Wed, Oct 25, 2017 at 8:32 AM,

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

I found that genalloc is very slow for large chunk sizes because bitmap_find_next_zero_area has to grind through that entire bitmap. Hence, I recommend avoiding genalloc for large chunk sizes. I'm thinking how this would behave on a 32 bit ARM platform On Wed, Oct 25, 2017 at 8:32 AM, wrote: >

[PATCH v2] ALSA: seq: 2nd attempt at fixing race creating a q

ts this situation by calling snd_use_lock_use() from snd_seq_queue_alloc() prior to calling queue_list_add(). It is then the caller's responsibility to call snd_use_lock_free(>use_lock). Reported-by: Dmitry Vyukov <dvyu...@google.com> Cc: <sta...@vger.kernel.org> Cc: Takash

[PATCH v2] ALSA: seq: 2nd attempt at fixing race creating a q

ts this situation by calling snd_use_lock_use() from snd_seq_queue_alloc() prior to calling queue_list_add(). It is then the caller's responsibility to call snd_use_lock_free(>use_lock). Reported-by: Dmitry Vyukov Cc: Cc: Takashi Iwai Signed-off-by: Daniel Mentz --- sound/core/seq/se

Re: [PATCH] ALSA: seq: 2nd attempt at fixing race creating a q

On Fri, Aug 11, 2017 at 7:42 AM, Takashi Iwai <ti...@suse.de> wrote: > > On Fri, 11 Aug 2017 05:07:34 +0200, > Daniel Mentz wrote: > > > > commit 4842e98f26dd80be3623c4714a244ba52ea096a8 ("ALSA: seq: Fix race at > > creating a queue") attempted to fix a r

Re: [PATCH] ALSA: seq: 2nd attempt at fixing race creating a q

On Fri, Aug 11, 2017 at 7:42 AM, Takashi Iwai wrote: > > On Fri, 11 Aug 2017 05:07:34 +0200, > Daniel Mentz wrote: > > > > commit 4842e98f26dd80be3623c4714a244ba52ea096a8 ("ALSA: seq: Fix race at > > creating a queue") attempted to fix a race reported by syzka

[PATCH] ALSA: seq: 2nd attempt at fixing race creating a q

alling snd_use_lock_use(). Reported-by: Dmitry Vyukov <dvyu...@google.com> Cc: <sta...@vger.kernel.org> Cc: Takashi Iwai <ti...@suse.de> Signed-off-by: Daniel Mentz <danielme...@google.com> --- sound/core/seq/seq_clientmgr.c | 13 - sound/core/seq/seq_queue.c | 14

[PATCH] ALSA: seq: 2nd attempt at fixing race creating a q

alling snd_use_lock_use(). Reported-by: Dmitry Vyukov Cc: Cc: Takashi Iwai Signed-off-by: Daniel Mentz --- sound/core/seq/seq_clientmgr.c | 13 - sound/core/seq/seq_queue.c | 14 +- sound/core/seq/seq_queue.h | 2 +- 3 files changed, 14 insertions(+), 15 deletions(-)

Re: [PATCH] kmod: test_kmod: Correctly lock reg_dev_mutex

OK. While we're here: I think there's a spelling error in usage() in tools/testing/selftests/kmod/kmod.sh echo "-c Run test ID once" echo "-s Run test ID x test-count number of times" I believe that "-c" and "-s" are swapped. "c" probably stands for count and "s" for single.

Re: [PATCH] kmod: test_kmod: Correctly lock reg_dev_mutex

OK. While we're here: I think there's a spelling error in usage() in tools/testing/selftests/kmod/kmod.sh echo "-c Run test ID once" echo "-s Run test ID x test-count number of times" I believe that "-c" and "-s" are swapped. "c" probably stands for count and "s" for single.

[PATCH] kmod: test_kmod: Correctly lock reg_dev_mutex

It appears that, in the preamble of register_test_dev_kmod(), mutex_lock() has been confused with mutex_unlock(). Previously, register_test_dev_kmod() never called mutex_lock() but instead, it called mutex_unlock() twice. Signed-off-by: Daniel Mentz <danielme...@google.com> Cc: Luis R. Rod

[PATCH] kmod: test_kmod: Correctly lock reg_dev_mutex

It appears that, in the preamble of register_test_dev_kmod(), mutex_lock() has been confused with mutex_unlock(). Previously, register_test_dev_kmod() never called mutex_lock() but instead, it called mutex_unlock() twice. Signed-off-by: Daniel Mentz Cc: Luis R. Rodriguez Cc: Greg Kroah-Hartman

Re: [RFC][PATCH 0/4] Fixes for two recently found timekeeping bugs

of CLOCK_MONOTONIC_RAW jumping backwards by 1 ns is now passing. Tested-by: Daniel Mentz <danielme...@google.com> On Tue, May 30, 2017 at 5:10 PM, Daniel Mentz <danielme...@google.com> wrote: > I successfully tested these four patches on a HiKey (ARMv8) board using a > 4.9 kernel. I che

Re: [RFC][PATCH 0/4] Fixes for two recently found timekeeping bugs

of CLOCK_MONOTONIC_RAW jumping backwards by 1 ns is now passing. Tested-by: Daniel Mentz On Tue, May 30, 2017 at 5:10 PM, Daniel Mentz wrote: > I successfully tested these four patches on a HiKey (ARMv8) board using a > 4.9 kernel. I cherry picked various commits from upstream that touched > ke

Re: [RFC][PATCH 2/4] time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting

On Sat, May 27, 2017 at 12:36 AM, Ingo Molnar wrote: > > * John Stultz wrote: > >> + u64 nsecps; > > What does the 'ps' postfix stand for? It's not obvious (to me). > I guess that nsecps stands for "nanoseconds per second", although the code appears

Re: [RFC][PATCH 2/4] time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting

On Sat, May 27, 2017 at 12:36 AM, Ingo Molnar wrote: > > * John Stultz wrote: > >> + u64 nsecps; > > What does the 'ps' postfix stand for? It's not obvious (to me). > I guess that nsecps stands for "nanoseconds per second", although the code appears to be storing that value left shifted by

Re: [PATCH] lib/genalloc.c: Start search from start of chunk

On Wed, Oct 26, 2016 at 12:39 PM, Andrew Morton <a...@linux-foundation.org> wrote: > On Wed, 26 Oct 2016 19:09:51 +0100 Will Deacon <will.dea...@arm.com> wrote: > >> On Tue, Oct 25, 2016 at 11:36:44AM -0700, Daniel Mentz wrote: >> > gen_pool_alloc_algo() iterates

Re: [PATCH] lib/genalloc.c: Start search from start of chunk

On Wed, Oct 26, 2016 at 12:39 PM, Andrew Morton wrote: > On Wed, 26 Oct 2016 19:09:51 +0100 Will Deacon wrote: > >> On Tue, Oct 25, 2016 at 11:36:44AM -0700, Daniel Mentz wrote: >> > gen_pool_alloc_algo() iterates over the chunks of a pool trying to find >> >

[PATCH] lib/genalloc.c: Start search from start of chunk

lt;nsek...@ti.com> Cc: Takashi Iwai <ti...@suse.de> Cc: Thadeu Lima de Souza Cascardo <casca...@linux.vnet.ibm.com> Cc: Thierry Reding <thierry.red...@gmail.com> Cc: Vinod Koul <vinod.k...@intel.com> Cc: Vladimir Zapolskiy <vladimir_zapols...@mentor.com> Cc: Will

[PATCH] lib/genalloc.c: Start search from start of chunk

Thierry Reding Cc: Vinod Koul Cc: Vladimir Zapolskiy Cc: Will Deacon Signed-off-by: Daniel Mentz --- lib/genalloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/genalloc.c b/lib/genalloc.c index 0a11396..144fe6b 100644 --- a/lib/genalloc.c +++ b/lib/genalloc.c @@

[PATCH] lib/genalloc.c: Start search from start of chunk

<casca...@linux.vnet.ibm.com> Cc: Thierry Reding <thierry.red...@gmail.com> Cc: Vinod Koul <vinod.k...@intel.com> Cc: Vladimir Zapolskiy <vladimir_zapols...@mentor.com> Cc: Will Deacon <will.dea...@arm.com> Signed-off-by: Daniel Mentz <danielme...@google.com> ---

[PATCH] lib/genalloc.c: Start search from start of chunk

Mark Brown Cc: Mathieu Desnoyers Cc: Mauro Carvalho Chehab Cc: Olof Johansson Cc: Ritesh Harjain Cc: Rob Herring Cc: Russell King Cc: Sekhar Nori Cc: Takashi Iwai Cc: Thadeu Lima de Souza Cascardo Cc: Thierry Reding Cc: Vinod Koul Cc: Vladimir Zapolskiy Cc: Will Deacon Signed-off-by: Da

[PATCH] ARC: [build] Support gz, lzma compressed uImage

Add support for lzma compressed uImage. Support for gzip was already available but could not be enabled because we were missing CONFIG_HAVE_KERNEL_GZIP in arch/arc/Kconfig. Signed-off-by: Daniel Mentz <danielme...@google.com> Cc: linux-snps-...@lists.infradead.org Cc: Vineet Gupta <v

[PATCH] ARC: [build] Support gz, lzma compressed uImage

Add support for lzma compressed uImage. Support for gzip was already available but could not be enabled because we were missing CONFIG_HAVE_KERNEL_GZIP in arch/arc/Kconfig. Signed-off-by: Daniel Mentz Cc: linux-snps-...@lists.infradead.org Cc: Vineet Gupta --- arch/arc/Kconfig | 2

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

On Mon, Sep 26, 2016 at 5:38 AM, Alexey Brodkin <alexey.brod...@synopsys.com> wrote: > On Fri, 2016-09-23 at 18:04 -0700, Daniel Mentz wrote: >> On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin >> <alexey.brod...@synopsys.com> wrote: >> > >> > On Thu,

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

On Mon, Sep 26, 2016 at 5:38 AM, Alexey Brodkin wrote: > On Fri, 2016-09-23 at 18:04 -0700, Daniel Mentz wrote: >> On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin >> wrote: >> > >> > On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote: >> > &

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin <alexey.brod...@synopsys.com> wrote: > On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote: >> Sorry, that was a misunderstanding. Buildroot routinely runs the strip >> command on .ko files before installing them on t

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin wrote: > On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote: >> Sorry, that was a misunderstanding. Buildroot routinely runs the strip >> command on .ko files before installing them on the target. I was only >> looking at

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

On Thu, Sep 22, 2016 at 1:59 PM, Vineet Gupta <vineet.gup...@synopsys.com> wrote: > Hi Daniel, > > On 09/19/2016 06:21 PM, Daniel Mentz wrote: >> I confirmed that the .eh_frame section is present and that the >> .debug_frame section is absent. I also verified that the fi

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

On Thu, Sep 22, 2016 at 1:59 PM, Vineet Gupta wrote: > Hi Daniel, > > On 09/19/2016 06:21 PM, Daniel Mentz wrote: >> I confirmed that the .eh_frame section is present and that the >> .debug_frame section is absent. I also verified that the file size of >> the .ko fil

Re: [PATCH 0/3] ARC unwinder switch to .eh_frame

Hi Vineet, Thank you for your patches. I applied them, and verified that unwinding works with code that is compiled into the kernel image as well as kernel modules. I confirmed that the .eh_frame section is present and that the .debug_frame section is absent. I also verified that the file size of

Re: [PATCH 0/3] ARC unwinder switch to .eh_frame

Hi Vineet, Thank you for your patches. I applied them, and verified that unwinding works with code that is compiled into the kernel image as well as kernel modules. I confirmed that the .eh_frame section is present and that the .debug_frame section is absent. I also verified that the file size of

[PATCH] dma-debug: Fix dma_debug_entry offset calculation

the following: "DMA-API: exceeded 7 overlapping mappings of cacheline 0x03e0" Cacheline 0x03e0 does not exist on our platform. Fixes: 0abdd7a81b7e ("dma-debug: introduce debug_dma_assert_idle()") Signed-off-by: Daniel Mentz --- lib/dma-debug.c | 4 ++-- 1 file changed

[PATCH] dma-debug: Fix dma_debug_entry offset calculation

the following: "DMA-API: exceeded 7 overlapping mappings of cacheline 0x03e0" Cacheline 0x03e0 does not exist on our platform. Fixes: 0abdd7a81b7e ("dma-debug: introduce debug_dma_assert_idle()") Signed-off-by: Daniel Mentz <danielme...@google.com> --- lib/dma-debug.c |