Searched hist:220 (Results 51 - 75 of 512) sorted by relevance
/linux-master/drivers/staging/greybus/ | ||
H A D | audio_gb.c | diff 1045451f Thu Jan 28 03:20:47 MST 2016 Viresh Kumar <viresh.kumar@linaro.org> greybus: audio: Fix sparse warnings greybus/audio_apbridgea.c:13:5: warning: symbol 'gb_audio_apbridgea_set_config' was not declared. Should it be static? greybus/audio_apbridgea.c:30:5: warning: symbol 'gb_audio_apbridgea_register_cport' was not declared. Should it be static? greybus/audio_apbridgea.c:44:5: warning: symbol 'gb_audio_apbridgea_unregister_cport' was not declared. Should it be static? greybus/audio_apbridgea.c:58:5: warning: symbol 'gb_audio_apbridgea_set_tx_data_size' was not declared. Should it be static? greybus/audio_apbridgea.c:72:5: warning: symbol 'gb_audio_apbridgea_get_tx_delay' was not declared. Should it be static? greybus/audio_apbridgea.c:80:5: warning: symbol 'gb_audio_apbridgea_start_tx' was not declared. Should it be static? greybus/audio_apbridgea.c:94:5: warning: symbol 'gb_audio_apbridgea_stop_tx' was not declared. Should it be static? greybus/audio_apbridgea.c:106:5: warning: symbol 'gb_audio_apbridgea_set_rx_data_size' was not declared. Should it be static? greybus/audio_apbridgea.c:120:5: warning: symbol 'gb_audio_apbridgea_get_rx_delay' was not declared. Should it be static? greybus/audio_apbridgea.c:128:5: warning: symbol 'gb_audio_apbridgea_start_rx' was not declared. Should it be static? greybus/audio_apbridgea.c:141:5: warning: symbol 'gb_audio_apbridgea_stop_rx' was not declared. Should it be static? greybus/audio_gb.c:14:5: warning: symbol 'gb_audio_gb_get_topology' was not declared. Should it be static? greybus/audio_gb.c:48:5: warning: symbol 'gb_audio_gb_get_control' was not declared. Should it be static? greybus/audio_gb.c:70:5: warning: symbol 'gb_audio_gb_set_control' was not declared. Should it be static? greybus/audio_gb.c:85:5: warning: symbol 'gb_audio_gb_enable_widget' was not declared. Should it be static? greybus/audio_gb.c:97:5: warning: symbol 'gb_audio_gb_disable_widget' was not declared. Should it be static? greybus/audio_gb.c:109:5: warning: symbol 'gb_audio_gb_get_pcm' was not declared. Should it be static? greybus/audio_gb.c:133:5: warning: symbol 'gb_audio_gb_set_pcm' was not declared. Should it be static? greybus/audio_gb.c:150:5: warning: symbol 'gb_audio_gb_set_tx_data_size' was not declared. Should it be static? greybus/audio_gb.c:163:5: warning: symbol 'gb_audio_gb_get_tx_delay' was not declared. Should it be static? greybus/audio_gb.c:183:5: warning: symbol 'gb_audio_gb_activate_tx' was not declared. Should it be static? greybus/audio_gb.c:195:5: warning: symbol 'gb_audio_gb_deactivate_tx' was not declared. Should it be static? greybus/audio_gb.c:207:5: warning: symbol 'gb_audio_gb_set_rx_data_size' was not declared. Should it be static? greybus/audio_gb.c:220:5: warning: symbol 'gb_audio_gb_get_rx_delay' was not declared. Should it be static? greybus/audio_gb.c:240:5: warning: symbol 'gb_audio_gb_activate_rx' was not declared. Should it be static? greybus/audio_gb.c:252:5: warning: symbol 'gb_audio_gb_deactivate_rx' was not declared. Should it be static? Fix them by including the header that declares the exported routines. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> |
H A D | audio_apbridgea.c | diff 1045451f Thu Jan 28 03:20:47 MST 2016 Viresh Kumar <viresh.kumar@linaro.org> greybus: audio: Fix sparse warnings greybus/audio_apbridgea.c:13:5: warning: symbol 'gb_audio_apbridgea_set_config' was not declared. Should it be static? greybus/audio_apbridgea.c:30:5: warning: symbol 'gb_audio_apbridgea_register_cport' was not declared. Should it be static? greybus/audio_apbridgea.c:44:5: warning: symbol 'gb_audio_apbridgea_unregister_cport' was not declared. Should it be static? greybus/audio_apbridgea.c:58:5: warning: symbol 'gb_audio_apbridgea_set_tx_data_size' was not declared. Should it be static? greybus/audio_apbridgea.c:72:5: warning: symbol 'gb_audio_apbridgea_get_tx_delay' was not declared. Should it be static? greybus/audio_apbridgea.c:80:5: warning: symbol 'gb_audio_apbridgea_start_tx' was not declared. Should it be static? greybus/audio_apbridgea.c:94:5: warning: symbol 'gb_audio_apbridgea_stop_tx' was not declared. Should it be static? greybus/audio_apbridgea.c:106:5: warning: symbol 'gb_audio_apbridgea_set_rx_data_size' was not declared. Should it be static? greybus/audio_apbridgea.c:120:5: warning: symbol 'gb_audio_apbridgea_get_rx_delay' was not declared. Should it be static? greybus/audio_apbridgea.c:128:5: warning: symbol 'gb_audio_apbridgea_start_rx' was not declared. Should it be static? greybus/audio_apbridgea.c:141:5: warning: symbol 'gb_audio_apbridgea_stop_rx' was not declared. Should it be static? greybus/audio_gb.c:14:5: warning: symbol 'gb_audio_gb_get_topology' was not declared. Should it be static? greybus/audio_gb.c:48:5: warning: symbol 'gb_audio_gb_get_control' was not declared. Should it be static? greybus/audio_gb.c:70:5: warning: symbol 'gb_audio_gb_set_control' was not declared. Should it be static? greybus/audio_gb.c:85:5: warning: symbol 'gb_audio_gb_enable_widget' was not declared. Should it be static? greybus/audio_gb.c:97:5: warning: symbol 'gb_audio_gb_disable_widget' was not declared. Should it be static? greybus/audio_gb.c:109:5: warning: symbol 'gb_audio_gb_get_pcm' was not declared. Should it be static? greybus/audio_gb.c:133:5: warning: symbol 'gb_audio_gb_set_pcm' was not declared. Should it be static? greybus/audio_gb.c:150:5: warning: symbol 'gb_audio_gb_set_tx_data_size' was not declared. Should it be static? greybus/audio_gb.c:163:5: warning: symbol 'gb_audio_gb_get_tx_delay' was not declared. Should it be static? greybus/audio_gb.c:183:5: warning: symbol 'gb_audio_gb_activate_tx' was not declared. Should it be static? greybus/audio_gb.c:195:5: warning: symbol 'gb_audio_gb_deactivate_tx' was not declared. Should it be static? greybus/audio_gb.c:207:5: warning: symbol 'gb_audio_gb_set_rx_data_size' was not declared. Should it be static? greybus/audio_gb.c:220:5: warning: symbol 'gb_audio_gb_get_rx_delay' was not declared. Should it be static? greybus/audio_gb.c:240:5: warning: symbol 'gb_audio_gb_activate_rx' was not declared. Should it be static? greybus/audio_gb.c:252:5: warning: symbol 'gb_audio_gb_deactivate_rx' was not declared. Should it be static? Fix them by including the header that declares the exported routines. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> |
/linux-master/fs/ocfs2/ | ||
H A D | ocfs2_ioctl.h | diff 220ebc43 Tue May 24 23:37:51 MDT 2011 Tristan Ye <tristan.ye@oracle.com> Ocfs2/move_extents: Adding new ioctl code 'OCFS2_IOC_MOVE_EXT' to ocfs2. Patch also manages to add a manipulative struture for this ioctl. Signed-off-by: Tristan Ye <tristan.ye@oracle.com> |
/linux-master/drivers/net/wireless/intel/ipw2x00/ | ||
H A D | ipw2200.h | diff 413cda95 Mon Sep 26 15:49:04 MDT 2022 Gustavo A. R. Silva <gustavoars@kernel.org> ipw2x00: Replace zero-length array with DECLARE_FLEX_ARRAY() helper Zero-length arrays are deprecated and we are moving towards adopting C99 flexible-array members, instead. So, replace zero-length arrays declarations in anonymous union with the new DECLARE_FLEX_ARRAY() helper macro. This helper allows for flexible-array members in unions. Link: https://github.com/KSPP/linux/issues/193 Link: https://github.com/KSPP/linux/issues/220 Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/YzIeULWc17XSIglv@work |
/linux-master/tools/perf/arch/x86/util/ | ||
H A D | topdown.h | diff 9a0b3626 Thu Jul 21 00:57:06 MDT 2022 Zhengjun Xing <zhengjun.xing@linux.intel.com> perf stat: Add topdown metrics in the default perf stat on the hybrid machine Topdown metrics are missed in the default perf stat on the hybrid machine, add Topdown metrics in default perf stat for hybrid systems. Currently, we support the perf metrics Topdown for the p-core PMU in the perf stat default, the perf metrics Topdown support for e-core PMU will be implemented later separately. Refactor the code adds two x86 specific functions. Widen the size of the event name column by 7 chars, so that all metrics after the "#" become aligned again. The perf metrics topdown feature is supported on the cpu_core of ADL. The dedicated perf metrics counter and the fixed counter 3 are used for the topdown events. Adding the topdown metrics doesn't trigger multiplexing. Before: # ./perf stat -a true Performance counter stats for 'system wide': 53.70 msec cpu-clock # 25.736 CPUs utilized 80 context-switches # 1.490 K/sec 24 cpu-migrations # 446.951 /sec 52 page-faults # 968.394 /sec 2,788,555 cpu_core/cycles/ # 51.931 M/sec 851,129 cpu_atom/cycles/ # 15.851 M/sec 2,974,030 cpu_core/instructions/ # 55.385 M/sec 416,919 cpu_atom/instructions/ # 7.764 M/sec 586,136 cpu_core/branches/ # 10.916 M/sec 79,872 cpu_atom/branches/ # 1.487 M/sec 14,220 cpu_core/branch-misses/ # 264.819 K/sec 7,691 cpu_atom/branch-misses/ # 143.229 K/sec 0.002086438 seconds time elapsed After: # ./perf stat -a true Performance counter stats for 'system wide': 61.39 msec cpu-clock # 24.874 CPUs utilized 76 context-switches # 1.238 K/sec 24 cpu-migrations # 390.968 /sec 52 page-faults # 847.097 /sec 2,753,695 cpu_core/cycles/ # 44.859 M/sec 903,899 cpu_atom/cycles/ # 14.725 M/sec 2,927,529 cpu_core/instructions/ # 47.690 M/sec 428,498 cpu_atom/instructions/ # 6.980 M/sec 581,299 cpu_core/branches/ # 9.470 M/sec 83,409 cpu_atom/branches/ # 1.359 M/sec 13,641 cpu_core/branch-misses/ # 222.216 K/sec 8,008 cpu_atom/branch-misses/ # 130.453 K/sec 14,761,308 cpu_core/slots/ # 240.466 M/sec 3,288,625 cpu_core/topdown-retiring/ # 22.3% retiring 1,323,323 cpu_core/topdown-bad-spec/ # 9.0% bad speculation 5,477,470 cpu_core/topdown-fe-bound/ # 37.1% frontend bound 4,679,199 cpu_core/topdown-be-bound/ # 31.7% backend bound 646,194 cpu_core/topdown-heavy-ops/ # 4.4% heavy operations # 17.9% light operations 1,244,999 cpu_core/topdown-br-mispredict/ # 8.4% branch mispredict # 0.5% machine clears 3,891,800 cpu_core/topdown-fetch-lat/ # 26.4% fetch latency # 10.7% fetch bandwidth 1,879,034 cpu_core/topdown-mem-bound/ # 12.7% memory bound # 19.0% Core bound 0.002467839 seconds time elapsed Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Xing Zhengjun <zhengjun.xing@linux.intel.com> Acked-by: Ian Rogers <irogers@google.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20220721065706.2886112-6-zhengjun.xing@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
/linux-master/fs/f2fs/ | ||
H A D | iostat.c | diff 0dbbf0fb Fri Jan 20 09:16:55 MST 2023 Yangtao Li <frank.li@vivo.com> f2fs: fix to avoid potential memory corruption in __update_iostat_latency() Add iotype sanity check to avoid potential memory corruption. This is to fix the compile error below: fs/f2fs/iostat.c:231 __update_iostat_latency() error: buffer overflow 'io_lat->peak_lat[type]' 3 <= 3 vim +228 fs/f2fs/iostat.c 211 static inline void __update_iostat_latency(struct bio_iostat_ctx *iostat_ctx, 212 enum iostat_lat_type type) 213 { 214 unsigned long ts_diff; 215 unsigned int page_type = iostat_ctx->type; 216 struct f2fs_sb_info *sbi = iostat_ctx->sbi; 217 struct iostat_lat_info *io_lat = sbi->iostat_io_lat; 218 unsigned long flags; 219 220 if (!sbi->iostat_enable) 221 return; 222 223 ts_diff = jiffies - iostat_ctx->submit_ts; 224 if (page_type >= META_FLUSH) ^^^^^^^^^^ 225 page_type = META; 226 227 spin_lock_irqsave(&sbi->iostat_lat_lock, flags); @228 io_lat->sum_lat[type][page_type] += ts_diff; ^^^^^^^^^ Mixup between META_FLUSH and NR_PAGE_TYPE leads to memory corruption. Fixes: a4b6817625e7 ("f2fs: introduce periodic iostat io latency traces") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Suggested-by: Chao Yu <chao@kernel.org> Suggested-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> |
/linux-master/sound/pci/mixart/ | ||
H A D | mixart_core.h | diff 4040fc51 Fri May 19 14:54:46 MDT 2023 Gustavo A. R. Silva <gustavoars@kernel.org> ALSA: mixart: Replace one-element arrays with simple object declarations One-element arrays are deprecated, and we are replacing them with flexible array members instead. However, in this case it seems those one-element arrays have never actually been used as fake flexible arrays. See this code that dates from Linux-2.6.12-rc2 initial git repository build (commit 1da177e4c3f4 ("Linux-2.6.12-rc2")): sound/pci/mixart/mixart_core.h: 215 struct mixart_stream_state_req 216 { 217 u32 delayed; 218 u64 scheduler; 219 u32 reserved4np[3]; 220 u32 stream_count; /* set to 1 for instance */ 221 struct mixart_flow_info stream_info; /* could be an array[stream_count] */ 222 } __attribute__((packed)); sound/pci/mixart/mixart.c: 388 389 memset(&stream_state_req, 0, sizeof(stream_state_req)); 390 stream_state_req.stream_count = 1; 391 stream_state_req.stream_info.stream_desc.uid_pipe = stream->pipe->group_uid; 392 stream_state_req.stream_info.stream_desc.stream_idx = stream->substream->number; 393 So, taking the code above as example, replace multiple one-element arrays with simple object declarations, and refactor the rest of the code, accordingly. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. This results in no differences in binary output. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/296 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/ZGfiFjcL8+r3mayq@work Signed-off-by: Takashi Iwai <tiwai@suse.de> |
/linux-master/drivers/media/rc/keymaps/ | ||
H A D | rc-ati-x10.c | diff 220edfb0 Sun May 11 05:17:37 MDT 2014 George Spelvin <linux@horizon.com> [media] ati_remote: Add comments to keycode table A more detailed description of what the buttons look like and their intended function makes it easier for people to maintain this code without access to the hardware. [m.chehab@samsung.com: Fixed a typo "Mdeia" instead of "Media"] Signed-off-by: George Spelvin <linux@horizon.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> |
/linux-master/Documentation/devicetree/bindings/net/ | ||
H A D | rockchip-dwmac.yaml | diff 220d63f2 Mon Apr 08 00:44:10 MDT 2024 Sascha Hauer <s.hauer@pengutronix.de> dt-bindings: net: rockchip-dwmac: use rgmii-id in example The dwmac supports specifying the RGMII clock delays, but it is recommended to use rgmii-id and to specify the delays in the phy node instead [1]. Change the example accordingly to no longer promote this undesired setting. [1] https://lore.kernel.org/all/1a0de7b4-f0f7-4080-ae48-f5ffa9e76be3@lunn.ch/ Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240408-rockchip-dwmac-rgmii-id-binding-v1-1-3886d1a8bd54@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
/linux-master/drivers/staging/rts5208/ | ||
H A D | rtsx_transport.c | diff 3331f9cb Sat Jan 14 09:58:02 MST 2017 Omri Arad <omriarad3@gmail.com> drivers: staging: rts5208: fix endianness handling 'cb' and 'sgb' were assigned __le values but were not marked as such, this fixes the following sparse warnings: drivers/staging/rts5208/rtsx_transport.c:220:34: warning: incorrect type in assignment (different base types) drivers/staging/rts5208/rtsx_transport.c:220:34: expected unsigned int [unsigned] [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:220:34: got restricted __le32 [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: warning: incorrect type in assignment (different base types) drivers/staging/rts5208/rtsx_transport.c:319:44: expected unsigned long long [unsigned] [long] [long long] [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: got restricted __le64 [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: warning: incorrect type in assignment (different base types) drivers/staging/rts5208/rtsx_transport.c:319:44: expected unsigned long long [unsigned] [long] [long long] [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: got restricted __le64 [usertype] <noident> Signed-off-by: Omri Arad <omriarad3@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 3331f9cb Sat Jan 14 09:58:02 MST 2017 Omri Arad <omriarad3@gmail.com> drivers: staging: rts5208: fix endianness handling 'cb' and 'sgb' were assigned __le values but were not marked as such, this fixes the following sparse warnings: drivers/staging/rts5208/rtsx_transport.c:220:34: warning: incorrect type in assignment (different base types) drivers/staging/rts5208/rtsx_transport.c:220:34: expected unsigned int [unsigned] [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:220:34: got restricted __le32 [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: warning: incorrect type in assignment (different base types) drivers/staging/rts5208/rtsx_transport.c:319:44: expected unsigned long long [unsigned] [long] [long long] [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: got restricted __le64 [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: warning: incorrect type in assignment (different base types) drivers/staging/rts5208/rtsx_transport.c:319:44: expected unsigned long long [unsigned] [long] [long long] [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: got restricted __le64 [usertype] <noident> Signed-off-by: Omri Arad <omriarad3@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 3331f9cb Sat Jan 14 09:58:02 MST 2017 Omri Arad <omriarad3@gmail.com> drivers: staging: rts5208: fix endianness handling 'cb' and 'sgb' were assigned __le values but were not marked as such, this fixes the following sparse warnings: drivers/staging/rts5208/rtsx_transport.c:220:34: warning: incorrect type in assignment (different base types) drivers/staging/rts5208/rtsx_transport.c:220:34: expected unsigned int [unsigned] [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:220:34: got restricted __le32 [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: warning: incorrect type in assignment (different base types) drivers/staging/rts5208/rtsx_transport.c:319:44: expected unsigned long long [unsigned] [long] [long long] [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: got restricted __le64 [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: warning: incorrect type in assignment (different base types) drivers/staging/rts5208/rtsx_transport.c:319:44: expected unsigned long long [unsigned] [long] [long long] [usertype] <noident> drivers/staging/rts5208/rtsx_transport.c:319:44: got restricted __le64 [usertype] <noident> Signed-off-by: Omri Arad <omriarad3@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
/linux-master/drivers/media/rc/ | ||
H A D | ir-hix5hd2.c | diff 7f01308e Wed Sep 24 08:07:31 MDT 2014 Mauro Carvalho Chehab <mchehab@kernel.org> [media] ir-hix5hd2: fix address space casting drivers/media/rc/ir-hix5hd2.c:99:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:99:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:99:41: got void * drivers/media/rc/ir-hix5hd2.c:100:16: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:100:16: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:100:16: got void * drivers/media/rc/ir-hix5hd2.c:117:40: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:117:40: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:117:40: got void * drivers/media/rc/ir-hix5hd2.c:119:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:119:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:119:41: got void * drivers/media/rc/ir-hix5hd2.c:121:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:121:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:121:41: got void * drivers/media/rc/ir-hix5hd2.c:147:18: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:147:18: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:147:18: got void * drivers/media/rc/ir-hix5hd2.c:155:28: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:155:28: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:155:28: got void * drivers/media/rc/ir-hix5hd2.c:157:25: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:157:25: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:157:25: got void * drivers/media/rc/ir-hix5hd2.c:159:61: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:159:61: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:159:61: got void * drivers/media/rc/ir-hix5hd2.c:167:28: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:167:28: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:167:28: got void * drivers/media/rc/ir-hix5hd2.c:169:36: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:169:36: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:169:36: got void * drivers/media/rc/ir-hix5hd2.c:188:64: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:188:64: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:188:64: got void * drivers/media/rc/ir-hix5hd2.c:190:68: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:190:68: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:190:68: got void * drivers/media/rc/ir-hix5hd2.c:220:20: warning: incorrect type in assignment (different address spaces) drivers/media/rc/ir-hix5hd2.c:220:20: expected void *base drivers/media/rc/ir-hix5hd2.c:220:20: got void [noderef] <asn:2>* drivers/media/rc/ir-hix5hd2.c:315:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:315:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:315:41: got void * drivers/media/rc/ir-hix5hd2.c:316:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:316:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:316:41: got void * drivers/media/rc/ir-hix5hd2.c:317:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:317:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:317:41: got void * drivers/media/rc/ir-hix5hd2.c:318:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:318:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:318:41: got void * Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> diff 7f01308e Wed Sep 24 08:07:31 MDT 2014 Mauro Carvalho Chehab <mchehab@kernel.org> [media] ir-hix5hd2: fix address space casting drivers/media/rc/ir-hix5hd2.c:99:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:99:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:99:41: got void * drivers/media/rc/ir-hix5hd2.c:100:16: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:100:16: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:100:16: got void * drivers/media/rc/ir-hix5hd2.c:117:40: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:117:40: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:117:40: got void * drivers/media/rc/ir-hix5hd2.c:119:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:119:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:119:41: got void * drivers/media/rc/ir-hix5hd2.c:121:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:121:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:121:41: got void * drivers/media/rc/ir-hix5hd2.c:147:18: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:147:18: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:147:18: got void * drivers/media/rc/ir-hix5hd2.c:155:28: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:155:28: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:155:28: got void * drivers/media/rc/ir-hix5hd2.c:157:25: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:157:25: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:157:25: got void * drivers/media/rc/ir-hix5hd2.c:159:61: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:159:61: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:159:61: got void * drivers/media/rc/ir-hix5hd2.c:167:28: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:167:28: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:167:28: got void * drivers/media/rc/ir-hix5hd2.c:169:36: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:169:36: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:169:36: got void * drivers/media/rc/ir-hix5hd2.c:188:64: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:188:64: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:188:64: got void * drivers/media/rc/ir-hix5hd2.c:190:68: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:190:68: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:190:68: got void * drivers/media/rc/ir-hix5hd2.c:220:20: warning: incorrect type in assignment (different address spaces) drivers/media/rc/ir-hix5hd2.c:220:20: expected void *base drivers/media/rc/ir-hix5hd2.c:220:20: got void [noderef] <asn:2>* drivers/media/rc/ir-hix5hd2.c:315:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:315:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:315:41: got void * drivers/media/rc/ir-hix5hd2.c:316:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:316:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:316:41: got void * drivers/media/rc/ir-hix5hd2.c:317:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:317:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:317:41: got void * drivers/media/rc/ir-hix5hd2.c:318:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:318:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:318:41: got void * Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> diff 7f01308e Wed Sep 24 08:07:31 MDT 2014 Mauro Carvalho Chehab <mchehab@kernel.org> [media] ir-hix5hd2: fix address space casting drivers/media/rc/ir-hix5hd2.c:99:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:99:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:99:41: got void * drivers/media/rc/ir-hix5hd2.c:100:16: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:100:16: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:100:16: got void * drivers/media/rc/ir-hix5hd2.c:117:40: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:117:40: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:117:40: got void * drivers/media/rc/ir-hix5hd2.c:119:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:119:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:119:41: got void * drivers/media/rc/ir-hix5hd2.c:121:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:121:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:121:41: got void * drivers/media/rc/ir-hix5hd2.c:147:18: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:147:18: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:147:18: got void * drivers/media/rc/ir-hix5hd2.c:155:28: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:155:28: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:155:28: got void * drivers/media/rc/ir-hix5hd2.c:157:25: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:157:25: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:157:25: got void * drivers/media/rc/ir-hix5hd2.c:159:61: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:159:61: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:159:61: got void * drivers/media/rc/ir-hix5hd2.c:167:28: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:167:28: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:167:28: got void * drivers/media/rc/ir-hix5hd2.c:169:36: warning: incorrect type in argument 1 (different address spaces) drivers/media/rc/ir-hix5hd2.c:169:36: expected void const volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:169:36: got void * drivers/media/rc/ir-hix5hd2.c:188:64: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:188:64: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:188:64: got void * drivers/media/rc/ir-hix5hd2.c:190:68: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:190:68: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:190:68: got void * drivers/media/rc/ir-hix5hd2.c:220:20: warning: incorrect type in assignment (different address spaces) drivers/media/rc/ir-hix5hd2.c:220:20: expected void *base drivers/media/rc/ir-hix5hd2.c:220:20: got void [noderef] <asn:2>* drivers/media/rc/ir-hix5hd2.c:315:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:315:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:315:41: got void * drivers/media/rc/ir-hix5hd2.c:316:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:316:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:316:41: got void * drivers/media/rc/ir-hix5hd2.c:317:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:317:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:317:41: got void * drivers/media/rc/ir-hix5hd2.c:318:41: warning: incorrect type in argument 2 (different address spaces) drivers/media/rc/ir-hix5hd2.c:318:41: expected void volatile [noderef] <asn:2>*addr drivers/media/rc/ir-hix5hd2.c:318:41: got void * Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> |
/linux-master/tools/perf/util/bpf_skel/ | ||
H A D | lock_data.h | diff 4d1792d0 Wed Sep 06 11:49:01 MDT 2023 Namhyung Kim <namhyung@kernel.org> perf lock contention: Add --lock-cgroup option The --lock-cgroup option shows lock contention stats break down by cgroups. Add LOCK_AGGR_CGROUP mode and use it instead of use_cgroup field. $ sudo ./perf lock con -ab --lock-cgroup sleep 1 contended total wait max wait avg wait cgroup 8 15.70 us 6.34 us 1.96 us / 2 1.48 us 747 ns 738 ns /user.slice/.../app.slice/app-gnome-google\x2dchrome-6442.scope 1 848 ns 848 ns 848 ns /user.slice/.../session.slice/org.gnome.Shell@x11.service 1 220 ns 220 ns 220 ns /user.slice/.../session.slice/pipewire-pulse.service For now, the cgroup mode only works with BPF (-b). Committer notes: Remove -g as it is used in the other tools with a clear meaning of collect/show callchains. As agreed with Namhyung off list. Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Hao Luo <haoluo@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <song@kernel.org> Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20230906174903.346486-4-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> diff 4d1792d0 Wed Sep 06 11:49:01 MDT 2023 Namhyung Kim <namhyung@kernel.org> perf lock contention: Add --lock-cgroup option The --lock-cgroup option shows lock contention stats break down by cgroups. Add LOCK_AGGR_CGROUP mode and use it instead of use_cgroup field. $ sudo ./perf lock con -ab --lock-cgroup sleep 1 contended total wait max wait avg wait cgroup 8 15.70 us 6.34 us 1.96 us / 2 1.48 us 747 ns 738 ns /user.slice/.../app.slice/app-gnome-google\x2dchrome-6442.scope 1 848 ns 848 ns 848 ns /user.slice/.../session.slice/org.gnome.Shell@x11.service 1 220 ns 220 ns 220 ns /user.slice/.../session.slice/pipewire-pulse.service For now, the cgroup mode only works with BPF (-b). Committer notes: Remove -g as it is used in the other tools with a clear meaning of collect/show callchains. As agreed with Namhyung off list. Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Hao Luo <haoluo@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <song@kernel.org> Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20230906174903.346486-4-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> diff 4d1792d0 Wed Sep 06 11:49:01 MDT 2023 Namhyung Kim <namhyung@kernel.org> perf lock contention: Add --lock-cgroup option The --lock-cgroup option shows lock contention stats break down by cgroups. Add LOCK_AGGR_CGROUP mode and use it instead of use_cgroup field. $ sudo ./perf lock con -ab --lock-cgroup sleep 1 contended total wait max wait avg wait cgroup 8 15.70 us 6.34 us 1.96 us / 2 1.48 us 747 ns 738 ns /user.slice/.../app.slice/app-gnome-google\x2dchrome-6442.scope 1 848 ns 848 ns 848 ns /user.slice/.../session.slice/org.gnome.Shell@x11.service 1 220 ns 220 ns 220 ns /user.slice/.../session.slice/pipewire-pulse.service For now, the cgroup mode only works with BPF (-b). Committer notes: Remove -g as it is used in the other tools with a clear meaning of collect/show callchains. As agreed with Namhyung off list. Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Hao Luo <haoluo@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <song@kernel.org> Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20230906174903.346486-4-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
/linux-master/arch/powerpc/perf/ | ||
H A D | hv-gpci.c | diff ad86d7ee Thu Feb 29 05:28:47 MST 2024 Kajol Jain <kjain@linux.ibm.com> powerpc/hv-gpci: Fix the H_GET_PERF_COUNTER_INFO hcall return value checks Running event hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ in one of the system throws below error: ---Logs--- # perf list | grep hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=?/[Kernel PMU event] # perf stat -v -e hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ sleep 2 Using CPUID 00800200 Control descriptor is not initialized Warning: hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ event is not supported by the kernel. failed to read counter hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ Performance counter stats for 'system wide': <not supported> hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ 2.000700771 seconds time elapsed The above error is because of the hcall failure as required permission "Enable Performance Information Collection" is not set. Based on current code, single_gpci_request function did not check the error type incase hcall fails and by default returns EINVAL. But we can have other reasons for hcall failures like H_AUTHORITY/H_PARAMETER with detail_rc as GEN_BUF_TOO_SMALL, for which we need to act accordingly. Fix this issue by adding new checks in the single_gpci_request and h_gpci_event_init functions. Result after fix patch changes: # perf stat -e hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ sleep 2 Error: No permission to enable hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/ event. Fixes: 220a0c609ad1 ("powerpc/perf: Add support for the hv gpci (get performance counter info) interface") Reported-by: Akanksha J N <akanksha@linux.ibm.com> Signed-off-by: Kajol Jain <kjain@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240229122847.101162-1-kjain@linux.ibm.com diff f9addd85 Fri Aug 13 02:21:58 MDT 2021 Kajol Jain <kjain@linux.ibm.com> powerpc/perf/hv-gpci: Fix counter value parsing H_GetPerformanceCounterInfo (0xF080) hcall returns the counter data in the result buffer. Result buffer has specific format defined in the PAPR specification. One of the fields is counter offset and width of the counter data returned. Counter data are returned in a unsigned char array in big endian byte order. To get the final counter data, the values must be left shifted byte at a time. But commit 220a0c609ad17 ("powerpc/perf: Add support for the hv gpci (get performance counter info) interface") made the shifting bitwise and also assumed little endian order. Because of that, hcall counters values are reported incorrectly. In particular this can lead to counters go backwards which messes up the counter prev vs now calculation and leads to huge counter value reporting: #: perf stat -e hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ -C 0 -I 1000 time counts unit events 1.000078854 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 2.000213293 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 3.000320107 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 4.000428392 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 5.000537864 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 6.000649087 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 7.000760312 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 8.000865218 16,448 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 9.000978985 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 10.001088891 16,384 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 11.001201435 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 12.001307937 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ Fix the shifting logic to correct match the format, ie. read bytes in big endian order. Fixes: e4f226b1580b ("powerpc/perf/hv-gpci: Increase request buffer size") Cc: stable@vger.kernel.org # v4.6+ Reported-by: Nageswara R Sastry<rnsastry@linux.ibm.com> Signed-off-by: Kajol Jain <kjain@linux.ibm.com> Tested-by: Nageswara R Sastry<rnsastry@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210813082158.429023-1-kjain@linux.ibm.com 220a0c60 Thu Mar 13 23:00:41 MDT 2014 Cody P Schafer <cody@linux.vnet.ibm.com> powerpc/perf: Add support for the hv gpci (get performance counter info) interface This provides a basic link between perf and hv_gpci. Notably, it does not yet support transactions and does not list any events (they can still be manually composed). Example usage via perf tool: perf stat -e 'hv_gpci/counter_info_version=3,offset=0,length=8,secondary_index=0,starting_index=0xffffffff,request=0x10/' -r 0 -C 0 -x ' ' sleep 0.1 Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> |
/linux-master/drivers/infiniband/core/ | ||
H A D | Makefile | diff ed999f82 Wed Dec 18 13:18:10 MST 2019 Chuck Lever <chuck.lever@oracle.com> RDMA/cma: Add trace points in RDMA Connection Manager Record state transitions as each connection is established. The IP address of both peers and the Type of Service is reported. These trace points are not in performance hot paths. Also, record each cm_event_handler call to ULPs. This eliminates the need for each ULP to add its own similar trace point in its CM event handler function. These new trace points appear in a new trace subsystem called "rdma_cma". Sample events: <...>-220 [004] 121.430733: cm_id_create: cm.id=0 <...>-472 [003] 121.430991: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ADDR_RESOLVED (0/0) <...>-472 [003] 121.430995: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-472 [003] 121.431172: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ROUTE_RESOLVED (2/0) <...>-472 [003] 121.431174: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 121.433480: cm_qp_create: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 pd.id=2 qp_type=RC send_wr=4091 recv_wr=256 qp_num=521 rc=0 <...>-220 [004] 121.433577: cm_send_req: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 kworker/1:2-973 [001] 121.436190: cm_send_mra: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436340: cm_send_rtu: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436359: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ESTABLISHED (9/0) kworker/1:2-973 [001] 121.436365: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-1975 [005] 123.161954: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-1975 [005] 123.161974: cm_sent_dreq: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-220 [004] 123.162102: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/0:1-13 [000] 123.162391: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 DISCONNECTED (10/0) kworker/0:1-13 [000] 123.162393: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 123.164456: cm_qp_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 <...>-220 [004] 123.165290: cm_id_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 Some features to note: - restracker ID of the rdma_cm_id is tagged on each trace event - The source and destination IP addresses and TOS are reported - CM event upcalls are shown with decoded event and status - CM state transitions are reported - rdma_cm_id lifetime events are captured - The latency of ULP CM event handlers is reported - Lifetime events of associated QPs are reported - Device removal and insertion is reported This patch is based on previous work by: Saeed Mahameed <saeedm@mellanox.com> Mukesh Kacker <mukesh.kacker@oracle.com> Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com> Aron Silverton <aron.silverton@oracle.com> Avinash Repaka <avinash.repaka@oracle.com> Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Link: https://lore.kernel.org/r/20191218201810.30584.3052.stgit@manet.1015granger.net Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> diff ed999f82 Wed Dec 18 13:18:10 MST 2019 Chuck Lever <chuck.lever@oracle.com> RDMA/cma: Add trace points in RDMA Connection Manager Record state transitions as each connection is established. The IP address of both peers and the Type of Service is reported. These trace points are not in performance hot paths. Also, record each cm_event_handler call to ULPs. This eliminates the need for each ULP to add its own similar trace point in its CM event handler function. These new trace points appear in a new trace subsystem called "rdma_cma". Sample events: <...>-220 [004] 121.430733: cm_id_create: cm.id=0 <...>-472 [003] 121.430991: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ADDR_RESOLVED (0/0) <...>-472 [003] 121.430995: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-472 [003] 121.431172: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ROUTE_RESOLVED (2/0) <...>-472 [003] 121.431174: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 121.433480: cm_qp_create: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 pd.id=2 qp_type=RC send_wr=4091 recv_wr=256 qp_num=521 rc=0 <...>-220 [004] 121.433577: cm_send_req: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 kworker/1:2-973 [001] 121.436190: cm_send_mra: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436340: cm_send_rtu: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436359: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ESTABLISHED (9/0) kworker/1:2-973 [001] 121.436365: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-1975 [005] 123.161954: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-1975 [005] 123.161974: cm_sent_dreq: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-220 [004] 123.162102: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/0:1-13 [000] 123.162391: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 DISCONNECTED (10/0) kworker/0:1-13 [000] 123.162393: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 123.164456: cm_qp_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 <...>-220 [004] 123.165290: cm_id_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 Some features to note: - restracker ID of the rdma_cm_id is tagged on each trace event - The source and destination IP addresses and TOS are reported - CM event upcalls are shown with decoded event and status - CM state transitions are reported - rdma_cm_id lifetime events are captured - The latency of ULP CM event handlers is reported - Lifetime events of associated QPs are reported - Device removal and insertion is reported This patch is based on previous work by: Saeed Mahameed <saeedm@mellanox.com> Mukesh Kacker <mukesh.kacker@oracle.com> Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com> Aron Silverton <aron.silverton@oracle.com> Avinash Repaka <avinash.repaka@oracle.com> Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Link: https://lore.kernel.org/r/20191218201810.30584.3052.stgit@manet.1015granger.net Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> diff ed999f82 Wed Dec 18 13:18:10 MST 2019 Chuck Lever <chuck.lever@oracle.com> RDMA/cma: Add trace points in RDMA Connection Manager Record state transitions as each connection is established. The IP address of both peers and the Type of Service is reported. These trace points are not in performance hot paths. Also, record each cm_event_handler call to ULPs. This eliminates the need for each ULP to add its own similar trace point in its CM event handler function. These new trace points appear in a new trace subsystem called "rdma_cma". Sample events: <...>-220 [004] 121.430733: cm_id_create: cm.id=0 <...>-472 [003] 121.430991: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ADDR_RESOLVED (0/0) <...>-472 [003] 121.430995: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-472 [003] 121.431172: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ROUTE_RESOLVED (2/0) <...>-472 [003] 121.431174: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 121.433480: cm_qp_create: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 pd.id=2 qp_type=RC send_wr=4091 recv_wr=256 qp_num=521 rc=0 <...>-220 [004] 121.433577: cm_send_req: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 kworker/1:2-973 [001] 121.436190: cm_send_mra: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436340: cm_send_rtu: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436359: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ESTABLISHED (9/0) kworker/1:2-973 [001] 121.436365: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-1975 [005] 123.161954: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-1975 [005] 123.161974: cm_sent_dreq: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-220 [004] 123.162102: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/0:1-13 [000] 123.162391: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 DISCONNECTED (10/0) kworker/0:1-13 [000] 123.162393: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 123.164456: cm_qp_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 <...>-220 [004] 123.165290: cm_id_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 Some features to note: - restracker ID of the rdma_cm_id is tagged on each trace event - The source and destination IP addresses and TOS are reported - CM event upcalls are shown with decoded event and status - CM state transitions are reported - rdma_cm_id lifetime events are captured - The latency of ULP CM event handlers is reported - Lifetime events of associated QPs are reported - Device removal and insertion is reported This patch is based on previous work by: Saeed Mahameed <saeedm@mellanox.com> Mukesh Kacker <mukesh.kacker@oracle.com> Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com> Aron Silverton <aron.silverton@oracle.com> Avinash Repaka <avinash.repaka@oracle.com> Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Link: https://lore.kernel.org/r/20191218201810.30584.3052.stgit@manet.1015granger.net Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> diff ed999f82 Wed Dec 18 13:18:10 MST 2019 Chuck Lever <chuck.lever@oracle.com> RDMA/cma: Add trace points in RDMA Connection Manager Record state transitions as each connection is established. The IP address of both peers and the Type of Service is reported. These trace points are not in performance hot paths. Also, record each cm_event_handler call to ULPs. This eliminates the need for each ULP to add its own similar trace point in its CM event handler function. These new trace points appear in a new trace subsystem called "rdma_cma". Sample events: <...>-220 [004] 121.430733: cm_id_create: cm.id=0 <...>-472 [003] 121.430991: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ADDR_RESOLVED (0/0) <...>-472 [003] 121.430995: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-472 [003] 121.431172: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ROUTE_RESOLVED (2/0) <...>-472 [003] 121.431174: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 121.433480: cm_qp_create: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 pd.id=2 qp_type=RC send_wr=4091 recv_wr=256 qp_num=521 rc=0 <...>-220 [004] 121.433577: cm_send_req: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 kworker/1:2-973 [001] 121.436190: cm_send_mra: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436340: cm_send_rtu: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436359: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ESTABLISHED (9/0) kworker/1:2-973 [001] 121.436365: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-1975 [005] 123.161954: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-1975 [005] 123.161974: cm_sent_dreq: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-220 [004] 123.162102: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/0:1-13 [000] 123.162391: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 DISCONNECTED (10/0) kworker/0:1-13 [000] 123.162393: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 123.164456: cm_qp_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 <...>-220 [004] 123.165290: cm_id_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 Some features to note: - restracker ID of the rdma_cm_id is tagged on each trace event - The source and destination IP addresses and TOS are reported - CM event upcalls are shown with decoded event and status - CM state transitions are reported - rdma_cm_id lifetime events are captured - The latency of ULP CM event handlers is reported - Lifetime events of associated QPs are reported - Device removal and insertion is reported This patch is based on previous work by: Saeed Mahameed <saeedm@mellanox.com> Mukesh Kacker <mukesh.kacker@oracle.com> Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com> Aron Silverton <aron.silverton@oracle.com> Avinash Repaka <avinash.repaka@oracle.com> Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Link: https://lore.kernel.org/r/20191218201810.30584.3052.stgit@manet.1015granger.net Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> diff ed999f82 Wed Dec 18 13:18:10 MST 2019 Chuck Lever <chuck.lever@oracle.com> RDMA/cma: Add trace points in RDMA Connection Manager Record state transitions as each connection is established. The IP address of both peers and the Type of Service is reported. These trace points are not in performance hot paths. Also, record each cm_event_handler call to ULPs. This eliminates the need for each ULP to add its own similar trace point in its CM event handler function. These new trace points appear in a new trace subsystem called "rdma_cma". Sample events: <...>-220 [004] 121.430733: cm_id_create: cm.id=0 <...>-472 [003] 121.430991: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ADDR_RESOLVED (0/0) <...>-472 [003] 121.430995: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-472 [003] 121.431172: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ROUTE_RESOLVED (2/0) <...>-472 [003] 121.431174: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 121.433480: cm_qp_create: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 pd.id=2 qp_type=RC send_wr=4091 recv_wr=256 qp_num=521 rc=0 <...>-220 [004] 121.433577: cm_send_req: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 kworker/1:2-973 [001] 121.436190: cm_send_mra: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436340: cm_send_rtu: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436359: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ESTABLISHED (9/0) kworker/1:2-973 [001] 121.436365: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-1975 [005] 123.161954: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-1975 [005] 123.161974: cm_sent_dreq: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-220 [004] 123.162102: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/0:1-13 [000] 123.162391: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 DISCONNECTED (10/0) kworker/0:1-13 [000] 123.162393: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 123.164456: cm_qp_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 <...>-220 [004] 123.165290: cm_id_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 Some features to note: - restracker ID of the rdma_cm_id is tagged on each trace event - The source and destination IP addresses and TOS are reported - CM event upcalls are shown with decoded event and status - CM state transitions are reported - rdma_cm_id lifetime events are captured - The latency of ULP CM event handlers is reported - Lifetime events of associated QPs are reported - Device removal and insertion is reported This patch is based on previous work by: Saeed Mahameed <saeedm@mellanox.com> Mukesh Kacker <mukesh.kacker@oracle.com> Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com> Aron Silverton <aron.silverton@oracle.com> Avinash Repaka <avinash.repaka@oracle.com> Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Link: https://lore.kernel.org/r/20191218201810.30584.3052.stgit@manet.1015granger.net Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> diff ed999f82 Wed Dec 18 13:18:10 MST 2019 Chuck Lever <chuck.lever@oracle.com> RDMA/cma: Add trace points in RDMA Connection Manager Record state transitions as each connection is established. The IP address of both peers and the Type of Service is reported. These trace points are not in performance hot paths. Also, record each cm_event_handler call to ULPs. This eliminates the need for each ULP to add its own similar trace point in its CM event handler function. These new trace points appear in a new trace subsystem called "rdma_cma". Sample events: <...>-220 [004] 121.430733: cm_id_create: cm.id=0 <...>-472 [003] 121.430991: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ADDR_RESOLVED (0/0) <...>-472 [003] 121.430995: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-472 [003] 121.431172: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ROUTE_RESOLVED (2/0) <...>-472 [003] 121.431174: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 121.433480: cm_qp_create: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 pd.id=2 qp_type=RC send_wr=4091 recv_wr=256 qp_num=521 rc=0 <...>-220 [004] 121.433577: cm_send_req: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 kworker/1:2-973 [001] 121.436190: cm_send_mra: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436340: cm_send_rtu: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436359: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ESTABLISHED (9/0) kworker/1:2-973 [001] 121.436365: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-1975 [005] 123.161954: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-1975 [005] 123.161974: cm_sent_dreq: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-220 [004] 123.162102: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/0:1-13 [000] 123.162391: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 DISCONNECTED (10/0) kworker/0:1-13 [000] 123.162393: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 123.164456: cm_qp_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 <...>-220 [004] 123.165290: cm_id_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 Some features to note: - restracker ID of the rdma_cm_id is tagged on each trace event - The source and destination IP addresses and TOS are reported - CM event upcalls are shown with decoded event and status - CM state transitions are reported - rdma_cm_id lifetime events are captured - The latency of ULP CM event handlers is reported - Lifetime events of associated QPs are reported - Device removal and insertion is reported This patch is based on previous work by: Saeed Mahameed <saeedm@mellanox.com> Mukesh Kacker <mukesh.kacker@oracle.com> Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com> Aron Silverton <aron.silverton@oracle.com> Avinash Repaka <avinash.repaka@oracle.com> Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Link: https://lore.kernel.org/r/20191218201810.30584.3052.stgit@manet.1015granger.net Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> |
/linux-master/include/linux/ | ||
H A D | pps_kernel.h | diff 220a60a4 Mon Sep 03 04:34:58 MDT 2012 Ben Hutchings <bhutchings@solarflare.com> pps/ptp: Allow PHC devices to adjust PPS events for known delay Initial version by Stuart Hodgson <smhodgson@solarflare.com> Some PHC device drivers may deliver PPS events with a significant and variable delay, but still be able to measure precisely what that delay is. Add a pps_sub_ts() function for subtracting a delay from the timestamp(s) in a PPS event, and a PTP event type (PTP_CLOCK_PPSUSR) for which the caller provides a complete PPS event. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> |
/linux-master/arch/hexagon/kernel/ | ||
H A D | kgdb.c | diff 3d298ca1 Fri Nov 01 05:54:17 MDT 2013 Chen Gang <gang.chen@asianux.com> hexagon: kernel: kgdb: include related header for pass compiling. Need include related headers for pass compiling, the related error (with allmodconfig for v4): CC arch/hexagon/kernel/kgdb.o arch/hexagon/kernel/kgdb.c:30: error: invalid use of undefined type 'struct pt_regs' arch/hexagon/kernel/kgdb.c:31: error: invalid use of undefined type 'struct pt_regs' ... arch/hexagon/kernel/kgdb.c:220: error: implicit declaration of function 'local_irq_save' arch/hexagon/kernel/kgdb.c:222: error: implicit declaration of function 'local_irq_restore' ... Signed-off-by: Chen Gang <gang.chen@asianux.com> Signed-off-by: Richard Kuo <rkuo@codeaurora.org> |
/linux-master/include/uapi/linux/ | ||
H A D | shm.h | diff c21a6970 Tue Apr 10 17:35:23 MDT 2018 Davidlohr Bueso <dave@stgolabs.net> ipc/shm: introduce shmctl(SHM_STAT_ANY) Patch series "sysvipc: introduce STAT_ANY commands", v2. The following patches adds the discussed (see [1]) new command for shm as well as for sems and msq as they are subject to the same discrepancies for ipc object permission checks between the syscall and via procfs. These new commands are justified in that (1) we are stuck with this semantics as changing syscall and procfs can break userland; and (2) some users can benefit from performance (for large amounts of shm segments, for example) from not having to parse the procfs interface. Once merged, I will submit the necesary manpage updates. But I'm thinking something like: : diff --git a/man2/shmctl.2 b/man2/shmctl.2 : index 7bb503999941..bb00bbe21a57 100644 : --- a/man2/shmctl.2 : +++ b/man2/shmctl.2 : @@ -41,6 +41,7 @@ : .\" 2005-04-25, mtk -- noted aberrant Linux behavior w.r.t. new : .\" attaches to a segment that has already been marked for deletion. : .\" 2005-08-02, mtk: Added IPC_INFO, SHM_INFO, SHM_STAT descriptions. : +.\" 2018-02-13, dbueso: Added SHM_STAT_ANY description. : .\" : .TH SHMCTL 2 2017-09-15 "Linux" "Linux Programmer's Manual" : .SH NAME : @@ -242,6 +243,18 @@ However, the : argument is not a segment identifier, but instead an index into : the kernel's internal array that maintains information about : all shared memory segments on the system. : +.TP : +.BR SHM_STAT_ANY " (Linux-specific)" : +Return a : +.I shmid_ds : +structure as for : +.BR SHM_STAT . : +However, the : +.I shm_perm.mode : +is not checked for read access for : +.IR shmid , : +resembing the behaviour of : +/proc/sysvipc/shm. : .PP : The caller can prevent or allow swapping of a shared : memory segment with the following \fIcmd\fP values: : @@ -287,7 +300,7 @@ operation returns the index of the highest used entry in the : kernel's internal array recording information about all : shared memory segments. : (This information can be used with repeated : -.B SHM_STAT : +.B SHM_STAT/SHM_STAT_ANY : operations to obtain information about all shared memory segments : on the system.) : A successful : @@ -328,7 +341,7 @@ isn't accessible. : \fIshmid\fP is not a valid identifier, or \fIcmd\fP : is not a valid command. : Or: for a : -.B SHM_STAT : +.B SHM_STAT/SHM_STAT_ANY : operation, the index value specified in : .I shmid : referred to an array slot that is currently unused. This patch (of 3): There is a permission discrepancy when consulting shm ipc object metadata between /proc/sysvipc/shm (0444) and the SHM_STAT shmctl command. The later does permission checks for the object vs S_IRUGO. As such there can be cases where EACCESS is returned via syscall but the info is displayed anyways in the procfs files. While this might have security implications via info leaking (albeit no writing to the shm metadata), this behavior goes way back and showing all the objects regardless of the permissions was most likely an overlook - so we are stuck with it. Furthermore, modifying either the syscall or the procfs file can cause userspace programs to break (ie ipcs). Some applications require getting the procfs info (without root privileges) and can be rather slow in comparison with a syscall -- up to 500x in some reported cases. This patch introduces a new SHM_STAT_ANY command such that the shm ipc object permissions are ignored, and only audited instead. In addition, I've left the lsm security hook checks in place, as if some policy can block the call, then the user has no other choice than just parsing the procfs file. [1] https://lkml.org/lkml/2017/12/19/220 Link: http://lkml.kernel.org/r/20180215162458.10059-2-dave@stgolabs.net Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Kees Cook <keescook@chromium.org> Cc: Robert Kettler <robert.kettler@outlook.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
/linux-master/samples/bpf/ | ||
H A D | do_hbm_test.sh | diff 71634d7f Tue Jul 02 16:09:52 MDT 2019 brakmo <brakmo@fb.com> bpf: Add support for fq's EDT to HBM Adds support for fq's Earliest Departure Time to HBM (Host Bandwidth Manager). Includes a new BPF program supporting EDT, and also updates corresponding programs. It will drop packets with an EDT of more than 500us in the future unless the packet belongs to a flow with less than 2 packets in flight. This is done so each flow has at least 2 packets in flight, so they will not starve, and also to help prevent delayed ACK timeouts. It will also work with ECN enabled traffic, where the packets will be CE marked if their EDT is more than 50us in the future. The table below shows some performance numbers. The flows are back to back RPCS. One server sending to another, either 2 or 4 flows. One flow is a 10KB RPC, the rest are 1MB RPCs. When there are more than one flow of a given RPC size, the numbers represent averages. The rate limit applies to all flows (they are in the same cgroup). Tests ending with "-edt" ran with the new BPF program supporting EDT. Tests ending with "-hbt" ran on top HBT qdisc with the specified rate (i.e. no HBM). The other tests ran with the HBM BPF program included in the HBM patch-set. EDT has limited value when using DCTCP, but it helps in many cases when using Cubic. It usually achieves larger link utilization and lower 99% latencies for the 1MB RPCs. HBM ends up queueing a lot of packets with its default parameter values, reducing the goodput of the 10KB RPCs and increasing their latency. Also, the RTTs seen by the flows are quite large. Aggr 10K 10K 10K 1MB 1MB 1MB Limit rate drops RTT rate P90 P99 rate P90 P99 Test rate Flows Mbps % us Mbps us us Mbps ms ms -------- ---- ----- ---- ----- --- ---- ---- ---- ---- ---- ---- cubic 1G 2 904 0.02 108 257 511 539 647 13.4 24.5 cubic-edt 1G 2 982 0.01 156 239 656 967 743 14.0 17.2 dctcp 1G 2 977 0.00 105 324 408 744 653 14.5 15.9 dctcp-edt 1G 2 981 0.01 142 321 417 811 660 15.7 17.0 cubic-htb 1G 2 919 0.00 1825 40 2822 4140 879 9.7 9.9 cubic 200M 2 155 0.30 220 81 532 655 74 283 450 cubic-edt 200M 2 188 0.02 222 87 1035 1095 101 84 85 dctcp 200M 2 188 0.03 111 77 912 939 111 76 325 dctcp-edt 200M 2 188 0.03 217 74 1416 1738 114 76 79 cubic-htb 200M 2 188 0.00 5015 8 14ms 15ms 180 48 50 cubic 1G 4 952 0.03 110 165 516 546 262 38 154 cubic-edt 1G 4 973 0.01 190 111 1034 1314 287 65 79 dctcp 1G 4 951 0.00 103 180 617 905 257 37 38 dctcp-edt 1G 4 967 0.00 163 151 732 1126 272 43 55 cubic-htb 1G 4 914 0.00 3249 13 7ms 8ms 300 29 34 cubic 5G 4 4236 0.00 134 305 490 624 1310 10 17 cubic-edt 5G 4 4865 0.00 156 306 425 759 1520 10 16 dctcp 5G 4 4936 0.00 128 485 221 409 1484 7 9 dctcp-edt 5G 4 4924 0.00 148 390 392 623 1508 11 26 v1 -> v2: Incorporated Andrii's suggestions v2 -> v3: Incorporated Yonghong's suggestions v3 -> v4: Removed credit update that is not needed Signed-off-by: Lawrence Brakmo <brakmo@fb.com> Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> |
H A D | hbm_kern.h | diff 71634d7f Tue Jul 02 16:09:52 MDT 2019 brakmo <brakmo@fb.com> bpf: Add support for fq's EDT to HBM Adds support for fq's Earliest Departure Time to HBM (Host Bandwidth Manager). Includes a new BPF program supporting EDT, and also updates corresponding programs. It will drop packets with an EDT of more than 500us in the future unless the packet belongs to a flow with less than 2 packets in flight. This is done so each flow has at least 2 packets in flight, so they will not starve, and also to help prevent delayed ACK timeouts. It will also work with ECN enabled traffic, where the packets will be CE marked if their EDT is more than 50us in the future. The table below shows some performance numbers. The flows are back to back RPCS. One server sending to another, either 2 or 4 flows. One flow is a 10KB RPC, the rest are 1MB RPCs. When there are more than one flow of a given RPC size, the numbers represent averages. The rate limit applies to all flows (they are in the same cgroup). Tests ending with "-edt" ran with the new BPF program supporting EDT. Tests ending with "-hbt" ran on top HBT qdisc with the specified rate (i.e. no HBM). The other tests ran with the HBM BPF program included in the HBM patch-set. EDT has limited value when using DCTCP, but it helps in many cases when using Cubic. It usually achieves larger link utilization and lower 99% latencies for the 1MB RPCs. HBM ends up queueing a lot of packets with its default parameter values, reducing the goodput of the 10KB RPCs and increasing their latency. Also, the RTTs seen by the flows are quite large. Aggr 10K 10K 10K 1MB 1MB 1MB Limit rate drops RTT rate P90 P99 rate P90 P99 Test rate Flows Mbps % us Mbps us us Mbps ms ms -------- ---- ----- ---- ----- --- ---- ---- ---- ---- ---- ---- cubic 1G 2 904 0.02 108 257 511 539 647 13.4 24.5 cubic-edt 1G 2 982 0.01 156 239 656 967 743 14.0 17.2 dctcp 1G 2 977 0.00 105 324 408 744 653 14.5 15.9 dctcp-edt 1G 2 981 0.01 142 321 417 811 660 15.7 17.0 cubic-htb 1G 2 919 0.00 1825 40 2822 4140 879 9.7 9.9 cubic 200M 2 155 0.30 220 81 532 655 74 283 450 cubic-edt 200M 2 188 0.02 222 87 1035 1095 101 84 85 dctcp 200M 2 188 0.03 111 77 912 939 111 76 325 dctcp-edt 200M 2 188 0.03 217 74 1416 1738 114 76 79 cubic-htb 200M 2 188 0.00 5015 8 14ms 15ms 180 48 50 cubic 1G 4 952 0.03 110 165 516 546 262 38 154 cubic-edt 1G 4 973 0.01 190 111 1034 1314 287 65 79 dctcp 1G 4 951 0.00 103 180 617 905 257 37 38 dctcp-edt 1G 4 967 0.00 163 151 732 1126 272 43 55 cubic-htb 1G 4 914 0.00 3249 13 7ms 8ms 300 29 34 cubic 5G 4 4236 0.00 134 305 490 624 1310 10 17 cubic-edt 5G 4 4865 0.00 156 306 425 759 1520 10 16 dctcp 5G 4 4936 0.00 128 485 221 409 1484 7 9 dctcp-edt 5G 4 4924 0.00 148 390 392 623 1508 11 26 v1 -> v2: Incorporated Andrii's suggestions v2 -> v3: Incorporated Yonghong's suggestions v3 -> v4: Removed credit update that is not needed Signed-off-by: Lawrence Brakmo <brakmo@fb.com> Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> |
/linux-master/arch/arm64/crypto/ | ||
H A D | poly1305-glue.c | diff 7ae19d42 Fri Jul 22 00:31:57 MDT 2022 GUO Zihua <guozihua@huawei.com> crypto: arm64/poly1305 - fix a read out-of-bound A kasan error was reported during fuzzing: BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019 Call trace: dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x158/0x1e4 lib/dump_stack.c:118 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140 mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131 [inline] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200 [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134 [inline] __se_sys_setsockopt net/socket.c:2131 [inline] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683 This error can be reproduced by the following code compiled as ko on a system with kasan enabled: #include <linux/module.h> #include <linux/crypto.h> #include <crypto/hash.h> #include <crypto/poly1305.h> char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07" "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f" "\x10\x11\x12\x13\x14\x15\x16\x17" "\x18\x19\x1a\x1b\x1c\x1d\x1e"; int init(void) { struct crypto_shash *tfm = NULL; char *data = NULL, *out = NULL; tfm = crypto_alloc_shash("poly1305", 0, 0); data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(data, test_data, POLY1305_KEY_SIZE - 1); crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out); kfree(data); kfree(out); return 0; } void deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE("GPL"); The root cause of the bug sits in neon_poly1305_blocks. The logic neon_poly1305_blocks() performed is that if it was called with both s[] and r[] uninitialized, it will first try to initialize them with the data from the first "block" that it believed to be 32 bytes in length. First 16 bytes are used as the key and the next 16 bytes for s[]. This would lead to the aforementioned read out-of-bound. However, after calling poly1305_init_arch(), only 16 bytes were deducted from the input and s[] is initialized yet again with the following 16 bytes. The second initialization of s[] is certainly redundent which indicates that the first initialization should be for r[] only. This patch fixes the issue by calling poly1305_init_arm64() instead of poly1305_init_arch(). This is also the implementation for the same algorithm on arm platform. Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation") Cc: stable@vger.kernel.org Signed-off-by: GUO Zihua <guozihua@huawei.com> Reviewed-by: Eric Biggers <ebiggers@google.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> |
/linux-master/Documentation/kernel-hacking/ | ||
H A D | locking.rst | diff 220ee02a Thu Jun 13 10:25:48 MDT 2019 Stephen Kitt <steve@sk2.org> docs: stop suggesting strlcpy Since strlcpy is deprecated, the documentation shouldn't suggest using it. This patch fixes the examples to use strscpy instead. It also uses sizeof instead of underlying constants as far as possible, to simplify future changes to the corresponding data structures. Signed-off-by: Stephen Kitt <steve@sk2.org> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Jonathan Corbet <corbet@lwn.net> |
/linux-master/drivers/usb/gadget/udc/aspeed-vhub/ | ||
H A D | hub.c | diff 220fafb4 Wed Jul 13 06:05:28 MDT 2022 Liang He <windhl@126.com> usb: aspeed-vhub: Fix refcount leak bug in ast_vhub_init_desc() We should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. Fixes: 30d2617fd7ed ("usb: gadget: aspeed: allow to set usb strings in device tree") Signed-off-by: Liang He <windhl@126.com> Link: https://lore.kernel.org/r/20220713120528.368168-1-windhl@126.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
/linux-master/drivers/md/bcache/ | ||
H A D | stats.h | diff 220bb38c Tue Sep 10 20:02:45 MDT 2013 Kent Overstreet <kmo@daterainc.com> bcache: Break up struct search With all the recent refactoring around struct btree op struct search has gotten rather large. But we can now easily break it up in a different way - we break out struct btree_insert_op which is for inserting data into the cache, and that's now what the copying gc code uses - struct search is now specific to request.c Signed-off-by: Kent Overstreet <kmo@daterainc.com> |
/linux-master/tools/perf/util/ | ||
H A D | topdown.c | diff 9a0b3626 Thu Jul 21 00:57:06 MDT 2022 Zhengjun Xing <zhengjun.xing@linux.intel.com> perf stat: Add topdown metrics in the default perf stat on the hybrid machine Topdown metrics are missed in the default perf stat on the hybrid machine, add Topdown metrics in default perf stat for hybrid systems. Currently, we support the perf metrics Topdown for the p-core PMU in the perf stat default, the perf metrics Topdown support for e-core PMU will be implemented later separately. Refactor the code adds two x86 specific functions. Widen the size of the event name column by 7 chars, so that all metrics after the "#" become aligned again. The perf metrics topdown feature is supported on the cpu_core of ADL. The dedicated perf metrics counter and the fixed counter 3 are used for the topdown events. Adding the topdown metrics doesn't trigger multiplexing. Before: # ./perf stat -a true Performance counter stats for 'system wide': 53.70 msec cpu-clock # 25.736 CPUs utilized 80 context-switches # 1.490 K/sec 24 cpu-migrations # 446.951 /sec 52 page-faults # 968.394 /sec 2,788,555 cpu_core/cycles/ # 51.931 M/sec 851,129 cpu_atom/cycles/ # 15.851 M/sec 2,974,030 cpu_core/instructions/ # 55.385 M/sec 416,919 cpu_atom/instructions/ # 7.764 M/sec 586,136 cpu_core/branches/ # 10.916 M/sec 79,872 cpu_atom/branches/ # 1.487 M/sec 14,220 cpu_core/branch-misses/ # 264.819 K/sec 7,691 cpu_atom/branch-misses/ # 143.229 K/sec 0.002086438 seconds time elapsed After: # ./perf stat -a true Performance counter stats for 'system wide': 61.39 msec cpu-clock # 24.874 CPUs utilized 76 context-switches # 1.238 K/sec 24 cpu-migrations # 390.968 /sec 52 page-faults # 847.097 /sec 2,753,695 cpu_core/cycles/ # 44.859 M/sec 903,899 cpu_atom/cycles/ # 14.725 M/sec 2,927,529 cpu_core/instructions/ # 47.690 M/sec 428,498 cpu_atom/instructions/ # 6.980 M/sec 581,299 cpu_core/branches/ # 9.470 M/sec 83,409 cpu_atom/branches/ # 1.359 M/sec 13,641 cpu_core/branch-misses/ # 222.216 K/sec 8,008 cpu_atom/branch-misses/ # 130.453 K/sec 14,761,308 cpu_core/slots/ # 240.466 M/sec 3,288,625 cpu_core/topdown-retiring/ # 22.3% retiring 1,323,323 cpu_core/topdown-bad-spec/ # 9.0% bad speculation 5,477,470 cpu_core/topdown-fe-bound/ # 37.1% frontend bound 4,679,199 cpu_core/topdown-be-bound/ # 31.7% backend bound 646,194 cpu_core/topdown-heavy-ops/ # 4.4% heavy operations # 17.9% light operations 1,244,999 cpu_core/topdown-br-mispredict/ # 8.4% branch mispredict # 0.5% machine clears 3,891,800 cpu_core/topdown-fetch-lat/ # 26.4% fetch latency # 10.7% fetch bandwidth 1,879,034 cpu_core/topdown-mem-bound/ # 12.7% memory bound # 19.0% Core bound 0.002467839 seconds time elapsed Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Xing Zhengjun <zhengjun.xing@linux.intel.com> Acked-by: Ian Rogers <irogers@google.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20220721065706.2886112-6-zhengjun.xing@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
H A D | topdown.h | diff 9a0b3626 Thu Jul 21 00:57:06 MDT 2022 Zhengjun Xing <zhengjun.xing@linux.intel.com> perf stat: Add topdown metrics in the default perf stat on the hybrid machine Topdown metrics are missed in the default perf stat on the hybrid machine, add Topdown metrics in default perf stat for hybrid systems. Currently, we support the perf metrics Topdown for the p-core PMU in the perf stat default, the perf metrics Topdown support for e-core PMU will be implemented later separately. Refactor the code adds two x86 specific functions. Widen the size of the event name column by 7 chars, so that all metrics after the "#" become aligned again. The perf metrics topdown feature is supported on the cpu_core of ADL. The dedicated perf metrics counter and the fixed counter 3 are used for the topdown events. Adding the topdown metrics doesn't trigger multiplexing. Before: # ./perf stat -a true Performance counter stats for 'system wide': 53.70 msec cpu-clock # 25.736 CPUs utilized 80 context-switches # 1.490 K/sec 24 cpu-migrations # 446.951 /sec 52 page-faults # 968.394 /sec 2,788,555 cpu_core/cycles/ # 51.931 M/sec 851,129 cpu_atom/cycles/ # 15.851 M/sec 2,974,030 cpu_core/instructions/ # 55.385 M/sec 416,919 cpu_atom/instructions/ # 7.764 M/sec 586,136 cpu_core/branches/ # 10.916 M/sec 79,872 cpu_atom/branches/ # 1.487 M/sec 14,220 cpu_core/branch-misses/ # 264.819 K/sec 7,691 cpu_atom/branch-misses/ # 143.229 K/sec 0.002086438 seconds time elapsed After: # ./perf stat -a true Performance counter stats for 'system wide': 61.39 msec cpu-clock # 24.874 CPUs utilized 76 context-switches # 1.238 K/sec 24 cpu-migrations # 390.968 /sec 52 page-faults # 847.097 /sec 2,753,695 cpu_core/cycles/ # 44.859 M/sec 903,899 cpu_atom/cycles/ # 14.725 M/sec 2,927,529 cpu_core/instructions/ # 47.690 M/sec 428,498 cpu_atom/instructions/ # 6.980 M/sec 581,299 cpu_core/branches/ # 9.470 M/sec 83,409 cpu_atom/branches/ # 1.359 M/sec 13,641 cpu_core/branch-misses/ # 222.216 K/sec 8,008 cpu_atom/branch-misses/ # 130.453 K/sec 14,761,308 cpu_core/slots/ # 240.466 M/sec 3,288,625 cpu_core/topdown-retiring/ # 22.3% retiring 1,323,323 cpu_core/topdown-bad-spec/ # 9.0% bad speculation 5,477,470 cpu_core/topdown-fe-bound/ # 37.1% frontend bound 4,679,199 cpu_core/topdown-be-bound/ # 31.7% backend bound 646,194 cpu_core/topdown-heavy-ops/ # 4.4% heavy operations # 17.9% light operations 1,244,999 cpu_core/topdown-br-mispredict/ # 8.4% branch mispredict # 0.5% machine clears 3,891,800 cpu_core/topdown-fetch-lat/ # 26.4% fetch latency # 10.7% fetch bandwidth 1,879,034 cpu_core/topdown-mem-bound/ # 12.7% memory bound # 19.0% Core bound 0.002467839 seconds time elapsed Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Xing Zhengjun <zhengjun.xing@linux.intel.com> Acked-by: Ian Rogers <irogers@google.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20220721065706.2886112-6-zhengjun.xing@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
Completed in 824 milliseconds