1. 11 3月, 2016 21 次提交
  2. 10 3月, 2016 19 次提交
    • R
      can: rcar_can: Add r8a7795 support · e481ab23
      Ramesh Shanmugasundaram 提交于
      Added r8a7795 SoC support.
      Signed-off-by: NRamesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      e481ab23
    • M
      can: ifi: Add obscure bit swap for EFF frame IDs · 6cc64266
      Marek Vasut 提交于
      In case of CAN2.0 EFF frame, the controller handles frame IDs in a
      rather bizzare way. The ID is split into an extended part, IDX[28:11]
      and standard part, ID[10:0]. In the TX path, the core first sends the
      top 11 bits of the IDX, followed by ID and finally the rest of IDX.
      In the RX path, the core stores the ID the LSbit part of IDX field,
      followed by the LSbit parts of real IDX. The MSbit parts of IDX are
      stored in ID field of the register.
      
      This patch implements the necessary bit shuffling to mitigate this
      obscure behavior. In case two of these controllers are connected
      together, the RX and TX bit swapping nullifies itself and the issue
      does not manifest. The issue only manifests when talking to another
      different CAN controller.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Marc Kleine-Budde <mkl@pengutronix.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Oliver Hartkopp <socketcan@hartkopp.net>
      Cc: Wolfgang Grandegger <wg@grandegger.com>
      Reviewed-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      6cc64266
    • M
      can: ifi: Fix RX and TX ID mask · 22365435
      Marek Vasut 提交于
      The RX and TX ID mask for CAN2.0 is 11 bits wide. This patch fixes
      the incorrect mask, which caused the CAN IDs to miss the MSBit both
      on receive and transmit.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Marc Kleine-Budde <mkl@pengutronix.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Oliver Hartkopp <socketcan@hartkopp.net>
      Cc: Wolfgang Grandegger <wg@grandegger.com>
      Reviewed-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      22365435
    • M
      can: ifi: Fix TX DLC configuration · f1deaee0
      Marek Vasut 提交于
      The TX DLC, the transmission length information, was not written
      into the transmit configuration register. When using the CAN core
      with different CAN controller, the receiving CAN controller will
      receive only the ID part of the CAN frame, but no data at all.
      
      This patch adds the TX DLC into the register to fix this issue.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Marc Kleine-Budde <mkl@pengutronix.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Oliver Hartkopp <socketcan@hartkopp.net>
      Cc: Wolfgang Grandegger <wg@grandegger.com>
      Reviewed-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      f1deaee0
    • M
      can: ifi: Fix clock generator configuration · 99312c37
      Marek Vasut 提交于
      The clock generation does not match reality when using the CAN IP
      core outside of the FPGA design. This patch fixes the computation
      of values which are programmed into the clock generator registers.
      
      First, there are some off-by-one errors which manifest themselves
      only when communicating with different controller, so those are
      fixed.
      
      Second, the bits in the clock generator registers have different
      meaning depending on whether the core is in ISO CANFD mode or any
      of the other modes (BOSCH CANFD or CAN2.0). Detect the ISO CANFD
      mode and fix handling of this special case of clock configuration.
      
      Finally, the CAN clock speed is in CANCLOCK register, not SYSCLOCK
      register, so fix this as well.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Marc Kleine-Budde <mkl@pengutronix.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Oliver Hartkopp <socketcan@hartkopp.net>
      Cc: Wolfgang Grandegger <wg@grandegger.com>
      Reviewed-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      99312c37
    • A
      bpf: avoid copying junk bytes in bpf_get_current_comm() · cdc4e47d
      Alexei Starovoitov 提交于
      Lots of places in the kernel use memcpy(buf, comm, TASK_COMM_LEN); but
      the result is typically passed to print("%s", buf) and extra bytes
      after zero don't cause any harm.
      In bpf the result of bpf_get_current_comm() is used as the part of
      map key and was causing spurious hash map mismatches.
      Use strlcpy() to guarantee zero-terminated string.
      bpf verifier checks that output buffer is zero-initialized,
      so even for short task names the output buffer don't have junk bytes.
      Note it's not a security concern, since kprobe+bpf is root only.
      
      Fixes: ffeedafb ("bpf: introduce current->pid, tgid, uid, gid, comm accessors")
      Reported-by: NTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cdc4e47d
    • A
      bpf: bpf_stackmap_copy depends on CONFIG_PERF_EVENTS · b8cdc051
      Alexei Starovoitov 提交于
      0-day bot reported build error:
      kernel/built-in.o: In function `map_lookup_elem':
      >> kernel/bpf/.tmp_syscall.o:(.text+0x329b3c): undefined reference to `bpf_stackmap_copy'
      when CONFIG_BPF_SYSCALL is set and CONFIG_PERF_EVENTS is not.
      Add weak definition to resolve it.
      This code path in map_lookup_elem() is never taken
      when CONFIG_PERF_EVENTS is not set.
      
      Fixes: 557c0c6e ("bpf: convert stackmap to pre-allocation")
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8cdc051
    • D
      Merge branch 'variable-length-ll-headers' · 3b8377dc
      David S. Miller 提交于
      Willem de Bruijn says:
      
      ====================
      net: validate variable length ll headers
      
      Allow device-specific validation of link layer headers. Existing
      checks drop all packets shorter than hard_header_len. For variable
      length protocols, such packets can be valid.
      
      patch 1 adds header_ops.validate and dev_validate_header
      patch 2 implements the protocol specific callback for AX25
      patch 3 replaces ll_header_truncated with dev_validate_header
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b8377dc
    • W
      packet: validate variable length ll headers · 9ed988cd
      Willem de Bruijn 提交于
      Replace link layer header validation check ll_header_truncate with
      more generic dev_validate_header.
      
      Validation based on hard_header_len incorrectly drops valid packets
      in variable length protocols, such as AX25. dev_validate_header
      calls header_ops.validate for such protocols to ensure correctness
      below hard_header_len.
      
      See also http://comments.gmane.org/gmane.linux.network/401064
      
      Fixes 9c707762 ("packet: make packet_snd fail on len smaller than l2 header")
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9ed988cd
    • W
      ax25: add link layer header validation function · ea47781c
      Willem de Bruijn 提交于
      As variable length protocol, AX25 fails link layer header validation
      tests based on a minimum length. header_ops.validate allows protocols
      to validate headers that are shorter than hard_header_len. Implement
      this callback for AX25.
      
      See also http://comments.gmane.org/gmane.linux.network/401064Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ea47781c
    • W
      net: validate variable length ll headers · 2793a23a
      Willem de Bruijn 提交于
      Netdevice parameter hard_header_len is variously interpreted both as
      an upper and lower bound on link layer header length. The field is
      used as upper bound when reserving room at allocation, as lower bound
      when validating user input in PF_PACKET.
      
      Clarify the definition to be maximum header length. For validation
      of untrusted headers, add an optional validate member to header_ops.
      
      Allow bypassing of validation by passing CAP_SYS_RAWIO, for instance
      for deliberate testing of corrupt input. In this case, pad trailing
      bytes, as some device drivers expect completely initialized headers.
      
      See also http://comments.gmane.org/gmane.linux.network/401064Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2793a23a
    • D
      Merge branch 'kcm' · 9531ab65
      David S. Miller 提交于
      Tom Herbert says:
      
      ====================
      kcm: Kernel Connection Multiplexor (KCM)
      
      Kernel Connection Multiplexor (KCM) is a facility that provides a
      message based interface over TCP for generic application protocols.
      The motivation for this is based on the observation that although
      TCP is byte stream transport protocol with no concept of message
      boundaries, a common use case is to implement a framed application
      layer protocol running over TCP. To date, most TCP stacks offer
      byte stream API for applications, which places the burden of message
      delineation, message I/O operation atomicity, and load balancing
      in the application. With KCM an application can efficiently send
      and receive application protocol messages over TCP using a
      datagram interface.
      
      In order to delineate message in a TCP stream for receive in KCM, the
      kernel implements a message parser. For this we chose to employ BPF
      which is applied to the TCP stream. BPF code parses application layer
      messages and returns a message length. Nearly all binary application
      protocols are parsable in this manner, so KCM should be applicable
      across a wide range of applications. Other than message length
      determination in receive, KCM does not require any other application
      specific awareness. KCM does not implement any other application
      protocol semantics-- these are are provided in userspace or could be
      implemented in a kernel module layered above KCM.
      
      KCM implements an NxM multiplexor in the kernel as diagrammed below:
      
      +------------+   +------------+   +------------+   +------------+
      | KCM socket |   | KCM socket |   | KCM socket |   | KCM socket |
      +------------+   +------------+   +------------+   +------------+
            |                 |               |                |
            +-----------+     |               |     +----------+
                        |     |               |     |
                     +----------------------------------+
                     |           Multiplexor            |
                     +----------------------------------+
                       |   |           |           |  |
             +---------+   |           |           |  ------------+
             |             |           |           |              |
      +----------+  +----------+  +----------+  +----------+ +----------+
      |  Psock   |  |  Psock   |  |  Psock   |  |  Psock   | |  Psock   |
      +----------+  +----------+  +----------+  +----------+ +----------+
            |              |           |            |             |
      +----------+  +----------+  +----------+  +----------+ +----------+
      | TCP sock |  | TCP sock |  | TCP sock |  | TCP sock | | TCP sock |
      +----------+  +----------+  +----------+  +----------+ +----------+
      
      The KCM sockets provide the datagram interface to applications,
      Psocks are the state for each attached TCP connection (i.e. where
      message delineation is performed on receive).
      
      A description of the APIs and design can be found in the included
      Documentation/networking/kcm.txt.
      
      In this patch set:
      
        - Add MSG_BATCH flag. This is used in sendmsg msg_hdr flags to
          indicate that more messages will be sent on the socket. The stack
          may batch messages up if it is beneficial for transmission.
        - In sendmmsg, set MSG_BATCH in all sub messages except for the last
          one.
        - In order to allow sendmmsg to contain multiple messages with
          SOCK_SEQPAKET we allow each msg_hdr in the sendmmsg to set MSG_EOR.
        - Add KCM module
          - This supports SOCK_DGRAM and SOCK_SEQPACKET.
        - KCM documentation
      
      v2:
        - Added splice and page operations.
        - Assemble receive messages in place on TCP socket (don't have a
          separate assembly queue.
        - Based on above, enforce maxmimum receive message to be the size
          of the recceive socket buffer.
        - Support message assembly timeout. Use the timeout value in
          sk_rcvtimeo on the TCP socket.
        - Tested some with a couple of other production applications,
          see ~5% improvement in application latency.
      
      Testing:
      
      Dave Watson has integrated KCM into Thrift and we intend to put these
      changes into open source. Example of this is in:
      
      https://github.com/djwatson/fbthrift/commit/
      dd7e0f9cf4e80912fdb90f6cd394db24e61a14cc
      
      Some initial KCM Thrift benchmark numbers (comment from Dave)
      
      Thrift by default ties a single connection to a single thread.  KCM is
      instead able to load balance multiple connections across multiple epoll
      loops easily.
      
      A test sending ~5k bytes of data to a kcm thrift server, dropping the
      bytes on recv:
      
      QPS     Latency / std dev Latency
        without KCM
          70336     209/123
        with KCM
          70353     191/124
      
      A test sending a small request, then doing work in the epoll thread,
      before serving more requests:
      
      QPS     Latency / std dev Latency
      without KCM
          14282     559/602
      with KCM
          23192     344/234
      
      At the high end, there's definitely some additional kernel overhead:
      
      Cranking the pipelining way up, with lots of small requests
      
      QPS     Latency / std dev Latency
      without KCM
         1863429     127/119
      with KCM
         1337713     192/241
      
      ---
      
      So for a "realistic" workload, KCM performs pretty well (second case).
      Under extreme conditions of highest tps we still have some work to do.
      In its nature a multiplexor will spread work between CPUs which is
      logically good for load balancing but coan conflict with the goal
      promoting affinity. Batching messages on both send and receive are
      the means to recoup performance.
      
      Future support:
      
       - Integration with TLS (TLS-in-kernel is a separate initiative).
       - Page operations/splice support
       - Unconnected KCM sockets. Will be able to attach sockets to different
         destinations, AF_KCM addresses with be used in sendmsg and recvmsg
         to indicate destination
       - Explore more utility in performing BPF inline with a TCP data stream
         (setting SO_MARK, rxhash for messages being sent received on
         KCM sockets).
       - Performance work
         - Diagnose performance issues under high message load
      
      FAQ (Questions posted on LWN)
      
      Q: Why do this in the kernel?
      
      A: Because the kernel is good at scheduling threads and steering packets
         to threads. KCM fits well into this model since it allows the unit
         of work for scheduling and steering to be the application layer
         messages themselves. KCM should be thought of as generic application
         protocol acceleration. It to the philosophy that the kernel provides
         generic and extensible interfaces.
      
      Q: How can adding code in the path yield better performance?
      
      A: It is true that for just sending receiving a single message there
         would be some performance loss since the code path is longer (for
         instance comparing netperf to KCM). But for real production
         applications performance takes on many dynamics. Parallelism, context
         switching, affinity, granularity of locking, and load balancing are
         all relevant. The theory of KCM is that by an application-centric
         interface, the kernel can provide better support for these
         performance characteristics.
      
      Q: Why not use an existing message-oriented protocol such as RUDP,
         DCCP, SCTP, RDS, and others?
      
      A: Because that would entail using a completely new transport protocol.
         Deploying a new protocol at scale is either a huge undertaking or
         fundamentally infeasible. This is true in either the Internet and in
         the data center due in a large part to protocol ossification.
         Besides, KCM we want KCM to work existing, well deployed application
         protocols that we couldn't change even if we wanted to (e.g. http/2).
      
         KCM simply defines a new interface method, it does not redefine any
         aspect of the transport protocol nor application protocol, nor set
         any new requirements on these. Neither does KCM attempt to implement
         any application protocol logic other than message deliniation in the
         stream. These are fundamental requirement of KCM.
      
      Q: How does this affect TCP?
      
      A: It doesn't, not in the slightest. The use of KCM can be one-sided,
         KCM has no effect on the wire.
      
      Q: Why force TCP into doing something it's not designed for?
      
      A: TCP is defined as transport protocol and there is no standard that
         says the API into TCP must be stream based sockets, or for that
         matter sockets at all (or even that TCP needs to be implemented in a
         kernel). KCM is not inconsistent with the design of TCP just because
         to makes an message based interface over TCP, if it were then every
         application protocol sending messages over TCP would also be! :-)
      
      Q: What about the problem of a connections with very slow rate of
         incoming data? As a result your application can get storms of very
         short reads. And it actually happens a lot with connection from
         mobile devices and it is a problem for servers handling a lot of
         connections.
      
      A: The storm of short reads will occur regardless of whether KCM is used
         or not. KCM does have one advantage in this scenario though, it will
         only wake up the application when a full message has been received,
         not for each packet that makes up part of a bigger messages. If a
         bunch of small messages are received, the application can receive
         messages in batches using recvmmsg.
      
      Q: Why not just use DPDK, or at least provide KCM like functionality in
         DPDK?
      
      A: DPDK, or more generally OS bypass presumably with a TCP stack in
         userland, presents a different model of load balancing than that of
         KCM (and the kernel). KCM implements load balancing of messages
         across the threads of an application, whereas DPDK load balances
         based on queues which are more static and coarse-grained since
         multiple connections are bound to queues. DPDK works best when
         processing of packets is silo'ed in a thread on the CPU processing
         a queue, and packet processing (for both the stack and application)
         is fairly uniform. KCM works well for applications where the amount
         of work to process messages varies an application work is commonly
         delegated to worker threads often on different CPUs.
      
         The message based interface over TCP is something that could be
         provide by a DPDK or OS bypass library.
      
      Q: I'm not quite seeing this for HTTP. Maybe for HTTP/2, I guess, or web
         sockets?
      
      A: Yes. KCM is most appropriate for message based protocols over TCP
         where is easy to deduce the message length (e.g. a length field)
         and the protocol implements its own message ordering semantics.
         Fortunately this encompasses many modern protocols.
      
      Q: How is memory limited and controlled?
      
      A: In v2 all data for messages is now kept in socket buffers, either
         those for TCP or KCM, so socket buffer limits are applicable.
         This includes receive messages assembly which is now done ont teh
         TCP socket buffer instead of a separate queue-- this has the
         consequence that the TCP socket buffer limit provides an
         enforceable maxmimum message size.
      
         Additionally, a timeout may be set for messages assembly. The
         value used for this is taken from sk_rcvtimeo of the TCP socket.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9531ab65
    • T
      kcm: Add description in Documentation · 10016594
      Tom Herbert 提交于
      Add kcm.txt to desribe KCM and interfaces.
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10016594
    • T
      kcm: Add receive message timeout · 29152a34
      Tom Herbert 提交于
      This patch adds receive timeout for message assembly on the attached TCP
      sockets. The timeout is set when a new messages is started and the whole
      message has not been received by TCP (not in the receive queue). If the
      completely message is subsequently received the timer is cancelled, if the
      timer expires the RX side is aborted.
      
      The timeout value is taken from the socket timeout (SO_RCVTIMEO) that is
      set on a TCP socket (i.e. set by get sockopt before attaching a TCP socket
      to KCM.
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      29152a34
    • T
      kcm: Add memory limit for receive message construction · 7ced95ef
      Tom Herbert 提交于
      Message assembly is performed on the TCP socket. This is logically
      equivalent of an application that performs a peek on the socket to find
      out how much memory is needed for a receive buffer. The receive socket
      buffer also provides the maximum message size which is checked.
      
      The receive algorithm is something like:
      
         1) Receive the first skbuf for a message (or skbufs if multiple are
            needed to determine message length).
         2) Check the message length against the number of bytes in the TCP
            receive queue (tcp_inq()).
      	- If all the bytes of the message are in the queue (incluing the
      	  skbuf received), then proceed with message assembly (it should
      	  complete with the tcp_read_sock)
              - Else, mark the psock with the number of bytes needed to
      	  complete the message.
         3) In TCP data ready function, if the psock indicates that we are
            waiting for the rest of the bytes of a messages, check the number
            of queued bytes against that.
              - If there are still not enough bytes for the message, just
      	  return
              - Else, clear the waiting bytes and proceed to receive the
      	  skbufs.  The message should now be received in one
      	  tcp_read_sock
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ced95ef
    • T
      kcm: Sendpage support · f29698fc
      Tom Herbert 提交于
      Implement kcm_sendpage. Set in sendpage to kcm_sendpage in both
      dgram and seqpacket ops.
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f29698fc
    • T
      kcm: Splice support · 91687355
      Tom Herbert 提交于
      Implement kcm_splice_read. This is supported only for seqpacket.
      Add kcm_seqpacket_ops and set splice read to kcm_splice_read.
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      91687355
    • T
      kcm: Add statistics and proc interfaces · cd6e111b
      Tom Herbert 提交于
      This patch adds various counters for KCM. These include counters for
      messages and bytes received or sent, as well as counters for number of
      attached/unattached TCP sockets and other error or edge events.
      
      The statistics are exposed via a proc interface. /proc/net/kcm provides
      statistics per KCM socket and per psock (attached TCP sockets).
      /proc/net/kcm_stats provides aggregate statistics.
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cd6e111b
    • T
      kcm: Kernel Connection Multiplexor module · ab7ac4eb
      Tom Herbert 提交于
      This module implements the Kernel Connection Multiplexor.
      
      Kernel Connection Multiplexor (KCM) is a facility that provides a
      message based interface over TCP for generic application protocols.
      With KCM an application can efficiently send and receive application
      protocol messages over TCP using datagram sockets.
      
      For more information see the included Documentation/networking/kcm.txt
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab7ac4eb