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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <52A072BB.6020609@dell.com>
Date:	Thu, 5 Dec 2013 04:40:13 -0800
From:	<Srinivas_G_Gowda@...l.com>
To:	<Srinivas_G_Gowda@...l.com>
CC:	<minyard@....org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] ipmi: setting mod_timer for read_event_msg buffer
 cmd


> 
> No, I did not see final else in ipmi_thread ever getting hit.
> 
> I am looking at  ipmi_thread_busy_wait(),
>  by default the below condition never gets set unitl I explicetly set "kipmid_max_busy_us" to some value.
> if (smi_info->intf_num < num_max_busy_us)
> 
> This means by default "max_busy_us" is always 0. Hence Ill basically end up only doing this
> if (max_busy_us == 0 || smi_result != SI_SM_CALL_WITH_DELAY)
>                 ipmi_si_set_not_busy(busy_until);
> 
> That probably explains why I never hit the else condition in ipmi_thread.
> 
> I see ipmi_start_timer_if_necessary() getting called from ipmi_thread() after setting "kipmid_max_busy_us"
> Ill set "kipmid_max_busy_us=300" and run the stress. I am hoping that we will not see the issue in this case.
> 

I don't see the issue after this change. (I am going to try again just to be sure)
I am trying to figure out how to hit ipmi_start_timer_if_necessary() in default mode...! 


Thanks,
G

> 
> Thanks,
> G
> 
> 
> 
>> Thanks,
>>
>> -corey
>>
>>>
>>>
>>> Thanks,
>>> G
>>>
>>> -----Original Message-----
>>> From: Corey Minyard [mailto:tcminyard@...il.com] On Behalf Of Corey Minyard
>>> Sent: Tuesday, December 03, 2013 2:34 AM
>>> To: Gowda, Srinivas G
>>> Cc: tcminyard@...il.com; linux-kernel@...r.kernel.org; openipmi@...sta.com
>>> Subject: Re: [PATCH 1/1] ipmi: setting mod_timer for read_event_msg buffer cmd On 12/02/2013 08:49 AM, Srinivas_G_Gowda@...l.com wrote: 
>>>> Thanks for the patch Corey. 
>>>> I am afraid that the system does not have interrupts enabled. It uses polling mode. 
>>>>
>>>> When the error is seen, I know for a fact that in function
>>>> ipmi_thread() smi_result is SI_SM_CALL_WITH_DELAY, I have some logs where in busy_wait always reads as 1. Not sure if it was ever set to 0. (ill check this again).
>>>> Ill anyway run the test using the patch that you have shared. 
>>>>
>>>> b/w would it harm if we were to do to something like this ?
>>> Unfortunately, that would start the timer unnecessarily.  You don't want to start timers unnecessarily in the kernel or the power management police will come after you.
>>> The patch I sent did have this call in the non-idle portion of the kernel thread and that should have done the same thing.  Plus, if you are using the kernel thread, it's going to run periodically and should kick things off again if they get stuck.  I'm suspicious now that something else is going on.
>>> -corey 
>>>> Signed-off-by: Srinivas Gowda <srinivas_g_gowda@...l.com>
>>>> ---
>>>>   drivers/char/ipmi/ipmi_si_intf.c | 1 +
>>>>   1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/drivers/char/ipmi/ipmi_si_intf.c
>>>> b/drivers/char/ipmi/ipmi_si_intf.c
>>>> index 15e4a60..e23484f 100644
>>>> --- a/drivers/char/ipmi/ipmi_si_intf.c
>>>> +++ b/drivers/char/ipmi/ipmi_si_intf.c
>>>> @@ -1008,6 +1008,7 @@ static int ipmi_thread(void *data)
>>>>                spin_unlock_irqrestore(&(smi_info->si_lock), flags);
>>>>                busy_wait = ipmi_thread_busy_wait(smi_result, smi_info,
>>>>                                                  &busy_until);
>>>> +             ipmi_start_timer_if_necessary(smi_info);
>>>>                if (smi_result == SI_SM_CALL_WITHOUT_DELAY)
>>>>                        ; /* do nothing */
>>>>                else if (smi_result == SI_SM_CALL_WITH_DELAY && 
>>>> busy_wait)
>>
> 
> 
> 

--
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