linux-kernel - Re: [build failure] Re: BKL: remove extraneous #include <smp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=Xoo90jiaQBMxchFkKXt0dgre0tWe-LnVR6aSD@mail.gmail.com>
Date:	Thu, 18 Nov 2010 07:57:08 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [build failure] Re: BKL: remove extraneous #include <smp_lock.h>

On Thu, Nov 18, 2010 at 1:43 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> Latest -git fails to build in some circumstances:
>
>  drivers/net/irda/sir_dev.c: In function ‘sirdev_schedule_request’:
>  drivers/net/irda/sir_dev.c:292:244: error: dereferencing pointer to incomplete type

Yeah. That's the "in_atomic()" check (stupid testing by just splitting
that one thing over three lines instead of one and seeing which one
gcc complains about), and it wants the declaration for "struct
task_struct".

And that file has a very minimal #includes. I'd even be impressed at
how small the list is, if it actually made any sense.  It looks like
_all_ includes in that file are pretty much incidental ;)

At a quick glance I'm not even seeing how it's including hardirq.h,
but clearly it's not enough.

Equally clearly it looks like the _correct_ fix is to move
"lock_depth" into the thread structure together with the preempt
count. Of course, I'm not sure whether that's really worth it, or
whether we should just be lazy and include <sched.h> with everything
that entails into hardirq.h.

How painful would it be to move lock_depth into thread_struct? I guess
we don't have anything that cares about structure offsets in assembly
for that thing.  I should just try.

                             Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/