linux-toradex.git, branch v2.6.27.60

Linux 2.6.27.60

2012-02-11T14:40:57+00:00

Signed-off-by: Willy Tarreau

dm: do not forward ioctls from logical volumes to the underlying device

2012-02-11T14:40:56+00:00

commit ec8013beddd717d1740cfefb1a9b900deef85462 upstream.

A logical volume can map to just part of underlying physical volume.
In this case, it must be treated like a partition.

Based on a patch from Alasdair G Kergon.

Cc: Alasdair G Kergon 
Cc: dm-devel@redhat.com
Signed-off-by: Paolo Bonzini 
Signed-off-by: Linus Torvalds 
[bwh: Backport to 2.6.32 - drop change to drivers/md/dm-flakey.c]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Willy Tarreau

block: fail SCSI passthrough ioctls on partition devices

2012-02-11T14:40:55+00:00

commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream.

[ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
  and -ENOIOCTLCMD from sd_compat_ioctl. ]

Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device.  This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.

This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice.  Still, I'm treating it specially to avoid spamming the logs.

In principle, this restriction should include programs running with
CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities.  However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls.  Their actions will still be logged.

This patch does not affect the non-libata IDE driver.  That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe 
Cc: James Bottomley 
Signed-off-by: Paolo Bonzini 
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds 
[bwh: Backport to 2.6.32 - ENOIOCTLCMD does not get converted to
 ENOTTY, so we must return ENOTTY directly]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Willy Tarreau

block: add and use scsi_blk_cmd_ioctl

2012-02-11T14:40:54+00:00

commit 577ebb374c78314ac4617242f509e2f5e7156649 upstream.

Introduce a wrapper around scsi_cmd_ioctl that takes a block device.

The function will then be enhanced to detect partition block devices
and, in that case, subject the ioctls to whitelisting.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe 
Cc: James Bottomley 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backport to 2.6.32 - adjust context]
Signed-off-by: Ben Hutchings 
[wt: slightly changed the interface to match 2.6.27's scsi_cmd_ioctl()
     which still needs the file pointer but has no mode parameter].

Signed-off-by: Willy Tarreau

i8k: Avoid lahf in 64-bit code

2012-02-11T14:40:53+00:00

commit bc1f419c76a2d6450413ce4349f4e4a07be011d5 upstream.

i8k uses lahf to read the flag register in 64-bit code; early x86-64
CPUs, however, lack this instruction and we get an invalid opcode
exception at runtime.
Use pushf to load the flag register into the stack instead.

Signed-off-by: Luca Tettamanti 
Reported-by: Jeff Rickman 
Tested-by: Jeff Rickman 
Tested-by: Harry G McGavran Jr 
Cc: Massimo Dal Zotto 
Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

kbuild: Fix passing -Wno-* options to gcc 4.4+

2012-02-11T14:40:52+00:00

commit 8417da6f2128008c431c7d130af6cd3d9079922e upstream.

Starting with 4.4, gcc will happily accept -Wno- in the
cc-option test and complain later when compiling a file that has some
other warning. This rather unexpected behavior is intentional as per
http://gcc.gnu.org/PR28322, so work around it by testing for support of
the opposite option (without the no-). Introduce a new Makefile function
cc-disable-warning that does this and update two uses of cc-option in
the toplevel Makefile.

Reported-and-tested-by: Stephen Rothwell 
Signed-off-by: Michal Marek 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

kbuild: Disable -Wunused-but-set-variable for gcc 4.6.0

2012-02-11T14:40:52+00:00

commit af0e5d565d2fffcd97d1e2d89669d627cc04e8b8 upstream.

Disable the new -Wunused-but-set-variable that was added in gcc 4.6.0
It produces more false positives than useful warnings.

This can still be enabled using W=1
[gregkh - No it can not for 2.6.32, but we don't care]

Signed-off-by: Dave Jones 
Acked-by: Sam Ravnborg 
Tested-by: Sam Ravnborg 
Signed-off-by: Michal Marek 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

Fix gcc 4.5.1 miscompiling drivers/char/i8k.c (again)

2012-02-11T14:40:51+00:00

commit 22d3243de86bc92d874abb7c5b185d5c47aba323 upstream.

The fix in commit 6b4e81db2552 ("i8k: Tell gcc that *regs gets
clobbered") to work around the gcc miscompiling i8k.c to add "+m
(*regs)" caused register pressure problems and a build failure.

Changing the 'asm' statement to 'asm volatile' instead should prevent
that and works around the gcc bug as well, so we can remove the "+m".

[ Background on the gcc bug: a memory clobber fails to mark the function
  the asm resides in as non-pure (aka "__attribute__((const))"), so if
  the function does nothing else that triggers the non-pure logic, gcc
  will think that that function has no side effects at all. As a result,
  callers will be mis-compiled.

  Adding the "+m" made gcc see that it's not a pure function, and so
  does "asm volatile". The problem was never really the need to mark
  "*regs" as changed, since the memory clobber did that part - the
  problem was just a bug in the gcc "pure" function analysis  - Linus ]

Signed-off-by: Jim Bos 
Acked-by: Jakub Jelinek 
Cc: Andi Kleen 
Cc: Andreas Schwab 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

i8k: Tell gcc that *regs gets clobbered

2012-02-11T14:40:50+00:00

commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48 upstream.

More recent GCC caused the i8k driver to stop working, on Slackware
compiler was upgraded from gcc-4.4.4 to gcc-4.5.1 after which it didn't
work anymore, meaning the driver didn't load or gave total nonsensical
output.

As it turned out the asm(..) statement forgot to mention it modifies the
*regs variable.

Credits to Andi Kleen and Andreas Schwab for providing the fix.

Signed-off-by: Jim Bos 
Cc: Andi Kleen 
Cc: Andreas Schwab 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

x86: Fix mmap random address range

2012-02-11T14:40:49+00:00

commit 9af0c7a6fa860698d080481f24a342ba74b68982 upstream.

On x86_32 casting the unsigned int result of get_random_int() to
long may result in a negative value.  On x86_32 the range of
mmap_rnd() therefore was -255 to 255.  The 32bit mode on x86_64
used 0 to 255 as intended.

The bug was introduced by 675a081 ("x86: unify mmap_{32|64}.c")
in January 2008.

Signed-off-by: Ludwig Nussel 
Cc: Linus Torvalds 
Cc: harvey.harrison@gmail.com
Cc: "H. Peter Anvin" 
Cc: Harvey Harrison 
Signed-off-by: Andrew Morton 
Link: http://lkml.kernel.org/r/201111152246.pAFMklOB028527@wpaz5.hot.corp.google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau