Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 14 8月, 2009 2 次提交
    • P
      rt2x00: fix memory corruption in rf cache, add a sanity check · 6b26dead
      由 Pavel Roskin 提交于 
      Change rt2x00_rf_read() and rt2x00_rf_write() to subtract 1 from the rf
register number.  This is needed because the rf registers are enumerated
starting with one.  The size of the rf register cache is just enough to
hold all registers, so writing to the highest register was corrupting
memory.  Add a check to make sure that the rf register number is valid.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Cc: stable@kernel.org
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6b26dead
    • L
      mac80211: fix panic when splicing unprepared TIDs · 416fbdff
      由 Luis R. Rodriguez 提交于 
      We splice skbs from the pending queue for a TID
onto the local pending queue when tearing down a
block ack request. This is not necessary unless we
actually have received a request to start a block ack
request (rate control, for example). If we never received
that request we should not be splicing the tid pending
queue as it would be null, causing a panic.

Not sure yet how exactly we allowed through a call when the
tid state does not have at least HT_ADDBA_REQUESTED_MSK set,
that will require some further review as it is not quite
obvious.

For more information see the bug report:

http://bugzilla.kernel.org/show_bug.cgi?id=13922

This fixes this oops:

BUG: unable to handle kernel NULL pointer dereference at 00000030
IP: [<f8806c70>] ieee80211_agg_splice_packets+0x40/0xc0 [mac80211]
*pdpt = 0000000002d1e001 *pde = 0000000000000000
Thread overran stack, or stack corrupted
Oops: 0000 [#1] SMP
last sysfs file: /sys/module/aes_generic/initstate
Modules linked in: <bleh>

Pid: 0, comm: swapper Not tainted (2.6.31-rc5-wl #2) Dell DV051
EIP: 0060:[<f8806c70>] EFLAGS: 00010292 CPU: 0
EIP is at ieee80211_agg_splice_packets+0x40/0xc0 [mac80211]
EAX: 00000030 EBX: 0000004c ECX: 00000003 EDX: 00000000
ESI: c1c98000 EDI: f745a1c0 EBP: c076be58 ESP: c076be38
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c076a000 task=c0709160 task.ti=c076a000)
Stack: <bleh2>
Call Trace:
 [<f8806edb>] ? ieee80211_stop_tx_ba_cb+0xab/0x150 [mac80211]
 [<f8802f1e>] ? ieee80211_tasklet_handler+0xce/0x110 [mac80211]
 [<c04862ff>] ? net_rx_action+0xef/0x1d0
 [<c0149378>] ? tasklet_action+0x58/0xc0
 [<c014a0f2>] ? __do_softirq+0xc2/0x190
 [<c018eb48>] ? handle_IRQ_event+0x58/0x140
 [<c01205fe>] ? ack_apic_level+0x7e/0x270
 [<c014a1fd>] ? do_softirq+0x3d/0x40
 [<c014a345>] ? irq_exit+0x65/0x90
 [<c010a6af>] ? do_IRQ+0x4f/0xc0
 [<c014a35d>] ? irq_exit+0x7d/0x90
 [<c011d547>] ? smp_apic_timer_interrupt+0x57/0x90
 [<c01094a9>] ? common_interrupt+0x29/0x30
 [<c010fd9e>] ? mwait_idle+0xbe/0x100
 [<c0107e42>] ? cpu_idle+0x52/0x90
 [<c054b1a5>] ? rest_init+0x55/0x60
 [<c077492d>] ? start_kernel+0x315/0x37d
 [<c07743ce>] ? unknown_bootoption+0x0/0x1f9
 [<c0774099>] ? i386_start_kernel+0x79/0x81
Code: <bleh3>
EIP: [<f8806c70>] ieee80211_agg_splice_packets+0x40/0xc0 [mac80211] SS:ESP 0068:c076be38
CR2: 0000000000000030

Cc: stable@kernel.org
Testedy-by: NJack Lau <jackelectronics@hotmail.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      416fbdff
  3. 13 8月, 2009 2 次提交
  5. 11 8月, 2009 2 次提交
  7. 10 8月, 2009 26 次提交
  9. 09 8月, 2009 8 次提交
    • F
      perf_counter: Fix/complete ftrace event records sampling · f413cdb8
      由 Frederic Weisbecker 提交于 
      This patch implements the kernel side support for ftrace event
record sampling.

A new counter sampling attribute is added:

   PERF_SAMPLE_TP_RECORD

which requests ftrace events record sampling. In this case
if a PERF_TYPE_TRACEPOINT counter is active and a tracepoint
fires, we emit the tracepoint binary record to the
perfcounter event buffer, as a sample.

Result, after setting PERF_SAMPLE_TP_RECORD attribute from perf
record:

 perf record -f -F 1 -a -e workqueue:workqueue_execution
 perf report -D

 0x21e18 [0x48]: event: 9
 .
 . ... raw event: size 72 bytes
 .  0000:  09 00 00 00 01 00 48 00 d0 c7 00 81 ff ff ff ff  ......H........
 .  0010:  0a 00 00 00 0a 00 00 00 21 00 00 00 00 00 00 00  ........!......
 .  0020:  2b 00 01 02 0a 00 00 00 0a 00 00 00 65 76 65 6e  +...........eve
 .  0030:  74 73 2f 31 00 00 00 00 00 00 00 00 0a 00 00 00  ts/1...........
 .  0040:  e0 b1 31 81 ff ff ff ff                          .......
.
0x21e18 [0x48]: PERF_EVENT_SAMPLE (IP, 1): 10: 0xffffffff8100c7d0 period: 33

The raw ftrace binary record starts at offset 0020.

Translation:

 struct trace_entry {
	type		= 0x2b = 43;
	flags		= 1;
	preempt_count	= 2;
	pid		= 0xa = 10;
	tgid		= 0xa = 10;
 }

 thread_comm = "events/1"
 thread_pid  = 0xa = 10;
 func	    = 0xffffffff8131b1e0 = flush_to_ldisc()

What will come next?

 - Userspace support ('perf trace'), 'flight data recorder' mode
   for perf trace, etc.

 - The unconditional copy from the profiling callback brings
   some costs however if someone wants no such sampling to
   occur, and needs to be fixed in the future. For that we need
   to have an instant access to the perf counter attribute.
   This is a matter of a flag to add in the struct ftrace_event.

 - Take care of the events recursivity! Don't ever try to record
   a lock event for example, it seems some locking is used in
   the profiling fast path and lead to a tracing recursivity.
   That will be fixed using raw spinlock or recursivity
   protection.

 - [...]

 - Profit! :-)
Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Tom Zanussi <tzanussi@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Gabriel Munteanu <eduard.munteanu@linux360.ro>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f413cdb8
    • P
      perf_counter, ftrace: Fix perf_counter integration · 3a659305
      由 Peter Zijlstra 提交于 
      Adds possible second part to the assign argument of TP_EVENT().

  TP_perf_assign(
	__perf_count(foo);
	__perf_addr(bar);
  )

