From: Peter Zijlstra <peterz@infradead.org>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Will Deacon <will@kernel.org>,
Marc Gonzalez <marc.w.gonzalez@free.fr>,
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Vineet Gupta <Vineet.Gupta1@synopsys.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Rafael Wysocki <rjw@rjwysocki.net>,
LKML <linux-kernel@vger.kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Russell King <rmk+kernel@armlinux.org.uk>,
Mark Brown <broonie@kernel.org>, Tejun Heo <tj@kernel.org>,
arcml <linux-snps-arc@lists.infradead.org>,
Robin Murphy <robin.murphy@arm.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc()
Date: Fri, 20 Dec 2019 21:23:46 +0100 [thread overview]
Message-ID: <20191220202346.GT2827@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CY4PR1201MB012011E554FC69F7B074B7E2A12D0@CY4PR1201MB0120.namprd12.prod.outlook.com>
On Fri, Dec 20, 2019 at 07:32:16PM +0000, Alexey Brodkin wrote:
> Well it somehow used to work for quite some time now with the data-buffer
> being allocated with 4 words offset (which is 16 bytes for 32-bit platform
3 words, devres_node is 3 words.
Which is exactly why we had to change it, the odd alignment caused ARC
to explode.
> and 32 for 64-bit which is still much less than mentioned 128 bytes).
> Or we just never managed to identify those rare cases when data corruption
> really happened?
The races are rather rare methinks, you'd have to get a list-op
concurrently with a DMA.
If you get the list corrupted, I'm thinking the crash is fairly likely,
albeit really difficuly to debug.
> > No matter which way round you allocate devres and data, by necessity
> > they're always going to consume the same total amount of memory.
>
> So then the next option I guess is to separate meta-data from data buffers
> completely. Are there any reasons to not do that
Dunno, should work just fine I think.
> other than the hack we're
> discussing here (meta-data in the beginning of the buffer) used to work OK-ish?
If meta-data at the beginngin used to work, I don't see why meta-data at
the end wouldn't work equally well. They'd be equally broken.
But I'm still flabbergasted at the fact that they're doing non-coherent
DMA to kmalloc memory, I thought we had a DMA api for that, with a
special allocator and everything (but what do I know, I've never used
that).
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Will Deacon <will@kernel.org>,
Marc Gonzalez <marc.w.gonzalez@free.fr>,
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Vineet Gupta <Vineet.Gupta1@synopsys.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Rafael Wysocki <rjw@rjwysocki.net>,
LKML <linux-kernel@vger.kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Russell King <rmk+kernel@armlinux.org.uk>,
Mark Brown <broonie@kernel.org>, Tejun Heo <tj@kernel.org>,
arcml <linux-snps-arc@lists.infradead.org>,
Robin Murphy <robin.murphy@arm.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc()
Date: Fri, 20 Dec 2019 21:23:46 +0100 [thread overview]
Message-ID: <20191220202346.GT2827@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CY4PR1201MB012011E554FC69F7B074B7E2A12D0@CY4PR1201MB0120.namprd12.prod.outlook.com>
On Fri, Dec 20, 2019 at 07:32:16PM +0000, Alexey Brodkin wrote:
> Well it somehow used to work for quite some time now with the data-buffer
> being allocated with 4 words offset (which is 16 bytes for 32-bit platform
3 words, devres_node is 3 words.
Which is exactly why we had to change it, the odd alignment caused ARC
to explode.
> and 32 for 64-bit which is still much less than mentioned 128 bytes).
> Or we just never managed to identify those rare cases when data corruption
> really happened?
The races are rather rare methinks, you'd have to get a list-op
concurrently with a DMA.
If you get the list corrupted, I'm thinking the crash is fairly likely,
albeit really difficuly to debug.
> > No matter which way round you allocate devres and data, by necessity
> > they're always going to consume the same total amount of memory.
>
> So then the next option I guess is to separate meta-data from data buffers
> completely. Are there any reasons to not do that
Dunno, should work just fine I think.
> other than the hack we're
> discussing here (meta-data in the beginning of the buffer) used to work OK-ish?
If meta-data at the beginngin used to work, I don't see why meta-data at
the end wouldn't work equally well. They'd be equally broken.
But I'm still flabbergasted at the fact that they're doing non-coherent
DMA to kmalloc memory, I thought we had a DMA api for that, with a
special allocator and everything (but what do I know, I've never used
that).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
Marc Gonzalez <marc.w.gonzalez@free.fr>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rafael Wysocki <rjw@rjwysocki.net>,
LKML <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Will Deacon <will@kernel.org>,
Russell King <rmk+kernel@armlinux.org.uk>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Tejun Heo <tj@kernel.org>, Mark Brown <broonie@kernel.org>,
arcml <linux-snps-arc@lists.infradead.org>,
Vineet Gupta <Vineet.Gupta1@synopsys.com>,
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Subject: Re: [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc()
Date: Fri, 20 Dec 2019 21:23:46 +0100 [thread overview]
Message-ID: <20191220202346.GT2827@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CY4PR1201MB012011E554FC69F7B074B7E2A12D0@CY4PR1201MB0120.namprd12.prod.outlook.com>
On Fri, Dec 20, 2019 at 07:32:16PM +0000, Alexey Brodkin wrote:
> Well it somehow used to work for quite some time now with the data-buffer
> being allocated with 4 words offset (which is 16 bytes for 32-bit platform
3 words, devres_node is 3 words.
Which is exactly why we had to change it, the odd alignment caused ARC
to explode.
> and 32 for 64-bit which is still much less than mentioned 128 bytes).
> Or we just never managed to identify those rare cases when data corruption
> really happened?
The races are rather rare methinks, you'd have to get a list-op
concurrently with a DMA.
If you get the list corrupted, I'm thinking the crash is fairly likely,
albeit really difficuly to debug.
> > No matter which way round you allocate devres and data, by necessity
> > they're always going to consume the same total amount of memory.
>
> So then the next option I guess is to separate meta-data from data buffers
> completely. Are there any reasons to not do that
Dunno, should work just fine I think.
> other than the hack we're
> discussing here (meta-data in the beginning of the buffer) used to work OK-ish?
If meta-data at the beginngin used to work, I don't see why meta-data at
the end wouldn't work equally well. They'd be equally broken.
But I'm still flabbergasted at the fact that they're doing non-coherent
DMA to kmalloc memory, I thought we had a DMA api for that, with a
special allocator and everything (but what do I know, I've never used
that).
next prev parent reply other threads:[~2019-12-20 20:24 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 15:30 [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc() Marc Gonzalez
2019-12-17 15:30 ` Marc Gonzalez
2019-12-17 15:45 ` Greg Kroah-Hartman
2019-12-17 15:45 ` Greg Kroah-Hartman
2019-12-17 16:17 ` Marc Gonzalez
2019-12-17 16:17 ` Marc Gonzalez
2019-12-18 14:20 ` Alexey Brodkin
2019-12-18 14:20 ` Alexey Brodkin
2019-12-18 14:20 ` Alexey Brodkin
2019-12-18 15:40 ` Marc Gonzalez
2019-12-18 15:40 ` Marc Gonzalez
2019-12-18 15:40 ` Marc Gonzalez
2019-12-20 10:19 ` Marc Gonzalez
2019-12-20 10:19 ` Marc Gonzalez
2019-12-20 10:22 ` Greg Kroah-Hartman
2019-12-20 10:22 ` Greg Kroah-Hartman
2019-12-20 10:22 ` Greg Kroah-Hartman
2019-12-20 10:22 ` Greg Kroah-Hartman
2019-12-20 12:05 ` Marc Gonzalez
2019-12-20 12:05 ` Marc Gonzalez
2019-12-20 17:19 ` Peter Zijlstra
2019-12-20 17:19 ` Peter Zijlstra
2019-12-20 14:06 ` Peter Zijlstra
2019-12-20 14:06 ` Peter Zijlstra
2019-12-20 14:16 ` Greg Kroah-Hartman
2019-12-20 14:16 ` Greg Kroah-Hartman
2019-12-20 15:01 ` Robin Murphy
2019-12-20 15:01 ` Robin Murphy
2019-12-20 17:13 ` Peter Zijlstra
2019-12-20 17:13 ` Peter Zijlstra
2019-12-20 22:02 ` Robin Murphy
2019-12-20 22:02 ` Robin Murphy
2020-01-06 10:05 ` Peter Zijlstra
2020-01-06 10:05 ` Peter Zijlstra
2019-12-20 19:32 ` Alexey Brodkin
2019-12-20 19:32 ` Alexey Brodkin
2019-12-20 19:32 ` Alexey Brodkin
2019-12-20 20:23 ` Peter Zijlstra [this message]
2019-12-20 20:23 ` Peter Zijlstra
2019-12-20 20:23 ` Peter Zijlstra
2019-12-20 21:02 ` Alexey Brodkin
2019-12-20 21:02 ` Alexey Brodkin
2019-12-20 21:02 ` Alexey Brodkin
2019-12-20 21:47 ` Dmitry Torokhov
2019-12-20 21:47 ` Dmitry Torokhov
2019-12-20 21:47 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191220202346.GT2827@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Alexey.Brodkin@synopsys.com \
--cc=Eugeniy.Paltsev@synopsys.com \
--cc=Vineet.Gupta1@synopsys.com \
--cc=bjorn.andersson@linaro.org \
--cc=broonie@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=marc.w.gonzalez@free.fr \
--cc=rjw@rjwysocki.net \
--cc=rmk+kernel@armlinux.org.uk \
--cc=robin.murphy@arm.com \
--cc=tj@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.