Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 10 Aug 2020 12:05:02 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     "Ahmed S. Darwish" <a.darwish@linutronix.de>
Cc:     bigeasy@linutronix.de, linux-kernel@vger.kernel.org,
        linux@roeck-us.net, mingo@redhat.com, paulmck@kernel.org,
        peterz@infradead.org, rostedt@goodmis.org, tglx@linutronix.de,
        will@kernel.org
Subject: Re: [PATCH] Revert "seqlock: lockdep assert non-preemptibility on
 seqcount_t write"
Message-ID: <20200810100502.GA2406768@kroah.com>
References: <20200810085954.GA1591892@kroah.com>
 <20200810095428.2602276-1-a.darwish@linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200810095428.2602276-1-a.darwish@linutronix.de>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Aug 10, 2020 at 11:54:28AM +0200, Ahmed S. Darwish wrote:
> This reverts commit 859247d39fb008ea812e8f0c398a58a20c12899e.
> 
> Current implementation of lockdep_assert_preemption_disabled() uses
> per-CPU variables, which was done to untangle the existing
> seqlock.h<=>sched.h 'current->' task_struct circular dependency.
> 
> Using per-CPU variables did not fully untangle the dependency for
> various non-x86 architectures though, resulting in multiple broken
> builds. For the affected architectures, raw_smp_processor_id() led
> back to 'current->', thus having the original seqlock.h<=>sched.h
> dependency in full-effect.
> 
> For now, revert adding lockdep_assert_preemption_disabled() to
> seqlock.h.
> 
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Link: https://lkml.kernel.org/r/20200808232122.GA176509@roeck-us.net
> Link: https://lkml.kernel.org/r/20200810085954.GA1591892@kroah.com
> References: Commit a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context} to per-cpu variables")
> Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Even after this, there are still some build errors on arm32, but I don't
think they are due to this change:

	ERROR: modpost: "__aeabi_uldivmod" [drivers/net/ethernet/sfc/sfc.ko] undefined!
	ERROR: modpost: "__bad_udelay" [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined!

thanks,

greg k-h