From: Szymon Janc <szymon.janc@tieto.com>
To: Anderson Lizardo <anderson.lizardo@openbossa.org>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH BlueZ 1/7] android: Use 16-bit UUID for SDP search
Date: Wed, 12 Feb 2014 13:17:27 +0100 [thread overview]
Message-ID: <9537432.Rvi7jDRuau@leonov> (raw)
In-Reply-To: <CAJdJm_P3caDzXXttQUvkoeo3pSaWaiuJ4G0B1gbwfw0uwfDD3A@mail.gmail.com>
Hi Anderson,
On Wednesday 12 of February 2014 07:28:24 Anderson Lizardo wrote:
> Hi Szymon,
>
> On Wed, Feb 12, 2014 at 6:59 AM, Szymon Janc <szymon.janc@tieto.com> wrote:
> >> Applied all except 6/7, I think we should probably return an error if
> >> there is an attempt to register a service out of range, then the
> >> caller can assert so we can have a proper test for it that expect an
> >> error in such case.
> >
> > Well, currently IPC depends on hal-msg.h which defines max allowed service
> > ID and using something bigger is a code bug. We could have make IPC
> > independent of hal-msg.h and just verify registered ID in runtime but
> > that would add extra code for each caller with no profit as IDs are fixed
> > anyway.
>
> Personally, I don't have strong opinions on using assert() versus
> raise(SIGTERM) (which is how runtime error conditions seem to be
> handled). Initially I went with raise(SIGTERM), but then I noticed the
> IDs are statically defined, and there is no way to give a invalid ID
> to ipc_register(), unless due to programming error (for which
> assert() is ideal, due to low overhead and no introduction of dead
> code).
>
> That said, this patch is not critical, but only a check so future
> users of ipc_register() don't reintroduce a similar crash fixed by the
> other commit.
>
> > That test fix is invalid as we actually want to test if IPC handles
> > out-of-
> > bound service ID correctly (when receiving register command).
> > And I'm not sure why this actually was causing any problems since that
> > test is not registering handlers for out-of-bound service ID, just sends
> > ipc message with such ID.
>
> I forgot to clarify this on the commit message: the "out of bound"
> service ID is still passed on the IPC message. What I fixed is the
> service ID field used solely for registering the handlers (i.e. passed
> to ipc_register()). If you check the changed struct, there is another
> field for the IPC headers where there is still the expected (out of
> bound) ID.
>
> In the current format, ipc_register() must not receive an "out of
> bound" ID otherwise memory corruptions occur, which introduces subtle
> bugs (in my case the crash happened in very specific compilation
> parameters and valgrind didn't help because the corrupted structures
> were static).
Yes, I was looking at service ID in wrong line. This seems ok now.
--
BR
Szymon Janc
next prev parent reply other threads:[~2014-02-12 12:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-11 18:32 [PATCH BlueZ 1/7] android: Use 16-bit UUID for SDP search Anderson Lizardo
2014-02-11 18:32 ` [PATCH BlueZ 2/7] android/tester: Update SDP PDU after UUID change Anderson Lizardo
2014-02-11 18:32 ` [PATCH BlueZ 3/7] android/hidhost: Trivial coding style fix Anderson Lizardo
2014-02-11 18:32 ` [PATCH BlueZ 4/7] android/client: Fix set_info command Anderson Lizardo
2014-02-11 18:32 ` [PATCH BlueZ 5/7] android/test-ipc: Fix crash due to invalid ipc_register() parameter Anderson Lizardo
2014-02-11 18:32 ` [PATCH BlueZ 6/7] android: Add assertion for ID parameter in ipc_register/ipc_unregister Anderson Lizardo
2014-02-11 18:32 ` [PATCH BlueZ 7/7] android: Add test-ipc to "make check" Anderson Lizardo
2014-02-12 9:58 ` [PATCH BlueZ 1/7] android: Use 16-bit UUID for SDP search Luiz Augusto von Dentz
2014-02-12 10:59 ` Szymon Janc
2014-02-12 11:28 ` Anderson Lizardo
2014-02-12 12:17 ` Szymon Janc [this message]
2014-02-12 11:29 ` Luiz Augusto von Dentz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9537432.Rvi7jDRuau@leonov \
--to=szymon.janc@tieto.com \
--cc=anderson.lizardo@openbossa.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.