commit 1888926ea8d25287d9339ca618230867d63002f6 Author: Greg Kroah-Hartman Date: Thu Oct 20 10:03:41 2016 +0200 Linux 4.8.3 commit 89eeba1594ac641a30b91942961e80fae978f839 Author: Linus Torvalds Date: Thu Oct 13 13:07:36 2016 -0700 mm: remove gup_flags FOLL_WRITE games from __get_user_pages() commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream. This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug"). In the meantime, the s390 situation has long been fixed, and we can now fix it by checking the pte_dirty() bit properly (and do it better). The s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement software dirty bits") which made it into v3.9. Earlier kernels will have to look at the page state itself. Also, the VM has become more scalable, and what used a purely theoretical race back then has become easier to trigger. To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid. Reported-and-tested-by: Phil "not Paul" Oester Acked-by: Hugh Dickins Reviewed-by: Michal Hocko Cc: Andy Lutomirski Cc: Kees Cook Cc: Oleg Nesterov Cc: Willy Tarreau Cc: Nick Piggin Cc: Greg Thelen Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0312017cbbb5f46dbf4932f65df0c2c66f9c8f27 Author: Artem Savkov Date: Wed Sep 14 07:40:35 2016 +1000 Make __xfs_xattr_put_listen preperly report errors. commit 791cc43b36eb1f88166c8505900cad1b43c7fe1a upstream. Commit 2a6fba6 "xfs: only return -errno or success from attr ->put_listent" changes the returnvalue of __xfs_xattr_put_listen to 0 in case when there is insufficient space in the buffer assuming that setting context->count to -1 would be enough, but all of the ->put_listent callers only check seen_enough. This results in a failed assertion: XFS: Assertion failed: context->count >= 0, file: fs/xfs/xfs_xattr.c, line: 175 in insufficient buffer size case. This is only reproducible with at least 2 xattrs and only when the buffer gets depleted before the last one. Furthermore if buffersize is such that it is enough to hold the last xattr's name, but not enough to hold the sum of preceeding xattr names listxattr won't fail with ERANGE, but will suceed returning last xattr's name without the first character. The first character end's up overwriting data stored at (context->alist - 1). Signed-off-by: Artem Savkov Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Cc: Eric Sandeen Signed-off-by: Greg Kroah-Hartman commit 8523011cec401fcf524cff3b8119ab2fa5c9ac0f Author: Heiner Kallweit Date: Wed Aug 3 21:49:03 2016 +0200 scsi: configure runtime pm before calling device_add in scsi_add_host_with_dma commit 0d5644b7d8daa3c1d91acb4367731f568c9c9469 upstream. Runtime PM should be configured already once we call device_add. See also the description in this mail thread https://lists.linuxfoundation.org/pipermail/linux-pm/2009-November/023198.html or the order of calls e.g. in usb_new_device. The changed order also helps to avoid scenarios where runtime pm for &shost->shost_gendev is activated whilst the parent is suspended, resulting in error message "runtime PM trying to activate child device hostx but parent yyy is not active". In addition properly reverse the runtime pm calls in the error path. Signed-off-by: Heiner Kallweit Acked-by: Alan Stern Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit ccb3dd25005d999605637f0203ce67be9373eac2 Author: Laurent Pinchart Date: Wed Aug 17 09:57:37 2016 -0300 v4l: rcar-fcp: Don't force users to check for disabled FCP support commit fd44aa9a254b18176ec3792a18e7de6977030ca8 upstream. The rcar_fcp_enable() function immediately returns successfully when the FCP device pointer is NULL to avoid forcing the users to check the FCP device manually before every call. However, the stub version of the function used when the FCP driver is disabled returns -ENOSYS unconditionally, resulting in a different API contract for the two versions of the function. As a user that requires FCP support will fail at probe time when calling rcar_fcp_get() if the FCP driver is disabled, the stub version of the rcar_fcp_enable() function will only be called with a NULL FCP device. We can thus return 0 unconditionally to align the behaviour with the normal version of the function. Reported-by: Sergei Shtylyov Signed-off-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman