[...]
>>>>> + raw_ssr = kmalloc(sizeof(card->raw_ssr), GFP_KERNEL);
>>>>> + if (!raw_ssr)
>>>>> + return -ENOMEM;
>>>>> +
>>
>> Creating this bounce buffer does of course comes with a small cost.
>> Maybe we could neglect its impact!?
>>
>> However we could also make the card->raw_ssr be cacheline aligned, via
>> using the __cacheline_aligned attribute for it.
>>
>> Also, this isn't the only case when the mmc core creates bounce
>> buffers while reading card registers during the card initialization.
>>
>> Perhaps a better method is to use the __cacheline_aligned for these
>> buffers that needs to be DMA-able (requests which is
>> MMC_DATA_READ|WRITE)). Of course that change would affect/increase the
>> number of bytes allocated for each card struct (due to padding), but
>> since this is just a single struct being allocated per card, this
>> shouldn't be an issue.
>>
>> What do you think?
>
> The issue is now in v4.9 and is causing problems on some platforms with the
> reported card name becoming corrupted (since it cid.prodname is on the same
> cacheline).
>
> I'd say go with the simple solution for the fix, which is using the bounce
> buffer. If somebody wants to rework this (and all the other bounce buffers)
> to use __cacheline_aligned or something else that can be done as a separate
> patch series on top of this.
>
> When you apply the patch can you add
>
> Fixes: 5275a652d296 ("mmc: sd: Export SD Status via “ssr” device attribute")
Ahh, I didn't realize this was a fix for a regression. I thought it
was a long outstanding issue that more or less never occurred.
>
> and tag it for stable?
Yes, of course. I will deal with it as of tomorrow morning. Thanks for
pinging me on this!
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
