Packet Size Mismatches

Vernon Mauery vernon.mauery at linux.intel.com
Fri Jan 11 11:57:44 AEDT 2019


On 10-Jan-2019 03:46 PM, Patrick Venture wrote:
>On Thu, Jan 10, 2019 at 2:06 PM Vernon Mauery
><vernon.mauery at linux.intel.com> wrote:
>>
>> On 09-Jan-2019 09:10 AM, Patrick Venture wrote:
>> >Per the maximum response size patch
>> >(https://gerrit.openbmc-project.xyz/15743), the goal is to know how
>> >many bytes can be returned by the channel.  This can vary by channel,
>> >per the comments, and other related changes.  However, presently,
>> >we're seeing a memory corruption over kcs which has a limit of 256.
>> >So, we're copying way too much data onto the response.  The code
>> >itself has no idea how many bytes it can send.
>>
>> This is a tricky problem.... Ideally, if an IPMI command wants to return
>> a large number of bytes, it would consult its context and return an
>> error if the response would not fit in the channel. This relies on each
>> command to be written correctly. In a slightly less ideal world, the
>
>Obviously the 64 byte response buffer in impid will be fixed at some
>point shortly, probably in your currently staged patches.

I am not sure that this particular issue is addressed yet, but the 
patches I have lay a framework that allows it to be more easily fixed.

>Is the context something new being passed to handlers?  (I haven't had
>a chance to really dig through your full stack of patches).

The context is something that can be requested as part of the handler 
signature. The handler can have the request object, the context object, 
or the yield context object. The request object contains all the info, 
the context contains some of the info, and the yield context is only for 
async operations. 

handler.hpp contains the details of what sorts of goodies that can be 
requested on top of ipmi data types.
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-host-ipmid/+/11273/17/ipmi/handler.hpp

--Vernon



More information about the openbmc mailing list