RISC-V and Arm Linux Kernel Hacks

unlink라는 시스템 콜을 따라가면 아래 함수를 볼 수 있다.
여기서 lookup_hash(&nd) 함수를 좀 파고들어가 보자.

static long do_unlinkat(int dfd, const char __user *pathname)
{
    int error;
    char *name;
    struct dentry *dentry;
    struct nameidata nd;
    struct inode *inode = NULL;
...
    nd.flags &= ~LOOKUP_PARENT;

    mutex_lock_nested(&nd.path.dentry->d_inode->i_mutex, I_MUTEX_PARENT);
    dentry = lookup_hash(&nd);
}

아래와 같은 함수 호출 체인을 볼 수 있는데, 덴트리는 덴트리 캐시에서 덴트리 인스턴스를 찾는 것이다.
static struct dentry *lookup_hash(struct nameidata *nd)
{
    return __lookup_hash(&nd->last, nd->path.dentry, nd);
}

static struct dentry *__lookup_hash(struct qstr *name,
        struct dentry *base, struct nameidata *nd)
{
    bool need_lookup;
    struct dentry *dentry;

    dentry = lookup_dcache(name, base, nd, &need_lookup);
    if (!need_lookup)
        return dentry;

    return lookup_real(base->d_inode, dentry, nd);
}

d_hash(parent, hash); 라는 함수를 호출해서 해시 테이블 포멧의 덴트리 캐시 리스트를 가져온다.

static struct dentry *lookup_dcache(struct qstr *name, struct dentry *dir,
                    struct nameidata *nd, bool *need_lookup)
{
    struct dentry *dentry;
    int error;

    *need_lookup = false;
    dentry = d_lookup(dir, name);
..
}
struct dentry *d_lookup(struct dentry *parent, struct qstr *name)
{
    struct dentry *dentry;
    unsigned seq;

        do {
                seq = read_seqbegin(&rename_lock);
                dentry = __d_lookup(parent, name);
                if (dentry)
            break;
    } while (read_seqretry(&rename_lock, seq));
    return dentry;
}

struct dentry *__d_lookup(struct dentry *parent, struct qstr *name)
{
    unsigned int len = name->len;
    unsigned int hash = name->hash;
    const unsigned char *str = name->name;
    struct hlist_bl_head *b = d_hash(parent, hash);
    struct hlist_bl_node *node;
..
}

결국 *d_hash() 함수를 통해 덴트리 캐시를 처리하는 해시 테이블에 접근한다.
dentry_hashtable은 0xC17C8200에 있다.
  (static struct hlist_bl_head *) dentry_hashtable = 0xC17C8200 = __bss_stop+0x9117E0 -> (
    (struct hlist_bl_node *) first = 0x0 =  -> NULL)
static inline struct hlist_bl_head *d_hash(const struct dentry *parent,
                    unsigned int hash)
{
    hash += (unsigned long) parent / L1_CACHE_BYTES;
    hash = hash + (hash >> D_HASHBITS);
    return dentry_hashtable + (hash & D_HASHMASK);
}

0xC17C8200 란 주소와 이 리스트의 구조체만 가지고 리스트의 내용을 깔 수가 있는데 다음에 찾자.

파워 관리 관점에서 안드로이드 디바이스는 간단히 두 가지 상태로 분류할 수 있다. 수면(Deep Sleep)과 깨어난(Wake)이다.

Sleep은 최소한의 파워 리소스를 사용하여 디바이스를 사용할 수 있는 상태이며, Wake는 프로세서 및 대부분의 파워 리소스가 사용을 하여 어떤 작업을 하고 있는 상태이다.  그런데, Wakelock은 디바이스별로 Sleep상태에서 깨우거나 Sleep상태로 들어가는 것을 막을 수 있는 기능이다.

PWL(Partial Wakelock)은 흔히 유저 스패이스에서 구동되고 있는 앱에서 일어나는 wakelock을 의미하며 일어나는 상황 역시 데이터 동기화, 영상 재생 중 화면 꺼짐 방지 등으로 다양하다. 앱을 설치할 때 퍼미션을 살펴보면 시스템 도구 항목 아래 절전 모드로 진입하는 것을 방지한다라고 명시된 부분이 wakelock을 뜻한다. 앱개발 시 WAKE_LOCK이란 퍼미션을 요청해야 하며 허락될 경우 필요한 때에 따라 Sleep상태로 들어가는 것을 방지할 수 있다.

가끔 오랜 시간동안 화면이 꺼져 있어도 디바이스가 Wake 상태였던 것을 종종 확인할 수 있다. 화면이 꺼져 있으며 유저가 디바이스를 사용하고 있지 않지만 wakelock을 통해 프로세서가 활성화되어 필요한 작업을 하고 있다는 것이다.  예를 들어, 특정 앱에서 작업을 스케줄 해둘 경우 시간에 맞춰 작업을 진행하고 끝날 때까진 Wake 상태를 유지한다. Sleep상태에선 최소한의 자원을 이용하지만 Wake 상태에선 파워 리소스를 사용해야 한다. 즉, 배터리를 더 소모한다는 것이다.

가끔 아래와 같이 printk를 추가해서 로그를 보려고 빌드를 하면, 컴파일러가 아래와 같이 에러를 토해내고 컴파일이 중지되는 경우가 있다.
printk("=====!!!!!current task[%s]=======\n", current->comm);

/android/kernel/arch/arm/mach-tegra/timer.c:111:58: error: dereferencing pointer to incomplete type
make[3]: *** [arch/arm/mach-tegra/timer.o] Error 1
make[2]: *** [arch/arm/mach-tegra] Error 2
make[2]: *** Waiting for unfinished jobs....
  CHK     kernel/config_data.h
make[1]: *** [sub-make] Error 2

printk("=====!!!!!current task[%s]=======\n", current->comm);

이 때는 아래와 같은 해더 파일을 추가하면 된다.
#include <linux/sched.h>

printk("[callstack %s,%d] task[%s]========= \n", __func__,__LINE__, current->comm);

안드로이드에서 wake lock이란 기능이 있습니다. 그런데 대부분 wake lock을 어떤 모듈이 잡고 있어서 슬립에 못 들어가는 문제가 생기죠. 이럴 때 프로파일링하면 좋은 디버그 패치를 소개합니다.