)]}'
{
  "commit": "8347199c6fa5fadb8fad959c9c6e556f10500353",
  "tree": "5dd65b100bb698f83bac3ccff83e2952bf00422a",
  "parents": [
    "44e99697e83d9796f27089d4434a5a76122fcc72"
  ],
  "author": {
    "name": "Luis Chamberlain",
    "email": "mcgrof@kernel.org",
    "time": "Sat Jul 03 00:09:26 2021 +0000"
  },
  "committer": {
    "name": "Luis Chamberlain",
    "email": "mcgrof@kernel.org",
    "time": "Fri Sep 17 10:58:10 2021 -0700"
  },
  "message": "zram: use ATTRIBUTE_GROUPS to fix sysfs deadlock module removal\n\nThe ATTRIBUTE_GROUPS is typically used to avoid boiler plate\ncode which is used in many drivers. Embracing ATTRIBUTE_GROUPS was\nlong due on the zram driver, however a recent fix for sysfs allows\nusers of ATTRIBUTE_GROUPS to also associate a module to the group\nattribute.\n\nIn zram\u0027s case this also means it allows us to fix a race which triggers\na deadlock on the zram driver. This deadlock happens when a sysfs attribute\nuse a lock also used on module removal. This happens when for instance a\nsysfs file on a driver is used, then at the same time we have module\nremoval call trigger. The module removal call code holds a lock, and then\nthe sysfs file entry waits for the same lock. While holding the lock the\nmodule removal tries to remove the sysfs entries, but these cannot be\nremoved yet as one is waiting for a lock. This won\u0027t complete as the lock\nis already held. Likewise module removal cannot complete, and so we\ndeadlock.\n\nSysfs fixes this when the group attributes have a module associated to\nit, sysfs will *try* to get a refcount to the module when a shared\nlock is used, prior to mucking with a sysfs attribute. If this fails we\njust give up right away.\n\nThis deadlock was first reported with the zram driver, a sketch of how\nthis can happen follows:\n\nCPU A                              CPU B\n                                   whatever_store()\nmodule_unload\n  mutex_lock(foo)\n                                   mutex_lock(foo)\n   del_gendisk(zram-\u003edisk);\n     device_del()\n       device_remove_groups()\n\nIn this situation whatever_store() is waiting for the mutex foo to\nbecome unlocked, but that won\u0027t happen until module removal is complete.\nBut module removal won\u0027t complete until the sysfs file being poked\ncompletes which is waiting for a lock already held.\n\nThis issue can be reproduced easily on the zram driver as follows:\n\nLoop 1 on one terminal:\n\nwhile true;\n\tdo modprobe zram;\n\tmodprobe -r zram;\ndone\n\nLoop 2 on a second terminal:\nwhile true; do\n\techo 1024 \u003e  /sys/block/zram0/disksize;\n\techo 1 \u003e /sys/block/zram0/reset;\ndone\n\nWithout this patch we end up in a deadlock, and the following\nstack trace is produced which hints to us what the issue was:\n\nINFO: task bash:888 blocked for more than 120 seconds.\n      Tainted: G            E 5.12.0-rc1-next-20210304+ #4\n\"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:bash            state:D stack:    0 pid:  888 ppid: 887 flags:\u003cetc\u003e\nCall Trace:\n __schedule+0x2e4/0x900\n schedule+0x46/0xb0\n schedule_preempt_disabled+0xa/0x10\n __mutex_lock.constprop.0+0x2c3/0x490\n ? _kstrtoull+0x35/0xd0\n reset_store+0x6c/0x160 [zram]\n kernfs_fop_write_iter+0x124/0x1b0\n new_sync_write+0x11c/0x1b0\n vfs_write+0x1c2/0x260\n ksys_write+0x5f/0xe0\n do_syscall_64+0x33/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f34f2c3df33\nRSP: 002b:00007ffe751df6e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f34f2c3df33\nRDX: 0000000000000002 RSI: 0000561ccb06ec10 RDI: 0000000000000001\nRBP: 0000561ccb06ec10 R08: 000000000000000a R09: 0000000000000001\nR10: 0000561ccb157590 R11: 0000000000000246 R12: 0000000000000002\nR13: 00007f34f2d0e6a0 R14: 0000000000000002 R15: 00007f34f2d0e8a0\nINFO: task modprobe:1104 can\u0027t die for more than 120 seconds.\ntask:modprobe        state:D stack:    0 pid: 1104 ppid: 916 flags:\u003cetc\u003e\nCall Trace:\n __schedule+0x2e4/0x900\n schedule+0x46/0xb0\n __kernfs_remove.part.0+0x228/0x2b0\n ? finish_wait+0x80/0x80\n kernfs_remove_by_name_ns+0x50/0x90\n remove_files+0x2b/0x60\n sysfs_remove_group+0x38/0x80\n sysfs_remove_groups+0x29/0x40\n device_remove_attrs+0x4a/0x80\n device_del+0x183/0x3e0\n ? mutex_lock+0xe/0x30\n del_gendisk+0x27a/0x2d0\n zram_remove+0x8a/0xb0 [zram]\n ? hot_remove_store+0xf0/0xf0 [zram]\n zram_remove_cb+0xd/0x10 [zram]\n idr_for_each+0x5e/0xd0\n destroy_devices+0x39/0x6f [zram]\n __do_sys_delete_module+0x190/0x2a0\n do_syscall_64+0x33/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f32adf727d7\nRSP: 002b:00007ffc08bb38a8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0\nRAX: ffffffffffffffda RBX: 000055eea23cbb10 RCX: 00007f32adf727d7\nRDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055eea23cbb78\nRBP: 000055eea23cbb10 R08: 0000000000000000 R09: 0000000000000000\nR10: 00007f32adfe5ac0 R11: 0000000000000206 R12: 000055eea23cbb78\nR13: 0000000000000000 R14: 0000000000000000 R15: 000055eea23cbc20\n\n[0] https://lkml.kernel.org/r/20210401235925.GR4332@42.do-not-panic.com\n\nSigned-off-by: Luis Chamberlain \u003cmcgrof@kernel.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b26abcb955cc00ad021802b96d2b7332e905582a",
      "old_mode": 33188,
      "old_path": "drivers/block/zram/zram_drv.c",
      "new_id": "60a55ae8cd91e6c78b98201bca2be2d559d6e480",
      "new_mode": 33188,
      "new_path": "drivers/block/zram/zram_drv.c"
    }
  ]
}