Skip to content

L
linux
Switch branch/tag
  1. 19 Dec, 2011 2 commits
  3. 10 Dec, 2011 10 commits
  5. 08 Dec, 2011 1 commit
  7. 07 Dec, 2011 7 commits
    • Anton Vorontsov's avatar
      of/irq: Get rid of NO_IRQ usage · 77a7300a
      Anton Vorontsov authored 
      PPC32/64 defines NO_IRQ to zero, so no problems expected.
ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
which returns correct ('0') value in 'no irq' case. So everything
should be fine.

Other arches might break if some of their OF drivers rely on NO_IRQ
being not 0. If so, the drivers must be fixed, finally.

[ Rob Herring points out that microblaze should be fixed, and has posted
  a patch for testing for that.   - Linus ]
Signed-off-by: default avatarAnton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: default avatarWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      77a7300a
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 10ec5e6c
      Linus Torvalds authored 
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  vmwgfx: Use kcalloc instead of kzalloc to allocate array
  drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
  drm/radeon/kms: fix return type for radeon_encoder_get_dp_bridge_encoder_id
      10ec5e6c
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 3172f8fe
      Linus Torvalds authored 
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  fix apparmor dereferencing potentially freed dentry, sanitize __d_path() API
      3172f8fe
    • Thomas Meyer's avatar
      vmwgfx: Use kcalloc instead of kzalloc to allocate array · 24bb5a0c
      Thomas Meyer authored 
      The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.

The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107Signed-off-by: default avatarThomas Meyer <thomas@m3y3r.de>
Reviewed-by: default avatarJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      24bb5a0c
    • Daniel Vetter's avatar
      drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a · eb1711bb
      Daniel Vetter authored 
      The recursion loop goes retire_requests->unbind->gpu_idle->retire_reqeusts.

Every time we go through this we need a
- active object that can be retired
- and there are no other references to that object than the one from
  the active list, so that it gets unbound and freed immediately.
Otherwise the recursion stops. So the recursion is only limited by the
number of objects that fit these requirements sitting in the active list
any time retire_request is called.

Issue exercised by tests/gem_unref_active_buffers from i-g-t.

There's been a decent bikeshed discussion whether it wouldn't be
better to pass around a flag, but imo this is o.k. for such a limited
case that only supports a w/a.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42180Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: default avatarChris Wilson <chris@chris-wilson>
[ickle- we built better bikesheds, but this keeps the rain off for now]
Tested-by: default avatarDave Airlie <airlied@redhat.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      eb1711bb
    • Alex Deucher's avatar
      drm/radeon/kms: fix return type for radeon_encoder_get_dp_bridge_encoder_id · dc87cd5c
      Alex Deucher authored 
      Seems like something got mis-merged here.

Noticed by kallisti5 on IRC.
Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      dc87cd5c
    • Al Viro's avatar
      fix apparmor dereferencing potentially freed dentry, sanitize __d_path() API · 02125a82
      Al Viro authored 
      __d_path() API is asking for trouble and in case of apparmor d_namespace_path()
getting just that.  The root cause is that when __d_path() misses the root
it had been told to look for, it stores the location of the most remote ancestor
in *root.  Without grabbing references.  Sure, at the moment of call it had
been pinned down by what we have in *path.  And if we raced with umount -l, we
could have very well stopped at vfsmount/dentry that got freed as soon as
prepend_path() dropped vfsmount_lock.

It is safe to compare these pointers with pre-existing (and known to be still
alive) vfsmount and dentry, as long as all we are asking is "is it the same
address?".  Dereferencing is not safe and apparmor ended up stepping into
that.  d_namespace_path() really wants to examine the place where we stopped,
even if it's not connected to our namespace.  As the result, it looked
at ->d_sb->s_magic of a dentry that might've been already freed by that point.
All other callers had been careful enough to avoid that, but it's really
a bad interface - it invites that kind of trouble.

The fix is fairly straightforward, even though it's bigger than I'd like:
	* prepend_path() root argument becomes const.
	* __d_path() is never called with NULL/NULL root.  It was a kludge
to start with.  Instead, we have an explicit function - d_absolute_root().
Same as __d_path(), except that it doesn't get root passed and stops where
it stops.  apparmor and tomoyo are using it.
	* __d_path() returns NULL on path outside of root.  The main
caller is show_mountinfo() and that's precisely what we pass root for - to
skip those outside chroot jail.  Those who don't want that can (and do)
use d_path().
	* __d_path() root argument becomes const.  Everyone agrees, I hope.
	* apparmor does *NOT* try to use __d_path() or any of its variants
