- 21 Dec, 2021 19 commits
-
-
Chunfeng Yun authored
In order to support nvmem bits property, should support minimum 1 byte read stride and minimum 1 byte read granularity at the same time. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211209174235.14049-4-srinivas.kandagatla@linaro.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Chunfeng Yun authored
Add compatible for mt8195 Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Chunfeng Yun authored
Add support bits property, will satisfy more consumers. Acked-by:
-
Minghao Chi authored
Return value from ocxl_context_attach() directly instead of taking this in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Acked-by:
Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20211215060438.441918-1-chi.minghao@zte.com.cnSigned-off-by:
-
Uladzislau Rezki (Sony) authored
Instead of invoking a synchronize_rcu() to free a pointer after a grace period we can directly make use of new API that does the same but in more efficient way. Signed-off-by:
Uladzislau Rezki (Sony) <urezki@gmail.com> Link: https://lore.kernel.org/r/20211215111845.2514-6-urezki@gmail.comSigned-off-by:
-
Greg Kroah-Hartman authored
MIPS include files define "PC" so when building the paride driver the following build warning shows up: rivers/block/paride/bpck.c:32: warning: "PC" redefined Fix this by undefining PC before redefining it as is done for other defines in this driver. Cc: Tim Waugh <tim@cyberelk.net> Acked-by:
Jens Axboe <axboe@kernel.dk> Link: https://lore.kernel.org/r/20211130084626.3215987-1-gregkh@linuxfoundation.orgSigned-off-by:
-
Tiezhu Yang authored
According to https://rapidio.org/vendor-id/, there is no 0x000d vendor id in the complete and current list of VendorIDs, it means that the related code is dead code now, so just remove them. Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Link: https://lore.kernel.org/r/1639625581-22867-3-git-send-email-yangtiezhu@loongson.cnSigned-off-by:
-
Tiezhu Yang authored
The definition of RIO_VID_FREESCALE, RIO_DID_MPC8560, RIO_DID_TSI500, RIO_DID_TSI576 and RIO_DID_TSI721 are not used for many years in the current code, so just remove them. Signed-off-by:
-
Johan Hovold authored
Explicitly remove the file entries from sysfs before dropping the final reference for symmetry reasons and for consistency with the rest of the driver. Signed-off-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20211201132528.30025-5-johan@kernel.orgSigned-off-by:
-
Johan Hovold authored
Make sure to always NUL-terminate file names retrieved from the firmware to avoid accessing data beyond the entry slab buffer and exposing it through sysfs in case the firmware data is corrupt. Fixes: 75f3e8e4 ("firmware: introduce sysfs driver for QEMU's fw_cfg device") Cc: stable@vger.kernel.org # 4.6 Cc: Gabriel Somlo <somlo@cmu.edu> Signed-off-by:
-
Johan Hovold authored
An initialised kobject must be freed using kobject_put() to avoid leaking associated resources (e.g. the object name). Commit fe3c6068 ("firmware: Fix a reference count leak.") "fixed" the leak in the first error path of the file registration helper but left the second one unchanged. This "fix" would however result in a NULL pointer dereference due to the release function also removing the never added entry from the fw_cfg_entry_cache list. This has now been addressed. Fix the remaining kobject leak by restoring the common error path and adding the missing kobject_put(). Fixes: 75f3e8e4 ("firmware: introduce sysfs driver for QEMU's fw_cfg device") Cc: stable@vger.kernel.org # 4.6 Cc: Gabriel Somlo <somlo@cmu.edu> Signed-off-by:
-
Johan Hovold authored
Commit fe3c6068 ("firmware: Fix a reference count leak.") "fixed" a kobject leak in the file registration helper by properly calling kobject_put() for the entry in case registration of the object fails (e.g. due to a name collision). This would however result in a NULL pointer dereference when the release function tries to remove the never added entry from the fw_cfg_entry_cache list. Fix this by moving the list-removal out of the release function. Note that the offending commit was one of the benign looking umn.edu fixes which was reviewed but not reverted. [1][2] [1] https://lore.kernel.org/r/202105051005.49BFABCE@keescook [2] https://lore.kernel.org/all/YIg7ZOZvS3a8LjSv@kroah.com Fixes: fe3c6068 ("firmware: Fix a reference count leak.") Cc: stable@vger.kernel.org # 5.8 Cc: Qiushi Wu <wu000273@umn.edu> Cc: Kees Cook <keescook@chromium.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jason Wang authored
Static variables do not need to be initialised to 0, because compilers will initialise all uninitialised statics to 0. Thus, remove the unneeded initializations. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Link: https://lore.kernel.org/r/20211212071838.304307-1-wangborong@cdjrlc.comSigned-off-by:
-
Kai Ye authored
Use the sysfs_emit to replace sprintf. sprintf may cause output defect in sysfs content, it is better to use new added sysfs_emit function which knows the size of the temporary buffer. Signed-off-by:
Kai Ye <yekai13@huawei.com> Link: https://lore.kernel.org/r/20211206104724.11559-1-yekai13@huawei.comSigned-off-by:
-
Jason Wang authored
The double `for' in the comment in line 81 is repeated. Remove one of them from the comment. Reviewed-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Ben Hutchings authored
The help text for GOOGLE_FIRMWARE states that it should only be enabled when building a kernel for Google's own servers. However, many of the drivers dependent on it are also useful on Chromebooks or on any platform using coreboot. Update the help text to reflect this double duty. Fixes: d384d6f4 ("firmware: google memconsole: Add coreboot support") Reviewed-by:
Julius Werner <jwerner@chromium.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Link: https://lore.kernel.org/r/20180618225540.GD14131@decadent.org.ukSigned-off-by:
-
Ajith P V authored
binder.c uses <asm/cacheflush.h> instead of <linux/cacheflush.h>. Hence change cacheflush header file to proper one. This change also avoid warning from checkpatch that shown below: WARNING: Use #include <linux/cacheflush.h> instead of <asm/cacheflush.h> Signed-off-by:
Ajith P V <ajithpv.linux@gmail.com> Link: https://lore.kernel.org/r/20211215132018.31522-1-ajithpv.linux@gmail.comSigned-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'coresight-next-v5.17' of gitolite.kernel.org:pub/scm/linux/kernel/git/coresight/linux into char-misc-next Mathieu writes: Coresight changes for v5.17 This pull request includes: - A patch that uses devm_bitmap_zalloc() instead of the open-coded equivalent. - Work to make coresight complex configuration loadable via modules. - Some coresight documentation updates. Signed-off-by:Mathieu Poirier <mathieu.poirier@linaro.org> * tag 'coresight-next-v5.17' of gitolite.kernel.org:pub/scm/linux/kernel/git/coresight/linux: coresight: core: Fix typo in a comment Documentation: coresight: Update coresight configuration docs coresight: configfs: Allow configfs to activate configuration coresight: syscfg: Example CoreSight configuration loadable module coresight: syscfg: Update load API for config loadable modules coresight: configuration: Update API to permit dynamic load/unload coresight: configuration: Update API to introduce load owner concept Documentation: coresight: Fix documentation issue coresight: Use devm_bitmap_zalloc when applicable
-
Greg Kroah-Hartman authored
Merge tag 'fpga-for-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux-fpga into char-misc-next Moritz writes: FPGA Manager changes for 5.17-rc1 Russ' patches rework the way we register FPGA managers, regions and bridges by simplifying the functions into a single register call. Nathan's patch addresses an unused variable warning that was introduced by Russ' patches. Yang's patch addresses a kernel doc warning. All patches have been reviewed on the mailing list, and have been in the last few linux-next releases (as part of our for-next branch) without issues. Signed-off-by:
Moritz Fischer <mdf@kernel.org> * tag 'fpga-for-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux-fpga: fpga: region: fix kernel-doc fpga: stratix10-soc: Do not use ret uninitialized in s10_probe() fpga: region: Use standard dev_release for class driver fpga: bridge: Use standard dev_release for class driver fpga: mgr: Use standard dev_release for class driver
-
- 17 Dec, 2021 17 commits
-
-
David Collins authored
The qpnpint_irq_set_type() callback function configures the type (edge vs level) and polarity (high, low, or both) of a particular PMIC interrupt within a given peripheral. To do this, it reads the three consecutive IRQ configuration registers, modifies the specified IRQ bit within the register values, and finally writes the three modified register values back to the PMIC. While a spinlock is used to provide mutual exclusion on the SPMI bus during the register read and write calls, there is no locking around the overall read, modify, write sequence. This opens up the possibility of a race condition if two tasks set the type of a PMIC IRQ within the same peripheral simultaneously. When the race condition is encountered, both tasks will read the old value of the registers and IRQ bits set by one of the tasks will be dropped upon the register write of the other task. This then leads to PMIC IRQs being enabled with an incorrect type and polarity configured. Such misconfiguration can lead to an IRQ storm that overwhelms the system and causes it to crash. This race condition and IRQ storm have been observed when using a pair of pm8941-pwrkey devices to handle PMK8350 pwrkey and resin interrupts. The independent devices probe asynchronously in parallel and can simultaneously request and configure PMIC IRQs in the same PMIC peripheral. For a good case, the IRQ configuration calls end up serialized due to timing deltas and the register read/write sequence looks like this: 1. pwrkey probe: SPMI read(0x1311): 0x00, 0x00, 0x00 2. pwrkey probe: SPMI write(0x1311): 0x80, 0x80, 0x80 3. resin probe: SPMI read(0x1311): 0x80, 0x80, 0x80 4. resin probe: SPMI write(0x1311): 0xC0, 0xC0, 0xC0 The final register states after both devices have requested and enabled their respective IRQs is thus: 0x1311: 0xC0 0x1312: 0xC0 0x1313: 0xC0 0x1314: 0x00 0x1315: 0xC0 For a bad case, the IRQ configuration calls end up occurring simultaneously and the race condition is encountered. The register read/write sequence then looks like this: 1. pwrkey probe: SPMI read(0x1311): 0x00, 0x00, 0x00 2. resin probe: SPMI read(0x1311): 0x00, 0x00, 0x00 3. pwrkey probe: SPMI write(0x1311): 0x80, 0x80, 0x80 4. resin probe: SPMI write(0x1311): 0x40, 0x40, 0x40 In this case, the final register states after both devices have requested and enabled their respective IRQs is thus: 0x1311: 0x40 0x1312: 0x40 0x1313: 0x40 0x1314: 0x00 0x1315: 0xC0 This corresponds to the resin IRQ being configured for both rising and falling edges, as expected. However, the pwrkey IRQ is misconfigured as level type with both polarity high and low set to disabled. The PMIC IRQ triggering hardware treats this particular register configuration as if level low triggering is enabled. The raw pwrkey IRQ signal is low when the power key is not being pressed. Thus, the pwrkey IRQ begins firing continuously in an IRQ storm. Fix the race condition by holding the spmi-pmic-arb spinlock for the duration of the read, modify, write sequence performed in the qpnpint_irq_set_type() function. Split the pmic_arb_read_cmd() and pmic_arb_write_cmd() functions each into three parts so that hardware register IO is decoupled from spinlock locking. This allows a new function pmic_arb_masked_write() to be added which locks the spinlock and then calls register IO functions to perform SPMI read and write commands in a single atomic operation. Link: https://lore.kernel.org/r/20211118034719.28971-1-quic_collinsd@quicinc.comSigned-off-by:
David Collins <quic_collinsd@quicinc.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20211216190812.1574801-7-sboyd@kernel.orgSigned-off-by:
-
James Lo authored
Add spmi support for MT8195. Refine indent in spmi-mtk-pmif.c. Link: https://lore.kernel.org/r/20211119034613.32489-5-james.lo@mediatek.comAcked-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
James Lo <james.lo@mediatek.com> Signed-off-by:
Henry Chen <henryc.chen@mediatek.com> Signed-off-by:
Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Signed-off-by:
-
James Lo authored
Add spmi support for MT6873/8192. Refine indent in spmi-mtk-pmif.c. Link: https://lore.kernel.org/r/20211119034613.32489-4-james.lo@mediatek.comAcked-by:
-
James Lo authored
This adds documentation for the SPMI controller found on Mediatek SoCs. Link: https://lore.kernel.org/r/20211119034613.32489-3-james.lo@mediatek.comReviewed-by:
-
James Lo authored
'reg' is controller specific so we shouldn't even be specifying it here. Just remove it. Link: https://lore.kernel.org/r/20211119034613.32489-2-james.lo@mediatek.comReviewed-by:
-
Stephen Boyd authored
It's useful to know what particular device/component is having trouble accessing the bus. Add the sid and address to error messages here so that debugging is a little simpler. Link: https://lore.kernel.org/r/20210920234849.3614036-1-swboyd@chromium.org Cc: Subbaraman Narayanamurthy <subbaram@codeaurora.org> Cc: satya priya <skakit@codeaurora.org> Reviewed-by:
Subbaraman Narayanamurthy <subbaram@codeaurora.org> Reviewed-by:
Satya Priya <skakit@codeaurora.org> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
Thomas Perrot authored
Add support for EM919X modems, this modem series is based on SDX55 qcom chip. It is mandatory to use the same ring for control+data and diag events. Link: https://lore.kernel.org/r/20211123081541.648426-1-thomas.perrot@bootlin.comTested-by:
Aleksander Morgado <aleksander@aleksander.es> Reviewed-by:
Manivannan Sadhasivam <mani@kernel.org> Signed-off-by:
Thomas Perrot <thomas.perrot@bootlin.com> Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20211216081227.237749-11-manivannan.sadhasivam@linaro.orgSigned-off-by:
-
Kees Cook authored
The find.h APIs are designed to be used only on unsigned long arguments. This can technically result in a over-read, but it is harmless in this case. Regardless, fix it to avoid the warning seen under -Warray-bounds, which we'd like to enable globally: In file included from ./include/linux/bitmap.h:9, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/cpumask.h:5, from ./arch/x86/include/asm/msr.h:11, from ./arch/x86/include/asm/processor.h:22, from ./arch/x86/include/asm/cpufeature.h:5, from ./arch/x86/include/asm/thread_info.h:53, from ./include/linux/thread_info.h:60, from ./arch/x86/include/asm/preempt.h:7, from ./include/linux/preempt.h:78, from ./include/linux/spinlock.h:55, from ./include/linux/wait.h:9, from ./include/linux/wait_bit.h:8, from ./include/linux/fs.h:6, from ./include/linux/debugfs.h:15, from drivers/bus/mhi/core/init.c:7: drivers/bus/mhi/core/init.c: In function 'to_mhi_pm_state_str': ./include/linux/find.h:187:37: warning: array subscript 'long unsigned int[0]' is partly outside array bounds of 'enum mhi_pm_state[1]' [-Warray-bounds] 187 | unsigned long val = *addr & GENMASK(size - 1, 0); | ^~~~~ drivers/bus/mhi/core/init.c:80:51: note: while referencing 'state' 80 | const char *to_mhi_pm_state_str(enum mhi_pm_state state) | ~~~~~~~~~~~~~~~~~~^~~~~ Link: https://lore.kernel.org/r/20211215232446.2069794-1-keescook@chromium.org [mani: changed the variable name "bits" to "pm_state"] Reviewed-by:Kees Cook <keescook@chromium.org> Signed-off-by:
-
Manivannan Sadhasivam authored
Add a new API "mhi_prepare_for_transfer_autoqueue" for using with client drivers like QRTR to request MHI core to autoqueue buffers for the DL channel along with starting both UL and DL channels. So far, the "auto_queue" flag specified by the controller drivers in channel definition served this purpose but this will be removed at some point in future. Cc: netdev@vger.kernel.org Cc: Jakub Kicinski <kuba@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Co-developed-by:
Loic Poulain <loic.poulain@linaro.org> Acked-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Manivannan Sadhasivam authored
During SYS_ERR condition, as a response to the MHI_RESET from host, some devices tend to issue BHI interrupt without clearing the SYS_ERR state in the device. This creates a race condition and causes a failure in booting up the device. The issue is seen on the Sierra Wireless EM9191 modem during SYS_ERR handling in mhi_async_power_up(). Once the host detects that the device is in SYS_ERR state, it issues MHI_RESET and waits for the device to process the reset request. During this time, the device triggers the BHI interrupt to the host without clearing SYS_ERR condition. So the host starts handling the SYS_ERR condition again. To fix this issue, let's register the IRQ handler only after handling the SYS_ERR check to avoid getting spurious IRQs from the device. Fixes: e18d4e9f ("bus: mhi: core: Handle syserr during power_up") Cc: stable@vger.kernel.org Reported-by:
-
Bhaumik Bhatt authored
The 'wake-capable' entry in channel configuration is not set when parsing the configuration specified by the controller driver. Add the missing entry to ensure channel is correctly specified as a 'wake-capable' channel. Link: https://lore.kernel.org/r/1638320491-13382-1-git-send-email-quic_bbhatt@quicinc.com Fixes: 0cbf2608 ("bus: mhi: core: Add support for registering MHI controllers") Cc: stable@vger.kernel.org Reviewed-by:
Bhaumik Bhatt <quic_bbhatt@quicinc.com> Signed-off-by:
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. Replace 'pci_set_dma_mask/pci_set_consistent_dma_mask' by an equivalent and less verbose 'dma_set_mask_and_coherent()' call. Link: https://lore.kernel.org/r/bb3dc436fe142309a2334549db782c5ebb80a2be.1625718497.git.christophe.jaillet@wanadoo.frReviewed-by:
Hemant Kumar <hemantk@codeaurora.org> Reviewed-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Manivannan Sadhasivam authored
This patch fixes the below checkpatch warnings in MHI bus: WARNING: Possible repeated word: 'events' + /* Process ctrl events events */ WARNING: Missing a blank line after declarations + struct mhi_buf_info info = { }; + buf = kmalloc(len, GFP_KERNEL); WARNING: Move const after static - use 'static const struct mhi_pm_transitions' +static struct mhi_pm_transitions const dev_state_transitions[] = { Signed-off-by: -
Bhaumik Bhatt authored
The implementation for execution environment specific functionality is spread out. Use macros that help determine the paths to be taken. Link: https://lore.kernel.org/r/1636409978-31847-1-git-send-email-quic_bbhatt@quicinc.comReviewed-by:
Bhaumik Bhatt <bbhatt@codeaurora.org> Signed-off-by:
-
Loic Poulain authored
There is no reason for shutting down MHI ungracefully on freeze, this causes the MHI host stack & device stack to not be aligned anymore since the proper MHI reset sequence is not performed for ungraceful shutdown. Link: https://lore.kernel.org/r/1635268180-13699-1-git-send-email-loic.poulain@linaro.org Fixes: 5f0c2ee1 ("bus: mhi: pci-generic: Fix hibernation") Cc: stable@vger.kernel.org Suggested-by:
-
Slark Xiao authored
Add new device ID 0xe0bf for T99W175. This device ID is created because it is using Qualcomm SDX55 new base line. Test evidence as below: root@jbd-ThinkPad-P1-Gen-4:/dev# lspci -nn | grep Foxconn 0000:08:00.0 Wireless controller [0d40]: Foxconn International, Inc. Device [105b:e0bf] root@jbd-ThinkPad-P1-Gen-4:/dev# cat wwan0at0 & echo -ne "ati\r" > wwan0at0 [2] 2977 root@jbd-ThinkPad-P1-Gen-4:/dev# ati Manufacturer: Qualcomm Model: T99W175 Revision: T99W175.F0.6.0.0.6.CC.005 1 [Oct 21 2021 10:00:00] IMEI: +GCAP: +CGSM OK Link: https://lore.kernel.org/r/20211029104918.3976-1-slark_xiao@163.comReviewed-by:
Slark Xiao <slark_xiao@163.com> Signed-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'lkdtm-v5.17-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into char-misc-next Kees writes: lkdtm updates for v5.17-rc1 - Fix printk() usage during recursion (Ard Biesheuvel) - Fix rodata section to actually have contents (Christophe Leroy) - Add notes about lkdtm_kernel_info usage (Kees Cook) - Avoid stack-entropy selftest when LKDTM is disabled (Misono Tomohiro) * tag 'lkdtm-v5.17-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: selftest/lkdtm: Skip stack-entropy test if lkdtm is not available lkdtm: Fix content of section containing lkdtm_rodata_do_nothing() lkdtm: avoid printk() in recursive_loop() lkdtm: Note that lkdtm_kernel_info should be removed in the future
-
- 16 Dec, 2021 4 commits
-
-
Misono Tomohiro authored
Exit with return code 4 if lkdtm is not available like other tests in order to properly skip the test. Signed-off-by:
Misono Tomohiro <misono.tomohiro@jp.fujitsu.com> Signed-off-by:
-
Christophe Leroy authored
On a kernel without CONFIG_STRICT_KERNEL_RWX, running EXEC_RODATA test leads to "Illegal instruction" failure. Looking at the content of rodata_objcopy.o, we see that the function content zeroes only: Disassembly of section .rodata: 0000000000000000 <.lkdtm_rodata_do_nothing>: 0: 00 00 00 00 .long 0x0 Add the contents flag in order to keep the content of the section while renaming it. Disassembly of section .rodata: 0000000000000000 <.lkdtm_rodata_do_nothing>: 0: 4e 80 00 20 blr Fixes: e9e08a07 ("lkdtm: support llvm-objcopy") Cc: stable@vger.kernel.org Cc: Kees Cook <keescook@chromium.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Ard Biesheuvel authored
The recursive_loop() function is intended as a diagnostic to ensure that exhausting the stack is caught and mitigated. Currently, it uses pr_info() to ensure that the function has side effects that the compiler cannot simply optimize away, so that the stack footprint does not get reduced inadvertently. The typical mitigation for stack overflow is to kill the task, and this overflow may occur inside the call to pr_info(), which means it could be holding the console lock when this happens. This means that the console lock is never going to be released again, preventing the diagnostic prints related to the stack overflow handling from being visible on the console. So let's replace the call to pr_info() with a call to memzero_explicit(), which is not a 'magic' function name like memset() or memcpy(), which the compiler may replace with plain loads and stores. To ensure that the stack frames are nested rather than tail-called, put the call to memzero_explicit() after the recursive call. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
-
Kees Cook authored
As per Linus's request, remove lkdtm_kernel_info once sufficient reporting exists in CI systems: https://lore.kernel.org/lkml/CAHk-=wiFvfkoFixTapvvyPMN9pq5G-+Dys2eSyBa1vzDGAO5+A@mail.gmail.com Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
