The default resource group ("rdtgroup_default") is associated with the
root of the resctrl filesystem and should never be removed. New resource
groups can be created as subdirectories of the resctrl filesystem and
they can be removed from user space. There exists a safeguard in the
directory removal code (rdtgroup_rmdir()) that ensures that only
subdirectories can be removed by testing that the directory to be
removed has to be a child of the root directory.
A possible deadlock was recently fixed with commit 334b0f4e9b1b
("x86/resctrl: Fix a deadlock due to inaccurate reference"). This fix
involved associating the private data of the "mon_groups" and "mon_data"
directories to the resource group to which they belong instead of NULL
as before. A consequence of this change was that the original safeguard
code preventing removal of "mon_groups" and "mon_data" found in the root
directory failed resulting in attempts to remove the default resource
group that ends in a BUG:
kernel BUG at mm/slub.c:3969!
invalid opcode: 0000 [#1] SMP PTI
Call Trace:
rdtgroup_rmdir+0x16b/0x2c0
kernfs_iop_rmdir+0x5c/0x90
vfs_rmdir+0x7a/0x160
do_rmdir+0x17d/0x1e0
do_syscall_64+0x55/0x1d0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fix this by improving the directory removal safeguard to ensure that
subdirectories of the resctrl root directory can only be removed if
they are a child of the resctrl filesystem's root _and_ not associated
with the default resource group.
Fixes: 334b0f4e9b1b ("x86/resctrl: Fix a deadlock due to inaccurate reference")
Cc: stable(a)vger.kernel.org
Reported-by: Sai Praneeth Prakhya <sai.praneeth.prakhya(a)intel.com>
Tested-by: Sai Praneeth Prakhya <sai.praneeth.prakhya(a)intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre(a)intel.com>
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 064e9ef44cd6..9d4e73a9b5a9 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -3072,7 +3072,8 @@ static int rdtgroup_rmdir(struct kernfs_node *kn)
* If the rdtgroup is a mon group and parent directory
* is a valid "mon_groups" directory, remove the mon group.
*/
- if (rdtgrp->type == RDTCTRL_GROUP && parent_kn == rdtgroup_default.kn) {
+ if (rdtgrp->type == RDTCTRL_GROUP && parent_kn == rdtgroup_default.kn &&
+ rdtgrp != &rdtgroup_default) {
if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP ||
rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED) {
ret = rdtgroup_ctrl_remove(kn, rdtgrp);
--
2.21.0
Hi,
My name is felix. I have a quick and easy business offer that
will benefit us both immensely. The amount involved is over 9.4
Milli0n in US d0llars.
I await your immediate reply so that I can give full details.
Rgds
Felix
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 3688b0db5c331f4ec3fa5eb9f670a4b04f530700
Gitweb: https://git.kernel.org/tip/3688b0db5c331f4ec3fa5eb9f670a4b04f530700
Author: Grygorii Strashko <grygorii.strashko(a)ti.com>
AuthorDate: Wed, 08 Apr 2020 22:15:32 +03:00
Committer: Marc Zyngier <maz(a)kernel.org>
CommitterDate: Fri, 17 Apr 2020 08:59:28 +01:00
irqchip/ti-sci-inta: Fix processing of masked irqs
The ti_sci_inta_irq_handler() does not take into account INTA IRQs state
(masked/unmasked) as it uses INTA_STATUS_CLEAR_j register to get INTA IRQs
status, which provides raw status value.
This causes hard IRQ handlers to be called or threaded handlers to be
scheduled many times even if corresponding INTA IRQ is masked.
Above, first of all, affects the LEVEL interrupts processing and causes
unexpected behavior up the system stack or crash.
Fix it by using the Interrupt Masked Status INTA_STATUSM_j register which
provides masked INTA IRQs status.
Fixes: 9f1463b86c13 ("irqchip/ti-sci-inta: Add support for Interrupt Aggregator driver")
Signed-off-by: Grygorii Strashko <grygorii.strashko(a)ti.com>
Signed-off-by: Marc Zyngier <maz(a)kernel.org>
Reviewed-by: Lokesh Vutla <lokeshvutla(a)ti.com>
Link: https://lore.kernel.org/r/20200408191532.31252-1-grygorii.strashko@ti.com
Cc: stable(a)vger.kernel.org
---
drivers/irqchip/irq-ti-sci-inta.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-ti-sci-inta.c b/drivers/irqchip/irq-ti-sci-inta.c
index 8f6e6b0..7e3ebf6 100644
--- a/drivers/irqchip/irq-ti-sci-inta.c
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -37,6 +37,7 @@
#define VINT_ENABLE_SET_OFFSET 0x0
#define VINT_ENABLE_CLR_OFFSET 0x8
#define VINT_STATUS_OFFSET 0x18
+#define VINT_STATUS_MASKED_OFFSET 0x20
/**
* struct ti_sci_inta_event_desc - Description of an event coming to
@@ -116,7 +117,7 @@ static void ti_sci_inta_irq_handler(struct irq_desc *desc)
chained_irq_enter(irq_desc_get_chip(desc), desc);
val = readq_relaxed(inta->base + vint_desc->vint_id * 0x1000 +
- VINT_STATUS_OFFSET);
+ VINT_STATUS_MASKED_OFFSET);
for_each_set_bit(bit, &val, MAX_EVENTS_PER_VINT) {
virq = irq_find_mapping(domain, vint_desc->events[bit].hwirq);
The function posix_acl_create() applies the umask only if the inode
has no ACL (= NULL) or if ACLs are not supported by the filesystem
driver (= -EOPNOTSUPP).
However, this happens only after after the IS_POSIXACL() check
succeeded. If the superblock doesn't enable ACL support, umask will
never be applied. A filesystem which has no ACL support will of
course not enable SB_POSIXACL, rendering the umask-applying code path
unreachable.
This fixes a bug which causes the umask to be ignored with O_TMPFILE
on tmpfs:
https://github.com/MusicPlayerDaemon/MPD/issues/558https://bugs.gentoo.org/show_bug.cgi?id=686142#c3https://bugzilla.kernel.org/show_bug.cgi?id=203625
Signed-off-by: Max Kellermann <mk(a)cm4all.com>
Reviewed-by: J. Bruce Fields <bfields(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
fs/posix_acl.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index 249672bf54fe..e5e7a2295b99 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -589,9 +589,14 @@ posix_acl_create(struct inode *dir, umode_t *mode,
*acl = NULL;
*default_acl = NULL;
- if (S_ISLNK(*mode) || !IS_POSIXACL(dir))
+ if (S_ISLNK(*mode))
return 0;
+ if (!IS_POSIXACL(dir)) {
+ *mode &= ~current_umask();
+ return 0;
+ }
+
p = get_acl(dir, ACL_TYPE_DEFAULT);
if (!p || p == ERR_PTR(-EOPNOTSUPP)) {
*mode &= ~current_umask();
--
2.20.1