On Tue, Nov 20, 2012 at 11:33:25AM -0800, Andrew Morton wrote:
> On Tue, 20 Nov 2012 15:31:45 +0100
> Marek Szyprowski wrote:
>
> > dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> > regardless the flags provided by the caller. This causes excessive
>
On Tue, 20 Nov 2012 11:48:44 +0100
Marek Szyprowski wrote:
> > As this patch is already in -next and is stuck there for two more
> > weeks I can't (or at least won't) merge this patch, so I can't help
> > with any of the above.
>
> I will fix both issues in the next version of the patch. Would
On Tue, 20 Nov 2012 15:31:45 +0100
Marek Szyprowski wrote:
> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> regardless the flags provided by the caller. This causes excessive
> pruning of emergency memory pools without any good reason. Additionaly,
> on ARM arch
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency memory pools without any good reason. Additionaly,
on ARM architecture any driver which is using dmapools will sooner or
later trigger
Hello,
On 11/19/2012 11:48 PM, Andrew Morton wrote:
On Sun, 18 Nov 2012 19:18:46 -0500
Jason Cooper wrote:
> I've added the maintainers for mm/*. Hopefully they can let us know if
> this is good for v3.8...
As Marek has inexplicably put this patch into linux-next via his tree,
we don't
Hello,
On 11/19/2012 11:48 PM, Andrew Morton wrote:
On Sun, 18 Nov 2012 19:18:46 -0500
Jason Cooper ja...@lakedaemon.net wrote:
I've added the maintainers for mm/*. Hopefully they can let us know if
this is good for v3.8...
As Marek has inexplicably put this patch into linux-next via his
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency memory pools without any good reason. Additionaly,
on ARM architecture any driver which is using dmapools will sooner or
later trigger
On Tue, 20 Nov 2012 15:31:45 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency memory pools without any good reason. Additionaly,
on ARM
On Tue, 20 Nov 2012 11:48:44 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
As this patch is already in -next and is stuck there for two more
weeks I can't (or at least won't) merge this patch, so I can't help
with any of the above.
I will fix both issues in the next version of
On Tue, Nov 20, 2012 at 11:33:25AM -0800, Andrew Morton wrote:
On Tue, 20 Nov 2012 15:31:45 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning
On Sun, 18 Nov 2012 19:18:46 -0500
Jason Cooper wrote:
> I've added the maintainers for mm/*. Hopefully they can let us know if
> this is good for v3.8...
As Marek has inexplicably put this patch into linux-next via his tree,
we don't appear to be getting a say in the matter!
The patch looks
On Sun, 18 Nov 2012 19:18:46 -0500
Jason Cooper ja...@lakedaemon.net wrote:
I've added the maintainers for mm/*. Hopefully they can let us know if
this is good for v3.8...
As Marek has inexplicably put this patch into linux-next via his tree,
we don't appear to be getting a say in the matter!
Marek,
I've added the maintainers for mm/*. Hopefully they can let us know if
this is good for v3.8...
thx,
Jason.
On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
> the flags provided by the
Marek,
I've added the maintainers for mm/*. Hopefully they can let us know if
this is good for v3.8...
thx,
Jason.
On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
the flags provided by the caller
On 12.11.2012 11:38, Andrew Lunn wrote:
On Mon, Nov 12, 2012 at 10:48:02AM +0100, Soeren Moch wrote:
On 11.11.2012 18:22, Andrew Lunn wrote:
On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless
the flags
On Mon, Nov 12, 2012 at 10:48:02AM +0100, Soeren Moch wrote:
> On 11.11.2012 18:22, Andrew Lunn wrote:
> > On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> >> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> regardless
> >> th
On 11.11.2012 18:22, Andrew Lunn wrote:
> On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
>> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless
>> the flags provided by the caller. This causes excessive pruning of
>> emergency mem
On 11.11.2012 18:22, Andrew Lunn wrote:
On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless
the flags provided by the caller. This causes excessive pruning of
emergency memory pools without any good
On Mon, Nov 12, 2012 at 10:48:02AM +0100, Soeren Moch wrote:
On 11.11.2012 18:22, Andrew Lunn wrote:
On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless
the flags provided by the caller. This causes
On 12.11.2012 11:38, Andrew Lunn wrote:
On Mon, Nov 12, 2012 at 10:48:02AM +0100, Soeren Moch wrote:
On 11.11.2012 18:22, Andrew Lunn wrote:
On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless
the flags
On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
> the flags provided by the caller. This causes excessive pruning of
> emergency memory pools without any good reason. This patch changes
On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
the flags provided by the caller. This causes excessive pruning of
emergency memory pools without any good reason. This patch changes the code
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
the flags provided by the caller. This causes excessive pruning of
emergency memory pools without any good reason. This patch changes the code
to correctly use gfp flags provided by the dmapool caller. This should
solve
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
the flags provided by the caller. This causes excessive pruning of
emergency memory pools without any good reason. This patch changes the code
to correctly use gfp flags provided by the dmapool caller. This should
solve
(page->offset), not sizeof(int). Just in case someone
changes the type of dma_page.offset.
- Use pr_err(), as suggested by checkpatch. Please use checkpatch.
---
a/mm/dmapool.c~dmapool-make-dmapool_debug-detect-corruption-of-free-marker-fix
+++ a/mm/dmapool.c
@@ -350,23 +350,24 @@ void *dma_
This can help to catch case where hardware is writting after dma free.
Signed-off-by: Matthieu Castet
---
mm/dmapool.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index c5ab33b..e10898a 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
This can help to catch case where hardware is writting after dma free.
Signed-off-by: Matthieu Castet matthieu.cas...@parrot.com
---
mm/dmapool.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index c5ab33b..e10898a 100644
---
is strange, it misses capitalisation and needed
a grammatical fix
- Use sizeof(page-offset), not sizeof(int). Just in case someone
changes the type of dma_page.offset.
- Use pr_err(), as suggested by checkpatch. Please use checkpatch.
---
a/mm/dmapool.c~dmapool-make-dmapool_debug-detect
From: Randy Dunlap <[EMAIL PROTECTED]>
Docbook fatal error, file was moved:
docproc: linux-2.6.24-git15/drivers/base/dmapool.c: No such file or directory
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
Documentation/DocBook/kernel-api.tmpl |2 +-
1 file changed, 1 insertion(+), 1
From: Randy Dunlap [EMAIL PROTECTED]
Docbook fatal error, file was moved:
docproc: linux-2.6.24-git15/drivers/base/dmapool.c: No such file or directory
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
Documentation/DocBook/kernel-api.tmpl |2 +-
1 file changed, 1 insertion(+), 1
With one trivial change (taking the lock slightly earlier on wakeup
from schedule), all uses of the waitq are under the pool lock, so we
can use the locked (or __) versions of the wait queue functions, and
avoid the extra spinlock.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
Acked-by: David
Run Lindent and fix all issues reported by checkpatch.pl
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
mm/dmapool.c | 288 +-
1 files changed, 142 insertions(+), 146 deletions(-)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index
We were missing a copyright statement and license, so add GPLv2, David
Brownell's copyright and my copyright.
The asm/io.h include was superfluous, but we were missing a few other
necessary includes.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
mm/dmapool.c | 40
Use a list of free blocks within a page instead of using a bitmap.
Update documentation to reflect this. As well as being a slight
reduction in memory allocation, locked ops and lines of code, it speeds
up a transaction processing benchmark by 0.4%.
Signed-off-by: Matthew Wilcox <[EMAIL
Check that 'align' is a power of two, like the API specifies.
Align 'size' to 'align' correctly -- the current code has an off-by-one.
The ALIGN macro in kernel.h doesn't.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
---
mm/dmapool.c | 15
/7 of this series.
- I've run checkpatch.pl over the file, and fixed all the warnings/errors
it reported.
- And I've updated it to 2.6.24-rc4.
Patches also available from:
http://git.kernel.org/?p=linux/kernel/git/willy/misc.git;a=shortlog;h=dmapool
I'll send all seven as a followup to this mail
and 6/7 of this series.
- I've run checkpatch.pl over the file, and fixed all the warnings/errors
it reported.
- And I've updated it to 2.6.24-rc4.
Patches also available from:
http://git.kernel.org/?p=linux/kernel/git/willy/misc.git;a=shortlog;h=dmapool
I'll send all seven as a followup
Use a list of free blocks within a page instead of using a bitmap.
Update documentation to reflect this. As well as being a slight
reduction in memory allocation, locked ops and lines of code, it speeds
up a transaction processing benchmark by 0.4%.
Signed-off-by: Matthew Wilcox [EMAIL
Check that 'align' is a power of two, like the API specifies.
Align 'size' to 'align' correctly -- the current code has an off-by-one.
The ALIGN macro in kernel.h doesn't.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
Acked-by: David S. Miller [EMAIL PROTECTED]
---
mm/dmapool.c | 15
We were missing a copyright statement and license, so add GPLv2, David
Brownell's copyright and my copyright.
The asm/io.h include was superfluous, but we were missing a few other
necessary includes.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
---
mm/dmapool.c | 40
Run Lindent and fix all issues reported by checkpatch.pl
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
---
mm/dmapool.c | 288 +-
1 files changed, 142 insertions(+), 146 deletions(-)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index
With one trivial change (taking the lock slightly earlier on wakeup
from schedule), all uses of the waitq are under the pool lock, so we
can use the locked (or __) versions of the wait queue functions, and
avoid the extra spinlock.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
Acked-by: David
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 15:01:19 -0400
> The previous implementation simply refused to allocate more than a
> boundary's worth of data from an entire page. Some users didn't know
> this, so specified things like SMP_CACHE_BYTES, not realising the
>
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 15:01:18 -0400
> Also add documentation for how dma pools work, move the header above the
> includes, add my copyright, add the original author's copyright, add a
> GPL v2 licence to the file and fix the includes.
>
> Signed-off-by:
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 15:01:17 -0400
> Check that 'align' is a power of two, like the API specifies.
> Align 'size' to 'align' correctly -- the current code has an off-by-one.
> The ALIGN macro in kernel.h doesn't.
>
> Signed-off-by: Matthew Wilcox
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 15:01:16 -0400
> With one trivial change (taking the lock slightly earlier on wakeup
> from schedule), all uses of the waitq are under the pool lock, so we
> can use the locked (or __) versions of the wait queue functions, and
>
Matthew Wilcox wrote:
> On Wed, Sep 26, 2007 at 09:47:41PM +0200, roel wrote:
>> The brackets in the first if/else are not required, and you could combine
>> the two statements:
>
> You mean braces, not brackets. And I find this little fetish of yours
> highly disturbing. I prefer to use
Matthew Wilcox wrote:
[...]
> @@ -142,14 +144,13 @@ struct dma_pool *dma_pool_create(const char *name,
> struct device *dev,
> if ((size % align) != 0)
> size = ALIGN(size, align);
>
> - if (allocation == 0) {
> - if (PAGE_SIZE < size)
> -
Matthew Wilcox wrote:
[...]
> @@ -113,9 +133,12 @@ struct dma_pool *dma_pool_create(const char *name,
> struct device *dev,
> return NULL;
> }
>
> - if (size == 0)
> + if (size == 0) {
> return NULL;
> -
> + } else if (size < 4) {
> +
Matthew Wilcox wrote:
> Check that 'align' is a power of two, like the API specifies.
> Align 'size' to 'align' correctly -- the current code has an off-by-one.
> The ALIGN macro in kernel.h doesn't.
>
> Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
> ---
> mm/dmapool.c | 15
difficult to review. Also I assume the main change is
"Change dmapool free block management" -- but I'm left wondering
exactly how and why you're changing it.
- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL P
The previous implementation simply refused to allocate more than a
boundary's worth of data from an entire page. Some users didn't know
this, so specified things like SMP_CACHE_BYTES, not realising the
horrible waste of memory that this was. It's fairly easy to correct
this problem, just by
Also add documentation for how dma pools work, move the header above the
includes, add my copyright, add the original author's copyright, add a
GPL v2 licence to the file and fix the includes.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
mm/dmapool.c | 161
With one trivial change (taking the lock slightly earlier on wakeup
from schedule), all uses of the waitq are under the pool lock, so we
can use the locked (or __) versions of the wait queue functions, and
avoid the extra spinlock.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
Check that 'align' is a power of two, like the API specifies.
Align 'size' to 'align' correctly -- the current code has an off-by-one.
The ALIGN macro in kernel.h doesn't.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
mm/dmapool.c | 15 ---
1 files changed, 8 insertions(+),
I have a series of patches to dmapool that I'd like opinions on. I
don't have any performance numbers yet, but some of the patches are a
good idea, with or without performance numbers.
One of the problems with dmapool is that it doesn't have a maintainer
listed. I've spent enough time looking
I have a series of patches to dmapool that I'd like opinions on. I
don't have any performance numbers yet, but some of the patches are a
good idea, with or without performance numbers.
One of the problems with dmapool is that it doesn't have a maintainer
listed. I've spent enough time looking
With one trivial change (taking the lock slightly earlier on wakeup
from schedule), all uses of the waitq are under the pool lock, so we
can use the locked (or __) versions of the wait queue functions, and
avoid the extra spinlock.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
---
mm/dmapool.c
Check that 'align' is a power of two, like the API specifies.
Align 'size' to 'align' correctly -- the current code has an off-by-one.
The ALIGN macro in kernel.h doesn't.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
---
mm/dmapool.c | 15 ---
1 files changed, 8 insertions(+), 7
Also add documentation for how dma pools work, move the header above the
includes, add my copyright, add the original author's copyright, add a
GPL v2 licence to the file and fix the includes.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
---
mm/dmapool.c | 161
The previous implementation simply refused to allocate more than a
boundary's worth of data from an entire page. Some users didn't know
this, so specified things like SMP_CACHE_BYTES, not realising the
horrible waste of memory that this was. It's fairly easy to correct
this problem, just by
to review. Also I assume the main change is
Change dmapool free block management -- but I'm left wondering
exactly how and why you're changing it.
- R.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
Matthew Wilcox wrote:
Check that 'align' is a power of two, like the API specifies.
Align 'size' to 'align' correctly -- the current code has an off-by-one.
The ALIGN macro in kernel.h doesn't.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
---
mm/dmapool.c | 15 ---
1
Matthew Wilcox wrote:
[...]
@@ -113,9 +133,12 @@ struct dma_pool *dma_pool_create(const char *name,
struct device *dev,
return NULL;
}
- if (size == 0)
+ if (size == 0) {
return NULL;
-
+ } else if (size 4) {
+ size = 4;
+
Matthew Wilcox wrote:
[...]
@@ -142,14 +144,13 @@ struct dma_pool *dma_pool_create(const char *name,
struct device *dev,
if ((size % align) != 0)
size = ALIGN(size, align);
- if (allocation == 0) {
- if (PAGE_SIZE size)
-
Matthew Wilcox wrote:
On Wed, Sep 26, 2007 at 09:47:41PM +0200, roel wrote:
The brackets in the first if/else are not required, and you could combine
the two statements:
You mean braces, not brackets. And I find this little fetish of yours
highly disturbing. I prefer to use braces, and
From: Matthew Wilcox [EMAIL PROTECTED]
Date: Wed, 26 Sep 2007 15:01:16 -0400
With one trivial change (taking the lock slightly earlier on wakeup
from schedule), all uses of the waitq are under the pool lock, so we
can use the locked (or __) versions of the wait queue functions, and
avoid the
From: Matthew Wilcox [EMAIL PROTECTED]
Date: Wed, 26 Sep 2007 15:01:17 -0400
Check that 'align' is a power of two, like the API specifies.
Align 'size' to 'align' correctly -- the current code has an off-by-one.
The ALIGN macro in kernel.h doesn't.
Signed-off-by: Matthew Wilcox [EMAIL
From: Matthew Wilcox [EMAIL PROTECTED]
Date: Wed, 26 Sep 2007 15:01:18 -0400
Also add documentation for how dma pools work, move the header above the
includes, add my copyright, add the original author's copyright, add a
GPL v2 licence to the file and fix the includes.
Signed-off-by:
From: Matthew Wilcox [EMAIL PROTECTED]
Date: Wed, 26 Sep 2007 15:01:19 -0400
The previous implementation simply refused to allocate more than a
boundary's worth of data from an entire page. Some users didn't know
this, so specified things like SMP_CACHE_BYTES, not realising the
horrible
From: Victor Fusco <[EMAIL PROTECTED]>
Fix the sparse warning "implicit cast to nocast type"
File/Subsystem:drivers/base/dmapool
Signed-off-by: Victor Fusco <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
--
---
drivers/base/dmapool.c |3
From: Victor Fusco [EMAIL PROTECTED]
Fix the sparse warning implicit cast to nocast type
File/Subsystem:drivers/base/dmapool
Signed-off-by: Victor Fusco [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
--
---
drivers/base/dmapool.c |3 ++-
include/linux/dmapool.h |3
Nish Aravamudan <[EMAIL PROTECTED]> wrote:
>
> > Also, __set_current_state() can be user here: the add_wait_queue() contains
> > the necessary barriers. (Grubby, but we do that in quite a few places with
> > this particular code sequence (we should have an add_wait_queue() variant
> > which
On Sun, 6 Mar 2005 19:44:14 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
> >
> > Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> > Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
> > ---
> >
[EMAIL PROTECTED] wrote:
>
> use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
>
> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
> ---
>
>
> kj-domen/drivers/base/dmapool.c |2 +-
> 1 files changed, 1 insertion(+), 1
use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/base/dmapool.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN
use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/drivers/base/dmapool.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN
[EMAIL PROTECTED] wrote:
use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/drivers/base/dmapool.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
On Sun, 6 Mar 2005 19:44:14 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
Nish Aravamudan [EMAIL PROTECTED] wrote:
Also, __set_current_state() can be user here: the add_wait_queue() contains
the necessary barriers. (Grubby, but we do that in quite a few places with
this particular code sequence (we should have an add_wait_queue() variant
which does the
201 - 280 of 280 matches
Mail list logo
