From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by gnuweeb.org (Postfix) with ESMTPS id 452457ED92 for ; Mon, 6 Jun 2022 18:28:44 +0000 (UTC) Authentication-Results: gnuweeb.org; dkim=pass (1024-bit key; unprotected) header.d=linux-foundation.org header.i=@linux-foundation.org header.a=rsa-sha256 header.s=google header.b=e5deP955; dkim-atps=neutral Received: by mail-ed1-f51.google.com with SMTP id x5so14875865edi.2 for ; Mon, 06 Jun 2022 11:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qXYqp07Gt1ZtS5TmqPmPcYjNyQa7EHn+PPqLupxduxE=; b=e5deP955cqquSyg6oIIx3CAf8kgiTaqIY9bcnFfEj7ZLflDPPAW86Emcn95M8HZaCC 42qc7J70nZug2SNdJKjJgyCMPhAPg0LD/D4YMTCvWKzcs83etYmdBaLlq/Isztw3LXqz giP1rEm6h5Y0md23q+Lg6Uqv0VYv58smLzap0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qXYqp07Gt1ZtS5TmqPmPcYjNyQa7EHn+PPqLupxduxE=; b=ywaw6aZtVE3PnMjNTGPm7ESpk0/bjWKwmFrDiFIy4zWJ6mqrFSfpCVtj5XcRr2hLYm 75g9b40vKjWBua04x0dqxYAEVoHrTOSbDUu/pYCgIysiUEtqovegqLpQB9rNqrSEdeQ2 zH1hWbLLRRgG+6qFsjn2feJrT9aE7WFV7QZODT2foIUGMZ9xyhkWMaroDXlt2kIOxTwk LecCX05RYgb1s+Yqw3vMMNSb1PJjmMG0n0cxixiuaZI8eWuXPGguULox5d8vZ0OKfKi6 +FvX3LE2qZIWbqWTvpSn8wi9j2EIIbPjIKpwvtBE/vjMUUnyeGFBnVVtmS+riKKIZGhC 0QhQ== X-Gm-Message-State: AOAM5319OoNh6pVgY2eNk4VEXjelgq0EFMdz8L3rsOXV2uGEALg9RwXT EvOjRFKo5qwlB/Ct64ZVa5V9J//5AiGUMPNSI/s= X-Google-Smtp-Source: ABdhPJylHXMkjmJxsSGC0p8RQikL7hHfxL4+gX2MLpA9qZfzjK3GhoQQwViyz7o6hKgkd6eyeeRJUQ== X-Received: by 2002:a05:6402:26c1:b0:42e:203d:ee8c with SMTP id x1-20020a05640226c100b0042e203dee8cmr24227305edd.227.1654540122319; Mon, 06 Jun 2022 11:28:42 -0700 (PDT) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com. [209.85.221.45]) by smtp.gmail.com with ESMTPSA id gk2-20020a17090790c200b006febce7081esm6678504ejb.177.2022.06.06.11.28.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jun 2022 11:28:41 -0700 (PDT) Received: by mail-wr1-f45.google.com with SMTP id k19so20946398wrd.8 for ; Mon, 06 Jun 2022 11:28:40 -0700 (PDT) X-Received: by 2002:a05:6000:1b0f:b0:210:313a:ef2a with SMTP id f15-20020a0560001b0f00b00210313aef2amr22896573wrz.281.1654540120455; Mon, 06 Jun 2022 11:28:40 -0700 (PDT) MIME-Version: 1.0 References: <226cee6a-6ca1-b603-db08-8500cd8f77b7@gnuweeb.org> <87r1414y5v.fsf@email.froward.int.ebiederm.org> In-Reply-To: <87r1414y5v.fsf@email.froward.int.ebiederm.org> From: Linus Torvalds Date: Mon, 6 Jun 2022 11:28:23 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Linux 5.18-rc4 To: "Eric W. Biederman" Cc: Ammar Faizi , John Johansen , James Morris , LSM List , Linux Kernel Mailing List , Al Viro , Kees Cook , "" , Linux-MM , gwml@vger.gnuweeb.org Content-Type: text/plain; charset="UTF-8" List-Id: On Mon, Jun 6, 2022 at 8:19 AM Eric W. Biederman wrote: > Has anyone looked into this lock ordering issues? The deadlock is > >> [78140.503821] CPU0 CPU1 > >> [78140.503823] ---- ---- > >> [78140.503824] lock(&newf->file_lock); > >> [78140.503826] lock(&p->alloc_lock); > >> [78140.503828] lock(&newf->file_lock); > >> [78140.503830] lock(&ctx->lock); and the alloc_lock -> file_lock on CPU1 is trivial - it's seq_show() in fs/proc/fd.c: task_lock(task); files = task->files; if (files) { unsigned int fd = proc_fd(m->private); spin_lock(&files->file_lock); and that looks all normal. But the other chains look painful. I do see the IPC code doing ugly things, in particular I detest this code: task_lock(current); list_add(&shp->shm_clist, ¤t->sysvshm.shm_clist); task_unlock(current); where it is using the task lock to protect the shm_clist list. Nasty. And it's doing that inside the shm_ids.rwsem lock _and_ inside the shp->shm_perm.lock. So the IPC code has newseg() doing shmget -> ipcget(): down_write(ids->rwsem) -> newseg(): ipc_addid gets perm->lock task_lock(current) so you have ids->rwsem -> perm->lock -> alloc_lock there. So now we have that ids->rwsem -> ipcperm->lock -> alloc_lock -> file_lock when you put those sequences together. But I didn't figure out what the security subsystem angle is and how that then apparently mixes things up with execve. Yes, newseg() is doing that error = security_shm_alloc(&shp->shm_perm); while holding rwsem, but I can't see how that matters. From the lockdep output, rwsem doesn't actually seem to be part of the whole sequence. It *looks* like we have apparmour ctx->lock --> radix_tree_preloads.lock --> ipcperm->lock and apparently that's called under the file_lock somewhere, completing the circle. I guess the execve component is that begin_new_exec -> security_bprm_committing_creds -> apparmor_bprm_committing_creds -> aa_inherit_files -> iterate_fd -> *takes file_lock* match_file -> aa_file_perm -> update_file_ctx *takes ctx->lock* so that's how you get file_lock -> ctx->lock. So you have: SHMGET: ipcperm->lock -> alloc_lock /proc: alloc_lock -> file_lock apparmor_bprm_committing_creds: file_lock -> ctx->lock and then all you need is ctx->lock -> ipcperm->lock but I didn't find that part. I suspect that part is that both Apparmor and IPC use the idr local lock. Linus