Re: libata/sata_sil24 cache alignment problem?

[Tejun Heo <htejun@gmail.com>]

Alan Cox wrote:
>> I hadn't considered that approach due to the way the ata_port is allocated:
>>
>>> libata-core.c:
>>>         host = scsi_host_alloc(ent->sht, sizeof(struct ata_port));
>>>
>>> hosts.c:
>>> struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
>>> {
>>>         shost = kzalloc(sizeof(struct Scsi_Host) + privsize, gfp_mask);
>>> }
>> The ata_port allocation is tacked onto the end of the Scsi_Host
>> allocation, so the start of ata_port will only be cache aligned if the
>> end of the Scsi_Host struct is, although that would be easy enough to
>> fix since it's currently aligned to an unsigned long boundary.
> 
> You are right.

For recent kernels, ata_port is allocated separately so
____cacheline_aligned should be enough.

>> I like that approach better, since it's clearer what the intent is,

But, yeah, allocating separately is probably safer.

>> and it's easier.  Is there any other way that the ata_port struct
>> might be used that would invalidate this?  
> 
> I can't think of one. The object lifetime is right - the ata_port is
> created before the port buffer is used and destroyed after it is finished
> (obviously or embedding it in the struct wouldn't work either)

I'll prep a patch for the current kernel.  Hmmm... This means that any
DMA buffer should be aligned to cacheline.  Block layer DMA alignment
helpers should probably take this into consideration and we better add
warnings to dma map functions.  This only affects DMA-to-memory, right?

Thanks.

-- 
tejun