Skip to content

L
linux
Switch branch/tag
  1. 18 Oct, 2010 18 commits
  3. 14 Oct, 2010 4 commits
    • Linus Torvalds's avatar
      Linux 2.6.36-rc8 · cd07202c
      Linus Torvalds authored
      cd07202c
    • Linus Torvalds's avatar
      Un-inline the core-dump helper functions · 3aa0ce82
      Linus Torvalds authored 
      Tony Luck reports that the addition of the access_ok() check in commit
0eead9ab ("Don't dump task struct in a.out core-dumps") broke the
ia64 compile due to missing the necessary header file includes.

Rather than add yet another include (<asm/unistd.h>) to make everything
happy, just uninline the silly core dump helper functions and move the
bodies to fs/exec.c where they make a lot more sense.

dump_seek() in particular was too big to be an inline function anyway,
and none of them are in any way performance-critical.  And we really
don't need to mess up our include file headers more than they already
are.
Reported-and-tested-by: default avatarTony Luck <tony.luck@gmail.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3aa0ce82
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · ae42d8d4
      Linus Torvalds authored 
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
  ehea: Fix a checksum issue on the receive path
  net: allow FEC driver to use fixed PHY support
  tg3: restore rx_dropped accounting
  b44: fix carrier detection on bind
  net: clear heap allocations for privileged ethtool actions
  NET: wimax, fix use after free
  ATM: iphase, remove sleep-inside-atomic
  ATM: mpc, fix use after free
  ATM: solos-pci, remove use after free
  net/fec: carrier off initially to avoid root mount failure
  r8169: use device model DMA API
  r8169: allocate with GFP_KERNEL flag when able to sleep
      ae42d8d4
    • Linus Torvalds's avatar
      Don't dump task struct in a.out core-dumps · 0eead9ab
      Linus Torvalds authored 
      akiphie points out that a.out core-dumps have that odd task struct
dumping that was never used and was never really a good idea (it goes
back into the mists of history, probably the original core-dumping
code).  Just remove it.

Also do the access_ok() check on dump_write().  It probably doesn't
matter (since normal filesystems all seem to do it anyway), but he
points out that it's normally done by the VFS layer, so ...

[ I suspect that we should possibly do "vfs_write()" instead of
  calling ->write directly.  That also does the whole fsnotify and write
  statistics thing, which may or may not be a good idea. ]

And just to be anal, do this all for the x86-64 32-bit a.out emulation
code too, even though it's not enabled (and won't currently even
compile)
Reported-by: default avatarakiphie <akiphie@lavabit.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0eead9ab
  5. 13 Oct, 2010 11 commits
  7. 12 Oct, 2010 7 commits
    • Russell King's avatar
      ARM: relax ioremap prohibition (309caa9c) for -final and -stable · 06c10884
      Russell King authored 
      ... but produce a big warning about the problem as encouragement
for people to fix their drivers.
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      06c10884
    • Russell King's avatar
      Merge branch 'for-rmk' of git://git.pengutronix.de/git/imx/linux-2.6 · 841f48a8
      Russell King authored
      841f48a8
    • Mika Westerberg's avatar
      ARM: 6440/1: ep93xx: DMA: fix channel_disable · 10d48b39
      Mika Westerberg authored 
      When channel_disable() is called, it disables per channel interrupts and
waits until channels state becomes STATE_STALL, and then disables the
channel. Now, if the DMA transfer is disabled while the channel is in
STATE_NEXT we will not wait anything and disable the channel immediately.
This seems to cause weird data corruption for example in audio transfers.

Fix is to wait while we are in STATE_NEXT or STATE_ON and only then
disable the channel.
Signed-off-by: default avatarMika Westerberg <mika.westerberg@iki.fi>
Acked-by: default avatarRyan Mallon <ryan@bluewatersys.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      10d48b39
    • Linus Torvalds's avatar
      Merge branch 'kvm-updates/2.6.36' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 0acc1b2a
      Linus Torvalds authored 
      * 'kvm-updates/2.6.36' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86: Move TSC reset out of vmcb_init
  KVM: x86: Fix SVM VMCB reset
      0acc1b2a
    • Steven Rostedt's avatar
      ring-buffer: Fix typo of time extends per page · d0134324
      Steven Rostedt authored 
      Time stamps for the ring buffer are created by the difference between
