Searched hist:2765 (Results 1 - 17 of 17) sorted by relevance
/linux-master/arch/sparc/include/asm/ | ||
H A D | parport_64.h | diff 9f2072ca Wed Apr 10 07:35:06 MDT 2024 Uwe Kleine-König <u.kleine-koenig@pengutronix.de> sparc: parport: Convert to platform remove callback returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andreas Larsson <andreas@gaisler.com> Link: https://lore.kernel.org/r/2765e090dba2d99f92e16c92b6aa55090aae053b.1712755381.git.u.kleine-koenig@pengutronix.de Signed-off-by: Andreas Larsson <andreas@gaisler.com> |
/linux-master/drivers/scsi/aic7xxx/ | ||
H A D | Kconfig.aic79xx | diff a2ae85df Sun Aug 07 00:32:07 MDT 2005 akpm@osdl.org <akpm@osdl.org> [SCSI] aic79xx: needs to select SPI_TRANSPORT_ATTRS without it you get this failure: drivers/built-in.o(.text+0xdcccd): In function `ahd_linux_slave_configure': drivers/scsi/aic7xxx/aic79xx_osm.c:636: undefined reference to `spi_dv_device' drivers/built-in.o(.text+0xdd7b1): In function `ahd_send_async': drivers/scsi/aic7xxx/aic79xx_osm.c:1652: undefined reference to `spi_display_xfer_agreement' drivers/built-in.o(.init.text+0x7b4d): In function `ahd_linux_init': drivers/scsi/aic7xxx/aic79xx_osm.c:2765: undefined reference to `spi_attach_transport' drivers/built-in.o(.init.text+0x7c94):drivers/scsi/aic7xxx/aic79xx_osm.c:2774: undefined reference to `spi_release_transport' drivers/built-in.o(.exit.text+0x72c): In function `ahd_linux_exit': drivers/scsi/aic7xxx/aic79xx_osm.c:2783: undefined reference to `spi_release_transport' Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> |
/linux-master/arch/parisc/include/uapi/asm/ | ||
H A D | unistd.h | diff 2765b3ed Thu Jun 28 09:41:58 MDT 2018 Helge Deller <deller@gmx.de> parisc: Wire up io_pgetevents syscall Signed-off-by: Helge Deller <deller@gmx.de> |
/linux-master/drivers/media/dvb-frontends/ | ||
H A D | stv0367.c | diff 8c8ca1c7 Sat Oct 27 08:26:42 MDT 2012 Mauro Carvalho Chehab <mchehab@kernel.org> [media] stv0367: get rid of warning: no previous prototype drivers/media/dvb-frontends/stv0367.c:1267:25: warning: no previous prototype for 'stv0367ter_lock_algo' [-Wmissing-prototypes] drivers/media/dvb-frontends/stv0367.c:1531:5: warning: no previous prototype for 'stv0367ter_init' [-Wmissing-prototypes] drivers/media/dvb-frontends/stv0367.c:2381:21: warning: no previous prototype for 'stv0367cab_SetQamSize' [-Wmissing-prototypes] drivers/media/dvb-frontends/stv0367.c:2765:5: warning: no previous prototype for 'stv0367cab_init' [-Wmissing-prototypes] drivers/media/dvb-frontends/stv0367.c:882:4: warning: no previous prototype for 'stv0367_getbits' [-Wmissing-prototypes] Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> |
/linux-master/drivers/gpu/drm/amd/display/dc/link/ | ||
H A D | link_dpms.c | diff b0399e22 Mon Oct 02 08:21:08 MDT 2023 Agustin Gutierrez <agustin.gutierrez@amd.com> drm/amd/display: Remove power sequencing check [Why] Some ASICs keep backlight powered on after dpms off command has been issued. [How] The check for no edp power sequencing was never going to pass. The value is never changed from what it is set by design. Cc: stable@vger.kernel.org # 6.1+ Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2765 Reviewed-by: Swapnil Patel <swapnil.patel@amd.com> Acked-by: Roman Li <roman.li@amd.com> Signed-off-by: Agustin Gutierrez <agustin.gutierrez@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
/linux-master/fs/ubifs/ | ||
H A D | recovery.c | diff 2765df7d Wed Feb 02 00:22:54 MST 2011 Artem Bityutskiy <Artem.Bityutskiy@nokia.com> UBIFS: use max_write_size during recovery When recovering from unclean reboots UBIFS scans the journal and checks nodes. If a corrupted node is found, UBIFS tries to check if this is the last node in the LEB or not. This is is done by checking if there only 0xFF bytes starting from the next min. I/O unit. However, since now we write in c->max_write_size, we should actually check for 0xFFs starting from the next max. write unit. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> |
/linux-master/drivers/atm/ | ||
H A D | iphase.c | diff ea443e5e Tue Jul 30 21:21:41 MDT 2019 Gustavo A. R. Silva <gustavo@embeddedor.com> atm: iphase: Fix Spectre v1 vulnerability board is controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/atm/iphase.c:2765 ia_ioctl() warn: potential spectre issue 'ia_dev' [r] (local cap) drivers/atm/iphase.c:2774 ia_ioctl() warn: possible spectre second half. 'iadev' drivers/atm/iphase.c:2782 ia_ioctl() warn: possible spectre second half. 'iadev' drivers/atm/iphase.c:2816 ia_ioctl() warn: possible spectre second half. 'iadev' drivers/atm/iphase.c:2823 ia_ioctl() warn: possible spectre second half. 'iadev' drivers/atm/iphase.c:2830 ia_ioctl() warn: potential spectre issue '_ia_dev' [r] (local cap) drivers/atm/iphase.c:2845 ia_ioctl() warn: possible spectre second half. 'iadev' drivers/atm/iphase.c:2856 ia_ioctl() warn: possible spectre second half. 'iadev' Fix this by sanitizing board before using it to index ia_dev and _ia_dev Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
/linux-master/drivers/net/ethernet/intel/igb/ | ||
H A D | e1000_82575.c | diff 0a206f9d Tue Jun 01 08:02:38 MDT 2021 YueHaibing <yuehaibing@huawei.com> igb: Fix -Wunused-const-variable warning If CONFIG_IGB_HWMON is n, gcc warns: drivers/net/ethernet/intel/igb/e1000_82575.c:2765:17: warning: ‘e1000_emc_therm_limit’ defined but not used [-Wunused-const-variable=] static const u8 e1000_emc_therm_limit[4] = { ^~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/intel/igb/e1000_82575.c:2759:17: warning: ‘e1000_emc_temp_data’ defined but not used [-Wunused-const-variable=] static const u8 e1000_emc_temp_data[4] = { ^~~~~~~~~~~~~~~~~~~ Move it into #ifdef block to fix this. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
/linux-master/kernel/bpf/ | ||
H A D | log.c | diff 57354f5f Wed Feb 14 10:41:00 MST 2024 Andrii Nakryiko <andrii@kernel.org> bpf: improve duplicate source code line detection Verifier log avoids printing the same source code line multiple times when a consecutive block of BPF assembly instructions are covered by the same original (C) source code line. This greatly improves verifier log legibility. Unfortunately, this check is imperfect and in production applications it quite often happens that verifier log will have multiple duplicated source lines emitted, for no apparently good reason. E.g., this is excerpt from a real-world BPF application (with register states omitted for clarity): BEFORE ====== ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5369: (07) r8 += 2 ; 5370: (07) r7 += 16 ; ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5371: (07) r9 += 1 ; 5372: (79) r4 = *(u64 *)(r10 -32) ; ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5373: (55) if r9 != 0xf goto pc+2 ; if (i >= map->cnt) @ strobemeta_probe.bpf.c:396 5376: (79) r1 = *(u64 *)(r10 -40) ; 5377: (79) r1 = *(u64 *)(r1 +8) ; ; if (i >= map->cnt) @ strobemeta_probe.bpf.c:396 5378: (dd) if r1 s<= r9 goto pc-5 ; ; descr->key_lens[i] = 0; @ strobemeta_probe.bpf.c:398 5379: (b4) w1 = 0 ; 5380: (6b) *(u16 *)(r8 -30) = r1 ; ; task, data, off, STROBE_MAX_STR_LEN, map->entries[i].key); @ strobemeta_probe.bpf.c:400 5381: (79) r3 = *(u64 *)(r7 -8) ; 5382: (7b) *(u64 *)(r10 -24) = r6 ; ; task, data, off, STROBE_MAX_STR_LEN, map->entries[i].key); @ strobemeta_probe.bpf.c:400 5383: (bc) w6 = w6 ; ; barrier_var(payload_off); @ strobemeta_probe.bpf.c:280 5384: (bf) r2 = r6 ; 5385: (bf) r1 = r4 ; As can be seen, line 394 is emitted thrice, 396 is emitted twice, and line 400 is duplicated as well. Note that there are no intermingling other lines of source code in between these duplicates, so the issue is not compiler reordering assembly instruction such that multiple original source code lines are in effect. It becomes more obvious what's going on if we look at *full* original line info information (using btfdump for this, [0]): #2764: line: insn #5363 --> 394:3 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2765: line: insn #5373 --> 394:21 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2766: line: insn #5375 --> 394:47 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2767: line: insn #5377 --> 394:3 @ ./././strobemeta_probe.bpf.c for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { #2768: line: insn #5378 --> 414:10 @ ./././strobemeta_probe.bpf.c return off; We can see that there are four line info records covering instructions #5363 through #5377 (instruction indices are shifted due to subprog instruction being appended to main program), all of them are pointing to the same C source code line #394. But each of them points to a different part of that line, which is denoted by differing column numbers (3, 21, 47, 3). But verifier log doesn't distinguish between parts of the same source code line and doesn't emit this column number information, so for end user it's just a repetitive visual noise. So let's improve the detection of repeated source code line and avoid this. With the changes in this patch, we get this output for the same piece of BPF program log: AFTER ===== ; for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) { @ strobemeta_probe.bpf.c:394 5369: (07) r8 += 2 ; 5370: (07) r7 += 16 ; 5371: (07) r9 += 1 ; 5372: (79) r4 = *(u64 *)(r10 -32) ; 5373: (55) if r9 != 0xf goto pc+2 ; if (i >= map->cnt) @ strobemeta_probe.bpf.c:396 5376: (79) r1 = *(u64 *)(r10 -40) ; 5377: (79) r1 = *(u64 *)(r1 +8) ; 5378: (dd) if r1 s<= r9 goto pc-5 ; ; descr->key_lens[i] = 0; @ strobemeta_probe.bpf.c:398 5379: (b4) w1 = 0 ; 5380: (6b) *(u16 *)(r8 -30) = r1 ; ; task, data, off, STROBE_MAX_STR_LEN, map->entries[i].key); @ strobemeta_probe.bpf.c:400 5381: (79) r3 = *(u64 *)(r7 -8) ; 5382: (7b) *(u64 *)(r10 -24) = r6 ; 5383: (bc) w6 = w6 ; ; barrier_var(payload_off); @ strobemeta_probe.bpf.c:280 5384: (bf) r2 = r6 ; 5385: (bf) r1 = r4 ; All the duplication is gone and the log is cleaner and less distracting. [0] https://github.com/anakryiko/btfdump Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20240214174100.2847419-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
/linux-master/drivers/net/wireless/broadcom/brcm80211/brcmfmac/ | ||
H A D | core.c | diff d0151c2b Sun Sep 27 23:49:21 MDT 2020 Wright Feng <wright.feng@cypress.com> brcmfmac: Fix warning when hitting FW crash with flow control feature Brcmfmac got warning message when hitting FW crash in TX throughput test with fcmode=2. It's caused by FMAC flushed TXQ in brcmf_sdio_bus_stop but without doing hanger slot cleanup. Therefore, we move brcmf_remove_interface before brcmf_bus_stop to make sure the hanger slot is clean when flushing TXQ. [ 1891.512234] WARNING: CPU: 1 PID: 2765 at drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c:49 brcmu_pkt_buf_free_skb+0x21/0x30 [brcmutil] [ 1891.512234] Modules linked in: brcmfmac(OE-) brcmutil(OE) cfg80211(OE) compat(OE) rfkill mmc_block(OE) sdhci_pci(OE) sdhci(OE) mmc_core(OE) ip6table_filter ip6_tables ebtable_nat ebtables dns_resolver fscache e1000e ppdev iTCO_wdt iTCO_vendor_support tpm_tis tpm_tis_core tpm mei_me mei pcspkr lpc_ich i2c_i801 mfd_core ptp pps_core parport_pc parport wmi tcp_bic uinput i915 iosf_mbi i2c_algo_bit drm_kms_helper drm i2c_core video [last unloaded: brcmfmac] [ 1891.512247] CPU: 1 PID: 2765 Comm: rmmod Tainted: G W OE 4.12.0 #1 [ 1891.512247] Hardware name: /DH77EB, BIOS EBH7710H.86A.0100.2013.0312.1351 03/12/2013 [ 1891.512248] task: ffff880118f08000 task.stack: ffffc90001180000 [ 1891.512249] RIP: 0010:brcmu_pkt_buf_free_skb+0x21/0x30 [brcmutil] [ 1891.512249] RSP: 0018:ffffc90001183cc0 EFLAGS: 00010086 [ 1891.512250] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 [ 1891.512251] RDX: 0000000000000000 RSI: 0000000000000086 RDI: ffff880118e3ab00 [ 1891.512251] RBP: ffffc90001183cc0 R08: 0000000000000000 R09: 000000000000a050 [ 1891.512252] R10: 0000000000000001 R11: 0000000000aaaaaa R12: 00000000000000bc [ 1891.512253] R13: ffff880118b40c78 R14: 0000000000000002 R15: ffff880118e3ab00 [ 1891.512253] FS: 00007f2a49760740(0000) GS:ffff88011f280000(0000) knlGS:0000000000000000 [ 1891.512254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1891.512254] CR2: 00000000012994a8 CR3: 000000011a3c4000 CR4: 00000000001406e0 [ 1891.512255] Call Trace: [ 1891.512259] brcmf_fws_cleanup+0x1ea/0x240 [brcmfmac] [ 1891.512264] brcmf_fws_detach+0x42/0x60 [brcmfmac] [ 1891.512268] brcmf_proto_bcdc_detach+0x26/0x40 [brcmfmac] [ 1891.512273] brcmf_proto_detach+0x57/0x70 [brcmfmac] [ 1891.512277] brcmf_detach+0x89/0x100 [brcmfmac] [ 1891.512282] brcmf_sdio_remove+0x76/0x180 [brcmfmac] [ 1891.512286] brcmf_sdiod_remove+0x25/0xb0 [brcmfmac] [ 1891.512291] brcmf_ops_sdio_remove+0xbd/0x120 [brcmfmac] [ 1891.512294] sdio_bus_remove+0x33/0x100 [mmc_core] [ 1891.512295] device_release_driver_internal+0x141/0x200 [ 1891.512297] driver_detach+0x38/0x70 [ 1891.512298] bus_remove_driver+0x55/0xd0 [ 1891.512299] driver_unregister+0x2c/0x50 [ 1891.512303] sdio_unregister_driver+0x1a/0x20 [mmc_core] [ 1891.512307] brcmf_sdio_exit+0x2f/0x40 [brcmfmac] [ 1891.512312] brcmf_core_exit+0x15/0xd7 [brcmfmac] [ 1891.512316] __exit_compat+0x9/0x2b [brcmfmac] [ 1891.512318] SyS_delete_module+0x155/0x230 [ 1891.512319] ? exit_to_usermode_loop+0x70/0x99 [ 1891.512321] do_syscall_64+0x54/0xc0 [ 1891.512322] entry_SYSCALL64_slow_path+0x25/0x25 Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200928054922.44580-2-wright.feng@cypress.com diff d0151c2b Sun Sep 27 23:49:21 MDT 2020 Wright Feng <wright.feng@cypress.com> brcmfmac: Fix warning when hitting FW crash with flow control feature Brcmfmac got warning message when hitting FW crash in TX throughput test with fcmode=2. It's caused by FMAC flushed TXQ in brcmf_sdio_bus_stop but without doing hanger slot cleanup. Therefore, we move brcmf_remove_interface before brcmf_bus_stop to make sure the hanger slot is clean when flushing TXQ. [ 1891.512234] WARNING: CPU: 1 PID: 2765 at drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c:49 brcmu_pkt_buf_free_skb+0x21/0x30 [brcmutil] [ 1891.512234] Modules linked in: brcmfmac(OE-) brcmutil(OE) cfg80211(OE) compat(OE) rfkill mmc_block(OE) sdhci_pci(OE) sdhci(OE) mmc_core(OE) ip6table_filter ip6_tables ebtable_nat ebtables dns_resolver fscache e1000e ppdev iTCO_wdt iTCO_vendor_support tpm_tis tpm_tis_core tpm mei_me mei pcspkr lpc_ich i2c_i801 mfd_core ptp pps_core parport_pc parport wmi tcp_bic uinput i915 iosf_mbi i2c_algo_bit drm_kms_helper drm i2c_core video [last unloaded: brcmfmac] [ 1891.512247] CPU: 1 PID: 2765 Comm: rmmod Tainted: G W OE 4.12.0 #1 [ 1891.512247] Hardware name: /DH77EB, BIOS EBH7710H.86A.0100.2013.0312.1351 03/12/2013 [ 1891.512248] task: ffff880118f08000 task.stack: ffffc90001180000 [ 1891.512249] RIP: 0010:brcmu_pkt_buf_free_skb+0x21/0x30 [brcmutil] [ 1891.512249] RSP: 0018:ffffc90001183cc0 EFLAGS: 00010086 [ 1891.512250] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 [ 1891.512251] RDX: 0000000000000000 RSI: 0000000000000086 RDI: ffff880118e3ab00 [ 1891.512251] RBP: ffffc90001183cc0 R08: 0000000000000000 R09: 000000000000a050 [ 1891.512252] R10: 0000000000000001 R11: 0000000000aaaaaa R12: 00000000000000bc [ 1891.512253] R13: ffff880118b40c78 R14: 0000000000000002 R15: ffff880118e3ab00 [ 1891.512253] FS: 00007f2a49760740(0000) GS:ffff88011f280000(0000) knlGS:0000000000000000 [ 1891.512254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1891.512254] CR2: 00000000012994a8 CR3: 000000011a3c4000 CR4: 00000000001406e0 [ 1891.512255] Call Trace: [ 1891.512259] brcmf_fws_cleanup+0x1ea/0x240 [brcmfmac] [ 1891.512264] brcmf_fws_detach+0x42/0x60 [brcmfmac] [ 1891.512268] brcmf_proto_bcdc_detach+0x26/0x40 [brcmfmac] [ 1891.512273] brcmf_proto_detach+0x57/0x70 [brcmfmac] [ 1891.512277] brcmf_detach+0x89/0x100 [brcmfmac] [ 1891.512282] brcmf_sdio_remove+0x76/0x180 [brcmfmac] [ 1891.512286] brcmf_sdiod_remove+0x25/0xb0 [brcmfmac] [ 1891.512291] brcmf_ops_sdio_remove+0xbd/0x120 [brcmfmac] [ 1891.512294] sdio_bus_remove+0x33/0x100 [mmc_core] [ 1891.512295] device_release_driver_internal+0x141/0x200 [ 1891.512297] driver_detach+0x38/0x70 [ 1891.512298] bus_remove_driver+0x55/0xd0 [ 1891.512299] driver_unregister+0x2c/0x50 [ 1891.512303] sdio_unregister_driver+0x1a/0x20 [mmc_core] [ 1891.512307] brcmf_sdio_exit+0x2f/0x40 [brcmfmac] [ 1891.512312] brcmf_core_exit+0x15/0xd7 [brcmfmac] [ 1891.512316] __exit_compat+0x9/0x2b [brcmfmac] [ 1891.512318] SyS_delete_module+0x155/0x230 [ 1891.512319] ? exit_to_usermode_loop+0x70/0x99 [ 1891.512321] do_syscall_64+0x54/0xc0 [ 1891.512322] entry_SYSCALL64_slow_path+0x25/0x25 Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200928054922.44580-2-wright.feng@cypress.com |
/linux-master/scripts/dtc/include-prefixes/arm64/qcom/ | ||
H A D | sm8150.dtsi | diff 5b2dae72 Sun Dec 20 17:29:07 MST 2020 Danny Lin <danny@kdrag0n.dev> arm64: dts: qcom: sm8150: Add CPU capacities and energy model Power and performance measurements were made using my freqbench [1] benchmark coordinator, which isolates, offlines, and disables the timer tick on test CPUs to maximize accuracy. It uses EEMBC CoreMark [2] as the workload and measures power usage using the PM8150B PMIC's fuel gauge. The energy model dynamic-power-coefficient values were calculated with DPC = µW / MHz / V^2 for each OPP, and averaged across all OPPs within each cluster for the final coefficient. Voltages were obtained from the qcom-cpufreq-hw driver that reads voltages from the OSM LUT programmed into the SoC. Normalized DMIPS/MHz capacity scale values for each CPU were calculated from CoreMarks/MHz (CoreMark iterations per second per MHz), which serves the same purpose. For each CPU, the final capacity-dmips-mhz value is the C/MHz value of its maximum frequency normalized to SCHED_CAPACITY_SCALE (1024) for the fastest CPU in the system. An Asus ZenFone 6 device running a downstream Qualcomm 4.14 kernel (LA.UM.8.1.r1-15600-sm8150.0) was used for benchmarks to ensure proper frequency scaling and other low-level controls. Raw benchmark results can be found in the freqbench repository [3]. Below is a human-readable summary: Frequency domains: cpu1 cpu4 cpu7 Offline CPUs: cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 Baseline power usage: 1400 mW ===== CPU 1 ===== Frequencies: 300 403 499 576 672 768 844 940 1036 1113 1209 1305 1382 1478 1555 1632 1708 1785 300: 1114 3.7 C/MHz 52 mW 11.8 J 21.3 I/mJ 224.4 s 403: 1497 3.7 C/MHz 57 mW 9.5 J 26.2 I/mJ 167.0 s 499: 1854 3.7 C/MHz 73 mW 9.8 J 25.5 I/mJ 134.9 s 576: 2139 3.7 C/MHz 83 mW 9.7 J 25.8 I/mJ 116.9 s 672: 2495 3.7 C/MHz 65 mW 6.5 J 38.6 I/mJ 100.2 s 768: 2852 3.7 C/MHz 72 mW 6.3 J 39.4 I/mJ 87.7 s 844: 3137 3.7 C/MHz 77 mW 6.2 J 40.5 I/mJ 79.7 s 940: 3493 3.7 C/MHz 84 mW 6.0 J 41.8 I/mJ 71.6 s 1036: 3850 3.7 C/MHz 91 mW 5.9 J 42.5 I/mJ 64.9 s 1113: 4135 3.7 C/MHz 96 mW 5.8 J 43.2 I/mJ 60.5 s 1209: 4491 3.7 C/MHz 102 mW 5.7 J 44.2 I/mJ 55.7 s 1305: 4848 3.7 C/MHz 110 mW 5.7 J 44.0 I/mJ 51.6 s 1382: 5133 3.7 C/MHz 114 mW 5.5 J 45.2 I/mJ 48.7 s 1478: 5490 3.7 C/MHz 120 mW 5.5 J 45.7 I/mJ 45.5 s 1555: 5775 3.7 C/MHz 126 mW 5.5 J 45.8 I/mJ 43.3 s 1632: 6060 3.7 C/MHz 131 mW 5.4 J 46.1 I/mJ 41.3 s 1708: 6345 3.7 C/MHz 137 mW 5.4 J 46.3 I/mJ 39.4 s 1785: 6630 3.7 C/MHz 146 mW 5.5 J 45.5 I/mJ 37.7 s ===== CPU 4 ===== Frequencies: 710 825 940 1056 1171 1286 1401 1497 1612 1708 1804 1920 2016 2131 2227 2323 2419 710: 2765 3.9 C/MHz 126 mW 11.4 J 22.0 I/mJ 90.4 s 825: 6432 7.8 C/MHz 206 mW 8.0 J 31.2 I/mJ 38.9 s 940: 7331 7.8 C/MHz 227 mW 7.7 J 32.3 I/mJ 34.1 s 1056: 8227 7.8 C/MHz 249 mW 7.6 J 33.0 I/mJ 30.4 s 1171: 9127 7.8 C/MHz 261 mW 7.2 J 34.9 I/mJ 27.4 s 1286: 10020 7.8 C/MHz 289 mW 7.2 J 34.6 I/mJ 25.0 s 1401: 10918 7.8 C/MHz 311 mW 7.1 J 35.1 I/mJ 22.9 s 1497: 11663 7.8 C/MHz 336 mW 7.2 J 34.7 I/mJ 21.4 s 1612: 12546 7.8 C/MHz 375 mW 7.5 J 33.5 I/mJ 19.9 s 1708: 13320 7.8 C/MHz 398 mW 7.5 J 33.5 I/mJ 18.8 s 1804: 14069 7.8 C/MHz 456 mW 8.1 J 30.9 I/mJ 17.8 s 1920: 14909 7.8 C/MHz 507 mW 8.5 J 29.4 I/mJ 16.8 s 2016: 15706 7.8 C/MHz 558 mW 8.9 J 28.1 I/mJ 15.9 s 2131: 16612 7.8 C/MHz 632 mW 9.5 J 26.3 I/mJ 15.1 s 2227: 17349 7.8 C/MHz 698 mW 10.1 J 24.8 I/mJ 14.4 s 2323: 18088 7.8 C/MHz 717 mW 9.9 J 25.2 I/mJ 13.8 s 2419: 18835 7.8 C/MHz 845 mW 11.2 J 22.3 I/mJ 13.3 s ===== CPU 7 ===== Frequencies: 825 940 1056 1171 1286 1401 1497 1612 1708 1804 1920 2016 2131 2227 2323 2419 2534 2649 2745 2841 825: 3215 3.9 C/MHz 158 mW 12.3 J 20.3 I/mJ 77.8 s 940: 7330 7.8 C/MHz 269 mW 9.2 J 27.3 I/mJ 34.1 s 1056: 8227 7.8 C/MHz 291 mW 8.8 J 28.2 I/mJ 30.4 s 1171: 9125 7.8 C/MHz 316 mW 8.7 J 28.9 I/mJ 27.4 s 1286: 10024 7.8 C/MHz 338 mW 8.4 J 29.6 I/mJ 25.0 s 1401: 10922 7.8 C/MHz 365 mW 8.4 J 29.9 I/mJ 22.9 s 1497: 11674 7.8 C/MHz 383 mW 8.2 J 30.4 I/mJ 21.4 s 1612: 12564 7.8 C/MHz 406 mW 8.1 J 30.9 I/mJ 19.9 s 1708: 13317 7.8 C/MHz 427 mW 8.0 J 31.2 I/mJ 18.8 s 1804: 14062 7.8 C/MHz 446 mW 7.9 J 31.5 I/mJ 17.8 s 1920: 14966 7.8 C/MHz 498 mW 8.3 J 30.1 I/mJ 16.7 s 2016: 15711 7.8 C/MHz 513 mW 8.2 J 30.6 I/mJ 15.9 s 2131: 16599 7.8 C/MHz 599 mW 9.0 J 27.7 I/mJ 15.1 s 2227: 17353 7.8 C/MHz 622 mW 9.0 J 27.9 I/mJ 14.4 s 2323: 18095 7.8 C/MHz 704 mW 9.7 J 25.7 I/mJ 13.8 s 2419: 18849 7.8 C/MHz 738 mW 9.8 J 25.5 I/mJ 13.3 s 2534: 19761 7.8 C/MHz 824 mW 10.4 J 23.9 I/mJ 12.7 s 2649: 20658 7.8 C/MHz 882 mW 10.7 J 23.4 I/mJ 12.1 s 2745: 21400 7.8 C/MHz 1003 mW 11.7 J 21.3 I/mJ 11.7 s 2841: 22147 7.8 C/MHz 1092 mW 12.3 J 20.3 I/mJ 11.3 s [1] https://github.com/kdrag0n/freqbench [2] https://www.eembc.org/coremark/ [3] https://github.com/kdrag0n/freqbench/tree/master/results/sm8150/main Signed-off-by: Danny Lin <danny@kdrag0n.dev> Link: https://lore.kernel.org/r/20201221002907.2870059-4-danny@kdrag0n.dev Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> |
/linux-master/arch/arm64/boot/dts/qcom/ | ||
H A D | sm8150.dtsi | diff 5b2dae72 Sun Dec 20 17:29:07 MST 2020 Danny Lin <danny@kdrag0n.dev> arm64: dts: qcom: sm8150: Add CPU capacities and energy model Power and performance measurements were made using my freqbench [1] benchmark coordinator, which isolates, offlines, and disables the timer tick on test CPUs to maximize accuracy. It uses EEMBC CoreMark [2] as the workload and measures power usage using the PM8150B PMIC's fuel gauge. The energy model dynamic-power-coefficient values were calculated with DPC = µW / MHz / V^2 for each OPP, and averaged across all OPPs within each cluster for the final coefficient. Voltages were obtained from the qcom-cpufreq-hw driver that reads voltages from the OSM LUT programmed into the SoC. Normalized DMIPS/MHz capacity scale values for each CPU were calculated from CoreMarks/MHz (CoreMark iterations per second per MHz), which serves the same purpose. For each CPU, the final capacity-dmips-mhz value is the C/MHz value of its maximum frequency normalized to SCHED_CAPACITY_SCALE (1024) for the fastest CPU in the system. An Asus ZenFone 6 device running a downstream Qualcomm 4.14 kernel (LA.UM.8.1.r1-15600-sm8150.0) was used for benchmarks to ensure proper frequency scaling and other low-level controls. Raw benchmark results can be found in the freqbench repository [3]. Below is a human-readable summary: Frequency domains: cpu1 cpu4 cpu7 Offline CPUs: cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 Baseline power usage: 1400 mW ===== CPU 1 ===== Frequencies: 300 403 499 576 672 768 844 940 1036 1113 1209 1305 1382 1478 1555 1632 1708 1785 300: 1114 3.7 C/MHz 52 mW 11.8 J 21.3 I/mJ 224.4 s 403: 1497 3.7 C/MHz 57 mW 9.5 J 26.2 I/mJ 167.0 s 499: 1854 3.7 C/MHz 73 mW 9.8 J 25.5 I/mJ 134.9 s 576: 2139 3.7 C/MHz 83 mW 9.7 J 25.8 I/mJ 116.9 s 672: 2495 3.7 C/MHz 65 mW 6.5 J 38.6 I/mJ 100.2 s 768: 2852 3.7 C/MHz 72 mW 6.3 J 39.4 I/mJ 87.7 s 844: 3137 3.7 C/MHz 77 mW 6.2 J 40.5 I/mJ 79.7 s 940: 3493 3.7 C/MHz 84 mW 6.0 J 41.8 I/mJ 71.6 s 1036: 3850 3.7 C/MHz 91 mW 5.9 J 42.5 I/mJ 64.9 s 1113: 4135 3.7 C/MHz 96 mW 5.8 J 43.2 I/mJ 60.5 s 1209: 4491 3.7 C/MHz 102 mW 5.7 J 44.2 I/mJ 55.7 s 1305: 4848 3.7 C/MHz 110 mW 5.7 J 44.0 I/mJ 51.6 s 1382: 5133 3.7 C/MHz 114 mW 5.5 J 45.2 I/mJ 48.7 s 1478: 5490 3.7 C/MHz 120 mW 5.5 J 45.7 I/mJ 45.5 s 1555: 5775 3.7 C/MHz 126 mW 5.5 J 45.8 I/mJ 43.3 s 1632: 6060 3.7 C/MHz 131 mW 5.4 J 46.1 I/mJ 41.3 s 1708: 6345 3.7 C/MHz 137 mW 5.4 J 46.3 I/mJ 39.4 s 1785: 6630 3.7 C/MHz 146 mW 5.5 J 45.5 I/mJ 37.7 s ===== CPU 4 ===== Frequencies: 710 825 940 1056 1171 1286 1401 1497 1612 1708 1804 1920 2016 2131 2227 2323 2419 710: 2765 3.9 C/MHz 126 mW 11.4 J 22.0 I/mJ 90.4 s 825: 6432 7.8 C/MHz 206 mW 8.0 J 31.2 I/mJ 38.9 s 940: 7331 7.8 C/MHz 227 mW 7.7 J 32.3 I/mJ 34.1 s 1056: 8227 7.8 C/MHz 249 mW 7.6 J 33.0 I/mJ 30.4 s 1171: 9127 7.8 C/MHz 261 mW 7.2 J 34.9 I/mJ 27.4 s 1286: 10020 7.8 C/MHz 289 mW 7.2 J 34.6 I/mJ 25.0 s 1401: 10918 7.8 C/MHz 311 mW 7.1 J 35.1 I/mJ 22.9 s 1497: 11663 7.8 C/MHz 336 mW 7.2 J 34.7 I/mJ 21.4 s 1612: 12546 7.8 C/MHz 375 mW 7.5 J 33.5 I/mJ 19.9 s 1708: 13320 7.8 C/MHz 398 mW 7.5 J 33.5 I/mJ 18.8 s 1804: 14069 7.8 C/MHz 456 mW 8.1 J 30.9 I/mJ 17.8 s 1920: 14909 7.8 C/MHz 507 mW 8.5 J 29.4 I/mJ 16.8 s 2016: 15706 7.8 C/MHz 558 mW 8.9 J 28.1 I/mJ 15.9 s 2131: 16612 7.8 C/MHz 632 mW 9.5 J 26.3 I/mJ 15.1 s 2227: 17349 7.8 C/MHz 698 mW 10.1 J 24.8 I/mJ 14.4 s 2323: 18088 7.8 C/MHz 717 mW 9.9 J 25.2 I/mJ 13.8 s 2419: 18835 7.8 C/MHz 845 mW 11.2 J 22.3 I/mJ 13.3 s ===== CPU 7 ===== Frequencies: 825 940 1056 1171 1286 1401 1497 1612 1708 1804 1920 2016 2131 2227 2323 2419 2534 2649 2745 2841 825: 3215 3.9 C/MHz 158 mW 12.3 J 20.3 I/mJ 77.8 s 940: 7330 7.8 C/MHz 269 mW 9.2 J 27.3 I/mJ 34.1 s 1056: 8227 7.8 C/MHz 291 mW 8.8 J 28.2 I/mJ 30.4 s 1171: 9125 7.8 C/MHz 316 mW 8.7 J 28.9 I/mJ 27.4 s 1286: 10024 7.8 C/MHz 338 mW 8.4 J 29.6 I/mJ 25.0 s 1401: 10922 7.8 C/MHz 365 mW 8.4 J 29.9 I/mJ 22.9 s 1497: 11674 7.8 C/MHz 383 mW 8.2 J 30.4 I/mJ 21.4 s 1612: 12564 7.8 C/MHz 406 mW 8.1 J 30.9 I/mJ 19.9 s 1708: 13317 7.8 C/MHz 427 mW 8.0 J 31.2 I/mJ 18.8 s 1804: 14062 7.8 C/MHz 446 mW 7.9 J 31.5 I/mJ 17.8 s 1920: 14966 7.8 C/MHz 498 mW 8.3 J 30.1 I/mJ 16.7 s 2016: 15711 7.8 C/MHz 513 mW 8.2 J 30.6 I/mJ 15.9 s 2131: 16599 7.8 C/MHz 599 mW 9.0 J 27.7 I/mJ 15.1 s 2227: 17353 7.8 C/MHz 622 mW 9.0 J 27.9 I/mJ 14.4 s 2323: 18095 7.8 C/MHz 704 mW 9.7 J 25.7 I/mJ 13.8 s 2419: 18849 7.8 C/MHz 738 mW 9.8 J 25.5 I/mJ 13.3 s 2534: 19761 7.8 C/MHz 824 mW 10.4 J 23.9 I/mJ 12.7 s 2649: 20658 7.8 C/MHz 882 mW 10.7 J 23.4 I/mJ 12.1 s 2745: 21400 7.8 C/MHz 1003 mW 11.7 J 21.3 I/mJ 11.7 s 2841: 22147 7.8 C/MHz 1092 mW 12.3 J 20.3 I/mJ 11.3 s [1] https://github.com/kdrag0n/freqbench [2] https://www.eembc.org/coremark/ [3] https://github.com/kdrag0n/freqbench/tree/master/results/sm8150/main Signed-off-by: Danny Lin <danny@kdrag0n.dev> Link: https://lore.kernel.org/r/20201221002907.2870059-4-danny@kdrag0n.dev Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> |
/linux-master/drivers/mmc/host/ | ||
H A D | mtk-sd.c | diff c0d638a0 Thu Dec 03 15:29:16 MST 2020 Arnd Bergmann <arnd@arndb.de> mmc: mediatek: mark PM functions as __maybe_unused The #ifdef check for the suspend/resume functions is wrong: drivers/mmc/host/mtk-sd.c:2765:12: error: unused function 'msdc_suspend' [-Werror,-Wunused-function] static int msdc_suspend(struct device *dev) drivers/mmc/host/mtk-sd.c:2779:12: error: unused function 'msdc_resume' [-Werror,-Wunused-function] static int msdc_resume(struct device *dev) Remove the #ifdef and mark all four as __maybe_unused to aovid the problem. Fixes: c0a2074ac575 ("mmc: mediatek: Fix system suspend/resume support for CQHCI") Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20201203222922.1067522-1-arnd@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> |
/linux-master/drivers/md/bcache/ | ||
H A D | super.c | diff fecaee6f Sun Nov 29 18:19:32 MST 2015 Zheng Liu <wenqing.lz@taobao.com> bcache: clear BCACHE_DEV_UNLINK_DONE flag when attaching a backing device This bug can be reproduced by the following script: #!/bin/bash bcache_sysfs="/sys/fs/bcache" function clear_cache() { if [ ! -e $bcache_sysfs ]; then echo "no bcache sysfs" exit fi cset_uuid=$(ls -l $bcache_sysfs|head -n 2|tail -n 1|awk '{print $9}') sudo sh -c "echo $cset_uuid > /sys/block/sdb/sdb1/bcache/detach" sleep 5 sudo sh -c "echo $cset_uuid > /sys/block/sdb/sdb1/bcache/attach" } for ((i=0;i<10;i++)); do clear_cache done The warning messages look like below: [ 275.948611] ------------[ cut here ]------------ [ 275.963840] WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xb8/0xd0() (Tainted: P W --------------- ) [ 275.979253] Hardware name: Tecal RH2285 [ 275.994106] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:09.0/0000:08:00.0/host4/target4:2:1/4:2:1:0/block/sdb/sdb1/bcache/cache' [ 276.024105] Modules linked in: bcache tcp_diag inet_diag ipmi_devintf ipmi_si ipmi_msghandler bonding 8021q garp stp llc ipv6 ext3 jbd loop sg iomemory_vsl(P) bnx2 microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 jbd2 mbcache megaraid_sas pata_acpi ata_generic ata_piix dm_mod [last unloaded: scsi_wait_scan] [ 276.072643] Pid: 2765, comm: sh Tainted: P W --------------- 2.6.32 #1 [ 276.089315] Call Trace: [ 276.105801] [<ffffffff81070fe7>] ? warn_slowpath_common+0x87/0xc0 [ 276.122650] [<ffffffff810710d6>] ? warn_slowpath_fmt+0x46/0x50 [ 276.139361] [<ffffffff81205c08>] ? sysfs_add_one+0xb8/0xd0 [ 276.156012] [<ffffffff8120609b>] ? sysfs_do_create_link+0x12b/0x170 [ 276.172682] [<ffffffff81206113>] ? sysfs_create_link+0x13/0x20 [ 276.189282] [<ffffffffa03bda21>] ? bcache_device_link+0xc1/0x110 [bcache] [ 276.205993] [<ffffffffa03bfa08>] ? bch_cached_dev_attach+0x478/0x4f0 [bcache] [ 276.222794] [<ffffffffa03c4a17>] ? bch_cached_dev_store+0x627/0x780 [bcache] [ 276.239680] [<ffffffff8116783a>] ? alloc_pages_current+0xaa/0x110 [ 276.256594] [<ffffffff81203b15>] ? sysfs_write_file+0xe5/0x170 [ 276.273364] [<ffffffff811887b8>] ? vfs_write+0xb8/0x1a0 [ 276.290133] [<ffffffff811890b1>] ? sys_write+0x51/0x90 [ 276.306368] [<ffffffff8100c072>] ? system_call_fastpath+0x16/0x1b [ 276.322301] ---[ end trace 9f5d4fcdd0c3edfb ]--- [ 276.338241] ------------[ cut here ]------------ [ 276.354109] WARNING: at /home/wenqing.lz/bcache/bcache/super.c:720 bcache_device_link+0xdf/0x110 [bcache]() (Tainted: P W --------------- ) [ 276.386017] Hardware name: Tecal RH2285 [ 276.401430] Couldn't create device <-> cache set symlinks [ 276.401759] Modules linked in: bcache tcp_diag inet_diag ipmi_devintf ipmi_si ipmi_msghandler bonding 8021q garp stp llc ipv6 ext3 jbd loop sg iomemory_vsl(P) bnx2 microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 jbd2 mbcache megaraid_sas pata_acpi ata_generic ata_piix dm_mod [last unloaded: scsi_wait_scan] [ 276.465477] Pid: 2765, comm: sh Tainted: P W --------------- 2.6.32 #1 [ 276.482169] Call Trace: [ 276.498610] [<ffffffff81070fe7>] ? warn_slowpath_common+0x87/0xc0 [ 276.515405] [<ffffffff810710d6>] ? warn_slowpath_fmt+0x46/0x50 [ 276.532059] [<ffffffffa03bda3f>] ? bcache_device_link+0xdf/0x110 [bcache] [ 276.548808] [<ffffffffa03bfa08>] ? bch_cached_dev_attach+0x478/0x4f0 [bcache] [ 276.565569] [<ffffffffa03c4a17>] ? bch_cached_dev_store+0x627/0x780 [bcache] [ 276.582418] [<ffffffff8116783a>] ? alloc_pages_current+0xaa/0x110 [ 276.599341] [<ffffffff81203b15>] ? sysfs_write_file+0xe5/0x170 [ 276.616142] [<ffffffff811887b8>] ? vfs_write+0xb8/0x1a0 [ 276.632607] [<ffffffff811890b1>] ? sys_write+0x51/0x90 [ 276.648671] [<ffffffff8100c072>] ? system_call_fastpath+0x16/0x1b [ 276.664756] ---[ end trace 9f5d4fcdd0c3edfc ]--- We forget to clear BCACHE_DEV_UNLINK_DONE flag in bcache_device_attach() function when we attach a backing device first time. After detaching this backing device, this flag will be true and sysfs_remove_link() isn't called in bcache_device_unlink(). Then when we attach this backing device again, sysfs_create_link() will return EEXIST error in bcache_device_link(). So the fix is trival and we clear this flag in bcache_device_link(). Signed-off-by: Zheng Liu <wenqing.lz@taobao.com> Tested-by: Joshua Schmid <jschmid@suse.com> Tested-by: Eric Wheeler <bcache@linux.ewheeler.net> Cc: Kent Overstreet <kmo@daterainc.com> Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe <axboe@fb.com> diff fecaee6f Sun Nov 29 18:19:32 MST 2015 Zheng Liu <wenqing.lz@taobao.com> bcache: clear BCACHE_DEV_UNLINK_DONE flag when attaching a backing device This bug can be reproduced by the following script: #!/bin/bash bcache_sysfs="/sys/fs/bcache" function clear_cache() { if [ ! -e $bcache_sysfs ]; then echo "no bcache sysfs" exit fi cset_uuid=$(ls -l $bcache_sysfs|head -n 2|tail -n 1|awk '{print $9}') sudo sh -c "echo $cset_uuid > /sys/block/sdb/sdb1/bcache/detach" sleep 5 sudo sh -c "echo $cset_uuid > /sys/block/sdb/sdb1/bcache/attach" } for ((i=0;i<10;i++)); do clear_cache done The warning messages look like below: [ 275.948611] ------------[ cut here ]------------ [ 275.963840] WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xb8/0xd0() (Tainted: P W --------------- ) [ 275.979253] Hardware name: Tecal RH2285 [ 275.994106] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:09.0/0000:08:00.0/host4/target4:2:1/4:2:1:0/block/sdb/sdb1/bcache/cache' [ 276.024105] Modules linked in: bcache tcp_diag inet_diag ipmi_devintf ipmi_si ipmi_msghandler bonding 8021q garp stp llc ipv6 ext3 jbd loop sg iomemory_vsl(P) bnx2 microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 jbd2 mbcache megaraid_sas pata_acpi ata_generic ata_piix dm_mod [last unloaded: scsi_wait_scan] [ 276.072643] Pid: 2765, comm: sh Tainted: P W --------------- 2.6.32 #1 [ 276.089315] Call Trace: [ 276.105801] [<ffffffff81070fe7>] ? warn_slowpath_common+0x87/0xc0 [ 276.122650] [<ffffffff810710d6>] ? warn_slowpath_fmt+0x46/0x50 [ 276.139361] [<ffffffff81205c08>] ? sysfs_add_one+0xb8/0xd0 [ 276.156012] [<ffffffff8120609b>] ? sysfs_do_create_link+0x12b/0x170 [ 276.172682] [<ffffffff81206113>] ? sysfs_create_link+0x13/0x20 [ 276.189282] [<ffffffffa03bda21>] ? bcache_device_link+0xc1/0x110 [bcache] [ 276.205993] [<ffffffffa03bfa08>] ? bch_cached_dev_attach+0x478/0x4f0 [bcache] [ 276.222794] [<ffffffffa03c4a17>] ? bch_cached_dev_store+0x627/0x780 [bcache] [ 276.239680] [<ffffffff8116783a>] ? alloc_pages_current+0xaa/0x110 [ 276.256594] [<ffffffff81203b15>] ? sysfs_write_file+0xe5/0x170 [ 276.273364] [<ffffffff811887b8>] ? vfs_write+0xb8/0x1a0 [ 276.290133] [<ffffffff811890b1>] ? sys_write+0x51/0x90 [ 276.306368] [<ffffffff8100c072>] ? system_call_fastpath+0x16/0x1b [ 276.322301] ---[ end trace 9f5d4fcdd0c3edfb ]--- [ 276.338241] ------------[ cut here ]------------ [ 276.354109] WARNING: at /home/wenqing.lz/bcache/bcache/super.c:720 bcache_device_link+0xdf/0x110 [bcache]() (Tainted: P W --------------- ) [ 276.386017] Hardware name: Tecal RH2285 [ 276.401430] Couldn't create device <-> cache set symlinks [ 276.401759] Modules linked in: bcache tcp_diag inet_diag ipmi_devintf ipmi_si ipmi_msghandler bonding 8021q garp stp llc ipv6 ext3 jbd loop sg iomemory_vsl(P) bnx2 microcode serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 jbd2 mbcache megaraid_sas pata_acpi ata_generic ata_piix dm_mod [last unloaded: scsi_wait_scan] [ 276.465477] Pid: 2765, comm: sh Tainted: P W --------------- 2.6.32 #1 [ 276.482169] Call Trace: [ 276.498610] [<ffffffff81070fe7>] ? warn_slowpath_common+0x87/0xc0 [ 276.515405] [<ffffffff810710d6>] ? warn_slowpath_fmt+0x46/0x50 [ 276.532059] [<ffffffffa03bda3f>] ? bcache_device_link+0xdf/0x110 [bcache] [ 276.548808] [<ffffffffa03bfa08>] ? bch_cached_dev_attach+0x478/0x4f0 [bcache] [ 276.565569] [<ffffffffa03c4a17>] ? bch_cached_dev_store+0x627/0x780 [bcache] [ 276.582418] [<ffffffff8116783a>] ? alloc_pages_current+0xaa/0x110 [ 276.599341] [<ffffffff81203b15>] ? sysfs_write_file+0xe5/0x170 [ 276.616142] [<ffffffff811887b8>] ? vfs_write+0xb8/0x1a0 [ 276.632607] [<ffffffff811890b1>] ? sys_write+0x51/0x90 [ 276.648671] [<ffffffff8100c072>] ? system_call_fastpath+0x16/0x1b [ 276.664756] ---[ end trace 9f5d4fcdd0c3edfc ]--- We forget to clear BCACHE_DEV_UNLINK_DONE flag in bcache_device_attach() function when we attach a backing device first time. After detaching this backing device, this flag will be true and sysfs_remove_link() isn't called in bcache_device_unlink(). Then when we attach this backing device again, sysfs_create_link() will return EEXIST error in bcache_device_link(). So the fix is trival and we clear this flag in bcache_device_link(). Signed-off-by: Zheng Liu <wenqing.lz@taobao.com> Tested-by: Joshua Schmid <jschmid@suse.com> Tested-by: Eric Wheeler <bcache@linux.ewheeler.net> Cc: Kent Overstreet <kmo@daterainc.com> Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe <axboe@fb.com> |
/linux-master/arch/x86/kvm/ | ||
H A D | hyperv.c | diff a073d7e3 Mon Sep 16 01:42:32 MDT 2019 Wanpeng Li <wanpengli@tencent.com> KVM: hyperv: Fix Direct Synthetic timers assert an interrupt w/o lapic_in_kernel Reported by syzkaller: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:__apic_accept_irq+0x46/0x740 arch/x86/kvm/lapic.c:1029 Call Trace: kvm_apic_set_irq+0xb4/0x140 arch/x86/kvm/lapic.c:558 stimer_notify_direct arch/x86/kvm/hyperv.c:648 [inline] stimer_expiration arch/x86/kvm/hyperv.c:659 [inline] kvm_hv_process_stimers+0x594/0x1650 arch/x86/kvm/hyperv.c:686 vcpu_enter_guest+0x2b2a/0x54b0 arch/x86/kvm/x86.c:7896 vcpu_run+0x393/0xd40 arch/x86/kvm/x86.c:8152 kvm_arch_vcpu_ioctl_run+0x636/0x900 arch/x86/kvm/x86.c:8360 kvm_vcpu_ioctl+0x6cf/0xaf0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2765 The testcase programs HV_X64_MSR_STIMERn_CONFIG/HV_X64_MSR_STIMERn_COUNT, in addition, there is no lapic in the kernel, the counters value are small enough in order that kvm_hv_process_stimers() inject this already-expired timer interrupt into the guest through lapic in the kernel which triggers the NULL deferencing. This patch fixes it by don't advertise direct mode synthetic timers and discarding the inject when lapic is not in kernel. syzkaller source: https://syzkaller.appspot.com/x/repro.c?x=1752fe0a600000 Reported-by: syzbot+dff25ee91f0c7d5c1695@syzkaller.appspotmail.com Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Signed-off-by: Wanpeng Li <wanpengli@tencent.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
/linux-master/fs/ | ||
H A D | dax.c | diff d77e92e2 Wed Sep 09 10:29:40 MDT 2015 Ross Zwisler <zwisler@kernel.org> dax: update PMD fault handler with PMEM API As part of the v4.3 merge window the DAX code was updated by Matthew and Kirill to handle PMD pages. Also as part of the v4.3 merge window we updated the DAX code to do proper PMEM flushing (commit 2765cfbb342c: "dax: update I/O path to do proper PMEM flushing"). The additional code added by the DAX PMD patches also needs to be updated to properly use the PMEM API. This ensures that after a PMD fault is handled the zeros written to the newly allocated pages are durable on the DIMMs. linux/dax.h is included to get rid of a bunch of sparse warnings. Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Matthew Wilcox <willy@linux.intel.com>, Cc: Dan Williams <dan.j.williams@intel.com> Cc: Kirill Shutemov <kirill@shutemov.name> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> diff 2765cfbb Tue Aug 18 13:55:40 MDT 2015 Ross Zwisler <zwisler@kernel.org> dax: update I/O path to do proper PMEM flushing Update the DAX I/O path so that all operations that store data (I/O writes, zeroing blocks, punching holes, etc.) properly synchronize the stores to media using the PMEM API. This ensures that the data DAX is writing is durable on media before the operation completes. Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dan Williams <dan.j.williams@intel.com> |
/linux-master/tools/perf/util/ | ||
H A D | evlist.c | diff 513068f2 Wed Feb 24 08:51:48 MST 2021 Namhyung Kim <namhyung@kernel.org> perf stat: Fix use-after-free when -r option is used I got a segfault when using -r option with event groups. The option makes it run the workload multiple times and it will reuse the evlist and evsel for each run. While most of resources are allocated and freed properly, the id hash in the evlist was not and it resulted in the bug. You can see it with the address sanitizer like below: $ perf stat -r 100 -e '{cycles,instructions}' true ================================================================= ==693052==ERROR: AddressSanitizer: heap-use-after-free on address 0x6080000003d0 at pc 0x558c57732835 bp 0x7fff1526adb0 sp 0x7fff1526ada8 WRITE of size 8 at 0x6080000003d0 thread T0 #0 0x558c57732834 in hlist_add_head /home/namhyung/project/linux/tools/include/linux/list.h:644 #1 0x558c57732834 in perf_evlist__id_hash /home/namhyung/project/linux/tools/lib/perf/evlist.c:237 #2 0x558c57732834 in perf_evlist__id_add /home/namhyung/project/linux/tools/lib/perf/evlist.c:244 #3 0x558c57732834 in perf_evlist__id_add_fd /home/namhyung/project/linux/tools/lib/perf/evlist.c:285 #4 0x558c5747733e in store_evsel_ids util/evsel.c:2765 #5 0x558c5747733e in evsel__store_ids util/evsel.c:2782 #6 0x558c5730b717 in __run_perf_stat /home/namhyung/project/linux/tools/perf/builtin-stat.c:895 #7 0x558c5730b717 in run_perf_stat /home/namhyung/project/linux/tools/perf/builtin-stat.c:1014 #8 0x558c5730b717 in cmd_stat /home/namhyung/project/linux/tools/perf/builtin-stat.c:2446 #9 0x558c57427c24 in run_builtin /home/namhyung/project/linux/tools/perf/perf.c:313 #10 0x558c572b1a48 in handle_internal_command /home/namhyung/project/linux/tools/perf/perf.c:365 #11 0x558c572b1a48 in run_argv /home/namhyung/project/linux/tools/perf/perf.c:409 #12 0x558c572b1a48 in main /home/namhyung/project/linux/tools/perf/perf.c:539 #13 0x7fcadb9f7d09 in __libc_start_main ../csu/libc-start.c:308 #14 0x558c572b60f9 in _start (/home/namhyung/project/linux/tools/perf/perf+0x45d0f9) Actually the nodes in the hash table are struct perf_stream_id and they were freed in the previous run. Fix it by resetting the hash. Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: https://lore.kernel.org/r/20210225035148.778569-2-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
Completed in 677 milliseconds