Bug in "Probe" logic in Entity Manager- while parsing Probe statements from EM configs

[harsh23tyagi11]

I recently discovered this little bug in the logic that parses the probe statement in Entity Manager, hence documenting it for visibility and can fix this later either by a creating an exclusive parser or some other parsing mechanism.

Bug Description: The code line here in findProbeType() method call- https://github.com/openbmc/entity-manager/blob/master/src/entity_manager.cpp#L92 is if probe.find(probeType->first) != std::string::npos) which fails if the probe statement has OR in it as it will find the first occurrence of the probeTypes in the string.

For instance: probe = xyz.openbmc_project.UsbDevice({'VENDOR_ID': '2frrr3'}) would fail to be probed and would be considered as a conjunction statement - since it has OR at 36th index (in vendOR_id).

probeType->first values are yielded from:

probeTypes{{{"FALSE", probe_type_codes::FALSE_T},
                {"TRUE", probe_type_codes::TRUE_T},
                {"AND", probe_type_codes::AND},
                {"OR", probe_type_codes::OR},
                {"FOUND", probe_type_codes::FOUND},
                {"MATCH_ONE", probe_type_codes::MATCH_ONE}}};

Now every time this function yields to true, the EM doesn't search the DBus for object paths and consider it as a conjunction statement such as OR, FOUND etc.

Current resolution: Until this is fixed avoid having probeTypes character strings in the probe statements.

Potential fixes:

• Have a better regex to extract probe statements
• Have an exact match for probeTypes within string
• Have an exclusive parser as mentioned by this design: https://gerrit.openbmc.org/c/openbmc/entity-manager/+/36517