Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 10 6月, 2009 11 次提交
  3. 05 6月, 2009 18 次提交
  5. 04 6月, 2009 3 次提交
    • E
      drm/i915: Change GEM throttling to be 20ms like the comment says. · b962442e
      由 Eric Anholt 提交于 
      keithp didn't like the original 20ms plan because a cooperative client could
be starved by an uncooperative client.  There may even have been problems
with cooperative clients versus cooperative clients.  So keithp changed
throttle to just wait for the second to last seqno emitted by that client.
It worked well, until we started getting more round-trips to the server
due to DRI2 -- the server throttles in BlockHandler, and so if you did more
than one round trip after finishing your frame, you'd end up unintentionally
syncing to the swap.

Fix this by keeping track of the client's requests, so the client can wait
when it has an outstanding request over 20ms old.  This should have
non-starving behavior, good behavior in the presence of restarts, and less
waiting.  Improves high-settings openarena performance on my GM45 by 50%.
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b962442e
    • E
      drm/i915: Save/restore cursor state on suspend/resume. · 1fd1c624
      由 Eric Anholt 提交于 
      This may fix cursor corruption in X on resume, which would persist until
the cursor was hidden and then shown again.

V2: Also include the cursor control regs.
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      1fd1c624
    • E
      drm/i915: Remove a bad BUG_ON in the fence management code. · 0e7ddf7e
      由 Eric Anholt 提交于 
      This could be triggered by a gtt mapping fault on 965 that decides to
remove the fence from another object that happens to be active currently.
Since the other object doesn't rely on the fence reg for its execution, we
don't wait for it to finish.  We'll soon be not waiting on 915 most of the
time as well, so just drop the BUG_ON.
Signed-off-by: NEric Anholt <eric@anholt.net>
      0e7ddf7e
  7. 03 6月, 2009 6 次提交
  9. 02 6月, 2009 2 次提交
    • M
      net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel... · 12186be7
      由 Minoru Usui 提交于 
      net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup

This patch fixes a bug which unconfigured struct tcf_proto keeps
chaining in tc_ctl_tfilter(), and avoids kernel panic in
cls_cgroup_classify() when we use cls_cgroup.

When we execute 'tc filter add', tcf_proto is allocated, initialized
by classifier's init(), and chained.  After it's chained,
tc_ctl_tfilter() calls classifier's change().  When classifier's
change() fails, tc_ctl_tfilter() does not free and keeps tcf_proto.

In addition, cls_cgroup is initialized in change() not in init().  It
accesses unconfigured struct tcf_proto which is chained before
change(), then hits Oops.
Signed-off-by: NMinoru Usui <usui@mxm.nes.nec.co.jp>
Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
Tested-by: NMinoru Usui <usui@mxm.nes.nec.co.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12186be7
    • N
      e1000: add missing length check to e1000 receive routine · ea30e119
      由 Neil Horman 提交于 
      	Patch to fix bad length checking in e1000.  E1000 by default does two
things:

1) Spans rx descriptors for packets that don't fit into 1 skb on recieve
2) Strips the crc from a frame by subtracting 4 bytes from the length prior to
doing an skb_put

Since the e1000 driver isn't written to support receiving packets that span
multiple rx buffers, it checks the End of Packet bit of every frame, and
discards it if its not set.  This places us in a situation where, if we have a
spanning packet, the first part is discarded, but the second part is not (since
it is the end of packet, and it passes the EOP bit test).  If the second part of
the frame is small (4 bytes or less), we subtract 4 from it to remove its crc,
underflow the length, and wind up in skb_over_panic, when we try to skb_put a
huge number of bytes into the skb.  This amounts to a remote DOS attack through
careful selection of frame size in relation to interface MTU.  The fix for this
is already in the e1000e driver, as well as the e1000 sourceforge driver, but no
one ever pushed it to e1000.  This is lifted straight from e1000e, and prevents
small frames from causing the underflow described above
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Tested-by: NAndy Gospodarek <andy@greyhouse.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ea30e119