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]
Date:	Fri, 4 Dec 2015 11:21:51 +0000
From:	Sudeep Holla <sudeep.holla@....com>
To:	Grygorii Strashko <grygorii.strashko@...com>,
	Tony Lindgren <tony@...mide.com>
Cc:	Sudeep Holla <sudeep.holla@....com>,
	Linus Walleij <linus.walleij@...aro.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-omap@...r.kernel.org
Subject: Re: [PATCH 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND
 flag



On 04/12/15 11:18, Grygorii Strashko wrote:
> On 12/04/2015 12:54 PM, Sudeep Holla wrote:
>> Hi Grygorii,
>>
>> On 04/12/15 10:44, Grygorii Strashko wrote:
>>> On 12/03/2015 11:37 PM, Tony Lindgren wrote:
>>
>> [...]
>>
>>>> And these both need to be applied together when we have a fix for the
>>>> above
>>>> as otherwise we'll get the lock recursion Sudeep mentioned in patch 2/2.
>>>>
>>>
>>> Most probably below diff will fix above issue:
>>>
>>> diff --git a/arch/arm/mach-omap2/prm_common.c
>>> b/arch/arm/mach-omap2/prm_common.c
>>> index 3fc2cbe..69cde67 100644
>>> --- a/arch/arm/mach-omap2/prm_common.c
>>> +++ b/arch/arm/mach-omap2/prm_common.c
>>> @@ -338,6 +338,7 @@ int omap_prcm_register_chain_handler(struct
>>> omap_prcm_irq_setup *irq_setup)
>>>                   ct->chip.irq_ack = irq_gc_ack_set_bit;
>>>                   ct->chip.irq_mask = irq_gc_mask_clr_bit;
>>>                   ct->chip.irq_unmask = irq_gc_mask_set_bit;
>>> +               ct->chip.flags = IRQCHIP_SKIP_SET_WAKE;
>>
>> Thanks for testing.
>
> Sry, I've not tested it yet - it's just fast assumption :(
>

OK, no worries.

>> In that case without this hunk, we should get error
>> from pcs_irq_set_wake in the suspend path. No ? May be driver is not
>> checking the error value and entering suspend.
>>
>
> Yep. Noone is checking return result from enable_irq_wake() in suspend path
> (see dev_pm_arm_wake_irq()).
>

True, but one possible reason for the warning Tony posted.

> Actually, return result of  enable_irq_wake()  is checked only in ~30% of
> cases in kernel now :)
>

That's bad, but I admit that even I failed to add check in some of the
patches I posted earlier.

-- 
Regards,
Sudeep
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