Skip to content
  1. Nov 24, 2012
  3. Nov 23, 2012
  5. Nov 22, 2012
    • Aaro Koskinen's avatar
      OMAPDSS: do not fail if dpll4_m4_ck is missing · 8ad9375f
      Aaro Koskinen authored 
      Do not fail if dpll4_m4_ck is missing. The clock is not there on omap24xx,
so this should not be a hard error.

The patch retains the functionality before the commit 185bae10

 (OMAPDSS:
DSS: Cleanup cpu_is_xxxx checks).

Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      8ad9375f
    • Al Viro's avatar
      [PARISC] fix user-triggerable panic on parisc · 441a179d
      Al Viro authored 
      

int sys32_rt_sigprocmask(int how, compat_sigset_t __user *set, compat_sigset_t __user *oset,
                                    unsigned int sigsetsize)
{
        sigset_t old_set, new_set;
        int ret;

        if (set && get_sigset32(set, &new_set, sigsetsize))

...
static int
get_sigset32(compat_sigset_t __user *up, sigset_t *set, size_t sz)
{
        compat_sigset_t s;
        int r;

        if (sz != sizeof *set) panic("put_sigset32()");

In other words, rt_sigprocmask(69, (void *)69, 69) done by 32bit process
will promptly panic the box.

Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      441a179d
    • NeilBrown's avatar
      md/raid10: decrement correct pending counter when writing to replacement. · 884162df
      NeilBrown authored 
      

When a write to a replacement device completes, we carefully
and correctly found the rdev that the write actually went to
and the blithely called rdev_dec_pending on the primary rdev,
even if this write was to the replacement.

This means that any writes to an array while a replacement
was ongoing would cause the nr_pending count for the primary
device to go negative, so it could never be removed.

This bug has been present since replacement was introduced in
3.3, so it is suitable for any -stable kernel since then.

Reported-by: default avatar"George Spelvin" <linux@horizon.com>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      884162df
    • NeilBrown's avatar
      md/raid10: close race that lose writes lost when replacement completes. · e7c0c3fa
      NeilBrown authored 
      

When a replacement operation completes there is a small window
when the original device is marked 'faulty' and the replacement
still looks like a replacement.  The faulty should be removed and
the replacement moved in place very quickly, bit it isn't instant.

So the code write out to the array must handle the possibility that
the only working device for some slot in the replacement - but it
doesn't.  If the primary device is faulty it just gives up.  This
can lead to corruption.

So make the code more robust: if either  the primary or the
replacement is present and working, write to them.  Only when
neither are present do we give up.

This bug has been present since replacement was introduced in
3.3, so it is suitable for any -stable kernel since then.

Reported-by: default avatar"George Spelvin" <linux@horizon.com>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      e7c0c3fa