I'm working on a tool for (reliably) transferring diffs across versions of a given C code. To evaluate my tool, I have been comparing the output of my tool against the manual backports in the stable branch.
In the process, I have found some oddities in some backported patches which, I believe, are incorrect. In all cases, the root cause seems to be that `patch` was able to apply a backported diff after some fuzzy matching but did so at a wrong location (IMHO). Below is an example. I can report the others if there is indeed a problem.
On the branch stable/linux-4.4.y, the upstream patch
b560a208cda0297fef6ff85bbfd58a8f0a52a543 Bluetooth: MGMT: Fix not checking if BT_HS is enabled
is backported as commit
5abe9f99f5129bee5492072ff76b91ec4fad485b.
If we look at both commits we have:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Upstream b560a208cda0297fef6ff85bbfd58a8f0a52a543 %%%%%%%%%
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index 0b711ad..12d7b36 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c [...] @@ -1817,6 +1818,10 @@ static int set_hs(struct sock *sk, struct hci_dev *hdev, void *data, u16 len) bt_dev_dbg(hdev, "sock %p", sk); + if (!IS_ENABLED(CONFIG_BT_HS)) + return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, + MGMT_STATUS_NOT_SUPPORTED); + status = mgmt_bredr_support(hdev); if (status) return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, status);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Backported 5abe9f99f5129bee5492072ff76b91ec4fad485b %%%%%%%%%
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index ecc3da6..ee761fb 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c [...] @@ -2281,6 +2282,10 @@ static int set_link_security(struct sock *sk, struct hci_dev *hdev, void *data, BT_DBG("request for %s", hdev->name); + if (!IS_ENABLED(CONFIG_BT_HS)) + return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, + MGMT_STATUS_NOT_SUPPORTED); + status = mgmt_bredr_support(hdev); if (status) return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_LINK_SECURITY,
I suspect that this does *not* reflect the intent of the orignal patch (which was addressing an issue in `set_hs`) whereas, here, the backported patch is somewhat arbitrarily modifying `set_link_security` while `set_hs` remains as-is.
Is this indeed an issue? Should I report on the other cases as well?
- Guillaume Bertholon