Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756686Ab3IMI3u (ORCPT ); Fri, 13 Sep 2013 04:29:50 -0400 Received: from merlin.infradead.org ([205.233.59.134]:41105 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755753Ab3IMI3p (ORCPT ); Fri, 13 Sep 2013 04:29:45 -0400 Date: Fri, 13 Sep 2013 10:29:33 +0200 From: Peter Zijlstra To: Thomas Hellstrom Cc: Maarten Lankhorst , Daniel Vetter , Dave Airlie , intel-gfx , dri-devel , Linux Kernel Mailing List , Ingo Molnar , Thomas Gleixner Subject: Re: [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE Message-ID: <20130913082933.GH31370@twins.programming.kicks-ass.net> References: <20130912150645.GZ31370@twins.programming.kicks-ass.net> <5231E18D.7070306@canonical.com> <5231EF5A.7010901@vmware.com> <52323734.4070908@canonical.com> <5232B44C.9010408@vmware.com> <5232BBE1.5030509@canonical.com> <5232C2BB.9070303@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5232C2BB.9070303@vmware.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1481 Lines: 30 On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote: > >>if (!bo_tryreserve()) { > >> up_read mmap_sem(); // Release the mmap_sem to avoid deadlocks. > >> bo_reserve(); // Wait for the BO to become available (interruptible) > >> bo_unreserve(); // Where is bo_wait_unreserved() when we need it, Maarten :P > >> return VM_FAULT_RETRY; // Go ahead and retry the VMA walk, after regrabbing > >>} > > Anyway, could you describe what is wrong, with the above solution, because > it seems perfectly legal to me. Luckily the rule of law doesn't have anything to do with this stuff -- at least I sincerely hope so. The thing that's wrong with that pattern is that its still not deterministic - although its a lot better than the pure trylock. Because you have to release and re-acquire with the trylock another user might have gotten in again. Its utterly prone to starvation. The acquire+release does remove the dead/life-lock scenario from the FIFO case, since blocking on the acquire will allow the other task to run (or even get boosted on -rt). Aside from that there's nothing particularly wrong with it and lockdep should be happy afaict (but I haven't had my morning juice yet). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/