two events. Each page of the ring buffer holds a full 64 bit timestamp.
Each event has a 27 bit delta stamp from the last event. The unit of time
is nanoseconds, so 27 bits can hold ~134 milliseconds. If two events
happen more than 134 milliseconds apart, a time extend is inserted
to add more bits for the delta. The time extend has 59 bits, which
is good for ~18 years.

Currently the time extend is committed separately from the event.
If an event is discarded before it is committed, due to filtering,
the time extend still exists. If all events are being filtered, then
after ~134 milliseconds a new time extend will be added to the buffer.

This can only happen till the end of the page. Since each page holds
a full timestamp, there is no reason to add a time extend to the
beginning of a page. Time extends can only fill a page that has actual
data at the beginning, so there is no fear that time extends will fill
more than a page without any data.

When reading an event, a loop is made to skip over time extends
since they are only used to maintain the time stamp and are never
given to the caller. As a paranoid check to prevent the loop running
forever, with the knowledge that time extends may only fill a page,
a check is made that tests the iteration of the loop, and if the
iteration is more than the number of time extends that can fit in a page
a warning is printed and the ring buffer is disabled (all of ftrace
is also disabled with it).

There is another event type that is called a TIMESTAMP which can
hold 64 bits of data in the theoretical case that two events happen
18 years apart. This code has not been implemented, but the name
of this event exists, as well as the structure for it. The
size of a TIMESTAMP is 16 bytes, where as a time extend is only
8 bytes. The macro used to calculate how many time extends can fit on
a page used the TIMESTAMP size instead of the time extend size
cutting the amount in half.

The following test case can easily trigger the warning since we only
need to have half the page filled with time extends to trigger the
warning:

 # cd /sys/kernel/debug/tracing/
 # echo function > current_tracer
 # echo 'common_pid < 0' > events/ftrace/function/filter
 # echo > trace
 # echo 1 > trace_marker
 # sleep 120
 # cat trace

Enabling the function tracer and then setting the filter to only trace
functions where the process id is negative (no events), then clearing
the trace buffer to ensure that we have nothing in the buffer,
then write to trace_marker to add an event to the beginning of a page,
sleep for 2 minutes (only 35 seconds is probably needed, but this
guarantees the bug), and then finally reading the trace which will
trigger the bug.

This patch fixes the typo and prevents the false positive of that warning.
Reported-by: default avatarHans J. Koch <hjk@linutronix.de>
Tested-by: default avatarHans J. Koch <hjk@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Stable Kernel <stable@kernel.org>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      d0134324
    • Deng-Cheng Zhu's avatar
      perf, MIPS: Support cross compiling of tools/perf for MIPS · c1e028ef
      Deng-Cheng Zhu authored 
      Changes:
 v4: Fix the cosmetic issue of redundant dot-ops
 v3: Change rmb() to use SYNC
 v2: Include mips unistd.h and define rmb()/cpu_relax() in tools/perf/perf.h
Signed-off-by: default avatarDeng-Cheng Zhu <dengcheng.zhu@gmail.com>
Acked-by: default avatarRalf Baechle <ralf@linux-mips.org>
Cc: David Daney <ddaney@caviumnetworks.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c1e028ef
    • Jean Delvare's avatar
      drm/radeon/kms: Silent spurious error message · a8c051f0
      Jean Delvare authored 
      I see the following error message in my kernel log from time to time:
radeon 0000:07:00.0: ffff88007c334000 reserve failed for wait
radeon 0000:07:00.0: ffff88007c334000 reserve failed for wait

After investigation, it turns out that there's nothing to be afraid of
and everything works as intended. So remove the spurious log message.
Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
Reviewed-by: default avatarJerome Glisse <jglisse@redhat.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      a8c051f0
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7