Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Message-ID: <2d15edac-0227-415a-b12c-922c6873ae04@kernel.dk>
Date:   Fri, 27 Oct 2023 10:39:13 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: lockdep: holding locks across syscall boundaries
Content-Language: en-US
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>
References: <a99a7fbe-ec31-4e31-87c7-1b7ae1dd1a5a@kernel.dk>
 <20231027155949.GA26550@noisy.programming.kicks-ass.net>
 <ed3c5450-3dce-4f6a-9a8c-04fcdba1cbf2@kernel.dk>
 <20231027161235.GB26550@noisy.programming.kicks-ass.net>
From:   Jens Axboe <axboe@kernel.dk>
In-Reply-To: <20231027161235.GB26550@noisy.programming.kicks-ass.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 10/27/23 10:12 AM, Peter Zijlstra wrote:
> The difference is that in this case the full lock order is determined by
> kernel code (under our full control), while in the earlier example, the
> lock order is determined by syscall order -- out of our control.

Ah yes, good point - this seems like the key concept here. I think we're
better off doing this seperately and just return -EDEADLK or something
like that if it's being violated, rather than spew complaints.

Thanks!

-- 
Jens Axboe