when it sees that path->mnt is an internal vfsmount.  In that case it's
definitely not mounted anywhere and dentry_path() is exactly what we want
there.  Handling of sysctl()-triggered weirdness is moved to that place.
	* if apparmor is asked to do pathname relative to chroot jail
and __d_path() tells it we it's not in that jail, the sucker just calls
d_absolute_path() instead.  That's the other remaining caller of __d_path(),
BTW.
        * seq_path_root() does _NOT_ return -ENAMETOOLONG (it's stupid anyway -
the normal seq_file logics will take care of growing the buffer and redoing
the call of ->show() just fine).  However, if it gets path not reachable
from root, it returns SEQ_SKIP.  The only caller adjusted (i.e. stopped
ignoring the return value as it used to do).
Reviewed-by: default avatarJohn Johansen <john.johansen@canonical.com>
ACKed-by: default avatarJohn Johansen <john.johansen@canonical.com>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org
      02125a82
  9. 06 Dec, 2011 12 commits
  11. 05 Dec, 2011 8 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6 · 35337c83
      Linus Torvalds authored 
      * 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:
  [S390] ap: Setup timer for sending messages after reset.
  [S390] cio: fix chsc_chp_vary
  [S390] cio: provide fake irb for transport mode IO
  [S390] cio: disallow driver io for known to be broken paths
  [S390] hibernate: directly trigger subchannel evaluation
  [S390] remove reset of system call restart on psw changes
  [S390] add missing .set function for NT_S390_LAST_BREAK regset
  [S390] fix page change underindication in pgste_update_all
  [S390] ptrace inferior call interactions with TIF_SYSCALL
  [S390] kdump: Replace is_kdump_kernel() with OLDMEM_BASE check
      35337c83
    • françois romieu's avatar
      r8169: fix Rx index race between FIFO overflow recovery and NAPI handler. · c7c2c39b
      françois romieu authored 
      Since 92fc43b4, rtl8169_tx_timeout ends up
resetting Rx and Tx indexes and thus racing with the NAPI handler via
-> rtl8169_hw_reset
   -> rtl_hw_reset
      -> rtl8169_init_ring_indexes

What about returning to the original state ?

rtl_hw_reset is only used by rtl8169_hw_reset and rtl8169_init_one.

The latter does not need rtl8169_init_ring_indexes because the indexes
still contain their original values from the newly allocated network
device private data area (i.e. 0).

rtl8169_hw_reset is used by:
1. rtl8169_down
   Helper for rtl8169_close. rtl8169_open explicitely inits the indexes
   anyway.
2. rtl8169_pcierr_interrupt
   Indexes are set by rtl8169_reinit_task.
3. rtl8169_interrupt
   rtl8169_hw_reset is needed when the device goes down. See 1.
4. rtl_shutdown
   System shutdown handler. Indexes are irrelevant.
5. rtl8169_reset_task
   Indexes must be set before rtl_hw_start is called.
6. rtl8169_tx_timeout
   Indexes should not be set. This is the job of rtl8169_reset_task anyway.

The removal of rtl8169_hw_reset in rtl8169_tx_timeout and its move in
rtl8169_reset_task do not change the analysis.
Signed-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
Cc: hayeswang <hayeswang@realtek.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7c2c39b
    • françois romieu's avatar
      r8169: Rx FIFO overflow fixes. · 811fd301
      françois romieu authored 
      Realtek has specified that the post 8168c gigabit chips and the post
8105e fast ethernet chips recover automatically from a Rx FIFO overflow.
The driver does not need to clear the RxFIFOOver bit of IntrStatus and
it should rather avoid messing it.

The implementation deserves some explanation:
1. events outside of the intr_event bit mask are now ignored. It enforces
   a no-processing policy for the events that either should not be there
   or should be ignored.

2. RxFIFOOver was already ignored in rtl_cfg_infos[RTL_CFG_1] for the
   whole 8168 line of chips with two exceptions:
   - RTL_GIGA_MAC_VER_22 since b5ba6d12
     ("use RxFIFO overflow workaround for 8168c chipset.").
     This one should now be correctly handled.
   - RTL_GIGA_MAC_VER_11 (8168b) which requires a different Rx FIFO
     overflow processing.

   Though it does not conform to Realtek suggestion above, the updated
   driver includes no change for RTL_GIGA_MAC_VER_12 and RTL_GIGA_MAC_VER_17.
   Both are 8168b. RTL_GIGA_MAC_VER_12 is common and a bit old so I'd rather
   wait for experimental evidence that the change suggested by Realtek really
   helps or does not hurt in unexpected ways.

   Removed case statements in rtl8169_interrupt are only 8168 relevant.

3. RxFIFOOver is masked for post 8105e 810x chips, namely the sole 8105e
   (RTL_GIGA_MAC_VER_30) itself.
Signed-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
Cc: hayeswang <hayeswang@realtek.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      811fd301
    • Linus Walleij's avatar
      gpio: fix a build failure on KS8695 GPIO · 8c9b0434
      Linus Walleij authored 
      I screwed up by compiling that driver for the machine rather
than the arch. Correcting this fixes the build error.

Cc: Grant Likely <grant.likely@secretlab.ca>
Reported-by: default avatarMike Frysinger <vapier@gentoo.org>
Signed-off-by: default avatarLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8c9b0434
    • Steven Rostedt's avatar
      ftrace: Fix hash record accounting bug · ddf6e0e5
      Steven Rostedt authored 
      If the set_ftrace_filter is cleared by writing just whitespace to
it, then the filter hash refcounts will be decremented but not
updated. This causes two bugs:

1) No functions will be enabled for tracing when they all should be

2) If the users clears the set_ftrace_filter twice, it will crash ftrace:

------------[ cut here ]------------
WARNING: at /home/rostedt/work/git/linux-trace.git/kernel/trace/ftrace.c:1384 __ftrace_hash_rec_update.part.27+0x157/0x1a7()
Modules linked in:
Pid: 2330, comm: bash Not tainted 3.1.0-test+ #32
Call Trace:
 [<ffffffff81051828>] warn_slowpath_common+0x83/0x9b
 [<ffffffff8105185a>] warn_slowpath_null+0x1a/0x1c
 [<ffffffff810ba362>] __ftrace_hash_rec_update.part.27+0x157/0x1a7
 [<ffffffff810ba6e8>] ? ftrace_regex_release+0xa7/0x10f
 [<ffffffff8111bdfe>] ? kfree+0xe5/0x115
 [<ffffffff810ba51e>] ftrace_hash_move+0x2e/0x151
 [<ffffffff810ba6fb>] ftrace_regex_release+0xba/0x10f
 [<ffffffff8112e49a>] fput+0xfd/0x1c2
 [<ffffffff8112b54c>] filp_close+0x6d/0x78
 [<ffffffff8113a92d>] sys_dup3+0x197/0x1c1
 [<ffffffff8113a9a6>] sys_dup2+0x4f/0x54
 [<ffffffff8150cac2>] system_call_fastpath+0x16/0x1b
---[ end trace 77a3a7ee73794a02 ]---

Link: http://lkml.kernel.org/r/20111101141420.GA4918@debianReported-by: default avatarRabin Vincent <rabin@rab.in>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      ddf6e0e5
    • Steven Rostedt's avatar
      perf: Fix parsing of __print_flags() in TP_printk() · d06c27b2
      Steven Rostedt authored 
      A update is made to the sched:sched_switch event that adds some
logic to the first parameter of the __print_flags() that shows the
state of tasks. This change cause perf to fail parsing the flags.

A simple fix is needed to have the parser be able to process ops
within the argument.

Cc: stable@vger.kernel.org
Reported-by: default avatarAndrew Vagin <avagin@openvz.org>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      d06c27b2
    • Gleb Natapov's avatar
      jump_label: jump_label_inc may return before the code is patched · bbbf7af4
      Gleb Natapov authored 
      If cpu A calls jump_label_inc() just after atomic_add_return() is
called by cpu B, atomic_inc_not_zero() will return value greater then
zero and jump_label_inc() will return to a caller before jump_label_update()
finishes its job on cpu B.

Link: http://lkml.kernel.org/r/20111018175551.GH17571@redhat.com

Cc: stable@vger.kernel.org
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: default avatarJason Baron <jbaron@redhat.com>
Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      bbbf7af4
    • Steven Rostedt's avatar
      ftrace: Remove force undef config value left for testing · c7c6ec8b
      Steven Rostedt authored 
      A forced undef of a config value was used for testing and was
accidently left in during the final commit. This causes x86 to
run slower than needed while running function tracing as well
as causes the function graph selftest to fail when DYNMAIC_FTRACE
is not set. This is because the code in MCOUNT expects the ftrace
code to be processed with the config value set that happened to
be forced not set.

The forced config option was left in by:
    commit 6331c28c
    ftrace: Fix dynamic selftest failure on some archs

Link: http://lkml.kernel.org/r/20111102150255.GA6973@debian

Cc: stable@vger.kernel.org
Reported-by: default avatarRabin Vincent <rabin@rab.in>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      c7c6ec8b
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7