The FIPS lab is required to test the service indicators and version
information services of the module, i.e. the
fips140_is_approved_service() and fips140_module_version() functions.
There are several ways we could support this:
- Implement the tests in the module ourselves. However it's unclear
that CMVP would allow this, and we would need the full list of tests,
which could change over time depending on what the lab decides to do.
- Support the lab writing, building, and loading a custom kernel module
(or a custom kernel image) that tests these functions.
- Provide a userspace interface to these services, restricted to builds
with CONFIG_CRYPTO_FIPS140_MOD_EVAL_TESTING=y. This would allow
writing the tests in userspace, which would be much easier.
Implement the last solution, since it's the easier of the two solutions
that are "guaranteed" to be allowed. Make the module register a char
device which supports some ioctls, one per function that needs to be
tested. Also provide some sample userspace code in samples/crypto/.
Note: copy_to_user() would break the integrity check, so take some care
to exclude it. This is allowed since this is non-production code.
Bug: 188620248
Change-Id: Ic256d9c5bd4d0c57ede88a3e3e76e89554909b38
Signed-off-by: Eric Biggers <ebiggers@google.com>
The lab is required to test injecting an integrity error, so add a
module parameter fail_integrity_check=1 which does this. This parameter
is only supported when CONFIG_CRYPTO_FIPS140_MOD_EVAL_TESTING=y.
Bug: 188620248
Change-Id: I1f3683837706dc1df2755ca5b6e88f21f7956135
Signed-off-by: Eric Biggers <ebiggers@google.com>
It turns out that we have to add more code to the module to support lab
evaluation testing, beyond the error injection support we currently
have. Therefore, rename CONFIG_CRYPTO_FIPS140_MOD_ERROR_INJECTION to
CONFIG_CRYPTO_FIPS140_MOD_EVAL_TESTING, and move the relevant code into
a new file fips140-eval-testing.c which is conditionally compiled.
Also rename the "broken_alg" module parameter to "fail_selftest" so that
it is similar to "fail_integrity_check" which we'll be adding.
Bug: 188620248
Change-Id: I01bcbf7525690e277854ba4ed8dd89e7cd08d98e
Signed-off-by: Eric Biggers <ebiggers@google.com>
When a task yields, it relinquishes the cpu and
scheduler is tasked to find another task.
However our vendor scheduler logic implementation
could return the same task leading to a loop where
the yielded task gets to run back, so add hook point
in do_sched_yield() for vendor can do some work
before task is scheduled.
Bug: 205804537
Change-Id: I6528c3f4b0ee360559ef9c97cb1eb2b2d1357870
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
Function fs endpoint file operations are synchronized via an interruptible
mutex wait. However we see threads that do ep file operations concurrently
are getting blocked for the mutex lock in __fdget_pos(). This is an
uninterruptible wait and we see hung task warnings and kernel panic
if hung_task_panic systcl is enabled if host does not send/receive
the data for long time.
The reason for threads getting blocked in __fdget_pos() is due to
the file position protection introduced by the commit 9c225f2655
("vfs: atomic f_pos accesses as per POSIX"). Since function fs
endpoint files does not have the notion of the file position, switch
to the stream mode. This will bypass the file position mutex and
threads will be blocked in interruptible state for the function fs
mutex.
It should not affects user space as we are only changing the task state
changes the task state from UNINTERRUPTIBLE to INTERRUPTIBLE while waiting
for the USB transfers to be finished. However there is a slight change to
the O_NONBLOCK behavior. Earlier threads that are using O_NONBLOCK are also
getting blocked inside fdget_pos(). Now they reach to function fs and error
code is returned. The non blocking behavior is actually honoured now.
Reviewed-by: John Keeping <john@metanate.com>
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Link: https://lore.kernel.org/r/1636712682-1226-1-git-send-email-quic_pkondeti@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c76ef96fc00eb398c8fc836b0eb2f82bcc619dc7
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Bug: 206906138
Change-Id: Ifb99336a4da7587c7e71a6c45999a36948194d7a
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
This patch will export some tracepoints so that vendor modules can use them.
Export these tracepoint functions to track IO data flow for performance tuning.
Bug: 205648026
Change-Id: Ia37b8f99b2d940cecce46c8bc24f724c14450517
Signed-off-by: Yang Yang <yang.yang@vivo.com>
GKI required the KMI_GENERATION to be added to the kernel version
string, but this only makes sense for GKI kernels, for non-GKI kernels
we don't need it. Leave all the other stuff we added, though, as it
seems useful.
Bug: 205897686
Change-Id: I2e7b3cb7ed5529f1e5e7c9d79a1f7ce4a1b6ee1f
Signed-off-by: Alistair Delva <adelva@google.com>
We want to get binder free space information in the binder
transaction, but this needs to hold the mutex lock. So we add
this restrict hook to do this.
Bug: 205648032
Change-Id: Ie1f377018da686bd62f5ac2d1e5421899741e6d5
Signed-off-by: Liangliang Li <liliangliang@vivo.com>
Need to add additional symbol in execution path to ABI list.
Bug: 176077958
Change-Id: I676b4f9a016c825572d10de49b6062a90078f2f2
Signed-off-by: Shaleen Agrawal <shalagra@codeaurora.org>
This reverts commit 20285dc271, which
causes serious performance downgrade because the calculated cpu
frequency will be much lower than before due to change of cpu util.
Bug: 205915994
Test: build pass
Change-Id: I68dced7a58547a3324fcfeebea6c02bb30c4182d
Signed-off-by: Rick Yiu <rickyiu@google.com>
sem->count will be negative after writer is killed
if flag RWSEM_FLAG_HANDOFF is not set, we shouldn't clean again
CPU2 CPU4
task A[reader] task B[writer]
down_read_killable[locked]
sem->count=0x100
down_write_killable
sem->count=0x102[wlist not empty]
up_read
count=0x2
sig kill received
down_read_killable
sem->count=0x102[wlist not empty]
goto branch out_nolock:
list_del(&waiter.list);
wait list is empty
sem->count-RWSEM_FLAG_HANDOFF
sem->count=0xFE
list_empty(&sem->wait_list) is TRUE
sem->count andnot RWSEM_FLAG_WAITERS
sem->count=0xFC
up_read
sem->count-=0x100
sem->count=0xFFFFFFFFFFFFFFFC
DEBUG_RWSEMS_WARN_ON(tmp < 0, sem);
Bug: 204595609
Link: https://lore.kernel.org/all/a630a9aa-8c66-31c9-21a0-3d30bde2c9df@redhat.com/T/
Signed-off-by: mazhenhua <mazhenhua@xiaomi.com>
Change-Id: Ife64c179335d74768a3d68e402c72d10148f3e7e
A recent change to use proc->cred instead of proc->tsk as the source
for sender_euid caused a failure in the CredentialsTest#CaptureLayersTest
test. Revert 1 line of the patch to fix the test. The rest of the patch
needs to remain since the subsequent patches rely on it.
Before fixing upstream, we need to investigate more since the code looks
correct so the issue may be a latent userspace bug.
Bug: 205938623
Fixes: d65efd5b73dc ("UPSTREAM: binder: use euid from cred instead of using task")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I16543a50f43f79131234995fb0813de00795bd3d
Use the standard auto-generated kernel version string instead of a
manually assigned version number that will get out-of-date. There was
discussion of custom version numbers being needed for certification
purposes, but it appears that they won't be needed after all.
This will produce a version string like
"5.10.66-android12-9-00017-g0b8a0a4df237".
Bug: 188620248
Change-Id: Ia369e91e4a18f489418123c672686e05ca99063d
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 4e0c1040758540aac34b753ed41792c8ad322a8c)
Use the 'struct cred' saved at binder_open() to lookup
the security ID via security_cred_getsecid(). This
ensures that the security context that opened binder
is the one used to generate the secctx.
Cc: stable@vger.kernel.org # 5.4+
Fixes: ec74136ded ("binder: create node flag to request sender's security context")
Signed-off-by: Todd Kjos <tkjos@google.com>
Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Bug: 200688826
(cherry picked from commit 4d5b5539742d2554591751b4248b0204d20dcc9d)
[ refactored to avoid changing KMI: struct binder_proc ]
Change-Id: Ie023be3190caf20ca3901560455e9f027c9426cd
Since binder was integrated with selinux, it has passed
'struct task_struct' associated with the binder_proc
to represent the source and target of transactions.
The conversion of task to SID was then done in the hook
implementations. It turns out that there are race conditions
which can result in an incorrect security context being used.
Fix by using the 'struct cred' saved during binder_open and pass
it to the selinux subsystem.
Cc: stable@vger.kernel.org # 5.14 (need backport for earlier stables)
Fixes: 79af73079d ("Add security hooks to binder and implement the hooks for SELinux.")
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Bug: 200688826
(cherry picked from commit 52f88693378a58094c538662ba652aff0253c4fe)
[ refactored to avoid changing KMI: struct binder_proc ]
Change-Id: I1664c1f0c2142c17e9ca0d6790bb94de79f531e3
Save the 'struct cred' associated with a binder process
at initial open to avoid potential race conditions
when converting to an euid.
Set a transaction's sender_euid from the 'struct cred'
saved at binder_open() instead of looking up the euid
from the binder proc's 'struct task'. This ensures
the euid is associated with the security context that
of the task that opened binder.
Cc: stable@vger.kernel.org # 4.4+
Fixes: 457b9a6f09 ("Staging: android: add binder driver")
Signed-off-by: Todd Kjos <tkjos@google.com>
Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Suggested-by: Jann Horn <jannh@google.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Bug: 200688826
(cherry picked from commit 29bc22ac5e5bc63275e850f0c8fc549e3d0e306b)
[ refactored to avoid changing KMI: struct binder_proc ]
Change-Id: Icaf996a7f5543b7d6943dff3cbe89bfc3614044c
These hooks will do the following works:
a) Record the number of times when target_freq being clamped
b) Record the number of times when target_freq is greater than policy->cur
c) Make corresponding optimization strategies in different hooks
Bug: 205906618
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Change-Id: I8eba66fd0c6d36393ca39045cf228b659834e0ae
Signed-off-by: xieliujie <xieliujie@oppo.com>
Export get_wchan to get the block reason
Bug: 205684022
Signed-off-by: xieliujie <xieliujie@oppo.com>
Change-Id: I7b65bb502b805e7dac13e5f9d725da1ff70fe306
These hooks will do the following works:
a) record the time of the process in various states
b) Make corresponding optimization strategies in different hooks
Bug: 205938967
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Change-Id: Ia3c47bbf0aadd17337ce18fd910343b1b8c3ef93
cpufreq_times_record_transition() is not called when fast switch is
enabled, leading /proc/[pid]/time_in_state to attribute all time on a
cluster to a single frequency. To fix this, add a call to
cpufreq_times_record_transition() in the fast switch path.
Test: /proc/[pid]/time_in_state shows times for more than one freq per
cluster
Bug: 204726690
Signed-off-by: zhengding chen <chenzhengding@oppo.com>
Change-Id: Ief47ffb49fcc7fbf5408eea3056930e8791d2820
Add hooks to gather data of unusual aborts and summarize it with
other information.
Bug: 203187389
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Change-Id: I37b3047e72f64dc210d3d3bffe5ee207daeba8d6
During the suspend is in process, thermal_zone_device_update bails out
thermal zone re-evaluation for any sensor trip violation without
setting next valid trip to that sensor. It assumes during resume
it will re-evaluate same thermal zone and update trip. But when it is
in suspend temperature goes down and on resume path while updating
thermal zone if temperature is less than previously violated trip,
thermal zone set trip function evaluates the same previous high and
previous low trip as new high and low trip. Since there is no change
in high/low trip, it bails out from thermal zone set trip API without
setting any trip. It leads to a case where sensor high trip or low
trip is disabled forever even though thermal zone has a valid high
or low trip.
During thermal zone device init, reset thermal zone previous high
and low trip. It resolves above mentioned scenario.
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
Reviewed-by: Thara Gopinath <thara.gopinath@linaro.org>
Bug: 205496325
Link: https://lore.kernel.org/linux-pm/51de966a-9c9e-88a8-5c2c-96773a64d527@linaro.org/T/#u
Change-Id: Ib57ac6164811a566b497964701f23a3c209915e3
Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
A potential use after free can occur in _vm_unmap_aliases where an already
freed vmap_area could be accessed, Consider the following scenario:
Process 1 Process 2
__vm_unmap_aliases __vm_unmap_aliases
purge_fragmented_blocks_allcpus rcu_read_lock()
rcu_read_lock()
list_del_rcu(&vb->free_list)
list_for_each_entry_rcu(vb .. )
__purge_vmap_area_lazy
kmem_cache_free(va)
va_start = vb->va->va_start
Here Process 1 is in purge path and it does list_del_rcu on vmap_block and
later frees the vmap_area, since Process 2 was holding the rcu lock at
this time vmap_block will still be present in and Process 2 accesse it and
thereby it tries to access vmap_area of that vmap_block which was already
freed by Process 1 and this results in use after free.
Fix this by adding a check for vb->dirty before accessing vmap_area
structure since vb->dirty will be set to VMAP_BBMAP_BITS in purge path
checking for this will prevent the use after free.
Link: https://lkml.kernel.org/r/1616062105-23263-1-git-send-email-vjitta@codeaurora.org
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 205658047
(cherry picked from commit ad216c0316ad6391d90f4de0a7f59396b2925a06
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)
Change-Id: I450781b5734570d1b9e8c63ac29ad3635c8e49bb
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
The following deadlock has been observed on a test setup:
* All tags allocated.
* The SCSI error handler calls ufshcd_eh_host_reset_handler()
* ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler()
* ufshcd_err_handler() locks up as follows:
Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt
Call trace:
__switch_to+0x298/0x5d8
__schedule+0x6cc/0xa94
schedule+0x12c/0x298
blk_mq_get_tag+0x210/0x480
__blk_mq_alloc_request+0x1c8/0x284
blk_get_request+0x74/0x134
ufshcd_exec_dev_cmd+0x68/0x640
ufshcd_verify_dev_init+0x68/0x35c
ufshcd_probe_hba+0x12c/0x1cb8
ufshcd_host_reset_and_restore+0x88/0x254
ufshcd_reset_and_restore+0xd0/0x354
ufshcd_err_handler+0x408/0xc58
process_one_work+0x24c/0x66c
worker_thread+0x3e8/0xa4c
kthread+0x150/0x1b4
ret_from_fork+0x10/0x30
Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved
request.
This patch is closely related to the upstream patch with the same title.
Bug: 205080886
Link: https://lore.kernel.org/linux-scsi/700f0463-23a9-8465-f712-1188cb884dea@acm.org/T/#u
Change-Id: I9e9ba3f45ba23ecf576380aa19701d3437af6cdd
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Before reducing 'can_queue' from 32 to 31, make
ufshcd_change_queue_depth() restrict the queue depth to 'can_queue'
instead of hba->nutrs (32). This is a backport of a subset of the
following patch: "[PATCH 2/2] scsi: ufs: Fix a deadlock in the error
handler".
Bug: 205080886
Link: https://lore.kernel.org/linux-scsi/20211103000529.1549411-3-bvanassche@acm.org/
Change-Id: I6e694a9698f91293fc2987217e3f939726c397dd
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Commit 4c22227e39 ("cfg80211: fix management registrations locking")
in 5.10.77, which is commit 09b1d5dc6ce1 ("cfg80211: fix management
registrations locking") upstream, moved the mgmt_registrations_lock out
of struct wireless_dev. This did not change the structure size, but
caused a CRC change in the structure pointer, which tripped the abi
checker.
So restore the variable, and comment that this is not used anymore. No
driver should ever be touching this so it is safe.
Note, using a __GENKSYMS__ hack would work, as the overall structure
size remains the same when this variable is removed, BUT the warning
that the field is gone is reported by libabigail correctly, which would
require a .xml update, so it's not worth it.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibcfe743833860e6f75611d7ebed1036a77be0a69
The management registrations locking was broken, the list was
locked for each wdev, but cfg80211_mgmt_registrations_update()
iterated it without holding all the correct spinlocks, causing
list corruption.
Rather than trying to fix it with fine-grained locking, just
move the lock to the wiphy/rdev (still need the list on each
wdev), we already need to hold the wdev lock to change it, so
there's no contention on the lock in any case. This trivially
fixes the bug since we hold one wdev's lock already, and now
will hold the lock that protects all lists.
Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen <j@w1.fi>
Fixes: 6cd536fe62 ("cfg80211: change internal management frame registration API")
Link: https://lore.kernel.org/r/20211025133111.5cf733eab0f4.I7b0abb0494ab712f74e2efcd24bb31ac33f7eee9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 204384349
(cherry picked from commit 09b1d5dc6ce1c9151777f6c4e128a59457704c97)
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id1bca68277be3a5f7c7329a8195018946f686bdb
When receiving a disconnect event from the UDC, the mass storage
function driver currently runs the handle_exception() routine
asynchronously. For UDCs that support runtime PM, there is a
possibility the UDC is already suspended by the time the
do_set_interface() is executed. This can lead to HW register access
while the UDC is already suspended.
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Bug: 204343836
(cherry picked from commit 9fff139aeb11186fd8e75860c959c86cb43ab2f6
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing)
Change-Id: I6c8011baddf02d6b0eadb5934416bc24b8a93f4a
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
The usb_ep_disable() and usb_ep_enable() routines are being widely
used in atomic/interrupt context by function drivers. Hence, the
statement about it being able to only run in process context may
not be true. Add an explicit comment mentioning that it can be used
in atomic context.
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Bug: 204343836
(cherry picked from commit b0d5d2a71641bb50cada708cc8fdca946a837e9a
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing)
Change-Id: I1adb5d074fe2f9e33ebfdb30d335283c56bc7b39
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
If CONFIG_CFI_CLANG=y, attempting to read an event histogram will cause
the kernel to panic due to failed CFI check.
1. echo 'hist:keys=common_pid' >> events/sched/sched_switch/trigger
2. cat events/sched/sched_switch/hist
3. kernel panics on attempting to read hist
This happens because the sort() function expects a generic
int (*)(const void *, const void *) pointer for the compare function.
To prevent this CFI failure, change tracing map cmp_entries_* function
signatures to match this.
Also, fix the build error reported by the kernel test robot [1].
[1] https://lore.kernel.org/r/202110141140.zzi4dRh4-lkp@intel.com/
Link: https://lkml.kernel.org/r/20211014045217.3265162-1-kaleshsingh@google.com
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Bug: 204946901
(cherry picked from commit 7ce1bb83a14019f8c396d57ec704d19478747716)
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Change-Id: I4a1a39b086b5e306ddecabd9a6076e2fb14c3f70
In host control mode, eviction is precieved as an extreme measure.
There are several conditions that both the entering and exiting regions
should meet, so that eviction will take place.
The common case however, is that those conditions are rarely met, so it
is normal that the act of eviction fails. Therefore, Do not report an
error in host control mode if eviction fails.
Link: https://lore.kernel.org/r/20210808090024.21721-5-avri.altman@wdc.com
Fixes: 6c59cb501b86 (scsi: ufs: ufshpb: Make eviction depend on region's reads)
(cherry picked from commit 10163cee1f06fc2e17bcf7bbc2982337202d1d5c
git: //git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: Id6aa444ea5e2efd15c507bbd586c421018c75998
num_inflight_map_req should not be negative. It is incremented and
decremented without any protection, allowing it theoretically to be
negative, should some weird unbalanced count occur.
Verify that the those calls are properly serielized.
Link: https://lore.kernel.org/r/20210808090024.21721-4-avri.altman@wdc.com
Fixes: 33845a2d844b (scsi: ufs: ufshpb: Limit the number of in-flight map requests)
(cherry picked from commit 22aede9f48b6766fb67441610120db9b04adf109
git: //git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: I8a8252c919e6678752b60bcd950cb08e765e6aed
In HPB2.0, if pre_req_min_tr_len < transfer_len < pre_req_max_tr_len
the driver is expected to send a HPB-WRITE-BUFFER companion to HPB-READ.
The upper bound should fit into a single byte, regardless of
bMAX_ DATA_SIZE_FOR_HPB_SINGLE_CMD which being an attribute (u32) can
be significantly larger.
To further illustrate the issue let us consider the following scenario:
- SCSI_DEFAULT_MAX_SECTORS is 1024 limiting the IO chunks to 512KB
- The OEM changes scsi_host_template .max_sectors to be 2048, which
allows a 1M requests: transfer_len = 256
- pre_req_max_tr_len = HPB_MULTI_CHUNK_HIGH = 256
- ufshpb_is_supported_chunk returns true (256 <= 256)
- WARN_ON_ONCE(transfer_len > HPB_MULTI_CHUNK_HIGH) doesn't warn
- ufshpb_set_hpb_read_to_upiu cast transfer_len to u8: transfer_len = 0
- the command is failing with illegal request
Link: https://lore.kernel.org/r/20210808090024.21721-3-avri.altman@wdc.com
Fixes: 41d8a9333cc9 (scsi: ufs: ufshpb: Add HPB 2.0 support)
(cherry picked from commit 07106f86ae13d9197bfd38c2d47743304b14099e
git: //git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: I0dc568020a0fe6c4ddf6952f89ad5230770fd7f3
