Sd_bus_call - ELOOP Issue

Sd_bus_call - ELOOP Issue

[Kumar Thangavel]

[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]

Hi All,

        We are handing the ipmi commands (Bridge IC request) in the ipmi
module.

        Please find below the gerrit links for the Design and Sample code
implementation of BIC request handling in the ipmi.

        Design :
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-host-ipmid/+/32213
        Sample code implementation :
https://gerrit.openbmc-project.xyz/c/openbmc/fb-ipmi-oem/+/32215

        So, This is regarding the ipmi implementation issue as per the new
design of handling BIC request.

      1. We are handling the command "0x38 0 1 6 0x15 0xa0 0 0 6 1 0"
Netfn = 0x38, cmd =1 is from Bridge IC in the ipmi module. In the ipmid, we
are making new callback(ipmiOemBicHandler) to handle this BIC request.

       2. The Netfn= 0x38 and cmd=1 is verified, we are getting the
commands from the BIC, the same is received at ipmb and ipmid also. The
register call back is also  called. When we fill up the response from the
ipmiOemBicHandler works fine. The response is received at the BIC as well.

       3. But as per the new design, we need to call ipmid command handler
recursively. When we get the Netfn= 0x38 and cmd=1 command in
ipmiOemBicHandler, the handler needs to open the packet and there will be
an another command (for ex Netfn=6 and cmd=1 get_dev_id). ipmiOemBicHandler
needs to send this command

       4. In  ipmiOemBicHandler callback function we are using synchronous
method to create connection, using this connection we are calling "execute"
ipmid dbus method from the ipmid deamon.

       5.  While calling "execute" method, internally it calls sd_bus_call
function. Sd_bus_call returns ELOOP exception due to sender and receiver
         process are same.

       6. As per our understanding, current  sd_bus_call not supported for
connection with the same bus/clients. (sender  and receiver are same
           application name ). Please confirm.

            Log :
            yosemitev2 ipmid[370]: sd_bus_call function called..
            yosemitev2 ipmid[370]: sd_bus_call function ELOOP .
            yosemitev2 ipmid[370]:  unique name = :1.71
            yosemitev2 ipmid[370]:  incoming sender = :1.71
            yosemitev2 ipmid[370]: executeCallback called. catch block
            yosemitev2 ipmid[370]: EXCEPTION=sd_bus_call:
System.Error.ELOOP: Too many levels of symbolic links

       So,  Could you please confirm sd_bus_call does not support the same
bus/clients with in the same process.

       Also, Please let us know if any alternate method to  call the
execute dbus method with the same bus/connection.

Thanks,
Kumar.

