Searched hist:2765 (Results 1 - 17 of 17) sorted by relevance

/linux-master/arch/sparc/include/asm/
H A Dparport_64.hdiff 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 DKconfig.aic79xxdiff 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 Dunistd.hdiff 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 Dstv0367.cdiff 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 Dlink_dpms.cdiff 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 Drecovery.cdiff 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 Diphase.cdiff 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 De1000_82575.cdiff 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 Dlog.cdiff 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 Dcore.cdiff 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 Dsm8150.dtsidiff 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 Dsm8150.dtsidiff 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 Dmtk-sd.cdiff 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 Dsuper.cdiff 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 Dhyperv.cdiff 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 Ddax.cdiff 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 Devlist.cdiff 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