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

include/linux/sched.h: don't use task->pid/tgid in same_thread_group/has_group_leader_pid

2015-08-06T23:32:18+00:00

commit e1403b8edf669ff49bbdf602cc97fefa2760cb15 upstream.

task_struct->pid/tgid should go away.

1. Change same_thread_group() to use task->signal for comparison.

2. Change has_group_leader_pid(task) to compare task_pid(task) with
   signal->leader_pid.

Signed-off-by: Oleg Nesterov 
Cc: Michal Hocko 
Cc: Sergey Dyasly 
Reviewed-by: "Eric W. Biederman" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings 
Cc: Sheng Yong

dt: Add empty of_property_match_string() function

2015-08-06T23:32:16+00:00

commit bd3d5500f0c41a30149cb184362716096a17bc75 upstream.

This commit adds an empty of_property_match_string() function for
!CONFIG_OF builds.

Acked-by: Rob Herring 
Signed-off-by: Thierry Reding 
Signed-off-by: Ben Hutchings 
Cc: Jonathan Toppins

of: Add of_property_match_string() to find index into a string list

2015-08-06T23:32:16+00:00

commit 7aff0fe33033fc75b61446ba29d38b1b1354af9f upstream.

Add a helper function for finding the index of a string in a string
list property.  This helper is useful for bindings that use a separate
*-name property for attaching names to tuples in another property such
as 'reg' or 'gpios'.

Signed-off-by: Grant Likely 
[jt: dropped changes to files not existing in the 3.2 tree]
Signed-off-by: Jonathan Toppins 
Reviewed-by: Andy Gospodarek 
Acked-by: Curt Brune 
Acked-by: Roopa Prabhu 
Signed-off-by: Ben Hutchings

nilfs2: fix sanity check of btree level in nilfs_btree_root_broken()

2015-08-06T23:32:09+00:00

commit d8fd150fe3935e1692bf57c66691e17409ebb9c1 upstream.

The range check for b-tree level parameter in nilfs_btree_root_broken()
is wrong; it accepts the case of "level == NILFS_BTREE_LEVEL_MAX" even
though the level is limited to values in the range of 0 to
(NILFS_BTREE_LEVEL_MAX - 1).

Since the level parameter is read from storage device and used to index
nilfs_btree_path array whose element count is NILFS_BTREE_LEVEL_MAX, it
can cause memory overrun during btree operations if the boundary value
is set to the level parameter on device.

This fixes the broken sanity check and adds a comment to clarify that
the upper bound NILFS_BTREE_LEVEL_MAX is exclusive.

Signed-off-by: Ryusuke Konishi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

libata: Ignore spurious PHY event on LPM policy change

2015-08-06T23:32:06+00:00

commit 09c5b4803a80a5451d950d6a539d2eb311dc0fb1 upstream.

When the LPM policy is set to ATA_LPM_MAX_POWER, the device might
generate a spurious PHY event that cuases errors on the link.
Ignore this event if it occured within 10s after the policy change.

The timeout was chosen observing that on a Dell XPS13 9333 these
spurious events can occur up to roughly 6s after the policy change.

Link: http://lkml.kernel.org/g/3352987.ugV1Ipy7Z5@xps13
Signed-off-by: Gabriele Mazzotta 
Signed-off-by: Tejun Heo 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

libata: Add helper to determine when PHY events should be ignored

2015-08-06T23:32:06+00:00

commit 8393b811f38acdf7fd8da2028708edad3e68ce1f upstream.

This is a preparation commit that will allow to add other criteria
according to which PHY events should be dropped.

Signed-off-by: Gabriele Mazzotta 
Signed-off-by: Tejun Heo 
Signed-off-by: Ben Hutchings

jhash: Update jhash_[321]words functions to use correct initval

2015-08-06T23:32:02+00:00

commit 2e7056c433216f406b90a003aa0ba42e19d3bdcf upstream.

Looking over the implementation for jhash2 and comparing it to jhash_3words
I realized that the two hashes were in fact very different.  Doing a bit of
digging led me to "The new jhash implementation" in which lookup2 was
supposed to have been replaced with lookup3.

In reviewing the patch I noticed that jhash2 had originally initialized a
and b to JHASH_GOLDENRATIO and c to initval, but after the patch a, b, and
c were initialized to initval + (length << 2) + JHASH_INITVAL.  However the
changes in jhash_3words simply replaced the initialization of a and b with
JHASH_INITVAL.

This change corrects what I believe was an oversight so that a, b, and c in
jhash_3words all have the same value added consisting of initval + (length
<< 2) + JHASH_INITVAL so that jhash2 and jhash_3words will now produce the
same hash result given the same inputs.

Fixes: 60d509c823cca ("The new jhash implementation")
Signed-off-by: Alexander Duyck 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

Defer processing of REQ_PREEMPT requests for blocked devices

