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: <5760FE41.9060603@nod.at>
Date:	Wed, 15 Jun 2016 09:05:37 +0200
From:	Richard Weinberger <richard@....at>
To:	paulmck@...ux.vnet.ibm.com,
	kbuild test robot <fengguang.wu@...el.com>
Cc:	kbuild-all@...org, linux-kernel@...r.kernel.org, jdike@...toit.com,
	user-mode-linux-devel@...ts.sourceforge.net
Subject: Re: [rcu:rcu/next 25/36] include/linux/irqflags.h:79:3: error:
 implicit declaration of function 'arch_irqs_disabled_flags'

Paul,

Am 15.06.2016 um 00:54 schrieb Paul E. McKenney:
> On Mon, Jun 06, 2016 at 02:04:03AM +0800, kbuild test robot wrote:
>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
>> head:   13ee0de9cd2444b57ce30c4f1607b49b90aa0c38
>> commit: f251ac814fc5787765009e60d54a2bd4277350c8 [25/36] rcu: Make call_rcu_tasks() tolerate first call with irqs disabled
>> config: um-allmodconfig (attached as .config)
>> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
>> reproduce:
>>         git checkout f251ac814fc5787765009e60d54a2bd4277350c8
>>         # save the attached .config to linux build tree
>>         make ARCH=um 
> 
> My kneejerk reaction would be to make CONFIG_TASKS_RCU depend on
> !UML or something similar.
> 
> Another approach would be create a arch_irqs_disabled_flags() for UML.
> 
> Any preferences?

Patches for arch_irqs_disabled_flags() support are already on LKML:
https://lkml.org/lkml/2016/6/12/162

My plan was to merge them in the v4.8 merge window.
So having CONFIG_TASKS_RCU depend on !UML for now should be fine.
We can remove the dependency in v4.8 again.

Thanks,
//richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