Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
“761b3297934c741aaa4d13130a3e0a31131506d5”上不存在“paddle/fluid/operators/sequence_ops/sequence_expand_op.cu”
切换分支/标签
  1. 04 5月, 2010 3 次提交
    • P
      dm9601: fix phy/eeprom write routine · e9162ab1
      由 Peter Korsgaard 提交于 
      Use correct bit positions in DM_SHARED_CTRL register for writes.

Michael Planes recently encountered a 'KY-RS9600 USB-LAN converter', which
came with a driver CD containing a Linux driver. This driver turns out to
be a copy of dm9601.c with symbols renamed and my copyright stripped.
That aside, it did contain 1 functional change in dm_write_shared_word(),
and after checking the datasheet the original value was indeed wrong
(read versus write bits).

On Michaels HW, this change bumps receive speed from ~30KB/s to ~900KB/s.
On other devices the difference is less spectacular, but still significant
(~30%).
Reported-by: NMichael Planes <michael.planes@free.fr>
CC: stable@kernel.org
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9162ab1
    • S
      ppp_generic: handle non-linear skbs when passing them to pppd · 19937d04
      由 Simon Arlott 提交于 
      Frequently when using PPPoE with an interface MTU greater than 1500,
the skb is likely to be non-linear. If the skb needs to be passed to
pppd then the skb data must be read correctly.

The previous commit fixes an issue with accidentally sending skbs
to pppd based on an invalid read of the protocol type. When that
error occurred pppd was reading invalid skb data too.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19937d04
    • S
      ppp_generic: pull 2 bytes so that PPP_PROTO(skb) is valid · ea8420e9
      由 Simon Arlott 提交于 
      In ppp_input(), PPP_PROTO(skb) may refer to invalid data in the skb.

If this happens and (proto >= 0xc000 || proto == PPP_CCPFRAG) then
the packet is passed directly to pppd.

This occurs frequently when using PPPoE with an interface MTU
greater than 1500 because the skb is more likely to be non-linear.

The next 2 bytes need to be pulled in ppp_input(). The pull of 2
bytes in ppp_receive_frame() has been removed as it is no longer
required.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ea8420e9
  3. 02 5月, 2010 1 次提交
  5. 01 5月, 2010 3 次提交
  7. 29 4月, 2010 4 次提交
  9. 28 4月, 2010 12 次提交
  11. 27 4月, 2010 4 次提交
  13. 25 4月, 2010 1 次提交
  15. 24 4月, 2010 2 次提交
    • A
      gianfar: Fix potential oops during OF address translation · 7ce97d4f
      由 Anton Vorontsov 提交于 
      gianfar driver may pass NULL pointer to the of_translate_address(),
which may lead to a kernel oops. Fix this by using of_iomap(), which
is also much simpler and shorter.
Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ce97d4f
    • A
      fsl_pq_mdio: Fix kernel oops during OF address translation · 3b1fd3e5
      由 Anton Vorontsov 提交于 
      Old P1020RDB device trees were not specifing tbipa address for
MDIO nodes, which is now causing this kernel oops:

 ...
 eth2: TX BD ring size for Q[6]: 256
 eth2: TX BD ring size for Q[7]: 256
 Unable to handle kernel paging request for data at address 0x00000000
 Faulting instruction address: 0xc0015504
 Oops: Kernel access of bad area, sig: 11 [#1]
 ...
 NIP [c0015504] memcpy+0x3c/0x9c
 LR [c000a9f8] __of_translate_address+0xfc/0x21c
 Call Trace:
 [df839e00] [c000a94c] __of_translate_address+0x50/0x21c (unreliable)
 [df839e50] [c01a33e8] get_gfar_tbipa+0xb0/0xe0
 ...

The old device trees are buggy, though having a dead ethernet is
better than a dead kernel, so fix the issue by using of_iomap().

Also, a somewhat similar issue exist in the probe() routine, though
there the oops is only a possibility. Nonetheless, fix it too.
Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b1fd3e5
  17. 22 4月, 2010 5 次提交
  19. 20 4月, 2010 1 次提交
  21. 17 4月, 2010 3 次提交
  23. 14 4月, 2010 1 次提交
    • M
      tun: orphan an skb on tx · 0110d6f2
      由 Michael S. Tsirkin 提交于 
      The following situation was observed in the field:
tap1 sends packets, tap2 does not consume them, as a result
tap1 can not be closed. This happens because
tun/tap devices can hang on to skbs undefinitely.

As noted by Herbert, possible solutions include a timeout followed by a
copy/change of ownership of the skb, or always copying/changing
ownership if we're going into a hostile device.

This patch implements the second approach.

Note: one issue still remaining is that since skbs
keep reference to tun socket and tun socket has a
reference to tun device, we won't flush backlog,
instead simply waiting for all skbs to get transmitted.
At least this is not user-triggerable, and
this was not reported in practice, my assumption is
other devices besides tap complete an skb
within finite time after it has been queued.

A possible solution for the second issue
would not to have socket reference the device,
instead, implement dev->destructor for tun, and
wait for all skbs to complete there, but this
needs some thought, probably too risky for 2.6.34.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Tested-by: NYan Vugenfirer <yvugenfi@redhat.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0110d6f2