Re: [linux-yocto][linux-yocto v5.10/standard/ti-sdk-5.4/ti-j72xx][PATCH] crypto: add timeout to crypto_wait_req
In message: [linux-yocto][linux-yocto
v5.10/standard/ti-sdk-5.4/ti-j72xx][PATCH] crypto: add timeout to
crypto_wait_req
on 06/05/2021 Xulin Sun wrote:
> From: Tero Kristo
>
> commit 0ecd89ec64116669bcf7f7feae03a110cc2ad30c from
> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
>
> Currently crypto_wait_req waits indefinitely for an async crypto request
> to complete. This is bad as it can cause for example the crypto test
> manager to hang without any notification as to why it has happened.
> Instead of waiting indefinitely, add a 1 second timeout to the call,
> and provide a warning print if a timeout happens.
merged.
Bruce
>
> Signed-off-by: Tero Kristo
> Signed-off-by: Xulin Sun
> ---
> include/linux/crypto.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index 27576da1112e..f769adf9edd5 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -593,7 +593,6 @@ static inline int crypto_wait_req(int err, struct
> crypto_wait *wait)
> switch (err) {
> case -EINPROGRESS:
> case -EBUSY:
> - wait_for_completion(>completion);
> err = wait_for_completion_timeout(>completion,
> msecs_to_jiffies(1000));
> reinit_completion(>completion);
> --
> 2.17.1
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9845):
https://lists.yoctoproject.org/g/linux-yocto/message/9845
Mute This Topic: https://lists.yoctoproject.org/mt/82625266/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [PATCH v5.10] net/dccp: make it depend on CONFIG_BROKEN (CVE-2020-16119)
In message: [PATCH v5.10] net/dccp: make it depend on CONFIG_BROKEN (CVE-2020-16119) on 05/05/2021 Paul Gortmaker wrote: > There were some proposed fixes for this back in 2020, but the discussion > largely fizzled out[1] and never got picked up again. > > We can see other distros are either blacklisting it from user space[2] > or explicitly calling it out as "is not set" in their base config[3] but > that really doesn't bind the workaround to the kernel source in any > robust transportable way. > > So I've done the tried and true "depends on BROKEN" to ensure the > workaround goes wherever the kernel source goes. > > We can revert this if a real fix eventually appears, but given that it > was marked "EXPERIMENTAL" back when we had that, I don't expect we'll > need to. Also note that none of our base ktypes or BSPs enabled it. Sounds good to me. This is now merged and pushed to all the 5.10 branches, and queued for the next kernel that is generated. Bruce > > [1] > https://lore.kernel.org/netdev/20201013171849.236025-1-kleber.so...@canonical.com/T/ > [2] https://access.redhat.com/security/cve/cve-2020-16119 > [3] > https://github.com/archlinux/svntogit-packages/commit/c07751100e1d64d9aa5789881ddc2ef68e43aed4 > > Signed-off-by: Paul Gortmaker > > diff --git a/net/dccp/Kconfig b/net/dccp/Kconfig > index 0c7d2f66ba27..efa01566da0f 100644 > --- a/net/dccp/Kconfig > +++ b/net/dccp/Kconfig > @@ -2,6 +2,7 @@ > menuconfig IP_DCCP > tristate "The DCCP Protocol" > depends on INET > + depends on BROKEN > help > Datagram Congestion Control Protocol (RFC 4340) > > -- > 2.25.1 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9844): https://lists.yoctoproject.org/g/linux-yocto/message/9844 Mute This Topic: https://lists.yoctoproject.org/mt/82597190/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [kernel v5.10/standard/nxp-sdk-5.4/nxp-imx8][PATCH] arm64: dts: imx8: Move usb3_lpcg to IMX_SC_R_USB_2 domain
Because the usb3_aclk device is created during the probe of clk-imx8qxp driver,
but the usb3_lpcg is added to the dpm_list in the parsing of dtb.
Therefore, the usb3_aclk enters the suspend first when the system is suspended.
Since the usb3_lpcg depends on the usb3_aclk, when the usb3_lpcg enters the
suspend When the register cannot be accessed normally, the following calltrace
appears:
Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 409 Comm: sh Not tainted 5.10.25-yocto-standard #1
Hardware name: Freescale i.MX8QM MEK (DT)
pstate: 2005 (nzCv daif -PAN -UAO -TCO BTYPE=--)
pc : imx_clk_lpcg_scu_suspend+0x44/0x60
lr : imx_clk_lpcg_scu_suspend+0x3c/0x60
sp : 8000133bba30
x29: 8000133bba30 x28: 0002
x27: 80001088fac4 x26: 8000119b1200
x25: 8000117da49c x24: 800011926400
x23: 800011a8cf60 x22:
x21: 000810b71410 x20: 000810b71410
x19: 000810ef0680 x18: 0020
x17: x16:
x15: 0f130d005a0f171d x14: 7573206f7265
x13: x12: 0003
x11: 0101010101010101 x10: 0930
x9 : 7f7f7f7f7f7f7f7f x8 : 626f6b5e686c6367
x7 : 1d170f5a000d130f x6 : 0f130d005a0f171d
x5 : x4 : ab9b119afb0b1b60
x3 : 0043 x2 : 0009
x1 : 000810ef0708 x0 : 800012f8
Call trace:
imx_clk_lpcg_scu_suspend+0x44/0x60
pm_generic_suspend_noirq+0x38/0x50
genpd_finish_suspend+0xb8/0x150
genpd_suspend_noirq+0x20/0x30
dpm_run_callback+0x50/0x1c0
__device_suspend_noirq+0xec/0x244
dpm_noirq_suspend_devices+0x11c/0x320
dpm_suspend_noirq+0x30/0xa4
suspend_devices_and_enter+0x3b0/0x8a0
pm_suspend+0x288/0x330
state_store+0x98/0x120
kobj_attr_store+0x1c/0x30
sysfs_kf_write+0x50/0x60
kernfs_fop_write_iter+0x124/0x1b4
new_sync_write+0xf4/0x190
vfs_write+0x21c/0x280
ksys_write+0x78/0x104
__arm64_sys_write+0x28/0x3c
el0_svc_common.constprop.0+0x9c/0x1f0
do_el0_svc+0x78/0xa0
el0_svc+0x20/0x30
el0_sync_handler+0x1a4/0x1b0
el0_sync+0x174/0x180
Code: d2800122 97fd4d7a 3480 f9400e60 (b940)
---[ end trace 22db9b04ad434a5d ]---
In order fix this issue, moving the usb3_lpcg to the same power domain as
usb3_aclk,
so that we can make sure that the power is not off when the usb3_lpcg is
suspending.
Signed-off-by: Xiaolei Wang
---
arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
b/arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
index 4eb51cad186d..f83a30a138ee 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
@@ -330,7 +330,7 @@ usb3_lpcg: clock-controller@5b28 {
"usb3_core_pclk",
"usb3_phy_clk",
"usb3_aclk";
- power-domains = < IMX_SC_R_USB_2_PHY>;
+ power-domains = < IMX_SC_R_USB_2>;
};
rawnand_0_lpcg: clock-controller@5b29 {
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9843):
https://lists.yoctoproject.org/g/linux-yocto/message/9843
Mute This Topic: https://lists.yoctoproject.org/mt/82646848/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] QA notification for completed autobuilder build (yocto-3.2.4.rc1)
A build flagged for QA (yocto-3.2.4.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.2.4.rc1 Build hash information: bitbake: e05d79a6ed92c9ce17b90fd5fb6186898a7b3bf8 meta-arm: 39bc4076b2d9a662111beaa0621ee9c1e37f56ea meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43 meta-intel: c325d3e2eab9952dc175a38f31b78fecdcdd0fcc meta-kernel: 4b288396eff43fe9b1a233aed1ce9b48329a2eb6 meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879 oecore: d47b7cdc3508343349f3bb3eacb2dc3227dd94d2 poky: 60c8482769f38a4db6f38d525405c887794511a9 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53413): https://lists.yoctoproject.org/g/yocto/message/53413 Mute This Topic: https://lists.yoctoproject.org/mt/82633746/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #yocto cmake configurations
Thanks… I forgot that… linked. I appreciate the help. Steve From: Khem Raj Sent: Wednesday, May 5, 2021 5:06 PM To: Monsees, Steven C (US) Cc: yocto@lists.yoctoproject.org Subject: Re: [yocto] #yocto cmake configurations External Email Alert This email has been sent from an account outside of the BAE Systems network. Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar. usually one uses llvm-config to get the libs and order is important too especially with static libs. Can you dump all .a files from clang and see if its defined in some other .a which is either missing or present after the faulting .a in linker cmd On Wed, May 5, 2021 at 12:53 PM Monsees, Steven C (US) mailto:steven.mons...@baesystems.com>> wrote: I made some modification in the cmake modules to adjust for the linker issue below, but now I appear to have uncovered an issue with the static libraries which meta-clang generated under the SDK… (see below)… The link command is attached as “tmp.txt”. There are a lot of these being generated, this is but a subset… Note: (1) “workspace_3” is a reference to my build area where I built the STD SDK, why would this be here the SDK should be independent of this are, no ? (2) the code with the undefined reference does appear to be missing the proper header file reference /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `CodeGenModule': /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:114: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const' /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:116: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const' /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:118: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const' /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr() const': /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const' /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::checkAliases()': /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:304: undefined reference to `clang::Decl::getDefiningAttr() const' /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::SectionAttr* clang::Decl::getAttr() const': /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539: undefined reference to `clang::Decl::getAttrs() const' /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr() const': /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined
[yocto] Next Yocto Project LTS - April 2022
I'm pleased to be able to announce that the project is planning to have the April 2022 release next year be our next LTS release. This fits in with our original announced plan of 2 year cycles and recognises that the LTS has been well received by members and our community. It also aligns well with LTS releases of other projects meaning we have "co-travellers". The current dunfell LTS would be due to end at that time. There has been discussion about extending it beyond the currently planned timeframe but no agreement/decision has been made on the extra finance that would require at this time. There is also some concern about the potential pressure on layer maintainers in wider ecosystem which we plan to investigate further. By confirming this now, we're hoping to give people a chance to align strategies and plan for feature development to land into the LTS. There is a clear need for any new/experimental changes to be planned/developed now in order to ensure they're ready and stabilised for the LTS. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53411): https://lists.yoctoproject.org/g/yocto/message/53411 Mute This Topic: https://lists.yoctoproject.org/mt/82627563/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH] config.json: Remove -j option for reproducibility as live output is useful
The -j option has the side effect that the output is cached. For a long running
single threaded target, the live output is more useful so switch to it.
Signed-off-by: Richard Purdie
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.json b/config.json
index 3e12d3f..6533dab 100644
--- a/config.json
+++ b/config.json
@@ -191,7 +191,7 @@
"SDKMACHINE" : "x86_64",
"step1" : {
"shortname" : "Reproducible Selftest",
-"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1
oe-selftest -r reproducible -j 1"],
+"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1
oe-selftest -r reproducible"],
"ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
}
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53410): https://lists.yoctoproject.org/g/yocto/message/53410
Mute This Topic: https://lists.yoctoproject.org/mt/82627420/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] KeyError: 'getpwuid(): uid not found: 1000' in do_package phase
On Thu, May 6, 2021 at 10:57 AM Thomas Hill via lists.yoctoproject.org wrote: > Hi Martin! > > On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote: > > > https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442 > > is an example where it triggers this error, but doesn't trigger the more > common host-user-contaminated QA error (unless you happened to use UID 1001 > on host for the user running bitbake). > > I have here a similar problem with one of my own packages. It happens that > my bitbake user uses UID 1001. Do you have more information why this is a > problem? Should it be enough to change the UID to 1002 to get everything > running? > No, you should chown the files to be owned by the expected user which exists in the image (probably root like in my commit). Changing the UID of the user on host is very bad work around (as it will fail for the next person building the same image with host user 1001. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53409): https://lists.yoctoproject.org/g/yocto/message/53409 Mute This Topic: https://lists.yoctoproject.org/mt/78301741/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Hardknott - pseudo excluded from intercept_scripts
On Wed, 2021-05-05 at 00:56 -0700, Chuck Wolber wrote:
> The following code is an effective workaround. It must be added after the
> core-image is inherited.
>
> python () {
> pseudo_ignore_paths = d.getVar('PSEUDO_IGNORE_PATHS')
> result = ','.join([x for x in pseudo_ignore_paths.split(',') if
> "intercept_scripts" not in x])
> d.setVar('PSEUDO_IGNORE_PATHS', result)
> }
>
> ..Ch:W..
>
> On Tue, May 4, 2021 at 8:53 PM Chuck Wolber via lists.yoctoproject.org <
> chuckwolber=gmail@lists.yoctoproject.org> wrote:
> >
> > I was attempting an image build with Yocto Hardknott, and I ran into a
> > chown problem during do_rootfs(). I
> > traced it down to ${WORKDIR}/intercept_scripts showing up in the
> > PSEUDO_IGNORE_PATHS environment variable.
> >
> > This commit made the change:
> > https://git.openembedded.org/openembedded-core/commit/meta/classes/image.bbclass?id=9463be2292b942a1072eea1b9644e55aadb9
> >
> > I continued down the rabbit hole until I got here:
> > https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/__init__.py#n173
> >
> > Line 192 specifically is the smoking gun. The files are being copied from
> > poky/scripts/postinst-intercepts
> > into the ${WORKDIR}/intercept_scripts directory and immediately failing
> > when the copyFile utility attempts
> > to do a chown.
> >
> > Is there any logical explanation for this? Is this a bug or am I doing
> > something wrong? Is there a
> > workaround?
This should be fixed in master, the issue was triggered by a checkout
owned by root/root:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=eff192abe2ee43ebf981bafbb7fca8602ebdcf0c
Steve/Anuj: We'll likely want to backport that one.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53408): https://lists.yoctoproject.org/g/yocto/message/53408
Mute This Topic: https://lists.yoctoproject.org/mt/82596907/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] KeyError: 'getpwuid(): uid not found: 1000' in do_package phase
Hi Martin! On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote: > > https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442 > > > is an example where it triggers this error, but doesn't trigger the more > common host-user-contaminated QA error (unless you happened to use UID > 1001 on host for the user running bitbake). > I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running? Thanks! Tom -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53407): https://lists.yoctoproject.org/g/yocto/message/53407 Mute This Topic: https://lists.yoctoproject.org/mt/78301741/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v5.10/standard/ti-sdk-5.4/ti-j72xx][PATCH] crypto: add timeout to crypto_wait_req
From: Tero Kristo
commit 0ecd89ec64116669bcf7f7feae03a110cc2ad30c from
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
Currently crypto_wait_req waits indefinitely for an async crypto request
to complete. This is bad as it can cause for example the crypto test
manager to hang without any notification as to why it has happened.
Instead of waiting indefinitely, add a 1 second timeout to the call,
and provide a warning print if a timeout happens.
Signed-off-by: Tero Kristo
Signed-off-by: Xulin Sun
---
include/linux/crypto.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 27576da1112e..f769adf9edd5 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -593,7 +593,6 @@ static inline int crypto_wait_req(int err, struct
crypto_wait *wait)
switch (err) {
case -EINPROGRESS:
case -EBUSY:
- wait_for_completion(>completion);
err = wait_for_completion_timeout(>completion,
msecs_to_jiffies(1000));
reinit_completion(>completion);
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9842):
https://lists.yoctoproject.org/g/linux-yocto/message/9842
Mute This Topic: https://lists.yoctoproject.org/mt/82625266/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
