commit 078314ed62531b5c78edd17885c24bfad0fbb80b Author: Greg Kroah-Hartman Date: Thu Jan 17 08:47:40 2013 -0800 Linux 3.7.3 commit cf787fa284598caea41c63d10cff91ff3ecb9671 Author: Chris Wilson Date: Mon Jan 7 10:11:40 2013 +0000 drm/i915: Treat crtc->mode.clock == 0 as disabled commit 3490ea5de6ac4af309c3df8a26a5cca61306334c upstream. Prevent a divide-by-zero by consistently treating an 'active' CRTC without a mode set as actually disabled. This looks to have been first introduced with commit 24929352481f085c5f85d4d4cbc919ddf106d381 Author: Daniel Vetter Date: Mon Jul 2 20:28:59 2012 +0200 drm/i915: read out the modeset hw state at load and resume time but then combined with commit b0a2658acb5bf9ca86b4aab011b7106de3af0add Author: Daniel Vetter Date: Tue Dec 18 09:37:54 2012 +0100 drm/i915: don't disable disconnected outputs it finally started oopsing. Signed-off-by: Chris Wilson Reported-and-tested-by: Alexey Zaytsev Tested-by: Sedat Dilek Cc: Daniel Vetter Cc: Jesse Barnes Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 157f92ae25fc05a3dc43fc7503323e2118b36b23 Author: Krzysztof Mazur Date: Wed Dec 19 11:03:41 2012 +0100 i915: ensure that VGA plane is disabled commit 0fde901f1ddd2ce0e380a6444f1fb7ca555859e9 upstream. Some broken systems (like HP nc6120) in some cases, usually after LID close/open, enable VGA plane, making display unusable (black screen on LVDS, some strange mode on VGA output). We used to disable VGA plane only once at startup. Now we also check, if VGA plane is still disabled while changing mode, and fix that if something changed it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434 Signed-off-by: Krzysztof Mazur Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 20a13bc0a341facc35dfa1c4fc779c26303e5c99 Author: Daniel Vetter Date: Fri Nov 23 18:16:34 2012 +0100 drm/i915: force restore on lid open commit 45e2b5f640b3766da3eda48f6c35f088155c06f3 upstream. There seem to be indeed some awkwards machines around, mostly those without OpRegion support, where the firmware changes the display hw state behind our backs when closing the lid. This force-restore logic has been originally introduced in commit c1c7af60892070e4b82ad63bbfb95ae745056de0 Author: Jesse Barnes Date: Thu Sep 10 15:28:03 2009 -0700 drm/i915: force mode set at lid open time but after the modeset-rework we've disabled it in the vain hope that it's no longer required: commit 3b7a89fce3e3dc96b549d6d829387b4439044d0d Author: Daniel Vetter Date: Mon Sep 17 22:27:21 2012 +0200 drm/i915: fix OOPS in lid_notify Alas, no. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54677 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434 Tested-by: Krzysztof Mazur Reviewed-by: Jesse Barnes Signed-off-by: Daniel Vetter Signed-off-by: CAI Qian Signed-off-by: Greg Kroah-Hartman commit bfc898a97b610cb1f8bc58f3b8d86d038d87cde3 Author: David Zafman Date: Mon Dec 3 19:14:05 2012 -0800 libceph: Unlock unprocessed pages in start_read() error path (cherry picked from commit 8884d53dd63b1d9315b343564fcbe1ede004a99e) Function start_read() can get an error before processing all pages. It must not only release the remaining pages, but unlock them too. This fixes http://tracker.newdream.net/issues/3370 Signed-off-by: David Zafman Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit c5ee6af4a9c23a98d401800ddb5be6edf98117d1 Author: Yan, Zheng Date: Mon Nov 19 10:49:09 2012 +0800 ceph: call handle_cap_grant() for cap import message (cherry picked from commit 0e5e1774a92e6fe9c511585de8f078b4c4c68dbb) If client sends cap message that requests new max size during exporting caps, the exporting MDS will drop the message quietly. So the client may wait for the reply that updates the max size forever. call handle_cap_grant() for cap import message can avoid this issue. Signed-off-by: Yan, Zheng Signed-off-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 608601fb5b6ea8b4dfbceea54c4e67638eaaabf5 Author: Yan, Zheng Date: Mon Nov 19 10:49:08 2012 +0800 ceph: Fix __ceph_do_pending_vmtruncate (cherry picked from commit a85f50b6ef93fbbb2ae932ce9b2376509d172796) we should set i_truncate_pending to 0 after page cache is truncated to i_truncate_size Signed-off-by: Yan, Zheng Signed-off-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 8ba21a9fbaff1ac20dcfe7d8bf6a6c24d7c80546 Author: Yan, Zheng Date: Mon Nov 19 10:49:07 2012 +0800 ceph: Don't add dirty inode to dirty list if caps is in migration (cherry picked from commit 0685235ffd9dbdb9ccbda587f8a3c83ad1d5a921) Add dirty inode to cap_dirty_migrating list instead, this can avoid ceph_flush_dirty_caps() entering infinite loop. Signed-off-by: Yan, Zheng Signed-off-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit bd604499e4a60e5e5c279ef1b9b83cd21d614d7c Author: Yan, Zheng Date: Mon Nov 19 10:49:06 2012 +0800 ceph: Fix infinite loop in __wake_requests (cherry picked from commit ed75ec2cd19b47efcd292b6e23f58e56f4c5bc34) __wake_requests() will enter infinite loop if we use it to wake requests in the session->s_waiting list. __wake_requests() deletes requests from the list and __do_request() adds requests back to the list. Signed-off-by: Yan, Zheng Signed-off-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 4899444757a896e3d38650e8fe11b50e2eecc88f Author: Yan, Zheng Date: Mon Nov 19 10:49:04 2012 +0800 ceph: Don't update i_max_size when handling non-auth cap (cherry picked from commit 5e62ad30157d0da04cf40c6d1a2f4bc840948b9c) The cap from non-auth mds doesn't have a meaningful max_size value. Signed-off-by: Yan, Zheng Signed-off-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit f89f14aff0007cbed2648b10e78982a95802962a Author: Alex Elder Date: Thu Dec 6 09:37:23 2012 -0600 rbd: remove linger unconditionally (cherry picked from commit 61c74035626beb25a39b0273ccf7d75510bc36a1) In __unregister_linger_request(), the request is being removed from the osd client's req_linger list only when the request has a non-null osd pointer. It should be done whether or not the request currently has an osd. This is most likely a non-issue because I believe the request will always have an osd when this function is called. Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 495f76eadab76742d4060130604306bfaaafca24 Author: Alex Elder Date: Fri Nov 9 15:05:54 2012 -0600 rbd: get rid of RBD_MAX_SEG_NAME_LEN (cherry picked from commit 2fd82b9e92c2a718ae81fc987b4468ceeee6979b) RBD_MAX_SEG_NAME_LEN represents the maximum length of an rbd object name (i.e., one of the objects providing storage backing an rbd image). Another symbol, MAX_OBJ_NAME_SIZE, is used in the osd client code to define the maximum length of any object name in an osd request. Right now they disagree, with RBD_MAX_SEG_NAME_LEN being too big. There's no real benefit at this point to defining the rbd object name length limit separate from any other object name, so just get rid of RBD_MAX_SEG_NAME_LEN and use MAX_OBJ_NAME_SIZE in its place. Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit f14e81d15cd37d89b880226f2ad3b234e8e629c7 Author: Alex Elder Date: Fri Nov 16 09:29:16 2012 -0600 rbd: do not allow remove of mounted-on image (cherry picked from commit 42382b709bd1d143b9f0fa93e0a3a1f2f4210707) There is no check in rbd_remove() to see if anybody holds open the image being removed. That's not cool. Add a simple open count that goes up and down with opens and closes (releases) of the device, and don't allow an rbd image to be removed if the count is non-zero. Protect the updates of the open count value with ctl_mutex to ensure the underlying rbd device doesn't get removed while concurrently being opened. Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit a35420155f46065b5fded0a7478fff003be4e872 Author: Alex Elder Date: Thu Oct 25 23:34:40 2012 -0500 rbd: remove snapshots on error in rbd_add() (cherry picked from commit 41f38c2b2f8b66b176a0e548ef06294343a7bfa2) If rbd_dev_snaps_update() has ever been called for an rbd device structure there could be snapshot structures on its snaps list. In rbd_add(), this function is called but a subsequent error path neglected to clean up any of these snapshots. Add a call to rbd_remove_all_snaps() in the appropriate spot to remedy this. Change a couple of error labels to be a little clearer while there. Drop the leading underscores from the function name; there's nothing special about that function that they might signify. As suggested in review, the leading underscores in __rbd_remove_snap_dev() have been removed as well. Signed-off-by: Alex Elder Reviewed-by: Josh Durgin Signed-off-by: Greg Kroah-Hartman commit fefc034ae0af85c0b18fe209a1b6803d51880556 Author: Alex Elder Date: Tue Jul 3 16:01:19 2012 -0500 rbd: increase maximum snapshot name length (cherry picked from commit d4b125e9eb43babd14538ba61718e3db71a98d29) Change RBD_MAX_SNAP_NAME_LEN to be based on NAME_MAX. That is a practical limit for the length of a snapshot name (based on the presence of a directory using the name under /sys/bus/rbd to represent the snapshot). The /sys entry is created by prefixing it with "snap_"; define that prefix symbolically, and take its length into account in defining the snapshot name length limit. Enforce the limit in rbd_add_parse_args(). Also delete a dout() call in that function that was not meant to be committed. Signed-off-by: Alex Elder Reviewed-by: Dan Mick Reviewed-by: Josh Durgin Signed-off-by: Greg Kroah-Hartman commit d741dc0695e62bcd1b7cfc7a8baa1f9e95fd07c7 Author: Alex Elder Date: Mon Oct 22 11:31:26 2012 -0500 rbd: fix read-only option name (cherry picked from commit be466c1cc36621590ef17b05a6d342dfd33f7280) The name of the "read-only" mapping option was inadvertently changed in this commit: f84344f3 rbd: separate mapping info in rbd_dev Revert that hunk to return it to what it should be. Signed-off-by: Alex Elder Reviewed-by: Dan Mick Reviewed-by: Josh Durgin Signed-off-by: Greg Kroah-Hartman commit 2042c7c78b7819daff3033ef4868c8dc7fc34a09 Author: Alex Elder Date: Wed Oct 10 21:19:13 2012 -0700 rbd: zero return code in rbd_dev_image_id() (cherry picked from commit a0ea3a40fd20b8c66381f747c454f89d6d1f50d4) When rbd_dev_probe() calls rbd_dev_image_id() it expects to get a 0 return code if successful, but it is getting a positive value. The reason is that rbd_dev_image_id() returns the value it gets from rbd_req_sync_exec(), which returns the number of bytes read in as a result of the request. (This ultimately comes from ceph_copy_from_page_vector() in rbd_req_sync_op()). Force the return value to 0 when successful in rbd_dev_image_id(). Do the same in rbd_dev_v2_object_prefix(). Signed-off-by: Alex Elder Reviewed-by: Josh Durgin Reviewed-by: Dan Mick Signed-off-by: Greg Kroah-Hartman commit 38f14fd492d3a7d2d096795f2e457d556a6b2f95 Author: Alex Elder Date: Wed Oct 10 21:19:13 2012 -0700 rbd: fix bug in rbd_dev_id_put() (cherry picked from commit b213e0b1a62637b2a9395a34349b13d73ca2b90a) In rbd_dev_id_put(), there's a loop that's intended to determine the maximum device id in use. But it isn't doing that at all, the effect of how it's written is to simply use the just-put id number, which ignores whole purpose of this function. Fix the bug. Signed-off-by: Alex Elder Reviewed-by: Josh Durgin Signed-off-by: Greg Kroah-Hartman commit 4de98b629ee84b800da6f4a5f8b0f4cfba3a7e3c Author: Alex Elder Date: Thu Nov 29 08:37:03 2012 -0600 ceph: don't reference req after put (cherry picked from commit 7d5f24812bd182a2471cb69c1c2baf0648332e1f) In __unregister_request(), there is a call to list_del_init() referencing a request that was the subject of a call to ceph_osdc_put_request() on the previous line. This is not safe, because the request structure could have been freed by the time we reach the list_del_init(). Fix this by reversing the order of these lines. Signed-off-by: Alex Elder Reviewed-off-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 46ed4fbffa67c423be6233a01e2fdf220ca8f5f0 Author: Sage Weil Date: Wed Nov 28 12:28:24 2012 -0800 libceph: remove 'osdtimeout' option (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 commit b624d7561efd53d4854960c82e71acb5fb4dd24b Author: Alex Elder Date: Fri Dec 7 09:57:58 2012 -0600 libceph: avoid using freed osd in __kick_osd_requests() (cherry picked from commit 685a7555ca69030739ddb57a47f0ea8ea80196a4) If an osd has no requests and no linger requests, __reset_osd() will just remove it with a call to __remove_osd(). That drops a reference to the osd, and therefore the osd may have been free by the time __reset_osd() returns. That function offers no indication this may have occurred, and as a result the osd will continue to be used even when it's no longer valid. Change__reset_osd() so it returns an error (ENODEV) when it deletes the osd being reset. And change __kick_osd_requests() so it returns immediately (before referencing osd again) if __reset_osd() returns *any* error. Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 1c76436d1b962c8d53871d9d13c6a01094d15b95 Author: Sage Weil Date: Mon Oct 29 11:01:42 2012 -0700 libceph: fix osdmap decode error paths (cherry picked from commit 0ed7285e0001b960c888e5455ae982025210ed3d) Ensure that we set the err value correctly so that we do not pass a 0 value to ERR_PTR and confuse the calling code. (In particular, osd_client.c handle_map() will BUG(!newmap)). Signed-off-by: Sage Weil Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 39cebb4027204a30ba2f65befbeff1ff569d3968 Author: Sage Weil Date: Thu Dec 27 20:27:04 2012 -0600 libceph: fix protocol feature mismatch failure path (cherry picked from commit 0fa6ebc600bc8e830551aee47a0e929e818a1868) We should not set con->state to CLOSED here; that happens in ceph_fault() in the caller, where it first asserts that the state is not yet CLOSED. Avoids a BUG when the features don't match. Since the fail_protocol() has become a trivial wrapper, replace calls to it with direct calls to reset_connection(). Signed-off-by: Sage Weil Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 7d70ef5bba98643d31917590bea352c9857ddbc7 Author: Daniel Vetter Date: Mon Jan 7 10:27:13 2013 +0100 Revert "drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13" commit 48e858340dae43189a4e55647f6eac736766f828 upstream. This reverts commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364. The bogus lvds output is actually a lvds->hdmi bridge, which we don't really support. But unconditionally disabling it breaks some existing setups. Reported-by: John Tapsell References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/17237 Signed-off-by: Daniel Vetter Cc: Luis Henriques Signed-off-by: Greg Kroah-Hartman commit c65b5b47c4c8c6e67e245edc2c918d75f5f2e714 Author: Alex Elder Date: Wed Dec 26 10:43:57 2012 -0600 libceph: WARN, don't BUG on unexpected connection states (cherry picked from commit 122070a2ffc91f87fe8e8493eb0ac61986c5557c) A number of assertions in the ceph messenger are implemented with BUG_ON(), killing the system if connection's state doesn't match what's expected. At this point our state model is (evidently) not well understood enough for these assertions to trigger a BUG(). Convert all BUG_ON(con->state...) calls to be WARN_ON(con->state...) so we learn about these issues without killing the machine. We now recognize that a connection fault can occur due to a socket closure at any time, regardless of the state of the connection. So there is really nothing we can assert about the state of the connection at that point so eliminate that assertion. Reported-by: Ugis Tested-by: Ugis Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 5172e2dbec4277186424c479f04562db96bee404 Author: Alex Elder Date: Wed Dec 26 14:31:40 2012 -0600 libceph: always reset osds when kicking (cherry picked from commit e6d50f67a6b1a6252a616e6e629473b5c4277218) When ceph_osdc_handle_map() is called to process a new osd map, kick_requests() is called to ensure all affected requests are updated if necessary to reflect changes in the osd map. This happens in two cases: whenever an incremental map update is processed; and when a full map update (or the last one if there is more than one) gets processed. In the former case, the kick_requests() call is followed immediately by a call to reset_changed_osds() to ensure any connections to osds affected by the map change are reset. But for full map updates this isn't done. Both cases should be doing this osd reset. Rather than duplicating the reset_changed_osds() call, move it into the end of kick_requests(). Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 99c667637d1e9dc781b6b5e478452c367ee8163a Author: Alex Elder Date: Wed Dec 19 15:52:36 2012 -0600 libceph: move linger requests sooner in kick_requests() (cherry picked from commit ab60b16d3c31b9bd9fd5b39f97dc42c52a50b67d) The kick_requests() function is called by ceph_osdc_handle_map() when an osd map change has been indicated. Its purpose is to re-queue any request whose target osd is different from what it was when it was originally sent. It is structured as two loops, one for incomplete but registered requests, and a second for handling completed linger requests. As a special case, in the first loop if a request marked to linger has not yet completed, it is moved from the request list to the linger list. This is as a quick and dirty way to have the second loop handle sending the request along with all the other linger requests. Because of the way it's done now, however, this quick and dirty solution can result in these incomplete linger requests never getting re-sent as desired. The problem lies in the fact that the second loop only arranges for a linger request to be sent if it appears its target osd has changed. This is the proper handling for *completed* linger requests (it avoids issuing the same linger request twice to the same osd). But although the linger requests added to the list in the first loop may have been sent, they have not yet completed, so they need to be re-sent regardless of whether their target osd has changed. The first required fix is we need to avoid calling __map_request() on any incomplete linger request. Otherwise the subsequent __map_request() call in the second loop will find the target osd has not changed and will therefore not re-send the request. Second, we need to be sure that a sent but incomplete linger request gets re-sent. If the target osd is the same with the new osd map as it was when the request was originally sent, this won't happen. This can be fixed through careful handling when we move these requests from the request list to the linger list, by unregistering the request *before* it is registered as a linger request. This works because a side-effect of unregistering the request is to make the request's r_osd pointer be NULL, and *that* will ensure the second loop actually re-sends the linger request. Processing of such a request is done at that point, so continue with the next one once it's been moved. Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit ec3f5ec9d2cdb7dcf5e842a244301e4085d45bd0 Author: Alex Elder Date: Thu Dec 6 07:22:04 2012 -0600 libceph: register request before unregister linger (cherry picked from commit c89ce05e0c5a01a256100ac6a6019f276bdd1ca6) In kick_requests(), we need to register the request before we unregister the linger request. Otherwise the unregister will reset the request's osd pointer to NULL. Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit e15e4f8a7f6cc7670c99a49642cf25525c93f8d1 Author: Alex Elder Date: Mon Dec 17 12:23:48 2012 -0600 libceph: don't use rb_init_node() in ceph_osdc_alloc_request() (cherry picked from commit a978fa20fb657548561dddbfb605fe43654f0825) The red-black node in the ceph osd request structure is initialized in ceph_osdc_alloc_request() using rbd_init_node(). We do need to initialize this, because in __unregister_request() we call RB_EMPTY_NODE(), which expects the node it's checking to have been initialized. But rb_init_node() is apparently overkill, and may in fact be on its way out. So use RB_CLEAR_NODE() instead. For a little more background, see this commit: 4c199a93 rbtree: empty nodes have no color" Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit c9e5752d3f060e665d1643427d7c0dddd2d934f3 Author: Alex Elder Date: Mon Dec 17 12:23:48 2012 -0600 libceph: init event->node in ceph_osdc_create_event() (cherry picked from commit 3ee5234df68d253c415ba4f2db72ad250d9c21a9) The red-black node node in the ceph osd event structure is not initialized in create_osdc_create_event(). Because this node can be the subject of a RB_EMPTY_NODE() call later on, we should ensure the node is initialized properly for that. Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit e0ecd5e9df067c38cd62ad7244013f51e23f9045 Author: Alex Elder Date: Thu Dec 6 07:22:04 2012 -0600 libceph: init osd->o_node in create_osd() (cherry picked from commit f407731d12214e7686819018f3a1e9d7b6f83a02) The red-black node node in the ceph osd structure is not initialized in create_osd(). Because this node can be the subject of a RB_EMPTY_NODE() call later on, we should ensure the node is initialized properly for that. Add a call to RB_CLEAR_NODE() initialize it. Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 95d99d5fd234903edb6856d72a6d4eb74b0c05fb Author: Alex Elder Date: Fri Dec 14 16:47:41 2012 -0600 libceph: report connection fault with warning (cherry picked from commit 28362986f8743124b3a0fda20a8ed3e80309cce1) When a connection's socket disconnects, or if there's a protocol error of some kind on the connection, a fault is signaled and the connection is reset (closed and reopened, basically). We currently get an error message on the log whenever this occurs. A ceph connection will attempt to reestablish a socket connection repeatedly if a fault occurs. This means that these error messages will get repeatedly added to the log, which is undesirable. Change the error message to be a warning, so they don't get logged by default. Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 508e063d109bdfd9e9b15aad6b86b7000d7f48eb Author: Alex Elder Date: Fri Dec 7 19:50:07 2012 -0600 libceph: socket can close in any connection state (cherry picked from commit 7bb21d68c535ad8be38e14a715632ae398b37ac1) A connection's socket can close for any reason, independent of the state of the connection (and without irrespective of the connection mutex). As a result, the connectino can be in pretty much any state at the time its socket is closed. Handle those other cases at the top of con_work(). Pull this whole block of code into a separate function to reduce the clutter. Signed-off-by: Alex Elder Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 002f7ba84b349caf9e95591ed11c13d26d48e24f Author: Alexander Graf Date: Sat Oct 6 03:56:35 2012 +0200 KVM: PPC: 44x: fix DCR read/write commit e43a028752fed049e4bd94ef895542f96d79fa74 upstream. When remembering the direction of a DCR transaction, we should write to the same variable that we interpret on later when doing vcpu_run again. Signed-off-by: Alexander Graf Signed-off-by: CAI Qian Signed-off-by: Greg Kroah-Hartman commit aae56350f4207b3ac376cb95a8c54ae3985b7832 Author: Daniel Vetter Date: Sat Dec 8 12:58:33 2012 +0100 drm/i915: disable cpt phase pointer fdi rx workaround commit 539526b4137bc0e7a8806c38c8522f226814a0e6 upstream. We've originally added this in commit 291427f5fdadec6e4be2924172e83588880e1539 Author: Jesse Barnes Date: Fri Jul 29 12:42:37 2011 -0700 drm/i915: apply phase pointer override on SNB+ too and then copy-pasted it over to ivb/ppt. The w/a was originally added for ilk/ibx in commit 5b2adf897146edeac6a1e438fb67b5a53dbbdf34 Author: Jesse Barnes Date: Thu Oct 7 16:01:15 2010 -0700 drm/i915: add Ironlake clock gating workaround for FDI link training and fixed up a bit in commit 6f06ce184c765fd8d50669a8d12fdd566c920859 Author: Jesse Barnes Date: Tue Jan 4 15:09:38 2011 -0800 drm/i915: set phase sync pointer override enable before setting phase sync pointer It turns out that this w/a isn't actually required on cpt/ppt and positively harmful on ivb/ppt when using fdi B/C links - it results in a black screen occasionally, with seemingfully everything working as it should. The only failure indication I've found in the hw is that eventually (but not right after the modeset completes) a pipe underrun is signalled. Big thanks to Arthur Runyan for all the ideas for registers to check and changes to test, otherwise I couldn't ever have tracked this down! Reviewed-by: Jesse Barnes Cc: "Runyan, Arthur J" Signed-off-by: Daniel Vetter Signed-off-by: CAI Qian Signed-off-by: Greg Kroah-Hartman commit c08745c377c89ba6dde5c38eff96c5d7a710fd26 Author: Konstantin Khlebnikov Date: Fri Dec 14 15:03:10 2012 +0400 EDAC: Fix kernel panic on module unloading commit 311bd84247ee0bedae6cdfbfc5e2c3450f9decd1 upstream. This patch fixes use-after-free and double-free bugs in edac_mc_sysfs_exit(). mci_pdev has single reference and put_device() calls mc_attr_release() which calls kfree(). The following device_del() works with already released memory. An another kfree() in edac_mc_sysfs_exit() releses the same memory again. Great. Signed-off-by: Konstantin Khlebnikov Cc: Denis Kirjanov Cc: Mauro Carvalho Chehab Link: http://lkml.kernel.org/r/20121214110310.11019.21098.stgit@zurg Signed-off-by: Borislav Petkov [ a partial 3.7.y backport ] Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 633396662719397cbd7d4cb935807030d386f9de Author: Stanislaw Gruszka Date: Mon Dec 3 12:59:04 2012 +0100 Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails" commit ab9d6e4ffe192427ce9e93d4f927b0faaa8a941e upstream. This revert: commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f Author: Andreas Hartmann Date: Tue Apr 17 00:25:28 2012 +0200 rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails To fix problem workaround by above commit use IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL flag (see change log for "mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL" patch). Resolve: https://bugzilla.kernel.org/show_bug.cgi?id=42828 Bisected-by: Francisco Pina Martins Signed-off-by: Stanislaw Gruszka Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a4ed1f3cce5f365f1e0e8b5e2c63a03a2c2d10c1 Author: Joe Thornber Date: Fri Dec 21 20:23:31 2012 +0000 dm thin: fix race between simultaneous io and discards to same block commit e8088073c9610af017fd47fddd104a2c3afb32e8 upstream. There is a race when discard bios and non-discard bios are issued simultaneously to the same block. Discard support is expensive for all thin devices precisely because you have to be careful to quiesce the area you're discarding. DM thin must handle this conflicting IO pattern (simultaneous non-discard vs discard) even though a sane application shouldn't be issuing such IO. The race manifests as follows: 1. A non-discard bio is mapped in thin_bio_map. This doesn't lock out parallel activity to the same block. 2. A discard bio is issued to the same block as the non-discard bio. 3. The discard bio is locked in a dm_bio_prison_cell in process_discard to lock out parallel activity against the same block. 4. The non-discard bio's mapping continues and its all_io_entry is incremented so the bio is accounted for in the thin pool's all_io_ds which is a dm_deferred_set used to track time locality of non-discard IO. 5. The non-discard bio is finally locked in a dm_bio_prison_cell in process_bio. The race can result in deadlock, leaving the block layer hanging waiting for completion of a discard bio that never completes, e.g.: INFO: task ruby:15354 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. ruby D ffffffff8160f0e0 0 15354 15314 0x00000000 ffff8802fb08bc58 0000000000000082 ffff8802fb08bfd8 0000000000012900 ffff8802fb08a010 0000000000012900 0000000000012900 0000000000012900 ffff8802fb08bfd8 0000000000012900 ffff8803324b9480 ffff88032c6f14c0 Call Trace: [] schedule+0x29/0x70 [] schedule_timeout+0x195/0x220 [] ? _dm_request+0x111/0x160 [dm_mod] [] wait_for_common+0x11e/0x190 [] ? try_to_wake_up+0x2b0/0x2b0 [] wait_for_completion+0x1d/0x20 [] blkdev_issue_discard+0x219/0x260 [] blkdev_ioctl+0x6e9/0x7b0 [] block_ioctl+0x3c/0x40 [] do_vfs_ioctl+0x8c/0x340 [] ? block_llseek+0x67/0xb0 [] sys_ioctl+0xa1/0xb0 [] ? sys_rt_sigprocmask+0x86/0xd0 [] system_call_fastpath+0x16/0x1b The thinp-test-suite's test_discard_random_sectors reliably hits this deadlock on fast SSD storage. The fix for this race is that the all_io_entry for a bio must be incremented whilst the dm_bio_prison_cell is held for the bio's associated virtual and physical blocks. That cell locking wasn't occurring early enough in thin_bio_map. This patch fixes this. Care is taken to always call the new function inc_all_io_entry() with the relevant cells locked, but they are generally unlocked before calling issue() to try to avoid holding the cells locked across generic_submit_request. Also, now that thin_bio_map may lock bios in a cell, process_bio() is no longer the only thread that will do so. Because of this we must be sure to use cell_defer_except() to release all non-holder entries, that were added by the other thread, because they must be deferred. This patch depends on "dm thin: replace dm_cell_release_singleton with cell_defer_except". Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit fdcc934ea116e2e4cc3552c7add4bea979da87c7 Author: Ralf Baechle Date: Thu Dec 20 12:47:51 2012 +0100 Revert "MIPS: Optimise TLB handlers for MIPS32/64 R2 cores." commit 9120963578320532dfb3a9a7947e8d05b39900b5 upstream. This reverts commit ff401e52100dcdc85e572d1ad376d3307b3fe28e. This breaks on MIPS64 R2 cores such as Broadcom's. Signed-off-by: Jayachandran C Signed-off-by: Greg Kroah-Hartman commit 0e3f380e4da94e19a2e32fa00a144bed52aa561a Author: Axel Lin Date: Wed Jan 9 19:34:57 2013 +0800 regulator: max8998: Ensure enough delay time for max8998_set_voltage_buck_time_sel commit 81d0a6ae7befb24c06f4aa4856af7f8d1f612171 upstream. Use DIV_ROUND_UP to prevent truncation by integer division issue. This ensures we return enough delay time. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d7fe0a4e2263fa4c01be523b983b5781edb19ae3 Author: Axel Lin Date: Fri Dec 28 17:10:20 2012 +0800 regulator: max8998: Use uV in voltage_map_desc commit adf6178ad5552a7f2f742a8c85343c50f080c412 upstream. Integer division may truncate. This happens when pdata->buckx_voltagex setting is not align with 1000 uV. Thus use uV in voltage_map_desc, this ensures the selected voltage won't less than pdata buckx_voltagex settings. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e25286fe7b20849d6e3b447d513b16a1423a76ef Author: Axel Lin Date: Fri Dec 28 17:09:03 2012 +0800 regulator: max8997: Use uV in voltage_map_desc commit bc3b7756b5ff66828acf7bc24f148d28b8d61108 upstream. Current code does integer division (min_vol = min_uV / 1000) before pass min_vol to max8997_get_voltage_proper_val(). So it is possible min_vol is truncated to a smaller value. For example, if the request min_uV is 800900 for ldo. min_vol = 800900 / 1000 = 800 (mV) Then max8997_get_voltage_proper_val returns 800 mV for this case which is lower than the requested voltage. Use uV rather than mV in voltage_map_desc to prevent truncation by integer division. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8a935b4ad29d83731572f0eb10f033fee45ae2e3 Author: Jan Beulich Date: Wed Dec 19 16:15:56 2012 +0000 USB: ehci: make debug port in-use detection functional again commit 75e1a2ae1f61ce1ae640410ba757bba84bd9fefe upstream. Debug port in-use determination must be done before the controller gets reset the first time, i.e. before the call to ehci_setup() as of commit 1a49e2ac9651df7349867a5cf44e2c83de1046af. That commit effectively rendered commit 9fa5780beea1274d498a224822397100022da7d4 useless. While moving that code around, also fix the BAR determination - the respective capability field is a 3- rather than a 2-bit one -, and use PCI_CAP_ID_DBG instead of the literal 0x0a. It's unclear to me whether the debug port functionality is important enough to warrant fixing this in stable kernels too. Signed-off-by: Jan Beulich Cc: Konrad Rzeszutek Wilk Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit b8038a41540e8bc559bff3f131989a0bcbc5905a Author: Sarah Sharp Date: Mon Dec 17 14:12:35 2012 -0800 xhci: Handle HS bulk/ctrl endpoints that don't NAK. commit 55c1945edaac94c5338a3647bc2e85ff75d9cf36 upstream. A high speed control or bulk endpoint may have bInterval set to zero, which means it does not NAK. If bInterval is non-zero, it means the endpoint NAKs at a rate of 2^(bInterval - 1). The xHCI code to compute the NAK interval does not handle the special case of zero properly. The current code unconditionally subtracts one from bInterval and uses it as an exponent. This causes a very large bInterval to be used, and warning messages like these will be printed: usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes This may cause the xHCI host hardware to reject the Configure Endpoint command, which means the HS device will be unusable under xHCI ports. This patch should be backported to kernels as old as 2.6.31, that contain commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval()". Reported-by: Vincent Pelletier Suggested-by: Alan Stern Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 3cf79239413526ca844c97a0c175a5bc5bfe45a5 Author: Oliver Neukum Date: Thu Nov 29 15:05:57 2012 +0100 USB: hub: handle claim of enabled remote wakeup after reset commit 07e72b95f5038cc82304b9a4a2eb7f9fc391ea68 upstream. Some touchscreens have buggy firmware which claims remote wakeup to be enabled after a reset. They nevertheless crash if the feature is cleared by the host. Add a check for reset resume before checking for an enabled remote wakeup feature. On compliant devices the feature must be cleared after a reset anyway. Signed-off-by: Oliver Neukum Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 35b3b7dc3d885ca753653d61a0ef5c4318f5e9f6 Author: Sarah Sharp Date: Tue Nov 27 12:30:23 2012 -0800 xhci: Avoid "dead ports", add roothub port polling. commit c52804a472649b2e5005342308739434cbd51119 upstream. The USB core hub thread (khubd) is designed with external USB hubs in mind. It expects that if a port status change bit is set, the hub will continue to send a notification through the hub status data transfer. Basically, it expects hub notifications to be level-triggered. The xHCI host controller is designed to be edge-triggered on the logical 'OR' of all the port status change bits. When all port status change bits are clear, and a new change bit is set, the xHC will generate a Port Status Change Event. If another change bit is set in the same port status register before the first bit is cleared, it will not send another event. This means that the hub code may lose port status changes because of race conditions between clearing change bits. The user sees this as a "dead port" that doesn't react to device connects. The fix is to turn on port polling whenever a new change bit is set. Once the USB core issues a hub status request that shows that no change bits are set in any USB ports, turn off port polling. We can't allow the USB core to poll the roothub for port events during host suspend because if the PCI host is in D3cold, the port registers will be all f's. Instead, stop the port polling timer, and unconditionally restart it when the host resumes. If there are no port change bits set after the resume, the first call to hub_status_data will disable polling. This patch should be backported to stable kernels with the first xHCI support, 2.6.31 and newer, that include the commit 0f2a79300a1471cf92ab43af165ea13555c8b0a5 "USB: xhci: Root hub support." There will be merge conflicts because the check for HC_STATE_SUSPENDED was moved into xhci_suspend in 3.8. Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit f7965c0846d74b270e246c1470ca955d5078eb07 Author: Sarah Sharp Date: Wed Nov 14 17:58:04 2012 -0800 USB: Handle warm reset failure on empty port. commit 65bdac5effd15d6af619b3b7218627ef4d84ed6a upstream. An empty port can transition to either Inactive or Compliance Mode if a newly connected USB 3.0 device fails to link train. In that case, we issue a warm reset. Some devices, such as John's Roseweil eusb3 enclosure, slip back into Compliance Mode after the warm reset. The current warm reset code does not check for device connect status on warm reset completion, and it incorrectly reports the warm reset succeeded. This causes the USB core to attempt to send a Set Address control transfer to a port in Compliance Mode, which will always fail. Make hub_port_wait_reset check the current connect status and link state after the warm reset completes. Return a failure status if the device is disconnected or the link state is Compliance Mode or SS.Inactive. Make hub_events disable the port if warm reset fails. This will disable the port, and then bring it back into the RxDetect state. Make the USB core ignore the connect change until the device reconnects. Note that this patch does NOT handle connected devices slipping into the Inactive state very well. This is a concern, because devices can go into the Inactive state on U1/U2 exit failure. However, the fix for that case is too large for stable, so it will be submitted in a separate patch. This patch should be backported to kernels as old as 3.2, contain the commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic" Signed-off-by: Sarah Sharp Acked-by: Alan Stern Reported-by: John Covici Signed-off-by: Greg Kroah-Hartman commit bbd31bebacee9a324beb67db5cd1f70dd9a9c2d9 Author: Sarah Sharp Date: Thu Nov 15 14:58:04 2012 -0800 USB: Ignore port state until reset completes. commit 4f43447e62b37ee19c82a13f72f35b1ca60a74d3 upstream. The port reset code bails out early if the current connect status is cleared (device disconnected). If we're issuing a hot reset, it may also look at the link state before the reset is finished. Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the Error state or Resetting state, the port connection bit retains the value from the previous state. Therefore we can't trust it until the reset finishes. Also, the xHCI spec section 4.19.1.2.5 says software shall ignore the link state while the port is resetting, as it can be in an unknown state. The port state during reset is also unknown for USB 2.0 hubs. The hub sends a reset signal by driving the bus into an SE0 state. This overwhelms the "connect" signal from the device, so the port can't tell whether anything is connected or not. Fix the port reset code to ignore the port link state and current connect bit until the reset finishes, and USB_PORT_STAT_RESET is cleared. Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case, because it's redundant. When the warm reset finishes, the port reset bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set. Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit in the code to deal with the finished reset. This patch should be backported to all stable kernels. Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 7462d1bd2e5e5d5d993aa815f89afd4e4d1dd35a Author: Sarah Sharp Date: Wed Nov 14 17:16:52 2012 -0800 USB: Increase reset timeout. commit 77c7f072c87fa951e9a74805febf26466f31170c upstream. John's NEC 0.96 xHCI host controller needs a longer timeout for a warm reset to complete. The logs show it takes 650ms to complete the warm reset, so extend the hub reset timeout to 800ms to be on the safe side. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic". Signed-off-by: Sarah Sharp Acked-by: Alan Stern Reported-by: John Covici Signed-off-by: Greg Kroah-Hartman commit 17722a0806c1033edcc564958a929f836bc4050b Author: Sarah Sharp Date: Wed Nov 14 16:42:32 2012 -0800 USB: Allow USB 3.0 ports to be disabled. commit 41e7e056cdc662f704fa9262e5c6e213b4ab45dd upstream. If hot and warm reset fails, or a port remains in the Compliance Mode, the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0 ports, once the port is placed into the Disabled link state, it will not report any new device connects. To get device connect notifications, we need to put the link into the Disabled state, and then the RxDetect state. The xHCI driver needs to atomically clear all change bits on USB 3.0 port disable, so that we get Port Status Change Events for future port changes. We could technically do this in the USB core instead of in the xHCI roothub code, since the port state machine can't advance out of the disabled state until we set the link state to RxDetect. However, external USB 3.0 hubs don't need this code. They are level-triggered, not edge-triggered like xHCI, so they will continue to send interrupt events when any change bit is set. Therefore it doesn't make sense to put this code in the USB core. This patch is part of a series to fix several reports of infinite loops on device enumeration failure. This includes John, when he boots with a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96 host controller. The fix requires warm reset support, so it does not make sense to backport this patch to stable kernels without warm reset support. This patch should be backported to kernels as old as 3.2, contain the commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic" Signed-off-by: Sarah Sharp Acked-by: Alan Stern Reported-by: John Covici Signed-off-by: Greg Kroah-Hartman commit 00e33f5e757dc64908a1eb65c17800ef81784f8a Author: Sarah Sharp Date: Wed Nov 14 16:10:49 2012 -0800 USB: Ignore xHCI Reset Device status. commit 8b8132bc3d1cc3d4c0687e4d638a482fa920d98a upstream. When the USB core finishes reseting a USB device, the xHCI driver sends a Reset Device command to the host. The xHC then updates its internal representation of the USB device to the 'Default' device state. If the device was already in the Default state, the xHC will complete the command with an error status. If a device needs to be reset several times during enumeration, the second reset will always fail because of the xHCI Reset Device command. This can cause issues during enumeration. For example, usb_reset_and_verify_device calls into hub_port_init in a loop. Say that on the first call into hub_port_init, the device is successfully reset, but doesn't respond to several set address control transfers. Then the port will be disabled, but the udev will remain in tact. usb_reset_and_verify_device will call into hub_port_init again. On the second call into hub_port_init, the device will be reset, and the xHCI driver will issue a Reset Device command. This command will fail (because the device is already in the Default state), and usb_reset_and_verify_device will fail. The port will be disabled, and the device won't be able to enumerate. Fix this by ignoring the return value of the HCD reset_device callback. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic". Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit ed25f8809a6c3036f40f1467202db2198180034e Author: Andreas Fleig Date: Wed Dec 5 16:17:49 2012 +0100 USB: Add device quirk for Microsoft VX700 webcam commit bc009eca8d539162f7271c2daf0ab5e9e3bb90a0 upstream. Add device quirk for Microsoft Lifecam VX700 v2.0 webcams. Fixes squeaking noise of the microphone. Signed-off-by: Andreas Fleig Signed-off-by: Greg Kroah-Hartman commit 709a9d3cd1b75e167b1eafcc42a5f2b264f2e20a Author: Sarah Sharp Date: Wed Nov 14 15:58:52 2012 -0800 USB: Handle auto-transition from hot to warm reset. commit 1c7439c61fa6516419c32a9824976334ea969d47 upstream. USB 3.0 hubs and roothubs will automatically transition a failed hot reset to a warm (BH) reset. In that case, the warm reset change bit will be set, and the link state change bit may also be set. Change hub_port_finish_reset to unconditionally clear those change bits for USB 3.0 hubs. If these bits are not cleared, we may lose port change events from the roothub. This commit should be backported to kernels as old as 3.2, that contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic". Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 39c5cda91b2d77399030ea038626c85fac182f89 Author: Aleksi Torhamo Date: Wed Jan 9 20:08:48 2013 +0200 drm/nvc0/fb: fix crash when different mutex is used to protect same list commit 43f789792e2c7ea2bff37195e4c4b4239e9e02b7 upstream. Fixes regression introduced in commit 861d2107 "drm/nouveau/fb: merge fb/vram and port to subdev interfaces" nv50_fb_vram_{new,del} functions were changed to use nouveau_subdev->mutex instead of the old nouveau_mm->mutex. nvc0_fb_vram_new still uses the nouveau_mm->mutex, but nvc0 doesn't have its own fb_vram_del function, using nv50_fb_vram_del instead. Because of this, on nvc0 a different mutex ends up being used to protect additions and deletions to the same list. This patch is a -stable candidate for 3.7. Signed-off-by: Aleksi Torhamo Reported-by: Roy Spliet Tested-by: Roy Spliet Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit c6f94c3c86878b82463a2f94998ff0c54bc68025 Author: Aleksi Torhamo Date: Fri Jan 4 18:39:13 2013 +0200 drm/nouveau/clock: fix support for more than 2 monitors on nve0 commit d19528a9e4f220519c2cb3f56ef0c84ead3ee440 upstream. Fixes regression introduced in commit 70790f4f "drm/nouveau/clock: pull in the implementation from all over the place" When code was moved from nv50_crtc_set_clock to nvc0_clock_pll_set, the PLLs it is used for got limited to only the first two VPLLs. nv50_crtc_set_clock was only called to change VPLLs, so it didn't limit what it was used for in any way. Since nvc0_clock_pll_set is used for all PLLs, it has to specify which PLLs the code is used for, and only listed the first two VPLLs. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=58735 This patch is a -stable candidate for 3.7. Signed-off-by: Aleksi Torhamo Tested-by: Aleksi Torhamo Tested-by: Sean Santos Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 7fbc316ddf55e429c1275c371f18bd186b9a2533 Author: Marcin Slusarz Date: Sun Dec 2 12:56:22 2012 +0100 drm/nouveau: add locking around instobj list operations commit 4c4101d29fb6c63f78791d02c437702b11e1d4f0 upstream. Fixes memory corruptions, oopses, etc. when multiple gpuobjs are simultaneously created or destroyed. Signed-off-by: Marcin Slusarz Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 4d6438797e79e03b7d8e6a115c99e7f3b90bf4d1 Author: Marcin Slusarz Date: Tue Dec 18 20:30:47 2012 +0100 drm/nouveau: fix blank LVDS screen regression on pre-nv50 cards commit 92441b2263866c27ef48137be5aa6c8c692652fc upstream. Commit 2a44e499 ("drm/nouveau/disp: introduce proper init/fini, separate from create/destroy") started to call display init routines on pre-nv50 hardware on module load. But LVDS init code sets driver state in a way which prevents modesetting code from operating properly. nv04_display_init calls nv04_dfp_restore, which sets encoder->last_dpms to NV_DPMS_CLEARED. drm_crtc_helper_set_mode nv04_dfp_prepare nv04_lvds_dpms(DRM_MODE_DPMS_OFF) nv04_lvds_dpms checks last_dpms mode (which is NV_DPMS_CLEARED) and wrongly assumes it's a "powersaving mode", the new one (DRM_MODE_DPMS_OFF) is too, so it skips calling some crucial lvds scripts. Reported-by: Chris Paulson-Ellis Signed-off-by: Marcin Slusarz Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit ad30b29191aca88dc207172d3c456a082ceb11c1 Author: Marcin Slusarz Date: Tue Dec 25 18:13:22 2012 +0100 drm/nv17-50: restore fence buffer on resume commit f20ebd034eab43fd38c58b11c5bb5fb125e5f7d7 upstream. Since commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 "drm/nouveau/fence: convert to exec engine, and improve channel sync" nouveau fence sync implementation for nv17-50 and nvc0+ started to rely on state of fence buffer left by previous sync operation. But as pinned bo's (where fence state is stored) are not saved+restored across suspend/resume, we need to do it manually. nvc0+ was fixed by commit d6ba6d215a538a58f0f0026f0961b0b9125e8042 "drm/nvc0/fence: restore pre-suspend fence buffer context on resume". Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=50121 Signed-off-by: Marcin Slusarz Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 4e0aa7af20fc092342fd2044652c40c38cc21b68 Author: Sergei Shtylyov Date: Wed Nov 14 18:49:50 2012 +0300 usb: musb: core: print new line in the driver banner again commit 2ac788f705e5118dd45204e7a5bc8d5bb6873835 upstream. Commit 5c8a86e10a7c164f44537fabdc169fd8b4e7a440 (usb: musb: drop unneeded musb_debug trickery) erroneously removed '\n' from the driver's banner. Concatenate all the banner substrings while adding it back... Signed-off-by: Sergei Shtylyov Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit d591ff17cec40c1045b0fe96db05da0988e71517 Author: Sebastian Andrzej Siewior Date: Tue Nov 20 13:23:15 2012 +0100 usb: gadget: dummy: fix enumeration with g_multi commit 1d16638e3b9cc195bac18a8fcbca748f33c1bc24 upstream. If we do have endpoints named like "ep-a" then bEndpointAddress is counted internally by the gadget framework. If we do have endpoints named like "ep-1" then bEndpointAddress is assigned from the digit after "ep-". If we do have both, then it is likely that after we used up the "generic" endpoints we will use the digits and thus assign one bEndpointAddress to multiple endpoints. This theory can be proofed by using the completely enabled g_multi. Without this patch, the mass storage won't enumerate and times out because it shares endpoints with RNDIS. This patch also adds fills up the endpoints list so we have in total endpoints 1 to 15 in + out available while some of them are restricted to certain types like BULK or ISO. Without this change the nokia gadget won't load because the system does not provide enough (BULK) endpoints but it did before ep-a - ep-f were removed. Signed-off-by: Sebastian Andrzej Siewior Acked-by: Alan Stern Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit cbc5b362d08b0ae2b1f58b04918e10abb6ad261a Author: Denis N Ladin Date: Wed Dec 26 18:29:44 2012 +0500 USB: cdc-acm: Add support for "PSC Scanning, Magellan 800i" commit 036915a7a402753c05b8d0529f5fd08805ab46d0 upstream. Adding support "PSC Scanning, Magellan 800i" in cdc-acm Very simple, but very necessary. Suitable for all versions of the kernel > 2.6 Signed-off-by: Denis N Ladin Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit f3d19ca534587847628876c9af531d210041dc6d Author: Tomasz Mloduchowski Date: Sun Jan 13 23:32:53 2013 +0100 usb: ftdi_sio: Crucible Technologies COMET Caller ID - pid added commit 8cf65dc386f3634a43312f436cc7a935476a40c4 upstream. Simple fix to add support for Crucible Technologies COMET Caller ID USB decoder - a device containing FTDI USB/Serial converter chip, handling 1200bps CallerID messages decoded from the phone line - adding correct USB PID is sufficient. Tested to apply cleanly and work flawlessly against 3.6.9, 3.7.0-rc8 and 3.8.0-rc3 on both amd64 and x86 arches. Signed-off-by: Tomasz Mloduchowski Signed-off-by: Greg Kroah-Hartman commit 9feac54bb2b8de7947e56f51b2a71b365da715a3 Author: Bjørn Mork Date: Fri Dec 28 17:29:52 2012 +0100 USB: option: add Telekom Speedstick LTE II commit 5ec0085440ef8c2cf50002b34d5a504ee12aa2bf upstream. also known as Alcatel One Touch L100V LTE The driver description files gives these names to the vendor specific functions on this modem: Application1: VID_1BBB&PID_011E&MI_00 Application2: VID_1BBB&PID_011E&MI_01 Modem: VID_1BBB&PID_011E&MI_03 Ethernet: VID_1BBB&PID_011E&MI_04 Reported-by: Thomas Schäfer Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit e164af67aa98787e2278cd828ba4b25a324e4207 Author: Quentin.Li Date: Wed Dec 26 16:58:22 2012 +0800 USB: option: Add new MEDIATEK PID support commit 94a85b633829b946eef53fc1825d526312fb856f upstream. In option.c, add some new MEDIATEK PIDs support for MEDIATEK new products. This is a MEDIATEK inc. release patch. Signed-off-by: Quentin.Li Signed-off-by: Greg Kroah-Hartman commit eefde826774dc11ef211c7216bfd38e67b9b0212 Author: Bjørn Mork Date: Wed Dec 19 15:15:17 2012 +0100 USB: option: blacklist network interface on ZTE MF880 commit fab38246f318edcd0dcb8fd3852a47cf8938878a upstream. The driver description files gives these names to the vendor specific functions on this modem: diag: VID_19D2&PID_0284&MI_00 nmea: VID_19D2&PID_0284&MI_01 at: VID_19D2&PID_0284&MI_02 mdm: VID_19D2&PID_0284&MI_03 net: VID_19D2&PID_0284&MI_04 Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 048fb3a6fe8c66879496a40a073564d6db984a4a Author: Dzianis Kahanovich Date: Mon Dec 3 16:06:26 2012 +0300 USB: option: add Nexpring NP10T terminal id commit ad86e58661b38b279b7519d4e49c7a19dc1654bb upstream. Hyundai Petatel Inc. Nexpring NP10T terminal (EV-DO rev.A USB modem) ID Signed-off-by: Denis Kaganovich Signed-off-by: Greg Kroah-Hartman commit 0039b1cfcd30a3f001ea2dfd2eaef40a249c999b Author: Larry Finger Date: Thu Dec 20 15:55:01 2012 -0600 b43: Fix firmware loading when driver is built into the kernel commit 5e20a4b53094651d80f856ff55a916b999dbb57a upstream. Recent versions of udev cause synchronous firmware loading from the probe routine to fail because the request to user space would time out. The original fix for b43 (commit 6b6fa58) moved the firmware load from the probe routine to a work queue, but it still used synchronous firmware loading. This method is OK when b43 is built as a module; however, it fails when the driver is compiled into the kernel. This version changes the code to load the initial firmware file using request_firmware_nowait(). A completion event is used to hold the work queue until that file is available. This driver reads several firmware files - the remainder can be read synchronously. On some test systems, the async read fails; however, a following synch read works, thus the async failure falls through to the sync try. Reported-and-Tested by: Felix Janda Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8a3e96a47ce6da5c7eb9209822d947eefd16e46e Author: Bing Zhao Date: Wed Jan 2 16:07:35 2013 -0800 mwifiex: check wait_event_interruptible return value commit 9c969d8ccb1e17bd20742f4ac9f00c1a64487234 upstream. wait_event_interruptible function returns -ERESTARTSYS if it's interrupted by a signal. Driver should check the return value and handle this case properly. In mwifiex_wait_queue_complete() routine, as we are now checking wait_event_interruptible return value, the condition check is not required. Also, we have removed mwifiex_cancel_pending_ioctl() call to avoid a chance of sending second command to FW by other path as soon as we clear current command node. FW can not handle two commands simultaneously. Signed-off-by: Bing Zhao Signed-off-by: Amitkumar Karwar Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 6a544b84195102eb875d6e7132c77ab96e45f300 Author: Johannes Berg Date: Thu Dec 13 23:08:52 2012 +0100 mac80211: use del_timer_sync for final sta cleanup timer deletion commit a56f992cdabc63f56b4b142885deebebf936ff76 upstream. This is a very old bug, but there's nothing that prevents the timer from running while the module is being removed when we only do del_timer() instead of del_timer_sync(). The timer should normally not be running at this point, but it's not clearly impossible (or we could just remove this.) Tested-by: Ben Greear Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 52beb077553228824002fc77b701ff632423860c Author: Johannes Berg Date: Thu Dec 13 22:54:58 2012 +0100 mac80211: fix station destruction in AP/mesh modes commit 97f97b1f5fe0878b35c8e314f98591771696321b upstream. Unfortunately, commit b22cfcfcae5b, intended to speed up roaming by avoiding the synchronize_rcu() broke AP/mesh modes as it moved some code into that work item that will still call into the driver at a time where it's no longer expected to handle this: after the AP or mesh has been stopped. To fix this problem remove the per-station work struct, maintain a station cleanup list instead and flush this list when stations are flushed. To keep this patch smaller for stable, do this when the stations are flushed (sta_info_flush()). This unfortunately brings back the original roaming delay; I'll fix that again in a separate patch. Also, Ben reported that the original commit could sometimes (with many interfaces) cause long delays when an interface is set down, due to blocking on flush_workqueue(). Since we now maintain the cleanup list, this particular change of the original patch can be reverted. Reported-by: Ben Greear Tested-by: Ben Greear Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 1cf18948040a40fa4497e40bcde2ffa8d6b1196e Author: Stanislaw Gruszka Date: Tue Dec 11 10:48:23 2012 +0100 mac80211: fix ibss scanning commit 34bcf71502413f8903ade93746f2d0f04b937a78 upstream. Do not scan on no-IBSS and disabled channels in IBSS mode. Doing this can trigger Microcode errors on iwlwifi and iwlegacy drivers. Also rename ieee80211_request_internal_scan() function since it is only used in IBSS mode and simplify calling it from ieee80211_sta_find_ibss(). This patch should address: https://bugzilla.redhat.com/show_bug.cgi?id=883414 https://bugzilla.kernel.org/show_bug.cgi?id=49411 Reported-by: Jesse Kahtava Reported-by: Mikko Rapeli Signed-off-by: Stanislaw Gruszka Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 1b9ebe3914bf8c529491cff8e2b1011b5da3747b Author: Emmanuel Grumbach Date: Mon Dec 31 09:26:10 2012 +0200 iwlwifi: fix the reclaimed packet tracking upon flush queue commit f590dcec944552f9a4a61155810f3abd17d6465d upstream. There's a bug in the currently released firmware version, the sequence control in the Tx response isn't updated in all cases. Take it from the packet as a workaround. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 1c543013adbf1a59c4f416f08475458444c2331a Author: Johannes Berg Date: Thu Dec 27 21:37:04 2012 +0100 iwlwifi: fix PCIe interrupt handle return value commit 392d4cad7907f6cb4ffc85e135a01abfddc89027 upstream. By accident, commit eb6476441bc2fecf6232a87d0313a85f8e3da7f4 ("iwlwifi: protect use_ict with irq_lock") changed the return value of the iwl_pcie_isr() function in case it handles an interrupt -- it now returns IRQ_NONE instead of IRQ_HANDLED. Put back the correct return value. Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit edb6cae74b8c083d8264517eab0cb354c01c49ee Author: Jerome Glisse Date: Tue Jan 8 18:41:01 2013 -0500 radeon/kms: force rn50 chip to always report connected on analog output commit 51861d4eebc2ddc25c77084343d060fa79f6e291 upstream. Those rn50 chip are often connected to console remoting hw and load detection often fails with those. Just don't try to load detect and report connect. Signed-off-by: Jerome Glisse Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5aed7dcf6e61f4db14d1f2b2eeb3806fe82a5524 Author: Nitin Gupta Date: Wed Jan 2 08:53:41 2013 -0800 staging: zram: fix invalid memory references during disk write commit 397c60668aa5ae7130b5ad4e73870d7b8a787085 upstream. Fixes a bug introduced by commit c8f2f0db1 ("zram: Fix handling of incompressible pages") which caused invalid memory references during disk write. Invalid references could occur in two cases: - Incoming data expands on compression: In this case, reference was made to kunmap()'ed bio page. - Partial (non PAGE_SIZE) write with incompressible data: In this case, reference was made to a kfree()'ed buffer. Fixes bug 50081: https://bugzilla.kernel.org/show_bug.cgi?id=50081 Signed-off-by: Nitin Gupta Reported-by: Mihail Kasadjikov Reported-by: Tomas M Reviewed-by: Minchan Kim Signed-off-by: Greg Kroah-Hartman commit 3bfb254e7ba8d96e1f3288fb94e33242061cc156 Author: Sergey Senozhatsky Date: Tue Oct 30 22:40:23 2012 +0300 staging: zram: factor-out zram_decompress_page() function commit 37b51fdddf64e7ba0971d070428655f8d6f36578 upstream. zram_bvec_read() shared decompress functionality with zram_read_before_write() function. Factor-out and make commonly used zram_decompress_page() function, which also simplified error handling in zram_bvec_read(). Signed-off-by: Sergey Senozhatsky Reviewed-by: Nitin Gupta Signed-off-by: Greg Kroah-Hartman commit 2359043700dfb368aa43854285c2e48ed70d2c4b Author: Samuel Thibault Date: Mon Jan 7 22:03:51 2013 +0100 staging: speakup: avoid out-of-range access in synth_add() commit 6102c48bd421074a33e102f2ebda3724e8d275f9 upstream. Check that array index is in-bounds before accessing the synths[] array. Signed-off-by: Samuel Thibault Cc: Nickolai Zeldovich Signed-off-by: Greg Kroah-Hartman commit 92b8a9f4d01e371ea5e2405b9c670a29dab476e7 Author: Nickolai Zeldovich Date: Sat Jan 5 14:17:45 2013 -0500 staging: speakup: avoid out-of-range access in synth_init() commit ae428655b826f2755a8101b27beda42a275ef8ad upstream. Check that array index is in-bounds before accessing the synths[] array. Signed-off-by: Nickolai Zeldovich Cc: Samuel Thibault Signed-off-by: Greg Kroah-Hartman commit 9cad2ff8299b48c44b6d04c030138719dd528c74 Author: Larry Finger Date: Sat Dec 29 11:36:53 2012 -0600 staging: r8712u: Add new device ID commit da849a92d3bafaf24d770e971c2c9e5c3f60b5d1 upstream. The ISY IWL 1000 USB WLAN stick with USB ID 050d:11f1 is a clone of the Belkin F7D1101 V1 device. Reported-by: Thomas Hartmann Signed-off-by: Larry Finger Cc: Thomas Hartmann Signed-off-by: Greg Kroah-Hartman commit 6c1a00ab82e6749b5165cee08af2056d62fd752c Author: Ian Abbott Date: Fri Jan 4 11:33:21 2013 +0000 staging: comedi: comedi_test: fix race when cancelling command commit c0729eeefdcd76db338f635162bf0739fd2c5f6f upstream. Éric Piel reported a kernel oops in the "comedi_test" module. It was a NULL pointer dereference within `waveform_ai_interrupt()` (actually a timer function) that sometimes occurred when a running asynchronous command is cancelled (either by the `COMEDI_CANCEL` ioctl or by closing the device file). This seems to be a race between the caller of `waveform_ai_cancel()` which on return from that function goes and tears down the running command, and the timer function which uses the command. In particular, `async->cmd.chanlist` gets freed (and the pointer set to NULL) by `do_become_nonbusy()` in "comedi_fops.c" but a previously scheduled `waveform_ai_interrupt()` timer function will dereference that pointer regardless, leading to the oops. Fix it by replacing the `del_timer()` call in `waveform_ai_cancel()` with `del_timer_sync()`. Signed-off-by: Ian Abbott Reported-by: Éric Piel Signed-off-by: Greg Kroah-Hartman commit dd6fd3c34614fc138369da20c535840a03e998ec Author: Ian Abbott Date: Thu Jan 3 12:15:26 2013 +0000 staging: comedi: Kconfig: COMEDI_NI_AT_A2150 should select COMEDI_FC commit 34ffb33e09132401872fe79e95c30824ce194d23 upstream. The 'ni_at_a2150' module links to `cfc_write_to_buffer` in the 'comedi_fc' module, so selecting 'COMEDI_NI_AT_A2150' in the kernel config needs to also select 'COMEDI_FC'. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 81b2b4fb16aadd1d161307d7535f619aa3f3b877 Author: Éric Piel Date: Wed Dec 19 13:03:13 2012 +0100 staging: comedi: fix minimum AO period for NI 625x and NI 628x commit 34b55d8c48f4f76044d8f4d6ec3dc786cf210312 upstream. The minimum period was set to 357 ns, while the divider for these boards is 50 ns. This prevented to output at maximum speed as ni_ao_cmdtest() would return 357 but would not accept it. Not sure why it was set to 357 ns (this was done before the git history, which starts 5 years ago). My guess is that it comes from reading the specification stating a 2.8 MHz rate (~ 357 ns). The latest specification states a 2.86 MHz rate (~ 350 ns), which makes a lot more sense. Tested on a pci-6251. Signed-off-by: Éric Piel Acked-By: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 75ded7cb00915fc666186635b31796f9e06b8fd1 Author: Ian Abbott Date: Tue Dec 4 15:59:55 2012 +0000 staging: comedi: prevent auto-unconfig of manually configured devices commit 7d3135af399e92cf4c9bbc5f86b6c140aab3b88c upstream. When a low-level comedi driver auto-configures a device, a `struct comedi_dev_file_info` is allocated (as well as a `struct comedi_device`) by `comedi_alloc_board_minor()`. A pointer to the hardware `struct device` is stored as a cookie in the `struct comedi_dev_file_info`. When the low-level comedi driver auto-unconfigures the device, `comedi_auto_unconfig()` uses the cookie to find the `struct comedi_dev_file_info` so it can detach the comedi device from the driver, clean it up and free it. A problem arises if the user manually unconfigures and reconfigures the comedi device using the `COMEDI_DEVCONFIG` ioctl so that is no longer associated with the original hardware device. The problem is that the cookie is not cleared, so that a call to `comedi_auto_unconfig()` from the low-level driver will still find it, detach it, clean it up and free it. Stop this problem occurring by always clearing the `hardware_device` cookie in the `struct comedi_dev_file_info` whenever the `COMEDI_DEVCONFIG` ioctl call is successful. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 3e524dfa0c7d0b65569fb403a1702c18ca9561ad Author: Mike Dunn Date: Mon Jan 7 13:55:13 2013 -0800 ALSA: pxa27x: fix ac97 warm reset commit 3b4bc7bccc7857274705b05cf81a0c72cfd0b0dd upstream. This patch fixes some code that implements a work-around to a hardware bug in the ac97 controller on the pxa27x. A bug in the controller's warm reset functionality requires that the mfp used by the controller as the AC97_nRESET line be temporarily reconfigured as a generic output gpio (AF0) and manually held high for the duration of the warm reset cycle. This is what was done in the original code, but it was broken long ago by commit fb1bf8cd ([ARM] pxa: introduce processor specific pxa27x_assert_ac97reset()) which changed the mfp to a GPIO input instead of a high output. The fix requires the ac97 controller to obtain the gpio via gpio_request_one(), with arguments that configure the gpio as an output initially driven high. Tested on a palm treo 680 machine. Reportedly, this broken code only prevents a warm reset on hardware that lacks a pull-up on the line, which appears to be the case for me. Signed-off-by: Mike Dunn Signed-off-by: Igor Grinberg Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d512778257bc4c5c83c110094cd306d136a14714 Author: Mike Dunn Date: Mon Jan 7 13:55:12 2013 -0800 ALSA: pxa27x: fix ac97 cold reset commit 41b645c8624df6ace020a8863ad1449d69140f7d upstream. Cold reset on the pxa27x currently fails and pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44) appears in the kernel log. Through trial-and-error (the pxa270 developer's manual is mostly incoherent on the topic of ac97 reset), I got cold reset to complete by setting the WARM_RST bit in the GCR register (and later noticed that pxa3xx does this for cold reset as well). Also, a timeout loop is needed to wait for the reset to complete. Tested on a palm treo 680 machine. Signed-off-by: Mike Dunn Acked-by: Igor Grinberg Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 13fffc8624388123c85753997c1781aeb22258ac Author: Takashi Iwai Date: Tue Jan 8 13:51:30 2013 +0100 ALSA: hda - Disable runtime D3 for Intel CPT & co commit d7dab4dbbb2d1b0c903378d6bade2e4ae161804e upstream. We've got a few bug reports that the runtime D3 results in the dead HD-audio controller. It seems that the problem is in a deeper level than the sound driver itself, so as a temporal solution, disable the feature for these controllers again. Reported-and-tested-by: Vincent Blut Reported-and-tested-by: Maurizio Avogadro Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 844913456f9bcd427cf9d710f290e702942da07f Author: David Henningsson Date: Wed Dec 19 09:44:47 2012 +0100 Revert "ALSA: hda - Shut up pins at power-saving mode with Conexnat codecs" commit 7ed4165e2d01bdbbb4c1086eb73eadf0f64cbbf0 upstream. This reverts commit 697c373e34613609cb5450f98b91fefb6e910588. The original patch was meant to remove clicking, but in fact caused even more clicking instead. Thanks to c4pp4 for doing most of the work with this bug. BugLink: https://bugs.launchpad.net/bugs/886975 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 508cb26b0db4d271f6a38b9391524dd9fe7461cb Author: Linus Torvalds Date: Mon Jan 14 13:17:50 2013 -0800 vfs: add missing virtual cache flush after editing partial pages commit 6d283dba3721cc43be014b50a1acc2f35860a65a upstream. Andrew Morton pointed this out a month ago, and then I completely forgot about it. If we read a partial last page of a block device, we will zero out the end of the page, but since that page can then be mapped into user space, we should also make sure to flush the cache on architectures that have virtual caches. We have the flush_dcache_page() function for this, so use it. Now, in practice this really never matters, because nobody sane uses virtual caches to begin with, and they largely exist on old broken RISC arhitectures. And even if you did run on one of those obsolete CPU's, the whole "mmap and access the last partial page of a block device" behavior probably doesn't actually exist. The normal IO functions (read/write) will never see the zeroed-out part of the page that migth not be coherent in the cache, because they honor the size of the device. So I'm marking this for stable (3.7 only), but I'm not sure anybody will ever care. Pointed-out-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3191d984378e83fb0c8e4b18765c9aef9086155e Author: Hans de Goede Date: Fri Jan 11 12:08:58 2013 +0100 udldrmfb: udl_get_edid: drop unneeded i-- commit 7b4cf994e4c6ba48872bb25253cc393b7fb74c82 upstream. This is a left-over from when udl_get_edid returned the amount of bytes successfully read, which it no longer does. Signed-off-by: Hans de Goede Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 4313eb6bba9624764b6d8192282eb36f7a557a5a Author: Hans de Goede Date: Fri Jan 11 12:08:57 2013 +0100 udldrmfb: udl_get_edid: usb_control_msg buffer must not be on the stack commit 242187b362555849e8c971dfbbfd55f8bd9fa717 upstream. The buffer passed to usb_control_msg may end up in scatter-gather list, and may thus not be on the stack. Having it on the stack usually works on x86, but not on other archs. Signed-off-by: Hans de Goede Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 513c651beebdffa05fd7f4fa0221ea18edba6ad3 Author: Hans de Goede Date: Fri Jan 11 12:08:56 2013 +0100 udldrmfb: Fix EDID not working with monitors with EDID extension blocks commit c930812fe5ebe725760422c9c351d1f6fde1502d upstream. udldrmfb only reads the main EDID block, and if that advertises extensions the drm_edid code expects them to be present, and starts reading beyond the buffer udldrmfb passes it. Although it may be possible to read more EDID info with the udl we simpy don't know how, and even if trial and error gets it working on one device, that is no guarantee it will work on other revisions. So this patch does a simple fix in the form of patching the EDID info to report 0 extension blocks, this fixes udldrmfb only doing 1024x768 on monitors with EDID extension blocks. Signed-off-by: Hans de Goede Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 108a565af618969ee0322b92405d6f279ac540f6 Author: Mark Brown Date: Fri Jan 4 21:06:08 2013 +0000 ASoC: wm5100: Remove DSP B and left justified formats commit 5f960294e2031d12f10c8488c3446fecbf59628d upstream. These are not supported Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 22ef8a40186af788915d0444ed6edbd20e29e6f2 Author: Patrick Lai Date: Wed Dec 19 19:36:02 2012 -0800 ASoC: pcm: allow backend hardware to be freed in pause state commit 08b27848da620f206a8b6d80f26184485dd7aa40 upstream. When front-end PCM session is in paused state, back-end PCM session will be put in paused state as well if given front-end PCM session is the only client of given back-end. Then, application closes front-end PCM session, DPCM framework will not allow back-end enters HW_FREE state so back-end will never get shutdown completely. Signed-off-by: Patrick Lai Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 180f10d6ab1d22f1cac713b5e484d6dde218a0a8 Author: Axel Lin Date: Thu Dec 20 16:17:25 2012 +0800 ASoC: sta529: Fix update register bits in sta529_set_dai_fmt commit ad1937cdd59c412097ec2bb8f38c12a5640f1f9a upstream. Both the mask and mode settings are wrong in current code. According to the datasheet: S2PCFG0 (0x0A) BIT[3:1] DATA_FORMAT serial interface protocol format: 000: left Justified 001: I2S (default) 010: right justified 100: PCM no delay 101: PCM delay 111: DSP Thus fixes the defines for LEFT_J_DATA_FORMAT, I2S_DATA_FORMAT, and RIGHT_J_DATA_FORMAT. Also adds define for DATA_FORMAT_MSK. Signed-off-by: Axel Lin Acked-by: Rajeev Kumar Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 764806c51a779c7f3cc12b127962869c0196527a Author: Mark Brown Date: Fri Jan 4 10:48:10 2013 +0000 ASoC: wm2200: Remove DSP B and left justified AIF modes commit 0cc411b934c4317b363d1af993549f391852b980 upstream. These are not supported. Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit baace15abb2b21fa39c5c7b8789ca05f86d565d7 Author: Axel Lin Date: Fri Dec 21 16:28:37 2012 +0800 ASoC: wm2200: Fix setting dai format in wm2200_set_fmt commit 2a5f431592343b78896013b055582f94c12a5049 upstream. According to the defines in wm2200.h: /* * R1284 (0x504) - Audio IF 1_5 */ We should not left shift 1 bit for fmt_val when setting dai format. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit fb2aebf6fd8eaab7a6e17d7342e76a6e28f0e8a2 Author: Mark Brown Date: Fri Jan 4 21:18:12 2013 +0000 ASoC: wm2000: Fix sense of speech clarity enable commit 267f8fa2e1eef0612b2007e1f1846bcbc35cc1fa upstream. Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e63a29b3ecc1b1274298b9821a18e96f845aac77 Author: Mark Brown Date: Fri Jan 4 10:48:02 2013 +0000 ASoC: arizona: Remove DSP B and left justified AIF modes commit d71753e22b24548911b377db28f80870cf50d07b upstream. These are not supported. Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 83499ab418eb2326c9a05aed353184e2cc724493 Author: Axel Lin Date: Thu Dec 20 23:29:42 2012 +0800 ASoC: arizona: Do proper shift for setting AIF rate commit 7110a287ff2b1f3780905d1686a1a4edccb95133 upstream. ARIZONA_AIF1_RATE_MASK is 0x7800 /* AIF1_RATE - [14:11] */ Thus we need left shift ARIZONA_AIF1_RATE_SHIFT when setting aif1 rate. Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cb5685d1d73ee6d3517ee158cbb5abf6eb3ce5e1 Author: Mark Brown Date: Tue Dec 18 14:05:01 2012 +0000 ASoC: arizona: Correct FLL source definitions commit a8c02db029385fb4426e0396e108ab23cd08f384 upstream. The FLL source constants were numbered as a simple enumeration but were being used in the code as direct values to be written to the registers. Renumber the constants to reflect the usage. Reported-by: Ryo Tsutsui Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 044882a62f34cd6460196c13773bd210be39d717 Author: Roland Dreier Date: Mon Jan 7 11:45:16 2013 -0800 iscsi-target: Fix CmdSN comparison (use cmd->cmd_sn instead of cmd->stat_sn) commit 64fe4f4f181cc2fe97d4176bf6ee6e3725ae33ec upstream. Commit 64c13330a389 ("iscsi-target: Fix bug in handling of ExpStatSN ACK during u32 wrap-around") introduced a bug where we compare the wrong SN against our ExpCmdSN. Reported-by: Ben Hutchings Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit c95af8fdf6f818c74a2229500327f255a8b5b0d3 Author: Marek Vasut Date: Sat Nov 24 06:15:57 2012 +0100 HID: add quirk for Freescale i.MX23 ROM recovery commit 436136cec650d661eb662fcb508a99878606d050 upstream. The USB recovery mode present in i.MX23 ROM emulates USB HID. It needs this quirk to behave properly. Even if the official branding of the chip is Freescale i.MX23, I named it Sigmatel STMP3780 since that's what the chip really is and it even reports itself as STMP3780. Signed-off-by: Marek Vasut Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit fa6cb84c11774ebb8546d346f31b01a91c1cd09f Author: Eric Wong Date: Tue Jan 1 21:20:27 2013 +0000 epoll: prevent missed events on EPOLL_CTL_MOD commit 128dd1759d96ad36c379240f8b9463e8acfd37a1 upstream. EPOLL_CTL_MOD sets the interest mask before calling f_op->poll() to ensure events are not missed. Since the modifications to the interest mask are not protected by the same lock as ep_poll_callback, we need to ensure the change is visible to other CPUs calling ep_poll_callback. We also need to ensure f_op->poll() has an up-to-date view of past events which occured before we modified the interest mask. So this barrier also pairs with the barrier in wq_has_sleeper(). This should guarantee either ep_poll_callback or f_op->poll() (or both) will notice the readiness of a recently-ready/modified item. This issue was encountered by Andreas Voellmy and Junchang(Jason) Wang in: http://thread.gmane.org/gmane.linux.kernel/1408782/ Signed-off-by: Eric Wong Cc: Hans Verkuil Cc: Jiri Olsa Cc: Jonathan Corbet Cc: Al Viro Cc: Davide Libenzi Cc: Hans de Goede Cc: Mauro Carvalho Chehab Cc: David Miller Cc: Eric Dumazet Cc: Andrew Morton Cc: Andreas Voellmy Tested-by: "Junchang(Jason) Wang" Cc: netdev@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1b766177ea25e0fca2beffbde9bc82bdb763d1bc Author: Mark Brown Date: Tue Dec 11 01:14:11 2012 +0900 regmap: debugfs: Avoid overflows for very small reads commit db04328c167ff8e7c57f4a3532214aeada3a82fd upstream. If count is less than the size of a register then we may hit integer wraparound when trying to move backwards to check if we're still in the buffer. Instead move the position forwards to check if it's still in the buffer, we are unlikely to be able to allocate a buffer sufficiently big to overflow here. Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 22f794762d84e88c5965455b7cc4149bf6c05e5a Author: Zhang Rui Date: Tue Dec 4 23:23:16 2012 +0100 ACPI : do not use Lid and Sleep button for S5 wakeup commit b7e383046c2c7c13ad928cd7407eafff758ddd4b upstream. When system enters power off, the _PSW of Lid device is enabled. But this may cause the system to reboot instead of power off. A proper way to fix this is to always disable lid wakeup capability for S5. References: https://bugzilla.kernel.org/show_bug.cgi?id=35262 Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Cc: Joseph Salisbury Signed-off-by: Greg Kroah-Hartman commit ca3956dff41a87d21a854c8ac7fa882e41d16d62 Author: Namjae Jeon Date: Wed Oct 10 00:09:12 2012 +0900 udf: don't increment lenExtents while writing to a hole commit fb719c59bdb4fca86ee1fd1f42ab3735ca12b6b2 upstream. Incrementing lenExtents even while writing to a hole is bad for performance as calls to udf_discard_prealloc and udf_truncate_tail_extent would not return from start if isize != lenExtents Signed-off-by: Namjae Jeon Signed-off-by: Ashish Sangwan Signed-off-by: Jan Kara Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 087b1089e3a1eb5d3d8297378bba4f7d08660849 Author: Namjae Jeon Date: Wed Oct 10 00:08:56 2012 +0900 udf: fix memory leak while allocating blocks during write commit 2fb7d99d0de3fd8ae869f35ab682581d8455887a upstream. Need to brelse the buffer_head stored in cur_epos and next_epos. Signed-off-by: Namjae Jeon Signed-off-by: Ashish Sangwan Signed-off-by: Jan Kara Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit a21ebdce6d1ba32a8a514b66115753eac5f75a41 Author: Ed Cashin Date: Mon Dec 17 16:03:58 2012 -0800 aoe: remove vestigial request queue allocation commit 0a41409c518083133e79015092585d68915865be upstream. Before the aoe driver was an I/O request handler, it was a make_request-style block driver. Even so, there was a problem where sysfs expected a request queue to exist, so one was provided in commit 7135a71b19be ("aoe: allocate unused request_queue for sysfs"). During the transition to the request-handler style, a patch was merged that was based on a driver without the noop queue, and the noop queue remained in place after the patch was merged, even though a new functional queue was introduced by the patch, allocated through blk_init_queue. The user impact is a memory leak proportional to the number of AoE targets discovered. This patch removes the memory leak and cleans up vestiges of the old do-nothing queue from the aoeblk_gdalloc function. Signed-off-by: Ed Cashin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4a2113ba833fdc4d1800ad9c7fafaad23bfb4b54 Author: Guo Chao Date: Sun Jan 6 23:38:47 2013 -0500 ext4: release buffer in failed path in dx_probe() commit 0ecaef0644973e9006fdbc6974301047aaff9bc6 upstream. If checksum fails, we should also release the buffer read from previous iteration. Signed-off-by: Guo Chao Signed-off-by: "Theodore Ts'o" Reviewed-by: "Darrick J. Wong" Signed-off-by: Greg Kroah-Hartman commit d8403e29336c9c1ea90d2ed16b1534482979f1aa Author: Theodore Ts'o Date: Thu Dec 27 01:42:50 2012 -0500 ext4: avoid hang when mounting non-journal filesystems with orphan list commit 0e9a9a1ad619e7e987815d20262d36a2f95717ca upstream. When trying to mount a file system which does not contain a journal, but which does have a orphan list containing an inode which needs to be truncated, the mount call with hang forever in ext4_orphan_cleanup() because ext4_orphan_del() will return immediately without removing the inode from the orphan list, leading to an uninterruptible loop in kernel code which will busy out one of the CPU's on the system. This can be trivially reproduced by trying to mount the file system found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs source tree. If a malicious user were to put this on a USB stick, and mount it on a Linux desktop which has automatic mounts enabled, this could be considered a potential denial of service attack. (Not a big deal in practice, but professional paranoids worry about such things, and have even been known to allocate CVE numbers for such problems.) Signed-off-by: "Theodore Ts'o" Reviewed-by: Zheng Liu Signed-off-by: Greg Kroah-Hartman commit ab9f12650d4b035cf2e1e72fbb9cda45ed96b08c Author: Theodore Ts'o Date: Thu Dec 27 01:42:48 2012 -0500 ext4: lock i_mutex when truncating orphan inodes commit 721e3eba21e43532e438652dd8f1fcdfce3187e7 upstream. Commit c278531d39 added a warning when ext4_flush_unwritten_io() is called without i_mutex being taken. It had previously not been taken during orphan cleanup since races weren't possible at that point in the mount process, but as a result of this c278531d39, we will now see a kernel WARN_ON in this case. Take the i_mutex in ext4_orphan_cleanup() to suppress this warning. Reported-by: Alexander Beregalov Signed-off-by: "Theodore Ts'o" Reviewed-by: Zheng Liu Signed-off-by: Greg Kroah-Hartman commit 764df5435c448302d14c1fff0d80bf7af8aa5289 Author: Michael Tokarev Date: Tue Dec 25 14:08:16 2012 -0500 ext4: do not try to write superblock on ro remount w/o journal commit d096ad0f79a782935d2e06ae8fb235e8c5397775 upstream. When a journal-less ext4 filesystem is mounted on a read-only block device (blockdev --setro will do), each remount (for other, unrelated, flags, like suid=>nosuid etc) results in a series of scary messages from kernel telling about I/O errors on the device. This is becauese of the following code ext4_remount(): if (sbi->s_journal == NULL) ext4_commit_super(sb, 1); at the end of remount procedure, which forces writing (flushing) of a superblock regardless whenever it is dirty or not, if the filesystem is readonly or not, and whenever the device itself is readonly or not. We only need call ext4_commit_super when the file system had been previously mounted read/write. Thanks to Eric Sandeen for help in diagnosing this issue. Signed-off-By: Michael Tokarev Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 3a06c3ff07f7a00a48edbe264987cc33f409a6d5 Author: Jan Kara Date: Fri Dec 21 00:15:51 2012 -0500 jbd2: fix assertion failure in jbd2_journal_flush() commit d7961c7fa4d2e3c3f12be67e21ba8799b5a7238a upstream. The following race is possible between start_this_handle() and someone calling jbd2_journal_flush(). Process A Process B start_this_handle(). if (journal->j_barrier_count) # false if (!journal->j_running_transaction) { #true read_unlock(&journal->j_state_lock); jbd2_journal_lock_updates() jbd2_journal_flush() write_lock(&journal->j_state_lock); if (journal->j_running_transaction) { # false ... wait for committing trans ... write_unlock(&journal->j_state_lock); ... write_lock(&journal->j_state_lock); if (!journal->j_running_transaction) { # true jbd2_get_transaction(journal, new_transaction); write_unlock(&journal->j_state_lock); goto repeat; # eventually blocks on j_barrier_count > 0 ... J_ASSERT(!journal->j_running_transaction); # fails We fix the race by rechecking j_barrier_count after reacquiring j_state_lock in exclusive mode. Reported-by: yjwsignal@empal.com Signed-off-by: Jan Kara Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 7b563c7c8d2297ee7063b69c151e741b3d4b6eac Author: Jan Kara Date: Thu Dec 20 00:07:18 2012 -0500 ext4: check dioread_nolock on remount commit 261cb20cb2f0737a247aaf08dff7eb065e3e5b66 upstream. Currently we allow enabling dioread_nolock mount option on remount for filesystems where blocksize < PAGE_CACHE_SIZE. This isn't really supported so fix the bug by moving the check for blocksize != PAGE_CACHE_SIZE into parse_options(). Change the original PAGE_SIZE to PAGE_CACHE_SIZE along the way because that's what we are really interested in. Signed-off-by: Jan Kara Signed-off-by: "Theodore Ts'o" Reviewed-by: Eric Sandeen Signed-off-by: Greg Kroah-Hartman commit 7e195bc5bfc5e82fdf735372a4773e6894676911 Author: Forrest Liu Date: Mon Dec 17 09:55:39 2012 -0500 ext4: fix extent tree corruption caused by hole punch commit c36575e663e302dbaa4d16b9c72d2c9a913a9aef upstream. When depth of extent tree is greater than 1, logical start value of interior node is not correctly updated in ext4_ext_rm_idx. Signed-off-by: Forrest Liu Signed-off-by: "Theodore Ts'o" Reviewed-by: Ashish Sangwan Signed-off-by: Greg Kroah-Hartman commit 77b130deb4c58c76eec6b55e6ab123a9b280bc4d Author: Rafael J. Wysocki Date: Sat Dec 22 23:59:01 2012 +0100 PM: Move disabling/enabling runtime PM to late suspend/early resume commit 9f6d8f6ab26b42620a914d67f29822f9bba90233 upstream. Currently, the PM core disables runtime PM for all devices right after executing subsystem/driver .suspend() callbacks for them and re-enables it right before executing subsystem/driver .resume() callbacks for them. This may lead to problems when there are two devices such that the .suspend() callback executed for one of them depends on runtime PM working for the other. In that case, if runtime PM has already been disabled for the second device, the first one's .suspend() won't work correctly (and analogously for resume). To make those issues go away, make the PM core disable runtime PM for devices right before executing subsystem/driver .suspend_late() callbacks for them and enable runtime PM for them right after executing subsystem/driver .resume_early() callbacks for them. This way the potential conflitcs between .suspend_late()/.resume_early() and their runtime PM counterparts are still prevented from happening, but the subtle ordering issues related to disabling/enabling runtime PM for devices during system suspend/resume are much easier to avoid. Reported-and-tested-by: Jan-Matthias Braun Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson Reviewed-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit f3eb57e1c9738de4c35bd5219a96b2c031338b26 Author: Seth Forshee Date: Wed Dec 5 16:08:33 2012 -0600 samsung-laptop: Add quirk for broken acpi_video backlight on N250P commit e04c200f1f2de8eaa2f5af6d97e7e213a1abb424 upstream. BugLink: http://bugs.launchpad.net/bugs/1086921 Signed-off-by: Seth Forshee Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit a34bfbf421c069da5ea2f7a1d0f337b78e345039 Author: Lothar Waßmann Date: Thu Nov 22 13:49:14 2012 +0100 video: mxsfb: fix crash when unblanking the display commit 6c1ecba8d84841277d68140ef485335d5be28485 upstream. The VDCTRL4 register does not provide the MXS SET/CLR/TOGGLE feature. The write in mxsfb_disable_controller() sets the data_cnt for the LCD DMA to 0 which obviously means the max. count for the LCD DMA and leads to overwriting arbitrary memory when the display is unblanked. Signed-off-by: Lothar Waßmann Acked-by: Juergen Beisert Tested-by: Lauri Hintsala Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 8e4eba3f0b9102e133dd98ac86c083e3a51faca4 Author: Hante Meuleman Date: Wed Jan 2 15:12:39 2013 +0100 brcmfmac: fix parsing rsn ie for ap mode. commit 619c5a9ad54e6bbdafd16d1cdc6c049403710540 upstream. RSN IEs got incorrectly parsed and therefore ap mode using WPA2 security was not working. Reviewed-by: Arend Van Spriel Reviewed-by: Pieter-Paul Giesberts Signed-off-by: Hante Meuleman Signed-off-by: Arend van Spriel Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 14495b052a8abea799ba56c71b38ceeef209e3f0 Author: Sivaram Nair Date: Tue Dec 18 13:52:54 2012 +0100 cpuidle / coupled: fix ready counter decrement commit 92638e2facc5330475c7d558acec77721c3214e4 upstream. The ready_waiting_counts atomic variable is compared against the wrong online cpu count. The latter is computed incorrectly using logical-OR instead of bit-OR. This patch fixes that. Signed-off-by: Sivaram Nair Acked-by: Santosh Shilimkar Acked-by: Colin Cross Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 077264613be71c5698ccb7ff6f97ec8cf3f41317 Author: Ian Campbell Date: Mon Jan 7 05:32:06 2013 +0000 xen/netfront: improve truesize tracking commit d9a58a782e396a0f04e8445b7ba3763c8a48c7fe upstream. Using RX_COPY_THRESHOLD is incorrect if the SKB is actually smaller than that. We have already accounted for this in NETFRONT_SKB_CB(skb)->pull_to so use that instead. Fixes WARN_ON from skb_try_coalesce. Signed-off-by: Ian Campbell Cc: Sander Eikelenboom Cc: Konrad Rzeszutek Wilk Cc: annie li Cc: xen-devel@lists.xen.org Cc: netdev@vger.kernel.org Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2edbcdd71ca6c7751171221a559efcc3694c3694 Author: Kees Cook Date: Fri Jan 11 14:32:05 2013 -0800 audit: create explicit AUDIT_SECCOMP event type 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 commit 08d73254896be6d2dfa26df0a599424984ecb8c7 Author: Chris Verges Date: Fri Dec 21 01:58:34 2012 -0800 hwmon: (lm73} Detect and report i2c bus errors commit 0602934f302e016e2ea5dc6951681bfac77455ef upstream. If an LM73 device does not exist on an I2C bus, attempts to communicate with the device result in an error code returned from the i2c read/write functions. The current lm73 driver casts that return value from a s32 type to a s16 type, then converts it to a temperature in celsius. Because negative temperatures are valid, it is difficult to distinguish between an error code printed to the response buffer and a negative temperature recorded by the sensor. The solution is to evaluate the return value from the i2c functions before performing any temperature calculations. If the i2c function did not succeed, the error code should be passed back through the virtual file system layer instead of being printed into the response buffer. Before: $ cat /sys/class/hwmon/hwmon0/device/temp1_input -46 After: $ cat /sys/class/hwmon/hwmon0/device/temp1_input cat: read error: No such device or address Signed-off-by: Chris Verges Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 77114d247c1e4b7f14ca5ffec27d49e9ec95d90a Author: Malcolm Priestley Date: Sun Nov 11 16:07:57 2012 +0000 staging: vt6656: 64bit fixes: vCommandTimerWait change calculation of timer. commit 70e227790d4ee4590023d8041a3485f8053593fc upstream. The timer appears to run too fast/race on 64 bit systems. Using msecs_to_jiffies seems to cause a deadlock on 64 bit. A calculation of (MSecond * HZ) / 1000 appears to run satisfactory. Change BSSIDInfoCount to u32. After this patch the driver can be successfully connect on little endian 64/32 bit systems. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit 2e75b5b00bb60311a16752e59fe9638ac5080ce9 Author: Malcolm Priestley Date: Sun Nov 11 15:49:59 2012 +0000 staging: vt6656: 64bit fixes: key.c/h change unsigned long to u32 commit c0d05b305b00c698b0a8c1b3d46c9380bce9db45 upstream. Fixes long issues. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit 5314600e7f7ec2c978bcdbf3a165a554de8a683a Author: Malcolm Priestley Date: Sun Nov 11 15:45:52 2012 +0000 staging: vt6656: 64 bit fixes: fix long warning messages. commit b4dc03af5513774277c9c36b12a25cd3f25f4404 upstream. Fixes long warning messages from patch [PATCH 08/14] staging: vt6656: 64 bit fixes : correct all type sizes Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit 212ec470275eca2f5d0b8141e83c6e5697fd9a71 Author: Malcolm Priestley Date: Sun Nov 11 15:41:25 2012 +0000 staging: vt6656: 64 bit fixes : correct all type sizes commit 7730492855a2f9c828599bcd8d62760f96d319e4 upstream. After this patch all BYTE/WORD/DWORD types can be replaced with the appropriate u sizes. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit 29d8ba6cc019935d8c1fef02a14a10bc11830520 Author: Malcolm Priestley Date: Sun Nov 11 15:32:05 2012 +0000 staging: vt6656: 64 bit fixes: use u32 for QWORD definition. commit a552397d5e4ef0cc0bd3e9595d6acc9a3b381171 upstream. Size of long issues replace with u32. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit fb48ec355d6b206e921e127059f987ac39942aba Author: Malcolm Priestley Date: Sun Oct 7 08:27:00 2012 +0100 staging: vt6656: [BUG] out of bound array reference in RFbSetPower. commit ab1dd9963137a1e122004d5378a581bf16ae9bc8 upstream. Calling RFbSetPower with uCH zero value will cause out of bound array reference. This causes 64 bit kernels to oops on boot. Note: Driver does not function on 64 bit kernels and should be blacklisted on them. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit b5b020e9f6c65b391409552290d0979da5a4f5a6 Author: Joe Thornber Date: Fri Dec 21 20:23:31 2012 +0000 dm thin: replace dm_cell_release_singleton with cell_defer_except commit b7ca9c9273e5eebd63880dd8a6e4e5c18fc7901d upstream. Change existing users of the function dm_cell_release_singleton to share cell_defer_except instead, and then remove the now-unused function. Everywhere that calls dm_cell_release_singleton, the bio in question is the holder of the cell. If there are no non-holder entries in the cell then cell_defer_except behaves exactly like dm_cell_release_singleton. Conversely, if there *are* non-holder entries then dm_cell_release_singleton must not be used because those entries would need to be deferred. Consequently, it is safe to replace use of dm_cell_release_singleton with cell_defer_except. This patch is a pre-requisite for "dm thin: fix race between simultaneous io and discards to same block". Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit e01c4bf8aa398d2abceb73c4e4e2244b3355a51f Author: Alasdair G Kergon Date: Fri Dec 21 20:23:30 2012 +0000 dm ioctl: prevent unsafe change to dm_ioctl data_size commit e910d7ebecd1aac43125944a8641b6cb1a0dfabe upstream. Abort dm ioctl processing if userspace changes the data_size parameter after we validated it but before we finished copying the data buffer from userspace. The dm ioctl parameters are processed in the following sequence: 1. ctl_ioctl() calls copy_params(); 2. copy_params() makes a first copy of the fixed-sized portion of the userspace parameters into the local variable "tmp"; 3. copy_params() then validates tmp.data_size and allocates a new structure big enough to hold the complete data and copies the whole userspace buffer there; 4. ctl_ioctl() reads userspace data the second time and copies the whole buffer into the pointer "param"; 5. ctl_ioctl() reads param->data_size without any validation and stores it in the variable "input_param_size"; 6. "input_param_size" is further used as the authoritative size of the kernel buffer. The problem is that userspace code could change the contents of user memory between steps 2 and 4. In particular, the data_size parameter can be changed to an invalid value after the kernel has validated it. This lets userspace force the kernel to access invalid kernel memory. The fix is to ensure that the size has not changed at step 4. This patch shouldn't have a security impact because CAP_SYS_ADMIN is required to run this code, but it should be fixed anyway. Reported-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit f67218ea8e7e17ae084e2dfa1a24e02b955c3c01 Author: Mikulas Patocka Date: Fri Dec 21 20:23:30 2012 +0000 dm persistent data: rename node to btree_node commit 550929faf89e2e2cdb3e9945ea87d383989274cf upstream. This patch fixes a compilation failure on sparc32 by renaming struct node. struct node is already defined in include/linux/node.h. On sparc32, it happens to be included through other dependencies and persistent-data doesn't compile because of conflicting declarations. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit eb3b5cd16ff171d5a0f98feee8f4d088107c6334 Author: Mike Snitzer Date: Fri Dec 21 20:23:30 2012 +0000 dm: disable WRITE SAME commit c1a94672a830e01d58c7c7e8de530c3f136d6ff2 upstream. WRITE SAME bios are not yet handled correctly by device-mapper so disable their use on device-mapper devices by setting max_write_same_sectors to zero. As an example, a ciphertext device is incompatible because the data gets changed according to the location at which it written and so the dm crypt target cannot support it. Signed-off-by: Mike Snitzer Cc: Milan Broz Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 4f06f4b94023d3d1ec3a953db293d59878ac67b2 Author: Tatyana Nikolova Date: Thu Dec 6 19:58:27 2012 +0000 RDMA/nes: Fix for terminate timer crash commit 7bfcfa51c35cdd2d37e0d70fc11790642dd11fb3 upstream. The terminate timer needs to be initialized just once. Signed-off-by: Tatyana Nikolova Signed-off-by: Roland Dreier Signed-off-by: CAI Qian Signed-off-by: Greg Kroah-Hartman commit 02c397211c58c77fab36c7ec77fdf1f8db6d2f74 Author: Tatyana Nikolova Date: Thu Dec 6 20:05:02 2012 +0000 RDMA/nes: Fix for crash when registering zero length MR for CQ commit 7d9c199a55200c9b9fcad08e150470d02fb385be upstream. Signed-off-by: Tatyana Nikolova Signed-off-by: Roland Dreier Signed-off-by: CAI Qian Signed-off-by: Greg Kroah-Hartman commit b8a9600a6d5c59aefef8e4c45f10815d24170060 Author: Daniel Vetter Date: Thu Jan 10 18:03:00 2013 +0100 drm/i915: Revert shrinker changes from "Track unbound pages" commit 93927ca52a55c23e0a6a305e7e9082e8411ac9fa upstream. This partially reverts commit 6c085a728cf000ac1865d66f8c9b52935558b328 Author: Chris Wilson Date: Mon Aug 20 11:40:46 2012 +0200 drm/i915: Track unbound pages Closer inspection of that patch revealed a bunch of unrelated changes in the shrinker: - The shrinker count is now in pages instead of objects. - For counting the shrinkable objects the old code only looked at the inactive list, the new code looks at all bounds objects (including pinned ones). That is obviously in addition to the new unbound list. - The shrinker cound is no longer scaled with sysctl_vfs_cache_pressure. Note though that with the default tuning value of vfs_cache_pressue = 100 this doesn't affect the shrinker behaviour. - When actually shrinking objects, the old code first dropped purgeable objects, then normal (inactive) objects. Only then did it, in a last-ditch effort idle the gpu and evict everything. The new code omits the intermediate step of evicting normal inactive objects. Safe for the first change, which seems benign, and the shrinker count scaling, which is a bit a different story, the endresult of all these changes is that the shrinker is _much_ more likely to fall back to the last-ditch resort of idling the gpu and evicting everything. The old code could only do that if something else evicted lots of objects meanwhile (since without any other changes the nr_to_scan will be smaller than the object count). Reverting the vfs_cache_pressure behaviour itself is a bit bogus: Only dentry/inode object caches should scale their shrinker counts with vfs_cache_pressure. Originally I've had that change reverted, too. But Chris Wilson insisted that it's too bogus and shouldn't again see the light of day. Hence revert all these other changes and restore the old shrinker behaviour, with the minor adjustment that we now first scan the unbound list, then the inactive list for each object category (purgeable or normal). A similar patch has been tested by a few people affected by the gen4/5 hangs which started to appear in 3.7, which some people bisected to the "drm/i915: Track unbound pages" commit. But just disabling the unbound logic alone didn't change things at all. Note that this patch doesn't fix the referenced bugs, it only hides the underlying bug(s) well enough to restore pre-3.7 behaviour. The key to achieve that is to massively reduce the likelyhood of going into a full gpu stall and evicting everything. v2: Reword commit message a bit, taking Chris Wilson's comment into account. v3: On Chris Wilson's insistency, do not reinstate the rather bogus vfs_cache_pressure change. Tested-by: Greg KH Tested-by: Dave Kleikamp References: https://bugs.freedesktop.org/show_bug.cgi?id=55984 References: https://bugs.freedesktop.org/show_bug.cgi?id=57122 References: https://bugs.freedesktop.org/show_bug.cgi?id=56916 References: https://bugs.freedesktop.org/show_bug.cgi?id=57136 Cc: Chris Wilson Acked-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 8fe779f83994056e210b90463df1ddaccec4de09 Author: Chris Wilson Date: Wed Jan 2 10:31:22 2013 +0000 drm/i915; Only increment the user-pin-count after successfully pinning the bo commit 93be8788e648817d62fda33e2998eb6ca6ebf3a3 upstream. As along the error path we do not correct the user pin-count for the failure, we may end up with userspace believing that it has a pinned object at offset 0 (when interrupted by a signal for example). Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 2c15273e100d2f233f6dd0e993cd1d5a1043c4b8 Author: Chris Wilson Date: Wed Dec 19 16:51:06 2012 +0000 drm: Only evict the blocks required to create the requested hole commit 901593f2bf221659a605bdc1dcb11376ea934163 upstream. Avoid clobbering adjacent blocks if they happen to expire earlier and amalgamate together to form the requested hole. In passing this fixes a regression from commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c Author: Daniel Vetter Date: Fri Feb 18 17:59:12 2011 +0100 drm: mm: track free areas implicitly which swaps the end address for size (with a potential overflow) and effectively causes the eviction code to clobber almost all earlier buffers above the evictee. v2: Check the original hole not the adjusted as the coloring may confuse us when later searching for the overlapping nodes. Also make sure that we do apply the range restriction and color adjustment in the same order for both scanning, searching and insertion. v3: Send the version that was actually tested. Note that this seems to be ducttape of decent quality ot paper over some of our unbind related gpu hangs reported since 3.7. It is not fully effective though, and certainly doesn't fix the underlying bug. Signed-off-by: Chris Wilson Cc: Daniel Vetter [danvet: Added note plus bugzilla link and tested-by.] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984 Tested-by: Norbert Preining Acked-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 2370a21972ba82d0d1e65dd5341fba6387745ebd Author: Seung-Woo Kim Date: Thu Sep 27 15:30:06 2012 +0900 drm/prime: drop reference on imported dma-buf come from gem commit be8a42ae60addd8b6092535c11b42d099d6470ec upstream. Increasing ref counts of both dma-buf and gem for imported dma-buf come from gem makes memory leak. release function of dma-buf cannot be called because f_count of dma-buf increased by importing gem and gem ref count cannot be decrease because of exported dma-buf. So I add dma_buf_put() for imported gem come from its own gem into each drivers having prime_import and prime_export capabilities. With this, only gem ref count is increased if importing gem exported from gem of same driver. Signed-off-by: Seung-Woo Kim Signed-off-by: Kyungmin.park Cc: Inki Dae Cc: Daniel Vetter Cc: Rob Clark Cc: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 7a39dee1e930a9c9f6d25aa43f5a9297d0af2d4f Author: Dave Airlie Date: Thu Dec 20 10:51:09 2012 +1000 drm/i915: fix flags in dma buf exporting commit 5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 upstream. As pointed out by Seung-Woo Kim this should have been passing flags like nouveau/radeon have. Signed-off-by: Dave Airlie Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 2036d18a2e558f9aa12a1cdb961430f17e93b7f1 Author: Daniel Vetter Date: Tue Dec 18 09:37:54 2012 +0100 drm/i915: don't disable disconnected outputs commit b0a2658acb5bf9ca86b4aab011b7106de3af0add upstream. This piece of neat lore has been ported painstakingly and bug-for-bug compatible from the old crtc helper code. Imo it's utter nonsense. If you disconnected a cable and before you reconnect it, userspace (or the kernel) does an set_crtc call, this will result in that connector getting disabled. Which will result in a nice black screen when plugging in the cable again. There's absolutely no reason the kernel does such policy enforcements - if userspace tries to set up a mode on something disconnected we might fail loudly (since the dp link training fails), but silently adjusting the output configuration behind userspace's back is a recipe for disaster. Specifically I think that this could explain some of our MI_WAIT hangs around suspend, where userspace issues a scanline wait on a disable pipe. This mechanisims here could explain how that pipe got disabled without userspace noticing. Note that this fixes a NULL deref at BIOS takeover when the firmware sets up a disconnected output in a clone configuration with a connected output on the 2nd pipe: When doing the full modeset we don't have a mode for the 2nd pipe and OOPS. On the first pipe this doesn't matter, since at boot-up the fbdev helpers will set up the choosen configuration on that on first. Since this is now the umptenth bug around handling this imo brain-dead semantics correctly, I think it's time to kill it and see whether there's any userspace out there which relies on this. It also nicely demonstrates that we have a tiny window where DP hotplug can still kill the driver. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58396 Tested-by: Peter Ujfalusi Reviewed-by: Rodrigo Vivi Reviewed-by: Jesse Barnes Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 41c8765e911cf54ad0c71bf3a1642b918af937e8 Author: Chris Wilson Date: Thu Nov 1 09:26:26 2012 +0000 drm/i915: Flush outstanding unpin tasks before pageflipping commit b4a98e57fc27854b5938fc8b08b68e5e68b91e1f upstream. If we accumulate unpin tasks because we are pageflipping faster than the system can schedule its workers, we can effectively create a pin-leak. The solution taken here is to limit the number of unpin tasks we have per-crtc and to flush those outstanding tasks if we accumulate too many. This should prevent any jitter in the normal case, and also prevent the hang if we should run too fast. Note: It is important that we switch from the system workqueue to our own dev_priv->wq since all work items on that queue are guaranteed to only need the dev->struct_mutex and not any modeset resources. For otherwise if we have a work item ahead in the queue which needs the modeset lock (like the output detect work used by both polling or hpd), this work and so the unpin work will never execute since the pageflip code already holds that lock. Unfortunately there's no lockdep support for this scenario in the workqueue code. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46991 Reported-and-tested-by: Tvrtko Ursulin Signed-off-by: Chris Wilson [danvet: Added note about workqueu deadlock.] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56337 Signed-off-by: Daniel Vetter Tested-by: Daniel Gnoutcheff Signed-off-by: Greg Kroah-Hartman commit 810582c09a95e474ce0374727c53c4a8368ad417 Author: Chris Wilson Date: Mon Dec 3 11:36:30 2012 +0000 drm/i915: Close race between processing unpin task and queueing the flip commit e7d841ca03b7ab668620045cd7b428eda9f41601 upstream. Before queuing the flip but crucially after attaching the unpin-work to the crtc, we continue to setup the unpin-work. However, should the hardware fire early, we see the connected unpin-work and queue the task. The task then promptly runs and unpins the fb before we finish taking the required references or even pinning it... Havoc. To close the race, we use the flip-pending atomic to indicate when the flip is finally setup and enqueued. So during the flip-done processing, we can check more accurately whether the flip was expected. v2: Add the appropriate mb() to ensure that the writes to the page-flip worker are complete prior to marking it active and emitting the MI_FLIP. On the read side, the mb should be enforced by the spinlocks. Signed-off-by: Chris Wilson [danvet: Review the barriers a bit, we need a write barrier both before and after updating ->pending. Similarly we need a read barrier in the interrupt handler both before and after reading ->pending. With well-ordered irqs only one barrier in each place should be required, but since this patch explicitly sets out to combat spurious interrupts with is staged activation of the unpin work we need to go full-bore on the barriers, too. Discussed with Chris Wilson on irc and changes acked by him.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit e5e65a5233c3f368c442413cebe7de2a4580b564 Author: Mel Gorman Date: Fri Jan 11 14:32:16 2013 -0800 mm: compaction: partially revert capture of suitable high-order page 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 commit c49060cc36e8238d9b923e7523ff66195aba10f9 Author: Paulo Zanoni Date: Tue Nov 20 13:27:41 2012 -0200 drm/i915: make the panel fitter work on pipes B and C on IVB commit 13888d78c664a1f61d7b09d282f5916993827a40 upstream. I actually found this problem on Haswell, but then discovered Ivy Bridge also has it by reading the spec. I don't have the hardware to test this. Signed-off-by: Paulo Zanoni Reviewed-by: Damien Lespiau Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit cfdfb8f24b5bb75866fe4735b565a7a8d49e5c6c Author: Aaro Koskinen Date: Mon Dec 31 03:34:59 2012 +0200 drm/nouveau: fix init with agpgart-uninorth commit eda85d6ad490923152544fba0473798b6cc0edf6 upstream. Check that the AGP aperture can be mapped. This follows a similar change done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if the aperture can be mapped by the CPU.). The patch fixes the following error seen on G5 iMac: nouveau E[ DRM] failed to create kernel channel, -12 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58806 Reviewed-by: Michel Dänzer Signed-off-by: Aaro Koskinen Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 1af3ccd344b499bdeff716dfd82aa8f0241d007d Author: Niels Ole Salscheider Date: Thu Jan 3 19:09:28 2013 +0100 drm/radeon: Properly handle DDC probe for DP bridges commit 0a9069d34918659bc8a89e21e69e60b2b83291a3 upstream. DDC information can be accessed using AUX CH Fixes failure to probe monitors on some systems with DP bridge chips. agd5f: minor fixes Signed-off-by: Niels Ole Salscheider Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f3c27852bf18e4d473979feef1848ab95e6f2c4b Author: Alex Deucher Date: Thu Dec 20 16:35:47 2012 -0500 drm/radeon: add connector table for Mac G4 Silver commit cafa59b9011a7790be4ddd5979419259844a165d upstream. Apple cards do not provide data tables in the vbios so we have to hard code the connector parameters in the driver. Reported-by: Albrecht Dreß Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 9e9b509de67983d647c2bbce3985087d26808741 Author: Alex Deucher Date: Thu Dec 20 21:19:32 2012 -0500 drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list commit 668bbc81baf0f34df832d8aca5c7d5e19a493c68 upstream. It's used in a recent mesa commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a and there may be some other cases in the future where it's required. Signed-off-by: Alex Deucher Reviewed-by: Jerome Glisse Signed-off-by: Greg Kroah-Hartman commit 3ade78817143d8c4429cf982ff21c2395a5ab01d Author: Jerome Glisse Date: Mon Dec 17 11:04:32 2012 -0500 drm/radeon: avoid deadlock in pm path when waiting for fence commit 5f8f635edd8ad5a6416bff4c5ff486500357f473 upstream. radeon_fence_wait_empty_locked should not trigger GPU reset as no place where it's call from would benefit from such thing and it actually lead to a kernel deadlock in case the reset is triggered from pm codepath. Instead force ring completion in place where it makes sense or return early in others. Signed-off-by: Jerome Glisse Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit db44cfc70337f4f91292650e7066aa3d635d22b1 Author: Jerome Glisse Date: Mon Dec 17 10:29:06 2012 -0500 drm/radeon: don't leave fence blocked process on failed GPU reset commit 76903b96adbfbb38b049765add21e02e44c387a5 upstream. Force all fence to signal if GPU reset failed so no process get stuck on waiting fence. Signed-off-by: Jerome Glisse Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 2a384d099ad3a3a89d8b98b6a90272a800729c46 Author: Jerome Glisse Date: Fri Dec 14 16:20:46 2012 -0500 drm/radeon: restore modeset late in GPU reset path commit d3493574e267c203836bfdcb9c58d8af46fc0da1 upstream. Modeset path seems to conflict sometimes with the memory management leading to kernel deadlock. This move modesetting reset after GPU acceleration reset. Signed-off-by: Jerome Glisse Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4b5d9a570d4537037fd15019f7c0cc1bc0eff337 Author: Jerome Glisse Date: Tue Dec 11 11:56:52 2012 -0500 drm/radeon: fix amd afusion gpu setup aka sumo v2 commit bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a upstream. Set the proper number of tile pipe that should be a multiple of pipe depending on the number of se engine. Fix: https://bugs.freedesktop.org/show_bug.cgi?id=56405 https://bugs.freedesktop.org/show_bug.cgi?id=56720 v2: Don't change sumo2 Signed-off-by: Jerome Glisse Reviewed-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 431b82df6985f8d0c18f9c343c9c8015b13ad510 Author: Alex Deucher Date: Tue Dec 4 16:50:28 2012 -0500 drm/radeon: fix eDP clk and lane setup for scaled modes commit 93927f9c1db5f55085457e820f0631064c7bfa34 upstream. Need to use the adjusted mode since we are sending native timing and using the scaler for non-native modes. Signed-off-by: Alex Deucher Reviewed-by: Jerome Glisse Signed-off-by: Greg Kroah-Hartman commit 4166d4ec12857cd836d095d6fcd5ba8a6fe43510 Author: Alex Deucher Date: Tue Nov 13 18:03:41 2012 -0500 drm/radeon/dce32+: use fractional fb dividers for high clocks commit a02dc74b317d78298cb0587b9b1f6f741fd5c139 upstream. Fixes flickering with some high res montiors. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b099903257352efa7cf750162087588d2c48f89a Author: Christian König Date: Tue Sep 18 15:30:44 2012 -0400 drm/radeon: stop page faults from hanging the system (v2) commit ae133a1129790ec288b429b5f08ab4701633844a upstream. Redirect invalid memory accesses to the default page instead of locking up the memory controller. Also enable the invalid memory access interrupts and start spamming system log with it. v2 (agd5f): fix up against 2 level PT changes Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 019dfdc65ccbe1ec0f6e26da029e082416c7209f Author: Woodhouse, David Date: Wed Dec 19 13:25:35 2012 +0000 intel-iommu: Free old page tables before creating superpage commit 6491d4d02893d9787ba67279595990217177b351 upstream. The dma_pte_free_pagetable() function will only free a page table page if it is asked to free the *entire* 2MiB range that it covers. So if a page table page was used for one or more small mappings, it's likely to end up still present in the page tables... but with no valid PTEs. This was fine when we'd only be repopulating it with 4KiB PTEs anyway but the same virtual address range can end up being reused for a *large-page* mapping. And in that case were were trying to insert the large page into the second-level page table, and getting a complaint from the sanity check in __domain_mapping() because there was already a corresponding entry. This was *relatively* harmless; it led to a memory leak of the old page table page, but no other ill-effects. Fix it by calling dma_pte_clear_range (hopefully redundant) and dma_pte_free_pagetable() before setting up the new large page. Signed-off-by: David Woodhouse Tested-by: Ravi Murty Tested-by: Sudeep Dutt Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0b7deb3e6c234261798def6a39cc72981c9e6fc7 Author: Dan Williams Date: Fri Dec 14 13:10:50 2012 +0000 i2400m: add Intel 6150 device IDs commit 999a7c5776a0ed2133645fa7e008bec05bda9254 upstream. Add device IDs for WiMAX function of Intel 6150 cards. Signed-off-by: Dan Williams Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f771bae5ca892efab92c0b51988821a98f95b6af Author: Alexey Khoroshilov Date: Mon Nov 5 22:40:14 2012 +0400 jffs2: hold erase_completion_lock on exit commit 2cbba75a56ea78e6876b4e2547a882f10b3fe72b upstream. Users of jffs2_do_reserve_space() expect they still held erase_completion_lock after call to it. But there is a path where jffs2_do_reserve_space() leaves erase_completion_lock unlocked. The patch fixes it. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 5758b7dc3cc847cf0c3b3f4df9e3acb44aaffd0e Author: Trond Myklebust Date: Mon Jan 7 14:30:46 2013 -0500 SUNRPC: Ensure we release the socket write lock if the rpc_task exits early commit 87ed50036b866db2ec2ba16b2a7aec4a2b0b7c39 upstream. If the rpc_task exits while holding the socket write lock before it has allocated an rpc slot, then the usual mechanism for releasing the write lock in xprt_release() is defeated. The problem occurs if the call to xprt_lock_write() initially fails, so that the rpc_task is put on the xprt->sending wait queue. If the task exits after being assigned the lock by __xprt_lock_write_func, but before it has retried the call to xprt_lock_and_alloc_slot(), then it calls xprt_release() while holding the write lock, but will immediately exit due to the test for task->tk_rqstp != NULL. Reported-by: Chris Perl Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 0649c30fca0f15d0aae670b6e4cfa9e5776e6117 Author: Trond Myklebust Date: Fri Jan 4 12:23:21 2013 -0500 SUNRPC: Ensure that we free the rpc_task after cleanups are done commit c6567ed1402c55e19b012e66a8398baec2a726f3 upstream. This patch ensures that we free the rpc_task after the cleanup callbacks are done in order to avoid a deadlock problem that can be triggered if the callback needs to wait for another workqueue item to complete. Signed-off-by: Trond Myklebust Cc: Weston Andros Adamson Cc: Tejun Heo Cc: Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 243bddd7b189dbbb4561e33e1f34a2d361da2f9b Author: J. Bruce Fields Date: Wed Nov 14 10:48:05 2012 -0500 svcrpc: Revert "sunrpc/cache.h: replace simple_strtoul" 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 commit fac767ddb0a4eb6b6d8d416044263305db4a05e0 Author: Stanislav Kinsbursky Date: Mon Dec 17 20:18:52 2012 +0300 SUNRPC: continue run over clients list on PipeFS event instead of break commit cd6c5968582a273561464fe6b1e8cc8214be02df upstream. There are SUNRPC clients, which program doesn't have pipe_dir_name. These clients can be skipped on PipeFS events, because nothing have to be created or destroyed. But instead of breaking in case of such a client was found, search for suitable client over clients list have to be continued. Otherwise some clients could not be covered by PipeFS event handler. Signed-off-by: Stanislav Kinsbursky Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit e3e36c5ac26542baa9fc4ceb8f323659f690c2a6 Author: Trond Myklebust Date: Thu Nov 8 10:01:26 2012 -0500 SUNRPC: Fix validity issues with rpc_pipefs sb->s_fs_info commit 642fe4d00db56d65060ce2fd4c105884414acb16 upstream. rpc_kill_sb() must defer calling put_net() until after the notifier has been called, since most (all?) of the notifier callbacks assume that sb->s_fs_info points to a valid net namespace. It also must not call put_net() if the call to rpc_fill_super was unsuccessful. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=48421 Signed-off-by: Trond Myklebust Cc: Stanislav Kinsbursky Signed-off-by: Greg Kroah-Hartman commit 4be6f33ca418c24a214f19a7e2316bba1d1fe921 Author: Tomi Valkeinen Date: Thu Nov 22 10:39:56 2012 +0200 OMAP: board-files: fix i2c_bus for tfp410 commit ca2e16faa7378878c1522a7c1b6c38211de3331d upstream. The i2c handling in tfp410 driver, which handles converting parallel RGB to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af (OMAPDSS: TFP410: pdata rewrite). The patch changed what value the driver considers as invalid/undefined. Before the patch, 0 was the invalid value, but as 0 is a valid bus number, the patch changed this to -1. However, the fact was missed that many board files do not define the bus number at all, thus it's left to 0. This causes the driver to fail to get the i2c bus, exiting from the driver's probe with an error, meaning that the DVI output does not work for those boards. This patch fixes the issue by changing the i2c_bus number field in the driver's platform data from u16 to int, and setting the bus number to -1 in the board files for the boards that did not define the bus. The exception is devkit8000, for which the bus is set to 1, which is the correct bus for that board. The bug exists in v3.5+ kernels. Signed-off-by: Tomi Valkeinen Reported-by: Thomas Weber Cc: Thomas Weber Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit a77af8b6ec02d86956f5252fc37f1d9af5a93b7d Author: Pawel Moll Date: Mon Oct 29 11:23:02 2012 +0000 kbuild: Do not remove vmlinux when cleaning external module commit bd1ee804af8bdf2fd5131234330615f8aecbd9ed upstream. Since commit 1f2bfbd00e466ff3489b2ca5cc75b1cccd14c123 "kbuild: link of vmlinux moved to a script" make clean with M= argument (so cleaning external module) removes vmlinux, System.map and couple of other files from the *main* kernel build directory! This not what was happening before and almost certainly not what one would expect. This patch moves makes the clean target of the script called only when !KBUILD_EXTMOD. Signed-off-by: Pawel Moll Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit bf2c3394c626762602993707f728fdb07ba1ca4f Author: Wolfram Sang Date: Wed Dec 5 21:46:02 2012 +0100 mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems commit 6f2a6a52560ad8d85710aabd92b7a3239b3a6b07 upstream. It could happen (1 out of 100 times) that NAND did not start up correctly after warm rebooting, so the kernel could not find the UBI or DMA timed out due to a stalled BCH. When resetting BCH together with GPMI, the issue could not be observed anymore (after 10000+ reboots). We probably need the consistent state already before sending any command to NAND, even when no ECC is needed. I chose to keep the extra reset for BCH when changing the flash layout to be on the safe side. Signed-off-by: Wolfram Sang Acked-by: Huang Shijie Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 4837452e255f0ca6b7f8c49fb12de3fb660ce902 Author: Nathan Williams Date: Thu Nov 22 10:42:52 2012 +1100 mtd cs553x_nand: Initialise ecc.strength before nand_scan() commit d1f3b65d2d6fdb4bf0edd4b67e86e191af48daee upstream. Loading cs553x_nand with Hynix H27U1G8F2BTR NAND flash causes this bug: kernel BUG at drivers/mtd/nand/nand_base.c:3345! invalid opcode: 0000 [#1] Modules linked in: cs553x_nand(+) vfat fat usb_storage ehci_hcd usbcore usb_comr Pid: 436, comm: modprobe Not tainted 3.6.7 #1 EIP: 0060:[] EFLAGS: 00010296 CPU: 0 EIP is at nand_scan_tail+0x64c/0x69c EAX: 00000034 EBX: cea6ed98 ECX: 00000000 EDX: 00000000 ESI: cea6ec00 EDI: cea6ec00 EBP: 20000000 ESP: cdd17e48 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 CR0: 8005003b CR2: 0804e119 CR3: 0d850000 CR4: 00000090 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process modprobe (pid: 436, ti=cdd16000 task=cdd1c320 task.ti=cdd16000) Stack: c12e962c c118f7ef 00000003 cea6ed98 d014b25c 20000000 fffff007 00000001 00000000 cdd53b00 d014b000 c1001021 cdd53b00 d01493c0 cdd53b00 cdd53b00 d01493c0 c1047f83 d014b4a0 00000000 cdd17f9c ce4be454 cdd17f48 cdd1c320 Call Trace: [] ? nand_scan+0x1b/0x4d [] ? init_module+0x25c/0x2de [cs553x_nand] [] ? 0xd014afff [] ? do_one_initcall+0x21/0x111 [] ? sys_init_module+0xe4/0x1261 [] ? task_work_run+0x36/0x43 [] ? syscall_call+0x7/0xb Code: fa ff ff c7 86 d8 00 00 00 01 00 00 00 e9 5f fc ff ff 68 f8 26 2e c1 e8 a7 EIP: [] nand_scan_tail+0x64c/0x69c SS:ESP 0068:cdd17e48 Initialising ecc.strength before the call to nand_scan() fixes this. Signed-off-by: Nathan Williams Acked-by: Brian Norris Acked-by: Mike Dunn Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 5ec1cdca458496eb8e8461738b53fcbc2d024650 Author: Theodore Ts'o Date: Thu Nov 29 21:21:22 2012 -0500 ext4: fix possible use after free with metadata csum commit aeb1e5d69a5be592e86a926be73efb38c55af404 upstream. Commit fa77dcfafeaa introduces block bitmap checksum calculation into ext4_new_inode() in the case that block group was uninitialized. However we brelse() the bitmap buffer before we attempt to checksum it so we have no guarantee that the buffer is still there. Fix this by releasing the buffer after the possible checksum computation. Signed-off-by: Lukas Czerner Signed-off-by: "Theodore Ts'o" Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 6c96e0701d62e20a2d7ac2de6083bbe5841b9b95 Author: Eugene Shatokhin Date: Thu Nov 8 15:11:11 2012 -0500 ext4: fix memory leak in ext4_xattr_set_acl()'s error path commit 24ec19b0ae83a385ad9c55520716da671274b96c upstream. In ext4_xattr_set_acl(), if ext4_journal_start() returns an error, posix_acl_release() will not be called for 'acl' which may result in a memory leak. This patch fixes that. Reviewed-by: Lukas Czerner Signed-off-by: Eugene Shatokhin Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit a2d7d69aa0499e093f338d5f1f4e40f7f2b35db9 Author: Geert Uytterhoeven Date: Mon Oct 15 22:44:45 2012 +0200 mfd: Remove Unicode Byte Order Marks from da9055 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 commit 36623bfc682dc96a4654651f7f8ec11f86733920 Author: Charles Keepax Date: Fri Nov 9 16:15:28 2012 +0000 mfd: Only unregister platform devices allocated by the mfd core commit b9fbb62eb61452d728c39b2e5020739c575aac53 upstream. mfd_remove_devices would iterate over all devices sharing a parent with an mfd device regardless of whether they were allocated by the mfd core or not. This especially caused problems when the device structure was not contained within a platform_device, because to_platform_device is used on each device pointer. This patch defines a device_type for mfd devices and checks this is present from mfd_remove_devices_fn before processing the device. Signed-off-by: Charles Keepax Tested-by: Peter Tyser Reviewed-by: Mark Brown Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 79664c177e20f2b49e44d61f31a7cbbe6c24061c Author: Mark Brown Date: Fri Nov 23 12:05:33 2012 +0900 mfd: wm8994: Add support for WM1811 rev E commit fee546ce8cfd9dea1f53175f627e17ef5ff05df4 upstream. This is supported identically to the previous revisions. Signed-off-by: Mark Brown Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit ffd939ebf39c50a5f4e192870125bd6e2875f05d Author: Chris Boot Date: Tue Dec 11 21:58:48 2012 +0000 sbp-target: fix error path in sbp_make_tpg() commit e1fe2060d7e8f58a69374135e32e90f0bb79a7fd upstream. If the TPG memory is allocated successfully, but we fail further along in the function, a dangling pointer to freed memory is left in the TPort structure. This is mostly harmless, but does prevent re-trying the operation without first removing the TPort altogether. Reported-by: Chen Gang Signed-off-by: Chris Boot Cc: Andy Grover Cc: Nicholas A. Bellinger Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 3930216ba48431031d13f7ef757363852040a058 Author: Yi Zou Date: Mon Dec 10 17:04:00 2012 -0800 target/tcm_fc: fix the lockdep warning due to inconsistent lock state commit 9f4ad44b264f8bb61ffdd607148215566568430d upstream. The lockdep warning below is in theory correct but it will be in really weird rare situation that ends up that deadlock since the tcm fc session is hashed based the rport id. Nonetheless, the complaining below is about rcu callback that does the transport_deregister_session() is happening in softirq, where transport_register_session() that happens earlier is not. This triggers the lockdep warning below. So, just fix this to make lockdep happy by disabling the soft irq before calling transport_register_session() in ft_prli. BTW, this was found in FCoE VN2VN over two VMs, couple of create and destroy would get this triggered. v1: was enforcing register to be in softirq context which was not righ. See, http://www.spinics.net/lists/target-devel/msg03614.html v2: following comments from Roland&Nick (thanks), it seems we don't have to do transport_deregister_session() in rcu callback, so move it into ft_sess_free() but still do kfree() of the corresponding ft_sess struct in rcu callback to make sure the ft_sess is not freed till the rcu callback. ... [ 1328.370592] scsi2 : FCoE Driver [ 1328.383429] fcoe: No FDMI support. [ 1328.384509] host2: libfc: Link up on port (000000) [ 1328.934229] host2: Assigned Port ID 00a292 [ 1357.232132] host2: rport 00a393: Remove port [ 1357.232568] host2: rport 00a393: Port sending LOGO from Ready state [ 1357.233692] host2: rport 00a393: Delete port [ 1357.234472] host2: rport 00a393: work event 3 [ 1357.234969] host2: rport 00a393: callback ev 3 [ 1357.235979] host2: rport 00a393: Received a LOGO response closed [ 1357.236706] host2: rport 00a393: work delete [ 1357.237481] [ 1357.237631] ================================= [ 1357.238064] [ INFO: inconsistent lock state ] [ 1357.238450] 3.7.0-rc7-yikvm+ #3 Tainted: G O [ 1357.238450] --------------------------------- [ 1357.238450] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 1357.238450] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE0:SE0] takes: [ 1357.238450] (&(&se_tpg->session_lock)->rlock){+.?...}, at: [] transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] {SOFTIRQ-ON-W} state was registered at: [ 1357.238450] [] mark_held_locks+0x6d/0x95 [ 1357.238450] [] trace_hardirqs_on_caller+0x12d/0x197 [ 1357.238450] [] trace_hardirqs_on+0xd/0xf [ 1357.238450] [] _raw_spin_unlock_irq+0x2d/0x45 [ 1357.238450] [] __transport_register_session+0xb8/0x122 [target_core_mod] [ 1357.238450] [] transport_register_session+0x44/0x5a [target_core_mod] [ 1357.238450] [] ft_prli+0x1e3/0x275 [tcm_fc] [ 1357.238450] [] fc_rport_recv_req+0x95e/0xdc5 [libfc] [ 1357.238450] [] fc_lport_recv_els_req+0xc4/0xd5 [libfc] [ 1357.238450] [] fc_lport_recv_req+0x12f/0x18f [libfc] [ 1357.238450] [] fc_exch_recv+0x8ba/0x981 [libfc] [ 1357.238450] [] fcoe_percpu_receive_thread+0x47a/0x4e2 [fcoe] [ 1357.238450] [] kthread+0xb1/0xb9 [ 1357.238450] [] ret_from_fork+0x7c/0xb0 [ 1357.238450] irq event stamp: 275411 [ 1357.238450] hardirqs last enabled at (275410): [] rcu_process_callbacks+0x229/0x42a [ 1357.238450] hardirqs last disabled at (275411): [] _raw_spin_lock_irqsave+0x22/0x8e [ 1357.238450] softirqs last enabled at (275394): [] __do_softirq+0x246/0x26f [ 1357.238450] softirqs last disabled at (275399): [] run_ksoftirqd+0x29/0x62 [ 1357.238450] [ 1357.238450] other info that might help us debug this: [ 1357.238450] Possible unsafe locking scenario: [ 1357.238450] [ 1357.238450] CPU0 [ 1357.238450] ---- [ 1357.238450] lock(&(&se_tpg->session_lock)->rlock); [ 1357.238450] [ 1357.238450] lock(&(&se_tpg->session_lock)->rlock); [ 1357.238450] [ 1357.238450] *** DEADLOCK *** [ 1357.238450] [ 1357.238450] no locks held by ksoftirqd/0/3. [ 1357.238450] [ 1357.238450] stack backtrace: [ 1357.238450] Pid: 3, comm: ksoftirqd/0 Tainted: G O 3.7.0-rc7-yikvm+ #3 [ 1357.238450] Call Trace: [ 1357.238450] [] print_usage_bug+0x1f5/0x206 [ 1357.238450] [] ? save_stack_trace+0x2c/0x49 [ 1357.238450] [] ? print_irq_inversion_bug.part.14+0x1ae/0x1ae [ 1357.238450] [] mark_lock+0x106/0x258 [ 1357.238450] [] __lock_acquire+0x2e7/0xe53 [ 1357.238450] [] ? pvclock_clocksource_read+0x48/0xb4 [ 1357.238450] [] ? rcu_process_gp_end+0xc0/0xc9 [ 1357.238450] [] ? transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [] lock_acquire+0x119/0x143 [ 1357.238450] [] ? transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [] _raw_spin_lock_irqsave+0x54/0x8e [ 1357.238450] [] ? transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [] transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [] ? rcu_process_callbacks+0x229/0x42a [ 1357.238450] [] ft_sess_rcu_free+0x17/0x24 [tcm_fc] [ 1357.238450] [] ? ft_sess_free+0x1b/0x1b [tcm_fc] [ 1357.238450] [] rcu_process_callbacks+0x260/0x42a [ 1357.238450] [] __do_softirq+0x13a/0x26f [ 1357.238450] [] ? __schedule+0x65f/0x68e [ 1357.238450] [] run_ksoftirqd+0x29/0x62 [ 1357.238450] [] smpboot_thread_fn+0x1a5/0x1aa [ 1357.238450] [] ? smpboot_unregister_percpu_thread+0x47/0x47 [ 1357.238450] [] kthread+0xb1/0xb9 [ 1357.238450] [] ? wait_for_common+0xbb/0x10a [ 1357.238450] [] ? __init_kthread_worker+0x59/0x59 [ 1357.238450] [] ret_from_fork+0x7c/0xb0 [ 1357.238450] [] ? __init_kthread_worker+0x59/0x59 [ 1417.440099] rport-2:0-0: blocked FC remote port time out: removing rport Signed-off-by: Yi Zou Cc: Open-FCoE Cc: Nicholas A. Bellinger Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 84a4c28a7fd2b2e2f506bdcd060b8169584e0728 Author: Sebastian Andrzej Siewior Date: Wed Dec 5 12:08:29 2012 +0100 target/file: Fix 32-bit highmem breakage for SGL -> iovec mapping commit 40ff2c3b3da35dd3a00ac6722056a59b4b3f2caf upstream. This patch changes vectored file I/O to use kmap + kunmap when mapping incoming SGL memory -> struct iovec in order to properly support 32-bit highmem configurations. This is because an extra bounce buffer may be required when processing scatterlist pages allocated with GFP_KERNEL. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 39eca4f41e47835894743ab5d878f72a3981f397 Author: Xiaotian Feng Date: Thu Dec 13 16:12:18 2012 +0800 libata: fix Null pointer dereference on disk error commit 26cd4d65deba587f3cf2329b6869ce02bcbe68ec upstream. Following oops were observed when disk error happened: [ 4272.896937] sd 0:0:0:0: [sda] Unhandled error code [ 4272.896939] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK [ 4272.896942] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 5a de a7 00 00 08 00 [ 4272.896951] end_request: I/O error, dev sda, sector 5955239 [ 4291.574947] BUG: unable to handle kernel NULL pointer dereference at (null) [ 4291.658305] IP: [] ahci_activity_show+0x1/0x40 [ 4291.730090] PGD 76dbbc067 PUD 6c4fba067 PMD 0 [ 4291.783408] Oops: 0000 [#1] SMP [ 4291.822100] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sw_activity [ 4291.934235] CPU 9 [ 4291.958301] Pid: 27942, comm: hwinfo ...... ata_scsi_find_dev could return NULL, so ata_scsi_activity_{show,store} should check if atadev is NULL. Signed-off-by: Xiaotian Feng Cc: James Bottomley Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit d828328679cc84f2c766fbab04d3e569cead3c37 Author: Aaron Lu Date: Mon Dec 3 11:35:02 2012 +0800 libata: set dma_mode to 0xff in reset commit 5416912af75de9cba5d1c75b99a7888b0bbbd2fb upstream. ata_device->dma_mode's initial value is zero, which is not a valid dma mode, but ata_dma_enabled will return true for this value. This patch sets dma_mode to 0xff in reset function, so that ata_dma_enabled will not return true for this case, or it will cause problem for pata_acpi. The corrsponding bugzilla page is at: https://bugzilla.kernel.org/show_bug.cgi?id=49151 Reported-by: Phillip Wood Signed-off-by: Aaron Lu Tested-by: Szymon Janc Tested-by: Dutra Julio Acked-by: Alan Cox Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit a8a491ca60238bc7c031f7731a5730aa06b6dda7 Author: Maxime Bizon Date: Mon Oct 22 11:19:28 2012 +0200 pstore/ram: Fix undefined usage of rounddown_pow_of_two(0) commit b042e47491ba5f487601b5141a3f1d8582304170 upstream. record_size / console_size / ftrace_size can be 0 (this is how you disable the feature), but rounddown_pow_of_two(0) is undefined. As suggested by Kees Cook, use !is_power_of_2() as a condition to call rounddown_pow_of_two and avoid its undefined behavior on the value 0. This issue has been present since commit 1894a253 (ramoops: Move to fs/pstore/ram.c). Signed-off-by: Maxime Bizon Signed-off-by: Florian Fainelli Acked-by: Kees Cook Signed-off-by: Anton Vorontsov Signed-off-by: Greg Kroah-Hartman commit b82212de08b20b70efe679cd4c8579c13771e610 Author: Jack Morgenstein Date: Tue Nov 27 16:24:30 2012 +0000 mlx4_core: Fix potential deadlock in mlx4_eq_int() commit 311f813a2daefcba03f706a692fe0c67888d7622 upstream. The slave_state_lock spinlock is used in both interrupt context and process context, hence irq locking must be used. Found by lockdep. Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit aa538df256f8b65e707a30ece2548f1cd555e78a Author: Jack Morgenstein Date: Tue Nov 27 16:24:29 2012 +0000 IB/mlx4: Fix spinlock order to avoid lockdep warnings commit ceb7decb366591e9b67d70832e07f5d240572a3d upstream. lockdep warns about taking a hard-irq-unsafe lock (sriov->id_map_lock) inside a hard-irq-safe lock (sriov->going_down_lock). Since id_map_lock is never taken in the interrupt context, we can simply reverse the order of taking the two spinlocks, thus avoiding the warning and the depencency. Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 40e76e0a9e3211830067cfb248f27a91c48bee57 Author: Mattia Dongili Date: Fri Dec 21 07:21:09 2012 +0900 sony-laptop: fix SNC buffer calls when SN06 returns Integers commit dcbeec264d73b7228ffdfe767eab69b2353099b1 upstream. SN06 in some cases returns an Integer instead of a buffer. While the code handling the return value was trying to cope with the difference, the memcpy call was not making any difference between the two types of acpi_object union. This regression was introduced in 3.5. While there also rework the return value logic to improve readability. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=48671 Cc: Fabrizio Narni Cc: Signed-off-by: Mattia Dongili Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit 948dd7e6ca27070bfc2831e64f2178abc1465b98 Author: Mikael Pettersson Date: Sun Sep 16 20:53:43 2012 +0200 sata_promise: fix hardreset lockdep error commit 3100d49d3cd236443faae9d81137c81b22d36003 upstream. sata_promise's pdc_hard_reset_port() needs to serialize because it flips a port-specific bit in controller register that's shared by all ports. The code takes the ata host lock for this, but that's broken because an interrupt may arrive on our irq during the hard reset sequence, and that too will take the ata host lock. With lockdep enabled a big nasty warning is seen. Fixed by adding private state to the ata host structure, containing a second lock used only for serializing the hard reset sequences. This eliminated the lockdep warnings both on my test rig and on the original reporter's machine. Signed-off-by: Mikael Pettersson Tested-by: Adko Branil Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit c6e74389447ce2f0fb7f4ed917039dd65ac09b8d Author: Steve Hodgson Date: Fri Nov 16 08:06:17 2012 -0800 qla2xxx: Look up LUN for abort requests commit 06e97b489006f28e23bb028febfa1c01c266d676 upstream. Search through the list of pending commands on the session list to find the command the initiator is actually aborting, so that we can pass the correct LUN to the core TMR handling code. (nab: Allow abort requests to work to LUN=0 with mainline target code) Signed-off-by: Steve Hodgson Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 972d1d6d45c82772dd32c2feeba3a067eb52ce70 Author: Wei Yongjun Date: Fri Nov 23 12:07:39 2012 +0800 iscsit: use GFP_ATOMIC under spin lock commit 3c989d7603872bf878840f7ce3ea49b73bea4c6c upstream. The function iscsit_build_conn_drop_async_message() is called from iscsit_close_connection() with spin lock 'sess->conn_lock' held, so we should use GFP_ATOMIC instead of GFP_KERNEL. Signed-off-by: Wei Yongjun Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 15c53de53001f0c03b884c3c7d120ba3155bf9ac Author: Roland Dreier Date: Mon Nov 5 18:02:42 2012 -0800 iscsi-target: Always send a response before terminating iSCSI connection commit 1c5c12c666fda27c7c494b34934a0a0631a48130 upstream. There are some cases, for example when the initiator sends an out-of-bounds ErrorRecoveryLevel value, where the iSCSI target terminates the connection without sending back any error. Audit the login path and add appropriate iscsit_tx_login_rsp() calls to make sure this doesn't happen. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit b81446dc304c2ee93fe15c8b87dc56c0ebad89d5 Author: Steve Hodgson Date: Mon Nov 5 18:02:41 2012 -0800 iscsi-target: Fix bug in handling of ExpStatSN ACK during u32 wrap-around commit 64c13330a38935120501b19c97a3e6095747c7a1 upstream. This patch fixes a bug in the hanlding of initiator provided ExpStatSN and individual iscsi_cmd->stat_sn comparision during iscsi_conn->stat_sn wrap-around within iscsit_ack_from_expstatsn() code. This bug would manifest itself as iscsi_cmd descriptors not being Acked by a lower ExpStatSn, causing them to be leaked until an iSCSI connection or session reinstatement event occurs to release all commands. Also fix up two other uses of incorrect CmdSN SNA comparison to use wrapper usage from include/scsi/iscsi_proto.h. Signed-off-by: Steve Hodgson Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 31e015990c4645d43db93c159495979c3f8601a7 Author: Steve Hodgson Date: Wed Nov 21 02:39:56 2012 -0500 SCSI: qla2xxx: Free rsp_data even on error in qla2x00_process_loopback() commit 9bceab4e08c5e329e9def7fe1cab41c467236517 upstream. Signed-off-by: Steve Hodgson Signed-off-by: Armen Baloyan Signed-off-by: Saurav Kashyap Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 5e7c991e20bb1e6ada35e99011846799d07660f9 Author: Giridhar Malavali Date: Wed Nov 21 02:39:55 2012 -0500 SCSI: qla2xxx: Change in setting UNLOADING flag and FC vports logout sequence while unloading qla2xxx driver. commit 220d36b4c2d96446e88d561714829ec5801b4fc7 upstream. Signed-off-by: Giridhar Malavali Signed-off-by: Saurav Kashyap Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 75e411e6e52e836f44317282f2586894625f8f9a Author: David Jeffery Date: Wed Nov 21 02:39:54 2012 -0500 SCSI: qla2xxx: Test and clear FCPORT_UPDATE_NEEDED atomically. commit a394aac88506159e047630fc90dc2242568382d8 upstream. When the qla2xxx driver loses access to multiple, remote ports, there is a race condition which can occur which will keep the request stuck on a scsi request queue indefinitely. This bad state occurred do to a race condition with how the FCPORT_UPDATE_NEEDED bit is set in qla2x00_schedule_rport_del(), and how it is cleared in qla2x00_do_dpc(). The problem port has its drport pointer set, but it has never been processed by the driver to inform the fc transport that the port has been lost. qla2x00_schedule_rport_del() sets drport, and then sets the FCPORT_UPDATE_NEEDED bit. In qla2x00_do_dpc(), the port lists are walked and any drport pointer is handled and the fc transport informed of the port loss, then the FCPORT_UPDATE_NEEDED bit is cleared. This leaves a race where the dpc thread is processing one port removal, another port removal is marked with a call to qla2x00_schedule_rport_del(), and the dpc thread clears the bit for both removals, even though only the first removal was actually handled. Until another event occurs to set FCPORT_UPDATE_NEEDED, the later port removal is never finished and qla2xxx stays in a bad state which causes requests to become stuck on request queues. This patch updates the driver to test and clear FCPORT_UPDATE_NEEDED atomically. This ensures the port state changes are processed and not lost. Signed-off-by: David Jeffery Signed-off-by: Chad Dupuis Signed-off-by: Saurav Kashyap Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 5c8533cb197d1c6c40b4cd36bca559ec9bcadc3c Author: Armen Baloyan Date: Wed Nov 21 02:39:53 2012 -0500 SCSI: qla2xxx: Properly set result field of bsg_job reply structure for success and failure. commit 63ea923a97cb0d78efcbbd229950e101588f0ddb upstream. FC transport on receiving bsg_job submission failure, calls bsg_job->job_done() and sets the bsg_job->reply->result the returned value. In contrast, when the success code (0) is returned fc transport doesn't call bsg_job->job_done() and doesn't populate bsg_job->reply->result. Signed-off-by: Steve Hodgson Signed-off-by: Armen Baloyan Signed-off-by: Saurav Kashyap Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit a376e11af4cbd47b3f939bb71c29f4aed58cec21 Author: Sasha Levin Date: Thu Nov 15 15:51:46 2012 -0500 SCSI: prevent stack buffer overflow in host_reset commit 072f19b4bea31cdd482d79f805413f2f9ac9e233 upstream. store_host_reset() has tried to re-invent the wheel to compare sysfs strings. Unfortunately it did so poorly and never bothered to check the input from userspace before overwriting stack with it, so something simple as: echo "WoopsieWoopsie" > /sys/devices/pseudo_0/adapter0/host0/scsi_host/host0/host_reset would result in: [ 316.310101] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81f5bac7 [ 316.310101] [ 316.320051] Pid: 6655, comm: sh Tainted: G W 3.7.0-rc5-next-20121114-sasha-00016-g5c9d68d-dirty #129 [ 316.320051] Call Trace: [ 316.340058] pps pps0: PPS event at 1352918752.620355751 [ 316.340062] pps pps0: capture assert seq #303 [ 316.320051] [] panic+0xcd/0x1f4 [ 316.320051] [] ? store_host_reset+0xd7/0x100 [ 316.320051] [] __stack_chk_fail+0x16/0x20 [ 316.320051] [] store_host_reset+0xd7/0x100 [ 316.320051] [] dev_attr_store+0x13/0x30 [ 316.320051] [] sysfs_write_file+0x101/0x170 [ 316.320051] [] vfs_write+0xb8/0x180 [ 316.320051] [] sys_write+0x50/0xa0 [ 316.320051] [] tracesys+0xe1/0xe6 Fix this by uninventing whatever was going on there and just use sysfs_streq. Bug introduced by 29443691 ("[SCSI] scsi: Added support for adapter and firmware reset"). [jejb: added necessary const to prevent compile warnings] Signed-off-by: Sasha Levin Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit ac434537ba0a4a62f220eb745fce394193fa6bd8 Author: Xi Wang Date: Fri Nov 16 14:40:03 2012 -0500 SCSI: mvsas: fix undefined bit shift commit beecadea1b8d67f591b13f7099559f32f3fd601d upstream. The macro bit(n) is defined as ((u32)1 << n), and thus it doesn't work with n >= 32, such as in mvs_94xx_assign_reg_set(): if (i >= 32) { mvi->sata_reg_set |= bit(i); ... } The shift ((u32)1 << n) with n >= 32 also leads to undefined behavior. The result varies depending on the architecture. This patch changes bit(n) to do a 64-bit shift. It also simplifies mv_ffc64() using __ffs64(), since invoking ffz() with ~0 is undefined. Signed-off-by: Xi Wang Acked-by: Xiangliang Yu Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 7b9442906ecd833be4d67a8f9bfa161155a32de6 Author: Sangbeom Kim Date: Sat Nov 24 11:13:28 2012 +0900 regulator: s2mps11: Fix ramp delay value shift operation commit f7ebaaeb0b4b97b20c1816f11884e7bfe610a2fa upstream. This patch fix the abnormal ramp delay setting. The shift operation was wrong. Signed-off-by: Sangbeom Kim Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0c05b7d73d113ef6fefbe6024f75ed0888cf3063 Author: Lars-Peter Clausen Date: Fri Dec 7 18:30:51 2012 +0100 ASoC: sigmadsp: Fix endianness conversion issue commit a3adb1432d7a3ad86bb17a1638e44414537e4118 upstream. The 'addr' field of the sigma_action struct is stored as big endian in the firmware file. Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b68a40d30dd3b56b8fd744e3a97ba2b76eda58c3 Author: Mark Brown Date: Wed Nov 28 13:46:56 2012 +0000 ASoC: wm8994: Use the same DCS codes for all WM1811 variants commit 72222be39afbd39c16eb180646b0ac44bb1ba460 upstream. Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b791ca8fdc546678386a98a17be6f872472f50a4 Author: Bjørn Mork Date: Wed Dec 19 20:51:31 2012 +0100 watchdog: Fix disable/enable regression commit 3935e89505a1c3ab3f3b0c7ef0eae54124f48905 upstream. Commit 8d4516904b39 ("watchdog: Fix CPU hotplug regression") causes an oops or hard lockup when doing echo 0 > /proc/sys/kernel/nmi_watchdog echo 1 > /proc/sys/kernel/nmi_watchdog and the kernel is booted with nmi_watchdog=1 (default) Running laptop-mode-tools and disconnecting/connecting AC power will cause this to trigger, making it a common failure scenario on laptops. Instead of bailing out of watchdog_disable() when !watchdog_enabled we can initialize the hrtimer regardless of watchdog_enabled status. This makes it safe to call watchdog_disable() in the nmi_watchdog=0 case, without the negative effect on the enabled => disabled => enabled case. All these tests pass with this patch: - nmi_watchdog=1 echo 0 > /proc/sys/kernel/nmi_watchdog echo 1 > /proc/sys/kernel/nmi_watchdog - nmi_watchdog=0 echo 0 > /sys/devices/system/cpu/cpu1/online - nmi_watchdog=0 echo mem > /sys/power/state Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51661 Signed-off-by: Bjørn Mork Cc: Norbert Warmuth Cc: Joseph Salisbury Cc: Thomas Gleixner Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 19130bd42d6cd68525ee2cd77c386d5a954800c1 Author: Stephan Gatzka Date: Wed Nov 28 20:04:32 2012 +0100 firewire: net: Fix handling of fragmented multicast/broadcast packets. commit 9d2373420900a39f5212a3b289331aa3535b1000 upstream. This patch fixes both the transmit and receive portion of sending fragmented mutlicast and broadcast packets. The transmit section was broken because the offset for INTFRAG and LASTFRAG packets were just miscalculated by IEEE1394_GASP_HDR_SIZE (which was reserved with skb_push() in fwnet_send_packet). The receive section was broken because in fwnet_incoming_packet is a call to fwnet_peer_find_by_node_id(). Called with generation == -1 it will not find a peer and the partial datagrams are associated to a peer. [Stefan R: The fix to use context->card->generation is not perfect. It relies on the IR tasklet which processes packets from the prior bus generation to run before the self-ID-complete worklet which sets the current card generation. Alas, there is no simple way of a race-free implementation. Let's do it this way for now.] Signed-off-by: Stephan Gatzka Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit f3aa52b005647292321379c54cb1b9cb1fcf8130 Author: Christian Lamparter Date: Sat Dec 22 04:35:24 2012 +0100 carl9170: fix -EINVAL bailout during init with !CONFIG_MAC80211_MESH commit 6c653f66772c39c5e25db715bbd4730596fccd9e upstream. Sean reported that as of 3.7, his AR9170 device no longer works because the driver fails during initialization. He noted this is due to: "In carl9170/fw.c, ar->hw->wiphy is tagged with NL80211_IFTYPE_MESH_POINT support if the firmware has Content after Beacon Queuing. This is both in interface_modes and the only iface_combinations entry. If CONFIG_MAC80211_MESH is not set, ieee80211_register_hw removes NL80211_IFTYPE_MESH_POINT from interface_modes, but not iface_combinations. wiphy_register then checks to see if every interface type in every interface combination is in interface_modes. NL80211_IFTYPE_MESH_POINT was removed, so you get a WARN_ON warning and it returns -EINVAL, giving up." Unfortunately, the iface_combination (types) feature bitmap in ieee80211_iface_limit is part of a const member in the ieee80211_iface_combination struct. Hence, the MESH_POINT feature flag can't be masked by wiphy_register in the same way as interface_modes in ieee80211_register_hw. Reported-by: Sean Patrick Santos Signed-off-by: Christian Lamparter Tested-by: Sean Patrick Santos Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 7b3da3acecc614511a9f6bde79c529f1020361ed Author: Stanislaw Gruszka Date: Mon Dec 3 12:56:33 2012 +0100 mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL commit 5b632fe85ec82e5c43740b52e74c66df50a37db3 upstream. Commit f0425beda4d404a6e751439b562100b902ba9c98 "mac80211: retry sending failed BAR frames later instead of tearing down aggr" caused regression on rt2x00 hardware (connection hangs). This regression was fixed by commit be03d4a45c09ee5100d3aaaedd087f19bc20d01 "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails". But the latter commit caused yet another problem reported in https://bugzilla.kernel.org/show_bug.cgi?id=42828#c22 After long discussion in this thread: http://mid.gmane.org/20121018075615.GA18212@redhat.com and testing various alternative solutions, which failed on one or other setup, we have no other good fix for the issues like just revert both mentioned earlier commits. To do not affect other hardware which benefit from commit f0425beda4d404a6e751439b562100b902ba9c98, instead of reverting it, introduce flag that when used will restore mac80211 behaviour before the commit. Signed-off-by: Stanislaw Gruszka [replaced link with mid.gmane.org that has message-id] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 71351c91f95f986507a3bf05732284ad3e31dc85 Author: Sujith Manoharan Date: Wed Dec 26 12:27:39 2012 +0530 ath9k_hw: Fix RX gain initvals for AR9485 commit a796a1dd5da9645ad77aa687d1a890ecd63ab5a6 upstream. Populate iniModesRxGain with the correct initvals array for AR9485 v1.1 Signed-off-by: Sujith Manoharan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 1ceaa1eb68534c48bf9107b6fe5ccc45222a3981 Author: Felix Fietkau Date: Mon Dec 10 14:03:17 2012 +0100 ath9k_hw: Fix signal strength / channel noise reporting commit b7c0c238898d200e80487516e2b67aba2a522cc0 upstream. While AR_PHY_CCA_NOM_VAL_* does contain the expected internal noise floor for a chip measured in clean air, it refers to the lowest expected reading. Depending on the frequency, this measurement can vary by about 6db, thus causing a higher reported channel noise and signal strength. Factor in the 6db offset when converting internal noisefloor to channel noise. This patch makes the reported values more accurate for all chips without affecting NF calibration behavior. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 804661bbd0ed3f8175ff07d189d04feb97901f33 Author: Gabor Juhos Date: Sun Dec 9 23:57:09 2012 +0100 ath9k: ar9003: fix OTP register offsets for AR9340 commit b3cd8021379306c0be6932e4d3b4b01efc681769 upstream. Trying to access the OTP memory on the AR9340 causes a data bus error like this: Data bus error, epc == 86e84164, ra == 86e84164 Oops[#1]: Cpu 0 $ 0 : 00000000 00000061 deadc0de 00000000 $ 4 : b8115f18 00015f18 00000007 00000004 $ 8 : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c $12 : 7c7c3c7c 001f0041 00000000 7c7c7c3c $16 : 86ee0000 00015f18 00000000 00000007 $20 : 00000004 00000064 00000004 86d71c44 $24 : 00000000 86e6ca00 $28 : 86d70000 86d71b20 86ece0c0 86e84164 Hi : 00000000 Lo : 00000064 epc : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw] Tainted: G O ra : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw] Status: 1100d403 KERNEL EXL IE Cause : 4080801c PrId : 0001974c (MIPS 74Kc) Modules linked in: ath9k(O+) ath9k_common(O) ath9k_hw(O) ath(O) ar934x_nfc mac80211(O) usbcore usb_common scsi_mod nls_base nand nand_ecc nand_ids crc_ccitt cfg80211(O) compat(O) arc4 aes_generic crypto_blkcipher cryptomgr aead crypto_hash crypto_algapi ledtrig_timer ledtrig_default_on leds_gpio Process insmod (pid: 459, threadinfo=86d70000, task=87942140, tls=779ac440) Stack : 802fb500 000200da 804db150 804e0000 87816130 86ee0000 00010000 86d71b88 86d71bc0 00000004 00000003 86e9fcd0 80305300 0002c0d0 86e74c50 800b4c20 000003e8 00000001 00000000 86ee0000 000003ff 86e9fd64 80305300 80123938 fffffffc 00000004 000058bc 00000000 86ea0000 86ee0000 000001ff 878d6000 99999999 86e9fdc0 86ee0fcc 86e9e664 0000c0d0 86ee0000 0000700000007000 ... Call Trace: [<86e84164>] ath9k_hw_wait+0x58/0xb0 [ath9k_hw] [<86e9fcd0>] ath9k_hw_setup_statusring+0x16b8/0x1c7c [ath9k_hw] Code: 0000a812 0040f809 00000000 <00531024> 1054000b 24020001 0c05b5dc 2404000a 26520001 The cause of the error is that the OTP register offsets are different on the AR9340 than the actually used values. Signed-off-by: Gabor Juhos Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 71b918dfa5de78821fbab403f8003b96930bc0e9 Author: Felix Fietkau Date: Thu Dec 6 18:40:11 2012 +0100 Revert "ath9k_hw: Update AR9003 high_power tx gain table" commit 9c170e068636deb3e3f96114034bb711675f0faa upstream. This reverts commit f74b9d365ddd33a375802b064f96a5d0e99af7c0. Turns out reverting commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd "ath9k_hw: Updated AR9003 tx gain table for 5GHz" was not enough to bring the tx power back to normal levels on devices like the Buffalo WZR-HP-G450H, this one needs to be reverted as well. This revert improves tx power by ~10 db on that device Signed-off-by: Felix Fietkau Cc: rmanohar@qca.qualcomm.com Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit bcc86b4d54b8f0ad6818c2ee2e1d113fd2fffb02 Author: Rajkumar Manoharan Date: Thu Oct 25 17:11:31 2012 +0530 ath9k_hw: Enable hw PLL power save for AR9462 commit 1680260226a8fd2aab590319da83ad8e610da9bd upstream. This reduced the power consumption to half in full and network sleep. Signed-off-by: Rajkumar Manoharan Cc: Paul Stewart Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 2212805736fc988e4eb0b0c1df5dd5d4c53b1c04 Author: Max Filippov Date: Fri Jan 11 14:31:52 2013 -0800 mm: bootmem: fix free_all_bootmem_core() with odd bitmap alignment commit 10d73e655cef6e86ea8589dca3df4e495e4900b0 upstream. Currently free_all_bootmem_core ignores that node_min_pfn may be not multiple of BITS_PER_LONG. Eg commit 6dccdcbe2c3e ("mm: bootmem: fix checking the bitmap when finally freeing bootmem") shifts vec by lower bits of start instead of lower bits of idx. Also if (IS_ALIGNED(start, BITS_PER_LONG) && vec == ~0UL) assumes that vec bit 0 corresponds to start pfn, which is only true when node_min_pfn is a multiple of BITS_PER_LONG. Also loop in the else clause can double-free pages (e.g. with node_min_pfn == start == 1, map[0] == ~0 on 32-bit machine page 32 will be double-freed). This bug causes the following message during xtensa kernel boot: bootmem::free_all_bootmem_core nid=0 start=1 end=8000 BUG: Bad page state in process swapper pfn:00001 page:d04bd020 count:0 mapcount:-127 mapping: (null) index:0x2 page flags: 0x0() Call Trace: bad_page+0x8c/0x9c free_pages_prepare+0x5e/0x88 free_hot_cold_page+0xc/0xa0 __free_pages+0x24/0x38 __free_pages_bootmem+0x54/0x56 free_all_bootmem_core$part$11+0xeb/0x138 free_all_bootmem+0x46/0x58 mem_init+0x25/0xa4 start_kernel+0x11e/0x25c should_never_return+0x0/0x3be7 The fix is the following: - always align vec so that its bit 0 corresponds to start - provide BITS_PER_LONG bits in vec, if those bits are available in the map - don't free pages past next start position in the else clause. Signed-off-by: Max Filippov Cc: Gavin Shan Cc: Johannes Weiner Cc: Tejun Heo Cc: Yinghai Lu Cc: Joonsoo Kim Cc: Prasad Koya Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6f72e73ab0fb89eb51afd9a6dbb2ff339541b3c1 Author: Laura Abbott Date: Fri Jan 11 14:31:51 2013 -0800 mm: use aligned zone start for pfn_to_bitidx calculation commit c060f943d0929f3e429c5d9522290584f6281d6e upstream. The current calculation in pfn_to_bitidx assumes that (pfn - zone->zone_start_pfn) >> pageblock_order will return the same bit for all pfn in a pageblock. If zone_start_pfn is not aligned to pageblock_nr_pages, this may not always be correct. Consider the following with pageblock order = 10, zone start 2MB: pfn | pfn - zone start | (pfn - zone start) >> page block order ---------------------------------------------------------------- 0x26000 | 0x25e00 | 0x97 0x26100 | 0x25f00 | 0x97 0x26200 | 0x26000 | 0x98 0x26300 | 0x26100 | 0x98 This means that calling {get,set}_pageblock_migratetype on a single page will not set the migratetype for the full block. Fix this by rounding down zone_start_pfn when doing the bitidx calculation. For our use case, the effects of this bug were mostly tied to the fact that CMA allocations would either take a long time or fail to happen. Depending on the driver using CMA, this could result in anything from visual glitches to application failures. Signed-off-by: Laura Abbott Acked-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b743b4f99918fee303eead2b877d1a6daa306a40 Author: Jason Liu Date: Fri Jan 11 14:31:47 2013 -0800 mm: compaction: fix echo 1 > compact_memory return error issue commit 7964c06d66c76507d8b6b662bffea770c29ef0ce upstream. when run the folloing command under shell, it will return error sh/$ echo 1 > /proc/sys/vm/compact_memory sh/$ sh: write error: Bad address After strace, I found the following log: ... write(1, "1\n", 2) = 3 write(1, "", 4294967295) = -1 EFAULT (Bad address) write(2, "echo: write error: Bad address\n", 31echo: write error: Bad address ) = 31 This tells system return 3(COMPACT_COMPLETE) after write data to compact_memory. The fix is to make the system just return 0 instead 3(COMPACT_COMPLETE) from sysctl_compaction_handler after compaction_nodes finished. Signed-off-by: Jason Liu Suggested-by: David Rientjes Acked-by: Mel Gorman Cc: Rik van Riel Cc: Minchan Kim Cc: KAMEZAWA Hiroyuki Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9310564820f93829c014863584652949a47ed12d Author: Huacai Chen Date: Mon Aug 13 20:52:24 2012 +0800 MIPS: Fix poweroff failure when HOTPLUG_CPU configured. commit 8add1ecb81f541ef2fcb0b85a5470ad9ecfb4a84 upstream. When poweroff machine, kernel_power_off() call disable_nonboot_cpus(). And if we have HOTPLUG_CPU configured, disable_nonboot_cpus() is not an empty function but attempt to actually disable the nonboot cpus. Since system state is SYSTEM_POWER_OFF, play_dead() won't be called and thus disable_nonboot_cpus() hangs. Therefore, we make this patch to avoid poweroff failure. Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: Yong Zhang Cc: Fuxin Zhang Cc: Zhangjin Wu Patchwork: https://patchwork.linux-mips.org/patch/4211/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 9a42216b9006eb49b7275a429a30bef3ea517e3a Author: Sebastian Ott Date: Fri Nov 30 16:48:59 2012 +0100 s390/cio: fix pgid reserved check commit d99e79ec5574fc556c988f613ed6175f6de66f4a upstream. The check to whom a device is reserved is done by checking the path state of the affected channel paths. If it turns out that one path is flagged as reserved by someone else the whole device is marked as such. However the meaning of the RESVD_ELSE bit is that the addressed device is reserved to a different pathgroup (and not reserved to a different LPAR). If we do this test on a path which is currently not a member of the pathgroup we could erroneously mark the device as reserved to someone else. To fix this collect the reserved state for all potential members of the pathgroup and only mark the device as reserved if all of those potential members have the RESVD_ELSE bit set. Acked-by: Peter Oberparleiter Signed-off-by: Sebastian Ott Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 40bc15c0f535f4e6b88e8b50cfac2beed67efa55 Author: Alex Williamson Date: Thu Nov 29 14:07:59 2012 -0700 KVM: Fix user memslot overlap check commit 5419369ed6bd4cf711fdda5e52a5999b940413f5 upstream. Prior to memory slot sorting this loop compared all of the user memory slots for overlap with new entries. With memory slot sorting, we're just checking some number of entries in the array that may or may not be user slots. Instead, walk all the slots with kvm_for_each_memslot, which has the added benefit of terminating early when we hit the first empty slot, and skip comparison to private slots. Signed-off-by: Alex Williamson Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 1280178d00bf09683fa47a94a98c16437c18edd7 Author: Scott Wood Date: Wed Aug 22 15:04:23 2012 +0000 KVM: PPC: e500: fix allocation size error on g2h_tlb1_map commit e400e72f250d2567e89c9bafb47ab91e8d9a15a2 upstream. We were only allocating half the bytes we need, which was made more obvious by a recent fix to the memset in clear_tlb1_bitmap(). Signed-off-by: Scott Wood Signed-off-by: Alexander Graf Signed-off-by: Greg Kroah-Hartman commit 8e290e6ceafb54d615f4c18e4a163eba9d684eed Author: Gabor Juhos Date: Thu Dec 20 03:44:28 2012 +0000 powerpc: Add missing NULL terminator to avoid boot panic on PPC40x commit e6449c9b2d90c1bd9a5985bf05ddebfd1631cd6b upstream. The missing NULL terminator can cause a panic on PPC405 boards during boot: Linux/PowerPC load: console=ttyS0,115200 root=/dev/mtdblock1 rootfstype=squashfs,jffs2 noinitrd init=/etc/preinit Finalizing device tree... flat tree at 0x6a5160 bootconsole [udbg0] enabled Page fault in user mode with in_atomic() = 1 mm = (null) NIP = c0275f50 MSR = fffffffe Oops: Weird page fault, sig: 11 [#1] PowerPC 40x Platform Modules linked in: NIP: c0275f50 LR: c0275f60 CTR: c0280000 REGS: c0275eb0 TRAP: 636f7265 Not tainted (3.7.1) MSR: fffffffe CR: c06a6190 XER: 00000001 TASK = c02662a8[0] 'swapper' THREAD: c0274000 GPR00: c0275ec0 c000c658 c027c4bf 00000000 c0275ee0 c000a0ec c020a1a8 c020a1f0 GPR08: c020f631 c020f404 c025f078 c025f080 c0275f10 Call Trace: ---[ end trace 31fd0ba7d8756001 ]--- Kernel panic - not syncing: Attempted to kill the idle task! The panic happens since commit 9597abe00c1bab2aedce6b49866bf6d1e81c9eed (sections: fix section conflicts in arch/powerpc), however the root cause of this is that the NULL terminator were not added in commit a4f740cf33f7f6c164bbde3c0cdbcc77b0c4997c (of/flattree: Add of_flat_dt_match() helper function). Signed-off-by: Gabor Juhos Cc: Grant Likely Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 02b2d18491edaaf1560030145ba40fbe3aad6e5e Author: Shan Hai Date: Thu Nov 8 15:57:49 2012 +0000 powerpc/vdso: Remove redundant locking in update_vsyscall_tz() commit ce73ec6db47af84d1466402781ae0872a9e7873c upstream. The locking in update_vsyscall_tz() is not only unnecessary because the vdso code copies the data unproteced in __kernel_gettimeofday() but also introduces a hard to reproduce race condition between update_vsyscall() and update_vsyscall_tz(), which causes user space process to loop forever in vdso code. The following patch removes the locking from update_vsyscall_tz(). Locking is not only unnecessary because the vdso code copies the data unprotected in __kernel_gettimeofday() but also erroneous because updating the tb_update_count is not atomic and introduces a hard to reproduce race condition between update_vsyscall() and update_vsyscall_tz(), which further causes user space process to loop forever in vdso code. The below scenario describes the race condition, x==0 Boot CPU other CPU proc_P: x==0 timer interrupt update_vsyscall x==1 x++;sync settimeofday update_vsyscall_tz x==2 x++;sync x==3 sync;x++ sync;x++ proc_P: x==3 (loops until x becomes even) Because the ++ operator would be implemented as three instructions and not atomic on powerpc. A similar change was made for x86 in commit 6c260d58634 ("x86: vdso: Remove bogus locking in update_vsyscall_tz") Signed-off-by: Shan Hai Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit b0edb762d994e75e4fc99629633d34fa20833034 Author: Anton Blanchard Date: Sun Nov 11 19:01:05 2012 +0000 powerpc: Fix CONFIG_RELOCATABLE=y CONFIG_CRASH_DUMP=n build commit 11ee7e99f35ecb15f59b21da6a82d96d2cd3fcc8 upstream. If we build a kernel with CONFIG_RELOCATABLE=y CONFIG_CRASH_DUMP=n, the kernel fails when we run at a non zero offset. It turns out we were incorrectly wrapping some of the relocatable kernel code with CONFIG_CRASH_DUMP. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 5b0a3f20ea6632c956787d20676178498c1005b9 Author: Christian Borntraeger Date: Thu Nov 15 09:35:16 2012 +0100 s390/kvm: Fix address space mixup commit ce6a04ac1b759beafc88dbc443ae5da867579eeb upstream. I was chasing down a bug of random validity intercepts on s390. (guest prefix page not mapped in the host virtual aspace). Turns out that the problem was a wrong address space control element. The cause was quite complex: During paging activity a DAT protection during SIE caused a program interrupt. Normally, the sie retry loop tries to catch all interrupts during and shortly before sie to rerun the setup. The problem is now that protection causes a suppressing program interrupt, causing the PSW to point to the instruction AFTER SIE in case of DAT protection. This confused the logic of the retry loop to not trigger, instead we jumped directly back to SIE after return from the program interrupt. (the protection fault handler itself did a rewind of the psw). This usually works quite well, but: If now the protection fault handler has to wait, another program might be scheduled in. Later on the sie process will be schedules in again. In that case the content of CR1 (primary address space) will be wrong because switch_to will put the user space ASCE into CR1 and not the guest ASCE. In addition the program parameter is also wrong for every protection fault of a guest, since we dont issue the SPP instruction. So lets also check for PSW == instruction after SIE in the program check handler. Instead of expensively checking all program interruption codes that might be suppressing we assume that a program interrupt pointing after SIE was always a program interrupt in SIE. (Otherwise we have a kernel bug anyway). We also have to compensate the rewinding, since the C-level handlers will do that. Therefore we need to add a nop with the same length as SIE before the sie_loop. Signed-off-by: Christian Borntraeger Signed-off-by: Martin Schwidefsky CC: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit a9234777b4cdf210360e085d267e70a40500e8ef Author: Christian Borntraeger Date: Tue Oct 2 16:25:38 2012 +0200 s390/kvm: dont announce RRBM support commit 87cac8f879a5ecd7109dbe688087e8810b3364eb upstream. Newer kernels (linux-next with the transparent huge page patches) use rrbm if the feature is announced via feature bit 66. RRBM will cause intercepts, so KVM does not handle it right now, causing an illegal instruction in the guest. The easy solution is to disable the feature bit for the guest. This fixes bugs like: Kernel BUG at 0000000000124c2a [verbose debug info unavailable] illegal operation: 0001 [#1] SMP Modules linked in: virtio_balloon virtio_net ipv6 autofs4 CPU: 0 Not tainted 3.5.4 #1 Process fmempig (pid: 659, task: 000000007b712fd0, ksp: 000000007bed3670) Krnl PSW : 0704d00180000000 0000000000124c2a (pmdp_clear_flush_young+0x5e/0x80) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3 00000000003cc000 0000000000000004 0000000000000000 0000000079800000 0000000000040000 0000000000000000 000000007bed3918 000000007cf40000 0000000000000001 000003fff7f00000 000003d281a94000 000000007bed383c 000000007bed3918 00000000005ecbf8 00000000002314a6 000000007bed36e0 Krnl Code:>0000000000124c2a: b9810025 ogr %r2,%r5 0000000000124c2e: 41343000 la %r3,0(%r4,%r3) 0000000000124c32: a716fffa brct %r1,124c26 0000000000124c36: b9010022 lngr %r2,%r2 0000000000124c3a: e3d0f0800004 lg %r13,128(%r15) 0000000000124c40: eb22003f000c srlg %r2,%r2,63 [ 2150.713198] Call Trace: [ 2150.713223] ([<00000000002312c4>] page_referenced_one+0x6c/0x27c) [ 2150.713749] [<0000000000233812>] page_referenced+0x32a/0x410 [...] Signed-off-by: Martin Schwidefsky CC: Alex Graf Signed-off-by: Christian Borntraeger Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 99219d1135e9badaa08b18348aa44fd5772b39ea Author: Helmut Schaa Date: Mon Dec 3 22:35:39 2012 +0100 rt2x00: Only specify interface combinations if more then one interface is possible commit f5685ba675449b072feab6a5391a9ef9f604bc94 upstream. Otherwise rt2500* triggers a warning in cfg80211, from net/wireless/core.c: /* Combinations with just one interface aren't real */ if (WARN_ON(c->max_interfaces < 2)) This was introduced in commit 55d2e9da744ba11eae900b4bfc2da72eace3c1e1: rt2x00: Replace open coded interface checking with interface combinations. Reported-by: Stefan Lippers-Hollmann Tested-by: Stefan Lippers-Hollmann Signed-off-by: Helmut Schaa Acked-by: Gertjan van Wingerde Acked-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit fead3a6089083e7cbd03482970a06eb29dc6e290 Author: Rafał Miłecki Date: Mon Dec 10 07:53:56 2012 +0100 bcma: mips: fix clearing device IRQ commit cbbc0138efe1dcd5426b8fc5d87741f5057aee72 upstream. We were using wrong IRQ number so clearing wasn't working at all. Depending on a platform this could result in a one device having two interrupts assigned. On BCM4706 this resulted in all IRQs being broken. Signed-off-by: Rafał Miłecki Cc: Hauke Mehrtens Acked-by: Hauke Mehrtens Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 0f3bbc6a750c13a1aa862ec4268f530ab062b04a Author: Emmanuel Grumbach Date: Sun Dec 2 09:56:44 2012 +0200 iwlwifi: silently ignore fw flaws in Tx path commit 27edb1accf5695ff00a32c85c4a00ac7e1e7f298 upstream. We know that we have issues with the fw in the reclaim path. This is why iwl_reclaim doesn't complain too loud when it happens since it is recoverable. Somehow, the caller of iwl_reclaim however WARNed when it happens. This doesn't make any sense. When I digged into the history of that code, I discovered that this bug occurs only when we receive a BA notification. So move the W/A in the BA notification handling code where it was before. This patch addresses: http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2387 Reported-by: Florian Reitmeir Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e445c3386549b8d37e709a40e269d246906c4f98 Author: Emmanuel Grumbach Date: Wed Nov 28 10:51:34 2012 +0200 iwlwifi: don't handle masked interrupt commit 25a172655f837bdb032e451f95441bb4acec51bb upstream. This can lead to a panic if the driver isn't ready to handle them. Since our interrupt line is shared, we can get an interrupt at any time (and CONFIG_DEBUG_SHIRQ checks that even when the interrupt is being freed). If the op_mode has gone away, we musn't call it. To avoid this the transport disables the interrupts when the hw is stopped and the op_mode is leaving. If there is an event that would cause an interrupt the INTA register is updated regardless of the enablement of the interrupts: even if the interrupts are disabled, the INTA will be changed, but the device won't issue an interrupt. But the ISR can be called at any time, so we ought ignore the value in the INTA otherwise we can call the op_mode after it was freed. I found this bug when the op_mode_start failed, and called iwl_trans_stop_hw(trans, true). Then I played with the RFKILL button, and removed the module. While removing the module, the IRQ is freed, and the ISR is called (CONFIG_DEBUG_SHIRQ enabled). Panic. Signed-off-by: Emmanuel Grumbach Reviewed-by: Gregory Greenman Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 5f67a938114e5b5960100710699d082ce56fb1c6 Author: Felix Fietkau Date: Mon Dec 10 16:40:41 2012 +0100 ath5k: fix tx path skb leaks commit 596ab5ec3bf10a22be30d7cb1d903a4b83fd607c upstream. ieee80211_free_txskb() needs to be used instead of dev_kfree_skb_any for tx packets passed to the driver from mac80211 Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit c035745613eb1a144575b9660c01c6aafa13d5d5 Author: Mark Brown Date: Tue Nov 20 10:02:06 2012 +0900 regulator: wm831x: Set the new rather than old value for DVS VSEL commit 13ae633cf729b0ecb677b75b04886ff8fada8fad upstream. Reported-by: Guennadi Liakhovetski Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman