Adrian Bunk wrote:
> Commit 8de0a15483 added the following
> use-after-free in net/bluetooth/rfcomm/tty.c:
>
> <-- snip -->
>
> ...
> static int rfcomm_dev_add(struct rfcomm_dev_req *req, struct rfcomm_dlc *dlc)
> {
> ...
> if (IS_ERR(dev->tty_dev)) {
> list_del(&dev->list);
> kfree(dev);
> return PTR_ERR(dev->tty_dev);
> }
> ...
>
> <-- snip -->
>
> Spotted by the Coverity checker.
really good catch. I fully overlooked that one. The attached patch
should fix it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, the freezer treats all tasks as freezable, except for the kernel
threads that explicitly set the PF_NOFREEZE flag for themselves. This
approach is problematic, since it requires every kernel thread to either
set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
care for the freezing of tasks at all.
It seems better to only require the kernel threads that want to or need to
be frozen to use some freezer-related code and to remove any
freezer-related code from the other (nonfreezable) kernel threads, which is
done in this patch.
The patch causes all kernel threads to be nonfreezable by default (ie. to
have PF_NOFREEZE set by default) and introduces the set_freezable()
function that should be called by the freezable kernel threads in order to
unset PF_NOFREEZE. It also makes all of the currently freezable kernel
threads call set_freezable(), so it shouldn't cause any (intentional)
change of behaviour to appear. Additionally, it updates documentation to
describe the freezing of tasks more accurately.
[akpm@linux-foundation.org: build fixes]
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Nigel Cunningham <nigel@nigel.suspend2.net>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Gautham R Shenoy <ego@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
To better support and handle eSCO links in the future a bunch of
constants needs to be added and some basic routines need to be
updated. This is the initial step.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch changes the RFCOMM TTY release process so that the TTY is kept
on the list until it is really freed. A new device flag is used to keep
track of released TTYs.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The core problem is that RFCOMM socket layer ioctl can release
rfcomm_dev struct while RFCOMM TTY layer is still actively using
it. Calling tty_vhangup() is needed for a synchronous hangup before
rfcomm_dev is freed.
Addresses the oops at http://bugzilla.kernel.org/show_bug.cgi?id=7509
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Most drivers must handle fragmented HCI data packets and events. This
patch adds a generic function for their reassembly to the Bluetooth
core layer and thus allows to shrink the complexity of the drivers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When cleaning up HIDP sessions, we currently close the ACL connection
before deregistering the input device. Closing the ACL connection
schedules a workqueue to remove the associated objects from sysfs, but
the input device still refers to them -- and if the workqueue happens to
run before the input device removal, the kernel will oops when trying to
look up PHYSDEVPATH for the removed input device.
Fix this by deregistering the input device before closing the
connections.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The L2CAP configuration parameter handling was missing the support
for rejecting unknown options. The capability to reject unknown
options is mandatory since the Bluetooth 1.2 specification. This
patch implements its and also simplifies the parameter parsing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We presently use lock_sock() to acquire a lock on a socket in
hci_sock_dev_event(), but this goes BUG because lock_sock()
can sleep and we're already holding a read-write spinlock at
that point. So, we must use the non-sleeping BH version,
bh_lock_sock().
However, hci_sock_dev_event() is called from user context and
hence using simply bh_lock_sock() will deadlock against a
concurrent softirq that tries to acquire a lock on the same
socket. Hence, disabling BH's before acquiring the socket lock
and enable them afterwards, is the proper solution to fix
socket locking in hci_sock_dev_event().
Signed-off-by: Satyam Sharma <ssatyam@cse.iitk.ac.in>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
* 'upstream-fixes' of master.kernel.org:/pub/scm/linux/kernel/git/jikos/hid:
USB HID: hiddev - fix race between hiddev_send_event() and hiddev_release()
HID: add hooks for getkeycode() and setkeycode() methods
HID: switch to using input_dev->dev.parent
USB HID: Logitech wheel 0x046d/0xc294 needs HID_QUIRK_NOGET quirk
USB HID: usb_buffer_free() cleanup
USB HID: report descriptor of Cypress USB barcode readers needs fixup
Bluetooth HID: HIDP - don't initialize force feedback
USB HID: update CONFIG_USB_HIDINPUT_POWERBOOK description
HID: add input mappings for non-working keys on Logitech S510 remote
In preparation for struct class_device -> struct device input core
conversion, switch to using input_dev->dev.parent when specifying
device position in sysfs tree.
Also, do not access input_dev->private directly, use helpers and
do not use kfree() on input device, use input_free_device() instead.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Disable some more menus in the configuration files that are of no
interest to a s390 machine.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The current implementation of force feedback for HID devices is
USB-transport only and therefore calling hid_ff_init() from hidp code is
not going to work (plus it creates unwanted dependency of hidp on usbhid).
Remove the hid_ff_init() until either the hid-ff is made
transport-independent, or at least support for bluetooth transport is
added.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Remove includes of <linux/smp_lock.h> where it is not used/needed.
Suggested by Al Viro.
Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
sparc64, and arm (all 59 defconfigs).
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The RFCOMM specification says that the device closing the last DLC on
a particular session is responsible for closing the multiplexer by
closing the corresponding L2CAP channel.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If RFCOMM_RELEASE_ONHUP flag is on and rfcomm_release_dev is called
before connection is closed, rfcomm_dev is deleted twice from the
rfcomm_dev_list and refcount is messed up. This patch adds a check
before deleting device that the device actually is listed.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The kernel provides a new convenient way to access the sockets API for
in-kernel users. It is a good idea to actually use it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Bluetooth host adapters are attached to the Bluetooth class and the
low-level connections are children of these class devices. Having class
devices as parent of bus devices breaks a lot of reasonable assumptions
about sysfs. The host adapters should be attached to the Bluetooth bus
to simplify the dependency resolving. For compatibility an additional
symlink from the Bluetooth class will be used.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The L2CAP and HCI setsockopt() implementations have a small information
leak that makes it possible to leak kernel stack memory to userspace.
If the optlen parameter is 0, no data will be copied by copy_from_user(),
but the uninitialized stack buffer will be read and stored later. A call
to getsockopt() can now retrieve the leaked information.
To fix this problem the stack buffer given to copy_from_user() must be
initialized with the current settings.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Set TASK_INTERRUPTIBLE prior to testing the flag to avoid missed wakeups.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Spring cleaning time...
There seems to be a lot of places in the network code that have
extra bogus semicolons after conditionals. Most commonly is a
bogus semicolon after: switch() { }
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
To clearly state the intent of copying from linear sk_buffs, _offset being a
overly long variant but interesting for the sake of saving some bytes.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that it is also an offset from skb->head, reduces its size from 8 to 4 bytes
on 64bit architectures, allowing us to combine the 4 bytes hole left by the
layer headers conversion, reducing struct sk_buff size to 256 bytes, i.e. 4
64byte cachelines, and since the sk_buff slab cache is SLAB_HWCACHE_ALIGN...
:-)
Many calculations that previously required that skb->{transport,network,
mac}_header be first converted to a pointer now can be done directly, being
meaningful as offsets or pointers.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For the places where we need a pointer to the transport header, it is
still legal to touch skb->h.raw directly if just adding to,
subtracting from or setting it to another layer header.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For the common, open coded 'skb->h.raw = skb->data' operation, so that we can
later turn skb->h.raw into a offset, reducing the size of struct sk_buff in
64bit land while possibly keeping it as a pointer on 32bit.
This one touches just the most simple cases:
skb->h.raw = skb->data;
skb->h.raw = {skb_push|[__]skb_pull}()
The next ones will handle the slightly more "complex" cases.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For the places where we need a pointer to the mac header, it is still legal to
touch skb->mac.raw directly if just adding to, subtracting from or setting it
to another layer header.
This one also converts some more cases to skb_reset_mac_header() that my
regex missed as it had no spaces before nor after '=', ugh.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For the common, open coded 'skb->mac.raw = skb->data' operation, so that we can
later turn skb->mac.raw into a offset, reducing the size of struct sk_buff in
64bit land while possibly keeping it as a pointer on 32bit.
This one touches just the most simple case, next will handle the slightly more
"complex" cases.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
One less thing for drivers writers to worry about.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I have a bugreport that scrollwheel of bluetooth version of apple
mightymouse doesn't work. The USB version of mightymouse works, as there
is a quirk for handling scrollwheel in hid/usbhid for it.
Now that bluetooth git tree is hooked to generic hid layer, it could easily
use the quirks which are already present in generic hid parser, hid-input,
etc.
Below is a simple patch against bluetooth git tree, which adds quirk
handling to current bluetooth hidp code, and sets quirk flags for device
0x05ac/0x030c, which is the bluetooth version of the apple mightymouse.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Turning up the warnings on gcc makes it emit warnings
about the placement of 'inline' in function declarations.
Here's everything that was under net/
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Bluetooth] Fix socket locking in hci_sock_dev_event()
hci_sock_dev_event() uses bh_lock_sock() to lock the socket lock.
This is not deadlock-safe against locking of the same socket lock in
l2cap_connect_cfm() from softirq context. In addition to that,
hci_sock_dev_event() doesn't seem to be called from softirq context,
so it is safe to use lock_sock()/release_sock() instead.
The lockdep warning can be triggered on my T42p simply by switching
the Bluetooth off by the keyboard button.
=================================
[ INFO: inconsistent lock state ]
2.6.21-rc2 #4
---------------------------------
inconsistent {in-softirq-W} -> {softirq-on-W} usage.
khubd/156 [HC0[0]:SC0[0]:HE1:SE1] takes:
(slock-AF_BLUETOOTH){-+..}, at: [<e0ca5520>] hci_sock_dev_event+0xa8/0xc5 [bluetooth]
{in-softirq-W} state was registered at:
[<c012d1db>] mark_lock+0x59/0x414
[<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap]
[<c012dfd7>] __lock_acquire+0x3e5/0xb99
[<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap]
[<c012e7f2>] lock_acquire+0x67/0x81
[<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap]
[<c036ee72>] _spin_lock+0x29/0x34
[<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap]
[<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap]
[<e0ca17c3>] hci_send_cmd+0x126/0x14f [bluetooth]
[<e0ca4ce4>] hci_event_packet+0x729/0xebd [bluetooth]
[<e0ca205b>] hci_rx_task+0x2a/0x20f [bluetooth]
[<e0ca209d>] hci_rx_task+0x6c/0x20f [bluetooth]
[<c012d7be>] trace_hardirqs_on+0x10d/0x14e
[<c011ac85>] tasklet_action+0x3d/0x68
[<c011abba>] __do_softirq+0x41/0x92
[<c011ac32>] do_softirq+0x27/0x3d
[<c0105134>] do_IRQ+0x7b/0x8f
[<c0103dec>] common_interrupt+0x24/0x34
[<c0103df6>] common_interrupt+0x2e/0x34
[<c0248e65>] acpi_processor_idle+0x1b3/0x34a
[<c0248e68>] acpi_processor_idle+0x1b6/0x34a
[<c010232b>] cpu_idle+0x39/0x4e
[<c04bab0c>] start_kernel+0x372/0x37a
[<c04ba42b>] unknown_bootoption+0x0/0x202
[<ffffffff>] 0xffffffff
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In the case of bound RFCOMM TTY devices the parent is not available
before its usage. So when opening a RFCOMM TTY device, move it to
the corresponding ACL device as a child. When closing the device,
move it back to the virtual device tree.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The open and close callbacks for the HID device are not optional, but
for the Bluetooth HID report mode support it is enough to add empty
dummy callbacks.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch extends the current Bluetooth HID support to use the new
HID subsystem and adds full report mode support.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The compat ioctl patch copied the parser version field into the
report descriptor size field by mistake.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there. Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.
To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.
Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm. I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).
Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The PSM values below 0x1001 of L2CAP are reserved for well known
services. Restrict the possibility to bind them to privileged
users.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In the case the device registration for a new Bluetooth low-level
connection fails there is no need to unregister it when the temporary
data structure has been removed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When calling send() with a zero length parameter on a RFCOMM socket
it returns a positive value. In this rare case the variable err is
used uninitialized and unfortunately its value is returned.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the DLC device is no longer attached to the TTY device, then return
errors or default values for various callbacks of the TTY layer.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
With malformed packets it might be possible to overwrite internal
CMTP and CAPI data structures. This patch adds additional length
checks to prevent these kinds of remote attacks.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This is the grungy swap all the occurrences in the right places patch that
goes with the updates. At this point we have the same functionality as
before (except that sgttyb() returns speeds not zero) and are ready to
begin turning new stuff on providing nobody reports lots of bugs
If you are a tty driver author converting an out of tree driver the only
impact should be termios->ktermios name changes for the speed/property
setting functions from your upper layers.
If you are implementing your own TCGETS function before then your driver
was broken already and its about to get a whole lot more painful for you so
please fix it 8)
Also fill in c_ispeed/ospeed on init for most devices, although the current
code will do this for you anyway but I'd like eventually to lose that extra
paranoia
[akpm@osdl.org: bluetooth fix]
[mp3@de.ibm.com: sclp fix]
[mp3@de.ibm.com: warning fix for tty3270]
[hugh@veritas.com: fix tty_ioctl powerpc build]
[jdike@addtoit.com: uml: fix ->set_termios declaration]
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Martin Peschke <mp3@de.ibm.com>
Acked-by: Peter Oberparleiter <oberpar@de.ibm.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Conflicts:
drivers/infiniband/core/iwcm.c
drivers/net/chelsio/cxgb2.c
drivers/net/wireless/bcm43xx/bcm43xx_main.c
drivers/net/wireless/prism54/islpci_eth.c
drivers/usb/core/hub.h
drivers/usb/input/hid-core.c
net/core/netpoll.c
Fix up merge failures with Linus's head and fix new compilation failures.
Signed-Off-By: David Howells <dhowells@redhat.com>
The "u16 *" derefs of skb->data need to be wrapped inside of
a get_unaligned().
Thanks to Gustavo Zacarias for the bug report.
Signed-off-by: David S. Miller <davem@davemloft.net>
Any L2CAP connection in disconnecting state shall not response
to any further config requests from the remote side. So in case
such a request is received, ignore it.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When sending a positive config response it shall include the actual
MTU to be used on this channel. This differs from the Bluetooth 1.1
specification where it was enough to acknowledge the config request.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the RFCOMM session is no longer attached to the TTY device, then it
makes no sense to go through with changing the termios settings.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
After an inquiry completed or got canceled the Bluetooth core should
check for any pending connect attempts.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
To receive uvents for the low-level ACL and SCO links, they must be
assigned to a subsystem. It is enough to attach them to the already
established Bluetooth bus.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The latest HID disconnect sequence change introduced a NULL pointer
dereference. For the quirk to handle buggy remote HID implementations,
it is enough to wait for a potential control channel disconnect from
the remote side and it is also enough to wait only 500 msecs.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The bt_proto array needs to be protected by some kind of locking to
prevent a race condition between bt_sock_create and bt_sock_register.
And in addition all calls to sk_alloc need to be made GFP_ATOMIC now.
Signed-off-by: Masatake YAMATO <jet@gyve.org>
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the DLC device is no longer attached to the TTY device, then it
makes no sense to go through with changing the termios settings.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When the connection lookup for the device structure fails, the reference
count for the HCI device needs to be decremented.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Bluetooth HID specification demands that the interrupt channel
shall be disconnected first. This is needed to pass the qualification
tests.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Most Bluetooth chips don't support concurrent connect requests, because
this would involve a multiple baseband page with only one radio. In the
case an upper layer like L2CAP requests a concurrent connect these chips
return the error "Command Disallowed" for the second request. If this
happens it the responsibility of the Bluetooth core to queue the request
and try again after the previous connect attempt has been completed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Bluetooth subsystem currently uses a platform device for devices
with no parent. It is a better idea to use the new virtual devices
tree for these.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Some return values of the driver core register and create functions
are not handled and so might cause unexpected problems.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There exists no attempt do deal with the fact that a structure with
a uint32_t followed by a pointer is going to be different for 32-bit
and 64-bit userspace. Any 32-bit process trying to use it will be
failing with -EFAULT if it's lucky; suffering from having data dumped
at a random address if it's not.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
As part of an SMP cleanliness pass over UML, I consted a bunch of
structures in order to not have to document their locking. One of these
structures was a struct tty_operations. In order to const it in UML
without introducing compiler complaints, the declaration of
tty_set_operations needs to be changed, and then all of its callers need to
be fixed.
This patch declares all struct tty_operations in the tree as const. In all
cases, they are static and used only as input to tty_set_operations. As an
extra check, I ran an i386 allyesconfig build which produced no extra
warnings.
53 drivers are affected. I checked the history of a bunch of them, and in
most cases, there have been only a handful of maintenance changes in the
last six months. serial_core.c was the busiest one that I looked at.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The bt_sysfs_cleanup() is marked with __exit attribute, but it will
be called from an __init function in the error case. So the __exit
attribute must be removed.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the case of device pairing the only safe method is to establish
a low-level ACL link. In this case, the remote side should not use
the disconnect timer to give the other side the chance to enter the
PIN code. If the disconnect timer is used, the connection will be
dropped to soon, because it is impossible to identify an actual user
of this link.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
In case of non-blocking connects it is possible that the last user
of an ACL link quits before the connection has been fully established.
This will lead to a race condition where the internal state of a
connection is closed, but the actual link has been established and is
active. In case of Bluetooth 1.2 and later devices it is possible to
call create connection cancel to abort the connect. For older devices
the disconnect timer will be used to trigger the needed disconnect.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The local version information are needed to identify certain feature
sets of devices. They must be read on device init and stored for later
use. It is also possible to access them through the device model.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In case of non-blocking socket calls we should return EINPROGRESS
and not EAGAIN.
Signed-off-by: Ulisses Furquim <ulissesf@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The command complete event of the exit periodic inquiry command must
clear the HCI_INQUIRY flag and finish the HCI request.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch assigns the next free HCI device identifier to Bluetooth
devices based on the SDIO interface.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch integrates the services of the Bluetooth protocols RFCOMM,
BNEP and HIDP into the driver model. This makes it possible to assign
the virtual TTY, network and input devices to a specific Bluetooth
connection.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch integrates the low-level connections (ACL and SCO) into the
driver model. Every connection is presented as device with the parent
set to its host controller device.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Some Bluetooth RFCOMM implementations try to negotiate a bigger channel
MTU than we can support for a particular session. The maximum MTU for
a RFCOMM session is limited through the L2CAP layer. So if the other
side proposes a channel MTU that is bigger than the underlying L2CAP
MTU, we should reduce it to the L2CAP MTU of the session minus five
bytes for the RFCOMM headers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Bluetooth L2CAP layer has 2 locks that are used in softirq context,
(one spinlock and one rwlock, where the softirq usage is readlock) but
where not all usages of the lock were _bh safe. The patch below corrects
this.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch lets BT_HIDP depend on instead of select INPUT. This fixes
the following warning during an s390 build:
net/bluetooth/hidp/Kconfig:4:warning: 'select' used by config symbol
'BT_HIDP' refer to undefined symbol 'INPUT'
A dependency on INPUT also implies !S390 (and therefore makes the
explicit dependency obsolete) since INPUT is not available on s390.
The practical difference should be nearly zero, since INPUT is always
set to y unless EMBEDDED=y (or S390=y).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch adds the module parameter disable_cfc which can be used to
disable the credit based flow control. The credit based flow control
was introduced with the Bluetooth 1.1 specification and devices can
negotiate its support, but for testing purpose it is helpful to allow
disabling of it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch is a small cleanup of the L2CAP source code. It makes some
coding style changes and moves some functions around to avoid forward
declarations.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch converts the Bluetooth class devices into real devices. The
Bluetooth class is kept and the driver core provides the appropriate
symlinks for backward compatibility.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch adds a generic Bluetooth platform device that can be used
as parent device by virtual and serial devices.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch introduces the automatic sniff mode feature. This allows
the host to switch idle connections into sniff mode to safe power.
Signed-off-by: Ulisses Furquim <ulissesf@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch introduces a quirk that allows the drivers to tell the host
to correct the SCO buffer size values.
Signed-off-by: Olivier Galibert <galibert@pobox.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/devfs-2.6: (22 commits)
[PATCH] devfs: Remove it from the feature_removal.txt file
[PATCH] devfs: Last little devfs cleanups throughout the kernel tree.
[PATCH] devfs: Rename TTY_DRIVER_NO_DEVFS to TTY_DRIVER_DYNAMIC_DEV
[PATCH] devfs: Remove the tty_driver devfs_name field as it's no longer needed
[PATCH] devfs: Remove the line_driver devfs_name field as it's no longer needed
[PATCH] devfs: Remove the videodevice devfs_name field as it's no longer needed
[PATCH] devfs: Remove the gendisk devfs_name field as it's no longer needed
[PATCH] devfs: Remove the miscdevice devfs_name field as it's no longer needed
[PATCH] devfs: Remove the devfs_fs_kernel.h file from the tree
[PATCH] devfs: Remove devfs_remove() function from the kernel tree
[PATCH] devfs: Remove devfs_mk_cdev() function from the kernel tree
[PATCH] devfs: Remove devfs_mk_bdev() function from the kernel tree
[PATCH] devfs: Remove devfs_mk_symlink() function from the kernel tree
[PATCH] devfs: Remove devfs_mk_dir() function from the kernel tree
[PATCH] devfs: Remove devfs_*_tape() functions from the kernel tree
[PATCH] devfs: Remove devfs support from the sound subsystem
[PATCH] devfs: Remove devfs support from the ide subsystem.
[PATCH] devfs: Remove devfs support from the serial subsystem
[PATCH] devfs: Remove devfs from the init code
[PATCH] devfs: Remove devfs from the partition code
...
Remove TTY_DONT_FLIP tty flag. This flag was introduced in 2.1.X kernels
to prevent the N_TTY line discipline functions read_chan() and
n_tty_receive_buf() from running at the same time. 2.2.15 introduced
tty->read_lock to protect access to the N_TTY read buffer, which is the
only state requiring protection between these two functions.
The current TTY_DONT_FLIP implementation is broken for SMP, and is not
universally honored by drivers that send data directly to the line
discipline receive_buf function.
Because TTY_DONT_FLIP is not necessary, is broken in implementation, and is
not universally honored, it is removed.
Signed-off-by: Paul Fulghum <paulkf@microgate.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I've always found this flag confusing. Now that devfs is no longer around, it
has been renamed, and the documentation for when this flag should be used has
been updated.
Also fixes all drivers that use this flag.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
this fixes coverity bug id #1068.
hci_send_sco() frees skb if (skb->len > hdev->sco_mtu).
Since it returns a negative error value only in this case, we
can directly return here.
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
The kernel's implementation of notifier chains is unsafe. There is no
protection against entries being added to or removed from a chain while the
chain is in use. The issues were discussed in this thread:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113018709002036&w=2
We noticed that notifier chains in the kernel fall into two basic usage
classes:
"Blocking" chains are always called from a process context
and the callout routines are allowed to sleep;
"Atomic" chains can be called from an atomic context and
the callout routines are not allowed to sleep.
We decided to codify this distinction and make it part of the API. Therefore
this set of patches introduces three new, parallel APIs: one for blocking
notifiers, one for atomic notifiers, and one for "raw" notifiers (which is
really just the old API under a new name). New kinds of data structures are
used for the heads of the chains, and new routines are defined for
registration, unregistration, and calling a chain. The three APIs are
explained in include/linux/notifier.h and their implementation is in
kernel/sys.c.
With atomic and blocking chains, the implementation guarantees that the chain
links will not be corrupted and that chain callers will not get messed up by
entries being added or removed. For raw chains the implementation provides no
guarantees at all; users of this API must provide their own protections. (The
idea was that situations may come up where the assumptions of the atomic and
blocking APIs are not appropriate, so it should be possible for users to
handle these things in their own way.)
There are some limitations, which should not be too hard to live with. For
atomic/blocking chains, registration and unregistration must always be done in
a process context since the chain is protected by a mutex/rwsem. Also, a
callout routine for a non-raw chain must not try to register or unregister
entries on its own chain. (This did happen in a couple of places and the code
had to be changed to avoid it.)
Since atomic chains may be called from within an NMI handler, they cannot use
spinlocks for synchronization. Instead we use RCU. The overhead falls almost
entirely in the unregister routine, which is okay since unregistration is much
less frequent that calling a chain.
Here is the list of chains that we adjusted and their classifications. None
of them use the raw API, so for the moment it is only a placeholder.
ATOMIC CHAINS
-------------
arch/i386/kernel/traps.c: i386die_chain
arch/ia64/kernel/traps.c: ia64die_chain
arch/powerpc/kernel/traps.c: powerpc_die_chain
arch/sparc64/kernel/traps.c: sparc64die_chain
arch/x86_64/kernel/traps.c: die_chain
drivers/char/ipmi/ipmi_si_intf.c: xaction_notifier_list
kernel/panic.c: panic_notifier_list
kernel/profile.c: task_free_notifier
net/bluetooth/hci_core.c: hci_notifier
net/ipv4/netfilter/ip_conntrack_core.c: ip_conntrack_chain
net/ipv4/netfilter/ip_conntrack_core.c: ip_conntrack_expect_chain
net/ipv6/addrconf.c: inet6addr_chain
net/netfilter/nf_conntrack_core.c: nf_conntrack_chain
net/netfilter/nf_conntrack_core.c: nf_conntrack_expect_chain
net/netlink/af_netlink.c: netlink_chain
BLOCKING CHAINS
---------------
arch/powerpc/platforms/pseries/reconfig.c: pSeries_reconfig_chain
arch/s390/kernel/process.c: idle_chain
arch/x86_64/kernel/process.c idle_notifier
drivers/base/memory.c: memory_chain
drivers/cpufreq/cpufreq.c cpufreq_policy_notifier_list
drivers/cpufreq/cpufreq.c cpufreq_transition_notifier_list
drivers/macintosh/adb.c: adb_client_list
drivers/macintosh/via-pmu.c sleep_notifier_list
drivers/macintosh/via-pmu68k.c sleep_notifier_list
drivers/macintosh/windfarm_core.c wf_client_list
drivers/usb/core/notify.c usb_notifier_list
drivers/video/fbmem.c fb_notifier_list
kernel/cpu.c cpu_chain
kernel/module.c module_notify_list
kernel/profile.c munmap_notifier
kernel/profile.c task_exit_notifier
kernel/sys.c reboot_notifier_list
net/core/dev.c netdev_chain
net/decnet/dn_dev.c: dnaddr_chain
net/ipv4/devinet.c: inetaddr_chain
It's possible that some of these classifications are wrong. If they are,
please let us know or submit a patch to fix them. Note that any chain that
gets called very frequently should be atomic, because the rwsem read-locking
used for blocking chains is very likely to incur cache misses on SMP systems.
(However, if the chain's callout routines may sleep then the chain cannot be
atomic.)
The patch set was written by Alan Stern and Chandra Seetharaman, incorporating
material written by Keith Owens and suggestions from Paul McKenney and Andrew
Morton.
[jes@sgi.com: restructure the notifier chain initialization macros]
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com>
Signed-off-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
