Searched hist:8225 (Results 1 - 22 of 22) sorted by relevance
/linux-master/arch/arm/lib/ | ||
H A D | copy_template.S | diff ba999a04 Sun Oct 03 11:05:53 MDT 2021 Ard Biesheuvel <ardb@kernel.org> ARM: memcpy: use frame pointer as unwind anchor The memcpy template is a bit unusual in the way it manages the stack pointer: depending on the execution path through the function, the SP assumes different values as different subsets of the register file are preserved and restored again. This is problematic when it comes to EHABI unwind info, as it is not instruction accurate, and does not allow tracking the SP value as it changes. Commit 279f487e0b471 ("ARM: 8225/1: Add unwinding support for memory copy functions") addressed this by carving up the function in different chunks as far as the unwinder is concerned, and keeping a set of unwind directives for each of them, each corresponding with the state of the stack pointer during execution of the chunk in question. This not only duplicates unwind info unnecessarily, but it also complicates unwinding the stack upon overflow. Instead, let's do what the compiler does when the SP is updated halfway through a function, which is to use a frame pointer and emit the appropriate unwind directives to communicate this to the unwinder. Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's avoid touching R7 in the body of the template, so that Thumb-2 can use it as the frame pointer. R11 was not modified in the first place. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Keith Packard <keithpac@amazon.com> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M diff 279f487e Wed Nov 26 06:38:33 MST 2014 Lin Yongting <linyongting@gmail.com> ARM: 8225/1: Add unwinding support for memory copy functions The memory copy functions(memcpy, __copy_from_user, __copy_to_user) never had unwinding annotations added. Currently, when accessing invalid pointer by these functions occurs the backtrace shown will stop at these functions or some completely unrelated function. Add unwinding annotations in hopes of getting a more useful backtrace in following cases: 1. die on accessing invalid pointer by these functions 2. kprobe trapped at any instruction within these functions 3. interrupted at any instruction within these functions Signed-off-by: Lin Yongting <linyongting@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> |
H A D | copy_from_user.S | diff ba999a04 Sun Oct 03 11:05:53 MDT 2021 Ard Biesheuvel <ardb@kernel.org> ARM: memcpy: use frame pointer as unwind anchor The memcpy template is a bit unusual in the way it manages the stack pointer: depending on the execution path through the function, the SP assumes different values as different subsets of the register file are preserved and restored again. This is problematic when it comes to EHABI unwind info, as it is not instruction accurate, and does not allow tracking the SP value as it changes. Commit 279f487e0b471 ("ARM: 8225/1: Add unwinding support for memory copy functions") addressed this by carving up the function in different chunks as far as the unwinder is concerned, and keeping a set of unwind directives for each of them, each corresponding with the state of the stack pointer during execution of the chunk in question. This not only duplicates unwind info unnecessarily, but it also complicates unwinding the stack upon overflow. Instead, let's do what the compiler does when the SP is updated halfway through a function, which is to use a frame pointer and emit the appropriate unwind directives to communicate this to the unwinder. Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's avoid touching R7 in the body of the template, so that Thumb-2 can use it as the frame pointer. R11 was not modified in the first place. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Keith Packard <keithpac@amazon.com> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M diff 279f487e Wed Nov 26 06:38:33 MST 2014 Lin Yongting <linyongting@gmail.com> ARM: 8225/1: Add unwinding support for memory copy functions The memory copy functions(memcpy, __copy_from_user, __copy_to_user) never had unwinding annotations added. Currently, when accessing invalid pointer by these functions occurs the backtrace shown will stop at these functions or some completely unrelated function. Add unwinding annotations in hopes of getting a more useful backtrace in following cases: 1. die on accessing invalid pointer by these functions 2. kprobe trapped at any instruction within these functions 3. interrupted at any instruction within these functions Signed-off-by: Lin Yongting <linyongting@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> |
H A D | memcpy.S | diff ba999a04 Sun Oct 03 11:05:53 MDT 2021 Ard Biesheuvel <ardb@kernel.org> ARM: memcpy: use frame pointer as unwind anchor The memcpy template is a bit unusual in the way it manages the stack pointer: depending on the execution path through the function, the SP assumes different values as different subsets of the register file are preserved and restored again. This is problematic when it comes to EHABI unwind info, as it is not instruction accurate, and does not allow tracking the SP value as it changes. Commit 279f487e0b471 ("ARM: 8225/1: Add unwinding support for memory copy functions") addressed this by carving up the function in different chunks as far as the unwinder is concerned, and keeping a set of unwind directives for each of them, each corresponding with the state of the stack pointer during execution of the chunk in question. This not only duplicates unwind info unnecessarily, but it also complicates unwinding the stack upon overflow. Instead, let's do what the compiler does when the SP is updated halfway through a function, which is to use a frame pointer and emit the appropriate unwind directives to communicate this to the unwinder. Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's avoid touching R7 in the body of the template, so that Thumb-2 can use it as the frame pointer. R11 was not modified in the first place. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Keith Packard <keithpac@amazon.com> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M diff 279f487e Wed Nov 26 06:38:33 MST 2014 Lin Yongting <linyongting@gmail.com> ARM: 8225/1: Add unwinding support for memory copy functions The memory copy functions(memcpy, __copy_from_user, __copy_to_user) never had unwinding annotations added. Currently, when accessing invalid pointer by these functions occurs the backtrace shown will stop at these functions or some completely unrelated function. Add unwinding annotations in hopes of getting a more useful backtrace in following cases: 1. die on accessing invalid pointer by these functions 2. kprobe trapped at any instruction within these functions 3. interrupted at any instruction within these functions Signed-off-by: Lin Yongting <linyongting@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> |
H A D | copy_to_user.S | diff ba999a04 Sun Oct 03 11:05:53 MDT 2021 Ard Biesheuvel <ardb@kernel.org> ARM: memcpy: use frame pointer as unwind anchor The memcpy template is a bit unusual in the way it manages the stack pointer: depending on the execution path through the function, the SP assumes different values as different subsets of the register file are preserved and restored again. This is problematic when it comes to EHABI unwind info, as it is not instruction accurate, and does not allow tracking the SP value as it changes. Commit 279f487e0b471 ("ARM: 8225/1: Add unwinding support for memory copy functions") addressed this by carving up the function in different chunks as far as the unwinder is concerned, and keeping a set of unwind directives for each of them, each corresponding with the state of the stack pointer during execution of the chunk in question. This not only duplicates unwind info unnecessarily, but it also complicates unwinding the stack upon overflow. Instead, let's do what the compiler does when the SP is updated halfway through a function, which is to use a frame pointer and emit the appropriate unwind directives to communicate this to the unwinder. Note that Thumb-2 uses R7 for this, while ARM uses R11 aka FP. So let's avoid touching R7 in the body of the template, so that Thumb-2 can use it as the frame pointer. R11 was not modified in the first place. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Keith Packard <keithpac@amazon.com> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M diff 279f487e Wed Nov 26 06:38:33 MST 2014 Lin Yongting <linyongting@gmail.com> ARM: 8225/1: Add unwinding support for memory copy functions The memory copy functions(memcpy, __copy_from_user, __copy_to_user) never had unwinding annotations added. Currently, when accessing invalid pointer by these functions occurs the backtrace shown will stop at these functions or some completely unrelated function. Add unwinding annotations in hopes of getting a more useful backtrace in following cases: 1. die on accessing invalid pointer by these functions 2. kprobe trapped at any instruction within these functions 3. interrupted at any instruction within these functions Signed-off-by: Lin Yongting <linyongting@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> |
/linux-master/Documentation/devicetree/bindings/display/msm/ | ||
H A D | qcom,sc7180-dpu.yaml | diff 8225df64 Sun Jul 23 10:08:46 MDT 2023 Marijn Suijten <marijn.suijten@somainline.org> dt-bindings: display/msm: sc7180-dpu: Describe SM6125 SM6125 is identical to SM6375 including the throttle clock that is also provided to the MDP node downstream. Note that any SoC other than SM6375 (currently SC7180 and SM6350) has an unconstrained maximum number of clocks and could either pass or leave out this "throttle" clock. Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Patchwork: https://patchwork.freedesktop.org/patch/548972/ Link: https://lore.kernel.org/r/20230723-sm6125-dpu-v4-8-a3f287dd6c07@somainline.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> |
/linux-master/drivers/scsi/aic7xxx/ | ||
H A D | aic7770_osm.c | diff 172c122d Mon Apr 28 17:50:03 MDT 2008 Harvey Harrison <harvey.harrison@gmail.com> scsi: fix integer as NULL pointer warnings drivers/scsi/aic7xxx/aic7770_osm.c:53:58: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:355:47: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:372:55: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:997:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1003:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1165:46: warning: Using plain integer as NULL pointer drivers/scsi/fdomain.c:1446:40: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:1650:51: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:3171:42: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:5732:52: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8189:31: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8225:34: warning: Using plain integer as NULL pointer drivers/scsi/dpt_i2o.c:156:32: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:954:42: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:1104:18: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
H A D | aic7xxx_osm_pci.c | diff 172c122d Mon Apr 28 17:50:03 MDT 2008 Harvey Harrison <harvey.harrison@gmail.com> scsi: fix integer as NULL pointer warnings drivers/scsi/aic7xxx/aic7770_osm.c:53:58: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:355:47: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:372:55: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:997:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1003:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1165:46: warning: Using plain integer as NULL pointer drivers/scsi/fdomain.c:1446:40: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:1650:51: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:3171:42: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:5732:52: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8189:31: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8225:34: warning: Using plain integer as NULL pointer drivers/scsi/dpt_i2o.c:156:32: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:954:42: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:1104:18: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
/linux-master/Documentation/devicetree/bindings/media/ | ||
H A D | renesas,drif.yaml | diff 8225b9e1 Wed Oct 21 07:53:31 MDT 2020 Fabrizio Castro <fabrizio.castro.jz@renesas.com> media: dt-bindings: media: renesas,drif: Add r8a77965 support The r8a77965 (a.k.a. R-Car M3-N) device tree schema is compatible with the already documented R-Car Gen3 devices. Document r8a77965 support within renesas,drif.yaml. Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
/linux-master/arch/powerpc/kernel/ | ||
H A D | eeh_sysfs.c | diff 8225d543 Sat Jul 25 02:12:25 MDT 2020 Oliver O'Halloran <oohall@gmail.com> powerpc/eeh: Pass eeh_dev to eeh_ops->resume_notify() Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference a specific device rather than pci_dn. No functional changes. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200725081231.39076-8-oohall@gmail.com |
H A D | eeh_driver.c | diff 8225d543 Sat Jul 25 02:12:25 MDT 2020 Oliver O'Halloran <oohall@gmail.com> powerpc/eeh: Pass eeh_dev to eeh_ops->resume_notify() Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference a specific device rather than pci_dn. No functional changes. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200725081231.39076-8-oohall@gmail.com |
/linux-master/drivers/scsi/ | ||
H A D | fdomain.c | diff 172c122d Mon Apr 28 17:50:03 MDT 2008 Harvey Harrison <harvey.harrison@gmail.com> scsi: fix integer as NULL pointer warnings drivers/scsi/aic7xxx/aic7770_osm.c:53:58: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:355:47: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:372:55: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:997:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1003:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1165:46: warning: Using plain integer as NULL pointer drivers/scsi/fdomain.c:1446:40: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:1650:51: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:3171:42: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:5732:52: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8189:31: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8225:34: warning: Using plain integer as NULL pointer drivers/scsi/dpt_i2o.c:156:32: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:954:42: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:1104:18: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
H A D | ncr53c8xx.c | diff 726792b2 Thu May 01 05:35:20 MDT 2008 Andrew Morton <akpm@linux-foundation.org> drivers/scsi/ncr53c8xx.c: fix warning drivers/scsi/ncr53c8xx.c: In function 'process_waiting_list': drivers/scsi/ncr53c8xx.c:8225: warning: suggest parentheses around assignment used as truth value recently added by commit 172c122df5186e7cbd413d61757ff90267331002 Author: Harvey Harrison <harvey.harrison@gmail.com> Date: Mon Apr 28 16:50:03 2008 -0700 scsi: fix integer as NULL pointer warnings Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> diff 172c122d Mon Apr 28 17:50:03 MDT 2008 Harvey Harrison <harvey.harrison@gmail.com> scsi: fix integer as NULL pointer warnings drivers/scsi/aic7xxx/aic7770_osm.c:53:58: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:355:47: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:372:55: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:997:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1003:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1165:46: warning: Using plain integer as NULL pointer drivers/scsi/fdomain.c:1446:40: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:1650:51: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:3171:42: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:5732:52: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8189:31: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8225:34: warning: Using plain integer as NULL pointer drivers/scsi/dpt_i2o.c:156:32: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:954:42: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:1104:18: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
H A D | aha152x.c | diff 172c122d Mon Apr 28 17:50:03 MDT 2008 Harvey Harrison <harvey.harrison@gmail.com> scsi: fix integer as NULL pointer warnings drivers/scsi/aic7xxx/aic7770_osm.c:53:58: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:355:47: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:372:55: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:997:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1003:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1165:46: warning: Using plain integer as NULL pointer drivers/scsi/fdomain.c:1446:40: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:1650:51: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:3171:42: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:5732:52: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8189:31: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8225:34: warning: Using plain integer as NULL pointer drivers/scsi/dpt_i2o.c:156:32: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:954:42: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:1104:18: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
/linux-master/drivers/scsi/sym53c8xx_2/ | ||
H A D | sym_hipd.c | diff 172c122d Mon Apr 28 17:50:03 MDT 2008 Harvey Harrison <harvey.harrison@gmail.com> scsi: fix integer as NULL pointer warnings drivers/scsi/aic7xxx/aic7770_osm.c:53:58: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:355:47: warning: Using plain integer as NULL pointer drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:372:55: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:997:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1003:28: warning: Using plain integer as NULL pointer drivers/scsi/aha152x.c:1165:46: warning: Using plain integer as NULL pointer drivers/scsi/fdomain.c:1446:40: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:1650:51: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:3171:42: warning: Using plain integer as NULL pointer drivers/scsi/sym53c8xx_2/sym_hipd.c:5732:52: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8189:31: warning: Using plain integer as NULL pointer drivers/scsi/ncr53c8xx.c:8225:34: warning: Using plain integer as NULL pointer drivers/scsi/dpt_i2o.c:156:32: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:954:42: warning: Using plain integer as NULL pointer drivers/scsi/ultrastor.c:1104:18: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
/linux-master/drivers/spi/ | ||
H A D | spi-dw-core.c | diff 8225c1c9 Sun Sep 20 05:28:47 MDT 2020 Serge Semin <Sergey.Semin@baikalelectronics.ru> spi: dw: Initialize n_bytes before the memory barrier Since n_bytes field of the DW SPI private data is also utilized by the IRQ handler, we need to make sure it' initialization is done before the memory barrier. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org> |
/linux-master/arch/powerpc/platforms/pseries/ | ||
H A D | eeh_pseries.c | diff 8225d543 Sat Jul 25 02:12:25 MDT 2020 Oliver O'Halloran <oohall@gmail.com> powerpc/eeh: Pass eeh_dev to eeh_ops->resume_notify() Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference a specific device rather than pci_dn. No functional changes. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200725081231.39076-8-oohall@gmail.com |
/linux-master/arch/powerpc/include/asm/ | ||
H A D | eeh.h | diff 8225d543 Sat Jul 25 02:12:25 MDT 2020 Oliver O'Halloran <oohall@gmail.com> powerpc/eeh: Pass eeh_dev to eeh_ops->resume_notify() Mechanical conversion of the eeh_ops interfaces to use eeh_dev to reference a specific device rather than pci_dn. No functional changes. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200725081231.39076-8-oohall@gmail.com |
/linux-master/kernel/ | ||
H A D | seccomp.c | diff 8225d385 Fri Nov 21 08:06:01 MST 2014 Pranith Kumar <bobby.prani@gmail.com> seccomp: Replace smp_read_barrier_depends() with lockless_dereference() Recently lockless_dereference() was added which can be used in place of hard-coding smp_read_barrier_depends(). The following PATCH makes the change. Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> |
/linux-master/tools/perf/util/ | ||
H A D | map.h | diff e7b60c5a Mon Oct 12 01:02:12 MDT 2020 Namhyung Kim <namhyung@kernel.org> perf inject: Do not load map/dso when injecting build-id No need to load symbols in a DSO when injecting build-id. I guess the reason was to check the DSO is a special file like anon files. Use some helper functions in map.c to check them before reading build-id. Also pass sample event's cpumode to a new build-id event. It brought a speedup in the benchmark of 25 -> 21 msec on my laptop. Also the memory usage (Max RSS) went down by ~200 KB. # Running 'internals/inject-build-id' benchmark: Average build-id injection took: 21.389 msec (+- 0.138 msec) Average time per event: 2.097 usec (+- 0.014 usec) Average memory usage: 8225 KB (+- 0 KB) Committer notes: Before: $ perf stat -r5 perf bench internals inject-build-id > /dev/null Performance counter stats for 'perf bench internals inject-build-id' (5 runs): 4,020.56 msec task-clock:u # 1.271 CPUs utilized ( +- 0.74% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 123,354 page-faults:u # 0.031 M/sec ( +- 0.81% ) 7,119,951,568 cycles:u # 1.771 GHz ( +- 1.74% ) (83.27%) 230,086,969 stalled-cycles-frontend:u # 3.23% frontend cycles idle ( +- 1.97% ) (83.41%) 1,168,298,765 stalled-cycles-backend:u # 16.41% backend cycles idle ( +- 1.13% ) (83.44%) 11,173,083,669 instructions:u # 1.57 insn per cycle # 0.10 stalled cycles per insn ( +- 1.58% ) (83.31%) 2,413,908,936 branches:u # 600.392 M/sec ( +- 1.69% ) (83.26%) 46,576,289 branch-misses:u # 1.93% of all branches ( +- 2.20% ) (83.31%) 3.1638 +- 0.0309 seconds time elapsed ( +- 0.98% ) $ After: $ perf stat -r5 perf bench internals inject-build-id > /dev/null Performance counter stats for 'perf bench internals inject-build-id' (5 runs): 2,379.94 msec task-clock:u # 1.473 CPUs utilized ( +- 0.18% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 62,584 page-faults:u # 0.026 M/sec ( +- 0.07% ) 2,372,389,668 cycles:u # 0.997 GHz ( +- 0.29% ) (83.14%) 106,937,862 stalled-cycles-frontend:u # 4.51% frontend cycles idle ( +- 4.89% ) (83.20%) 581,697,915 stalled-cycles-backend:u # 24.52% backend cycles idle ( +- 0.71% ) (83.47%) 3,659,692,199 instructions:u # 1.54 insn per cycle # 0.16 stalled cycles per insn ( +- 0.10% ) (83.63%) 791,372,961 branches:u # 332.518 M/sec ( +- 0.27% ) (83.39%) 10,648,083 branch-misses:u # 1.35% of all branches ( +- 0.22% ) (83.16%) 1.61570 +- 0.00172 seconds time elapsed ( +- 0.11% ) $ Signed-off-by: Namhyung Kim <namhyung@kernel.org> Original-patch-by: Stephane Eranian <eranian@google.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Link: https://lore.kernel.org/r/20201012070214.2074921-5-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
H A D | map.c | diff e7b60c5a Mon Oct 12 01:02:12 MDT 2020 Namhyung Kim <namhyung@kernel.org> perf inject: Do not load map/dso when injecting build-id No need to load symbols in a DSO when injecting build-id. I guess the reason was to check the DSO is a special file like anon files. Use some helper functions in map.c to check them before reading build-id. Also pass sample event's cpumode to a new build-id event. It brought a speedup in the benchmark of 25 -> 21 msec on my laptop. Also the memory usage (Max RSS) went down by ~200 KB. # Running 'internals/inject-build-id' benchmark: Average build-id injection took: 21.389 msec (+- 0.138 msec) Average time per event: 2.097 usec (+- 0.014 usec) Average memory usage: 8225 KB (+- 0 KB) Committer notes: Before: $ perf stat -r5 perf bench internals inject-build-id > /dev/null Performance counter stats for 'perf bench internals inject-build-id' (5 runs): 4,020.56 msec task-clock:u # 1.271 CPUs utilized ( +- 0.74% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 123,354 page-faults:u # 0.031 M/sec ( +- 0.81% ) 7,119,951,568 cycles:u # 1.771 GHz ( +- 1.74% ) (83.27%) 230,086,969 stalled-cycles-frontend:u # 3.23% frontend cycles idle ( +- 1.97% ) (83.41%) 1,168,298,765 stalled-cycles-backend:u # 16.41% backend cycles idle ( +- 1.13% ) (83.44%) 11,173,083,669 instructions:u # 1.57 insn per cycle # 0.10 stalled cycles per insn ( +- 1.58% ) (83.31%) 2,413,908,936 branches:u # 600.392 M/sec ( +- 1.69% ) (83.26%) 46,576,289 branch-misses:u # 1.93% of all branches ( +- 2.20% ) (83.31%) 3.1638 +- 0.0309 seconds time elapsed ( +- 0.98% ) $ After: $ perf stat -r5 perf bench internals inject-build-id > /dev/null Performance counter stats for 'perf bench internals inject-build-id' (5 runs): 2,379.94 msec task-clock:u # 1.473 CPUs utilized ( +- 0.18% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 62,584 page-faults:u # 0.026 M/sec ( +- 0.07% ) 2,372,389,668 cycles:u # 0.997 GHz ( +- 0.29% ) (83.14%) 106,937,862 stalled-cycles-frontend:u # 4.51% frontend cycles idle ( +- 4.89% ) (83.20%) 581,697,915 stalled-cycles-backend:u # 24.52% backend cycles idle ( +- 0.71% ) (83.47%) 3,659,692,199 instructions:u # 1.54 insn per cycle # 0.16 stalled cycles per insn ( +- 0.10% ) (83.63%) 791,372,961 branches:u # 332.518 M/sec ( +- 0.27% ) (83.39%) 10,648,083 branch-misses:u # 1.35% of all branches ( +- 0.22% ) (83.16%) 1.61570 +- 0.00172 seconds time elapsed ( +- 0.11% ) $ Signed-off-by: Namhyung Kim <namhyung@kernel.org> Original-patch-by: Stephane Eranian <eranian@google.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Link: https://lore.kernel.org/r/20201012070214.2074921-5-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
/linux-master/tools/perf/ | ||
H A D | builtin-inject.c | diff e7b60c5a Mon Oct 12 01:02:12 MDT 2020 Namhyung Kim <namhyung@kernel.org> perf inject: Do not load map/dso when injecting build-id No need to load symbols in a DSO when injecting build-id. I guess the reason was to check the DSO is a special file like anon files. Use some helper functions in map.c to check them before reading build-id. Also pass sample event's cpumode to a new build-id event. It brought a speedup in the benchmark of 25 -> 21 msec on my laptop. Also the memory usage (Max RSS) went down by ~200 KB. # Running 'internals/inject-build-id' benchmark: Average build-id injection took: 21.389 msec (+- 0.138 msec) Average time per event: 2.097 usec (+- 0.014 usec) Average memory usage: 8225 KB (+- 0 KB) Committer notes: Before: $ perf stat -r5 perf bench internals inject-build-id > /dev/null Performance counter stats for 'perf bench internals inject-build-id' (5 runs): 4,020.56 msec task-clock:u # 1.271 CPUs utilized ( +- 0.74% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 123,354 page-faults:u # 0.031 M/sec ( +- 0.81% ) 7,119,951,568 cycles:u # 1.771 GHz ( +- 1.74% ) (83.27%) 230,086,969 stalled-cycles-frontend:u # 3.23% frontend cycles idle ( +- 1.97% ) (83.41%) 1,168,298,765 stalled-cycles-backend:u # 16.41% backend cycles idle ( +- 1.13% ) (83.44%) 11,173,083,669 instructions:u # 1.57 insn per cycle # 0.10 stalled cycles per insn ( +- 1.58% ) (83.31%) 2,413,908,936 branches:u # 600.392 M/sec ( +- 1.69% ) (83.26%) 46,576,289 branch-misses:u # 1.93% of all branches ( +- 2.20% ) (83.31%) 3.1638 +- 0.0309 seconds time elapsed ( +- 0.98% ) $ After: $ perf stat -r5 perf bench internals inject-build-id > /dev/null Performance counter stats for 'perf bench internals inject-build-id' (5 runs): 2,379.94 msec task-clock:u # 1.473 CPUs utilized ( +- 0.18% ) 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 62,584 page-faults:u # 0.026 M/sec ( +- 0.07% ) 2,372,389,668 cycles:u # 0.997 GHz ( +- 0.29% ) (83.14%) 106,937,862 stalled-cycles-frontend:u # 4.51% frontend cycles idle ( +- 4.89% ) (83.20%) 581,697,915 stalled-cycles-backend:u # 24.52% backend cycles idle ( +- 0.71% ) (83.47%) 3,659,692,199 instructions:u # 1.54 insn per cycle # 0.16 stalled cycles per insn ( +- 0.10% ) (83.63%) 791,372,961 branches:u # 332.518 M/sec ( +- 0.27% ) (83.39%) 10,648,083 branch-misses:u # 1.35% of all branches ( +- 0.22% ) (83.16%) 1.61570 +- 0.00172 seconds time elapsed ( +- 0.11% ) $ Signed-off-by: Namhyung Kim <namhyung@kernel.org> Original-patch-by: Stephane Eranian <eranian@google.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Link: https://lore.kernel.org/r/20201012070214.2074921-5-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
/linux-master/net/ipv6/ | ||
H A D | route.c | diff 9e147a1c Thu Nov 17 17:52:51 MST 2005 David S. Miller <davem@sunset.davemloft.net> [IPV6]: Fib dump really needs GFP_ATOMIC. Revert: 8225ccbaf01b459cf1e462047a51b2851e756bc1 Based upon a report by Yan Zheng. Signed-off-by: David S. Miller <davem@davemloft.net> diff 8225ccba Sat Nov 12 01:15:16 MST 2005 Thomas Graf <tgraf@suug.ch> [IPV6]: Fix unnecessary GFP_ATOMIC allocation in fib6 dump Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net> |
Completed in 822 milliseconds