Markus Armbruster <arm...@redhat.com> writes:

> Paolo Bonzini <pbonz...@redhat.com> writes:
>
>> On 27/11/2015 16:16, Markus Armbruster wrote:
>>>>> >> Since you also fix RESET_FAILED_CONTACT_COUNTER_RP_SIZE, I assume you
>>>>> >> checked them all.
>>>>> >> 
>>>>> >> Reviewed-by: Markus Armbruster <arm...@redhat.com>

Retracted.

>>>> > No, I just copied the upstream bluez patch.
>>> At least CREATE_CONN_CANCEL_CP_SIZE is also wrong.
>>> 
>>> Any particular reason not to mass-convert to sizeof and call it a day?
>>
>> No particular reason, but it is bluetooth after all. :)
>
> Okay, no need to say more.
>
> A bit of Emacs wizardry produced a test program, which coughed up three
> more:
>
> type                            sizeof()  _SIZE
> create_conn_cancel_cp                  7      6

Unused in QEMU.

The closest match I can find in the kernel's current
include/net/bluetooth/hci.h is

    #define HCI_OP_CREATE_CONN_CANCEL       0x0408
    struct hci_cp_create_conn_cancel {
            bdaddr_t bdaddr;
    } __packed;

Size 6, QEMU has an additional first member that brings it to size 7.
Pffft, I'm not going to touch this crap.

> reset_failed_contact_counter_rp        3      4

Unused in QEMU.  Can't match to the kernel's header.  You changed this
one.  I wouldn't touch it.

> read_link_quality_cp                   2      4

Unused in QEMU.  Can't match to the kernel's header.  I'm not going to
touch it.

> inquiry_info                          15     14

Used in bt_hci_inquiry_result_standard().  I figure bt_hci_event() will
leave the last byte uninitialized.

Kernel has

    struct inquiry_info {
            bdaddr_t bdaddr;
            __u8     pscan_rep_mode;
            __u8     pscan_period_mode;
            __u8     pscan_mode;
            __u8     dev_class[3];
            __le16   clock_offset;
    } __packed;

Size 14, QEMU has an additional first member that brings it to size 15.
I'm not going to touch it.

> evt_encrypt_change                     4      5

Used in bt_hci_event_encrypt_change().  I figure it makes bt_hci_event()
overrun the destination by one byte.

Kernel has

    struct hci_ev_encrypt_change {
            __u8     status;
            __le16   handle;
            __u8     encrypt;
    } __packed;

You changed this one.  Plausible, but I don't want to have my R-by on it
all the same.

> I'll send a patch.

No, I won't.  The only patch I could be persuaded to send would drop the
whole thing with prejudice.

Reply via email to