Hi, Luiz -----Original Message----- From: Luiz Augusto von Dentz [mailto:luiz.dentz@xxxxxxxxx] Sent: 2011年6月21日 17:48 To: Li, Nami Cc: linux-bluetooth@xxxxxxxxxxxxxxx Subject: Re: [PATCH obexd] Fix crash introduced by f5279bfcedd669bc5d4e88cc1c59807c92226dfb Hi Nami, 2011/6/21 Li, Nami <nami@xxxxxxxxxxxxxxxx>: > Hi, > > -----Original Message----- > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx > [mailto:linux-bluetooth-owner@xxxxxxxxxxxxxxx] On Behalf Of Luiz > Augusto von Dentz > Sent: 2011年6月21日 16:38 > To: linux-bluetooth@xxxxxxxxxxxxxxx > Subject: [PATCH obexd] Fix crash introduced by > f5279bfcedd669bc5d4e88cc1c59807c92226dfb > > From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> > > The callback function actually needs the bluetooth_service structure not obex_service_driver. > --- > plugins/bluetooth.c | 11 +++++++++-- > 1 files changed, 9 insertions(+), 2 deletions(-) > > diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c index > fe508f4..1037b24 100644 > --- a/plugins/bluetooth.c > +++ b/plugins/bluetooth.c > @@ -459,10 +459,11 @@ static int request_service_authorization(struct > bluetooth_service *service, > > static void confirm_event(GIOChannel *io, void *user_data) { > - struct bluetooth_service *service = user_data; > + struct bluetooth_service *service; > GError *err = NULL; > char address[18]; > uint8_t channel; > + struct obex_service_driver *driver = user_data; > > bt_io_get(io, BT_IO_RFCOMM, &err, > BT_IO_OPT_DEST, address, @@ -477,7 +478,13 @@ > static void confirm_event(GIOChannel *io, void *user_data) > info("bluetooth: New connection from: %s, channel %u", address, > channel); > > - if (service->driver->service != OBEX_OPP) { > + service = find_service(driver, 0); > > Will it be better to write as "service = find_service(driver, channel);" ? > Or if you choose not to use channel, I think you could omit channel > variable and omit bt_io_get(BT_IO_OPT_CHANNEL, &channel); >I only leave the channel there for logging, as for the find_service it is really useless to use the channel if we are going to support L2CAP in future, so in theory this should work regardless of the transport. Yeah, it`s better when support L2CAP. If the channel is only use for logging, can we delete it? There are only two functions calling find_service, one in your commit , another in register_record function: service = find_service(driver, 0); Seems the channel parameter is useless. And considering OBEX over L2CAP, should we modify find_service to static struct bluetooth_service *find_service(struct obex_service_driver *driver) just delete uint8_t channel parameter. If ok, you or me can upload a patch for this issue. Nami ?韬{.n?????%??檩??w?{.n???{饼?z????n?■???h?璀?｛?夸z罐?+€?zf＂?????i?????_璁?:+v??撸?
