Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 14 5月, 2015 2 次提交
  3. 21 4月, 2015 5 次提交
  5. 16 4月, 2015 1 次提交
  7. 15 4月, 2015 4 次提交
  9. 13 4月, 2015 2 次提交
    • H
      Input: alps - non interleaved V2 dualpoint has separate stick button bits · 92bac83d
      由 Hans de Goede 提交于 
      Non interleaved V2 dualpoint touchpad / stick combos have separate stick
button bits in the touchpad packets, if we do not check these then the
trackpoint buttons will not work when using the touchpad, and when pressed
when the user starts using the touchpad will report a release event even
though the button is still pressed.

This commit fixes this by checking the separate bits, note that we simply
combine the buttons, since the hardware does the same when using the touchpad
buttons with the trackpoint, so we do not have enough information to properly
separate them.
Reported-by: NHans de Bruin <jmdebruin@xmsnet.nl>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      92bac83d
    • H
      Input: alps - fix touchpad buttons getting stuck when used with trackpoint · 6bcca19f
      由 Hans de Goede 提交于 
      When the left touchpad button gets pressed, and then the trackpoint is
moved, and then the button is released, the following happens:

1) touchpad packet is received, touchpad evdev node reports BTN_LEFT 1

2) pointing stick packet is received, the hw will report a BTN_LEFT 1 in
   this packet because when the trackstick is active it communicates the
   combined touchpad + pointing stick buttons in the trackstick packet,
   since alps_report_bare_ps2_packet passes NULL (*) for the dev2 parameter
   to alps_report_buttons the combining is not detected and the
   pointing stick evdev node will also report BTN_LEFT 1

3) on release of the button a pointing stick packet with BTN_LEFT 0 is
   received and the pointing stick evdev node will report BTN_LEFT 0

Note how because of the passing as NULL for dev2 the touchpad evdev node
will never send BTN_LEFT 0 in this scenario leading to a stuck mouse button.

This is a regression in 4.0 introduced by commit 04aae283
("Input: ALPS - do not mix trackstick and external PS/2 mouse data")

This commit fixes this by passing in the touchpad evdev as dev2 parameter
when calling alps_report_buttons for the pointingstick on alps v2 devices,
so that alps_report_buttons correctly detect that we're already reporting
the button as pressed via the touchpad evdev node, and will also send the
release event there.

Cc: stable@vger.kernel.org # 4.0
Reported-by: NHans de Bruin <jmdebruin@xmsnet.nl>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      6bcca19f
  11. 11 4月, 2015 2 次提交
  13. 07 4月, 2015 13 次提交
  15. 06 4月, 2015 2 次提交
  17. 04 4月, 2015 2 次提交
  19. 03 4月, 2015 2 次提交
    • J
      xen-netfront: transmit fully GSO-sized packets · 0c36820e
      由 Jonathan Davies 提交于 
      xen-netfront limits transmitted skbs to be at most 44 segments in size. However,
GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448
bytes each. This slight reduction in the size of packets means a slight loss in
efficiency.

Since c/s 9ecd1a75, xen-netfront sets gso_max_size to
    XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER,
where XEN_NETIF_MAX_TX_SIZE is 65535 bytes.

The calculation used by tcp_tso_autosize (and also tcp_xmit_size_goal since c/s
6c09fa09) in determining when to split an skb into two is
    sk->sk_gso_max_size - 1 - MAX_TCP_HEADER.

So the maximum permitted size of an skb is calculated to be
    (XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER) - 1 - MAX_TCP_HEADER.

Intuitively, this looks like the wrong formula -- we don't need two TCP headers.
Instead, there is no need to deviate from the default gso_max_size of 65536 as
this already accommodates the size of the header.

Currently, the largest skb transmitted by netfront is 63712 bytes (44 segments
of 1448 bytes each), as observed via tcpdump. This patch makes netfront send
skbs of up to 65160 bytes (45 segments of 1448 bytes each).

Similarly, the maximum allowable mtu does not need to subtract MAX_TCP_HEADER as
it relates to the size of the whole packet, including the header.

Fixes: 9ecd1a75 ("xen-netfront: reduce gso_max_size to account for max TCP header")
Signed-off-by: NJonathan Davies <jonathan.davies@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c36820e
    • S
      IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic · 8494057a
      由 Shachar Raindel 提交于 
      Properly verify that the resulting page aligned end address is larger
than both the start address and the length of the memory area requested.

Both the start and length arguments for ib_umem_get are controlled by
the user. A misbehaving user can provide values which will cause an
integer overflow when calculating the page aligned end address.

This overflow can cause also miscalculation of the number of pages
mapped, and additional logic issues.

Addresses: CVE-2014-8159
Cc: <stable@vger.kernel.org>
Signed-off-by: NShachar Raindel <raindel@mellanox.com>
Signed-off-by: NJack Morgenstein <jackm@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
      8494057a
  21. 02 4月, 2015 5 次提交