2015-05-09T22:16:35+00:00

commit bba0bdd7ad4713d82338bcd9b72d57e9335a664b upstream.

SCSI transport drivers and SCSI LLDs block a SCSI device if the
transport layer is not operational. This means that in this state
no requests should be processed, even if the REQ_PREEMPT flag has
been set. This patch avoids that a rescan shortly after a cable
pull sporadically triggers the following kernel oops:

BUG: unable to handle kernel paging request at ffffc9001a6bc084
IP: [] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib]
Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task ffff880534aae100)
Call Trace:
 [] srp_post_send+0x65/0x70 [ib_srp]
 [] srp_queuecommand+0x1cf/0x3e0 [ib_srp]
 [] scsi_dispatch_cmd+0x101/0x280 [scsi_mod]
 [] scsi_request_fn+0x411/0x4d0 [scsi_mod]
 [] __blk_run_queue+0x27/0x30
 [] blk_execute_rq_nowait+0x82/0x110
 [] blk_execute_rq+0x62/0xf0
 [] scsi_execute+0xe8/0x190 [scsi_mod]
 [] scsi_execute_req+0xa3/0x130 [scsi_mod]
 [] scsi_probe_lun+0x17a/0x450 [scsi_mod]
 [] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod]
 [] __scsi_scan_target+0xdf/0x1f0 [scsi_mod]
 [] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod]
 [] scsi_scan+0xdb/0xe0 [scsi_mod]
 [] store_scan+0x13/0x20 [scsi_mod]
 [] sysfs_write_file+0xcb/0x160
 [] vfs_write+0xce/0x140
 [] sys_write+0x53/0xa0
 [] system_call_fastpath+0x16/0x1b
 [<00007f611c9d9300>] 0x7f611c9d92ff

Reported-by: Max Gurtuvoy 
Signed-off-by: Bart Van Assche 
Reviewed-by: Mike Christie 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

fsnotify: fix handling of renames in audit

2015-05-09T22:16:15+00:00

commit 6ee8e25fc3e916193bce4ebb43d5439e1e2144ab upstream.

Commit e9fd702a58c4 ("audit: convert audit watches to use fsnotify
instead of inotify") broke handling of renames in audit.  Audit code
wants to update inode number of an inode corresponding to watched name
in a directory.  When something gets renamed into a directory to a
watched name, inotify previously passed moved inode to audit code
however new fsnotify code passes directory inode where the change
happened.  That confuses audit and it starts watching parent directory
instead of a file in a directory.

This can be observed for example by doing:

  cd /tmp
  touch foo bar
  auditctl -w /tmp/foo
  touch foo
  mv bar foo
  touch foo

In audit log we see events like:

  type=CONFIG_CHANGE msg=audit(1423563584.155:90): auid=1000 ses=2 op="updated rules" path="/tmp/foo" key=(null) list=4 res=1
  ...
  type=PATH msg=audit(1423563584.155:91): item=2 name="bar" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
  type=PATH msg=audit(1423563584.155:91): item=3 name="foo" inode=1046842 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
  type=PATH msg=audit(1423563584.155:91): item=4 name="foo" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE
  ...

and that's it - we see event for the first touch after creating the
audit rule, we see events for rename but we don't see any event for the
last touch.  However we start seeing events for unrelated stuff
happening in /tmp.

Fix the problem by passing moved inode as data in the FS_MOVED_FROM and
FS_MOVED_TO events instead of the directory where the change happens.
This doesn't introduce any new problems because noone besides
audit_watch.c cares about the passed value:

  fs/notify/fanotify/fanotify.c cares only about FSNOTIFY_EVENT_PATH events.
  fs/notify/dnotify/dnotify.c doesn't care about passed 'data' value at all.
  fs/notify/inotify/inotify_fsnotify.c uses 'data' only for FSNOTIFY_EVENT_PATH.
  kernel/audit_tree.c doesn't care about passed 'data' at all.
  kernel/audit_watch.c expects moved inode as 'data'.

Fixes: e9fd702a58c49db ("audit: convert audit watches to use fsnotify instead of inotify")
Signed-off-by: Jan Kara 
Cc: Paul Moore 
Cc: Eric Paris 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)

2015-05-09T22:16:14+00:00

commit 074f9dd55f9cab1b82690ed7e44bcf38b9616ce0 upstream.

Currently the USB stack assumes that all host controller drivers are
capable of receiving wakeup requests from downstream devices.
However, this isn't true for the isp1760-hcd driver, which means that
it isn't safe to do a runtime suspend of any device attached to a
root-hub port if the device requires wakeup.

This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure
and sets the flag in isp1760-hcd.  The core is modified to prevent a
direct child of the root hub from being put into runtime suspend with
wakeup enabled if the flag is set.

Signed-off-by: Alan Stern 
Tested-by: Nicolas Pitre 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings