- 13 May, 2021 40 commits
-
-
Greg Kroah-Hartman authored
This reverts commit fe543b2f. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. While the original commit does keep the immediate "NULL dereference" from happening, it does not properly propagate the error back to the callers, AND it does not fix this same identical issue in the drivers/net/ethernet/cavium/liquidio/lio_vf_main.c for some reason. Cc: Kangjie Lu <kjlu@umn.edu> Cc: David S. Miller <davem@davemloft.net> Link: https://lore.kernel.org/r/20210503115736.2104747-65-gregkh@linuxfoundation.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
If m5602_write_sensor() or m5602_write_bridge() fail, do not continue to initialize the device but return the error to the calling funtion. Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-64-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
This reverts commit a21a0eb5. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. Different error values should never be "OR" together and expect anything sane to come out of the result. Cc: Aditya Pakki <pakki001@umn.edu> Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-63-gregkh@linuxfoundation.orgSigned-off-by:
-
Alaa Emad authored
If m5602_write_bridge times out, it will return a negative error value. So properly check for this and handle the error correctly instead of just ignoring it. Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Alaa Emad <alaaemadhossney.ae@gmail.com> Link: https://lore.kernel.org/r/20210503115736.2104747-62-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 65602585. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. Different error values should never be "OR" together and expect anything sane to come out of the result. Cc: Aditya Pakki <pakki001@umn.edu> Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-61-gregkh@linuxfoundation.orgSigned-off-by:
-
Alaa Emad authored
The function sp8870_readreg returns a negative value when i2c_transfer fails so properly check for this and return the error if it happens. Cc: Sean Young <sean@mess.org> Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 467a37fb. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This commit is not properly checking for an error at all, so if a read succeeds from this device, it will error out. Cc: Aditya Pakki <pakki001@umn.edu> Cc: Sean Young <sean@mess.org> Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-59-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
cs43130_probe() does not do any valid error checking of things it initializes, OR what it does, it does not unwind properly if there are errors. Fix this up by moving the sysfs files to an attribute group so the driver core will correctly add/remove them all at once and handle errors with them, and correctly check for creating a new workqueue and unwinding if that fails. Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-58-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
This reverts commit a2be42f1. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original patch here is not correct, sysfs files that were created are not unwound. Cc: Kangjie Lu <kjlu@umn.edu> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-57-gregkh@linuxfoundation.orgSigned-off-by:
-
Phillip Potter authored
Check for return value from various snd_soc_dapm_* calls, as many of them can return errors and this should be handled. Also, reintroduce the allocation failure check for rt5645->eq_param as well. Make all areas where return values are checked lead to the end of the function in the case of an error. Finally, introduce a comment explaining how resources here are actually eventually cleaned up by the caller. Cc: Mark Brown <broonie@kernel.org> Signed-off-by:
Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20210503115736.2104747-56-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 51dd97d1. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. Lots of things seem to be still allocated here and must be properly cleaned up if an error happens here. Cc: Kangjie Lu <kjlu@umn.edu> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-55-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
The libertas driver was trying to register sysfs groups "by hand" which causes them to be created _after_ the device is initialized and announced to userspace, which causes races and can prevent userspace tools from seeing the sysfs files correctly. Fix this up by using the built-in sysfs_groups pointers in struct net_device which were created for this very reason, fixing the race condition, and properly allowing for any error that might have occured to be handled properly. Cc: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210503115736.2104747-54-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 43425683. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit was incorrect, the error needs to be propagated back to the caller AND if the second group call fails, the first needs to be removed. There are much better ways to solve this, the driver should NOT be calling sysfs_create_group() on its own as it is racing userspace and loosing. Cc: Kangjie Lu <kjlu@umn.edu> Cc: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210503115736.2104747-53-gregkh@linuxfoundation.orgSigned-off-by:
-
Phillip Potter authored
Place a comment in hidma_mgmt_init explaining why success must currently be assumed, due to the cleanup issue that would need to be considered were this module ever to be unloadable or were this platform_driver_register call ever to fail. Acked-By:
Vinod Koul <vkoul@kernel.org> Acked-By:
Sinan Kaya <okaya@kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit a474b3f0. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original change is NOT correct, as it does not correctly unwind from the resources that was allocated before the call to platform_driver_register(). Cc: Aditya Pakki <pakki001@umn.edu> Acked-By:
-
Phillip Potter authored
crypt_stat memory itself is allocated when inode is created, in ecryptfs_alloc_inode, which returns NULL on failure and is handled by callers, which would prevent us getting to this point. It then calls ecryptfs_init_crypt_stat which allocates crypt_stat->tfm checking for and likewise handling allocation failure. Finally, crypt_stat->flags has ECRYPTFS_STRUCT_INITIALIZED merged into it in ecryptfs_init_crypt_stat as well. Simply put, the conditions that the BUG_ON checks for will never be triggered, as to even get to this function, the relevant conditions will have already been fulfilled (or the inode allocation would fail in the first place and thus no call to this function or those above it). Cc: Tyler Hicks <code@tyhicks.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 2c2a7552. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit log for this change was incorrect, no "error handling code" was added, things will blow up just as badly as before if any of these cases ever were true. As this BUG_ON() never fired, and most of these checks are "obviously" never going to be true, let's just revert to the original code for now until this gets unwound to be done correctly in the future. Cc: Aditya Pakki <pakki001@umn.edu> Fixes: 2c2a7552 ("ecryptfs: replace BUG_ON with error handling code") Cc: stable <stable@vger.kernel.org> Acked-by:
Tyler Hicks <code@tyhicks.com> Link: https://lore.kernel.org/r/20210503115736.2104747-49-gregkh@linuxfoundation.orgSigned-off-by:
-
Phillip Potter authored
Modify return type of hfcusb_ph_info to int, so that we can pass error value up the call stack when allocation of ph_info fails. Also change three of four call sites to actually account for the memory failure. The fourth, in ph_state_nt, is infeasible to change as it is in turn called by ph_state which is used as a function pointer argument to mISDN_initdchannel, which would necessitate changing its signature and updating all the places where it is used (too many). Fixes original flawed commit (38d22659) from the University of Minnesota. Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 38d22659. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. While it looks like the original change is correct, it is not, as none of the setup actually happens, and the error value is not propagated upwards. Cc: Aditya Pakki <pakki001@umn.edu> Cc: David S. Miller <davem@davemloft.net> Link: https://lore.kernel.org/r/20210503115736.2104747-47-gregkh@linuxfoundation.orgSigned-off-by:
-
Anirudh Rayabharam authored
In case create_workqueue() fails, release all resources and return -ENOMEM to caller to avoid potential NULL pointer deref later. Move up the create_workequeue() call to return early and avoid unwinding the call to riocm_rx_fill(). Cc: Alexandre Bounine <alex.bou9@gmail.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Anirudh Rayabharam <mail@anirudhrb.com> Link: https://lore.kernel.org/r/20210503115736.2104747-46-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 23015b22. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit has a memory leak on the error path here, it does not clean up everything properly. Cc: Kangjie Lu <kjlu@umn.edu> Cc: Alexandre Bounine <alex.bou9@gmail.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Fixes: 23015b22 ("rapidio: fix a NULL pointer dereference when create_workqueue() fails") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-45-gregkh@linuxfoundation.orgSigned-off-by:
-
Anirudh Rayabharam authored
Propagate error code from failure of ath6kl_wmi_cmd_send() to the caller. Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit fc6a6521. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The change being reverted does NOTHING as the caller to this function does not even look at the return value of the call. So the "claim" that this fixed an an issue is not true. It will be fixed up properly in a future patch by propagating the error up the stack correctly. Cc: Kangjie Lu <kjlu@umn.edu> Cc: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210503115736.2104747-43-gregkh@linuxfoundation.orgSigned-off-by:
-
Phillip Potter authored
Move hw->cfg.mode and hw->addr.mode assignments from hw->ci->cfg_mode and hw->ci->addr_mode respectively, to be before the subsequent checks for memory IO mode (and possible ioremap calls in this case). Also introduce ioremap error checks at both locations. This allows resources to be properly freed on ioremap failure, as when the caller of setup_io then subsequently calls release_io via its error path, release_io can now correctly determine the mode as it has been set before the ioremap call. Finally, refactor release_io function so that it will call release_mem_region in the memory IO case, regardless of whether or not hw->cfg.p/hw->addr.p are NULL. This means resources are then properly released on failure. This properly implements the original reverted commit (d721fe99) from the University of Minnesota, whilst also implementing the ioremap check for the hw->ci->cfg_mode if block as well. Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit d721fe99. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit was incorrect, it should have never have used "unlikely()" and if it ever does trigger, resources are left grabbed. Given there are no users for this code around, I'll just revert this and leave it "as is" as the odds that ioremap() will ever fail here is horrendiously low. Cc: Kangjie Lu <kjlu@umn.edu> Cc: David S. Miller <davem@davemloft.net> Link: https://lore.kernel.org/r/20210503115736.2104747-41-gregkh@linuxfoundation.orgSigned-off-by:
-
Igor Matheus Andrade Torrente authored
The return of ioremap if not checked, and can lead to a NULL to be assigned to hga_vram. Potentially leading to a NULL pointer dereference. The fix adds code to deal with this case in the error label and changes how the hgafb_probe handles the return of hga_card_detect. Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Igor Matheus Andrade Torrente <igormtorrente@gmail.com> Link: https://lore.kernel.org/r/20210503115736.2104747-40-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
This reverts commit ec7f6aad. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This patch "looks" correct, but the driver keeps on running and will fail horribly right afterward if this error condition ever trips. So points for trying to resolve an issue, but a huge NEGATIVE value for providing a "fake" fix for the problem as nothing actually got resolved at all. I'll go fix this up properly... Cc: Kangjie Lu <kjlu@umn.edu> Cc: Aditya Pakki <pakki001@umn.edu> Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Fixes: ec7f6aad ("video: hgafb: fix potential NULL pointer dereference") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-39-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
This reverts commit a2c6433e. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original patch was incorrect, and would leak memory if the error path the patch added was hit. Cc: Aditya Pakki <pakki001@umn.edu> Reviewed-by:
Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20210503115736.2104747-37-gregkh@linuxfoundation.orgSigned-off-by:
-
Atul Gopinathan authored
The field "fm_res" of "struct snd_sb8" is never used/dereferenced throughout the sb8.c code. Therefore there is no need for any null value check after the "request_region()". Add a comment note to make developers know about this and prevent any "NULL check" patches on this part of code. Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by:
Atul Gopinathan <atulgopinathan@gmail.com> Link: https://lore.kernel.org/r/20210503115736.2104747-36-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
This reverts commit dcd0feac. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit message for this change was incorrect as the code path can never result in a NULL dereference, alluding to the fact that whatever tool was used to "find this" is broken. It's just an optional resource reservation, so removing this check is fine. Cc: Kangjie Lu <kjlu@umn.edu> Acked-by:
-
Greg Kroah-Hartman authored
This reverts commit 0f25e000. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit did nothing if there was an error, except to print out a message, which is pointless. So remove the commit as it gives a "false sense of doing something". Cc: Kangjie Lu <kjlu@umn.edu> Reviewed-by:
-
Phillip Potter authored
Move ufshcd_set_variant call in ufs_hisi_init_common to common error section at end of the function, and then jump to this from the error checking statements for both devm_reset_control_get and ufs_hisi_get_resource. This fixes the original commit (63a06181) which was reverted due to the University of Minnesota problems. Suggested-by:
-
Greg Kroah-Hartman authored
This reverts commit 63a06181. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original commit is incorrect, it does not properly clean up on the error path, so I'll keep the revert and fix it up properly with a follow-on patch. Cc: Kangjie Lu <kjlu@umn.edu> Cc: Avri Altman <avri.altman@wdc.com> Cc: Martin K. Petersen <martin.petersen@oracle.com> Fixes: 63a06181 ("scsi: ufs: fix a missing check of devm_reset_control_get") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-31-gregkh@linuxfoundation.orgSigned-off-by:
-
Tom Seewald authored
The function hpet_resources() calls ioremap() two times, but in both cases it does not check if ioremap() returned a null pointer. Fix this by adding null pointer checks and returning an appropriate error. Signed-off-by:
Tom Seewald <tseewald@gmail.com> Link: https://lore.kernel.org/r/20210503115736.2104747-30-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 13bd14a4. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. While this is technically correct, it is only fixing ONE of these errors in this function, so the patch is not fully correct. I'll leave this revert and provide a fix for this later that resolves this same "problem" everywhere in this function. Cc: Kangjie Lu <kjlu@umn.edu> Link: https://lore.kernel.org/r/20210503115736.2104747-29-gregkh@linuxfoundation.orgSigned-off-by:
-
Atul Gopinathan authored
The fields, "toc" and "cd_info", of "struct gdrom_unit gd" are allocated in "probe_gdrom()". Prevent a memory leak by making sure "gd.cd_info" is deallocated in the "remove_gdrom()" function. Also prevent double free of the field "gd.toc" by moving it from the module's exit function to "remove_gdrom()". This is because, in "probe_gdrom()", the function makes sure to deallocate "gd.toc" in case of any errors, so the exit function invoked later would again free "gd.toc". The patch also maintains consistency by deallocating the above mentioned fields in "remove_gdrom()" along with another memory allocated field "gd.disk". Suggested-by:
Jens Axboe <axboe@kernel.dk> Cc: Peter Rosin <peda@axentia.se> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 093c4821. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. Because of this, all submissions from this group must be reverted from the kernel tree and will need to be re-reviewed again to determine if they actually are a valid fix. Until that work is complete, remove this change to ensure that no problems are being introduced into the codebase. Cc: Wenwen Wang <wang6495@umn.edu> Cc: Peter Rosin <peda@axentia.se> Cc: Jens Axboe <axboe@kernel.dk> Fixes: 093c4821 ("gdrom: fix a memory leak bug") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-27-gregkh@linuxfoundation.orgSigned-off-by:
-
Tom Seewald authored
The function qlcnic_dl_lb_test() currently calls netdev_alloc_skb() without checking afterwards that the allocation succeeded. Fix this by checking if the skb is NULL and returning an error in such a case. Breaking out of the loop if the skb is NULL is not correct as no error would be reported to the caller and no message would be printed for the user. Cc: David S. Miller <davem@davemloft.net> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 5bf7295f. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This commit does not properly detect if an error happens because the logic after this loop will not detect that there was a failed allocation. Cc: Aditya Pakki <pakki001@umn.edu> Cc: David S. Miller <davem@davemloft.net> Fixes: 5bf7295f ("qlcnic: Avoid potential NULL pointer dereference") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-25-gregkh@linuxfoundation.orgSigned-off-by:
-
Du Cheng authored
niu_pci_eeprom_read() may fail, so add checks to its return value and propagate the error up the callstack. An examination of the callstack up to niu_pci_eeprom_read shows that: niu_pci_eeprom_read() // returns int niu_pci_vpd_scan_props() // returns int niu_pci_vpd_fetch() // returns *void* niu_get_invariants() // returns int since niu_pci_vpd_fetch() returns void which breaks the bubbling up, change its return type to int so that error is propagated upwards. Signed-off-by:Du Cheng <ducheng2@gmail.com> Cc: Shannon Nelson <shannon.lee.nelson@gmail.com> Cc: David S. Miller <davem@davemloft.net> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-24-gregkh@linuxfoundation.orgSigned-off-by:
-
