1. 07 7月, 2018 1 次提交
    • J
      Bluetooth: Use extended scanning if controller supports · a2344b9e
      Jaganath Kanakkassery 提交于
      This implements Set extended scan param and set extended scan enable
      commands and use it for start LE scan based on controller support.
      
      The new features added in these commands are setting of new PHY for
      scanning and setting of scan duration. Both features are disabled
      for now, meaning only 1M PHY is set and scan duration is set to 0
      which means that scanning will be done untill scan disable is called.
      
      < HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 8
              Own address type: Random (0x01)
              Filter policy: Accept all advertisement (0x00)
              PHYs: 0x01
              Entry 0: LE 1M
                Type: Active (0x01)
                Interval: 11.250 msec (0x0012)
                Window: 11.250 msec (0x0012)
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Scan Parameters (0x08|0x0041) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Set Extended Scan Enable (0x08|0x0042) plen 6
              Extended scan: Enabled (0x01)
              Filter duplicates: Enabled (0x01)
              Duration: 0 msec (0x0000)
              Period: 0.00 sec (0x0000)
      > HCI Event: Command Complete (0x0e) plen 4
            LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
              Status: Success (0x00)
      Signed-off-by: NJaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a2344b9e
  2. 06 7月, 2018 4 次提交
    • C
      Bluetooth: remove unused bt-nokia-h4p.h header · 1b0707a7
      Corentin Labbe 提交于
      Nothing in tree use this header which seems a remains of a staging
      driver.
      This patch remove it.
      Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
      Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      1b0707a7
    • A
      Bluetooth: Add HCI command for clear Resolv list · 545f2596
      Ankit Navik 提交于
      Check for Resolv list supported by controller. So check the supported
      commmand first before issuing this command i.e.,HCI_OP_LE_CLEAR_RESOLV_LIST
      
      Before patch:
      < HCI Command: LE Read White List... (0x08|0x000f) plen 0  #55 [hci0] 13.338168
      > HCI Event: Command Complete (0x0e) plen 5                #56 [hci0] 13.338842
            LE Read White List Size (0x08|0x000f) ncmd 1
              Status: Success (0x00)
              Size: 25
      < HCI Command: LE Clear White List (0x08|0x0010) plen 0    #57 [hci0] 13.339029
      > HCI Event: Command Complete (0x0e) plen 4                #58 [hci0] 13.339939
            LE Clear White List (0x08|0x0010) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Read Resolving L.. (0x08|0x002a) plen 0  #59 [hci0] 13.340152
      > HCI Event: Command Complete (0x0e) plen 5                #60 [hci0] 13.340952
            LE Read Resolving List Size (0x08|0x002a) ncmd 1
              Status: Success (0x00)
              Size: 25
      < HCI Command: LE Read Maximum Dat.. (0x08|0x002f) plen 0  #61 [hci0] 13.341180
      > HCI Event: Command Complete (0x0e) plen 12               #62 [hci0] 13.341898
            LE Read Maximum Data Length (0x08|0x002f) ncmd 1
              Status: Success (0x00)
              Max TX octets: 251
              Max TX time: 17040
              Max RX octets: 251
              Max RX time: 17040
      
      After patch:
      < HCI Command: LE Read White List... (0x08|0x000f) plen 0  #55 [hci0] 28.919131
      > HCI Event: Command Complete (0x0e) plen 5                #56 [hci0] 28.920016
            LE Read White List Size (0x08|0x000f) ncmd 1
              Status: Success (0x00)
              Size: 25
      < HCI Command: LE Clear White List (0x08|0x0010) plen 0    #57 [hci0] 28.920164
      > HCI Event: Command Complete (0x0e) plen 4                #58 [hci0] 28.920873
            LE Clear White List (0x08|0x0010) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Read Resolving L.. (0x08|0x002a) plen 0  #59 [hci0] 28.921109
      > HCI Event: Command Complete (0x0e) plen 5                #60 [hci0] 28.922016
            LE Read Resolving List Size (0x08|0x002a) ncmd 1
              Status: Success (0x00)
              Size: 25
      < HCI Command: LE Clear Resolving... (0x08|0x0029) plen 0  #61 [hci0] 28.922166
      > HCI Event: Command Complete (0x0e) plen 4                #62 [hci0] 28.922872
            LE Clear Resolving List (0x08|0x0029) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Read Maximum Dat.. (0x08|0x002f) plen 0  #63 [hci0] 28.923117
      > HCI Event: Command Complete (0x0e) plen 12               #64 [hci0] 28.924030
            LE Read Maximum Data Length (0x08|0x002f) ncmd 1
              Status: Success (0x00)
              Max TX octets: 251
              Max TX time: 17040
              Max RX octets: 251
              Max RX time: 17040
      Signed-off-by: NAnkit Navik <ankit.p.navik@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      545f2596
    • A
      Bluetooth: Store Resolv list size · cfdb0c2d
      Ankit Navik 提交于
      When the controller supports the Read LE Resolv List size feature, the
      maximum list size are read and now stored.
      
      Before patch:
      < HCI Command: LE Read White List... (0x08|0x000f) plen 0  #55 [hci0] 17.979791
      > HCI Event: Command Complete (0x0e) plen 5                #56 [hci0] 17.980629
            LE Read White List Size (0x08|0x000f) ncmd 1
              Status: Success (0x00)
              Size: 25
      < HCI Command: LE Clear White List (0x08|0x0010) plen 0    #57 [hci0] 17.980786
      > HCI Event: Command Complete (0x0e) plen 4                #58 [hci0] 17.981627
            LE Clear White List (0x08|0x0010) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Read Maximum Dat.. (0x08|0x002f) plen 0  #59 [hci0] 17.981786
      > HCI Event: Command Complete (0x0e) plen 12               #60 [hci0] 17.982636
            LE Read Maximum Data Length (0x08|0x002f) ncmd 1
              Status: Success (0x00)
              Max TX octets: 251
              Max TX time: 17040
              Max RX octets: 251
              Max RX time: 17040
      
      After patch:
      < HCI Command: LE Read White List... (0x08|0x000f) plen 0  #55 [hci0] 13.338168
      > HCI Event: Command Complete (0x0e) plen 5                #56 [hci0] 13.338842
            LE Read White List Size (0x08|0x000f) ncmd 1
              Status: Success (0x00)
              Size: 25
      < HCI Command: LE Clear White List (0x08|0x0010) plen 0    #57 [hci0] 13.339029
      > HCI Event: Command Complete (0x0e) plen 4                #58 [hci0] 13.339939
            LE Clear White List (0x08|0x0010) ncmd 1
              Status: Success (0x00)
      < HCI Command: LE Read Resolving L.. (0x08|0x002a) plen 0  #59 [hci0] 13.340152
      > HCI Event: Command Complete (0x0e) plen 5                #60 [hci0] 13.340952
            LE Read Resolving List Size (0x08|0x002a) ncmd 1
              Status: Success (0x00)
              Size: 25
      < HCI Command: LE Read Maximum Dat.. (0x08|0x002f) plen 0  #61 [hci0] 13.341180
      > HCI Event: Command Complete (0x0e) plen 12               #62 [hci0] 13.341898
            LE Read Maximum Data Length (0x08|0x002f) ncmd 1
              Status: Success (0x00)
              Max TX octets: 251
              Max TX time: 17040
              Max RX octets: 251
              Max RX time: 17040
      Signed-off-by: NAnkit Navik <ankit.p.navik@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      cfdb0c2d
    • E
      net: ipv6: listify ipv6_rcv() and ip6_rcv_finish() · d8269e2c
      Edward Cree 提交于
      Essentially the same as the ipv4 equivalents.
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d8269e2c
  3. 05 7月, 2018 8 次提交
  4. 04 7月, 2018 14 次提交
  5. 02 7月, 2018 6 次提交
  6. 30 6月, 2018 7 次提交
    • G
      tipc: extend sock diag for group communication · a1be5a20
      GhantaKrishnamurthy MohanKrishna 提交于
      This commit extends the existing TIPC socket diagnostics framework
      for information related to TIPC group communication.
      Acked-by: NYing Xue <ying.xue@windriver.com>
      Acked-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NGhantaKrishnamurthy MohanKrishna <mohan.krishna.ghanta.krishnamurthy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a1be5a20
    • H
      net/smc: add SMC-D diag support · 4b1b7d3b
      Hans Wippel 提交于
      This patch adds diag support for SMC-D.
      Signed-off-by: NHans Wippel <hwippel@linux.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.ibm.com>
      Suggested-by: NThomas Richter <tmricht@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4b1b7d3b
    • H
      net/smc: add pnetid support for SMC-D and ISM · 1619f770
      Hans Wippel 提交于
      SMC-D relies on PNETIDs to find usable SMC-D/ISM devices for a SMC
      connection. This patch adds SMC-D/ISM support to the current PNETID
      implementation.
      Signed-off-by: NHans Wippel <hwippel@linux.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.ibm.com>
      Suggested-by: NThomas Richter <tmricht@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1619f770
    • H
      net/smc: add base infrastructure for SMC-D and ISM · c6ba7c9b
      Hans Wippel 提交于
      SMC supports two variants: SMC-R and SMC-D. For data transport, SMC-R
      uses RDMA devices, SMC-D uses so-called Internal Shared Memory (ISM)
      devices. An ISM device only allows shared memory communication between
      SMC instances on the same machine. For example, this allows virtual
      machines on the same host to communicate via SMC without RDMA devices.
      
      This patch adds the base infrastructure for SMC-D and ISM devices to
      the existing SMC code. It contains the following:
      
      * ISM driver interface:
        This interface allows an ISM driver to register ISM devices in SMC. In
        the process, the driver provides a set of device ops for each device.
        SMC uses these ops to execute SMC specific operations on or transfer
        data over the device.
      
      * Core SMC-D link group, connection, and buffer support:
        Link groups, SMC connections and SMC buffers (in smc_core) are
        extended to support SMC-D.
      
      * SMC type checks:
        Some type checks are added to prevent using SMC-R specific code for
        SMC-D and vice versa.
      
      To actually use SMC-D, additional changes to pnetid, CLC, CDC, etc. are
      required. These are added in follow-up patches.
      Signed-off-by: NHans Wippel <hwippel@linux.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.ibm.com>
      Suggested-by: NThomas Richter <tmricht@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6ba7c9b
    • U
      net/smc: add pnetid support · 0afff91c
      Ursula Braun 提交于
      s390 hardware supports the definition of a so-call Physical NETwork
      IDentifier (short PNETID) per network device port. These PNETIDS
      can be used to identify network devices that are attached to the same
      physical network (broadcast domain).
      
      On s390 try to use the PNETID of the ethernet device port used for
      initial connecting, and derive the IB device port used for SMC RDMA
      traffic.
      
      On platforms without PNETID support fall back to the existing
      solution of a configured pnet table.
      Signed-off-by: NUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0afff91c
    • Y
      tcp: add new SNMP counter for drops when try to queue in rcv queue · ea5d0c32
      Yafang Shao 提交于
      When sk_rmem_alloc is larger than the receive buffer and we can't
      schedule more memory for it, the skb will be dropped.
      
      In above situation, if this skb is put into the ofo queue,
      LINUX_MIB_TCPOFODROP is incremented to track it.
      
      While if this skb is put into the receive queue, there's no record.
      So a new SNMP counter is introduced to track this behavior.
      
      LINUX_MIB_TCPRCVQDROP:  Number of packets meant to be queued in rcv queue
      			but dropped because socket rcvbuf limit hit.
      Signed-off-by: NYafang Shao <laoar.shao@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ea5d0c32
    • D
      bpf: undo prog rejection on read-only lock failure · 85782e03
      Daniel Borkmann 提交于
      Partially undo commit 9facc336 ("bpf: reject any prog that failed
      read-only lock") since it caused a regression, that is, syzkaller was
      able to manage to cause a panic via fault injection deep in set_memory_ro()
      path by letting an allocation fail: In x86's __change_page_attr_set_clr()
      it was able to change the attributes of the primary mapping but not in
      the alias mapping via cpa_process_alias(), so the second, inner call
      to the __change_page_attr() via __change_page_attr_set_clr() had to split
      a larger page and failed in the alloc_pages() with the artifically triggered
      allocation error which is then propagated down to the call site.
      
      Thus, for set_memory_ro() this means that it returned with an error, but
      from debugging a probe_kernel_write() revealed EFAULT on that memory since
      the primary mapping succeeded to get changed. Therefore the subsequent
      hdr->locked = 0 reset triggered the panic as it was performed on read-only
      memory, so call-site assumptions were infact wrong to assume that it would
      either succeed /or/ not succeed at all since there's no such rollback in
      set_memory_*() calls from partial change of mappings, in other words, we're
      left in a state that is "half done". A later undo via set_memory_rw() is
      succeeding though due to matching permissions on that part (aka due to the
      try_preserve_large_page() succeeding). While reproducing locally with
      explicitly triggering this error, the initial splitting only happens on
      rare occasions and in real world it would additionally need oom conditions,
      but that said, it could partially fail. Therefore, it is definitely wrong
      to bail out on set_memory_ro() error and reject the program with the
      set_memory_*() semantics we have today. Shouldn't have gone the extra mile
      since no other user in tree today infact checks for any set_memory_*()
      errors, e.g. neither module_enable_ro() / module_disable_ro() for module
      RO/NX handling which is mostly default these days nor kprobes core with
      alloc_insn_page() / free_insn_page() as examples that could be invoked long
      after bootup and original 314beb9b ("x86: bpf_jit_comp: secure bpf jit
      against spraying attacks") did neither when it got first introduced to BPF
      so "improving" with bailing out was clearly not right when set_memory_*()
      cannot handle it today.
      
      Kees suggested that if set_memory_*() can fail, we should annotate it with
      __must_check, and all callers need to deal with it gracefully given those
      set_memory_*() markings aren't "advisory", but they're expected to actually
      do what they say. This might be an option worth to move forward in future
      but would at the same time require that set_memory_*() calls from supporting
      archs are guaranteed to be "atomic" in that they provide rollback if part
      of the range fails, once that happened, the transition from RW -> RO could
      be made more robust that way, while subsequent RO -> RW transition /must/
      continue guaranteeing to always succeed the undo part.
      
      Reported-by: syzbot+a4eb8c7766952a1ca872@syzkaller.appspotmail.com
      Reported-by: syzbot+d866d1925855328eac3b@syzkaller.appspotmail.com
      Fixes: 9facc336 ("bpf: reject any prog that failed read-only lock")
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      85782e03