> From: Dan Williams <dan.j.williams@xxxxxxxxx> > Sent: Thursday, March 21, 2024 6:05 AM > + * > + * Note that unwind order is dictated by declaration order. That > + * contraindicates a pattern like the following: > + * > + * .. code-block:: c > + * > + * int num, ret = 0; > + * struct pci_dev *bridge = ctrl->pcie->port; > + * struct pci_bus *parent = bridge->subordinate; > + * struct pci_dev *dev __free(pci_dev_put) = NULL; > + * > + * pci_lock_rescan_remove(); > + * > + * dev = pci_get_slot(parent, PCI_DEVFN(0, 0)); > + * > + * In this case @dev is declared in x-mas tree style in a preamble > + * declaration block. That is problematic because it destroys the > + * compiler's ability to infer proper unwind order. If other cleanup > + * helpers appeared in such a function that depended on @dev being live > + * to complete their unwind then using the "struct obj_type *obj > + * __free(...) = NULL" style is an anti-pattern that potentially causes > + * a use-after-free bug. Instead, the expectation is this conversion: > + * an example of dependent cleanup helpers might be helpful to better understand this expectation?
