On Mon, Jul 09, 2018 at 07:17:11AM +0000, Alexey Brodkin wrote:
Hi Greg,
On Mon, 2018-07-09 at 09:06 +0200, greg@kroah.com wrote:
On Mon, Jul 09, 2018 at 06:46:50AM +0000, Alexey Brodkin wrote:
Hi Greg,
On Mon, 2018-07-09 at 07:48 +0200, Greg KH wrote:
On Mon, Jul 09, 2018 at 07:44:44AM +0300, Alexey Brodkin wrote:
Depending on ABI "long long" type of a particular 32-bit CPU might be aligned by either word (32-bits) or double word (64-bits). Make sure "data" is really 64-bit aligned for any 32-bit CPU.
At least for 32-bit ARC cores ABI requires "long long" types to be aligned by normal 32-bit word. This makes "data" field aligned to 12 bytes. Which is still OK as long as we use 32-bit data only.
But once we want to use native atomic64_t type (i.e. when we use special instructions LLOCKD/SCONDD for accessing 64-bit data) we easily hit misaligned access exception.
So is this something you hit today? If not, why is this needed for stable kernels?
Indeed we hit that problem recently when Etnaviv driver was switched to DRM GPU scheduler, see commit e93b6deeb45a ("drm/etnaviv: hook up DRM GPU scheduler"). The most important part of DRM GPU scheduler is "job_id_count" member of "drm_gpu_scheduler" structure of type "atomic64_t". This structure is put in a buffer allocated by devm_kzalloc() and if "job_id_count" is not 64-bit aligned atomic instruction fails with an exception.
As for stable requirements - mentioned commit was a part of 4.17 kernel which broke GPU driver for one of our HSDK board so I guess back-porting to 4.17 is a no-brainer.
Ok, so 4.17 is as far back as you need? Please try to be specific when asking for stable backports.
Well in that particular case I really wanted to get this fix back-ported starting from v4.8 so I guess that's what I need to add in Cc tag, right? ----------------------------->8--------------------- Cc: stable@vger.kernel.org # 4.8+ ----------------------------->8---------------------
Yes.