Fix typo #118

zhenyuchen · 2014-09-12T10:03:25Z

No description provided.

frankcash · 2014-09-12T11:54:50Z

Linus doesn't accept Pulls from github.

captainepoch · 2014-09-12T13:49:49Z

You should take a look on how to submit a path into Linux Kernel's repo, dude!

Check this: https://github.com/gregkh/kernel-tutorial

Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 [ 0.603005] .... node #1, CPUs: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 [ 1.200005] .... node #2, CPUs: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.796005] .... node #3, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 [ 2.393005] .... node #4, CPUs: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 [ 2.996005] .... node #5, CPUs: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 3.600005] .... node torvalds#6, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 [ 4.202005] .... node torvalds#7, CPUs: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 [ 4.811005] .... node torvalds#8, CPUs: torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 5.421006] .... node torvalds#9, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 [ 6.032005] .... node torvalds#10, CPUs: torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 [ 6.648006] .... node torvalds#11, CPUs: torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 7.262005] .... node torvalds#12, CPUs: torvalds#96 torvalds#97 torvalds#98 torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103 [ 7.865005] .... node torvalds#13, CPUs: torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111 [ 8.466005] .... node torvalds#14, CPUs: torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119 [ 9.073006] .... node torvalds#15, CPUs: torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>

Reproducible by runtime suspending a Haswell machine with eDP + HDMI outputs connected. [ 209.600086] [drm:i915_runtime_suspend], Suspending device [ 209.688435] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 209.688500] IP: [<ffffffffa0109d4e>] i915_sink_crc+0x6e/0xf0 [i915] [ 209.688577] PGD 36aba067 PUD 35d7f067 PMD 0 [ 209.688613] Oops: 0000 [#1] SMP [ 209.688641] Modules linked in: fuse ip6table_filter ip6_tables ebtable_nat ebtables iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp microcode serio_raw e1000e pcspkr i2c_i801 ptp mei_me mei lpc_ich mfd_core pps_core dm_crypt i915 i2c_algo_bit crc32_pclmul drm_kms_helper crc32c_intel drm ghash_clmulni_intel video [ 209.688893] CPU: 1 PID: 1797 Comm: pm_pc8 Not tainted 3.13.0+ torvalds#118 [ 209.688937] Hardware name: Intel Corporation Shark Bay Client platform/WhiteTip Mountain 1, BIOS HSWLPTU1.86C.0133.R00.1309172123 09/17/2013 [ 209.689023] task: ffff88007fb4b690 ti: ffff88007d9d2000 task.ti: ffff88007d9d2000 [ 209.689074] RIP: 0010:[<ffffffffa0109d4e>] [<ffffffffa0109d4e>] i915_sink_crc+0x6e/0xf0 [i915] [ 209.689169] RSP: 0018:ffff88007d9d3e68 EFLAGS: 00010246 [ 209.689205] RAX: 0000000000000000 RBX: ffff880036a03478 RCX: ffff8800366c9770 [ 209.689252] RDX: ffff88014325cf38 RSI: ffff88007fb4bd08 RDI: ffff88007fb4b690 [ 209.689299] RBP: ffff88007d9d3e98 R08: 0000000000000000 R09: 0000000000000000 [ 209.689346] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800366c9148 [ 209.689393] R13: 00000000ffffffed R14: ffff88007d9d3f50 R15: ffff880036a03478 [ 209.689441] FS: 00007f5a74bc29c0(0000) GS:ffff88014f240000(0000) knlGS:0000000000000000 [ 209.689494] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 209.689533] CR2: 0000000000000060 CR3: 0000000079d7e000 CR4: 00000000001407e0 [ 209.689580] Stack: [ 209.689594] 0000000000001000 ffff880146083980 ffff880146083980 0000000000000000 [ 209.689649] ffff880146083980 0000000000000001 ffff88007d9d3f00 ffffffff811d0744 [ 209.689702] 0000000000000046 00007fff7949fe20 ffff880036a034b8 0000000000000080 [ 209.689756] Call Trace: [ 209.689778] [<ffffffff811d0744>] seq_read+0x164/0x3e0 [ 209.689816] [<ffffffff811ab165>] vfs_read+0x95/0x160 [ 209.689851] [<ffffffff811abc79>] SyS_read+0x49/0xa0 [ 209.689888] [<ffffffff810ef64c>] ? __audit_syscall_entry+0x9c/0xf0 [ 209.689933] [<ffffffff81659412>] system_call_fastpath+0x16/0x1b Testcase: igt/pm_pc8 (do a full run, it will fail at the debugfs-read subtest) Signed-off-by: Paulo Zanoni <[email protected]> [danvet: Flip around NULL check for robustness.] Signed-off-by: Daniel Vetter <[email protected]>

This patch is more tolerant to the typo errors on the rockchip,pins property (eg. rockchip-pins, rockchip-pin...) and provides a nice error message instead of raising a NULL pointer exception. Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc6-next-20140925+ torvalds#118 task: ee0379c0 ti: ee05c000 task.ti: ee05c000 PC is at rockchip_pinctrl_probe+0xbd0/0xe3c LR is at devres_add+0x3c/0x40 pc : [<c0201bd4>] lr : [<c0258228>] psr: 80000113 sp : ee05dc80 ip : ee05dc48 fp : ee05dcfc r10: 00000000 r9 : 00000000 r8 : ee7ed334 r7 : 0000002f r6 : ee197f00 r5 : ee7ed290 r4 : ee124210 r3 : 00000004 r2 : c0bc4250 r1 : 40000113 r0 : ee1ac990 Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 6000404a DAC: 00000015 Process swapper/0 (pid: 1, stack limit = 0xee05c240) Stack: (0xee05dc80 to 0xee05e000) dc80: ee7ed474 00001c00 00000000 00000001 ee11cb78 00000000 00000001 00000017 dca0: ee196f18 ee12f400 ee7e822c ee12f410 00000000 00000004 200800ff ee7e8c18 dcc0: 00000200 00000000 00000000 00000000 ee12f418 ee12f410 ffffffed c0bc3994 dce0: c0bdcc88 c0c2766c 00000000 00000000 ee05dd1c ee05dd00 c0256f80 c0201010 dd00: c0256f30 ee12f410 c0bc3994 00000000 ee05dd4c ee05dd20 c025555c c0256f3c dd20: ee05dd4c ee05dd30 c0bc3994 ee12f410 c025577 00000000 00000000 00000000 dd40: ee05dd64 ee05dd50 c02557a0 c025542c 00000000 ee12f410 ee05dd8c ee05dd68 dd60: c0253a38 c025577c ee038770 ee124fb8 c0482a58 ee12f410 c0bca028 ee12f444 dd80: ee05ddac ee05dd90 c02553a8 c02539c4 00000001 ee12f410 c0bca028 ee12f410 dda0: ee05ddcc ee05ddb0 c0254918 c0255348 00000000 ee12f410 00000000 ee12f418 ddc0: ee05de04 ee05ddd0 c0252c48 c02548f4 ee05de14 ee05dde0 c0327e9c c0329ad4 dde0: ee12f400 ee7e827c 00000000 00000000 00000000 00000001 ee05de14 ee05de08 de00: c0327a64 c0252814 ee05de3c ee05de18 c03282d0 c0327a34 00000000 ee7e822c de20: 00000000 00000000 00000000 c04b9da4 ee05de9c ee05de40 c0328590 c0328268 de40: 00000001 ffffffff 00000000 00000000 ff0a0005 ffffffff ee05de84 ee05ded8 de60: ee05de9c ee05de70 c0326910 c01e24e8 ee05de9c ee7e822c ee7e099c c04b9da4 de80: 00000000 00000000 00000001 00000000 ee05decc ee05dea0 c0328800 c0328324 dea0: 00000001 c05f16b0 ee125340 c0bb7ba0 c0bb7ba0 c0be36c0 c05f16b0 0000009a dec0: ee05dedc ee05ded0 c05f16e8 c03287a0 ee05df5c ee05dee0 c0008ab0 c05f16bc dee0: c0113df0 c0113adc ee05df0c ee05def8 c0038400 c00383f4 ef7fccfb 00000000 df00: ee05df5c ee05df10 c0038730 c05ee60 c004db80 c0484378 00000000 c05ec86c df20: 00000003 00000003 0000009a c05ebecc 00000000 00000003 c06216dc c062d2e4 df40: c0be36c0 c0be36c0 0000009a 00000000 ee05df94 ee05df60 c05eee10 c000899c df60: 00000003 00000003 c05ee5f4 ee0379c0 00000000 c047d8a8 00000000 00000000 df80: 00000000 00000000 ee05dfac ee05df98 c047d8b8 c05eed00 ee05c000 00000000 dfa0: 00000000 ee05dfb0 c000e958 c047d8b4 00000000 00000000 00000000 00000000 dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 13048395 9f284081 Backtrace: [<c0201004>] (rockchip_pinctrl_probe) from [<c0256f80>] (platform_drv_probe+0x50/0x9c) r10:00000000 r9:00000000 r8:c0c2766c r7:c0bdcc88 r6:c0bc3994 r5:ffffffed r4:ee12f410 [<c0256f30>] (platform_drv_probe) from [<c025555c>] (driver_probe_device+0x13c/0x350) r6:00000000 r5:c0bc3994 r4:ee12f410 r3:c0256f30 [<c0255420>] (driver_probe_device) from [<c02557a0>] (__device_attach+0x30/0x4c) r9:00000000 r8:00000000 r7:00000000 r6:c0255770 r5:ee12f410 r4:c0bc3994 [<c0255770>] (__device_attach) from [<c0253a38>] (bus_for_each_drv+0x80/0x94) r5:ee12f410 r4:00000000 [<c02539b8>] (bus_for_each_drv) from [<c02553a8>] (device_attach+0x6c/0x90) r6:ee12f444 r5:c0bca028 r4:ee12f410 [<c025533c>] (device_attach) from [<c0254918>] (bus_probe_device+0x30/0xa0) r6:ee12f410 r5:c0bca028 r4:ee12f410 r3:00000001 [<c02548e8>] (bus_probe_device) from [<c0252c48>] (device_add+0x440/0x52c) r6:ee12f418 r5:00000000 r4:ee12f410 r3:00000000 [<c0252808>] (device_add) from [<c0327a64>] (of_device_add+0x3c/0x40) r9:00000001 r8:00000000 r7:00000000 r6:00000000 r5:ee7e827c r4:ee12f400 [<c0327a28>] (of_device_add) from [<c03282d0>] (of_platform_device_create_pdata+0x74/0xa0) [<c032825c>] (of_platform_device_create_pdata) from [<c0328590>] (of_platform_bus_create+0x278/0x368) r8:c04b9da4 r7:00000000 r6:00000000 r5:00000000 r4:ee7e822c r3:00000000 [<c0328318>] (of_platform_bus_create) from [<c0328800>] (of_platform_populate+0x6c/0x98) r10:00000000 r9:00000001 r8:00000000 r7:00000000 r6:c04b9da4 r5:ee7e099c r4:ee7e822c [<c0328794>] (of_platform_populate) from [<c05f16e8>] (customize_machine+0x38/0x48) r9:0000009a r8:c05f16b0 r7:c0be36c0 r6:c0bb7ba0 r5:c0bb7ba0 r4:ee125340 [<c05f16b0>] (customize_machine) from [<c0008ab0>] (do_one_initcall+0x120/0x1d4) [<c0008990>] (do_one_initcall) from [<c05eee10>] (kernel_init_freeable+0x11c/0x1e4) r10:00000000 r9:0000009a r8:c0be36c0 r7:c0be36c0 r6:c062d2e4 r5:c06216dc r4:00000003 [<c05eecf4>] (kernel_init_freeable) from [<c047d8b8>] (kernel_init+0x10/0xec) r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c047d8a8 r4:00000000 [<c047d8a8>] (kernel_init) from [<c000e958>] (ret_from_fork+0x14/0x3c) r4:00000000 r3:ee05c000 Code: e51b304 e15a0003 aa000031 e5942014 (e5990000) ---[ end trace a350fda3a1974f25 ]---

When incoming packet qualifies for rx_copybreak, we copy the data to newly allocated skb. We do not free/unmap the original buffer. At this point driver assumes this buffer is unallocated. When enic_rq_alloc_buf() is called for buffer allocation, it checks if buf->os_buf is NULL. If its not NULL that means buffer can be re-used. When vnic_rq_clean() is called for freeing all rq buffers, and if the rx_copybreak reused buffer falls outside the used desc, we do not free the buffer. The following trace is observer when dma-debug is enabled. Fix is to walk through complete ring and clean if buffer is present. [ 40.555386] ------------[ cut here ]------------ [ 40.555396] WARNING: CPU: 0 PID: 491 at lib/dma-debug.c:971 dma_debug_device_change+0x188/0x1f0() [ 40.555400] pci 0000:06:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=4] One of leaked entries details: [device address=0x00000000ff4cc040] [size=9018 bytes] [mapped with DMA_FROM_DEVICE] [mapped as single] [ 40.555402] Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver coretemp intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw joydev mousedev gf128mul hid_generic glue_helper mgag200 usbhid ttm hid drm_kms_helper drm ablk_helper syscopyarea sysfillrect sysimgblt i2c_algo_bit i2c_core iTCO_wdt cryptd mac_hid evdev pcspkr sb_edac edac_core tpm_tis iTCO_vendor_support ipmi_si wmi tpm ipmi_msghandler shpchp lpc_ich processor acpi_power_meter hwmon button ac sch_fq_codel nfs lockd grace sunrpc fscache sd_mod ehci_pci ehci_hcd megaraid_sas usbcore scsi_mod usb_common enic(-) crc32c_generic crc32c_intel btrfs xor raid6_pq ext4 crc16 mbcache jbd2 [ 40.555467] CPU: 0 PID: 491 Comm: rmmod Not tainted 4.1.0-rc7-ARCH-01305-gf59b71f torvalds#118 [ 40.555469] Hardware name: Cisco Systems Inc UCSB-B200-M4/UCSB-B200-M4, BIOS B200M4.2.2.2.23.061220140128 06/12/2014 [ 40.555471] 0000000000000000 00000000e2f8a5b7 ffff880275f8bc48 ffffffff8158d6f0 [ 40.555474] 0000000000000000 ffff880275f8bca0 ffff880275f8bc88 ffffffff8107b04a [ 40.555477] ffff8802734e0000 0000000000000004 ffff8804763fb3c0 ffff88027600b650 [ 40.555480] Call Trace: [ 40.555488] [<ffffffff8158d6f0>] dump_stack+0x4f/0x7b [ 40.555492] [<ffffffff8107b04a>] warn_slowpath_common+0x8a/0xc0 [ 40.555494] [<ffffffff8107b0d5>] warn_slowpath_fmt+0x55/0x70 [ 40.555498] [<ffffffff812fa408>] dma_debug_device_change+0x188/0x1f0 [ 40.555503] [<ffffffff8109aaef>] notifier_call_chain+0x4f/0x80 [ 40.555506] [<ffffffff8109aecb>] __blocking_notifier_call_chain+0x4b/0x70 [ 40.555510] [<ffffffff8109af06>] blocking_notifier_call_chain+0x16/0x20 [ 40.555514] [<ffffffff813f8066>] __device_release_driver+0xf6/0x120 [ 40.555518] [<ffffffff813f8b08>] driver_detach+0xc8/0xd0 [ 40.555523] [<ffffffff813f7c59>] bus_remove_driver+0x59/0xe0 [ 40.555527] [<ffffffff813f93a0>] driver_unregister+0x30/0x70 [ 40.555534] [<ffffffff8131532d>] pci_unregister_driver+0x2d/0xa0 [ 40.555542] [<ffffffffa0200ec2>] enic_cleanup_module+0x10/0x14e [enic] [ 40.555547] [<ffffffff8110158f>] SyS_delete_module+0x1cf/0x280 [ 40.555551] [<ffffffff811e284e>] ? ____fput+0xe/0x10 [ 40.555554] [<ffffffff810980ec>] ? task_work_run+0xbc/0xf0 [ 40.555558] [<ffffffff815930ee>] system_call_fastpath+0x12/0x71 [ 40.555561] ---[ end trace 4988cadc77c2b236 ]--- [ 40.555562] Mapped at: [ 40.555563] [<ffffffff812fa865>] debug_dma_map_page+0x95/0x150 [ 40.555566] [<ffffffffa01f4a88>] enic_rq_alloc_buf+0x1b8/0x360 [enic] [ 40.555570] [<ffffffffa01f7658>] enic_open+0xf8/0x820 [enic] [ 40.555574] [<ffffffff8148d50e>] __dev_open+0xce/0x150 [ 40.555579] [<ffffffff8148d851>] __dev_change_flags+0xa1/0x170 Signed-off-by: Govindarajulu Varadarajan <[email protected]> Signed-off-by: David S. Miller <[email protected]>

