summaryrefslogtreecommitdiff
path: root/security/apparmor
diff options
context:
space:
mode:
authorJerry Zhang <zhangjerry@google.com>2018-04-17 04:17:40 +0300
committerFelipe Balbi <felipe.balbi@linux.intel.com>2018-07-26 13:44:24 +0300
commite610257e462f6104792d22fbb0927724df3bc401 (patch)
tree681a87100f358ca29b791613085fb8c3a61f4ece /security/apparmor
parentd7af78b9245545908c90bce2206f200a4250b5db (diff)
downloadlinux-e610257e462f6104792d22fbb0927724df3bc401.tar.xz
usb: gadget: f_fs: Only return delayed status when len is 0
Commit 1b9ba000 ("Allow function drivers to pause control transfers") states that USB_GADGET_DELAYED_STATUS is only supported if data phase is 0 bytes. It seems that when the length is not 0 bytes, there is no need to explicitly delay the data stage since the transfer is not completed until the user responds. However, when the length is 0, there is no data stage and the transfer is finished once setup() returns, hence there is a need to explicitly delay completion. This manifests as the following bugs: Prior to 946ef68ad4e4 ('Let setup() return USB_GADGET_DELAYED_STATUS'), when setup is 0 bytes, ffs would require user to queue a 0 byte request in order to clear setup state. However, that 0 byte request was actually not needed and would hang and cause errors in other setup requests. After the above commit, 0 byte setups work since the gadget now accepts empty queues to ep0 to clear the delay, but all other setups hang. Fixes: 946ef68ad4e4 ("Let setup() return USB_GADGET_DELAYED_STATUS") Signed-off-by: Jerry Zhang <zhangjerry@google.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Diffstat (limited to 'security/apparmor')
0 files changed, 0 insertions, 0 deletions