Re: [PATCH] mm/kmemleak: skip late_init if not skip disable
Hi, On Wed, Oct 9, 2019 at 12:51 AM Catalin Marinas wrote: > > Hi Murphy, > > On Sun, Sep 29, 2019 at 05:56:59PM +0800, Murphy Zhou wrote: > > Now if DEFAULT_OFF set to y, kmemleak_init will start the cleanup_work > > workqueue. Then late_init call will set kmemleak_initialized to 1, the > > cleaup workqueue will try to do cleanup, triggering: > > > > [24.738773] > > == > > [24.742784] BUG: KASAN: global-out-of-bounds in > > __kmemleak_do_cleanup+0x166/0x180 > > I don't think the invocation of kmemleak_do_cleanup() is the issue here. > It should be safe schedule the clean-up thread in case kmemleak was > disabled from boot. What you probably hit was a bug in > __kmemleak_do_cleanup() itself, fixed here: > > http://lkml.kernel.org/r/20191004134624.46216-1-catalin.mari...@arm.com > > With the above patch, I can no longer trigger the KASan warning. Got it. Thanks for noticing! > > -- > Catalin
[PATCH] mm/kmemleak: skip late_init if not skip disable
Now if DEFAULT_OFF set to y, kmemleak_init will start the cleanup_work
workqueue. Then late_init call will set kmemleak_initialized to 1, the
cleaup workqueue will try to do cleanup, triggering:
[24.738773] ==
[24.742784] BUG: KASAN: global-out-of-bounds in
__kmemleak_do_cleanup+0x166/0x180
[24.744144] Key type ._fscrypt registered
[24.745680] Read of size 8 at addr 88746c90 by task kworker/3:1/171
[24.745687]
[24.745697] CPU: 3 PID: 171 Comm: kworker/3:1 Not tainted
5.3.0-v5.3-12475-gcbafe18 #1
[24.745701] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[24.745710] Workqueue: events kmemleak_do_cleanup
[24.745717] Call Trace:
[24.745736] dump_stack+0x7c/0xc0
[24.745755] print_address_description.constprop.4+0x1f/0x300
[24.751562] Key type .fscrypt registered
[24.754370] __kasan_report.cold.8+0x76/0xb2
[24.754388] ? __kmemleak_do_cleanup+0x166/0x180
[24.754407] kasan_report+0xe/0x20
[24.778543] __kmemleak_do_cleanup+0x166/0x180
[24.780795] process_one_work+0x919/0x17d0
[24.782929] ? pwq_dec_nr_in_flight+0x320/0x320
[24.785092] worker_thread+0x87/0xb40
[24.786948] ? __kthread_parkme+0xc3/0x190
[24.789217] ? process_one_work+0x17d0/0x17d0
[24.791414] kthread+0x333/0x3f0
[24.793031] ? kthread_create_worker_on_cpu+0xc0/0xc0
[24.795473] ret_from_fork+0x3a/0x50
[24.797303]
[24.798091] The buggy address belongs to the variable:
[24.800634] mem_pool_free_count+0x10/0x40
[24.802656]
[24.803434] Memory state around the buggy address:
[24.805793] 88746b80: 04 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
[24.809177] 88746c00: 00 fa fa fa fa fa fa fa 00 00 fa fa fa fa fa fa
[24.812407] >88746c80: 04 fa fa fa fa fa fa fa 00 00 fa fa fa fa fa fa
[24.815638] ^
[24.817372] 88746d00: 00 00 fa fa fa fa fa fa 00 00 00 00 00 00 00 00
[24.820740] 88746d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[24.824021] ==
Fixes: c5665868183f ("mm: kmemleak: use the memory pool for early allocations")
Signed-off-by: Murphy Zhou
---
mm/kmemleak.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 03a8d84badad..b9baf617fe35 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1946,6 +1946,11 @@ void __init kmemleak_init(void)
*/
static int __init kmemleak_late_init(void)
{
+ if (!kmemleak_skip_disable) {
+ kmemleak_disable();
+ return 0;
+ }
+
kmemleak_initialized = 1;
debugfs_create_file("kmemleak", 0644, NULL, NULL, _fops);
--
2.21.0
scsi_debug module panic
Hi, It reproduces every time. It's ok on v5.2. So it's a regression in v5.3-rc1. Thanks, M [root@7u ~]# modprobe scsi_debug [ 244.084203] scsi host2: scsi_debug: version 0188 [20190125] [ 244.084203] dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0 [ 244.093098] BUG: kernel NULL pointer dereference, address: [ 244.097625] #PF: supervisor read access in kernel mode [ 244.101175] #PF: error_code(0x) - not-present page [ 244.104670] PGD 0 P4D 0 [ 244.106381] Oops: [#1] SMP PTI [ 244.108738] CPU: 17 PID: 182 Comm: kworker/u64:1 Not tainted 5.3.0-rc1-master-5f9e832 #112 [ 244.114161] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 244.117854] Workqueue: events_unbound async_run_entry_fn [ 244.121025] RIP: 0010:dma_direct_max_mapping_size+0x2b/0x65 [ 244.124324] Code: 66 66 66 90 55 53 48 89 fb e8 f1 14 00 00 84 c0 75 0a 5b 48 c7 c0 ff ff ff ff 5d c3 48 8b 83 28 02 00 00 48 8b ab 38 02 00 00 <48> 8b 00 48 89 ea 48 85 c0 74 0f 48 85 d2 48 89 c5 74 07 48 39 d0 [ 244.135752] RSP: 0018:b3bd40733bf8 EFLAGS: 00010202 [ 244.139237] RAX: RBX: a027feb50c18 RCX: [ 244.143966] RDX: 0800 RSI: 0800 RDI: a027feb50c18 [ 244.148748] RBP: R08: 000300e0 R09: a028104dd280 [ 244.153399] R10: a028104dd280 R11: ffa0 R12: a027feb50c18 [ 244.157982] R13: R14: a0280513c828 R15: [ 244.162375] FS: () GS:a0289464() knlGS: [ 244.167286] CS: 0010 DS: ES: CR0: 80050033 [ 244.170876] CR2: CR3: 3c20a000 CR4: 06e0 [ 244.175116] Call Trace: [ 244.176622] __scsi_init_queue+0x7a/0x130 [ 244.178788] scsi_mq_alloc_queue+0x34/0x50 [ 244.181015] scsi_alloc_sdev+0x1e4/0x2b0 [ 244.183150] scsi_probe_and_add_lun+0x8af/0xd60 [ 244.185628] ? kobject_set_name_vargs+0x6e/0x90 [ 244.188168] ? dev_set_name+0x53/0x70 [ 244.190258] ? _cond_resched+0x15/0x30 [ 244.192416] ? mutex_lock+0xe/0x30 [ 244.194284] __scsi_scan_target+0xf4/0x250 [ 244.196527] scsi_scan_channel.part.13+0x52/0x70 [ 244.198830] scsi_scan_host_selected+0xe3/0x190 [ 244.201159] ? __switch_to_asm+0x40/0x70 [ 244.203124] do_scan_async+0x17/0x180 [ 244.204961] async_run_entry_fn+0x39/0x160 [ 244.207012] process_one_work+0x171/0x380 [ 244.209007] worker_thread+0x49/0x3f0 [ 244.210840] kthread+0xf8/0x130 [ 244.212419] ? max_active_store+0x80/0x80 [ 244.214426] ? kthread_bind+0x10/0x10 [ 244.216264] ret_from_fork+0x35/0x40 [ 244.218075] Modules linked in: scsi_debug sunrpc snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_hda_codec crct10dif_pclmul snd_hda_core crc32_pclmul snd_hwdep ghash_clmulni_intel snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd snd_timer cryptd snd glue_helper sg pcspkr soundcore joydev virtio_balloon i2c_piix4 ip_tables xfs libcrc32c qxl drm_kms_helper syscopyarea sysfillrect sd_mod sysimgblt fb_sys_fops ttm ata_generic pata_acpi drm virtio_console 8139too ata_piix libata virtio_pci 8139cp virtio_ring crc32c_intel serio_raw mii virtio floppy dm_mirror dm_region_hash dm_log dm_mod [ 244.243647] CR2: [ 244.245274] ---[ end trace 1209311dc64cb7fa ]--- [ 244.247399] RIP: 0010:dma_direct_max_mapping_size+0x2b/0x65 [ 244.250145] Code: 66 66 66 90 55 53 48 89 fb e8 f1 14 00 00 84 c0 75 0a 5b 48 c7 c0 ff ff ff ff 5d c3 48 8b 83 28 02 00 00 48 8b ab 38 02 00 00 <48> 8b 00 48 89 ea 48 85 c0 74 0f 48 85 d2 48 89 c5 74 07 48 39 d0 [ 244.258533] RSP: 0018:b3bd40733bf8 EFLAGS: 00010202 [ 244.260749] RAX: RBX: a027feb50c18 RCX: [ 244.263777] RDX: 0800 RSI: 0800 RDI: a027feb50c18 [ 244.266798] RBP: R08: 000300e0 R09: a028104dd280 [ 244.269901] R10: a028104dd280 R11: ffa0 R12: a027feb50c18 [ 244.272899] R13: R14: a0280513c828 R15: [ 244.275909] FS: () GS:a0289464() knlGS: [ 244.279131] CS: 0010 DS: ES: CR0: 80050033 [ 244.281655] CR2: CR3: 3c20a000 CR4: 06e0 [ 244.284554] Kernel panic - not syncing: Fatal exception [ 244.287052] Kernel Offset: 0x22c0 from 0x8100 (relocation range: 0x8000-0xbfff) [ 244.291412] ---[ end Kernel panic - not syncing: Fatal exception ]---
Re: linux-next: Fixes tag needs some work in the cifs tree
On Fri, May 24, 2019 at 10:14 PM Steve French wrote:
>
> fixed and repushed to cifs-2.6.git for-next
Thanks!
[resend including mail lists]
>
> On Thu, May 23, 2019 at 11:27 PM Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > In commit
> >
> > f875253b5fe6 ("fs/cifs/smb2pdu.c: fix buffer free in SMB2_ioctl_free")
> >
> > Fixes tag
> >
> > Fixes: 2c87d6a ("cifs: Allocate memory for all iovs in smb2_ioctl")
> >
> > has these problem(s):
> >
> > - SHA1 should be at least 12 digits long
> > Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
> > or later) just making sure it is not set (or set to "auto").
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
>
>
> --
> Thanks,
>
> Steve
Re: [PATCH 0/2] fs/lock: show locks info owned by dead/invisible processes
Hi,
Looks like this missed v4.18 ?
Thanks,
Murphy
On Fri, Jun 8, 2018 at 10:27 PM, Konstantin Khorenko
wrote:
> The behavior has been changed after 9d5b86ac13c5 ("fs/locks: Remove fl_nspid
> and use fs-specific l_pid for remote locks")
> and now /proc/$PID/fdinfo/$FD does not show the info about the lock
> * if the flock owner process is dead and its pid has been already freed
> or
> * if the lock owner is not visible in current pidns.
>
> CRIU uses this interface to store locks info during dump and thus can break
> on v4.13 and newer.
>
> So let's show info about locks anyway in described cases (like it was before
> 9d5b86ac13c5), but show pid number saved in file_lock struct if we are in
> init_pid_ns (patch 1) or just zero otherwise (patch 2) like we do with SID.
>
> Reproducer:
> process A process A1 process A2
> fork()->
> exit() open()
> flock()
> fork()->
> exit() sleep()
>
> Before the patch:
>
> (root@vz7)/: cat /proc/${PID_A2}/fdinfo/3
> pos:4
> flags: 0212
> mnt_id: 257
> lock: (root@vz7)/:
>
> After the patch:
> ===
> (root@vz7)/:cat /proc/${PID_A2}/fdinfo/3
> pos:4
> flags: 0212
> mnt_id: 295
> lock: 1: FLOCK ADVISORY WRITE ${PID_A1} b6:f8a61:529946 0 EOF
>
> ===
> # cat flock1.c
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main(void)
> {
> int fd;
> int err;
> pid_t child_pid;
>
> child_pid = fork();
> if (child_pid == -1)
> perror("fork failed");
> if (child_pid) {
> exit(0);
> }
>
> fd = open("/tmp/a", O_CREAT | O_RDWR);
> if (fd == -1)
> perror("Failed to open the file");
>
> err = flock(fd, LOCK_EX);
> if (err == -1)
> perror("flock failed");
>
> child_pid = fork();
> if (child_pid == -1)
> perror("fork failed");
> if (child_pid)
> exit(0);
>
> sleep(1);
>
> return 0;
> }
>
> Konstantin Khorenko (2):
> fs/lock: skip lock owner pid translation in case we are in init_pid_ns
> fs/lock: show locks taken by processes from another pidns
>
> fs/locks.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> --
> 2.15.1
>
Re: [PATCH 0/2] fs/lock: show locks info owned by dead/invisible processes
Hi,
Looks like this missed v4.18 ?
Thanks,
Murphy
On Fri, Jun 8, 2018 at 10:27 PM, Konstantin Khorenko
wrote:
> The behavior has been changed after 9d5b86ac13c5 ("fs/locks: Remove fl_nspid
> and use fs-specific l_pid for remote locks")
> and now /proc/$PID/fdinfo/$FD does not show the info about the lock
> * if the flock owner process is dead and its pid has been already freed
> or
> * if the lock owner is not visible in current pidns.
>
> CRIU uses this interface to store locks info during dump and thus can break
> on v4.13 and newer.
>
> So let's show info about locks anyway in described cases (like it was before
> 9d5b86ac13c5), but show pid number saved in file_lock struct if we are in
> init_pid_ns (patch 1) or just zero otherwise (patch 2) like we do with SID.
>
> Reproducer:
> process A process A1 process A2
> fork()->
> exit() open()
> flock()
> fork()->
> exit() sleep()
>
> Before the patch:
>
> (root@vz7)/: cat /proc/${PID_A2}/fdinfo/3
> pos:4
> flags: 0212
> mnt_id: 257
> lock: (root@vz7)/:
>
> After the patch:
> ===
> (root@vz7)/:cat /proc/${PID_A2}/fdinfo/3
> pos:4
> flags: 0212
> mnt_id: 295
> lock: 1: FLOCK ADVISORY WRITE ${PID_A1} b6:f8a61:529946 0 EOF
>
> ===
> # cat flock1.c
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main(void)
> {
> int fd;
> int err;
> pid_t child_pid;
>
> child_pid = fork();
> if (child_pid == -1)
> perror("fork failed");
> if (child_pid) {
> exit(0);
> }
>
> fd = open("/tmp/a", O_CREAT | O_RDWR);
> if (fd == -1)
> perror("Failed to open the file");
>
> err = flock(fd, LOCK_EX);
> if (err == -1)
> perror("flock failed");
>
> child_pid = fork();
> if (child_pid == -1)
> perror("fork failed");
> if (child_pid)
> exit(0);
>
> sleep(1);
>
> return 0;
> }
>
> Konstantin Khorenko (2):
> fs/lock: skip lock owner pid translation in case we are in init_pid_ns
> fs/lock: show locks taken by processes from another pidns
>
> fs/locks.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> --
> 2.15.1
>
