1. 05 Jun, 2018 1 commit
    • Deepa Dinamani's avatar
      vfs: change inode times to use struct timespec64 · 95582b00
      Deepa Dinamani authored
      struct timespec is not y2038 safe. Transition vfs to use
      y2038 safe struct timespec64 instead.
      The change was made with the help of the following cocinelle
      script. This catches about 80% of the changes.
      All the header file and logic changes are included in the
      first 5 rules. The rest are trivial substitutions.
      I avoid changing any of the function signatures or any other
      filesystem specific data structures to keep the patch simple
      for review.
      The script can be a little shorter by combining different cases.
      But, this version was sufficient for my usecase.
      virtual patch
      @ depends on patch @
      identifier now;
      - struct timespec
      + struct timespec64
        current_time ( ... )
      - struct timespec now = current_kernel_time();
      + struct timespec64 now = current_kernel_time64();
      - return timespec_trunc(
      + return timespec64_trunc(
        ... );
      @ depends on patch @
      identifier xtime;
       struct \( iattr \| inode \| kstat \) {
      -       struct timespec xtime;
      +       struct timespec64 xtime;
      @ depends on patch @
      identifier t;
       struct inode_operations {
      int (*update_time) (...,
      -       struct timespec t,
      +       struct timespec64 t,
      @ depends on patch @
      identifier t;
      identifier fn_update_time =~ "update_time$";
       fn_update_time (...,
      - struct timespec *t,
      + struct timespec64 *t,
       ...) { ... }
      @ depends on patch @
      identifier t;
      lease_get_mtime( ... ,
      - struct timespec *t
      + struct timespec64 *t
        ) { ... }
      @te depends on patch forall@
      identifier ts;
      local idexpression struct inode *inode_node;
      identifier i_xtime =~ "^i_[acm]time$";
      identifier ia_xtime =~ "^ia_[acm]time$";
      identifier fn_update_time =~ "update_time$";
      identifier fn;
      expression e, E3;
      local idexpression struct inode *node1;
      local idexpression struct inode *node2;
      local idexpression struct iattr *attr1;
      local idexpression struct iattr *attr2;
      local idexpression struct iattr attr;
      identifier i_xtime1 =~ "^i_[acm]time$";
      identifier i_xtime2 =~ "^i_[acm]time$";
      identifier ia_xtime1 =~ "^ia_[acm]time$";
      identifier ia_xtime2 =~ "^ia_[acm]time$";
      - struct timespec ts;
      + struct timespec64 ts;
      - struct timespec ts = current_time(inode_node);
      + struct timespec64 ts = current_time(inode_node);
      <+... when != ts
      - timespec_equal(&inode_node->i_xtime, &ts)
      + timespec64_equal(&inode_node->i_xtime, &ts)
      - timespec_equal(&ts, &inode_node->i_xtime)
      + timespec64_equal(&ts, &inode_node->i_xtime)
      - timespec_compare(&inode_node->i_xtime, &ts)
      + timespec64_compare(&inode_node->i_xtime, &ts)
      - timespec_compare(&ts, &inode_node->i_xtime)
      + timespec64_compare(&ts, &inode_node->i_xtime)
      ts = current_time(e)
      fn_update_time(..., &ts,...)
      inode_node->i_xtime = ts
      node1->i_xtime = ts
      ts = inode_node->i_xtime
      <+... attr1->ia_xtime ...+> = ts
      ts = attr1->ia_xtime
      btrfs_set_stack_timespec_sec(..., ts.tv_sec)
      btrfs_set_stack_timespec_nsec(..., ts.tv_nsec)
      - ts = timespec64_to_timespec(
      + ts =
      - ts = ktime_to_timespec(
      + ts = ktime_to_timespec64(
      - ts = E3
      + ts = timespec_to_timespec64(E3)
      - ktime_get_real_ts(&ts)
      + ktime_get_real_ts64(&ts)
      - ts
      + timespec64_to_timespec(ts)
      <... when != ts
      - return ts;
      + return timespec64_to_timespec(ts);
      - timespec_equal(&node1->i_xtime1, &node2->i_xtime2)
      + timespec64_equal(&node1->i_xtime2, &node2->i_xtime2)
      - timespec_equal(&node1->i_xtime1, &attr2->ia_xtime2)
      + timespec64_equal(&node1->i_xtime2, &attr2->ia_xtime2)
      - timespec_compare(&node1->i_xtime1, &node2->i_xtime2)
      + timespec64_compare(&node1->i_xtime1, &node2->i_xtime2)
      node1->i_xtime1 =
      - timespec_trunc(attr1->ia_xtime1,
      + timespec64_trunc(attr1->ia_xtime1,
      - attr1->ia_xtime1 = timespec_trunc(attr2->ia_xtime2,
      + attr1->ia_xtime1 =  timespec64_trunc(attr2->ia_xtime2,
      - ktime_get_real_ts(&attr1->ia_xtime1)
      + ktime_get_real_ts64(&attr1->ia_xtime1)
      - ktime_get_real_ts(&attr.ia_xtime1)
      + ktime_get_real_ts64(&attr.ia_xtime1)
      @ depends on patch @
      struct inode *node;
      struct iattr *attr;
      identifier fn;
      identifier i_xtime =~ "^i_[acm]time$";
      identifier ia_xtime =~ "^ia_[acm]time$";
      expression e;
      - fn(node->i_xtime);
      + fn(timespec64_to_timespec(node->i_xtime));
      - node->i_xtime);
      + timespec64_to_timespec(node->i_xtime));
      - e = fn(attr->ia_xtime);
      + e = fn(timespec64_to_timespec(attr->ia_xtime));
      @ depends on patch forall @
      struct inode *node;
      struct iattr *attr;
      identifier i_xtime =~ "^i_[acm]time$";
      identifier ia_xtime =~ "^ia_[acm]time$";
      identifier fn;
      + struct timespec ts;
      + ts = timespec64_to_timespec(node->i_xtime);
      fn (...,
      - &node->i_xtime,
      + &ts,
      + ts = timespec64_to_timespec(attr->ia_xtime);
      fn (...,
      - &attr->ia_xtime,
      + &ts,
      @ depends on patch forall @
      struct inode *node;
      struct iattr *attr;
      struct kstat *stat;
      identifier ia_xtime =~ "^ia_[acm]time$";
      identifier i_xtime =~ "^i_[acm]time$";
      identifier xtime =~ "^[acm]time$";
      identifier fn, ret;
      + struct timespec ts;
      + ts = timespec64_to_timespec(node->i_xtime);
      ret = fn (...,
      - &node->i_xtime,
      + &ts,
      + ts = timespec64_to_timespec(node->i_xtime);
      ret = fn (...,
      - &node->i_xtime);
      + &ts);
      + ts = timespec64_to_timespec(attr->ia_xtime);
      ret = fn (...,
      - &attr->ia_xtime,
      + &ts,
      + ts = timespec64_to_timespec(attr->ia_xtime);
      ret = fn (...,
      - &attr->ia_xtime);
      + &ts);
      + ts = timespec64_to_timespec(stat->xtime);
      ret = fn (...,
      - &stat->xtime);
      + &ts);
      @ depends on patch @
      struct inode *node;
      struct inode *node2;
      identifier i_xtime1 =~ "^i_[acm]time$";
      identifier i_xtime2 =~ "^i_[acm]time$";
      identifier i_xtime3 =~ "^i_[acm]time$";
      struct iattr *attrp;
      struct iattr *attrp2;
      struct iattr attr ;
      identifier ia_xtime1 =~ "^ia_[acm]time$";
      identifier ia_xtime2 =~ "^ia_[acm]time$";
      struct kstat *stat;
      struct kstat stat1;
      struct timespec64 ts;
      identifier xtime =~ "^[acmb]time$";
      expression e;
      ( node->i_xtime2 \| attrp->ia_xtime2 \| attr.ia_xtime2 \) = node->i_xtime1  ;
       node->i_xtime2 = \( node2->i_xtime1 \| timespec64_trunc(...) \);
       node->i_xtime2 = node->i_xtime1 = node->i_xtime3 = \(ts \| current_time(...) \);
       node->i_xtime1 = node->i_xtime3 = \(ts \| current_time(...) \);
       stat->xtime = node2->i_xtime1;
       stat1.xtime = node2->i_xtime1;
      ( node->i_xtime2 \| attrp->ia_xtime2 \) = attrp->ia_xtime1  ;
      ( attrp->ia_xtime1 \| attr.ia_xtime1 \) = attrp2->ia_xtime2;
      - e = node->i_xtime1;
      + e = timespec64_to_timespec( node->i_xtime1 );
      - e = attrp->ia_xtime1;
      + e = timespec64_to_timespec( attrp->ia_xtime1 );
      node->i_xtime1 = current_time(...);
       node->i_xtime2 = node->i_xtime1 = node->i_xtime3 =
      - e;
      + timespec_to_timespec64(e);
       node->i_xtime1 = node->i_xtime3 =
      - e;
      + timespec_to_timespec64(e);
      - node->i_xtime1 = e;
      + node->i_xtime1 = timespec_to_timespec64(e);
      Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
      Cc: <anton@tuxera.com>
      Cc: <balbi@kernel.org>
      Cc: <bfields@fieldses.org>
      Cc: <darrick.wong@oracle.com>
      Cc: <dhowells@redhat.com>
      Cc: <dsterba@suse.com>
      Cc: <dwmw2@infradead.org>
      Cc: <hch@lst.de>
      Cc: <hirofumi@mail.parknet.co.jp>
      Cc: <hubcap@omnibond.com>
      Cc: <jack@suse.com>
      Cc: <jaegeuk@kernel.org>
      Cc: <jaharkes@cs.cmu.edu>
      Cc: <jslaby@suse.com>
      Cc: <keescook@chromium.org>
      Cc: <mark@fasheh.com>
      Cc: <miklos@szeredi.hu>
      Cc: <nico@linaro.org>
      Cc: <reiserfs-devel@vger.kernel.org>
      Cc: <richard@nod.at>
      Cc: <sage@redhat.com>
      Cc: <sfrench@samba.org>
      Cc: <swhiteho@redhat.com>
      Cc: <tj@kernel.org>
      Cc: <trond.myklebust@primarydata.com>
      Cc: <tytso@mit.edu>
      Cc: <viro@zeniv.linux.org.uk>
  2. 15 May, 2018 1 commit
  3. 13 Mar, 2018 2 commits
    • Lars-Peter Clausen's avatar
      usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS · 946ef68a
      Lars-Peter Clausen authored
      Some UDC drivers (like the DWC3) expect that the response to a setup()
      request is queued from within the setup function itself so that it is
      available as soon as setup() has completed.
      Upon receiving a setup request the function fs driver creates an event that
      is made available to userspace. And only once userspace has acknowledged
      that event the response to the setup request is queued.
      So it violates the requirement of those UDC drivers and random failures can
      be observed. This is basically a race condition and if userspace is able to
      read the event and queue the response fast enough all is good. But if it is
      not, for example because other processes are currently scheduled to run,
      the USB host that sent the setup request will observe an error.
      To avoid this the gadget framework provides the USB_GADGET_DELAYED_STATUS
      return code. If a setup() callback returns this value the UDC driver is
      aware that response is not yet available and can uses the appropriate
      methods to handle this case.
      Since in the case of function fs the response will never be available when
      the setup() function returns make sure that this status code is used.
      This fixed random occasional failures that were previously observed on a
      DWC3 based system under high system load.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
    • Lars-Peter Clausen's avatar
      usb: gadget: ffs: Execute copy_to_user() with USER_DS set · 4058ebf3
      Lars-Peter Clausen authored
      When using a AIO read() operation on the function FS gadget driver a URB is
      submitted asynchronously and on URB completion the received data is copied
      to the userspace buffer associated with the read operation.
      This is done from a kernel worker thread invoking copy_to_user() (through
      copy_to_iter()). And while the user space process memory is made available
      to the kernel thread using use_mm(), some architecture require in addition
      to this that the operation runs with USER_DS set. Otherwise the userspace
      memory access will fail.
      For example on ARM64 with Privileged Access Never (PAN) and User Access
      Override (UAO) enabled the following crash occurs.
      	Internal error: Accessing user space memory with fs=KERNEL_DS: 9600004f [#1] SMP
      	Modules linked in:
      	CPU: 2 PID: 1636 Comm: kworker/2:1 Not tainted 4.9.0-04081-g8ab2dfb-dirty #487
      	Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
      	Workqueue: events ffs_user_copy_worker
      	task: ffffffc87afc8080 task.stack: ffffffc87a00c000
      	PC is at __arch_copy_to_user+0x190/0x220
      	LR is at copy_to_iter+0x78/0x3c8
      	[<ffffff800847b790>] __arch_copy_to_user+0x190/0x220
      	[<ffffff80086f25d8>] ffs_user_copy_worker+0x70/0x130
      	[<ffffff80080b8c64>] process_one_work+0x1dc/0x460
      	[<ffffff80080b8f38>] worker_thread+0x50/0x4b0
      	[<ffffff80080bf5a0>] kthread+0xd8/0xf0
      	[<ffffff8008083680>] ret_from_fork+0x10/0x50
      Address this by placing a set_fs(USER_DS) before of the copy operation
      and revert it again once the copy operation has finished.
      This patch is analogous to commit d7ffde35
       ("vhost: use USER_DS in
      vhost_worker thread") which addresses the same underlying issue.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
  4. 05 Mar, 2018 1 commit
    • Xinyong's avatar
      usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb() · 1a087f03
      Xinyong authored
      When I debug a kernel crash issue in funcitonfs, found ffs_data.ref
      overflowed, While functionfs is unmounting, ffs_data is put twice.
      Commit 43938613
       ("drivers, usb: convert ffs_data.ref from atomic_t to
      refcount_t") can avoid refcount overflow, but that is risk some situations.
      So no need put ffs data in ffs_fs_kill_sb, already put in ffs_data_closed.
      The issue can be reproduced in Mediatek mt6763 SoC, ffs for ADB device.
      KASAN enabled configuration reports use-after-free errro.
      BUG: KASAN: use-after-free in refcount_dec_and_test+0x14/0xe0 at addr ffffffc0579386a0
      Read of size 4 by task umount/4650
      BUG kmalloc-512 (Tainted: P        W  O   ): kasan: bad access detected
      INFO: Allocated in ffs_fs_mount+0x194/0x844 age=22856 cpu=2 pid=566
      INFO: Freed in ffs_data_put+0x25c/0x320 age=0 cpu=3 pid=4650
      INFO: Object 0xffffffc057938600 @offset=1536 fp=0x          (null)
      Call trace:
      [<ffffff900808cf5c>] dump_backtrace+0x0/0x250
      [<ffffff900808d3a0>] show_stack+0x14/0x1c
      [<ffffff90084a8c04>] dump_stack+0xa0/0xc8
      [<ffffff900826c2b4>] print_trailer+0x158/0x260
      [<ffffff900826d9d8>] object_err+0x3c/0x40
      [<ffffff90082745f0>] kasan_report_error+0x2a8/0x754
      [<ffffff9008274f84>] kasan_report+0x5c/0x60
      [<ffffff9008273208>] __asan_load4+0x70/0x88
      [<ffffff90084cd81c>] refcount_dec_and_test+0x14/0xe0
      [<ffffff9008d98f9c>] ffs_data_put+0x80/0x320
      [<ffffff9008d9d904>] ffs_fs_kill_sb+0xc8/0x110
      [<ffffff90082852a0>] deactivate_locked_super+0x6c/0x98
      [<ffffff900828537c>] deactivate_super+0xb0/0xbc
      [<ffffff90082af0c0>] cleanup_mnt+0x64/0xec
      [<ffffff90082af1b0>] __cleanup_mnt+0x10/0x18
      [<ffffff90080d9e68>] task_work_run+0xcc/0x124
      [<ffffff900808c8c0>] do_notify_resume+0x60/0x70
      [<ffffff90080866e4>] work_pending+0x10/0x14
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarXinyong <xinyong.fang@linux.alibaba.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
  5. 12 Feb, 2018 2 commits
    • Jack Pham's avatar
      usb: gadget: f_fs: Use config_ep_by_speed() · 675272d0
      Jack Pham authored
      In commit 2bfa0719 ("usb: gadget: function: f_fs: pass
      companion descriptor along") there is a pointer arithmetic
      bug where the comp_desc is obtained as follows:
       comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
      Since ds is a pointer to usb_endpoint_descriptor, adding
      7 to it ends up going out of bounds (7 * sizeof(struct
      usb_endpoint_descriptor), which is actually 7*9 bytes) past
      the SS descriptor. As a result the maxburst value will be
      read incorrectly, and the UDC driver will also get a garbage
      comp_desc (assuming it uses it).
      Since Felipe wrote, "Eventually, f_fs.c should be converted
      to use config_ep_by_speed() like all other functions, though",
      let's finally do it. This allows the other usb_ep fields to
      be properly populated, such as maxpacket and mult. It also
      eliminates the awkward speed-based descriptor lookup since
      config_ep_by_speed() does that already using the ones found
      in struct usb_function.
      Fixes: 2bfa0719
       ("usb: gadget: function: f_fs: pass companion descriptor along")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJack Pham <jackp@codeaurora.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
    • Jack Pham's avatar
      usb: gadget: f_fs: Process all descriptors during bind · 6cf439e0
      Jack Pham authored
      During _ffs_func_bind(), the received descriptors are evaluated
      to prepare for binding with the gadget in order to allocate
      endpoints and optionally set up OS descriptors. However, the
      high- and super-speed descriptors are only parsed based on
      whether the gadget_is_dualspeed() and gadget_is_superspeed()
      calls are true, respectively.
      This is a problem in case a userspace program always provides
      all of the {full,high,super,OS} descriptors when configuring a
      function. Then, for example if a gadget device is not capable
      of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
      is skipped, resulting in an incorrect offset calculation for
      the vla_ptr when moving on to the OS descriptors that follow.
      This causes ffs_do_os_descs() to fail as it is now looking at
      the SS descriptors' offset within the raw_descs buffer instead.
      _ffs_func_bind() should evaluate the descriptors unconditionally,
      so remove the checks for gadget speed.
      Fixes: f0175ab5
       ("usb: gadget: f_fs: OS descriptors support")
      Cc: stable@vger.kernel.org
      Co-Developed-by: default avatarMayank Rana <mrana@codeaurora.org>
      Signed-off-by: default avatarMayank Rana <mrana@codeaurora.org>
      Signed-off-by: default avatarJack Pham <jackp@codeaurora.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
  6. 11 Feb, 2018 1 commit
    • Linus Torvalds's avatar
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds authored
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
      with de-mangling cleanups yet to come.
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      The next patch from Al will sort out the final differences, and we
      should be all done.
      Scripted-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  7. 09 Jan, 2018 1 commit
    • Hemant Kumar's avatar
      usb: f_fs: Prevent gadget unbind if it is already unbound · ce5bf9a5
      Hemant Kumar authored
      Upon usb composition switch there is possibility of ep0 file
      release happening after gadget driver bind. In case of composition
      switch from adb to a non-adb composition gadget will never gets
      bound again resulting into failure of usb device enumeration. Fix
      this issue by checking FFS_FL_BOUND flag and avoid extra
      gadget driver unbind if it is already done as part of composition
      This fixes adb reconnection error reported on Android running
      v4.4 and above kernel versions. Verified on Hikey running vanilla
      v4.15-rc7 + few out of tree Mali patches.
      Reviewed-at: https://android-review.googlesource.com/#/c/582632/
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Greg KH <gregkh@linux-foundation.org>
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Dmitry Shmidt <dimitrysh@google.com>
      Cc: Badhri <badhri@google.com>
      Cc: Android Kernel Team <kernel-team@android.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHemant Kumar <hemantk@codeaurora.org>
      [AmitP: Cherry-picked it from android-4.14 and updated the commit log]
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. 11 Dec, 2017 1 commit
    • Vincent Pelletier's avatar
      usb: gadget: ffs: Make sparse happier · c40619bb
      Vincent Pelletier authored
      Silences the following warnings:
      drivers/usb/gadget/function/f_fs.c:1253:37: warning: incorrect type in argument 1 (different address spaces)
      drivers/usb/gadget/function/f_fs.c:1253:37:    expected void [noderef] <asn:1>*to
      drivers/usb/gadget/function/f_fs.c:1253:37:    got void *<noident>
      drivers/usb/gadget/function/f_fs.c:2322:23: warning: cast to restricted __le32
      drivers/usb/gadget/function/f_fs.c:2876:38: warning: cast to restricted __le32
      drivers/usb/gadget/function/f_fs.c:272:12: warning: context imbalance in '__ffs_ep0_queue_wait' - unexpected unlock
      drivers/usb/gadget/function/f_fs.c:450:17: warning: context imbalance in 'ffs_ep0_write' - different lock contexts for basic block
      drivers/usb/gadget/function/f_fs.c:490:24: warning: context imbalance in '__ffs_ep0_read_events' - unexpected unlock
      drivers/usb/gadget/function/f_fs.c:496:16: warning: context imbalance in 'ffs_ep0_read' - different lock contexts for basic block
      Also, add an "unlocks spinlock" comment for consistency with existing ones.
      No behaviour change is intended.
      Signed-off-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
  9. 28 Nov, 2017 2 commits
    • Al Viro's avatar
    • John Keeping's avatar
      usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT · a3acc696
      John Keeping authored
      The specification says that the Reserved1 field in OS_DESC_EXT_COMPAT
      must have the value "1", but when this feature was first implemented we
      rejected any non-zero values.
      This was adjusted to accept all non-zero values (while now rejecting
      zero) in commit 53642399 ("usb: gadget: f_fs: Fix wrong check on
      reserved1 of OS_DESC_EXT_COMPAT"), but that breaks any userspace
      programs that worked previously by returning EINVAL when Reserved1 == 0
      which was previously the only value that succeeded!
      If we just set the field to "1" ourselves, both old and new userspace
      programs continue to work correctly and, as a bonus, old programs are
      now compliant with the specification without having to fix anything
      Fixes: 53642399
       ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJohn Keeping <john@metanate.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
  10. 27 Nov, 2017 1 commit
    • Vincent Pelletier's avatar
      usb: gadget: ffs: Forbid usb_ep_alloc_request from sleeping · 30bf90cc
      Vincent Pelletier authored
      Found using DEBUG_ATOMIC_SLEEP while submitting an AIO read operation:
      [  100.853642] BUG: sleeping function called from invalid context at mm/slab.h:421
      [  100.861148] in_atomic(): 1, irqs_disabled(): 1, pid: 1880, name: python
      [  100.867954] 2 locks held by python/1880:
      [  100.867961]  #0:  (&epfile->mutex){....}, at: [<f8188627>] ffs_mutex_lock+0x27/0x30 [usb_f_fs]
      [  100.868020]  #1:  (&(&ffs->eps_lock)->rlock){....}, at: [<f818ad4b>] ffs_epfile_io.isra.17+0x24b/0x590 [usb_f_fs]
      [  100.868076] CPU: 1 PID: 1880 Comm: python Not tainted 4.14.0-edison+ #118
      [  100.868085] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48
      [  100.868093] Call Trace:
      [  100.868122]  dump_stack+0x47/0x62
      [  100.868156]  ___might_sleep+0xfd/0x110
      [  100.868182]  __might_sleep+0x68/0x70
      [  100.868217]  kmem_cache_alloc_trace+0x4b/0x200
      [  100.868248]  ? dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3]
      [  100.868302]  dwc3_gadget_ep_alloc_request+0x24/0xe0 [dwc3]
      [  100.868343]  usb_ep_alloc_request+0x16/0xc0 [udc_core]
      [  100.868386]  ffs_epfile_io.isra.17+0x444/0x590 [usb_f_fs]
      [  100.868424]  ? _raw_spin_unlock_irqrestore+0x27/0x40
      [  100.868457]  ? kiocb_set_cancel_fn+0x57/0x60
      [  100.868477]  ? ffs_ep0_poll+0xc0/0xc0 [usb_f_fs]
      [  100.868512]  ffs_epfile_read_iter+0xfe/0x157 [usb_f_fs]
      [  100.868551]  ? security_file_permission+0x9c/0xd0
      [  100.868587]  ? rw_verify_area+0xac/0x120
      [  100.868633]  aio_read+0x9d/0x100
      [  100.868692]  ? __fget+0xa2/0xd0
      [  100.868727]  ? __might_sleep+0x68/0x70
      [  100.868763]  SyS_io_submit+0x471/0x680
      [  100.868878]  do_int80_syscall_32+0x4e/0xd0
      [  100.868921]  entry_INT80_32+0x2a/0x2a
      [  100.868932] EIP: 0xb7fbb676
      [  100.868941] EFLAGS: 00000292 CPU: 1
      [  100.868951] EAX: ffffffda EBX: b7aa2000 ECX: 00000002 EDX: b7af8368
      [  100.868961] ESI: b7fbb660 EDI: b7aab000 EBP: bfb6c658 ESP: bfb6c638
      [  100.868973]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
      Signed-off-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
  11. 09 Nov, 2017 1 commit
    • Andrew Gabbasov's avatar
      usb: gadget: f_fs: Fix use-after-free in ffs_free_inst · cdafb6d8
      Andrew Gabbasov authored
      KASAN enabled configuration reports an error
      BUG: KASAN: use-after-free in ffs_free_inst+... [usb_f_fs] at addr ...
      Write of size 8 by task ...
      This is observed after "ffs-test" is run and interrupted. If after that
      functionfs is unmounted and g_ffs module is unloaded, that use-after-free
      occurs during g_ffs module removal.
      Although the report indicates ffs_free_inst() function, the actual
      use-after-free condition occurs in _ffs_free_dev() function, which
      is probably inlined into ffs_free_inst().
      This happens due to keeping the ffs_data reference in device structure
      during functionfs unmounting, while ffs_data itself is freed as no longer
      needed. The fix is to clear that reference in ffs_closed() function,
      which is a counterpart of ffs_ready(), where the reference is stored.
      Fixes: 3262ad82
       ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Acked-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. 07 Nov, 2017 1 commit
  13. 04 Nov, 2017 1 commit
  14. 19 Oct, 2017 1 commit
  15. 28 Sep, 2017 1 commit
    • John Keeping's avatar
      usb: gadget: ffs: handle I/O completion in-order · addfc582
      John Keeping authored
      By submitting completed transfers to the system workqueue there is no
      guarantee that completion events will be queued up in the correct order,
      as in multi-processor systems there is a thread running for each
      processor and the work items are not bound to a particular core.
      This means that several completions are in the queue at the same time,
      they may be processed in parallel and complete out of order, resulting
      in data appearing corrupt when read by userspace.
      Create a single-threaded workqueue for FunctionFS so that data completed
      requests is passed to userspace in the order in which they complete.
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarJohn Keeping <john@metanate.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
  16. 15 Aug, 2017 1 commit
  17. 02 Jun, 2017 2 commits
  18. 16 May, 2017 1 commit
    • William Wu's avatar
      usb: gadget: f_fs: avoid out of bounds access on comp_desc · b7f73850
      William Wu authored
      Companion descriptor is only used for SuperSpeed endpoints,
      if the endpoints are HighSpeed or FullSpeed, the Companion
      descriptor will not allocated, so we can only access it if
      gadget is SuperSpeed.
      I can reproduce this issue on Rockchip platform rk3368 SoC
      which supports USB 2.0, and use functionfs for ADB. Kernel
      build with CONFIG_KASAN=y and CONFIG_SLUB_DEBUG=y report
      the following BUG:
      BUG: KASAN: slab-out-of-bounds in ffs_func_set_alt+0x224/0x3a0 at addr ffffffc0601f6509
      Read of size 1 by task swapper/0/0
      BUG kmalloc-256 (Not tainted): kasan: bad access detected
      Disabling lock debugging due to kernel taint
      INFO: Allocated in ffs_func_bind+0x52c/0x99c age=1275 cpu=0 pid=1
      INFO: Freed in inode_doinit_with_dentry+0x3f0/0x7c4 age=1275 cpu=7 pid=247
      Call trace:
      [<ffffff900808aab4>] dump_backtrace+0x0/0x230
      [<ffffff900808acf8>] show_stack+0x14/0x1c
      [<ffffff90084ad420>] dump_stack+0xa0/0xc8
      [<ffffff90082157cc>] print_trailer+0x188/0x198
      [<ffffff9008215948>] object_err+0x3c/0x4c
      [<ffffff900821b5ac>] kasan_report+0x324/0x4dc
      [<ffffff900821aa38>] __asan_load1+0x24/0x50
      [<ffffff90089eb750>] ffs_func_set_alt+0x224/0x3a0
      [<ffffff90089d3760>] composite_setup+0xdcc/0x1ac8
      [<ffffff90089d7394>] android_setup+0x124/0x1a0
      [<ffffff90089acd18>] _setup+0x54/0x74
      [<ffffff90089b6b98>] handle_ep0+0x3288/0x4390
      [<ffffff90089b9b44>] dwc_otg_pcd_handle_out_ep_intr+0x14dc/0x2ae4
      [<ffffff90089be85c>] dwc_otg_pcd_handle_intr+0x1ec/0x298
      [<ffffff90089ad680>] dwc_otg_pcd_irq+0x10/0x20
      [<ffffff9008116328>] handle_irq_event_percpu+0x124/0x3ac
      [<ffffff9008116610>] handle_irq_event+0x60/0xa0
      [<ffffff900811af30>] handle_fasteoi_irq+0x10c/0x1d4
      [<ffffff9008115568>] generic_handle_irq+0x30/0x40
      [<ffffff90081159b4>] __handle_domain_irq+0xac/0xdc
      [<ffffff9008080e9c>] gic_handle_irq+0x64/0xa4
      Memory state around the buggy address:
        ffffffc0601f6400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        ffffffc0601f6480: 00 00 00 00 00 00 00 00 00 00 06 fc fc fc fc fc
       >ffffffc0601f6500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffffffc0601f6580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffffffc0601f6600: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
      Signed-off-by: default avatarWilliam Wu <william.wu@rock-chips.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
  19. 11 Apr, 2017 1 commit
    • Michal Nazarewicz's avatar
      usb: gadget: f_fs: simplify ffs_dev name handling · ea920bb4
      Michal Nazarewicz authored
      Currently ffs_dev::name can be either allocated by the client of
      the ffs_dev structure or by the f_fs.c core itself.  The former
      is used by g_ffs while the latter happens with configfs.
      Historically, g_ffs did not need to allocate separate buffer for
      the name so what is now f_fs.c core never cared about freeing
      that space.  With configfs the name needs to be copied since the
      memory is not guaranteed to be availeble after ffs_set_inst_name
      The complication is therefore here to avoid allocations in the
      g_ffs case but it complicates the code inproportinally to
      benefits it provides.  In particular, g_ffs is considered
      ‘legacy’ so optimising for its sake is unlikely to be worth the
      With that observation in mind, simplify the code by unifying the
      code paths in g_ffs and configfs paths.  Furthermore, instead of
      allocating a new buffer for the name, simply embed it in the
      ffs_dev structure.  This further makes the memory management
      less convoluted and error-prone.
      The configfs interface for functionfs imposed a limit of 40
      characters for the name so this results in a 41-byte buffer
      added to the structure.  (For short names this may lead to
      wasted memory but the actual amount is not immediately obvious
      and depends on pointer size and which slab buckets the structure
      and name would fall into).
      Signed-off-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
  20. 17 Mar, 2017 1 commit
  21. 06 Mar, 2017 2 commits
  22. 02 Mar, 2017 1 commit
  23. 25 Jan, 2017 1 commit
  24. 24 Jan, 2017 2 commits
  25. 14 Jan, 2017 1 commit
    • Peter Zijlstra's avatar
      locking/atomic, kref: Add kref_read() · 2c935bc5
      Peter Zijlstra authored
      Since we need to change the implementation, stop exposing internals.
      Provide kref_read() to read the current reference count; typically
      used for debug messages.
      Kills two anti-patterns:
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  26. 12 Jan, 2017 1 commit
  27. 02 Jan, 2017 3 commits
    • Baolin Wang's avatar
      usb: gadget: f_fs: Fix possibe deadlock · b3ce3ce0
      Baolin Wang authored
      When system try to close /dev/usb-ffs/adb/ep0 on one core, at the same
      time another core try to attach new UDC, which will cause deadlock as
      below scenario. Thus we should release ffs lock before issuing
      [   52.642225] c1 ======================================================
      [   52.642228] c1 [ INFO: possible circular locking dependency detected ]
      [   52.642236] c1 4.4.6+ #1 Tainted: G        W  O
      [   52.642241] c1 -------------------------------------------------------
      [   52.642245] c1 usb ffs open/2808 is trying to acquire lock:
      [   52.642270] c0  (udc_lock){+.+.+.}, at: [<ffffffc00065aeec>]
      [   52.642272] c1  but task is already holding lock:
      [   52.642283] c0  (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>]
      [   52.642285] c1 which lock already depends on the new lock.
      [   52.642287] c1
                     the existing dependency chain (in reverse order) is:
      [   52.642295] c0
      	       -> #1 (ffs_lock){+.+.+.}:
      [   52.642307] c0        [<ffffffc00012340c>] __lock_acquire+0x20f0/0x2238
      [   52.642314] c0        [<ffffffc000123b54>] lock_acquire+0xe4/0x298
      [   52.642322] c0        [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
      [   52.642328] c0        [<ffffffc00066f7bc>] ffs_func_bind+0x504/0x6e8
      [   52.642334] c0        [<ffffffc000654004>] usb_add_function+0x84/0x184
      [   52.642340] c0        [<ffffffc000658ca4>] configfs_composite_bind+0x264/0x39c
      [   52.642346] c0        [<ffffffc00065b348>] udc_bind_to_driver+0x58/0x11c
      [   52.642352] c0        [<ffffffc00065b49c>] usb_udc_attach_driver+0x90/0xc8
      [   52.642358] c0        [<ffffffc0006598e0>] gadget_dev_desc_UDC_store+0xd4/0x128
      [   52.642369] c0        [<ffffffc0002c14e8>] configfs_write_file+0xd0/0x13c
      [   52.642376] c0        [<ffffffc00023c054>] vfs_write+0xb8/0x214
      [   52.642381] c0        [<ffffffc00023cad4>] SyS_write+0x54/0xb0
      [   52.642388] c0        [<ffffffc000085ff0>] el0_svc_naked+0x24/0x28
      [   52.642395] c0
                    -> #0 (udc_lock){+.+.+.}:
      [   52.642401] c0        [<ffffffc00011e3d0>] print_circular_bug+0x84/0x2e4
      [   52.642407] c0        [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
      [   52.642412] c0        [<ffffffc000123b54>] lock_acquire+0xe4/0x298
      [   52.642420] c0        [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
      [   52.642427] c0        [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
      [   52.642432] c0        [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
      [   52.642439] c0        [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
      [   52.642444] c0        [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
      [   52.642450] c0        [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
      [   52.642454] c0        [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
      [   52.642460] c0        [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
      [   52.642466] c0        [<ffffffc00023dd9c>] ____fput+0x20/0x2c
      [   52.642473] c0        [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
      [   52.642482] c0        [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
      [   52.642487] c0        [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
      [   52.642494] c0        [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
      [   52.642501] c0        [<ffffffc00008a8f0>] do_signal+0x154/0x518
      [   52.642507] c0        [<ffffffc00008af00>] do_notify_resume+0x70/0x78
      [   52.642512] c0        [<ffffffc000085ee8>] work_pending+0x1c/0x20
      [   52.642514] c1
                    other info that might help us debug this:
      [   52.642517] c1  Possible unsafe locking scenario:
      [   52.642518] c1        CPU0                    CPU1
      [   52.642520] c1        ----                    ----
      [   52.642525] c0   lock(ffs_lock);
      [   52.642529] c0                                lock(udc_lock);
      [   52.642533] c0                                lock(ffs_lock);
      [   52.642537] c0   lock(udc_lock);
      [   52.642539] c1
                            *** DEADLOCK ***
      [   52.642543] c1 1 lock held by usb ffs open/2808:
      [   52.642555] c0  #0:  (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>]
      [   52.642557] c1 stack backtrace:
      [   52.642563] c1 CPU: 1 PID: 2808 Comm: usb ffs open Tainted: G
      [   52.642565] c1 Hardware name: Spreadtrum SP9860g Board (DT)
      [   52.642568] c1 Call trace:
      [   52.642573] c1 [<ffffffc00008b430>] dump_backtrace+0x0/0x170
      [   52.642577] c1 [<ffffffc00008b5c0>] show_stack+0x20/0x28
      [   52.642583] c1 [<ffffffc000422694>] dump_stack+0xa8/0xe0
      [   52.642587] c1 [<ffffffc00011e548>] print_circular_bug+0x1fc/0x2e4
      [   52.642591] c1 [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
      [   52.642595] c1 [<ffffffc000123b54>] lock_acquire+0xe4/0x298
      [   52.642599] c1 [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
      [   52.642604] c1 [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
      [   52.642608] c1 [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
      [   52.642613] c1 [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
      [   52.642618] c1 [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
      [   52.642621] c1 [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
      [   52.642625] c1 [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
      [   52.642629] c1 [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
      [   52.642633] c1 [<ffffffc00023dd9c>] ____fput+0x20/0x2c
      [   52.642636] c1 [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
      [   52.642640] c1 [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
      [   52.642644] c1 [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
      [   52.642647] c1 [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
      [   52.642651] c1 [<ffffffc00008a8f0>] do_signal+0x154/0x518
      [   52.642656] c1 [<ffffffc00008af00>] do_notify_resume+0x70/0x78
      [   52.642659] c1 [<ffffffc000085ee8>] work_pending+0x1c/0x20
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
    • Vincent Pelletier's avatar
      usb: gadget: f_fs: Fix ExtCompat descriptor validation · 354bc45b
      Vincent Pelletier authored
      Reserved1 is documented as expected to be set to 0, but this test fails
      when it it set to 0. Reverse the condition.
      Signed-off-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
    • Vincent Pelletier's avatar
      usb: gadget: f_fs: Document eventfd effect on descriptor format. · 96a420d2
      Vincent Pelletier authored
      When FUNCTIONFS_EVENTFD flag is set, __ffs_data_got_descs reads a 32bits,
      little-endian value right after the fixed structure header, and passes it
      to eventfd_ctx_fdget. Document this.
      Also, rephrase a comment to be affirmative about the role of string
      descriptor at index 0. Ref: USB 2.0 spec paragraph "9.6.7 String", and
      also checked to still be current in USB 3.0 spec paragraph "9.6.9 String".
      Signed-off-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
  28. 05 Dec, 2016 1 commit
    • Al Viro's avatar
      [iov_iter] new primitives - copy_from_iter_full() and friends · cbbd26b8
      Al Viro authored
      copy_from_iter_full(), copy_from_iter_full_nocache() and
      csum_and_copy_from_iter_full() - counterparts of copy_from_iter()
      et.al., advancing iterator only in case of successful full copy
      and returning whether it had been successful or not.
      Convert some obvious users.  *NOTE* - do not blindly assume that
      something is a good candidate for those unless you are sure that
      not advancing iov_iter in failure case is the right thing in
      this case.  Anything that does short read/short write kind of
      stuff (or is in a loop, etc.) is unlikely to be a good one.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  29. 18 Nov, 2016 1 commit
  30. 03 Nov, 2016 1 commit
  31. 17 Oct, 2016 2 commits