1. 26 5月, 2015 1 次提交
    • N
      irda: use msecs_to_jiffies for conversion to jiffies · 005e8709
      Nicholas Mc Guire 提交于
      API compliance scanning with coccinelle flagged:
      ./net/irda/timer.c:63:35-37: use of msecs_to_jiffies probably perferable
      
      Converting milliseconds to jiffies by "val * HZ / 1000" technically
      is not a clean solution as it does not handle all corner cases correctly.
      By changing the conversion to use msecs_to_jiffies(val) conversion is
      correct in all cases. Further the () around the arithmetic expression
      was dropped.
      
      Patch was compile tested for x86_64_defconfig + CONFIG_IRDA=m
      
      Patch is against 4.1-rc4 (localversion-next is -next-20150522)
      Signed-off-by: NNicholas Mc Guire <hofrat@osadl.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      005e8709
  2. 11 5月, 2015 1 次提交
  3. 07 3月, 2015 1 次提交
  4. 03 3月, 2015 1 次提交
  5. 24 2月, 2015 1 次提交
  6. 31 1月, 2015 1 次提交
  7. 11 12月, 2014 1 次提交
  8. 24 11月, 2014 2 次提交
  9. 13 11月, 2014 2 次提交
  10. 12 11月, 2014 1 次提交
  11. 06 11月, 2014 1 次提交
    • D
      net: Add and use skb_copy_datagram_msg() helper. · 51f3d02b
      David S. Miller 提交于
      This encapsulates all of the skb_copy_datagram_iovec() callers
      with call argument signature "skb, offset, msghdr->msg_iov, length".
      
      When we move to iov_iters in the networking, the iov_iter object will
      sit in the msghdr.
      
      Having a helper like this means there will be less places to touch
      during that transformation.
      
      Based upon descriptions and patch from Al Viro.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      51f3d02b
  12. 03 11月, 2014 1 次提交
  13. 01 10月, 2014 1 次提交
  14. 14 8月, 2014 1 次提交
  15. 16 7月, 2014 2 次提交
  16. 11 7月, 2014 1 次提交
    • P
      tty: Remove tty_hung_up_p() tests from tty drivers' open() · e359a4e3
      Peter Hurley 提交于
      Since at least before 2.6.30, it has not been possible to observe
      a hung up file pointer in a tty driver's open() method unless/until
      the driver open() releases the tty_lock() (eg., before blocking).
      
      This is because tty_open() adds the file pointer while holding
      the tty_lock() _and_ doesn't release the lock until after calling
      the tty driver's open() method. [ Before tty_lock(), this was
      lock_kernel(). ]
      
      Since __tty_hangup() first waits on the tty_lock() before
      enumerating and hanging up the open file pointers, either
      __tty_hangup() will wait for the tty_lock() or tty_open() will
      not yet have added the file pointer. For example,
      
      CPU 0                          |  CPU 1
                                     |
      tty_open                       |  __tty_hangup
        ..                           |    ..
        tty_lock                     |    ..
        tty_reopen                   |    tty_lock  / blocks
        ..                           |
        tty_add_file(tty, filp)      |
        ..                           |
        tty->ops->open(tty, filp)    |
          tty_port_open              |
            tty_port_block_til_ready |
              ..                     |
              while (1)              |
                ..                   |
                tty_unlock           |    / unblocks
                schedule             |    for each filp on tty->tty_files
                                     |      f_ops = tty_hung_up_fops;
                                     |    ..
                                     |    tty_unlock
                tty_lock             |
        ..                           |
        tty_unlock                   |
      
      Note that since tty_port_block_til_ready() and similar drop
      the tty_lock while blocking, when woken, the file pointer
      must then be tested for having been hung up.
      
      Also, fix bit-rotted drivers that used extra_count to track the
      port->count bump.
      
      CC: Mikael Starvik <starvik@axis.com>
      CC: Samuel Ortiz <samuel@sortiz.org>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e359a4e3
  17. 24 6月, 2014 1 次提交
  18. 19 1月, 2014 1 次提交
  19. 07 12月, 2013 1 次提交
  20. 21 11月, 2013 1 次提交
    • H
      net: rework recvmsg handler msg_name and msg_namelen logic · f3d33426
      Hannes Frederic Sowa 提交于
      This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
      set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
      to return msg_name to the user.
      
      This prevents numerous uninitialized memory leaks we had in the
      recvmsg handlers and makes it harder for new code to accidentally leak
      uninitialized memory.
      
      Optimize for the case recvfrom is called with NULL as address. We don't
      need to copy the address at all, so set it to NULL before invoking the
      recvmsg handler. We can do so, because all the recvmsg handlers must
      cope with the case a plain read() is called on them. read() also sets
      msg_name to NULL.
      
      Also document these changes in include/linux/net.h as suggested by David
      Miller.
      
      Changes since RFC:
      
      Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
      non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
      affect sendto as it would bail out earlier while trying to copy-in the
      address. It also more naturally reflects the logic by the callers of
      verify_iovec.
      
      With this change in place I could remove "
      if (!uaddr || msg_sys->msg_namelen == 0)
      	msg->msg_name = NULL
      ".
      
      This change does not alter the user visible error logic as we ignore
      msg_namelen as long as msg_name is NULL.
      
      Also remove two unnecessary curly brackets in ___sys_recvmsg and change
      comments to netdev style.
      
      Cc: David Miller <davem@davemloft.net>
      Suggested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3d33426
  21. 20 11月, 2013 1 次提交
  22. 15 11月, 2013 1 次提交
  23. 20 10月, 2013 1 次提交
  24. 04 10月, 2013 1 次提交
  25. 20 7月, 2013 1 次提交
  26. 17 7月, 2013 1 次提交
  27. 13 6月, 2013 1 次提交
  28. 20 5月, 2013 1 次提交
    • C
      net: irda: using kzalloc() instead of kmalloc() to avoid strncpy() issue. · ff0102ee
      Chen Gang 提交于
      'discovery->data.info' length is 22, NICKNAME_MAX_LEN is 21, so the
      strncpy() will always left the last byte of 'discovery->data.info'
      uninitialized.
      
      When 'text' length is longer than 21 (NICKNAME_MAX_LEN), if still left
      the last byte of 'discovery->data.info' uninitialized, the next
      strlen() will cause issue.
      
      Also 'discovery->data' is 'struct irda_device_info' which defined in
      "include/uapi/...", it may copy to user mode, so need whole initialized.
      
      All together, need use kzalloc() instead of kmalloc() to initialize all
      members firstly.
      Signed-off-by: NChen Gang <gang.chen@asianux.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff0102ee
  29. 25 4月, 2013 1 次提交
  30. 20 4月, 2013 1 次提交
    • D
      irda: small read past the end of array in debug code · e15465e1
      Dan Carpenter 提交于
      The "reason" can come from skb->data[] and it hasn't been capped so it
      can be from 0-255 instead of just 0-6.  For example in irlmp_state_dtr()
      the code does:
      
      	reason = skb->data[3];
      	...
      	irlmp_disconnect_indication(self, reason, skb);
      
      Also LMREASON has a couple other values which don't have entries in the
      irlmp_reasons[] array.  And 0xff is a valid reason as well which means
      "unknown".
      
      So far as I can see we don't actually care about "reason" except for in
      the debug code.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e15465e1
  31. 13 4月, 2013 1 次提交
  32. 09 4月, 2013 3 次提交
  33. 08 4月, 2013 1 次提交
  34. 21 3月, 2013 1 次提交
  35. 19 3月, 2013 1 次提交
反馈
建议
客服 返回
顶部