基本的数据结构学习笔记：kref

本文简单介绍了设备驱动模型中最最简单的一个数据结构：kref，它作为内核中最基本的引用计数而存在。

首先直观地介绍该数据结构及操作它的一些方法，然后再介绍其具体的用法。参考：kref.h kref.c kref.txt

一、kref及操作kref的方法

struct kref

{

atomic_t refcount;

};

可以看到kref结构体的成员只有一个原子变量refcount，为什么还要用kref结构体来包装一下呢？

目前我所知道的有两种说法：

1、为了方便编译器做类型检查（不是很懂......）

2、为了以后方便扩展（这个很好理解）

不管怎样，反正目前这个结构体很简单啦。另外，内核还提供了4个函数用来操作kref：

void kref_set(struct kref *kref, int num);

void kref_init(struct kref *kref);

void kref_get(struct kref *kref);

int kref_put(struct kref *kref, void (*release) (struct kref *kref));

下面来看一下它们的源码。

/**

* kref_set - initialize object and set refcount to requested number.

* @kref: object in question.

* @num: initial reference counter

*/

void kref_set(struct kref *kref, int num)

{

atomic_set(&kref->refcount, num); //设置kref的引用计数为num

smp_mb(); //......这个暂时就不管了吧，没具体研究过

}

/**

* kref_init - initialize object.

* @kref: object in question.

*/

void kref_init(struct kref *kref)

{

kref_set(kref, 1); //简单地调用kref_set，将引用计数设置为1

}

/**

* kref_get - increment refcount for object.

* @kref: object.

*/

void kref_get(struct kref *kref)

{

WARN_ON(!atomic_read(&kref->refcount));//如果引用计数为0，内核将给出警告。不过，这样的情况可能发生呢？引用计数为0了，kref不就被释放了吗？这句话的作用应该是捕获编程错误，例如，在调用get之前没有调用init等等

atomic_inc(&kref->refcount);//原子地递增引用计数

smp_mb__after_atomic_inc();//......飘过

}

/**

* kref_put - decrement refcount for object.

* @kref: object.

* @release: pointer to the function that will clean up the object when the

* last reference to the object is released.

* This pointer is required, and it is not acceptable to pass kfree

* in as this function.

*

* Decrement the refcount, and if 0, call release().

* Return 1 if the object was removed, otherwise return 0. Beware, if this

* function returns 0, you still can not count on the kref from remaining in

* memory. Only use the return value if you want to see if the kref is now

* gone, not present.

*/

int kref_put(struct kref *kref, void (*release)(struct kref *kref))

{

WARN_ON(release == NULL);//如果没有指定release函数，内核给出警告

WARN_ON(release == (void (*)(struct kref *))kfree);//如果指定的release函数是kfree，则内核给出警告，从注释中可以看出

if (atomic_dec_and_test(&kref->refcount)) {//原子地递减引用计数，并检测递减后计数是否0

release(kref);//没有被引用了，调用注册进的release函数释放kref

return 1;//返回1，表示对象已被删除

}

return 0;

}

二、kref的用法

一般而言，都是将kref包含进一个自定义的结构体中，从而为包含它的结构体提供引用计数功能。

struct my_data

{

.

.

struct kref refcount;

.

.

};

使用时，在分配了自定义结构体之后，必须对kref成员进行初始化：

struct my_data *data;

data = kmalloc(sizeof(*data), GFP_KERNEL);

if (!data)

return -ENOMEM;

kref_init(&data->refcount); //初始化结构体data的引用计数为1

一旦拥有一个已初始化过的kref，那么必须遵循以下3个规则（因为kref里不存在任何lock，所以在编程时务必遵循规则，否则可能出错）：

1)如果对一个kref-ed的结构体指针做非局部性拷贝，特别是当将指针传递给另一个线程时，必须在传递之前调用kref_get()以增加kref-ed的结构体的引用计数：kref_get(&data->refcount);

如果已经有一个有效的指针指向一个包含kref的结构体（引用计数不会为0），那么在kref_get时可以不用“锁”。

