On 2017/10/14 下午8:04, Sverd Johnsen wrote:

Yes. bcache-tools ships some udev rules associated helper utils that
are used here.

Hi Sverd,

Is it possible for you to test the attached patch ? This is an effort to
avoid NULL dereference issue, let's try whether it works.

Thanks in advance.

Coly Li

On 14 October 2017 at 13:42, Coly Li [off-list ref] wrote:

quoted

On 2017/10/14 下午7:14, Sverd Johnsen wrote:

quoted

This is on 4.13.5. Happens sometime at boot, I just reboot and it
works fine. No other problems.

  40.391116] BUG: unable to handle kernel NULL pointer dereference at
00000000000006bc
   40.391663] IP: _raw_spin_lock_irqsave+0x12/0x30
   40.392152] PGD 0
   40.392153] P4D 0
   40.392658]
   40.393070] bcache: bch_journal_replay() journal replay done, 21
keys in 10 entries, seq 34810
   40.393427] bcache: register_cache() registered cache device sdc4
   40.394669] Oops: 0002 [#1] PREEMPT SMP
   40.395174] Modules linked in: tun(+) vhost tap kvm md_mod bcache

[snip]

quoted

Hi Sverd,

A fast glance on the code, c->data_bucket_lock from bch_alloc_sectors()
is very suspicious. c->data_bucket_lock is initialized in
bch_open_buckets_alloc(), which is called after calling kobject_init()
when allocate a cache set in bch_cache_set_alloc().

Cache/cache device register is via sysfs entry, therefor it is possible
that before spin lock c->data_bucket_lock is initialized, a cache/cached
device registration request sent into /sys/fs/bcache/register, then
trigger a NULL deference on the spin lock.

Normally it won't happen if the command is typed by human being. Do you
use some script to run the bcache automatically ? Then I can do further
check to confirm whether my guess is correct.