ODROID-XU3/XU4: Enable PWM output for status LEDs in dts under 4.2rc1

It appears that commit 75ef718 ("mm, vmstat: add infrastructure for per-node vmstats", 2016-07-28) has introduced a regression on machines that have nodes which have no memory, such as the POWER8 server that I use for testing. When I boot current upstream, I get a splat like this: [ 1.713998] Unable to handle kernel paging request for data at address 0xff7a10000 [ 1.714164] Faulting instruction address: 0xc000000000270cd0 [ 1.714304] Oops: Kernel access of bad area, sig: 11 [#1] [ 1.714414] SMP NR_CPUS=2048 NUMA PowerNV [ 1.714530] Modules linked in: [ 1.714647] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-kvm+ torvalds#118 [ 1.714786] task: c000000ff0680010 task.stack: c000000ff0704000 [ 1.714926] NIP: c000000000270cd0 LR: c000000000270ce8 CTR: 0000000000000000 [ 1.715093] REGS: c000000ff0707900 TRAP: 0300 Not tainted (4.7.0-kvm+) [ 1.715232] MSR: 9000000102009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE,TM[E]> CR: 846b6824 XER: 20000000 [ 1.715748] CFAR: c000000000008768 DAR: 0000000ff7a10000 DSISR: 42000000 SOFTE: 1 GPR00: c000000000270d08 c000000ff0707b80 c0000000011fb200 0000000000000000 GPR04: 0000000000000800 0000000000000000 0000000000000000 0000000000000000 GPR08: ffffffffffffffff 0000000000000000 0000000ff7a10000 c00000000122aae0 GPR12: c000000000a1e440 c00000000fb80000 c00000000000c188 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c000000000cecad0 GPR24: c000000000d035b8 c000000000d6cd18 c000000000d6cd18 c000001fffa86300 GPR28: 0000000000000000 c000001fffa96300 c000000001230034 c00000000122eb18 [ 1.717484] NIP [c000000000270cd0] refresh_zone_stat_thresholds+0x80/0x240 [ 1.717568] LR [c000000000270ce8] refresh_zone_stat_thresholds+0x98/0x240 [ 1.717648] Call Trace: [ 1.717687] [c000000ff0707b80] [c000000000270d08] refresh_zone_stat_thresholds+0xb8/0x240 (unreliable) [ 1.717818] [c000000ff0707bd0] [c000000000a1e4d4] init_per_zone_wmark_min+0x94/0xb0 [ 1.717932] [c000000ff0707c30] [c00000000000b90c] do_one_initcall+0x6c/0x1d0 [ 1.718036] [c000000ff0707cf0] [c000000000d04244] kernel_init_freeable+0x294/0x384 [ 1.718150] [c000000ff0707dc0] [c00000000000c1a8] kernel_init+0x28/0x160 [ 1.718249] [c000000ff0707e30] [c000000000009968] ret_from_kernel_thread+0x5c/0x74 [ 1.718358] Instruction dump: [ 1.718408] 3fc20003 3bde4e34 3b800000 60420000 3860ffff 3fbb0001 4800001c 60420000 [ 1.718575] 3d220003 3929f8e0 7d49502 e93d9c00 <7f8a49ae> 38a30001 38800800 7ca507b4 It turns out that we can get a pgdat in the online pgdat list where pgdat->per_cpu_nodestats is NULL. On my machine the pgdats for nodes 1 and 17 are like this. All the memory is in nodes 0 and 16. With the patch below, the system boots normally. I don't guarantee to have found every place that needs a check, and it may be better to fix this by allocating space for per-cpu statistics on nodes which have no memory rather than checking at each use site. Paul. -------- mm: cope with memoryless nodes not having per-cpu statistics allocated It seems that the pgdat for nodes which have no memory will also have no per-cpu statistics space allocated, that is, pgdat->per_cpu_nodestats is NULL. Avoid crashing on machines which have memoryless nodes by checking for non-NULL pgdat->per_cpu_nodestats. Signed-off-by: Paul Mackerras <[email protected]>

Paul Mackerras and Reza Arbab reported that machines with memoryless nodes fails when vmstats are refreshed. Paul reported an oops as follows [ 1.713998] Unable to handle kernel paging request for data at address 0xff7a10000 [ 1.714164] Faulting instruction address: 0xc000000000270cd0 [ 1.714304] Oops: Kernel access of bad area, sig: 11 [#1] [ 1.714414] SMP NR_CPUS=2048 NUMA PowerNV [ 1.714530] Modules linked in: [ 1.714647] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-kvm+ torvalds#118 [ 1.714786] task: c000000ff0680010 task.stack: c000000ff0704000 [ 1.714926] NIP: c000000000270cd0 LR: c000000000270ce8 CTR: 0000000000000000 [ 1.715093] REGS: c000000ff0707900 TRAP: 0300 Not tainted (4.7.0-kvm+) [ 1.715232] MSR: 9000000102009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE,TM[E]> CR: 846b6824 XER: 20000000 [ 1.715748] CFAR: c000000000008768 DAR: 0000000ff7a10000 DSISR: 42000000 SOFTE: 1 GPR00: c000000000270d08 c000000ff0707b80 c0000000011fb200 0000000000000000 GPR04: 0000000000000800 0000000000000000 0000000000000000 0000000000000000 GPR08: ffffffffffffffff 0000000000000000 0000000ff7a10000 c00000000122aae0 GPR12: c000000000a1e440 c00000000fb80000 c00000000000c188 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c000000000cecad0 GPR24: c000000000d035b8 c000000000d6cd18 c000000000d6cd18 c000001fffa86300 GPR28: 0000000000000000 c000001fffa96300 c000000001230034 c00000000122eb18 [ 1.717484] NIP [c000000000270cd0] refresh_zone_stat_thresholds+0x80/0x240 [ 1.717568] LR [c000000000270ce8] refresh_zone_stat_thresholds+0x98/0x240 [ 1.717648] Call Trace: [ 1.717687] [c000000ff0707b80] [c000000000270d08] refresh_zone_stat_thresholds+0xb8/0x240 (unreliable) Both supplied potential fixes but one potentially misses checks and another had redundant initialisations. This version initialises per_cpu_nodestats on a per-pgdat basis instead of on a per-zone basis. Reported-by: Paul Mackerras <[email protected]> Reported-by: Reza Arbab <[email protected]> Signed-off-by: Mel Gorman <[email protected]>

Paul Mackerras and Reza Arbab reported that machines with memoryless nodes fail when vmstats are refreshed. Paul reported an oops as follows Unable to handle kernel paging request for data at address 0xff7a10000 Faulting instruction address: 0xc000000000270cd0 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-kvm+ #118 task: c000000ff0680010 task.stack: c000000ff0704000 NIP: c000000000270cd0 LR: c000000000270ce8 CTR: 0000000000000000 REGS: c000000ff0707900 TRAP: 0300 Not tainted (4.7.0-kvm+) MSR: 9000000102009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE,TM[E]> CR: 846b6824 XER: 20000000 CFAR: c000000000008768 DAR: 0000000ff7a10000 DSISR: 42000000 SOFTE: 1 NIP refresh_zone_stat_thresholds+0x80/0x240 LR refresh_zone_stat_thresholds+0x98/0x240 Call Trace: refresh_zone_stat_thresholds+0xb8/0x240 (unreliable) Both supplied potential fixes but one potentially misses checks and another had redundant initialisations. This version initialises per_cpu_nodestats on a per-pgdat basis instead of on a per-zone basis. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mel Gorman <[email protected]> Reported-by: Paul Mackerras <[email protected]> Reported-by: Reza Arbab <[email protected]> Tested-by: Reza Arbab <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>

Paul Mackerras and Reza Arbab reported that machines with memoryless nodes fail when vmstats are refreshed. Paul reported an oops as follows [ 1.713998] Unable to handle kernel paging request for data at address 0xff7a10000 [ 1.714164] Faulting instruction address: 0xc000000000270cd0 [ 1.714304] Oops: Kernel access of bad area, sig: 11 [#1] [ 1.714414] SMP NR_CPUS=2048 NUMA PowerNV [ 1.714530] Modules linked in: [ 1.714647] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-kvm+ torvalds#118 [ 1.714786] task: c000000ff0680010 task.stack: c000000ff0704000 [ 1.714926] NIP: c000000000270cd0 LR: c000000000270ce8 CTR: 0000000000000000 [ 1.715093] REGS: c000000ff0707900 TRAP: 0300 Not tainted (4.7.0-kvm+) [ 1.715232] MSR: 9000000102009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE,TM[E]> CR: 846b6824 XER: 20000000 [ 1.715748] CFAR: c000000000008768 DAR: 0000000ff7a10000 DSISR: 42000000 SOFTE: 1 GPR00: c000000000270d08 c000000ff0707b80 c0000000011fb200 0000000000000000 GPR04: 0000000000000800 0000000000000000 0000000000000000 0000000000000000 GPR08: ffffffffffffffff 0000000000000000 0000000ff7a10000 c00000000122aae0 GPR12: c000000000a1e440 c00000000fb80000 c00000000000c188 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c000000000cecad0 GPR24: c000000000d035b8 c000000000d6cd18 c000000000d6cd18 c000001fffa86300 GPR28: 0000000000000000 c000001fffa96300 c000000001230034 c00000000122eb18 [ 1.717484] NIP [c000000000270cd0] refresh_zone_stat_thresholds+0x80/0x240 [ 1.717568] LR [c000000000270ce8] refresh_zone_stat_thresholds+0x98/0x240 [ 1.717648] Call Trace: [ 1.717687] [c000000ff0707b80] [c000000000270d08] refresh_zone_stat_thresholds+0xb8/0x240 (unreliable) Both supplied potential fixes but one potentially misses checks and another had redundant initialisations. This version initialises per_cpu_nodestats on a per-pgdat basis instead of on a per-zone basis. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mel Gorman <[email protected]> Reported-by: Paul Mackerras <[email protected]> Reported-by: Reza Arbab <[email protected]> Tested-by: Reza Arbab <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

It appears that commit 75ef718 ("mm, vmstat: add infrastructure for per-node vmstats", 2016-07-28) has introduced a regression on machines that have nodes which have no memory, such as the POWER8 server that I use for testing. When I boot current upstream, I get a splat like this: [ 1.713998] Unable to handle kernel paging request for data at address 0xff7a10000 [ 1.714164] Faulting instruction address: 0xc000000000270cd0 [ 1.714304] Oops: Kernel access of bad area, sig: 11 [#1] [ 1.714414] SMP NR_CPUS=2048 NUMA PowerNV [ 1.714530] Modules linked in: [ 1.714647] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-kvm+ torvalds#118 [ 1.714786] task: c000000ff0680010 task.stack: c000000ff0704000 [ 1.714926] NIP: c000000000270cd0 LR: c000000000270ce8 CTR: 0000000000000000 [ 1.715093] REGS: c000000ff0707900 TRAP: 0300 Not tainted (4.7.0-kvm+) [ 1.715232] MSR: 9000000102009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE,TM[E]> CR: 846b6824 XER: 20000000 [ 1.715748] CFAR: c000000000008768 DAR: 0000000ff7a10000 DSISR: 42000000 SOFTE: 1 GPR00: c000000000270d08 c000000ff0707b80 c0000000011fb200 0000000000000000 GPR04: 0000000000000800 0000000000000000 0000000000000000 0000000000000000 GPR08: ffffffffffffffff 0000000000000000 0000000ff7a10000 c00000000122aae0 GPR12: c000000000a1e440 c00000000fb80000 c00000000000c188 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c000000000cecad0 GPR24: c000000000d035b8 c000000000d6cd18 c000000000d6cd18 c000001fffa86300 GPR28: 0000000000000000 c000001fffa96300 c000000001230034 c00000000122eb18 [ 1.717484] NIP [c000000000270cd0] refresh_zone_stat_thresholds+0x80/0x240 [ 1.717568] LR [c000000000270ce8] refresh_zone_stat_thresholds+0x98/0x240 [ 1.717648] Call Trace: [ 1.717687] [c000000ff0707b80] [c000000000270d08] refresh_zone_stat_thresholds+0xb8/0x240 (unreliable) [ 1.717818] [c000000ff0707bd0] [c000000000a1e4d4] init_per_zone_wmark_min+0x94/0xb0 [ 1.717932] [c000000ff0707c30] [c00000000000b90c] do_one_initcall+0x6c/0x1d0 [ 1.718036] [c000000ff0707cf0] [c000000000d04244] kernel_init_freeable+0x294/0x384 [ 1.718150] [c000000ff0707dc0] [c00000000000c1a8] kernel_init+0x28/0x160 [ 1.718249] [c000000ff0707e30] [c000000000009968] ret_from_kernel_thread+0x5c/0x74 [ 1.718358] Instruction dump: [ 1.718408] 3fc20003 3bde4e34 3b800000 60420000 3860ffff 3fbb0001 4800001c 60420000 [ 1.718575] 3d220003 3929f8e0 7d49502 e93d9c00 <7f8a49ae> 38a30001 38800800 7ca507b4 It turns out that we can get a pgdat in the online pgdat list where pgdat->per_cpu_nodestats is NULL. On my machine the pgdats for nodes 1 and 17 are like this. All the memory is in nodes 0 and 16. With the patch below, the system boots normally. I don't guarantee to have found every place that needs a check, and it may be better to fix this by allocating space for per-cpu statistics on nodes which have no memory rather than checking at each use site. Paul. -------- mm: cope with memoryless nodes not having per-cpu statistics allocated It seems that the pgdat for nodes which have no memory will also have no per-cpu statistics space allocated, that is, pgdat->per_cpu_nodestats is NULL. Avoid crashing on machines which have memoryless nodes by checking for non-NULL pgdat->per_cpu_nodestats. Signed-off-by: Paul Mackerras <[email protected]>

========================================================= [ INFO: possible irq lock inversion dependency detected ] 4.10.0-rc2-00024-g4aecec9-dirty torvalds#118 Tainted: G W --------------------------------------------------------- swapper/1/0 just changed the state of lock: (&(&sighand->siglock)->rlock){-.....}, at: [<ffffffffbd0a1bc6>] __lock_task_sighand+0xb6/0x2c0 but this lock took another, HARDIRQ-unsafe lock in the past: (ucounts_lock){+.+...} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Chain exists of: &(&sighand->siglock)->rlock --> &(&tty->ctrl_lock)->rlock --> ucounts_lock Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(ucounts_lock); local_irq_disable(); lock(&(&sighand->siglock)->rlock); lock(&(&tty->ctrl_lock)->rlock); <Interrupt> lock(&(&sighand->siglock)->rlock); *** DEADLOCK *** This patch removes a dependency between rlock and ucount_lock. Fixes: f333c70 ("pidns: Add a limit on the number of pid namespaces") Cc: [email protected] Signed-off-by: Andrei Vagin <[email protected]> Signed-off-by: Eric W. Biederman <[email protected]>

2017-01-02 11:23+0100, Dmitry Vyukov: > Hello, > > I've got the following warning while running syzkaller fuzzer: > > WARNING: CPU: 2 PID: 13257 at arch/x86/kvm/vmx.c:8633 > vmx_handle_exit+0x262b/0x38b0 arch/x86/kvm/vmx.c:8633 > vmx: unexpected exit reason 0xb > CPU: 2 PID: 13257 Comm: syz-executor7 Not tainted 4.10.0-rc1+ torvalds#118 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:15 [inline] > dump_stack+0x292/0x3a2 lib/dump_stack.c:51 > panic+0x1cb/0x3a9 kernel/panic.c:179 > __warn+0x1c4/0x1e0 kernel/panic.c:539 > warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:562 > vmx_handle_exit+0x262b/0x38b0 arch/x86/kvm/vmx.c:8633 > vcpu_enter_guest arch/x86/kvm/x86.c:6884 [inline] > vcpu_run arch/x86/kvm/x86.c:6943 [inline] > kvm_arch_vcpu_ioctl_run+0xf3d/0x45f0 arch/x86/kvm/x86.c:7101 > kvm_vcpu_ioctl+0x673/0x1120 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2569 > vfs_ioctl fs/ioctl.c:43 [inline] > do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:683 > SYSC_ioctl fs/ioctl.c:698 [inline] > SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689 > entry_SYSCALL_64_fastpath+0x1f/0xc2 > RIP: 0033:0x4438a9 > RSP: 002b:00007f935aa2fb58 EFLAGS: 00000286 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 0000000000000015 RCX: 00000000004438a9 > RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000015 > RBP: 00000000006ddb30 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000700000 > R13: 0000000000000006 R14: 0000000000000015 R15: 0000000020014000 > Dumping ftrace buffer: > (ftrace buffer empty) > Kernel Offset: disabled > > Exit reason 0xb is GETSEC instruction. This does not look harmful as > it is handled as #UD. But I think we should print a single line > message regarding non-emulated instruction as in other cases, just to > not scare cloud admins and to make syzkaller ignore it. > > FTR, a raw reproducer is here: > https://gist.githubusercontent.com/dvyukov/c762f6ea04ebbba49cdee0a6caca31b4/raw/f21deb04cdc70ae74100c12447d71bb0cd2025c7/gistfile1.txt I can't reproduce -- maybe a nested bug, which will take a while to figure out. Still, host dump at that point is useless, so the change makes sense. A guest dump would be useful (e.g. I think that GETSEC should not exit if guest CR4.SMX is disabled), but just giving the error is about as good and we want something short and rate-limited if the message can be trigerred by a guest in production ... ---8<--- We never needed the call trace and we better rate-limit if it can be triggered by a guest. Signed-off-by: Radim Krčmář <[email protected]>

commit add7c65 upstream. ========================================================= [ INFO: possible irq lock inversion dependency detected ] 4.10.0-rc2-00024-g4aecec9-dirty torvalds#118 Tainted: G W --------------------------------------------------------- swapper/1/0 just changed the state of lock: (&(&sighand->siglock)->rlock){-.....}, at: [<ffffffffbd0a1bc6>] __lock_task_sighand+0xb6/0x2c0 but this lock took another, HARDIRQ-unsafe lock in the past: (ucounts_lock){+.+...} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Chain exists of: &(&sighand->siglock)->rlock --> &(&tty->ctrl_lock)->rlock --> ucounts_lock Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(ucounts_lock); local_irq_disable(); lock(&(&sighand->siglock)->rlock); lock(&(&tty->ctrl_lock)->rlock); <Interrupt> lock(&(&sighand->siglock)->rlock); *** DEADLOCK *** This patch removes a dependency between rlock and ucount_lock. Fixes: f333c70 ("pidns: Add a limit on the number of pid namespaces") Signed-off-by: Andrei Vagin <[email protected]> Acked-by: Al Viro <[email protected]> Signed-off-by: Eric W. Biederman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

lkl tools: refactor tap code from hijack library to general library

commit 9256645 ("net/core: relax BUILD_BUG_ON in netdev_stats_to_stats64") made an attempt to read beyond the size of the source a possibility. Fix to only copy src size to dest. As dest might be bigger than src. ================================================================== BUG: KASAN: slab-out-of-bounds in netdev_stats_to_stats64+0xe/0x30 at addr ffff8801be248b20 Read of size 192 by task VBoxNetAdpCtl/6734 CPU: 1 PID: 6734 Comm: VBoxNetAdpCtl Tainted: G O 4.11.4prahal+intel+ torvalds#118 Hardware name: LENOVO 20CDCTO1WW/20CDCTO1WW, BIOS GQET52WW (1.32 ) 05/04/2017 Call Trace: dump_stack+0x63/0x86 kasan_object_err+0x1c/0x70 kasan_report+0x270/0x520 ? netdev_stats_to_stats64+0xe/0x30 ? sched_clock_cpu+0x1b/0x190 ? __module_address+0x3e/0x3b0 ? unwind_next_frame+0x1ea/0xb00 check_memory_region+0x13c/0x1a0 memcpy+0x23/0x50 netdev_stats_to_stats64+0xe/0x30 dev_get_stats+0x1b9/0x230 rtnl_fill_stats+0x44/0xc00 ? nla_put+0xc6/0x130 rtnl_fill_ifinfo+0xe9e/0x3700 ? rtnl_fill_vfinfo+0xde0/0xde0 ? sched_clock+0x9/0x10 ? sched_clock+0x9/0x10 ? sched_clock_local+0x120/0x130 ? __module_address+0x3e/0x3b0 ? unwind_next_frame+0x1ea/0xb00 ? sched_clock+0x9/0x10 ? sched_clock+0x9/0x10 ? sched_clock_cpu+0x1b/0x190 ? VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] ? depot_save_stack+0x1d8/0x4a0 ? depot_save_stack+0x34f/0x4a0 ? depot_save_stack+0x34f/0x4a0 ? save_stack+0xb1/0xd0 ? save_stack_trace+0x16/0x20 ? save_stack+0x46/0xd0 ? kasan_slab_alloc+0x12/0x20 ? __kmalloc_node_track_caller+0x10d/0x350 ? __kmalloc_reserve.isra.36+0x2c/0xc0 ? __alloc_skb+0xd0/0x560 ? rtmsg_ifinfo_build_skb+0x61/0x120 ? rtmsg_ifinfo.part.25+0x16/0xb0 ? rtmsg_ifinfo+0x47/0x70 ? register_netdev+0x15/0x30 ? vboxNetAdpOsCreate+0xc0/0x1c0 [vboxnetadp] ? vboxNetAdpCreate+0x210/0x400 [vboxnetadp] ? VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] ? do_vfs_ioctl+0x17f/0xff0 ? SyS_ioctl+0x74/0x80 ? do_syscall_64+0x182/0x390 ? __alloc_skb+0xd0/0x560 ? __alloc_skb+0xd0/0x560 ? save_stack_trace+0x16/0x20 ? init_object+0x64/0xa0 ? ___slab_alloc+0x1ae/0x5c0 ? ___slab_alloc+0x1ae/0x5c0 ? __alloc_skb+0xd0/0x560 ? sched_clock+0x9/0x10 ? kasan_unpoison_shadow+0x35/0x50 ? kasan_kmalloc+0xad/0xe0 ? __kmalloc_node_track_caller+0x246/0x350 ? __alloc_skb+0xd0/0x560 ? kasan_unpoison_shadow+0x35/0x50 ? memset+0x31/0x40 ? __alloc_skb+0x31f/0x560 ? napi_consume_skb+0x320/0x320 ? br_get_link_af_size_filtered+0xb7/0x120 [bridge] ? if_nlmsg_size+0x440/0x630 rtmsg_ifinfo_build_skb+0x83/0x120 rtmsg_ifinfo.part.25+0x16/0xb0 rtmsg_ifinfo+0x47/0x70 register_netdevice+0xa2b/0xe50 ? __kmalloc+0x171/0x2d0 ? netdev_change_features+0x80/0x80 register_netdev+0x15/0x30 vboxNetAdpOsCreate+0xc0/0x1c0 [vboxnetadp] vboxNetAdpCreate+0x210/0x400 [vboxnetadp] ? vboxNetAdpComposeMACAddress+0x1d0/0x1d0 [vboxnetadp] ? kasan_check_write+0x14/0x20 VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] ? VBoxNetAdpLinuxOpen+0x20/0x20 [vboxnetadp] ? lock_acquire+0x11c/0x270 ? __audit_syscall_entry+0x2fb/0x660 do_vfs_ioctl+0x17f/0xff0 ? __audit_syscall_entry+0x2fb/0x660 ? ioctl_preallocate+0x1d0/0x1d0 ? __audit_syscall_entry+0x2fb/0x660 ? kmem_cache_free+0xb2/0x250 ? syscall_trace_enter+0x537/0xd00 ? exit_to_usermode_loop+0x100/0x100 SyS_ioctl+0x74/0x80 ? do_sys_open+0x350/0x350 ? do_vfs_ioctl+0xff0/0xff0 do_syscall_64+0x182/0x390 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7f7e39a1ae07 RSP: 002b:00007ffc6f04c6d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffc6f04c730 RCX: 00007f7e39a1ae07 RDX: 00007ffc6f04c730 RSI: 00000000c0207601 RDI: 0000000000000007 RBP: 00007ffc6f04c700 R08: 00007ffc6f04c780 R09: 0000000000000008 R10: 0000000000000541 R11: 0000000000000206 R12: 0000000000000007 R13: 00000000c0207601 R14: 00007ffc6f04c730 R15: 0000000000000012 Object at ffff8801be248008, in cache kmalloc-4096 size: 4096 Allocated: PID = 6734 save_stack_trace+0x16/0x20 save_stack+0x46/0xd0 kasan_kmalloc+0xad/0xe0 __kmalloc+0x171/0x2d0 alloc_netdev_mqs+0x8a7/0xbe0 vboxNetAdpOsCreate+0x65/0x1c0 [vboxnetadp] vboxNetAdpCreate+0x210/0x400 [vboxnetadp] VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] do_vfs_ioctl+0x17f/0xff0 SyS_ioctl+0x74/0x80 do_syscall_64+0x182/0x390 return_from_SYSCALL_64+0x0/0x6a Freed: PID = 5600 save_stack_trace+0x16/0x20 save_stack+0x46/0xd0 kasan_slab_free+0x73/0xc0 kfree+0xe4/0x220 kvfree+0x25/0x30 single_release+0x74/0xb0 __fput+0x265/0x6b0 ____fput+0x9/0x10 task_work_run+0xd5/0x150 exit_to_usermode_loop+0xe2/0x100 do_syscall_64+0x26c/0x390 return_from_SYSCALL_64+0x0/0x6a Memory state around the buggy address: ffff8801be248a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8801be248b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8801be248b80: 00 00 00 00 00 00 00 00 00 00 00 07 fc fc fc fc ^ ffff8801be248c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8801be248c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Signed-off-by: Alban Browaeys <[email protected]> Signed-off-by: David S. Miller <[email protected]>

commit 9af9959 upstream. commit 9256645 ("net/core: relax BUILD_BUG_ON in netdev_stats_to_stats64") made an attempt to read beyond the size of the source a possibility. Fix to only copy src size to dest. As dest might be bigger than src. ================================================================== BUG: KASAN: slab-out-of-bounds in netdev_stats_to_stats64+0xe/0x30 at addr ffff8801be248b20 Read of size 192 by task VBoxNetAdpCtl/6734 CPU: 1 PID: 6734 Comm: VBoxNetAdpCtl Tainted: G O 4.11.4prahal+intel+ torvalds#118 Hardware name: LENOVO 20CDCTO1WW/20CDCTO1WW, BIOS GQET52WW (1.32 ) 05/04/2017 Call Trace: dump_stack+0x63/0x86 kasan_object_err+0x1c/0x70 kasan_report+0x270/0x520 ? netdev_stats_to_stats64+0xe/0x30 ? sched_clock_cpu+0x1b/0x190 ? __module_address+0x3e/0x3b0 ? unwind_next_frame+0x1ea/0xb00 check_memory_region+0x13c/0x1a0 memcpy+0x23/0x50 netdev_stats_to_stats64+0xe/0x30 dev_get_stats+0x1b9/0x230 rtnl_fill_stats+0x44/0xc00 ? nla_put+0xc6/0x130 rtnl_fill_ifinfo+0xe9e/0x3700 ? rtnl_fill_vfinfo+0xde0/0xde0 ? sched_clock+0x9/0x10 ? sched_clock+0x9/0x10 ? sched_clock_local+0x120/0x130 ? __module_address+0x3e/0x3b0 ? unwind_next_frame+0x1ea/0xb00 ? sched_clock+0x9/0x10 ? sched_clock+0x9/0x10 ? sched_clock_cpu+0x1b/0x190 ? VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] ? depot_save_stack+0x1d8/0x4a0 ? depot_save_stack+0x34f/0x4a0 ? depot_save_stack+0x34f/0x4a0 ? save_stack+0xb1/0xd0 ? save_stack_trace+0x16/0x20 ? save_stack+0x46/0xd0 ? kasan_slab_alloc+0x12/0x20 ? __kmalloc_node_track_caller+0x10d/0x350 ? __kmalloc_reserve.isra.36+0x2c/0xc0 ? __alloc_skb+0xd0/0x560 ? rtmsg_ifinfo_build_skb+0x61/0x120 ? rtmsg_ifinfo.part.25+0x16/0xb0 ? rtmsg_ifinfo+0x47/0x70 ? register_netdev+0x15/0x30 ? vboxNetAdpOsCreate+0xc0/0x1c0 [vboxnetadp] ? vboxNetAdpCreate+0x210/0x400 [vboxnetadp] ? VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] ? do_vfs_ioctl+0x17f/0xff0 ? SyS_ioctl+0x74/0x80 ? do_syscall_64+0x182/0x390 ? __alloc_skb+0xd0/0x560 ? __alloc_skb+0xd0/0x560 ? save_stack_trace+0x16/0x20 ? init_object+0x64/0xa0 ? ___slab_alloc+0x1ae/0x5c0 ? ___slab_alloc+0x1ae/0x5c0 ? __alloc_skb+0xd0/0x560 ? sched_clock+0x9/0x10 ? kasan_unpoison_shadow+0x35/0x50 ? kasan_kmalloc+0xad/0xe0 ? __kmalloc_node_track_caller+0x246/0x350 ? __alloc_skb+0xd0/0x560 ? kasan_unpoison_shadow+0x35/0x50 ? memset+0x31/0x40 ? __alloc_skb+0x31f/0x560 ? napi_consume_skb+0x320/0x320 ? br_get_link_af_size_filtered+0xb7/0x120 [bridge] ? if_nlmsg_size+0x440/0x630 rtmsg_ifinfo_build_skb+0x83/0x120 rtmsg_ifinfo.part.25+0x16/0xb0 rtmsg_ifinfo+0x47/0x70 register_netdevice+0xa2b/0xe50 ? __kmalloc+0x171/0x2d0 ? netdev_change_features+0x80/0x80 register_netdev+0x15/0x30 vboxNetAdpOsCreate+0xc0/0x1c0 [vboxnetadp] vboxNetAdpCreate+0x210/0x400 [vboxnetadp] ? vboxNetAdpComposeMACAddress+0x1d0/0x1d0 [vboxnetadp] ? kasan_check_write+0x14/0x20 VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] ? VBoxNetAdpLinuxOpen+0x20/0x20 [vboxnetadp] ? lock_acquire+0x11c/0x270 ? __audit_syscall_entry+0x2fb/0x660 do_vfs_ioctl+0x17f/0xff0 ? __audit_syscall_entry+0x2fb/0x660 ? ioctl_preallocate+0x1d0/0x1d0 ? __audit_syscall_entry+0x2fb/0x660 ? kmem_cache_free+0xb2/0x250 ? syscall_trace_enter+0x537/0xd00 ? exit_to_usermode_loop+0x100/0x100 SyS_ioctl+0x74/0x80 ? do_sys_open+0x350/0x350 ? do_vfs_ioctl+0xff0/0xff0 do_syscall_64+0x182/0x390 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7f7e39a1ae07 RSP: 002b:00007ffc6f04c6d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffc6f04c730 RCX: 00007f7e39a1ae07 RDX: 00007ffc6f04c730 RSI: 00000000c0207601 RDI: 0000000000000007 RBP: 00007ffc6f04c700 R08: 00007ffc6f04c780 R09: 0000000000000008 R10: 0000000000000541 R11: 0000000000000206 R12: 0000000000000007 R13: 00000000c0207601 R14: 00007ffc6f04c730 R15: 0000000000000012 Object at ffff8801be248008, in cache kmalloc-4096 size: 4096 Allocated: PID = 6734 save_stack_trace+0x16/0x20 save_stack+0x46/0xd0 kasan_kmalloc+0xad/0xe0 __kmalloc+0x171/0x2d0 alloc_netdev_mqs+0x8a7/0xbe0 vboxNetAdpOsCreate+0x65/0x1c0 [vboxnetadp] vboxNetAdpCreate+0x210/0x400 [vboxnetadp] VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] do_vfs_ioctl+0x17f/0xff0 SyS_ioctl+0x74/0x80 do_syscall_64+0x182/0x390 return_from_SYSCALL_64+0x0/0x6a Freed: PID = 5600 save_stack_trace+0x16/0x20 save_stack+0x46/0xd0 kasan_slab_free+0x73/0xc0 kfree+0xe4/0x220 kvfree+0x25/0x30 single_release+0x74/0xb0 __fput+0x265/0x6b0 ____fput+0x9/0x10 task_work_run+0xd5/0x150 exit_to_usermode_loop+0xe2/0x100 do_syscall_64+0x26c/0x390 return_from_SYSCALL_64+0x0/0x6a Memory state around the buggy address: ffff8801be248a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8801be248b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8801be248b80: 00 00 00 00 00 00 00 00 00 00 00 07 fc fc fc fc ^ ffff8801be248c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8801be248c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Signed-off-by: Alban Browaeys <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit 9af9959 ] commit 9256645 ("net/core: relax BUILD_BUG_ON in netdev_stats_to_stats64") made an attempt to read beyond the size of the source a possibility. Fix to only copy src size to dest. As dest might be bigger than src. ================================================================== BUG: KASAN: slab-out-of-bounds in netdev_stats_to_stats64+0xe/0x30 at addr ffff8801be248b20 Read of size 192 by task VBoxNetAdpCtl/6734 CPU: 1 PID: 6734 Comm: VBoxNetAdpCtl Tainted: G O 4.11.4prahal+intel+ #118 Hardware name: LENOVO 20CDCTO1WW/20CDCTO1WW, BIOS GQET52WW (1.32 ) 05/04/2017 Call Trace: dump_stack+0x63/0x86 kasan_object_err+0x1c/0x70 kasan_report+0x270/0x520 ? netdev_stats_to_stats64+0xe/0x30 ? sched_clock_cpu+0x1b/0x190 ? __module_address+0x3e/0x3b0 ? unwind_next_frame+0x1ea/0xb00 check_memory_region+0x13c/0x1a0 memcpy+0x23/0x50 netdev_stats_to_stats64+0xe/0x30 dev_get_stats+0x1b9/0x230 rtnl_fill_stats+0x44/0xc00 ? nla_put+0xc6/0x130 rtnl_fill_ifinfo+0xe9e/0x3700 ? rtnl_fill_vfinfo+0xde0/0xde0 ? sched_clock+0x9/0x10 ? sched_clock+0x9/0x10 ? sched_clock_local+0x120/0x130 ? __module_address+0x3e/0x3b0 ? unwind_next_frame+0x1ea/0xb00 ? sched_clock+0x9/0x10 ? sched_clock+0x9/0x10 ? sched_clock_cpu+0x1b/0x190 ? VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] ? depot_save_stack+0x1d8/0x4a0 ? depot_save_stack+0x34f/0x4a0 ? depot_save_stack+0x34f/0x4a0 ? save_stack+0xb1/0xd0 ? save_stack_trace+0x16/0x20 ? save_stack+0x46/0xd0 ? kasan_slab_alloc+0x12/0x20 ? __kmalloc_node_track_caller+0x10d/0x350 ? __kmalloc_reserve.isra.36+0x2c/0xc0 ? __alloc_skb+0xd0/0x560 ? rtmsg_ifinfo_build_skb+0x61/0x120 ? rtmsg_ifinfo.part.25+0x16/0xb0 ? rtmsg_ifinfo+0x47/0x70 ? register_netdev+0x15/0x30 ? vboxNetAdpOsCreate+0xc0/0x1c0 [vboxnetadp] ? vboxNetAdpCreate+0x210/0x400 [vboxnetadp] ? VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] ? do_vfs_ioctl+0x17f/0xff0 ? SyS_ioctl+0x74/0x80 ? do_syscall_64+0x182/0x390 ? __alloc_skb+0xd0/0x560 ? __alloc_skb+0xd0/0x560 ? save_stack_trace+0x16/0x20 ? init_object+0x64/0xa0 ? ___slab_alloc+0x1ae/0x5c0 ? ___slab_alloc+0x1ae/0x5c0 ? __alloc_skb+0xd0/0x560 ? sched_clock+0x9/0x10 ? kasan_unpoison_shadow+0x35/0x50 ? kasan_kmalloc+0xad/0xe0 ? __kmalloc_node_track_caller+0x246/0x350 ? __alloc_skb+0xd0/0x560 ? kasan_unpoison_shadow+0x35/0x50 ? memset+0x31/0x40 ? __alloc_skb+0x31f/0x560 ? napi_consume_skb+0x320/0x320 ? br_get_link_af_size_filtered+0xb7/0x120 [bridge] ? if_nlmsg_size+0x440/0x630 rtmsg_ifinfo_build_skb+0x83/0x120 rtmsg_ifinfo.part.25+0x16/0xb0 rtmsg_ifinfo+0x47/0x70 register_netdevice+0xa2b/0xe50 ? __kmalloc+0x171/0x2d0 ? netdev_change_features+0x80/0x80 register_netdev+0x15/0x30 vboxNetAdpOsCreate+0xc0/0x1c0 [vboxnetadp] vboxNetAdpCreate+0x210/0x400 [vboxnetadp] ? vboxNetAdpComposeMACAddress+0x1d0/0x1d0 [vboxnetadp] ? kasan_check_write+0x14/0x20 VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] ? VBoxNetAdpLinuxOpen+0x20/0x20 [vboxnetadp] ? lock_acquire+0x11c/0x270 ? __audit_syscall_entry+0x2fb/0x660 do_vfs_ioctl+0x17f/0xff0 ? __audit_syscall_entry+0x2fb/0x660 ? ioctl_preallocate+0x1d0/0x1d0 ? __audit_syscall_entry+0x2fb/0x660 ? kmem_cache_free+0xb2/0x250 ? syscall_trace_enter+0x537/0xd00 ? exit_to_usermode_loop+0x100/0x100 SyS_ioctl+0x74/0x80 ? do_sys_open+0x350/0x350 ? do_vfs_ioctl+0xff0/0xff0 do_syscall_64+0x182/0x390 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7f7e39a1ae07 RSP: 002b:00007ffc6f04c6d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffc6f04c730 RCX: 00007f7e39a1ae07 RDX: 00007ffc6f04c730 RSI: 00000000c0207601 RDI: 0000000000000007 RBP: 00007ffc6f04c700 R08: 00007ffc6f04c780 R09: 0000000000000008 R10: 0000000000000541 R11: 0000000000000206 R12: 0000000000000007 R13: 00000000c0207601 R14: 00007ffc6f04c730 R15: 0000000000000012 Object at ffff8801be248008, in cache kmalloc-4096 size: 4096 Allocated: PID = 6734 save_stack_trace+0x16/0x20 save_stack+0x46/0xd0 kasan_kmalloc+0xad/0xe0 __kmalloc+0x171/0x2d0 alloc_netdev_mqs+0x8a7/0xbe0 vboxNetAdpOsCreate+0x65/0x1c0 [vboxnetadp] vboxNetAdpCreate+0x210/0x400 [vboxnetadp] VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp] do_vfs_ioctl+0x17f/0xff0 SyS_ioctl+0x74/0x80 do_syscall_64+0x182/0x390 return_from_SYSCALL_64+0x0/0x6a Freed: PID = 5600 save_stack_trace+0x16/0x20 save_stack+0x46/0xd0 kasan_slab_free+0x73/0xc0 kfree+0xe4/0x220 kvfree+0x25/0x30 single_release+0x74/0xb0 __fput+0x265/0x6b0 ____fput+0x9/0x10 task_work_run+0xd5/0x150 exit_to_usermode_loop+0xe2/0x100 do_syscall_64+0x26c/0x390 return_from_SYSCALL_64+0x0/0x6a Memory state around the buggy address: ffff8801be248a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8801be248b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8801be248b80: 00 00 00 00 00 00 00 00 00 00 00 07 fc fc fc fc ^ ffff8801be248c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8801be248c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Signed-off-by: Alban Browaeys <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

This patch replaces rcu_deference() with rcu_dereference_bh() in ipv6_route_seq_next() to avoid the following warning: [ 19.431685] WARNING: suspicious RCU usage [ 19.433451] 4.14.0-rc3-00914-g66f5d6c torvalds#118 Not tainted [ 19.435509] ----------------------------- [ 19.437267] net/ipv6/ip6_fib.c:2259 suspicious rcu_dereference_check() usage! [ 19.440790] [ 19.440790] other info that might help us debug this: [ 19.440790] [ 19.444734] [ 19.444734] rcu_scheduler_active = 2, debug_locks = 1 [ 19.447757] 2 locks held by odhcpd/3720: [ 19.449480] #0: (&p->lock){+.+.}, at: [<ffffffffb1231f7d>] seq_read+0x3c/0x333 [ 19.452720] #1: (rcu_read_lock_bh){....}, at: [<ffffffffb1d2b984>] ipv6_route_seq_start+0x5/0xfd [ 19.456323] [ 19.456323] stack backtrace: [ 19.458812] CPU: 0 PID: 3720 Comm: odhcpd Not tainted 4.14.0-rc3-00914-g66f5d6c torvalds#118 [ 19.462042] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 19.465414] Call Trace: [ 19.466788] dump_stack+0x86/0xc0 [ 19.468358] lockdep_rcu_suspicious+0xea/0xf3 [ 19.470183] ipv6_route_seq_next+0x71/0x164 [ 19.471963] seq_read+0x244/0x333 [ 19.473522] proc_reg_read+0x48/0x67 [ 19.475152] ? proc_reg_write+0x67/0x67 [ 19.476862] __vfs_read+0x26/0x10b [ 19.478463] ? __might_fault+0x37/0x84 [ 19.480148] vfs_read+0xba/0x146 [ 19.481690] SyS_read+0x51/0x8e [ 19.483197] do_int80_syscall_32+0x66/0x15a [ 19.484969] entry_INT80_compat+0x32/0x50 [ 19.486707] RIP: 0023:0xf7f0be8e [ 19.488244] RSP: 002b:00000000ffa75d04 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ 19.491431] RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 0000000008056068 [ 19.493886] RDX: 0000000000001000 RSI: 0000000008056008 RDI: 0000000000001000 [ 19.496331] RBP: 00000000000001ff R08: 0000000000000000 R09: 0000000000000000 [ 19.498768] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 19.501217] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Fixes: 66f5d6c ("ipv6: replace rwlock with rcu and spinlock in fib6_table") Reported-by: Xiaolong Ye <[email protected]> Signed-off-by: Wei Wang <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>

Found using DEBUG_ATOMIC_SLEEP while submitting an AIO read operation: [ 100.853642] BUG: sleeping function called from invalid context at mm/slab.h:421 [ 100.861148] in_atomic(): 1, irqs_disabled(): 1, pid: 1880, name: python [ 100.867954] 2 locks held by python/1880: [ 100.867961] #0: (&epfile->mutex){....}, at: [<f8188627>] ffs_mutex_lock+0x27/0x30 [usb_f_fs] [ 100.868020] #1: (&(&ffs->eps_lock)->rlock){....}, at: [<f818ad4b>] ffs_epfile_io.isra.17+0x24b/0x590 [usb_f_fs] [ 100.868076] CPU: 1 PID: 1880 Comm: python Not tainted 4.14.0-edison+ torvalds#118 [ 100.868085] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 [ 100.868093] Call Trace: [ 100.868122] dump_stack+0x47/0x62 [ 100.868156] ___might_sleep+0xfd/0x110 [ 100.868182] __might_sleep+0x68/0x70 [ 100.868217] kmem_cache_alloc_trace+0x4b/0x200 [ 100.868248] ? dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3] [ 100.868302] dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3] [ 100.868343] usb_ep_alloc_request+0x16/0xc0 [udc_core] [ 100.868386] ffs_epfile_io.isra.17+0x444/0x590 [usb_f_fs] [ 100.868424] ? _raw_spin_unlock_irqrestore+0x27/0x40 [ 100.868457] ? kiocb_set_cancel_fn+0x57/0x60 [ 100.868477] ? ffs_ep0_poll+0xc0/0xc0 [usb_f_fs] [ 100.868512] ffs_epfile_read_iter+0xfe/0x157 [usb_f_fs] [ 100.868551] ? security_file_permission+0x9c/0xd0 [ 100.868587] ? rw_verify_area+0xac/0x120 [ 100.868633] aio_read+0x9d/0x100 [ 100.868692] ? __fget+0xa2/0xd0 [ 100.868727] ? __might_sleep+0x68/0x70 [ 100.868763] SyS_io_submit+0x471/0x680 [ 100.868878] do_int80_syscall_32+0x4e/0xd0 [ 100.868921] entry_INT80_32+0x2a/0x2a [ 100.868932] EIP: 0xb7fbb676 [ 100.868941] EFLAGS: 00000292 CPU: 1 [ 100.868951] EAX: ffffffda EBX: b7aa2000 ECX: 00000002 EDX: b7af8368 [ 100.868961] ESI: b7fbb660 EDI: b7aab000 EBP: bfb6c658 ESP: bfb6c638 [ 100.868973] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b Signed-off-by: Vincent Pelletier <[email protected]>

commit 30bf90c upstream. Found using DEBUG_ATOMIC_SLEEP while submitting an AIO read operation: [ 100.853642] BUG: sleeping function called from invalid context at mm/slab.h:421 [ 100.861148] in_atomic(): 1, irqs_disabled(): 1, pid: 1880, name: python [ 100.867954] 2 locks held by python/1880: [ 100.867961] #0: (&epfile->mutex){....}, at: [<f8188627>] ffs_mutex_lock+0x27/0x30 [usb_f_fs] [ 100.868020] #1: (&(&ffs->eps_lock)->rlock){....}, at: [<f818ad4b>] ffs_epfile_io.isra.17+0x24b/0x590 [usb_f_fs] [ 100.868076] CPU: 1 PID: 1880 Comm: python Not tainted 4.14.0-edison+ torvalds#118 [ 100.868085] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 [ 100.868093] Call Trace: [ 100.868122] dump_stack+0x47/0x62 [ 100.868156] ___might_sleep+0xfd/0x110 [ 100.868182] __might_sleep+0x68/0x70 [ 100.868217] kmem_cache_alloc_trace+0x4b/0x200 [ 100.868248] ? dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3] [ 100.868302] dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3] [ 100.868343] usb_ep_alloc_request+0x16/0xc0 [udc_core] [ 100.868386] ffs_epfile_io.isra.17+0x444/0x590 [usb_f_fs] [ 100.868424] ? _raw_spin_unlock_irqrestore+0x27/0x40 [ 100.868457] ? kiocb_set_cancel_fn+0x57/0x60 [ 100.868477] ? ffs_ep0_poll+0xc0/0xc0 [usb_f_fs] [ 100.868512] ffs_epfile_read_iter+0xfe/0x157 [usb_f_fs] [ 100.868551] ? security_file_permission+0x9c/0xd0 [ 100.868587] ? rw_verify_area+0xac/0x120 [ 100.868633] aio_read+0x9d/0x100 [ 100.868692] ? __fget+0xa2/0xd0 [ 100.868727] ? __might_sleep+0x68/0x70 [ 100.868763] SyS_io_submit+0x471/0x680 [ 100.868878] do_int80_syscall_32+0x4e/0xd0 [ 100.868921] entry_INT80_32+0x2a/0x2a [ 100.868932] EIP: 0xb7fbb676 [ 100.868941] EFLAGS: 00000292 CPU: 1 [ 100.868951] EAX: ffffffda EBX: b7aa2000 ECX: 00000002 EDX: b7af8368 [ 100.868961] ESI: b7fbb660 EDI: b7aab000 EBP: bfb6c658 ESP: bfb6c638 [ 100.868973] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b Signed-off-by: Vincent Pelletier <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Siqi Lin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error because the value of 'lineclock' and 'frameclock' will be zero. Fix this by checking whether 'pixclock' is zero in kyrofb_check_var(). The following log reveals it: [ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0-dirty torvalds#118 [ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80 [ 103.074045] Call Trace: [ 103.074048] ? ___might_sleep+0x1ee/0x2d0 [ 103.074060] ? kyrofb_ioctl+0x330/0x330 [ 103.074069] fb_set_var+0x5bf/0xeb0 [ 103.074078] ? fb_blank+0x1a0/0x1a0 [ 103.074085] ? lock_acquire+0x3bd/0x530 [ 103.074094] ? lock_release+0x810/0x810 [ 103.074103] ? ___might_sleep+0x1ee/0x2d0 [ 103.074114] ? __mutex_lock+0x620/0x1190 [ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0 [ 103.074137] do_fb_ioctl+0x31e/0x700 [ 103.074144] ? fb_getput_cmap+0x280/0x280 [ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0 [ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80 [ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0 [ 103.074199] ? vfs_fileattr_set+0xb60/0xb60 [ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074216] ? lock_release+0x483/0x810 [ 103.074224] ? __fget_files+0x217/0x3d0 [ 103.074234] ? __fget_files+0x239/0x3d0 [ 103.074243] ? do_fb_ioctl+0x700/0x700 [ 103.074250] fb_ioctl+0xe6/0x130 Signed-off-by: Zheyu Ma <[email protected]>

The userspace program could pass any values to the driver through ioctl() interface. if the driver doesn't check the value of 'pixclock', it may cause divide error because the value of 'lineclock' and 'frameclock' will be zero. Fix this by checking whether 'pixclock' is zero in kyrofb_check_var(). The following log reveals it: [ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0-dirty torvalds#118 [ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80 [ 103.074045] Call Trace: [ 103.074048] ? ___might_sleep+0x1ee/0x2d0 [ 103.074060] ? kyrofb_ioctl+0x330/0x330 [ 103.074069] fb_set_var+0x5bf/0xeb0 [ 103.074078] ? fb_blank+0x1a0/0x1a0 [ 103.074085] ? lock_acquire+0x3bd/0x530 [ 103.074094] ? lock_release+0x810/0x810 [ 103.074103] ? ___might_sleep+0x1ee/0x2d0 [ 103.074114] ? __mutex_lock+0x620/0x1190 [ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0 [ 103.074137] do_fb_ioctl+0x31e/0x700 [ 103.074144] ? fb_getput_cmap+0x280/0x280 [ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0 [ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80 [ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0 [ 103.074199] ? vfs_fileattr_set+0xb60/0xb60 [ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074216] ? lock_release+0x483/0x810 [ 103.074224] ? __fget_files+0x217/0x3d0 [ 103.074234] ? __fget_files+0x239/0x3d0 [ 103.074243] ? do_fb_ioctl+0x700/0x700 [ 103.074250] fb_ioctl+0xe6/0x130 Signed-off-by: Zheyu Ma <[email protected]>

The userspace program could pass any values to the driver through ioctl() interface. if the driver doesn't check the value of 'pixclock', it may cause divide error because the value of 'lineclock' and 'frameclock' will be zero. Fix this by checking whether 'pixclock' is zero in kyrofb_check_var(). The following log reveals it: [ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0-dirty torvalds#118 [ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80 [ 103.074045] Call Trace: [ 103.074048] ? ___might_sleep+0x1ee/0x2d0 [ 103.074060] ? kyrofb_ioctl+0x330/0x330 [ 103.074069] fb_set_var+0x5bf/0xeb0 [ 103.074078] ? fb_blank+0x1a0/0x1a0 [ 103.074085] ? lock_acquire+0x3bd/0x530 [ 103.074094] ? lock_release+0x810/0x810 [ 103.074103] ? ___might_sleep+0x1ee/0x2d0 [ 103.074114] ? __mutex_lock+0x620/0x1190 [ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0 [ 103.074137] do_fb_ioctl+0x31e/0x700 [ 103.074144] ? fb_getput_cmap+0x280/0x280 [ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0 [ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80 [ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0 [ 103.074199] ? vfs_fileattr_set+0xb60/0xb60 [ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074216] ? lock_release+0x483/0x810 [ 103.074224] ? __fget_files+0x217/0x3d0 [ 103.074234] ? __fget_files+0x239/0x3d0 [ 103.074243] ? do_fb_ioctl+0x700/0x700 [ 103.074250] fb_ioctl+0xe6/0x130 Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

[ Upstream commit 1520b4b ] The userspace program could pass any values to the driver through ioctl() interface. if the driver doesn't check the value of 'pixclock', it may cause divide error because the value of 'lineclock' and 'frameclock' will be zero. Fix this by checking whether 'pixclock' is zero in kyrofb_check_var(). The following log reveals it: [ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0-dirty torvalds#118 [ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80 [ 103.074045] Call Trace: [ 103.074048] ? ___might_sleep+0x1ee/0x2d0 [ 103.074060] ? kyrofb_ioctl+0x330/0x330 [ 103.074069] fb_set_var+0x5bf/0xeb0 [ 103.074078] ? fb_blank+0x1a0/0x1a0 [ 103.074085] ? lock_acquire+0x3bd/0x530 [ 103.074094] ? lock_release+0x810/0x810 [ 103.074103] ? ___might_sleep+0x1ee/0x2d0 [ 103.074114] ? __mutex_lock+0x620/0x1190 [ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0 [ 103.074137] do_fb_ioctl+0x31e/0x700 [ 103.074144] ? fb_getput_cmap+0x280/0x280 [ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0 [ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80 [ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0 [ 103.074199] ? vfs_fileattr_set+0xb60/0xb60 [ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074216] ? lock_release+0x483/0x810 [ 103.074224] ? __fget_files+0x217/0x3d0 [ 103.074234] ? __fget_files+0x239/0x3d0 [ 103.074243] ? do_fb_ioctl+0x700/0x700 [ 103.074250] fb_ioctl+0xe6/0x130 Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>

PD#150472: driver defect clean up: torvalds#118 torvalds#147 Change-Id: I5eb405b884e05d42f238db43c9d3a16255f06d84 Signed-off-by: Pengcheng Chen <[email protected]>

scx: Convert remaining testcases to use new framework

With CONFIG_LTO_CLANG_THIN enabled, with some of previous version of kernel code base ([1]), I hit the following error: test_ksyms:PASS:kallsyms_fopen 0 nsec test_ksyms:FAIL:ksym_find symbol 'bpf_link_fops' not found torvalds#118 ksyms:FAIL The reason is that 'bpf_link_fops' is renamed to bpf_link_fops.llvm.8325593422554671469 Due to cross-file inlining, the static variable 'bpf_link_fops' in syscall.c is used by a function in another file. To avoid potential duplicated names, the llvm added suffix '.llvm.<hash>' ([2]) to 'bpf_link_fops' variable. Such renaming caused a problem in libbpf if 'bpf_link_fops' is used in bpf prog as a ksym but 'bpf_link_fops' does not match any symbol in /proc/kallsyms. To fix this issue, libbpf needs to understand that suffix '.llvm.<hash>' is caused by clang lto kernel and to process such symbols properly. With latest bpf-next code base built with CONFIG_LTO_CLANG_THIN, I cannot reproduce the above failure any more. But such an issue could happen with other symbols or in the future for bpf_link_fops symbol. For example, with my current kernel, I got the following from /proc/kallsyms: ffffffff84782154 d __func__.net_ratelimit.llvm.6135436931166841955 ffffffff85f0a500 d tk_core.llvm.726630847145216431 ffffffff85fdb960 d __fs_reclaim_map.llvm.10487989720912350772 ffffffff864c7300 d fake_dst_ops.llvm.54750082607048300 I could not easily create a selftest to test newly-added libbpf functionality with a static C test since I do not know which symbol is cross-file inlined. But based on my particular kernel, the following test change can run successfully. > diff --git a/tools/testing/selftests/bpf/prog_tests/ksyms.c b/tools/testing/selftests/bpf/prog_tests/ksyms.c > index 6a86d1f07800..904a103f7b1d 100644 > --- a/tools/testing/selftests/bpf/prog_tests/ksyms.c > +++ b/tools/testing/selftests/bpf/prog_tests/ksyms.c > @@ -42,6 +42,7 @@ void test_ksyms(void) > ASSERT_EQ(data->out__bpf_link_fops, link_fops_addr, "bpf_link_fops"); > ASSERT_EQ(data->out__bpf_link_fops1, 0, "bpf_link_fops1"); > ASSERT_EQ(data->out__btf_size, btf_size, "btf_size"); > + ASSERT_NEQ(data->out__fake_dst_ops, 0, "fake_dst_ops"); > ASSERT_EQ(data->out__per_cpu_start, per_cpu_start_addr, "__per_cpu_start"); > > cleanup: > diff --git a/tools/testing/selftests/bpf/progs/test_ksyms.c b/tools/testing/selftests/bpf/progs/test_ksyms.c > index 6c9cbb5a3bdf..fe91eef54b66 100644 > --- a/tools/testing/selftests/bpf/progs/test_ksyms.c > +++ b/tools/testing/selftests/bpf/progs/test_ksyms.c > @@ -9,11 +9,13 @@ __u64 out__bpf_link_fops = -1; > __u64 out__bpf_link_fops1 = -1; > __u64 out__btf_size = -1; > __u64 out__per_cpu_start = -1; > +__u64 out__fake_dst_ops = -1; > > extern const void bpf_link_fops __ksym; > extern const void __start_BTF __ksym; > extern const void __stop_BTF __ksym; > extern const void __per_cpu_start __ksym; > +extern const void fake_dst_ops __ksym; > /* non-existing symbol, weak, default to zero */ > extern const void bpf_link_fops1 __ksym __weak; > > @@ -23,6 +25,7 @@ int handler(const void *ctx) > out__bpf_link_fops = (__u64)&bpf_link_fops; > out__btf_size = (__u64)(&__stop_BTF - &__start_BTF); > out__per_cpu_start = (__u64)&__per_cpu_start; > + out__fake_dst_ops = (__u64)&fake_dst_ops; > > out__bpf_link_fops1 = (__u64)&bpf_link_fops1; This patch fixed the issue in libbpf such that the suffix '.llvm.<hash>' will be ignored during comparison of bpf prog ksym vs. symbols in /proc/kallsyms, this resolved the issue. Currently, only static variables in /proc/kallsyms are checked with '.llvm.<hash>' suffix since in bpf programs function ksyms with '.llvm.<hash>' suffix are most likely kfunc's and unlikely to be cross-file inlined. Note that currently kernel does not support gcc build with lto. [1] https://lore.kernel.org/bpf/[email protected]/ [2] https://github.com/llvm/llvm-project/blob/release/18.x/llvm/include/llvm/IR/ModuleSummaryIndex.h#L1714-L1719 Signed-off-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>

This reverts commit 5ae263a6ca027c4b79c4dfacfcf4eca8209eefd0, because disambiguating the per-thread lock is not as useless as it seemed at first. Fixes this regression when CONFIG_DEBUG_HARD_SPINLOCKS is on: [ 52.090120] [ 52.090129] ============================================ [ 52.090134] WARNING: possible recursive locking detected [ 52.090139] 5.10.199-00830-g18654c202dd6 torvalds#118 Not tainted [ 52.090143] -------------------------------------------- [ 52.090147] monitor-dlk-A:4/493 is trying to acquire lock: [ 52.090152] c34a7010 (__RAWLOCK(&thread->lock)){-.-.}-{0:0}, at: evl_lock_mutex_timeout+0x4e0/0x870 [ 52.090169] [ 52.090173] but task is already holding lock: [ 52.090176] c34a5810 (__RAWLOCK(&thread->lock)){-.-.}-{0:0}, at: evl_lock_mutex_timeout+0x4e0/0x870 [ 52.090192] [ 52.090195] other info that might help us debug this: [ 52.090199] Possible unsafe locking scenario: [ 52.090202] [ 52.090205] CPU0 [ 52.090208] ---- [ 52.090211] lock(__RAWLOCK(&thread->lock)); [ 52.090221] lock(__RAWLOCK(&thread->lock)); [ 52.090229] [ 52.090233] *** DEADLOCK *** [ 52.090235] [ 52.090239] May be due to missing lock nesting notation [ 52.090242] [ 52.090246] 2 locks held by monitor-dlk-A:4/493: [ 52.090249] #0: c2d030d4 (&mon->mutex){....}-{0:0}, at: evl_lock_mutex_timeout+0x104/0x870 [ 52.090267] #1: c34a5810 (__RAWLOCK(&thread->lock)){-.-.}-{0:0}, at: evl_lock_mutex_timeout+0x4e0/0x870 Signed-off-by: Philippe Gerum <[email protected]>

Fix typo

bedc5a6

EctoCosmonaut pushed a commit to EctoCosmonaut/linux that referenced this pull request Jan 13, 2016

Merge pull request torvalds#118 from hkallweit/odroidxu4-v4.2-rc1

4e537d2

ODROID-XU3/XU4: Enable PWM output for status LEDs in dts under 4.2rc1

laijs pushed a commit to laijs/linux that referenced this pull request Feb 13, 2017

Merge pull request torvalds#118 from libos-nuse/upstream-refactor-tap

d863e04

lkl tools: refactor tap code from hijack library to general library

akiernan pushed a commit to zuma-array/linux that referenced this pull request Nov 3, 2022

osd: clean up deadcode

16db9f0

PD#150472: driver defect clean up: torvalds#118 torvalds#147 Change-Id: I5eb405b884e05d42f238db43c9d3a16255f06d84 Signed-off-by: Pengcheng Chen <[email protected]>

akiernan pushed a commit to zuma-array/linux that referenced this pull request Nov 4, 2022

osd: clean up deadcode

feb979c

PD#150472: driver defect clean up: torvalds#118 torvalds#147 Change-Id: I5eb405b884e05d42f238db43c9d3a16255f06d84 Signed-off-by: Pengcheng Chen <[email protected]>

logic10492 pushed a commit to logic10492/linux-amd-zen2 that referenced this pull request Jan 18, 2024

Merge pull request torvalds#118 from sched-ext/refactor_tests

7592388

scx: Convert remaining testcases to use new framework

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix typo #118

Fix typo #118

zhenyuchen commented Sep 12, 2014

frankcash commented Sep 12, 2014

captainepoch commented Sep 12, 2014

Fix typo #118

Are you sure you want to change the base?

Fix typo #118

Conversation

zhenyuchen commented Sep 12, 2014

frankcash commented Sep 12, 2014

captainepoch commented Sep 12, 2014