1. 21 9月, 2016 3 次提交
    • P
      openvswitch: Fix Frame-size larger than 1024 bytes warning. · 190aa3e7
      pravin shelar 提交于
      There is no need to declare separate key on stack,
      we can just use sw_flow->key to store the key directly.
      
      This commit fixes following warning:
      
      net/openvswitch/datapath.c: In function ‘ovs_flow_cmd_new’:
      net/openvswitch/datapath.c:1080:1: warning: the frame size of 1040 bytes
      is larger than 1024 bytes [-Wframe-larger-than=]
      Signed-off-by: NPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      190aa3e7
    • D
      Merge branch 'for-upstream' of... · 204dfe17
      David S. Miller 提交于
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
      
      Johan Hedberg says:
      
      ====================
      pull request: bluetooth-next 2016-09-19
      
      Here's the main bluetooth-next pull request for the 4.9 kernel.
      
       - Added new messages for monitor sockets for better mgmt tracing
       - Added local name and appearance support in scan response
       - Added new Qualcomm WCNSS SMD based HCI driver
       - Minor fixes & cleanup to 802.15.4 code
       - New USB ID to btusb driver
       - Added Marvell support to HCI UART driver
       - Add combined LED trigger for controller power
       - Other minor fixes here and there
      
      Please let me know if there are any issues pulling. Thanks.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      204dfe17
    • A
      6pack: fix buffer length mishandling · ad979896
      Alan Cox 提交于
      Dmitry Vyukov wrote:
      > different runs). Looking at code, the following looks suspicious -- we
      > limit copy by 512 bytes, but use the original count which can be
      > larger than 512:
      >
      > static void sixpack_receive_buf(struct tty_struct *tty,
      >     const unsigned char *cp, char *fp, int count)
      > {
      >     unsigned char buf[512];
      >     ....
      >     memcpy(buf, cp, count < sizeof(buf) ? count : sizeof(buf));
      >     ....
      >     sixpack_decode(sp, buf, count1);
      
      With the sane tty locking we now have I believe the following is safe as
      we consume the bytes and move them into the decoded buffer before
      returning.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad979896
  2. 20 9月, 2016 37 次提交