Skip to content

GitLab

Switch branch/tag
  1. 29 Sep, 2008 2 commits
    • zippel@linux-m68k.org's avatar
      kconfig: fix silentoldconfig · 204c96f6
      zippel@linux-m68k.org authored 
      
Recent changes to oldconfig have mixed up the silentoldconfig handling,
so this fixes that by clearly separating that special mode, e.g.
KCONFIG_NOSILENTUPDATE is only relevant here, the .config is written as
needed.

This will also properly close Bug 11230.
Signed-off-by: default avatarRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      204c96f6
    • Linus Torvalds's avatar
      Fix NULL pointer dereference in proc_sys_compare · d0185c08
      Linus Torvalds authored 
      
The VFS interface for the 'd_compare()' is a bit special (read: 'odd'),
because it really just essentially replaces a memcmp().  The filesystem
is supposed to just compare the two names with whatever case-independent
or other function.

And when I say 'is supposed to', I obviously mean that 'procfs does odd
things, and actually looks at the dentry that we don't even pass down,
rather than just the name'.  Which results in problems, because we
actually call d_compare before we have even verified that the dentry is
still hashed at all.

And that causes a problm since the inode that procfs looks at may have
been free'd and the d_inode pointer is NULL.  procfs just assumes that
all dentries are positive, since procfs itself never generates a
negative one.  But memory pressure will still result in the dentry
getting torn down, and as it is removed by RCU, it still remains visible
on some lists - and to d_compare.

If the filesystem just did a name comparison, we wouldn't care.  And we
could just fix procfs to know about negative dentries too.  But rather
than have the low-level filesystems know about internal VFS details,
just move the check for a unhashed dentry up a bit, so that we will only
call d_compare on dentries that are still active.

The actual oops this caused didn't look like a NULL pointer dereference
because procfs did a 'container_of(inode, struct proc_inode, vfs_inode)'
to get at its internal proc_inode information from the inode pointer,
and accessed a field below the inode. So the oops would look something
like

	BUG: unable to handle kernel paging request at fffffffffffffff0
	IP: [<ffffffff802bc6c6>] proc_sys_compare+0x36/0x50

and was seen on both x86-64 (Alexey Dobriyan and Hugh Dickins) and
ppc64 (Hugh Dickins).
Reported-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
Acked-by: default avatarHugh Dickins <hugh@veritas.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Reviewed-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
Signed-of-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d0185c08
  3. 26 Sep, 2008 4 commits
  5. 25 Sep, 2008 5 commits
    • Lachlan McIlroy's avatar
      [XFS] Remove xfs_iext_irec_compact_full() · 71a8c87f
      Lachlan McIlroy authored 
      
Yet another bug was found in xfs_iext_irec_compact_full() and while the
source of the bug was found it wasn't an easy task to track it down
because the conditions are very difficult to reproduce.

A HUGE thank-you goes to Russell Cattelan and Eric Sandeen for their
significant effort in tracking down the source of this corruption.

xfs_iext_irec_compact_full() and xfs_iext_irec_compact_pages() are almost
identical - they both compact indirect extent lists by moving extents from
subsequent buffers into earlier ones. xfs_iext_irec_compact_pages() only
moves extents if all of the extents in the next buffer will fit into the
empty space in the buffer before it. xfs_iext_irec_compact_full() will go
a step further and move part of the next buffer if all the extents wont
fit. It will then shift the remaining extents in the next buffer up to the
start of the buffer. The bug here was that we did not update er_extoff and
this caused extent list corruption.

It does not appear that this extra functionality gains us much. Calling
xfs_iext_irec_compact_pages() instead will do a good enough job at
compacting the indirect list and will be quicker too.

For the case in xfs_iext_indirect_to_direct() the total number of extents
in the indirect list will fit into one buffer so we will never need the
extra functionality of xfs_iext_irec_compact_full() there.

Also xfs_iext_irec_compact_pages() doesn't need to do a memmove() (the
buffers will never overlap) so we don't want the performance hit that can
incur.

SGI-PV: 987159

SGI-Modid: xfs-linux-melb:xfs-kern:32166a
Signed-off-by: default avatarLachlan McIlroy <lachlan@sgi.com>
Signed-off-by: default avatarEric Sandeen <sandeen@sandeen.net>
      71a8c87f
    • Lachlan McIlroy's avatar
      [XFS] Fix extent list corruption in xfs_iext_irec_compact_full(). · f1ccd295
      Lachlan McIlroy authored 
      
If we don't move all the records from the next buffer into the current
buffer then we need to update the er_extoff field of the next buffer as we
shift the remaining records to the start of the buffer.

SGI-PV: 987159

SGI-Modid: xfs-linux-melb:xfs-kern:32165a
Signed-off-by: default avatarLachlan McIlroy <lachlan@sgi.com>
Signed-off-by: default avatarEric Sandeen <sandeen@sandeen.net>
Signed-off-by: default avatarRussell Cattelan <cattelan@thebarn.com>
      f1ccd295
    • Roland Dreier's avatar
      IPoIB: Fix crash when path record fails after path flush · 6ef190cc
      Roland Dreier authored 
      Commit ee1e2c82 ("IPoIB: Refresh paths instead of flushing them on SM
change events") changed how paths are flushed on an SM event.  This
change introduces a problem if the path record query triggered by
fails, causing path->ah to become NULL.  A later successful path query
will then trigger WARN_ON() in path_rec_completion(), and crash
because path->ah has already been freed, so the ipoib_put_ah() inside
the lock in path_rec_completion() may actually drop the last reference
(contrary to the comment that claims this is safe).

Fix this by updating path->ah and freeing old_ah only when the path
record query is successful.  This prevents the neighbour AH and that
path AH from getting out of sync.

This fixes <https://bugs.openfabrics.org/show_bug.cgi?id=1194

>
Reported-by: default avatarRabah Salem <ravah@mellanox.com>
Debugged-by: default avatarEli Cohen <eli@mellanox.co.il>
Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6ef190cc
    • Takashi Iwai's avatar
      ALSA: remove unneeded power_mutex lock in snd_pcm_drop · 24e8fc49
      Takashi Iwai authored 
      
The power_mutex lock in snd_pcm_drop may cause a possible deadlock
chain, and above all, it's unneeded.  Let's get rid of it.
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      24e8fc49
    • Takashi Iwai's avatar
      ALSA: fix locking in snd_pcm_open*() and snd_rawmidi_open*() · 399ccdc1
      Takashi Iwai authored 
      
The PCM and rawmidi open callbacks have a lock against card->controls_list
but it takes a wrong one, card->controls_rwsem, instead of a right one
card->ctl_files_rwlock.  This patch fixes them.

This change also fixes automatically the potential deadlocks due to
mm->mmap_sem in munmap and copy_from/to_user, reported by Sitsofe
Wheeler:

  A: snd_ctl_elem_user_tlv(): card->controls_rwsem => mm->mmap_sem
  B: snd_pcm_open(): card->open_mutex => card->controls_rwsem
  C: munmap: mm->mmap_sem => snd_pcm_release(): card->open_mutex

The patch breaks the chain.
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      399ccdc1
  7. 24 Sep, 2008 22 commits
  9. 23 Sep, 2008 7 commits