1. 23 May, 2017 5 commits
    • Lin Zhang's avatar
      net: ieee802154: fix net_device reference release too early · a611c58b
      Lin Zhang authored
      This patch fixes the kernel oops when release net_device reference in
      advance. In function raw_sendmsg(i think the dgram_sendmsg has the same
      problem), there is a race condition between dev_put and dev_queue_xmit
      when the device is gong that maybe lead to dev_queue_ximt to see
      an illegal net_device pointer.
      
      My test kernel is 3.13.0-32 and because i am not have a real 802154
      device, so i change lowpan_newlink function to this:
      
              /* find and hold real wpan device */
              real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
              if (!real_dev)
                      return -ENODEV;
      //      if (real_dev->type != ARPHRD_IEEE802154) {
      //              dev_put(real_dev);
      //              return -EINVAL;
      //      }
              lowpan_dev_info(dev)->real_dev = real_dev;
              lowpan_dev_info(dev)->fragment_tag = 0;
              mutex_init(&lowpan_dev_info(dev)->dev_list_mtx);
      
      Also, in order to simulate preempt, i change the raw_sendmsg function
      to this:
      
              skb->dev = dev;
              skb->sk  = sk;
              skb->protocol = htons(ETH_P_IEEE802154);
              dev_put(dev);
              //simulate preempt
              schedule_timeout_uninterruptible(30 * HZ);
              err = dev_queue_xmit(skb);
              if (err > 0)
                      err = net_xmit_errno(err);
      
      and this is my userspace test code named test_send_data:
      
      int main(int argc, char **argv)
      {
              char buf[127];
              int sockfd;
              sockfd = socket(AF_IEEE802154, SOCK_RAW, 0);
              if (sockfd < 0) {
                      printf("create sockfd error: %s\n", strerror(errno));
                      return -1;
              }
              send(sockfd, buf, sizeof(buf), 0);
              return 0;
      }
      
      This is my test case:
      
      root@zhanglin-x-computer:~/develop/802154# uname -a
      Linux zhanglin-x-computer 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15
      03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
      root@zhanglin-x-computer:~/develop/802154# ip link add link eth0 name
      lowpan0 type lowpan
      root@zhanglin-x-computer:~/develop/802154#
      //keep the lowpan0 device down
      root@zhanglin-x-computer:~/develop/802154# ./test_send_data &
      //wait a while
      root@zhanglin-x-computer:~/develop/802154# ip link del link dev lowpan0
      //the device is gone
      //oops
      [381.303307] general protection fault: 0000 [#1]SMP
      [381.303407] Modules linked in: af_802154 6lowpan bnep rfcomm
      bluetooth nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
      rts5139(C) snd_hda_intel
      snd_had_codec snd_hwdep snd_pcm snd_page_alloc snd_seq_midi
      snd_seq_midi_event snd_rawmidi snd_req intel_rapl snd_seq_device
      coretemp i915 kvm_intel
      kvm snd_timer snd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
      cypted drm_kms_helper drm i2c_algo_bit soundcore video mac_hid
      parport_pc ppdev ip parport hid_generic
      usbhid hid ahci r8169 mii libahdi
      [381.304286] CPU:1 PID: 2524 Commm: 1 Tainted: G C 0 3.13.0-32-generic
      [381.304409] Hardware name: Haier Haier DT Computer/Haier DT Codputer,
      BIOS FIBT19H02_X64 06/09/2014
      [381.304546] tasks: ffff000096965fc0 ti: ffffB0013779c000 task.ti:
      ffffB8013779c000
      [381.304659] RIP: 0010:[<ffffffff01621fe1>] [<ffffffff81621fe1>]
      __dev_queue_ximt+0x61/0x500
      [381.304798] RSP: 0018:ffffB8013779dca0 EFLAGS: 00010202
      [381.304880] RAX: 272b031d57565351 RBX: 0000000000000000 RCX: ffff8800968f1a00
      [381.304987] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800968f1a00
      [381.305095] RBP: ffff8e013773dce0 R08: 0000000000000266 R09: 0000000000000004
      [381.305202] R10: 0000000000000004 R11: 0000000000000005 R12: ffff88013902e000
      [381.305310] R13: 000000000000007f R14: 000000000000007f R15: ffff8800968f1a00
      [381.305418] FS:  00007fc57f50f740(0000) GS: ffff88013fc80000(0000)
      knlGS: 0000000000000000
      [381.305540] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [381.305627] CR2: 00007fad0841c000 CR3: 00000001368dd000 CR4: 00000000001007e0
      [361.905734] Stack:
      [381.305768]  00000000002052d0 000000003facb30a ffff88013779dcc0
      ffff880137764000
      [381.305898]  ffff88013779de70 000000000000007f 000000000000007f
      ffff88013902e000
      [381.306026]  ffff88013779dcf0 ffffffff81622490 ffff88013779dd39
      ffffffffa03af9f1
      [381.306155] Call Trace:
      [381.306202]  [<ffffffff81622490>] dev_queue_xmit+0x10/0x20
      [381.306294]  [<ffffffffa03af9f1>] raw_sendmsg+0x1b1/0x270 [af_802154]
      [381.306396]  [<ffffffffa03af054>] ieee802154_sock_sendmsg+0x14/0x20 [af_802154]
      [381.306512]  [<ffffffff816079eb>] sock_sendmsg+0x8b/0xc0
      [381.306600]  [<ffffffff811d52a5>] ? __d_alloc+0x25/0x180
      [381.306687]  [<ffffffff811a1f56>] ? kmem_cache_alloc_trace+0x1c6/0x1f0
      [381.306791]  [<ffffffff81607b91>] SYSC_sendto+0x121/0x1c0
      [381.306878]  [<ffffffff8109ddf4>] ? vtime_account_user+x54/0x60
      [381.306975]  [<ffffffff81020d45>] ? syscall_trace_enter+0x145/0x250
      [381.307073]  [<ffffffff816086ae>] SyS_sendto+0xe/0x10
      [381.307156]  [<ffffffff8172c87f>] tracesys+0xe1/0xe6
      [381.307233] Code: c6 a1 a4 ff 41 8b 57 78 49 8b 47 20 85 d2 48 8b 80
      78 07 00 00 75 21 49 8b 57 18 48 85 d2 74 18 48 85 c0 74 13 8b 92 ac
      01 00 00 <3b> 50 10 73 08 8b 44 90 14 41 89 47 78 41 f6 84 24 d5 00 00
      00
      [381.307801] RIP [<ffffffff81621fe1>] _dev_queue_xmit+0x61/0x500
      [381.307901]  RSP <ffff88013779dca0>
      [381.347512] Kernel panic - not syncing: Fatal exception in interrupt
      [381.347747] drm_kms_helper: panic occurred, switching back to text console
      
      In my opinion, there is always exist a chance that the device is gong
      before call dev_queue_xmit.
      
      I think the latest kernel is have the same problem and that
      dev_put should be behind of the dev_queue_xmit.
      Signed-off-by: default avatarLin Zhang <xiaolou4617@gmail.com>
      Acked-by: default avatarStefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a611c58b
    • Lin Zhang's avatar
      net: ieee802154: remove explicit set skb->sk · 8fafda77
      Lin Zhang authored
      Explicit set skb->sk is needless, sock_alloc_send_skb is already set it.
      Signed-off-by: default avatarLin Zhang <xiaolou4617@gmail.com>
      Acked-by: default avatarStefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      8fafda77
    • Jürg Billeter's avatar
      Bluetooth: btintel: Add MODULE_FIRMWARE entries for iBT 3.5 controllers · d1b7abae
      Jürg Billeter authored
      The iBT 3.5 controllers (Intel 8265, Windstorm Peak) need
      intel/ibt-12-16.sfi and intel/ibt-12-16.ddc firmware files from
      linux-firmware repository.
      Signed-off-by: default avatarJürg Billeter <j@bitron.ch>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      d1b7abae
    • Loic Poulain's avatar
      Bluetooth: btwilink: Fix unexpected skb free · a6187ffd
      Loic Poulain authored
      The caller (hci_core) still owns the skb in case of error, releasing
      it inside the send function can lead to use-after-free errors.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarLoic Poulain <loic.poulain@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a6187ffd
    • Guodong Xu's avatar
      Bluetooth: hci_ll: Fix download_firmware() return when __hci_cmd_sync fails · 823b8420
      Guodong Xu authored
      When __hci_cmd_sync() fails, download_firmware() should also fail, and
      the same error value should be returned as PTR_ERR(skb).
      
      Without this fix, download_firmware() will return a success when it actually
      failed in __hci_cmd_sync().
      
      Fixes: 37180552 ("bluetooth: hci_uart: add LL protocol serdev driver support")
      Signed-off-by: default avatarGuodong Xu <guodong.xu@linaro.org>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      823b8420
  2. 22 May, 2017 3 commits
  3. 19 May, 2017 1 commit
  4. 18 May, 2017 9 commits
    • Tobias Regnery's avatar
      Bluetooth: hci_nokia: select BT_HCIUART_H4 · c42c88e6
      Tobias Regnery authored
      We see the following build failure with CONFIG_BT_HCIUART_NOKIA=y and
      CONFIG_BT_HCIUART_H4=n:
      
      drivers/bluetooth/hci_nokia.c: In function 'nokia_recv':
      drivers/bluetooth/hci_nokia.c:644:18: error: implicit declaration of function 'h4_recv_buf' [-Werror=implicit-function-declaration]
      ...
      
      Fix this by selecting the BT_HCIUART_H4 symbol like all the other users
      of the protocoll.
      
      Fixes: 7bb31868 ("Bluetooth: add nokia driver")
      Signed-off-by: default avatarTobias Regnery <tobias.regnery@gmail.com>
      Reviewed-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c42c88e6
    • Dean Jenkins's avatar
      Bluetooth: hci_ldisc: Use rwlocking to avoid closing proto races · dec2c928
      Dean Jenkins authored
      When HCI_UART_PROTO_READY is in the set state, the Data Link protocol
      layer (proto) is bound to the HCI UART driver. This state allows the
      registered proto function pointers to be used by the HCI UART driver.
      
      When unbinding (closing) the Data Link protocol layer, the proto
      function pointers much be prevented from being used immediately before
      running the proto close function pointer. Otherwise, there is a risk
      that a proto non-close function pointer is used during or after the
      proto close function pointer is used. The consequences are likely to
      be a kernel crash because the proto close function pointer will free
      resources used in the Data Link protocol layer.
      
      Therefore, add a reader writer lock (rwlock) solution to prevent the
      close proto function pointer from running by using write_lock_irqsave()
      whilst the other proto function pointers are protected using
      read_lock(). This means HCI_UART_PROTO_READY can safely be cleared
      in the knowledge that no proto function pointers are running.
      
      When flag HCI_UART_PROTO_READY is put into the clear state,
      proto close function pointer can safely be run. Note
      flag HCI_UART_PROTO_SET being in the set state prevents the proto
      open function pointer from being run so there is no race condition
      between proto open and close function pointers.
      Signed-off-by: default avatarDean Jenkins <Dean_Jenkins@mentor.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      dec2c928
    • Marcel Holtmann's avatar
      Bluetooth: Skip vendor diagnostic configuration for HCI User Channel · b56c7b25
      Marcel Holtmann authored
      When the HCI User Channel access is requested, then do not try to
      undermine it with vendor diagnostic configuration. The exclusive user
      is required to configure its own vendor diagnostic in that case and
      can not rely on the host stack support.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      b56c7b25
    • Tobias Regnery's avatar
      Bluetooth: hci_uart: fix kconfig dependency · 76c4969f
      Tobias Regnery authored
      We see the following link error with CONFIG_BT_HCIUART=y,
      CONFIG_BT_HCIUART_LL=y and CONFIG_SERIAL_DEV_BUS=m:
      
      drivers/built-in.o: In function 'll_close':
      supp.c:(.text+0x55add4): undefined reference to 'serdev_device_close'
      supp.c:(.text+0x55add4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_close'
      drivers/built-in.o: In function 'll_open':
      supp.c:(.text+0x55aed0): undefined reference to 'serdev_device_open'
      supp.c:(.text+0x55aed0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_open'
      drivers/built-in.o: In function `hci_ti_probe':
      supp.c:(.text+0x55b00c): undefined reference to 'hci_uart_register_device'
      supp.c:(.text+0x55b00c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'hci_uart_register_device'
      drivers/built-in.o: In function `ll_setup':
      supp.c:(.text+0x55b08c): undefined reference to 'serdev_device_set_flow_control'
      supp.c:(.text+0x55b08c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_set_flow_control'
      supp.c:(.text+0x55b324): undefined reference to 'serdev_device_set_baudrate'
      supp.c:(.text+0x55b324): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_set_baudrate'
      drivers/built-in.o: In function 'll_init':
      supp.c:(.init.text+0x1b508): undefined reference to '__serdev_device_driver_register'
      supp.c:(.init.text+0x1b508): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol '__serdev_device_driver_register'
      
      Fix this by dependig BT_HCIUART_LL on the BT_HCIUART_SERDEV symbol.
      This implies a dependency on BT_HCIUART and hci_ll.c is only compiled in
      if SERIAl_DEV_BUS is built in or SERIAL_DEV_BUS and BT_HCIUART are
      modules.
      
      Fixes: 37180552 ("bluetooth: hci_uart: add LL protocol serdev driver support")
      Signed-off-by: default avatarTobias Regnery <tobias.regnery@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      76c4969f
    • Marcel Holtmann's avatar
      Bluetooth: Set LE Default PHY preferences · de2ba303
      Marcel Holtmann authored
      If the LE Set Default PHY command is supported, the indicate to the
      controller that the host has no preferences for transmitter PHY or
      receiver PHY selection.
      
      Issuing this command gives the controller a clear indication that other
      PHY can be selected if available.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      de2ba303
    • Marcel Holtmann's avatar
      Bluetooth: Enable LE PHY Update Complete event · 27bbca44
      Marcel Holtmann authored
      If either LE Set Default PHY command or LE Set PHY commands is
      supported, then enable the LE PHY Update Complete event.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      27bbca44
    • Marcel Holtmann's avatar
      Bluetooth: Enable LE Channel Selection Algorithm event · 9756d33b
      Marcel Holtmann authored
      If the Channel Selection Algorithm #2 feature is supported, then enable
      the new LE Channel Selection Algorithm event.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      9756d33b
    • Marcel Holtmann's avatar
      Bluetooth: Set LE Suggested Default Data Length to maximum · 12204875
      Marcel Holtmann authored
      When LE Data Packet Length Extension is supported, then actually
      increase the suggested default data length to the maximum to enable
      higher througput.
      
      < HCI Command: LE Read Maximum Data Length (0x08|0x002f) plen 0
      > HCI Event: Command Complete (0x0e) plen 12
            LE Read Maximum Data Length (0x08|0x002f) ncmd 1
              Status: Success (0x00)
              Max TX octets: 251
              Max TX time: 2120
              Max RX octets: 251
              Max RX time: 2120
      
      < HCI Command: LE Read Suggested Default Data Length (0x08|0x0023) plen 0
      > HCI Event: Command Complete (0x0e) plen 8
            LE Read Suggested Default Data Length (0x08|0x0023) ncmd 1
              Status: Success (0x00)
              TX octets: 27
              TX time: 328
      
      < HCI Command: LE Write Suggested Default Data Length (0x08|0x0024) plen 4
              TX octets: 251
              TX time: 2120
      > HCI Event: Command Complete (0x0e) plen 4
            LE Write Suggested Default Data Length (0x08|0x0024) ncmd 1
              Status: Success (0x00)
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      12204875
    • Tedd Ho-Jeong An's avatar
      Bluetooth: Add support for Intel Bluetooth device 9460/9560 [8087:0aaa] · 86a6129a
      Tedd Ho-Jeong An authored
      This patch adds support for Intel Bluetooth device 9460/9560 also known
      as Jefferson Peak (JfP). The firmware downloading mechanism is same as
      previous generation. So include the new USB product identifier and
      whitelist the hardware variant.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#=  5 Spd=12   MxCh= 0
      D:  Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=8087 ProdID=0aaa Rev= 0.02
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
      
      Bootloader version:
      < HCI Command: Intel Read Version (0x3f|0x0005) plen 0
      > HCI Event: Command Complete (0x0e) plen 13
            Intel Read Version (0x3f|0x0005) ncmd 32
              Status: Success (0x00)
              Hardware platform: 0x37
              Hardware variant: 0x11
              Hardware revision: 0.0
              Firmware variant: 0x06
              Firmware revision: 0.1
              Firmware build: 42-52.2015
              Firmware patch: 0
      Signed-off-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      86a6129a
  5. 17 May, 2017 22 commits