Which, when specified make the swcounter increment with @foo instead
of the usual 1, and report @bar for PERF_SAMPLE_ADDR (data address
associated with the event) when this triggers a counter overflow.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jason Baron <jbaron@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3a659305
    • I
      Merge branch 'linus' into tracing/urgent · e3560336
      由 Ingo Molnar 提交于 
      Merge reason: Merge up to almost-rc6 to pick up latest perfcounters
              (on which we'll queue up a dependent fix)
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e3560336
    • G
      KVM: Avoid redelivery of edge interrupt before next edge · b4a2f5e7
      由 Gleb Natapov 提交于 
      The check for an edge is broken in current ioapic code. ioapic->irr is
cleared on each edge interrupt by ioapic_service() and this makes
old_irr != ioapic->irr condition in kvm_ioapic_set_irq() to be always
true. The patch fixes the code to properly recognise edge.

Some HW emulation calls set_irq() without level change. If each such
call is propagated to an OS it may confuse a device driver. This is the
case with keyboard device emulation and Windows XP x64  installer on SMP VM.
Each keystroke produce two interrupts (down/up) one interrupt is
submitted to CPU0 and another to CPU1. This confuses Windows somehow
and it ignores keystrokes.
Signed-off-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>
      b4a2f5e7
    • R
      x86: fix buffer overflow in efi_init() · fdb8a427
      由 Roel Kluin 提交于 
      If the vendor name (from c16) can be longer than 100 bytes (or missing a
terminating null), then the null is written past the end of vendor[].

Found with Parfait, http://research.sun.com/projects/parfait/Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Huang Ying <ying.huang@intel.com>
      fdb8a427
    • F
      drm/i915: silence vblank warnings · 6cb504c2
      由 Frans Pop 提交于 
      these errors are pretty pointless
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      6cb504c2
    • P
      drm: silence pointless vblank warning. · 8d3457ec
      由 Paul Rolland 提交于 
      Some applications/hardware combinations are triggering the message "failed to
acquire vblank counter" to be issued up to 20 times a second, which makes it
both useless and dangerous, as this may hide other important messages.
This changes makes it only appear when people are debugging.
Signed-off-by: NPaul Rolland <rol@as2917.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Lost-twice-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      8d3457ec
    • K
      drm: When adding probed modes, preserve duplicate mode types · 38d5487d
      由 Keith Packard 提交于 
      The code which takes probed modes and adds them to a connector eliminates
duplicate modes by comparing them using drm_mode_equal. That function
doesn't consider the type bits, which means that any modes which differ only
in the type field will be lost.

One of the bits in the mode->type field is the DRM_MODE_TYPE_PREFERRED bit.
If the mode with that bit is lost, then higher level code will not know
which mode to select, causing a random mode to be used instead.

This patch simply merges the two mode type bits together; that seems
reasonable to me, but perhaps only a subset of the bits should be used? None
of these can be user defined as they all come from looking at just the
hardware.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      38d5487d