linux-toradex.git/fs, branch colibri Linux kernel for Apalis and Colibri modules proc: enhance time-average nr_running stats 2012-07-01T16:15:16+00:00 Alex Frid afrid@nvidia.com 2012-05-16T21:27:13+00:00 66df1168a350946cf1f2951371f6d530f1878fe8 Add time-average nr_running to loadavg printout Bug 958978 Change-Id: I5c6904efb52a86f4964eb66c1576fc91f60f5b1d Signed-off-by: Alex Frid <afrid@nvidia.com> (cherry picked from commit 86f3642cc44a69d1e4798719bd9182cd6923f526) Reviewed-on: http://git-master/r/111636 Reviewed-by: Sai Gurrappadi <sgurrappadi@nvidia.com> Tested-by: Sai Gurrappadi <sgurrappadi@nvidia.com> Reviewed-by: Automatic_Commit_Validation_User Reviewed-by: Peter Boonstoppel <pboonstoppel@nvidia.com> Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com> 
Add time-average nr_running to loadavg printout

Bug 958978

Change-Id: I5c6904efb52a86f4964eb66c1576fc91f60f5b1d
Signed-off-by: Alex Frid <afrid@nvidia.com>
(cherry picked from commit 86f3642cc44a69d1e4798719bd9182cd6923f526)
Reviewed-on: http://git-master/r/111636
Reviewed-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Tested-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Peter Boonstoppel <pboonstoppel@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
fat: Remove FAT Directory Bread message 2012-06-11T22:59:33+00:00 naveenk naveenk@nvidia.com 2012-04-27T06:33:50+00:00 2e07c84338f6391c2b9428be511a1fd5ffb4262f Remove FAT Directory Bread message which is causing timing issues. Bug 992496 Change-Id: Ieb58e38bf8ac81f6c0558361f9f296a8e9071b33 Signed-off-by: venkata jagadish <vjagadish@nvidia.com> Reviewed-on: http://git-master/r/105354 Reviewed-by: Naveen Kumar Arepalli <naveenk@nvidia.com> Reviewed-by: Pavan Kunapuli <pkunapuli@nvidia.com> Reviewed-by: Automatic_Commit_Validation_User Reviewed-by: Bitan Biswas <bbiswas@nvidia.com> 
Remove FAT Directory Bread message which is
causing timing issues.

Bug 992496

Change-Id: Ieb58e38bf8ac81f6c0558361f9f296a8e9071b33
Signed-off-by: venkata jagadish <vjagadish@nvidia.com>
Reviewed-on: http://git-master/r/105354
Reviewed-by: Naveen Kumar Arepalli <naveenk@nvidia.com>
Reviewed-by: Pavan Kunapuli <pkunapuli@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
xfs: fix endian conversion issue in discard code 2012-02-10T02:20:30+00:00 Dave Chinner dchinner@redhat.com 2012-01-26T19:47:42+00:00 a4aa0557adc774bb364c3533986aef052dd58073 commit b1c770c273a4787069306fc82aab245e9ac72e9d upstream When finding the longest extent in an AG, we read the value directly out of the AGF buffer without endian conversion. This will give an incorrect length, resulting in FITRIM operations potentially not trimming everything that it should. Note, for 3.0-stable this has been modified to apply to fs/xfs/linux-2.6/xfs_discard.c instead of fs/xfs/xfs_discard.c. -bpm Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ben Myers <bpm@sgi.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: Iad84b2bb82ee0d410cdb64eeea3a8431c5a0a7ad Reviewed-on: http://git-master/r/79660 Reviewed-by: Automatic_Commit_Validation_User 
commit b1c770c273a4787069306fc82aab245e9ac72e9d upstream

When finding the longest extent in an AG, we read the value directly
out of the AGF buffer without endian conversion. This will give an
incorrect length, resulting in FITRIM operations potentially not
trimming everything that it should.

Note, for 3.0-stable this has been modified to apply to
fs/xfs/linux-2.6/xfs_discard.c instead of fs/xfs/xfs_discard.c.  -bpm

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: Iad84b2bb82ee0d410cdb64eeea3a8431c5a0a7ad
Reviewed-on: http://git-master/r/79660
Reviewed-by: Automatic_Commit_Validation_User
xfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink() 2012-02-10T02:20:18+00:00 Jan Kara jack@suse.cz 2012-01-11T18:52:10+00:00 b51e517d28543e8ea56ae13ccf1f42c475aa3275 commit 9b025eb3a89e041bab6698e3858706be2385d692 upstream. Commit b52a360b forgot to call xfs_iunlock() when it detected corrupted symplink and bailed out. Fix it by jumping to 'out' instead of doing return. CC: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Reviewed-by: Alex Elder <elder@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Ben Myers <bpm@sgi.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: Ie83d93a6bbe0997f8a41afa9e3bf6f12cee476c6 Reviewed-on: http://git-master/r/79655 Reviewed-by: Automatic_Commit_Validation_User 
commit 9b025eb3a89e041bab6698e3858706be2385d692 upstream.

Commit b52a360b forgot to call xfs_iunlock() when it detected corrupted
symplink and bailed out. Fix it by jumping to 'out' instead of doing return.

CC: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Alex Elder <elder@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: Ie83d93a6bbe0997f8a41afa9e3bf6f12cee476c6
Reviewed-on: http://git-master/r/79655
Reviewed-by: Automatic_Commit_Validation_User
eCryptfs: Fix oops when printing debug info in extent crypto functions 2012-02-10T02:20:10+00:00 Tyler Hicks tyhicks@canonical.com 2012-01-24T16:02:22+00:00 704157b7ceb50c8d5154ccb5d53813235455b692 commit 58ded24f0fcb85bddb665baba75892f6ad0f4b8a upstream. If pages passed to the eCryptfs extent-based crypto functions are not mapped and the module parameter ecryptfs_verbosity=1 was specified at loading time, a NULL pointer dereference will occur. Note that this wouldn't happen on a production system, as you wouldn't pass ecryptfs_verbosity=1 on a production system. It leaks private information to the system logs and is for debugging only. The debugging info printed in these messages is no longer very useful and rather than doing a kmap() in these debugging paths, it will be better to simply remove the debugging paths completely. https://launchpad.net/bugs/913651 Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: Icbb95db933d5fa76938982fcf69cacea85ecbecc Reviewed-on: http://git-master/r/79652 Reviewed-by: Automatic_Commit_Validation_User 
commit 58ded24f0fcb85bddb665baba75892f6ad0f4b8a upstream.

If pages passed to the eCryptfs extent-based crypto functions are not
mapped and the module parameter ecryptfs_verbosity=1 was specified at
loading time, a NULL pointer dereference will occur.

Note that this wouldn't happen on a production system, as you wouldn't
pass ecryptfs_verbosity=1 on a production system. It leaks private
information to the system logs and is for debugging only.

The debugging info printed in these messages is no longer very useful
and rather than doing a kmap() in these debugging paths, it will be
better to simply remove the debugging paths completely.

https://launchpad.net/bugs/913651

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: Icbb95db933d5fa76938982fcf69cacea85ecbecc
Reviewed-on: http://git-master/r/79652
Reviewed-by: Automatic_Commit_Validation_User
eCryptfs: Check inode changes in setattr 2012-02-10T02:20:07+00:00 Tyler Hicks tyhicks@canonical.com 2012-01-20T02:33:44+00:00 58e263a27fb52705dbf7ba9840b129db801d30e9 commit a261a03904849c3df50bd0300efb7fb3f865137d upstream. Most filesystems call inode_change_ok() very early in ->setattr(), but eCryptfs didn't call it at all. It allowed the lower filesystem to make the call in its ->setattr() function. Then, eCryptfs would copy the appropriate inode attributes from the lower inode to the eCryptfs inode. This patch changes that and actually calls inode_change_ok() on the eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call would happen earlier in ecryptfs_setattr(), but there are some possible inode initialization steps that must happen first. Since the call was already being made on the lower inode, the change in functionality should be minimal, except for the case of a file extending truncate call. In that case, inode_newsize_ok() was never being called on the eCryptfs inode. Rather than inode_newsize_ok() catching maximum file size errors early on, eCryptfs would encrypt zeroed pages and write them to the lower filesystem until the lower filesystem's write path caught the error in generic_write_checks(). This patch introduces a new function, called ecryptfs_inode_newsize_ok(), which checks if the new lower file size is within the appropriate limits when the truncate operation will be growing the lower file. In summary this change prevents eCryptfs truncate operations (and the resulting page encryptions), which would exceed the lower filesystem limits or FSIZE rlimits, from ever starting. Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Reviewed-by: Li Wang <liwang@nudt.edu.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: Idbfa207399bf0f50ce92b4d6fb8ef43896c771d5 Reviewed-on: http://git-master/r/79651 Reviewed-by: Automatic_Commit_Validation_User 
commit a261a03904849c3df50bd0300efb7fb3f865137d upstream.

Most filesystems call inode_change_ok() very early in ->setattr(), but
eCryptfs didn't call it at all. It allowed the lower filesystem to make
the call in its ->setattr() function. Then, eCryptfs would copy the
appropriate inode attributes from the lower inode to the eCryptfs inode.

This patch changes that and actually calls inode_change_ok() on the
eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call
would happen earlier in ecryptfs_setattr(), but there are some possible
inode initialization steps that must happen first.

Since the call was already being made on the lower inode, the change in
functionality should be minimal, except for the case of a file extending
truncate call. In that case, inode_newsize_ok() was never being
called on the eCryptfs inode. Rather than inode_newsize_ok() catching
maximum file size errors early on, eCryptfs would encrypt zeroed pages
and write them to the lower filesystem until the lower filesystem's
write path caught the error in generic_write_checks(). This patch
introduces a new function, called ecryptfs_inode_newsize_ok(), which
checks if the new lower file size is within the appropriate limits when
the truncate operation will be growing the lower file.

In summary this change prevents eCryptfs truncate operations (and the
resulting page encryptions), which would exceed the lower filesystem
limits or FSIZE rlimits, from ever starting.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Li Wang <liwang@nudt.edu.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: Idbfa207399bf0f50ce92b4d6fb8ef43896c771d5
Reviewed-on: http://git-master/r/79651
Reviewed-by: Automatic_Commit_Validation_User
eCryptfs: Make truncate path killable 2012-02-10T02:20:03+00:00 Tyler Hicks tyhicks@canonical.com 2012-01-19T00:30:04+00:00 ab9cf2e9f3ddf639b56cec1edb2ec8d2563106a3 commit 5e6f0d769017cc49207ef56996e42363ec26c1f0 upstream. ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a page, zeroes out the appropriate portions, and then encrypts the page before writing it to the lower filesystem. It was unkillable and due to the lack of sparse file support could result in tying up a large portion of system resources, while encrypting pages of zeros, with no way for the truncate operation to be stopped from userspace. This patch adds the ability for ecryptfs_write() to detect a pending fatal signal and return as gracefully as possible. The intent is to leave the lower file in a useable state, while still allowing a user to break out of the encryption loop. If a pending fatal signal is detected, the eCryptfs inode size is updated to reflect the modified inode size and then -EINTR is returned. Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: I80e83c16c58586c700df081500b6c3e2a4a06270 Reviewed-on: http://git-master/r/79650 Reviewed-by: Automatic_Commit_Validation_User 
commit 5e6f0d769017cc49207ef56996e42363ec26c1f0 upstream.

ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a
page, zeroes out the appropriate portions, and then encrypts the page
before writing it to the lower filesystem. It was unkillable and due to
the lack of sparse file support could result in tying up a large portion
of system resources, while encrypting pages of zeros, with no way for
the truncate operation to be stopped from userspace.

This patch adds the ability for ecryptfs_write() to detect a pending
fatal signal and return as gracefully as possible. The intent is to
leave the lower file in a useable state, while still allowing a user to
break out of the encryption loop. If a pending fatal signal is detected,
the eCryptfs inode size is updated to reflect the modified inode size
and then -EINTR is returned.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I80e83c16c58586c700df081500b6c3e2a4a06270
Reviewed-on: http://git-master/r/79650
Reviewed-by: Automatic_Commit_Validation_User
ecryptfs: Improve metadata read failure logging 2012-02-10T02:20:00+00:00 Tim Gardner tim.gardner@canonical.com 2012-01-12T15:31:55+00:00 0460bba0e4b2042a2bd5984a8e96e5bda706c4cd commit 30373dc0c87ffef68d5628e77d56ffb1fa22e1ee upstream. Print inode on metadata read failure. The only real way of dealing with metadata read failures is to delete the underlying file system file. Having the inode allows one to 'find . -inum INODE`. [tyhicks@canonical.com: Removed some minor not-for-stable parts] Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: I0460c59fe4a6490683b1cf6f993945b3f05e8aca Reviewed-on: http://git-master/r/79649 Reviewed-by: Automatic_Commit_Validation_User 
commit 30373dc0c87ffef68d5628e77d56ffb1fa22e1ee upstream.

Print inode on metadata read failure. The only real
way of dealing with metadata read failures is to delete
the underlying file system file. Having the inode
allows one to 'find . -inum INODE`.

[tyhicks@canonical.com: Removed some minor not-for-stable parts]
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I0460c59fe4a6490683b1cf6f993945b3f05e8aca
Reviewed-on: http://git-master/r/79649
Reviewed-by: Automatic_Commit_Validation_User
eCryptfs: Sanitize write counts of /dev/ecryptfs 2012-02-10T02:19:58+00:00 Tyler Hicks tyhicks@canonical.com 2012-01-12T10:30:44+00:00 59f421c67d1dd3f5f065bff8f2f83088527f2752 commit db10e556518eb9d21ee92ff944530d84349684f4 upstream. A malicious count value specified when writing to /dev/ecryptfs may result in a a very large kernel memory allocation. This patch peeks at the specified packet payload size, adds that to the size of the packet headers and compares the result with the write count value. The resulting maximum memory allocation size is approximately 532 bytes. Change-Id: I4fe5831fb58f9de76c81aa4b60efa93cb100dab8 Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Reported-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Reviewed-on: http://git-master/r/79648 Reviewed-by: Automatic_Commit_Validation_User 
commit db10e556518eb9d21ee92ff944530d84349684f4 upstream.

A malicious count value specified when writing to /dev/ecryptfs may
result in a a very large kernel memory allocation.

This patch peeks at the specified packet payload size, adds that to the
size of the packet headers and compares the result with the write count
value. The resulting maximum memory allocation size is approximately 532
bytes.

Change-Id: I4fe5831fb58f9de76c81aa4b60efa93cb100dab8
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: http://git-master/r/79648
Reviewed-by: Automatic_Commit_Validation_User
Revert "proc: enable writing to /proc/pid/mem" 2012-02-03T13:54:26+00:00 Dima Zavin dima@android.com 2012-01-19T17:51:07+00:00 acf1905328610145bd85c0178479d3a70c7098ee This reverts commit 198214a7ee50375fa71a65e518341980cfd4b2f0. (cherry picked from commit dac306d896642f3dfcd878ab6a0a5b8c123722f3 from android.googlesource.com/common.git) Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: Ia8947a59125e9318f1c51cb63ceb15a6e136aad9 Reviewed-on: http://git-master/r/78884 Reviewed-by: Automatic_Commit_Validation_User 
This reverts commit 198214a7ee50375fa71a65e518341980cfd4b2f0.
(cherry picked from commit dac306d896642f3dfcd878ab6a0a5b8c123722f3 from
android.googlesource.com/common.git)

Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: Ia8947a59125e9318f1c51cb63ceb15a6e136aad9
Reviewed-on: http://git-master/r/78884
Reviewed-by: Automatic_Commit_Validation_User