Gomdol Kim

Quite interesting patch was released under the following url.
https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?h=rel/msm-3.18&id=a0039b1e721b7b3ee1cbe7f7f9d44d451ac74543

The detailed patch is to initialize the stack array with a different way as below.
usb : dwc3: Initialize kernel stack variables properly
If kernel stack variables are not initialized properly,
there is a chance of kernel information disclosure.
So, initialize kernel stack variables with null characters.

-rw-r--r-- drivers/usb/dwc3/debugfs.c 10 
1 files changed, 4 insertions, 6 deletions
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index ce7cd96..fb252ec 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -402,7 +402,7 @@ static ssize_t dwc3_mode_write(struct file *file,
struct dwc3 *dwc = s->private;
unsigned long flags;
u32 mode = 0;
- char buf[32];
+ char buf[32] = {0};

if (copy_from_user(&buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
return -EFAULT;
@@ -482,7 +482,7 @@ static ssize_t dwc3_testmode_write(struct file *file,
struct dwc3 *dwc = s->private;
unsigned long flags;
u32 testmode = 0;
- char buf[32];
+ char buf[32] = {0};

if (copy_from_user(&buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
return -EFAULT;
@@ -589,7 +589,7 @@ static ssize_t dwc3_link_state_write(struct file *file,
struct dwc3 *dwc = s->private;
unsigned long flags;
enum dwc3_link_state state = 0;
- char buf[32];
+ char buf[32] = {0};

if (copy_from_user(&buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
return -EFAULT;
@@ -630,12 +630,10 @@ static ssize_t dwc3_store_ep_num(struct file *file, const char __user *ubuf,
{
struct seq_file *s = file->private_data;
struct dwc3 *dwc = s->private;
- char kbuf[10];
+ char kbuf[10] = {0};
unsigned int num, dir, temp;
unsigned long flags;

- memset(kbuf, 0, 10);
-
if (copy_from_user(kbuf, ubuf, count > 10 ? 10 : count))
return -EFAULT;

In order to find out how the assemble code is updated after compling the patch-set, let me walk through more within dwc3_mode_write() .
The interesting debug information inside updated assemble code after "char buf[32] = {0};" is declared is that memset is appended by ARM-GCC compiler
[1]: R1 is updated as 0x0.
[2]: R2 is updated as 32 in decimal format.
[3]: R0 is belonging to stack memory area.
[4]: Call to memset is made.
memset(R0: buf, R1: 0x0, R2: 32)

[After]
static ssize_t dwc3_mode_write(struct file *file,
const char __user *ubuf, size_t count, loff_t *ppos)
{
c0629d9c: e1a0c00d mov ip, sp
c0629da0: e92ddbf0 push {r4, r5, r6, r7, r8, r9, fp, ip, lr, pc}
c0629da4: e24cb004 sub fp, ip, #4
c0629da8: e24dd028 sub sp, sp, #40 ; 0x28
c0629dac: e52de004 push {lr} ; (str lr, [sp, #-4]!)
c0629db0: ebe7958c bl c000f3e8 <__gnu_mcount_nc>
c0629db4: e59f7130 ldr r7, [pc, #304] ; c0629eec <dwc3_mode_write+0x150>
c0629db8: e1a04001 mov r4, r1
c0629dbc: e1a05002 mov r5, r2
c0629dc0: e3a01000 mov r1, #0 //<<--[1]
c0629dc4: e3a02020 mov r2, #32 //<<--[2]
c0629dc8: e5973000 ldr r3, [r7]
c0629dcc: e50b3028 str r3, [fp, #-40] ; 0xffffffd8
c0629dd0: e59030bc ldr r3, [r0, #188] ; 0xbc
c0629dd4: e24b0048 sub r0, fp, #72 ; 0x48 //<<--[3]
c0629dd8: e5936060 ldr r6, [r3, #96] ; 0x60 
c0629ddc: ebf2ec6f bl c02e4fa0 <memset> //<<--[4] 
c0629de0: e1a0200d mov r2, sp 
c0629de4: e3c21d7f bic r1, r2, #8128 ; 0x1fc0

[Before]
[1]: Assemble code before the patch is applied, the stack memory location mapped to buf[32] is saved into R0 without initilization. 
static ssize_t dwc3_mode_write(struct file *file,
const char __user *ubuf, size_t count, loff_t *ppos)
{
c0629d9c: e1a0c00d mov ip, sp
c0629da0: e92ddbf0 push {r4, r5, r6, r7, r8, r9, fp, ip, lr, pc}
c0629da4: e24cb004 sub fp, ip, #4
c0629da8: e24dd028 sub sp, sp, #40 ; 0x28
c0629dac: e52de004 push {lr} ; (str lr, [sp, #-4]!)
c0629db0: ebe7958c bl c000f3e8 <__gnu_mcount_nc>
c0629db4: e1a05002 mov r5, r2
//.. skip ,,
c0629dfc: 1a000005 bne c0629e18 <dwc3_mode_write+0x7c>
c0629e00: e24b0048 sub r0, fp, #72 ; 0x48 //<<--[1]
c0629e04: e1a02003 mov r2, r3
c0629e08: ebf2e301 bl c02e2a14 <__copy_from_user>
c0629e0c: e3500000 cmp r0, #0

Let me make it a rule to initialize the stack array like char kbuf[10] = {0}; instead of char kbuf[10];

Debugging

"ndroid.systemui" 프로세스가 raw_spin_lock_irqsave() API 동작 중에 aee_wdt_atf_entry() Trigger

-000|aee_wdt_atf_entry()
-001|prefetchw(inline)
-001|arch_spin_lock(inline)
-001|do_raw_spin_lock_flags(inline)
-001|__raw_spin_lock_irqsave(inline)
-001|raw_spin_lock_irqsave(lock = 0xDD82725C)
-002|__wake_up(q = 0xDD82725C, mode = 1, nr_exclusive = 1, key = 0x0)
-003|mmc_wait_data_done
-004|msdc_irq_data_complete(host = 0xDD827280, ?, error = 0)
-005|msdc_irq(?, dev_id = 0xDD13B9C8)
-006|static_key_count(inline)
-006|static_key_false(inline)
-006|trace_irq_handler_exit(inline)
-006|handle_irq_event_percpu(?, action = 0xDD13B9C8)
-007|handle_irq_event(desc = 0xC0F38440)
-008|cond_unmask_eoi_irq(inline)
-008|handle_fasteoi_irq(?, desc = 0xC0F38440)
-009|static_key_count(inline)
-009|static_key_false(inline)
-009|trace_irq_exit(inline)
-009|__handle_domain_irq(domain = 0xDE806000, hwirq = 111, lookup = TRUE, ?)
-010|__raw_readl(inline)
-010|gic_handle_irq(regs = 0xDD13BFB0)
-011|__irq_usr(asm)

@ spinlock이 release되어 spinlock 변수가 [owner: 0x56AC, next: 0x56AD]로 업데이트되기까지 기다림.

(raw_spinlock_t *)0xDD82725C = 0xDD82725C -> (
raw_lock = (
slock = 0x56AD56AB,
tickets = (
owner = 0x56AB, // <<--
next = 0x56AD))) // <<--

@ 0xDD82725C spinlock 변수 주소를 누가 접근하는 지 검색해보면.

(where)
(raw_spinlock_t *)0xDD82725C
c2d01b78: dd82725c
c2d01b7c: dd82725c
c44f0994: dd82725c
dd13bd60: dd82725c // "ndroid.systemui"
dd13bd9c: dd82725c // "ndroid.systemui"
dd13bdc8: dd82725c // "ndroid.systemui"
ddbefdb8: dd82725c // <<--"mmcqd/0"
ddbefdd0: dd82725c
e0abd994: dd82725c

"mmcqd/0" 프로세스가 접근함을 알 수 있음

v.v % (struct thread_info*)(0xDDBEFDB8 & ~0x1fff)
(long unsigned int) swap_in = 0 = 0x0 = '....',
(long unsigned int) swap_out = 0 = 0x0 = '....',
(struct task_cputime) cputime_expires = ((cputime_t) utime = 0 = 0x0 = '....', (cputime_t) stime = 0 = 0x0 = '....', (long lo
(struct list_head [3]) cpu_timers = ([0] = ((struct list_head *) next = 0xDDB49A08 = -> ((struct list_head *) next = 0xDDB49
(struct cred *) real_cred = 0xDDB71200 = -> ((atomic_t) usage = ((int) counter = 2 = 0x2 = '....'), (kuid_t) uid = ((uid_t)
(struct cred *) cred = 0xDDB71200 = -> ((atomic_t) usage = ((int) counter = 2 = 0x2 = '....'), (kuid_t) uid = ((uid_t) val =
(char [16]) comm = "mmcqd/0",

@ "mmcqd/0" 프로세스 콜스택

-000|schedule()
-001|mmc_wait_for_data_req_done(inline)
-001|mmc_start_req(host = 0xC0F75D0C, areq = 0xC0F644E0, error = 0xC102CB08)
-002|mmc_blk_issue_rw_rq(mq = 0xDDB64408, rqc = 0x0)
-003|mmc_blk_issue_rq(mq = 0xDDB64408, req = 0x0)
-004|mmc_queue_thread(d = 0xDDB64408)
-005|kthread(_create = 0xDDB8BDC0)
-006|ret_from_fork(asm)
-007|ret_fast_syscall(asm)

@ 코드를 가보면, spin_lock_irqsave(&context_info->lock, flags); API를 통해 lock을 걸고 있음

static int mmc_wait_for_data_req_done(struct mmc_host *host,
struct mmc_request *mrq,
struct mmc_async_req *next_req)
{
    struct mmc_command *cmd;
    struct mmc_context_info *context_info = &host->context_info;
    int err;
    unsigned long flags;
    while (1) {
        wait_event_interruptible(context_info->wait,
                                               (context_info->is_done_rcv ||
                                               context_info->is_new_req));
        spin_lock_irqsave(&context_info->lock, flags);
        context_info->is_waiting_last_req = false;

@ Watchdog Reset이 trigger된 "ndroid.systemui" 프로세스 콜 스택에 아래 함수들이 있었음

-003|mmc_wait_data_done
-004|msdc_irq_data_complete(host = 0xDD827280, ?, error = 0)

@ mmc_wait_data_done() 함수를 보면 mrq->host->context_info.is_done_rcv = true로 설정하고,
&mrq->host->context_info.wait wait queue을 깨우는 역할을 수행

static void mmc_wait_data_done(struct mmc_request *mrq){

    mrq->host->context_info.is_done_rcv = true;

     wake_up_interruptible(&mrq->host->context_info.wait);

}

그런데 mmc_wait_for_data_req_done() 함수의 아래 구문은 context_info->is_done_rcv, context_info->is_new_req가 true가
될 때 까지 기다리는 코드다.

wait_event_interruptible(context_info->wait,
(context_info->is_done_rcv ||
context_info->is_new_req));

정리해보면, race condition으로 wake_up_interruptible(&mrq->host->context_info.wait); 함수를 통해 wait_queue에 queue된 
&mrq->host->context_info.wait으로 등록된 프로세스를 깨우기 전에 아래 구문이 풀려버려 이미 깨어버린 경우임을 짐작.

잠을 자고 있는 누군가를 깨우려고 손을 대려고 하는데 이미 깨버린 경우와 비슷하네.

In-depth Analysis

내 추정이 맞다면 아래 코드를 삽입하면 바로 커널 패닉이 나야 한다.

(램덤프 force_mmc_wait_data_done_crash)

static void mmc_wait_data_done(struct mmc_request mrq){*
mrq->host->context_info.is_done_rcv = true;
+ mdelay(1);
wake_up_interruptible(&mrq->host->context_info.wait);
}

그런데 바로 커널 패닉이 발생했다.

-000|do_DataAbort(addr = 0, fsr = 0, regs = 0x0)
-001|__dabt_svc(asm)
-->|exception
-002|debug_spin_lock_before(inline)
-002|do_raw_spin_lock(lock = 0x02B4)
-003|raw_spin_lock_irqsave(lock = 0x02B4)
-004|__wake_up(q = 0x02B4, mode = 1, nr_exclusive = 1, key = 0x0)
-005|mmc_wait_data_done(mrq = 0xDC9725F8)
-006|msdc_irq_data_complete(host = 0xDC919300, ?, error = 0)
-007|msdc_irq(?, dev_id = 0x1)
-008|handle_irq_event_percpu(?, action = 0xDC91E0C0)
-009|handle_irq_event(desc = 0xC121A440)
-010|cond_unmask_eoi_irq(inline)
-010|handle_fasteoi_irq(?, desc = 0xC121A440)
-011|static_key_count(inline)
-011|static_key_false(inline)
-011|trace_irq_exit(inline)
-011|__handle_domain_irq(domain = 0xDE806000, hwirq = 111, lookup = TRUE, ?)
-012|__raw_readl(inline)
-012|gic_handle_irq(regs = 0xCB773E10)
-013|__irq_svc(asm)
-->|exception
-014|current_thread_info(inline)
-014|check_preemption_disabled(what1 = 0xC0F115AC, what2 = 0xC0EE0B28)
-015|debug_smp_processor_id()
-016|MT_trace_preempt_on()
-017|preempt_count_sub
-018|current_thread_info(inline)
-018|preempt_count(inline)
-018|should_resched(inline)
-018|__percpu_counter_add(fbc = 0xD8AC7178, amount = 0, batch = 32)
-019|__sb_start_write(sb = 0xC0F115AC, level = -1058141400, wait = FALSE)
-020|file_start_write(inline)
-020|vfs_write(file = 0xD366C480, buf = 0xBEA83A4C, ?, pos = 0xCB773F78)
-021|SYSC_write(inline)
-021|sys_write(?, buf = -1096271284, count = 146)
-022|ret_fast_syscall(asm)

@mrq->host->context_info.wait 변수를 확인해보면, 이미 mrq->host 변수가 0이다.

(struct mmc_request *)0xDC9725F8 = 0xDC9725F8 -> (
    sbc = 0xDC97262C,
    cmd = 0xDC972660,
    data = 0xDC9726C8,
    stop = 0xDC972694,
    completion = (done = 0x0, wait = (lock = (rlock = (raw_lock = (slock = 0x0,
      done = 0x0,
     host = 0x0)

@어머 그런데, mmcqd/0 프로세스가 mmc_wait_for_data_req_done() 코드를 이미 수행했네?

-000|context_switch(inline)
-000|__schedule()
-001|schedule()
-002|mmc_wait_for_data_req_done(inline)
-002|mmc_start_req(host = 0xDC919000, areq = 0xDC972710, ?)
-003|mmc_blk_issue_rw_rq(mq = 0x0, rqc = 0xC64B18C0)
-004|mmc_blk_issue_rq(mq = 0xDC972494, req = 0xC64B18C0)
-005|mmc_queue_thread(d = 0xDC972494)
-006|kthread(_create = 0xDCA24E40)
-007|ret_from_fork(asm)
-008|ret_fast_syscall(asm)

@ftrace log를 좀 더 추가해보자.

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index db74413..fcf6692 100644
? a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1034,6 +1034,9 @@ out:
}
EXPORT_SYMBOL(mmc_start_bkops);
#endif
/*
mmc_wait_data_done() - done callback for data request
@mrq: done data request
@@ -1042,10 +1045,25 @@ EXPORT_SYMBOL(mmc_start_bkops);
*/
static void mmc_wait_data_done(struct mmc_request *mrq)
static void mmc_wait_data_done(struct mmc_request mrq) *{
        mrq->host->context_info.is_done_rcv = true;

+      trace_printk("+msdc [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0));
        mdelay(1);
+      trace_printk("++msdc [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0));
        wake_up_interruptible(&mrq->host->context_info.wait);
+      trace_printk("--msdc [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0));

 

@ 역시나 GIC mtk-msdc(111) IRQ가 Trigger된 다음에 아래와 같이 커널 패닉이 발생함

(램덤프: neo_more_crash_ftrace)

-000|do_DataAbort(addr = 0, fsr = 0, regs = 0x0)
-001|__dabt_svc(asm)
-->|exception
-002|debug_spin_lock_before(inline)
-002|do_raw_spin_lock(lock = 0x02B4)
-003|raw_spin_lock_irqsave(lock = 0x02B4)
-004|__wake_up(q = 0x02B4, mode = 1, nr_exclusive = 1, key = 0x0)
-005|mmc_wait_data_done(mrq = 0xDC9235F8)
-006|msdc_irq_data_complete(host = 0xDC927300, ?, error = 0)
-007|msdc_irq(?, dev_id = 0x1)
-008|handle_irq_event_percpu(?, action = 0xDC92B180)
-009|handle_irq_event(desc = 0xC121A440)
-010|cond_unmask_eoi_irq(inline)
-010|handle_fasteoi_irq(?, desc = 0xC121A440)
-011|static_key_count(inline)
-011|static_key_false(inline)
-011|trace_irq_exit(inline)
-011|__handle_domain_irq(domain = 0xDE806000, hwirq = 111, lookup = TRUE, ?)
-012|__raw_readl(inline)
-012|gic_handle_irq(regs = 0xC2631E20)
-013|__irq_svc(asm)
-->|exception
-014|__fget(?, mask = 16384)
-015|__fget_light(?, mask = 16384)
-016|__fdget
-017|sockfd_lookup_light(?, err = 0xC2631EC8, fput_needed = 0xC2631ECC)
-018|SYSC_recvfrom(inline)
-018|sys_recvfrom(?, ubuf = -1212542344, ?, flags = 64, addr = 0, addr_len = 0)
-019|ret_fast_syscall(asm)

 

@ Ftrace log 분석
커널 패닉이 일어나기 직전 상황

[1]: irq=111 name=mtk-msdc 가 Trigger됨
[2]: IRQ context에서 mmc_wait_data_done() 함수가 호출 from(msdc_irq_data_complete)
[2]~[3] 사이 mmcq0 process가 context switching 되지 않고 수행 ( InputDispatcher-1538)
[3]: mdelay(1); 이후 찍히는 ftrace log
[4]: wake_up_interruptible(&mrq->host->context_info.wait); API 호출로 mmcq0 process을 wakeup 시킴
CPU5: mmcqd/0, pid=244
sched_wakeup: comm=mmcqd/0 pid=244 prio=120 success=1 target_cpu=005 state=W
[5]: wake_up_interruptible(&mrq->host->context_info.wait); API 호출이 끝난 후 찍히는 로그(별 의미 없음)

kworker/4:0-25 [004] 149.827488: irq_handler_entry: irq=111 name=mtk-msdc // <<--[1]
kworker/4:0-25 [004] 149.827495: bprint: mmc_wait_data_done: +msdc [F: mmc_wait_data_done, L:1049]: ? ? from(msdc_irq_data_complete) // <<--[2]
InputDispatcher-1538 [005] 149.827496: sched_migrate_task: comm=m.lge.launcher3 pid=2135 prio=120 orig_cpu=6 dest_cpu=4 state=W
InputDispatcher-1538 [005] 149.827519: sched_wakeup: comm=m.lge.launcher3 pid=2135 prio=120 success=1 target_cpu=004 state=W
InputDispatcher-1538 [005] 149.827591: sched_migrate_task: comm=ndroid.systemui pid=1622 prio=120 orig_cpu=5 dest_cpu=6 state=W
InputDispatcher-1538 [005] 149.827608: sched_wakeup: comm=ndroid.systemui pid=1622 prio=120 success=1 target_cpu=006 state=W
InputDispatcher-1538 [005] 149.827675: sched_migrate_task: comm=android.ui pid=1287 prio=118 orig_cpu=4 dest_cpu=6 state=W
InputDispatcher-1538 [005] 149.827694: sched_wakeup: comm=android.ui pid=1287 prio=118 success=1 target_cpu=006 state=W
InputDispatcher-1538 [005] 149.827855: sched_switch: prev_comm=InputDispatcher prev_pid=1538 prev_prio=112 prev_state=S ==> next_comm=swapper/5 next_pid=0 next_prio=120 extra_prev_state=K|m|d 
<idle>-0 [005] 149.827912: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=InputDispatcher next_pid=1538 next_prio=112 extra_prev_state=K|m|d 
InputDispatcher-1538 [005] 149.828064: sched_switch: prev_comm=InputDispatcher prev_pid=1538 prev_prio=112 prev_state=S ==> next_comm=swapper/5 next_pid=0 next_prio=120 extra_prev_state=K|m|d 
<idle>-0 [005] 149.828209: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=InputDispatcher next_pid=1538 next_prio=112 extra_prev_state=K|m|d 
InputDispatcher-1538 [005] 149.828352: sched_switch: prev_comm=InputDispatcher prev_pid=1538 prev_prio=112 prev_state=S ==> next_comm=swapper/5 next_pid=0 next_prio=120 extra_prev_state=K|m|d 
kworker/4:0-25 [004] 149.828497: bprint: mmc_wait_data_done: ++msdc [F: mmc_wait_data_done, L:1058]: ? ? from(msdc_irq_data_complete) // <<--[3]
kworker/4:0-25 [004] 149.828521: sched_wakeup: comm=mmcqd/0 pid=244 prio=120 success=1 target_cpu=005 state=W // <<--[4]
kworker/4:0-25 [004] 149.828525: bprint: mmc_wait_data_done: -msdc [F: mmc_wait_data_done, L:1060]: ? ? from(msdc_irq_data_complete) <<-[5]
<idle>0 [005] 149.828528: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=mmcqd/0 next_pid=244 next_prio=120 extra_prev_state=K|m|d <<-[6]
kworker/4:0-25 [004] 149.828530: irq_handler_exit: irq=111 ret=handled

 

1046 static void mmc_wait_data_done(struct mmc_request *mrq)
1047*{*
1048 mrq->host->context_info.is_done_rcv = true;
1049 trace_printk("+msdc [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0)); // <<--[2]
//생략
1051 mdelay(1);
//생략
1057
1058 trace_printk("++msdc [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0)); // <<--[3]
1059 wake_up_interruptible(&mrq->host->context_info.wait);
1060 trace_printk("-msdc [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0)); // <<-[5]

커널 패닉 상황
[7]: irq=111 name=mtk-msdc 가 handle 되었음
[8]: [mmcqd/0-244, CPU5]mmc_wait_for_data_req_done() 함수 내[from(mmc_blk_issue_rw_rq)] wait_event_interruptible()에서 빠져나옴.
[9][10]: [mmcqd/0-244, CPU5]mmc_wait_for_data_req_done() 함수를 빠져나옴
[11]: irq=111 name=mtk-msdc 가 Trigger됨 --> CPU4의 m.lge.launcher3-2135
[12]: [mmcqd/0-244, CPU5] 깨어난 mmcqd/0-244 프로세스 활동 시작
&mqrq->brq 변수를 0으로 밀어버림 (where: memset(brq, 0, sizeof(struct mmc_blk_request));
[13]: [m.lge.launcher3-2135 CPU4] irq=111 name=mtk-msdc IRQ로 Trigger되어 실행되어
mmc_wait_data_done() 함수 진입 
[14][15]: [mmcqd/0-244, CPU5] mmc_blk_rw_rq_prep() 함수 퇴장하려함
[16][17][18] [mmcqd/0-244, CPU5] mmc_wait_for_data_req_done() 함수 처리 후 퇴장하려함
[19]: [m.lge.launcher3-2135 CPU4] wake_up_interruptible(&mrq->host->context_info.wait);
[20] 커널 패닉
[12]번 동작에서 0으로 초기화된 &mrq->host 변수를 통해 밀린((where: memset(brq, 0, sizeof(struct mmc_blk_request)) wake_up_interruptible() API 호출

kworker/4:0-25 [004] 149.828530: irq_handler_exit: irq=111 ret=handled // <<--[7]
mmcqd/0-244 [005] 149.828536: bprint: mmc_start_req: ++mmcq [F: mmc_wait_for_data_req_done, L:1236]: ? ? from(mmc_blk_issue_rw_rq) // <<--[8]
kworker/4:0-25 [004] 149.828537: irq_handler_entry: irq=30 name=arch_timer
kworker/4:0-25 [004] 149.828546: irq_handler_exit: irq=30 ret=handled
mmcqd/0-244 [005] 149.828559: bprint: mmc_start_req: mmcq [F: mmc_wait_for_data_req_done, L:1268]: ? ? from(mmc_blk_issue_rw_rq) // <<-[9]
mmcqd/0-244 [005] 149.828561: bprint: mmc_start_req: mmcq release [F: mmc_wait_for_data_req_done, L:1270]: ? ? from(mmc_blk_issue_rw_rq) // <<--[10]
kworker/4:0-25 [004] 149.828584: workqueue_execute_end: work struct 0xcb40cae4
kworker/4:0-25 [004] 149.828630: sched_switch: prev_comm=kworker/4:0 prev_pid=25 prev_prio=120 prev_state=S ==> next_comm=m.lge.launcher3 next_pid=2135 next_prio=120 extra_prev_state=K|m|d 
m.lge.launcher3-2135 [004] 149.828660: irq_handler_entry: irq=111 name=mtk-msdc // <<--[11]
mmcqd/0-244 [005] 149.828661: bprint: mmc_blk_rw_rq_prep: ++mmc_blk_rw_rq_prep [F: mmc_blk_rw_rq_prep, L:1725]: ? ? from(mmc_blk_issue_rw_rq) // <<--[12]
m.lge.launcher3-2135 [004] 149.828666: bprint: mmc_wait_data_done: +msdc [F: mmc_wait_data_done, L:1049]: ? ? from(msdc_irq_data_complete) // <<--[13]
mmcqd/0-244 [005] 149.828670: bprint: mmc_blk_rw_rq_prep: -mmc_blk_rw_rq_prep [F: mmc_blk_rw_rq_prep, L:1905]: ? ? from(mmc_blk_issue_rw_rq) // <<-[14]
mmcqd/0-244 [005] 149.828672: bprint: mmc_blk_rw_rq_prep: mmc_blk_rw_rq_prep [F: mmc_blk_rw_rq_prep, L:1907]: ? ? from(mmc_blk_issue_rw_rq) // <<-[15]
mmcqd/0-244 [005] 149.828681: bprint: mmc_start_req: +mmcq [F: mmc_wait_for_data_req_done, L:1231]: ? ? from(mmc_blk_issue_rw_rq) // <<--[16]
mmcqd/0-244 [005] 149.828683: bprint: mmc_start_req: ++mmcq [F: mmc_wait_for_data_req_done, L:1236]: ? ? from(mmc_blk_issue_rw_rq) // <<--[17]
mmcqd/0-244 [005] 149.828695: bprint: mmc_start_req: -mmcq [F: mmc_wait_for_dat뗥nQ, L:0]: ? ? from(0x726f776bS) // <<--[18]
m.lge.launcher3-2135 [004] 149.829669: bprint: mmc_wait_data_done: ++msdc [F: mmc_wait_data_done, L:1058]: ? ? from(msdc_irq_data_complete) // <<--[19]
m.lge.launcher3-2135 [004] 149.829748: tracing_on: ftrace is disabled caller=oops_enter // <<–[20]

1222 static int mmc_wait_for_data_req_done(struct mmc_host *host,
1223 struct mmc_request *mrq,
1224 struct mmc_async_req *next_req)
1225*{*
1226 struct mmc_command *cmd;
1227 struct mmc_context_info *context_info = &host->context_info;
1228 int err;
1229 unsigned long flags;
1230
1231 trace_printk("+mmcq [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0)); // <<--[16]
1232 while (1) {
1233 wait_event_interruptible(context_info->wait,
1234 (context_info->is_done_rcv ||
1235 context_info->is_new_req));
1236 trace_printk("++mmcq [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0)); // <<--[8], [17]
1237 spin_lock_irqsave(&context_info->lock, flags);
//snip
1268 trace_printk("mmcq [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0)); // <<-[9], [18]
1269 mmc_retune_release(host);
1270 trace_printk("mmcq release [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0));
1271 return err;
1272 }

1701 static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
1702 struct mmc_card *card,
1703 int disable_multi,
1704 struct mmc_queue *mq)
1705*{*
1706 u32 readcmd, writecmd;
1707 struct mmc_blk_request *brq = &mqrq->brq;
//생략
1724 memset(brq, 0, sizeof(struct mmc_blk_request));
1725 trace_printk("++mmc_blk_rw_rq_prep [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0)); // <<--[12]
1726 brq->mrq.cmd = &brq->cmd;
//생략
1905 trace_printk("-mmc_blk_rw_rq_prep [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0)); //<<-[14]
1906 mmc_queue_bounce_pre(mqrq);
1907 trace_printk("-mmc_blk_rw_rq_prep [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0));
1908 }

1046 static void mmc_wait_data_done(struct mmc_request *mrq)
1047*{*
1048 mrq->host->context_info.is_done_rcv = true;
1049 trace_printk("+msdc [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0)); // <<--[13]
//생략
1051 mdelay(1);
//생략
1057
1058 trace_printk("++msdc [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0)); // <<--[19]
1059 wake_up_interruptible(&mrq->host->context_info.wait);
1060 trace_printk("--msdc [F: %s, L:%d]: ? ? from(%pS)\n", _func,LINE, (void *)_builtin_return_address(0));

정리하면 wake_up_interruptible() API에 파라미터로 전달되는 &mrq->host->context_info.wait를 다른 값(mmcqd를 깨울 수 있는 wait_queue)으로 바꾸거나,
wake_up_interruptible() 호출 시 조건을 줘야 한다. 혹은 spinlock irq save로 코드 보호

솔류션
가능 패치 1건: mrq->host->context_info.is_done_rcv; wake_up_interruptible(&mrq->host->context_info.wait); 처리 도중 MSDC irq가
trigger되었으므로 아래아 같이 spinlock irq save로 보호

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 347108a..21b7307 100644
? a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1042,8 +1042,10 @@ EXPORT_SYMBOL(mmc_start_bkops);
*/
static void mmc_wait_data_done(struct mmc_request *mrq)
{*
+    spin_lock_irqsave(&context_info->lock, flags);
     mrq->host->context_info.is_done_rcv = true;
     wake_up_interruptible(&mrq->host->context_info.wait);
+   spin_unlock_irqrestore(&context_info->lock, flags);
}

가능 패치 2건: wake_up_interruptible() 호출 시 조건을 줌. 패치가 허접해 보임.

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 347108a..ea832709 100644
? a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1043,7 +1043,8 @@ EXPORT_SYMBOL(mmc_start_bkops);
static void mmc_wait_data_done(struct mmc_request *mrq)
{
    mrq->host->context_info.is_done_rcv = true;
    wake_up_interruptible(&mrq->host->context_info.wait);
+  if (mrq->host)
+       wake_up_interruptible(&mrq->host->context_info.wait);
}

http://lge.lglifecare.com/Pages/Common/ShopDefault.aspx

NUMA SMP 시스템의 클러스터들 사이에 있는 버스에서는 SCI (scalable coherent interface) 기술을 사용하여 데이터가 움직인다. SCI는 다중 클러스터의 노드에 걸쳐 캐시 일관성이라고 불리는 것과 대등하다.

SMP와 NUMA 시스템은 대체로 공통의 데이터베이스 상에 집단적으로 작업하는 많은 수의 프로세서들에게, 작업 처리를 분담시킬 수 있는 데이터 마이닝과 의사결정 시스템 등과 같은 분야에 사용된다. 시퀀트, 데이터제너럴, NCR 등이 NUMA SMP 시스템을 생산하는 회사들이다.

• Keith Kirkpatrick은 The Move to NUMA에 관해 그림으로 설명한 기사를 제공합니다.
• 시퀀트는 CC-NUMA 시스템의 이행과 성능에 관한 백서를 제공합니다.

-------------

불균일 기억 장치 접근(Non-Uniform Memory Access, NUMA)는 멀티프로세서 시스템에서 사용되고 있는 컴퓨터 메모리 설계 방법중의 하나로, 메모리에 접근하는 시간이 메모리와 프로세서간의 상대적인 위치에 따라 달라진다. NUMA구조에서 프로세서는 자기의 로컬 메모리에 접근할 때가 원격 메모리에 접근할 때보다 더 빠르다. 원격 메모리는 다른 프로세서에 연결되어 있는 메모리를 말하고 로컬 메모리는 자기 프로세서에 연결되어 있는 메모리를 말한다.

NUMA 아키텍처는 이론적으로 SMP아키텍처로부터 확장된 개념이다. Burroughs large systems에 의해서 첫 상용화되었으며 이후 유니시스, Convex Computer(이후 휴렛 패커드), 실리콘 그래픽스, Sequent Computer Systems, Data General 그리고 DEC에서 상품화되었다. 이러한 회사들이 개발해 놓은 기술들은 유닉스 계열 운영 체제에 도입되었으며 일부는 윈도 NT에도 도입되었다.

기본 개념

NUMA 시스템의 한예. 프로세서들은 버스나 크로스바로 연결되어 있음을 주목하세요. 각각의 프로세서들은 그 위치에 따라 메모리에 접근하는 우선순위가 다름을 보여준다.

현대의 CPU는 주 메모리보다 훨씬 빠르게 동작한다. 그렇지만 컴퓨터 초기에는 CPU는 일반적으로 메모리보다 천천히 동작을 했다. 1960년대에 첫 슈퍼컴퓨터와 고속 컴퓨터가 개발되면서 역전이 되었다. 그 이후, 계속해서 데이터를 더 많이 사용해야 하는 CPU는 메모리에서 데이터를 다 가지고 올 때까지 기다려야 했다. 1980년대와 1990년대에 개발된 많은 슈퍼컴퓨터는 빠르게 메모리에 접근하는 방법을 제공했고 이것으로 대용량 데이터 집합에 대한 처리를 그 어떤 다른 시스템들보다 빠르게 할 수 있었다.

메모리에 접근하는 경우의 수를 줄이는 것이 현대 컴퓨터에서 성능을 높이는 한 방법이다. 예를 들면, 고속의 캐시 메모리를 지속적으로 증가시키는 것과 캐시 미스를 줄이기 위한 뛰어난 알고리즘을 사용하는 것이다. 그렇지만 운영체제 크기의 비약적인 증가와 그 위에서 돌아가는 애플리케이션 크기의 증가는 캐시를 통한 성능 향상을 압도하게 된다. 특히나 다중 프로세서 시스템에서는 이 문제가 더 심각하다. 하나의 프로세서만이 메모리에 접근할 수 있기 때문에 많은 다른 프로세서들은 기다려야만 하기 때문이다.

NUMA는 각각의 프로세서에 독립적인 별도의 메모리를 제공함으로써 이러한 문제를 해결하려 한다. 이렇게 하면 여러 프로세서들이 동일 메모리 주소에 접근하려 할때 성능 충돌을 피할 수 있다. 서버와 애플리케이션에서 아주 일반적인 펼쳐진 데이터를 처리하는 문제의 경우에, NUMA는 하나의 공유 메모리의 경우 대비 대략적으로 프로세서의 수나 아니면 메모리 뱅크수 만큼 성능을 향상시킬 수 있다. 그렇지만 하나 이상의 프로세서가 동일 데이터를 필요로 하는 경우에 NUMA시스템은 메모리 뱅크들 사이로 데이터를 이동시켜야 하는 경우가 발생한다. 이러한 동작은 NUMA의 성능을 떨어뜨리는 요인이다. 따라서 전반적인 성능은 주어진 시간에 동작하고 있는 일의 특성에 달려있다. 어떻게 프로세스가 원격 메모리 대신 로컬 메모리를 사용하게 하느냐가 프로그램의 최적화에 대한 문제이다.

캐시 일관성 NUMA (ccNUMA)

거의 모든 CPU 아키텍처는 CPU캐시라고 알려진 적은 양의 매우 빠른 비공유 메모리를 사용한다. NUMA환경에서 공유 메모리의 캐시 일관성을 유지시키는 것은 상당히 어려운 작업이다. 비록 캐시 일관성을 제공하지 않는 NUMA아키텍처는 설계와 제작이 용이하지만 현재의 폰 노이만 구조 프로그래밍 모델에서는 프로그래밍을 하기가 매우 어렵다. 따라서 현재 시장에 판매되고 있는 모든 NUMA 컴퓨터들은 캐시 일관성을 제공한다. 이것을 ccNUMA(cache-coherent NUMA)라고 분류한다.

인텔은 2007년 후반에 x86과 아이테니엄 서버에서 네할렘 마이크로아키텍처 기반 프로세서와 투킬라 프로세서에서부터 NUMA 아키텍처를 적용했다.^[1] 프로세서들간의 연결은 인텔 퀵패스 인터커넥트(QPI)를 통하여 이루어진다.^[2]

NUMA 대 클러스터 컴퓨팅

어떤사람들은 NUMA를 매우 가깝게 연결된 컴퓨터 클러스터이라고 본다. 클러스터 아키텍처에 가상 메모리 페이징을 도입하면 NUMA가 아닌 하드웨어에서 순전히 소프트웨어적으로 구현이 가능하다. 그렇지만 노드간의 레이턴시(대기시간,Latency)는 하드웨어 기반의 NUMA보다 수십배 이상 느리다.

-----------------

NUMA 개념

작은 프로세서 집합에 사용되는 시스템 버스를 여러 개 구성하는 것이 일반적인 하드웨어 추세입니다. 각 프로세서 그룹에는 자체 메모리가 있으며 자체 I/O 채널이 있는 경우도 있습니다. 그러나 각 CPU는 일관된 방법으로 다른 그룹과 연결된 메모리에 액세스합니다. 각 그룹을 NUMA 노드라고 합니다. NUMA 노드 내의 CPU 수는 하드웨어 공급업체에 따라 다릅니다. 다른 NUMA 노드와 연결된 메모리보다 로컬 메모리를 액세스하는 것이 더 빠릅니다. 이러한 이유로 Non-Uniform Memory Access, 즉 NUMA 아키텍처라고 명명되었습니다.

NUMA 하드웨어에서는 일부 메모리 영역이 실제로 나머지 영역과 다른 버스에 있습니다. NUMA는 로컬 메모리와 외부 메모리를 사용하므로 다른 영역에 비해 일부 메모리 영역에 액세스하는 시간이 오래 걸립니다. 로컬 메모리와 외부 메모리라는 용어는 대개 현재 실행 중인 스레드에 대한 참조에 사용됩니다. 로컬 메모리는 현재 스레드를 실행 중인 CPU와 같은 노드에 있는 메모리입니다. 스레드가 현재 실행 중인 노드에 속하지 않는 메모리는 외부 메모리입니다. 외부 메모리를 원격 메모리라고도 합니다. 로컬 메모리 액세스 비용에 대한 외부 메모리 액세스 비용의 비율을 NUMA 비율이라고 합니다. NUMA 비율이 1이면 이는 SMP(대칭 다중 처리)입니다. 비율이 높을수록 다른 노드의 메모리에 액세스하는 데 더 많은 비용이 소요됩니다. SQL Server 2000 SP3 이전 버전을 포함하여 NUMA를 인식하지 않는 Windows 응용 프로그램은 경우에 따라 NUMA 하드웨어에서 제대로 작동하지 않습니다.

NUMA의 주된 이점은 확장성입니다. NUMA 아키텍처는 SMP 아키텍처의 확장성 제한을 극복하기 위해 고안되었습니다. SMP를 사용하면 모든 메모리 액세스가 같은 공유 메모리 버스에 게시됩니다. CPU 수가 비교적 적을 때는 문제가 없지만 공유 메모리 버스 액세스를 위해 수십 개나 수백 개의 CPU가 경쟁할 경우에는 이 기능이 제대로 작동하지 않습니다. NUMA는 특정 메모리 버스의 CPU 개수를 제한하고 고속 연결로 여러 개의 노드를 연결하여 이러한 병목 현상을 완화합니다.

하드웨어 NUMA 및 소프트 NUMA

NUMA는 특별한 하드웨어(하드웨어 NUMA)를 통해 또는 SQL Server 메모리(소프트 NUMA)를 구성하여 메모리를 CPU에 대응시킬 수 있습니다. 시작 중에 SQL Server는 기본 운영 체제 및 하드웨어 구성이나 소프트 NUMA 설정에 따라 구성됩니다. 하드웨어 NUMA 및 소프트 NUMA 둘 다에 대해, NUMA 구성에서 SQL Server 시작 시 각 노드에 대한 다중 모드 구성 메시지와 CPU 마스크가 SQL Server 로그에 기록됩니다.

하드웨어 NUMA

SELECT DISTINCT memory_node_idFROM sys.dm_os_memory_clerks

소프트 NUMA

SQL Server에서는 CPU를 소프트 NUMA라는 노드로 그룹화할 수 있습니다. 일반적으로 많은 CPU가 있으며 하드웨어 NUMA가 없는 경우 소프트 NUMA를 구성하지만 소프트 NUMA를 사용하여 하드웨어 NUMA 노드를 더 작은 그룹으로 세분화할 수도 있습니다. SQL Server 스케줄러와 SQL Server 네트워크 인터페이스(SNI)만 소프트 NUMA를 인식합니다. 메모리 노드는 하드웨어 NUMA를 기반으로 생성되므로 소프트 NUMA의 영향을 받지 않습니다. 예를 들어 SMP 컴퓨터에 8개의 CPU가 있으며 각각 두 개의 CPU를 가진 소프트 NUMA 노드 4개를 만들면 메모리 노드 하나에서 4개의 NUMA 노드를 모두 처리합니다. 소프트 NUMA는 메모리에서 CPU로의 선호도를 제공하지 않습니다.

소프트 NUMA는 많은 CPU가 있고 하드웨어 NUMA가 없는 컴퓨터에서 I/O 및 지연 기록기 병목을 완화시키는 이점이 있습니다. 각 NUMA 노드에 대해 I/O 스레드와 지연 기록기 스레드가 각각 하나씩 있습니다. 데이터베이스 사용량에 따라 이러한 단일 스레드는 심각한 성능 병목이 될 수 있습니다. 4개의 소프트 NUMA 노드를 구성하면 I/O 스레드와 지연 기록기 스레드가 각각 4개가 되므로 성능이 향상됩니다.

여러 하드웨어 NUMA 노드의 CPU를 포함하는 소프트 NUMA를 만들 수는 없습니다. 예를 들어 하드웨어에 8개의 CPU(0..7)가 있고 하드웨어 NUMA 노드가 두 개(0-3 및 4-7)이면 CPU(0,1)과 CPU(2,3)을 결합하여 소프트 NUMA를 만들 수 있습니다. CPU(1, 5)를 사용하여 소프트 NUMA를 만들 수는 없지만 CPU 선호도를 사용하여 SQL Server 인스턴스의 선호도를 여러 NUMA 노드의 CPU로 설정할 수 있습니다. 따라서 앞서 설명한 예에서 SQL Server에 CPU 0-3이 사용되는 경우 I/O 스레드와 지연 기록기 스레드가 각각 하나씩 있습니다. 또한 SQL Server에 CPU 1, 2, 5, 6이 사용되는 경우 두 개의 NUMA 노드에 액세스하게 되며 I/O 스레드와 지연 기록기 스레드가 각각 두 개씩 있습니다.

공무원 연금으로 참 말이 많다. 공무원들은 사상 최대의 인원이 운집하여 데모를 하면서 정부의 연금개혁에 대해 격렬하게 항의를 하고 있다.

공무원 연금 개혁을 하는 이유는 간단하다. 지금 이 상태로 공무원연금을 두면 30년 후에 재정이 바닥이 나서 공무원들에게 연금을 줄 수 없게 되고 이 돈들은 결국 국민의 세금으로 충당해야 한다는 것이다.

공무원 노조들도 이러한 현실에 대한 인식을 같이 해야 하며 공무원연금 개혁에 대한 대안을 제시를 해야 한다. 무조건 투쟁은 국민들에게 집단 이기주의로 비추어 질 수도 있다.

더 큰 문제는 정부에게 있다. 공무원연금 개혁의 당사자인 공무원노조와 어떠한 소통도 없이 불도저같이 정부안을 일방적으로 밀어붙히려고만 하고 있다. 개혁안을 만들고 일방적인 통보만 할 뿐이다. 참 비민주적인 처사라고 할 수 있다.

어떤 정책이든 갈등이 생길 수 밖에 없는데 서로 아이디어를 짜 맞추면서 충돌이나 갈등을 최소화하는 과정에서 현실적인 대안이 나오기를 바란다.  

의지는 결핍에서 생겨나며 고통에서 생겨난다. 원망의 충족은 고통을 중단시킬 수 없다. 그러나 하나의 원망의 충족은 열의 고통의 현실을 배제한다. 갈망은 길고 요구는 무한하지만 만족은 짧다. 욕구의 충족은 새로운 욕구를 지어낼 뿐이다. 충족된 욕구도 허상이요, 새로운 욕구도 허상이다. 거지에게 구제품을 주면 오늘은 살아가지만 내일의 불행은 가중된다. 모든 의지의 근거는 요구며 결핍이며 고통이다.

의지에 대한 글은 쇼펜하우어가 한 말인데 참 나의 가슴 속을 울리는 명언으로 들린다.
정말 맞는 소리다. 어떤 고통도 없고 욕구 불만도 없는 사람에게 과연 의지란 강한 감성이 생길 수는 없을 것이다.

예술가들도 금전적인 상황이 안 좋을 경우나 예술계에서 인정을 받지 못할 때 즉 욕구 불만으로 가득차 있을 때 위대한 작품을 탄생시키곤 했다. 음악가를 예를 들자면 파산 직전의 상황에서 생활비를 벌기 위해 작곡한 모짜르트 협주곡 20번, 러시아 혁명을 지켜보면서 현실에 대한 절규로 작곡한 프로코피에트 피아노 협주곡 1번, 망명 생활 중에 아름다운 조국의 모습을 그리면서 작곡한 라흐마니노프 협주곡 2번 등등.

하지만 어린 시절, 학창 시절 내내 아무런 어려움 없이 왕자같이 커온 부자집 도련님들에게 강한 의지가 있을 것이라고 기대하기는 힘들다. 대신 조금만 어려운 시간을 겪게 되어도 쓰러지는 유약한 인간이 될 가능성이 있다.

내 생각에 직장에서 지금 내가 하고 있는 일이 너무 잘 풀리고 제대로 인정받는 순간이 오게 되면 나 자신을 뒤돌아보면서 겸허히 생각을 많이 해 봐야겠다. 나도 모르게 나의 능력을 뛰어 넘어 세상을 바꾸려는 나의 강한 의지가 줄어들게 될 수 밖에 없는 순간이 될 수 있기 때문이다.

중요한 건 욕구가 충족되지 않는 고통의 순간이 다가오면 손가락을 이 세상으로 돌리지 말고 나 자신을 되돌아보아야 한다는 것이다. 이 모든 욕구 불만은 나 자신으로 비롯되는 것이다. 내가 능력이 없던가 준비가 부족하던가 이런 식으로 말이다. 아니면 내 마음을 고쳐먹건가. 아무리 이 세상에 대해 하소연을 하거나 비판을 해도 되돌아오는 것은 공허한 나의 메아림이다.