[-- Attachment #2: Type: text/html, Size: 3920 bytes --]

Re: Sd_bus_call - ELOOP Issue

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

On Fri, May 29, 2020 at 09:29:48PM +0530, Kumar Thangavel wrote:

>        6. As per our understanding, current  sd_bus_call not supported for
> connection with the same bus/clients. (sender  and receiver are same
>            application name ). Please confirm.
> 
>             Log :
>             yosemitev2 ipmid[370]: sd_bus_call function called..
>             yosemitev2 ipmid[370]: sd_bus_call function ELOOP .
>             yosemitev2 ipmid[370]:  unique name = :1.71
>             yosemitev2 ipmid[370]:  incoming sender = :1.71
>             yosemitev2 ipmid[370]: executeCallback called. catch block
>             yosemitev2 ipmid[370]: EXCEPTION=sd_bus_call:
> System.Error.ELOOP: Too many levels of symbolic links

Yes, it appears that systemd has some code to specifically return ELOOP
in this case:

https://github.com/systemd/systemd/blob/master/src/libsystemd/sd-bus/sd-bus.c#L2236

> 
>        So,  Could you please confirm sd_bus_call does not support the same
> bus/clients with in the same process.
> 
>        Also, Please let us know if any alternate method to  call the
> execute dbus method with the same bus/connection.

My suggestion would be to see if one of the functions in ipmid-new.cpp,
such as executeIpmiCommand, can be exposed to providers for these kind
of recursive callbacks.

Maintainers of phosphor-host-ipmid have opinions here?
-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Sd_bus_call - ELOOP Issue

[Vernon Mauery]

On 29-May-2020 01:07 PM, Patrick Williams wrote:
>On Fri, May 29, 2020 at 09:29:48PM +0530, Kumar Thangavel wrote:
>
>>        6. As per our understanding, current  sd_bus_call not supported for
>> connection with the same bus/clients. (sender  and receiver are same
>>            application name ). Please confirm.
>>
>>             Log :
>>             yosemitev2 ipmid[370]: sd_bus_call function called..
>>             yosemitev2 ipmid[370]: sd_bus_call function ELOOP .
>>             yosemitev2 ipmid[370]:  unique name = :1.71
>>             yosemitev2 ipmid[370]:  incoming sender = :1.71
>>             yosemitev2 ipmid[370]: executeCallback called. catch block
>>             yosemitev2 ipmid[370]: EXCEPTION=sd_bus_call:
>> System.Error.ELOOP: Too many levels of symbolic links
>
>Yes, it appears that systemd has some code to specifically return ELOOP
>in this case:
>
>https://github.com/systemd/systemd/blob/master/src/libsystemd/sd-bus/sd-bus.c#L2236
>
>>
>>        So,  Could you please confirm sd_bus_call does not support the same
>> bus/clients with in the same process.
>>
>>        Also, Please let us know if any alternate method to  call the
>> execute dbus method with the same bus/connection.
>
>My suggestion would be to see if one of the functions in ipmid-new.cpp,
>such as executeIpmiCommand, can be exposed to providers for these kind
>of recursive callbacks.
>
>Maintainers of phosphor-host-ipmid have opinions here?

ipmid hosts a very small set of D-Bus objects/interfaces. I don't know 
of any standard commands that would call back to itself though. There is 
some context I seem to be missing here.

--Vernon

Re: Sd_bus_call - ELOOP Issue

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On Fri, May 29, 2020 at 11:21:07AM -0700, Vernon Mauery wrote:
> On 29-May-2020 01:07 PM, Patrick Williams wrote:
> > On Fri, May 29, 2020 at 09:29:48PM +0530, Kumar Thangavel wrote:
> > >        Also, Please let us know if any alternate method to  call the
> > > execute dbus method with the same bus/connection.
> > 
> > My suggestion would be to see if one of the functions in ipmid-new.cpp,
> > such as executeIpmiCommand, can be exposed to providers for these kind
> > of recursive callbacks.
> > 
> > Maintainers of phosphor-host-ipmid have opinions here?
> 
> ipmid hosts a very small set of D-Bus objects/interfaces. I don't know of
> any standard commands that would call back to itself though. There is some
> context I seem to be missing here.

Hi Vernon,

There were a few earlier posts about what Kumar is trying to accomplish.
We have a server with 1 chassis and 4 hosts.  Each host card has on it a
micro-controller which talks IPMB to the BMC.  My understanding is that
Kumar is trying to reuse most of the providers by taking the IPMB
message, stripping off a header, and then reusing the existing IPMI
provider for handling the bulk of the message.

1. https://lists.ozlabs.org/pipermail/openbmc/2020-May/021631.html
2. https://lists.ozlabs.org/pipermail/openbmc/2020-May/021880.html

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Sd_bus_call - ELOOP Issue

[郁雷]

On Sat, May 30, 2020 at 12:00 AM Kumar Thangavel
<kumarthangavel.hcl@gmail.com> wrote:
>
> Hi All,
>
>         We are handing the ipmi commands (Bridge IC request) in the ipmi module.
>
>         Please find below the gerrit links for the Design and Sample code implementation of BIC request handling in the ipmi.
>
>         Design : https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-host-ipmid/+/32213
>         Sample code implementation : https://gerrit.openbmc-project.xyz/c/openbmc/fb-ipmi-oem/+/32215
>
>         So, This is regarding the ipmi implementation issue as per the new design of handling BIC request.
>
>       1. We are handling the command "0x38 0 1 6 0x15 0xa0 0 0 6 1 0"  Netfn = 0x38, cmd =1 is from Bridge IC in the ipmi module. In the ipmid, we are making new callback(ipmiOemBicHandler) to handle this BIC request.
>
>        2. The Netfn= 0x38 and cmd=1 is verified, we are getting the commands from the BIC, the same is received at ipmb and ipmid also. The register call back is also  called. When we fill up the response from the ipmiOemBicHandler works fine. The response is received at the BIC as well.
>
>        3. But as per the new design, we need to call ipmid command handler recursively. When we get the Netfn= 0x38 and cmd=1 command in ipmiOemBicHandler, the handler needs to open the packet and there will be an another command (for ex Netfn=6 and cmd=1 get_dev_id). ipmiOemBicHandler needs to send this command
>
>        4. In  ipmiOemBicHandler callback function we are using synchronous method to create connection, using this connection we are calling "execute" ipmid dbus method from the ipmid deamon.
>
>        5.  While calling "execute" method, internally it calls sd_bus_call function. Sd_bus_call returns ELOOP exception due to sender and receiver
>          process are same.
>
>        6. As per our understanding, current  sd_bus_call not supported for connection with the same bus/clients. (sender  and receiver are same
>            application name ). Please confirm.
>
>             Log :
>             yosemitev2 ipmid[370]: sd_bus_call function called..
>             yosemitev2 ipmid[370]: sd_bus_call function ELOOP .
>             yosemitev2 ipmid[370]:  unique name = :1.71
>             yosemitev2 ipmid[370]:  incoming sender = :1.71
>             yosemitev2 ipmid[370]: executeCallback called. catch block
>             yosemitev2 ipmid[370]: EXCEPTION=sd_bus_call: System.Error.ELOOP: Too many levels of symbolic links
>
>        So,  Could you please confirm sd_bus_call does not support the same bus/clients with in the same process.

As far as I know, you could NOT make a sd bus call to the same service
when you are in the service's sd bus call.
If you really want to call the "self" service, probably you have to
"schedule" the call into the event loop.