mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Jörg Otte" <jrg.otte@gmail.com>,
	"Gustavo F. Padovan" <gustavo@padovan.org>,
	"Johan Hedberg" <johan.hedberg@gmail.com>,
	"bluez mailin list (linux-bluetooth@vger.kernel.org)"
	<linux-bluetooth@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [V4.1] Regression: Bluetooth mouse not working.
Date: Fri, 17 Apr 2015 13:35:11 -0700	[thread overview]
Message-ID: <024FA95B-C70F-42ED-BDBF-69D09AA58203@holtmann.org> (raw)
In-Reply-To: <CA+55aFx+NrXEtd4bveFbZqw0r9UHxkrQ7rzdZBbfBiGdvEX3zw@mail.gmail.com>

Hi Linus,

>> okay. I only looked at BlueZ 5.x and that might have been my mistake. Let me check this and fix this properly.
> 
> Why not just revert that commit. It looks like garbage. It has odd code like
> 
> +       u32 valid_flags = 0;
> +       ci->flags = session->flags & valid_flags;
> 
> which is basically saying "no flags are valid, and we are silently
> just clearing them all when copying".
> 
> The reason I think it's garbage is
> 
> (a) the commit clearly breaks something, so the whole "let's check
> flags that we've never checked before" is already fundamentally
> suspicious
> 
> (b) code like the above is just crap to begin with, because it makes
> things superficially "look" sensible when looking at individual lines
> of code (for example, when grepping things), and then when you look at
> the actual bigger picture, it turns out that the code doesn't actually
> care about the flags it is "copying", it just clears them all.
> 
> The other code sequences do things like
> 
> +       u32 valid_flags = 0;
> +       if (req->flags & ~valid_flags)
> +               return -EINVAL;
> 
> Which again is just a very unreadable way of saying "if any flags are
> set, return an error". This kind of thing is presumably what breaks
> things, because clearly people *have* set flags that you thought are
> invalid.
> 
> Now *IF* the interfaces had had these kinds of flag validation checks
> from day one, that would be one thing. But adding these kinds of
> things after the fact, when somebody then reports that they break
> things, then that's just a big big flag that you shouldn't try to do
> this at all. It's water under the bridge. That ship has sailed. It's
> too late. Give up on it.
> 
> So I don't think this code is "fixable". It really smells like a
> fundamental mistake to begin with. Just revert it, chalk it up as "ok,
> that was a stupid idea", and move on.

accepting all flags regardless was an oversight on my part in the first place. What this patch tried to do is to limit it to what userspace is currently actually using. My mistake was to look only at BlueZ 5.x userspace and not at BlueZ 4.x userspace. The fix to not break existing userspace is essentially this:

diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index a05b9dbf14c9..9070dfd6b4ad 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -1313,7 +1313,8 @@ int hidp_connection_add(struct hidp_connadd_req *req,
                        struct socket *ctrl_sock,
                        struct socket *intr_sock)
 {
-       u32 valid_flags = 0;
+       u32 valid_flags = BIT(HIDP_VIRTUAL_CABLE_UNPLUG) |
+                         BIT(HIDP_BOOT_PROTOCOL_MODE);

I ask Joerg to test this patch, but looking at old userspace is that is what is happening there.

Regards

Marcel


  reply	other threads:[~2015-04-17 20:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-17  9:36 Jörg Otte
2015-04-17 11:55 ` Luiz Augusto von Dentz
2015-04-17 13:44 ` Linus Torvalds
2015-04-17 14:51   ` Jörg Otte
2015-04-17 16:43     ` Jörg Otte
2015-04-17 16:51       ` Marcel Holtmann
2015-04-17 16:55         ` Jörg Otte
2015-04-17 16:59           ` Jörg Otte
2015-04-17 17:02           ` Marcel Holtmann
2015-04-17 17:19             ` Marcel Holtmann
2015-04-17 20:18             ` Linus Torvalds
2015-04-17 20:35               ` Marcel Holtmann [this message]
2015-04-17 21:03                 ` Linus Torvalds
2015-04-17 21:26                   ` Marcel Holtmann
2015-04-18 10:18                 ` Jörg Otte

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=024FA95B-C70F-42ED-BDBF-69D09AA58203@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=gustavo@padovan.org \
    --cc=johan.hedberg@gmail.com \
    --cc=jrg.otte@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®