linux-toradex.git/include/linux, branch v3.7.3

libceph: remove 'osdtimeout' option

2013-01-17T16:46:48+00:00

(cherry picked from commit 83aff95eb9d60aff5497e9f44a2ae906b86d8e88)

This would reset a connection with any OSD that had an outstanding
request that was taking more than N seconds.  The idea was that if the
OSD was buggy, the client could compensate by resending the request.

In reality, this only served to hide server bugs, and we haven't
actually seen such a bug in quite a while.  Moreover, the userspace
client code never did this.

More importantly, often the request is taking a long time because the
OSD is trying to recover, or overloaded, and killing the connection
and retrying would only make the situation worse by giving the OSD
more work to do.

Signed-off-by: Sage Weil 
Reviewed-by: Alex Elder 
Signed-off-by: Greg Kroah-Hartman

audit: create explicit AUDIT_SECCOMP event type

2013-01-17T16:46:22+00:00

commit 7b9205bd775afc4439ed86d617f9042ee9e76a71 upstream.

The seccomp path was using AUDIT_ANOM_ABEND from when seccomp mode 1
could only kill a process.  While we still want to make sure an audit
record is forced on a kill, this should use a separate record type since
seccomp mode 2 introduces other behaviors.

In the case of "handled" behaviors (process wasn't killed), only emit a
record if the process is under inspection.  This change also fixes
userspace examination of seccomp audit events, since it was considered
malformed due to missing fields of the AUDIT_ANOM_ABEND event type.

Signed-off-by: Kees Cook 
Cc: Al Viro 
Cc: Eric Paris 
Cc: Jeff Layton 
Cc: "Eric W. Biederman" 
Cc: Julien Tinnes 
Acked-by: Will Drewry 
Acked-by: Steve Grubb 
Cc: Andrea Arcangeli 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm: compaction: partially revert capture of suitable high-order page

2013-01-17T16:46:10+00:00

commit 8fb74b9fb2b182d54beee592350d9ea1f325917a upstream.

Eric Wong reported on 3.7 and 3.8-rc2 that ppoll() got stuck when
waiting for POLLIN on a local TCP socket.  It was easier to trigger if
there was disk IO and dirty pages at the same time and he bisected it to
commit 1fb3f8ca0e92 ("mm: compaction: capture a suitable high-order page
immediately when it is made available").

The intention of that patch was to improve high-order allocations under
memory pressure after changes made to reclaim in 3.6 drastically hurt
THP allocations but the approach was flawed.  For Eric, the problem was
that page->pfmemalloc was not being cleared for captured pages leading
to a poor interaction with swap-over-NFS support causing the packets to
be dropped.  However, I identified a few more problems with the patch
including the fact that it can increase contention on zone->lock in some
cases which could result in async direct compaction being aborted early.

In retrospect the capture patch took the wrong approach.  What it should
have done is mark the pageblock being migrated as MIGRATE_ISOLATE if it
was allocating for THP and avoided races that way.  While the patch was
showing to improve allocation success rates at the time, the benefit is
marginal given the relative complexity and it should be revisited from
scratch in the context of the other reclaim-related changes that have
taken place since the patch was first written and tested.  This patch
partially reverts commit 1fb3f8ca0e92 ("mm: compaction: capture a
suitable high-order page immediately when it is made available").

Reported-and-tested-by: Eric Wong 
Tested-by: Eric Dumazet 
Signed-off-by: Mel Gorman 
Cc: David Miller 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

svcrpc: Revert "sunrpc/cache.h: replace simple_strtoul"

2013-01-17T16:46:08+00:00

commit 621eb19ce1ec216e03ad354cb0c4061736b2a436 upstream.

Commit bbf43dc888833ac0539e437dbaeb28bfd4fbab9f "sunrpc/cache.h: replace
simple_strtoul" introduced new range-checking which could cause get_int
to fail on unsigned integers too large to be represented as an int.

We could parse them as unsigned instead--but it turns out svcgssd is
actually passing down "-1" in some cases.  Which is perhaps stupid, but
there's nothing we can do about it now.

So just revert back to the previous "sloppy" behavior that accepts
either representation.

Reported-by: Sven Geggus 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

mfd: Remove Unicode Byte Order Marks from da9055

2013-01-17T16:45:59+00:00

commit 90a38d999739f35f4fc925c875e6ee518546b66c upstream.

Older gcc (< 4.4) doesn't like files starting with Unicode BOMs:

include/linux/mfd/da9055/core.h:1: error: stray ‘\357’ in program
include/linux/mfd/da9055/core.h:1: error: stray ‘\273’ in program
include/linux/mfd/da9055/core.h:1: error: stray ‘\277’ in program
include/linux/mfd/da9055/pdata.h:1: error: stray ‘\357’ in program
include/linux/mfd/da9055/pdata.h:1: error: stray ‘\273’ in program
include/linux/mfd/da9055/pdata.h:1: error: stray ‘\277’ in program
include/linux/mfd/da9055/reg.h:1: error: stray ‘\357’ in program
include/linux/mfd/da9055/reg.h:1: error: stray ‘\273’ in program
include/linux/mfd/da9055/reg.h:1: error: stray ‘\277’ in program

Remove the BOMs, the rest of the files is plain ASCII anyway.

Output of "file" before:

include/linux/mfd/da9055/core.h:  UTF-8 Unicode (with BOM) C program text
include/linux/mfd/da9055/pdata.h: UTF-8 Unicode (with BOM) C program text
include/linux/mfd/da9055/reg.h:   UTF-8 Unicode (with BOM) C program text

Output of "file" after:

include/linux/mfd/da9055/core.h:  ASCII C program text
include/linux/mfd/da9055/pdata.h: ASCII C program text
include/linux/mfd/da9055/reg.h:   ASCII C program text

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Samuel Ortiz 
Signed-off-by: Greg Kroah-Hartman

linux/kernel.h: fix DIV_ROUND_CLOSEST with unsigned divisors

2013-01-11T17:19:05+00:00

commit c4e18497d8fd92eef2c6e7eadcc1a107ccd115ea upstream.

Commit 263a523d18bc ("linux/kernel.h: Fix warning seen with W=1 due to
change in DIV_ROUND_CLOSEST") fixes a warning seen with W=1 due to
change in DIV_ROUND_CLOSEST.

Unfortunately, the C compiler converts divide operations with unsigned
divisors to unsigned, even if the dividend is signed and negative (for
example, -10 / 5U = 858993457).  The C standard says "If one operand has
unsigned int type, the other operand is converted to unsigned int", so
the compiler is not to blame.  As a result, DIV_ROUND_CLOSEST(0, 2U) and
similar operations now return bad values, since the automatic conversion
of expressions such as "0 - 2U/2" to unsigned was not taken into
account.

Fix by checking for the divisor variable type when deciding which
operation to perform.  This fixes DIV_ROUND_CLOSEST(0, 2U), but still
returns bad values for negative dividends divided by unsigned divisors.
Mark the latter case as unsupported.

One observed effect of this problem is that the s2c_hwmon driver reports
a value of 4198403 instead of 0 if the ADC reads 0.

Other impact is unpredictable.  Problem is seen if the divisor is an
unsigned variable or constant and the dividend is less than (divisor/2).

Signed-off-by: Guenter Roeck 
Reported-by: Juergen Beisert 
Tested-by: Juergen Beisert 
Cc: Jean Delvare 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

PCI: Reduce Ricoh 0xe822 SD card reader base clock frequency to 50MHz

2013-01-11T17:19:02+00:00

commit 812089e01b9f65f90fc8fc670d8cce72a0e01fbb upstream.

Otherwise it fails like this on cards like the Transcend 16GB SDHC card:

    mmc0: new SDHC card at address b368
    mmcblk0: mmc0:b368 SDC   15.0 GiB
    mmcblk0: error -110 sending status command, retrying
    mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb0

Tested on my Lenovo x200 laptop.

[bhelgaas: changelog]
Signed-off-by: Andy Lutomirski 
Signed-off-by: Bjorn Helgaas 
Acked-by: Chris Ball 
CC: Manoj Iyer 
Signed-off-by: Greg Kroah-Hartman

freezer: add missing mb's to freezer_count() and freezer_should_skip()

2013-01-11T17:18:50+00:00

commit dd67d32dbc5de299d70cc9e10c6c1e29ffa56b92 upstream.

A task is considered frozen enough between freezer_do_not_count() and
freezer_count() and freezers use freezer_should_skip() to test this
condition.  This supposedly works because freezer_count() always calls
try_to_freezer() after clearing %PF_FREEZER_SKIP.

However, there currently is nothing which guarantees that
freezer_count() sees %true freezing() after clearing %PF_FREEZER_SKIP
when freezing is in progress, and vice-versa.  A task can escape the
freezing condition in effect by freezer_count() seeing !freezing() and
freezer_should_skip() seeing %PF_FREEZER_SKIP.

This patch adds smp_mb()'s to freezer_count() and
freezer_should_skip() such that either %true freezing() is visible to
freezer_count() or !PF_FREEZER_SKIP is visible to
freezer_should_skip().

Signed-off-by: Tejun Heo 
Cc: Oleg Nesterov 
Cc: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

mm/hugetlb: create hugetlb cgroup file in hugetlb_init

2013-01-11T17:18:50+00:00

commit 7179e7bf4592ac5a7b30257a7df6259ee81e51da upstream.

Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y and
CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option, system
will fail to boot.

This failure is caused by following code path:

  setup_hugepagesz
    hugetlb_add_hstate
      hugetlb_cgroup_file_init
        cgroup_add_cftypes
          kzalloc <--slab is *not available* yet

For this path, slab is not available yet, so memory allocated will be
failed, and cause WARN_ON() in hugetlb_cgroup_file_init().

So I move hugetlb_cgroup_file_init() into hugetlb_init().

[akpm@linux-foundation.org: tweak coding-style, remove pointless __init on inlined function]
[akpm@linux-foundation.org: fix warning]
Signed-off-by: Jianguo Wu 
Signed-off-by: Jiang Liu 
Reviewed-by: Aneesh Kumar K.V 
Acked-by: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

cgroup: cgroup_subsys->fork() should be called after the task is added to css_set

2013-01-11T17:18:49+00:00

commit 5edee61edeaaebafe584f8fb7074c1ef4658596b upstream.

cgroup core has a bug which violates a basic rule about event
notifications - when a new entity needs to be added, you add that to
the notification list first and then make the new entity conform to
the current state.  If done in the reverse order, an event happening
inbetween will be lost.

cgroup_subsys->fork() is invoked way before the new task is added to
the css_set.  Currently, cgroup_freezer is the only user of ->fork()
and uses it to make new tasks conform to the current state of the
freezer.  If FROZEN state is requested while fork is in progress
between cgroup_fork_callbacks() and cgroup_post_fork(), the child
could escape freezing - the cgroup isn't frozen when ->fork() is
called and the freezer couldn't see the new task on the css_set.

This patch moves cgroup_subsys->fork() invocation to
cgroup_post_fork() after the new task is added to the css_set.
cgroup_fork_callbacks() is removed.

Because now a task may be migrated during cgroup_subsys->fork(),
freezer_fork() is updated so that it adheres to the usual RCU locking
and the rather pointless comment on why locking can be different there
is removed (if it doesn't make anything simpler, why even bother?).

Signed-off-by: Tejun Heo 
Cc: Oleg Nesterov 
Cc: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman