From 7298a8bf4c63161114b47c6d627480dd5a2c1e1a Mon Sep 17 00:00:00 2001 From: Pawel Moll Date: Thu, 2 Apr 2015 14:01:06 +0100 Subject: bus: arm-ccn: Provide required event arguments [ Upstream commit 8f06c51fac1ca4104b8b64872f310e28186aea42 ] Since 688d4dfcdd624192cbf03c08402e444d1d11f294 "perf tools: Support parsing parameterized events" the perf userspace tools understands "argument=?" syntax in the events file, making sure that required arguments are provided by the user and not defaulting to 0, causing confusion. This patch adds the required arguments lists for CCN events. Signed-off-by: Pawel Moll Signed-off-by: Sasha Levin --- Documentation/arm/CCN.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/arm/CCN.txt b/Documentation/arm/CCN.txt index 0632b3aad83e..715776f06df6 100644 --- a/Documentation/arm/CCN.txt +++ b/Documentation/arm/CCN.txt @@ -38,7 +38,7 @@ Example of perf tool use: / # perf list | grep ccn ccn/cycles/ [Kernel PMU event] <...> - ccn/xp_valid_flit/ [Kernel PMU event] + ccn/xp_valid_flit,xp=?,port=?,vc=?,dir=?/ [Kernel PMU event] <...> / # perf stat -C 0 -e ccn/cycles/,ccn/xp_valid_flit,xp=1,port=0,vc=1,dir=1/ \ -- cgit v1.2.3 From cb8e1eef351b640cfdb1a753ef44494fbf59186d Mon Sep 17 00:00:00 2001 From: Jan Kara Date: Wed, 14 Dec 2016 13:24:48 +0100 Subject: fs: Give dentry to inode_change_ok() instead of inode [ Upstream commit 31051c85b5e2aaaf6315f74c72a732673632a905 ] inode_change_ok() will be resposible for clearing capabilities and IMA extended attributes and as such will need dentry. Give it as an argument to inode_change_ok() instead of an inode. Also rename inode_change_ok() to setattr_prepare() to better relect that it does also some modifications in addition to checks. References: CVE-2015-1350 Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara Signed-off-by: Philipp Hahn Signed-off-by: Sasha Levin --- Documentation/filesystems/porting | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index e69274de8d0c..0500895b768f 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -287,8 +287,8 @@ implementing on-disk size changes. Start with a copy of the old inode_setattr and vmtruncate, and the reorder the vmtruncate + foofs_vmtruncate sequence to be in order of zeroing blocks using block_truncate_page or similar helpers, size update and on finally on-disk truncation which should not fail. -inode_change_ok now includes the size checks for ATTR_SIZE and must be called -in the beginning of ->setattr unconditionally. +setattr_prepare (which used to be inode_change_ok) now includes the size checks +for ATTR_SIZE and must be called in the beginning of ->setattr unconditionally. [mandatory] -- cgit v1.2.3 From 1171afc4a34e2926e6e8e27c896cf328c8825ac3 Mon Sep 17 00:00:00 2001 From: "Eric W. Biederman" Date: Wed, 14 Dec 2016 13:24:51 +0100 Subject: mnt: Add a per mount namespace limit on the number of mounts [ Upstream commit d29216842a85c7970c536108e093963f02714498 ] CAI Qian pointed out that the semantics of shared subtrees make it possible to create an exponentially increasing number of mounts in a mount namespace. mkdir /tmp/1 /tmp/2 mount --make-rshared / for i in $(seq 1 20) ; do mount --bind /tmp/1 /tmp/2 ; done Will create create 2^20 or 1048576 mounts, which is a practical problem as some people have managed to hit this by accident. As such CVE-2016-6213 was assigned. Ian Kent described the situation for autofs users as follows: > The number of mounts for direct mount maps is usually not very large because of > the way they are implemented, large direct mount maps can have performance > problems. There can be anywhere from a few (likely case a few hundred) to less > than 10000, plus mounts that have been triggered and not yet expired. > > Indirect mounts have one autofs mount at the root plus the number of mounts that > have been triggered and not yet expired. > > The number of autofs indirect map entries can range from a few to the common > case of several thousand and in rare cases up to between 30000 and 50000. I've > not heard of people with maps larger than 50000 entries. > > The larger the number of map entries the greater the possibility for a large > number of active mounts so it's not hard to expect cases of a 1000 or somewhat > more active mounts. So I am setting the default number of mounts allowed per mount namespace at 100,000. This is more than enough for any use case I know of, but small enough to quickly stop an exponential increase in mounts. Which should be perfect to catch misconfigurations and malfunctioning programs. For anyone who needs a higher limit this can be changed by writing to the new /proc/sys/fs/mount-max sysctl. Tested-by: CAI Qian Signed-off-by: "Eric W. Biederman" Conflicts: fs/namespace.c kernel/sysctl.c Signed-off-by: Philipp Hahn Signed-off-by: Sasha Levin --- Documentation/sysctl/fs.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt index 302b5ed616a6..35e17f748ca7 100644 --- a/Documentation/sysctl/fs.txt +++ b/Documentation/sysctl/fs.txt @@ -265,6 +265,13 @@ aio-nr can grow to. ============================================================== +mount-max: + +This denotes the maximum number of mounts that may exist +in a mount namespace. + +============================================================== + 2. /proc/sys/fs/binfmt_misc ---------------------------------------------------------- -- cgit v1.2.3 From ec05ce11c1e99a4c34f0c9937dc6abe00c7a43de Mon Sep 17 00:00:00 2001 From: Paul Mackerras Date: Mon, 7 Nov 2016 15:09:58 +1100 Subject: KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state [ Upstream commit 0d808df06a44200f52262b6eb72bcb6042f5a7c5 ] When switching from/to a guest that has a transaction in progress, we need to save/restore the checkpointed register state. Although XER is part of the CPU state that gets checkpointed, the code that does this saving and restoring doesn't save/restore XER. This fixes it by saving and restoring the XER. To allow userspace to read/write the checkpointed XER value, we also add a new ONE_REG specifier. The visible effect of this bug is that the guest may see its XER value being corrupted when it uses transactions. Fixes: e4e38121507a ("KVM: PPC: Book3S HV: Add transactional memory support") Fixes: 0a8eccefcb34 ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Paul Mackerras Reviewed-by: Thomas Huth Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin --- Documentation/virtual/kvm/api.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 9fa2bf8c3f6f..7830f1c34a7d 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -1955,6 +1955,7 @@ registers, find a list below: PPC | KVM_REG_PPC_TM_VSCR | 32 PPC | KVM_REG_PPC_TM_DSCR | 64 PPC | KVM_REG_PPC_TM_TAR | 64 + PPC | KVM_REG_PPC_TM_XER | 64 | | MIPS | KVM_REG_MIPS_R0 | 64 ... -- cgit v1.2.3