Hi, On Wednesday, 12 May 2021 20:13:19 CEST Luiz Augusto von Dentz wrote: > Hi Kai, > > On Wed, May 12, 2021 at 11:06 AM Kai Krakow <kai@xxxxxxxxxxx> wrote: > > Hi Szymon! > > > > Am Mi., 12. Mai 2021 um 15:34 Uhr schrieb Szymon Janc <szymon.janc@xxxxxxxxxxx>: > > > Even with rate limited reporting this is very spammy and since > > > it is remote device that is providing bogus data there is no > > > need to report this as error. > > > > [...] > > > > > [72464.546319] Bluetooth: hci0: advertising data len corrected > > > [72464.857318] Bluetooth: hci0: advertising data len corrected > > > [72465.163332] Bluetooth: hci0: advertising data len corrected > > > [72465.278331] Bluetooth: hci0: advertising data len corrected > > > [72465.432323] Bluetooth: hci0: advertising data len corrected > > > [72465.891334] Bluetooth: hci0: advertising data len corrected > > > [72466.045334] Bluetooth: hci0: advertising data len corrected > > > [72466.197321] Bluetooth: hci0: advertising data len corrected > > > [72466.340318] Bluetooth: hci0: advertising data len corrected > > > [72466.498335] Bluetooth: hci0: advertising data len corrected > > > [72469.803299] bt_err_ratelimited: 10 callbacks suppressed > > > > > > Signed-off-by: Szymon Janc <szymon.janc@xxxxxxxxxxx> > > > Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=203753 > > > Cc: stable@xxxxxxxxxxxxxxx > > > --- > > > > > > net/bluetooth/hci_event.c | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c > > > index 5e99968939ce..abdc44dc0b2f 100644 > > > --- a/net/bluetooth/hci_event.c > > > +++ b/net/bluetooth/hci_event.c > > > @@ -5476,8 +5476,6 @@ static void process_adv_report(struct hci_dev > > > *hdev, u8 type, bdaddr_t *bdaddr,> > > > > /* Adjust for actual length */ > > > if (len != real_len) { > > > > > > - bt_dev_err_ratelimited(hdev, "advertising data len > > > corrected %u -> %u", - len, > > > real_len); > > > > > > len = real_len; > > > > > > } > > > > This renders the "if" quite useless since it now always ensures len = > > real_len and nothing else. At this point, the "if" can be removed, and > > len can be set unconditionally. Depending on the further context of > > the patch, destinction between real_len and len may not be needed at > > all and real_len could be renamed to len, ditching the unused original > > which is potentially bogus data anyways according to your commit > > description. > > That was introduced to truncate the len, the patch just removes the > logging but it does keep this logic, if you want to understand the > reason for it just use git blame and look at the history. Actually, with no log there is no need for this "if" and real_len could be indeed avoided. But I'd change this is subsequent patch which would not be tagged as stable candidate. Thoughts? -- pozdrawiam Szymon Janc