2)当完成对kref-ed结构体的使用时，必须要调用kref_put():kref_put(&data->refcount, data_release);

如果这是对结构体的最后的引用，那么data_release函数将被调用。

3)如果在没有取得结构体的一个有效的指针时，尝试去获取kref-ed结构体的引用，则必须串行地访问kref-ed结构体，这样在kref_get时不会发生kref_put，并且在kref_get期间结构体必须保持有效。

我们分析一段代码，来加深对以上3个规则的理解。

代码1：分配一个kref-ed结构体，并把它传递给另一个线程处理

void data_release(struct kref *ref)

{

struct my_data *data = container_of(ref, struct my_data, refcount);

kfree(data);

}

void more_data_handling(void *cb_data)

{

struct my_data *data = cb_data;

.

. do stuff with data here

.

kref_put(&data->refcount, data_release);

}

int my_data_handler(void)

{

int rv = 0;

struct my_data *data;

struct task_struct *task;

data = kmalloc(sizeof(*data), GFP_KERNEL);

if (!data)

return -ENOMEM;

kref_init(&data->refcount);

kref_get(&data->refcount);//规则1)

task = kthread_run(more_data_handling, data, "more_data_handling");

if (task == ERR_PTR(-ENOMEM))

{

rv = -ENOMEM;

kref_put(&data->refcount, data_release);

goto out;

}

.

. do stuff with data here

.

out:

kref_put(&data->refcount, data_release);

return rv;

}

这种方式不必关心两个线程访问data的顺序，kref_put()函数知道data何时不再有任何引用并且释放data。kref_get不需要“锁”，因为已经有了一个

有效的指针data。

规则3)是最让人烦的，举例来说，有一个链表，其元素都是kref-ed结构，我们希望获取链表的第一个元素的引用。

我们不能简单地将链表的第一个元素pull出来，然后调用kref_get。这将违反规则3)，因为我们还没有获取一个有效的指针。必须使用“锁”：

static DEFINE_MUTEX(mutex);

static LIST_HEAD(q);

struct my_data

{

struct kref refcount;

struct list_head link;

};

static struct my_data *get_entry()

{

struct my_data *entry = NULL;

mutex_lock(&mutex);

if (!list_empty(&q))

{

entry = container_of(q.next, struct my_q_entry, link);

kref_get(&entry->refcount);

}

mutex_unlock(&mutex);

return entry;

}

static void release_entry(struct kref *ref)

{

struct my_data *entry = container_of(ref, struct my_data, refcount);

list_del(&entry->link);

kfree(entry);

}

static void put_entry(struct my_data *entry)

{

mutex_lock(&mutex);

kref_put(&entry->refcount, release_entry);

mutex_unlock(&mutex);

}

如果不想在整个release操作期间都保持“锁”，可以使用kref_put的返回值。

比如你不想在保持“锁”的情况下调用kfree（因为没有必要？）

你可以这么使用kref_put：

static void release_entry(struct kref *ref)

{ /* All work is done after the return from kref_put(). */ }

static void put_entry(struct my_data *entry)

{

mutex_lock(&mutex);

if (kref_put(&entry->refcount, release_entry))

{

list_del(&entry->link);

mutex_unlock(&mutex);

kfree(entry);

}

else

mutex_unlock(&mutex);

}

上面的这种方式，在release函数会调用其他比较耗时的函数时比较有用，因为毕竟一个“锁”不能长时间的保持。

不过，还是推荐将所有的操作都放在release例程里做，因为那样的话代码会很简洁。

PS：关于kref的用法，基本是翻译kref.txt的，有些东西还没完全理解，待续吧......

其实只要理解了那3个规则，就知道该如何使用kref了，可惜啊，没有完全理解透，提几个问题，待以后理解了再补上。

Q1：关于规则1，为何在将kref-ed结构体传递给另一个进程前，必须调用kref_get？不可以在另一个进程内部调用kref_get吗？

Q2：为何不能将kfree传递给kref_put？为何要做这样的限制？