container_of isn't returning expected address - linux

Question

I'm not sure what I'm doing incorrectly but it's time for some extra eyes. I make a device with device_create() providing some "extra data" as follows:
pDevice = device_create(ahcip_class, NULL, /*no parent*/
MKDEV(AHCIP_MAJOR, AHCIP_MINOR + i), &mydevs[i],
DRIVER_NAME "%d", AHCIP_MINOR + i);
Expecting that my sysfs attribute function is going to take a pointer to the struct kobject member of struct device I do the following with my attribute function
static ahcip_dev *get_ahcip_dev(struct kobject *ko)
{
ahcip_dev *adev = NULL;
struct device *pdev = container_of(ko, struct device, kobj);
if (!pdev) {
pr_err("%s:%d unable to find device struct in kobject\n",
__func__, __LINE__);
return NULL;
}
/* some debugging stuff */
pr_info("%s:%d mydevs[0] %p\n", __func__, __LINE__, mydevs);
pr_info("%s:%d mydevs[1] %p\n", __func__, __LINE__, mydevs+1);
pr_info("%s:%d mydevs[0].psysfs_dev %p\n", __func__, __LINE__,
mydevs->psysfs_dev);
pr_info("%s:%d mydevs[1].psysfs_dev %p\n", __func__, __LINE__,
(mydevs + 1)->psysfs_dev);
pr_info("%s:%d pdev %p\n", __func__, __LINE__, pdev);
adev = (ahcip_dev*)dev_get_drvdata(pdev);
/* return the pointer anyway, but if it's null, print to klog */
if (!adev)
pr_err("%s:%d no ahcip_dev, private driver data is NULL\n",
__func__, __LINE__);
return adev;
}
static ssize_t pxis_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buff)
{
u32 pi = 0;
ahcip_dev *adev = get_ahcip_dev(kobj);
/* get_ahcip_dev() will print what happened, this needs to return
* error code
*/
if (!adev)
return -EIO;
pi = adev->port_index;
return sprintf(buff, "%08x\n", get_port_reg(adev->hba->ports[pi], 0x10));
}
The output (condensed) from the above function shows:
get_ahcip_dev:175 mydevs[1].psysfs_dev ffff88011b2b4800
get_ahcip_dev:176 pdev ffff88011b2b47f0
pdev in this case should point to the same memory location as mydevs[1].psysfs_dev but it's 16 bytes "earlier". What am I doing wrong?

Answer 1

I don't like to answer my own questions but this seems appropriate in this case. The root of the problem was a faulty assumption of what the attribute function needed to process. Attribute functions have this prototype you can view in context here
ssize_t (*show)(struct kobject *, struct attribute *,char *);
ssize_t (*store)(struct kobject *,struct attribute *,const char *, size_t);
Since the device_create() function returns a struct device object defined as follows (excerpt only, see full def here)
struct device {
struct device *parent;
struct device_private *p;
struct kobject kobj;
...
}
I assumed that it was this pointer that my attribute function must process. Reading through the description of the problem shows that when I used the container_of macro to get what I thought was the address of the containing struct device I was 16 bytes "to early." Notice, the first two fields of this structure are pointers. On a 64 bit system, which mine is, this is 16 bytes.
Because the function prototypes are defined as shown above, I assumed I was getting a reference to the kobj field. Instead, I was getting the actual struct device object. In other words, I was getting the address I wanted upon function entry and was still trying to find it.
Something about this may be documented in the labyrinth of Linux kernel documentation. If anyone knows of it, please put a link here. I read much but didn't see this one coming. I hope this question and answer helps some other kernel newbie.

Answer 2

Your example did not show how you created the sysfs attribute nor how your pxis_show() function was associated with it. Since you're trying to connect this attribute to a struct device, might you happen to be calling device_create_file() to create the sysfs node? If so, examining the callback prototypes of struct device_attribute might make more sense. You will see that the show/store callbacks look like:
ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
ssize_t (*store)(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count);
In which case that might better explain your extra offset issue--the first parameter is actually already pointing to your struct device, and not the embedded kobj member, so that performing a container_of() will take you back an additional 16 bytes.
You might be confusing the device_attribute callbacks with the struct sysfs_ops format, as they look similar, but notice the parameter types are different. In fact, there is a mapping from sysfs_ops to struct device_attribute as can be seen with the wrapper functions dev_attr_show and dev_attr_store as can be found here