* dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7
@ 2018-03-27 8:12 Sebastian Ott
2018-03-27 8:21 ` Geert Uytterhoeven
2018-03-27 14:33 ` Christoph Hellwig
0 siblings, 2 replies; 9+ messages in thread
From: Sebastian Ott @ 2018-03-27 8:12 UTC (permalink / raw)
To: Christoph Hellwig, Jesper Nilsson, Geert Uytterhoeven; +Cc: linux-kernel
Hi,
commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma
allocations specifying __GFP_ZERO by silently removing that flag.
Why should "the memory returned [] always be zeroed."?
Regards,
Sebastian
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7
2018-03-27 8:12 dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 Sebastian Ott
@ 2018-03-27 8:21 ` Geert Uytterhoeven
2018-03-27 8:41 ` Sebastian Ott
2018-03-27 14:33 ` Christoph Hellwig
1 sibling, 1 reply; 9+ messages in thread
From: Geert Uytterhoeven @ 2018-03-27 8:21 UTC (permalink / raw)
To: Sebastian Ott
Cc: Christoph Hellwig, Jesper Nilsson, Linux Kernel Mailing List
Hi Sebastian,
On Tue, Mar 27, 2018 at 10:12 AM, Sebastian Ott
<sebott@linux.vnet.ibm.com> wrote:
> commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma
> allocations specifying __GFP_ZERO by silently removing that flag.
How did it break? The flag is now always added.
> Why should "the memory returned [] always be zeroed."?
To avoid leaking information.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7
2018-03-27 8:21 ` Geert Uytterhoeven
@ 2018-03-27 8:41 ` Sebastian Ott
2018-03-27 8:51 ` Geert Uytterhoeven
0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Ott @ 2018-03-27 8:41 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Christoph Hellwig, Jesper Nilsson, Linux Kernel Mailing List
Hello Geert,
On Tue, 27 Mar 2018, Geert Uytterhoeven wrote:
> On Tue, Mar 27, 2018 at 10:12 AM, Sebastian Ott
> <sebott@linux.vnet.ibm.com> wrote:
> > commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma
> > allocations specifying __GFP_ZERO by silently removing that flag.
>
> How did it break? The flag is now always added.
+ flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM | __GFP_ZERO);
I read that as a removal. But maybe I need more coffee..
Sebastian
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7
2018-03-27 8:41 ` Sebastian Ott
@ 2018-03-27 8:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2018-03-27 8:51 UTC (permalink / raw)
To: Sebastian Ott
Cc: Christoph Hellwig, Jesper Nilsson, Linux Kernel Mailing List
Hi Sebastian,
On Tue, Mar 27, 2018 at 10:41 AM, Sebastian Ott
<sebott@linux.vnet.ibm.com> wrote:
> On Tue, 27 Mar 2018, Geert Uytterhoeven wrote:
>> On Tue, Mar 27, 2018 at 10:12 AM, Sebastian Ott
>> <sebott@linux.vnet.ibm.com> wrote:
>> > commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma
>> > allocations specifying __GFP_ZERO by silently removing that flag.
>>
>> How did it break? The flag is now always added.
>
> + flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM | __GFP_ZERO);
>
> I read that as a removal. But maybe I need more coffee..
Sorry, you're right.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7
2018-03-27 8:12 dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 Sebastian Ott
2018-03-27 8:21 ` Geert Uytterhoeven
@ 2018-03-27 14:33 ` Christoph Hellwig
2018-03-27 15:24 ` Sebastian Ott
1 sibling, 1 reply; 9+ messages in thread
From: Christoph Hellwig @ 2018-03-27 14:33 UTC (permalink / raw)
To: Sebastian Ott
Cc: Christoph Hellwig, Jesper Nilsson, Geert Uytterhoeven, linux-kernel
On Tue, Mar 27, 2018 at 10:12:54AM +0200, Sebastian Ott wrote:
> Hi,
>
> commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma
> allocations specifying __GFP_ZERO by silently removing that flag.
>
> Why should "the memory returned [] always be zeroed."?
Because that is what the current implementations do - we always zero
the memory returned from dma_map_ops.alloc().
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7
2018-03-27 14:33 ` Christoph Hellwig
@ 2018-03-27 15:24 ` Sebastian Ott
2018-03-27 16:45 ` Christoph Hellwig
0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Ott @ 2018-03-27 15:24 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jesper Nilsson, Geert Uytterhoeven, linux-kernel
On Tue, 27 Mar 2018, Christoph Hellwig wrote:
> On Tue, Mar 27, 2018 at 10:12:54AM +0200, Sebastian Ott wrote:
> > Hi,
> >
> > commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma
> > allocations specifying __GFP_ZERO by silently removing that flag.
> >
> > Why should "the memory returned [] always be zeroed."?
>
> Because that is what the current implementations do - we always zero
> the memory returned from dma_map_ops.alloc().
What do you mean by current implementations? Arch specific code? At least
on s390 we don't do that. dma-mapping.h doesn't do it either.
Sebastian
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7
2018-03-27 15:24 ` Sebastian Ott
@ 2018-03-27 16:45 ` Christoph Hellwig
2018-03-27 17:04 ` Sebastian Ott
0 siblings, 1 reply; 9+ messages in thread
From: Christoph Hellwig @ 2018-03-27 16:45 UTC (permalink / raw)
To: Sebastian Ott
Cc: Christoph Hellwig, Jesper Nilsson, Geert Uytterhoeven, linux-kernel
On Tue, Mar 27, 2018 at 05:24:10PM +0200, Sebastian Ott wrote:
> What do you mean by current implementations? Arch specific code? At least
> on s390 we don't do that. dma-mapping.h doesn't do it either.
The arch implementations should do it. Seems like s390 and potentially
a few others don't. I'm a little slow due to a cast on one arm, but I'll
do an audit and will fix up anything I'll find.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7
2018-03-27 16:45 ` Christoph Hellwig
@ 2018-03-27 17:04 ` Sebastian Ott
2018-03-28 11:57 ` Christoph Hellwig
0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Ott @ 2018-03-27 17:04 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jesper Nilsson, Geert Uytterhoeven, linux-kernel
On Tue, 27 Mar 2018, Christoph Hellwig wrote:
> On Tue, Mar 27, 2018 at 05:24:10PM +0200, Sebastian Ott wrote:
> > What do you mean by current implementations? Arch specific code? At least
> > on s390 we don't do that. dma-mapping.h doesn't do it either.
>
> The arch implementations should do it. Seems like s390 and potentially
> a few others don't. I'm a little slow due to a cast on one arm, but I'll
> do an audit and will fix up anything I'll find.
What was wrong with the old behavior (let the caller decide - the same
as with memory allocations)? We have interfaces like dma_zalloc_coherent,
which explicitely set __GFP_ZERO. We have callers of dma_alloc followed by
a manually memset..
Sebastian
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7
2018-03-27 17:04 ` Sebastian Ott
@ 2018-03-28 11:57 ` Christoph Hellwig
0 siblings, 0 replies; 9+ messages in thread
From: Christoph Hellwig @ 2018-03-28 11:57 UTC (permalink / raw)
To: Sebastian Ott
Cc: Christoph Hellwig, Jesper Nilsson, Geert Uytterhoeven, linux-kernel
On Tue, Mar 27, 2018 at 07:04:51PM +0200, Sebastian Ott wrote:
> What was wrong with the old behavior (let the caller decide - the same
> as with memory allocations)?
The old behavior on most (all?) mainstream architectures is that we
always zero the return value. On x86/i386 this goes back to at least
Linux 2.4. So common drivers simply expect this to happen.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-03-28 11:57 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-27 8:12 dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 Sebastian Ott
2018-03-27 8:21 ` Geert Uytterhoeven
2018-03-27 8:41 ` Sebastian Ott
2018-03-27 8:51 ` Geert Uytterhoeven
2018-03-27 14:33 ` Christoph Hellwig
2018-03-27 15:24 ` Sebastian Ott
2018-03-27 16:45 ` Christoph Hellwig
2018-03-27 17:04 ` Sebastian Ott
2018-03-28 11:57 ` Christoph Hellwig
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).