| Age | Commit message (Collapse) | Author |
|---|
|
Enhance raid5_remove_disk to be able to remove ->replacement
as well as ->rdev.
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
If a replacement device is present and has been recovered far enough,
then use it for reading into the stripe cache.
If we get an error we don't try to repair it, we just fail the device.
A replacement device that gives errors does not sound sensible.
This requires removing the setting of R5_ReadError when we get
a read error during a read that bypasses the cache. It was probably
a bad idea anyway as we don't know that every block in the read
caused an error, and it could cause ReadError to be set for the
replacement device, which is bad.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
We current initialise some fields of a bio when preparing a
stripe_head, and again just before submitting the request.
Remove the duplication by only setting the fields that lower level
devices don't touch in raid5_build_block, and only set the changeable
fields in ops_run_io.
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
Remove some #defines that are no longer used, and replace some
others with an enum.
And remove an unused field.
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
Just enhance data structures to record a second device per slot to be
used as a 'replacement' device, replacing the original.
We also have a second bio in each slot in each stripe_head. This will
only be used when writing to the array - we need to write to both the
original and the replacement at the same time, so will need two bios.
For now, only try using the replacement drive for aligned-reads.
In this case, we prefer the replacement if it has been recovered far
enough, otherwise use the original.
This includes a small enhancement. Previously we would only do
aligned reads if the target device was fully recovered. Now we also
do them if it has recovered far enough.
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
hot-replace is a feature being added to md which will allow a
device to be replaced without removing it from the array first.
With hot-replace a spare can be activated and recovery can start while
the original device is still in place, thus allowing a transition from
an unreliable device to a reliable device without leaving the array
degraded during the transition. It can also be use when the original
device is still reliable but it not wanted for some reason.
This will eventually be supported in RAID4/5/6 and RAID10.
This patch adds a super-block flag to distinguish the replacement
device. If an old kernel sees this flag it will reject the device.
It also adds two per-device flags which are viewable and settable via
sysfs.
"want_replacement" can be set to request that a device be replaced.
"replacement" is set to show that this device is replacing another
device.
The "rd%d" links in /sys/block/mdXx/md only apply to the original
device, not the replacement. We currently don't make links for the
replacement - there doesn't seem to be a need.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
Soon an array will be able to have multiple devices with the
same raid_disk number (an original and a replacement). So removing
a device based on the number won't work. So pass the actual device
handle instead.
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
When setting the slot number on a device in an active array we
currently check that the number is not already in use.
We then call into the personality's hot_add_disk function
which performs the same test and returns the same error.
Thus the common test is not needed.
As we will shortly be changing some personalities to allow duplicates
in some cases (to support hot-replace), the common test will become
inconvenient.
So remove the common test.
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
For each active region corresponding to a bit in the bitmap with have
a 14bit counter (and some flags).
This counts
number of active writes + bit in the on-disk bitmap + delay-needed.
The "delay-needed" is because we always want a delay before clearing a
bit. So the number here is normally number of active writes plus 2.
If there have been no writes for a while, we drop to 1.
If still no writes we clear the bit and drop to 0.
So for consistency, when setting bit from the on-disk bitmap or by
request from user-space it is best to set the counter to '2' to start
with.
In particular we might also set the NEEDED_MASK flag at this time, and
in all other cases NEEDED_MASK is only set when the counter is 2 or
more.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
While using etags to find free_pages(), I stumbled across this debug
definition of free_pages() that is to be used while debugging some raid
code in userspace. The __get_free_pages() allocates the correct size,
but the free_pages() does not match. free_pages(), like
__get_free_pages(), takes an order and not a size.
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
When an array is being reshaped to change the number of devices,
the two halves can be differently degraded. e.g. one could be
missing a device and the other not.
So we need to be more careful about calculating the 'degraded'
attribute.
Instead of just inc/dec at appropriate times, perform a full
re-calculation examining both possible cases. This doesn't happen
often so it not a big cost, and we already have most of the code to
do it.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
We have a variable 'mddev' in this function, but repeatedly get the
same value by dereferencing bitmap->mddev.
There is room for simplification here...
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
The info is already available in /proc/mdstat and /sys/block in
an accessible form so there is no point in putting a road-block in
the ioctl for information gathering.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
commit d0a4bb492772ce5c4bdfba3744a99ed6f6fb238f introduced a
regression which is annoying but fairly harmless.
When writing to an array that is undergoing recovery (a spare
in being integrated into the array), writing to the array will
set bits in the bitmap, but they will not be cleared when the
write completes.
For bits covering areas that have not been recovered yet this is not a
problem as the recovery will clear the bits. However bits set in
already-recovered region will stay set and never be cleared.
This doesn't risk data integrity. The only negatives are:
- next time there is a crash, more resyncing than necessary will
be done.
- the bitmap doesn't look clean, which is confusing.
While an array is recovering we don't want to update the
'events_cleared' setting in the bitmap but we do still want to clear
bits that have very recently been set - providing they were written to
the recovering device.
So split those two needs - which previously both depended on 'success'
and always clear the bit of the write went to all devices.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
Before performing a recovery we try to remove any spares that
might not be working, then add any that might have become relevant.
Currently we abort on the first spare that cannot be added.
This is a false optimisation.
It is conceivable that - depending on rules in the personality - a
subsequent spare might be accepted.
Also the loop does other things like count the available spares and
reset the 'recovery_offset' value.
If we abort early these might not happen properly.
So remove the early abort.
In particular if you have an array what is undergoing recovery and
which has extra spares, then the recovery may not restart after as
reboot as the could of 'spares' might end up as zero.
Reported-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
While reshaping a degraded array (as when reshaping a RAID0 by first
converting it to a degraded RAID4) we currently get confused about
which devices are in_sync. In most cases we get it right, but in the
region that is being reshaped we need to treat non-failed devices as
in-sync when we have the data but haven't actually written it out yet.
Reported-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
commit d70ed2e4fafdbef0800e73942482bb075c21578b
broke hot-add to a linear array.
After that commit, metadata if not written to devices until they
have been fully integrated into the array as determined by
saved_raid_disk. That patch arranged to clear that field after
a recovery completed.
However for linear arrays, there is no recovery - the integration is
instantaneous. So we need to explicitly clear the saved_raid_disk
field.
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
When running the Point Grey "flycap" program for their USB 3.0 camera
(which was running as a USB 2.0 device for some reason), I trigger this
oops whenever I try to open a video stream:
Dec 15 16:48:34 puck kernel: [ 1798.715559] BUG: unable to handle kernel NULL pointer dereference at (null)
Dec 15 16:48:34 puck kernel: [ 1798.719153] IP: [<ffffffff8147841e>] free_async+0x1e/0x70
Dec 15 16:48:34 puck kernel: [ 1798.720991] PGD 6f833067 PUD 6fc56067 PMD 0
Dec 15 16:48:34 puck kernel: [ 1798.722815] Oops: 0002 [#1] SMP
Dec 15 16:48:34 puck kernel: [ 1798.724627] CPU 0
Dec 15 16:48:34 puck kernel: [ 1798.724636] Modules linked in: ecryptfs encrypted_keys sha1_generic trusted binfmt_misc sha256_generic aesni_intel cryptd aes_x86_64 aes_generic parport_pc dm_crypt ppdev joydev snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi snd_hda_intel snd_hda_codec snd_hwdep snd_pcm thinkpad_acpi mac80211 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer btusb uvcvideo snd_seq_device bluetooth videodev psmouse snd v4l2_compat_ioctl32 serio_raw tpm_tis cfg80211 tpm tpm_bios nvram soundcore snd_page_alloc lp parport i915 xhci_hcd ahci libahci drm_kms_helper drm sdhci_pci sdhci e1000e i2c_algo_bit video
Dec 15 16:48:34 puck kernel: [ 1798.734212]
Dec 15 16:48:34 puck kernel: [ 1798.736162] Pid: 2713, comm: FlyCap2 Not tainted 3.2.0-rc5+ #28 LENOVO 4286CTO/4286CTO
Dec 15 16:48:34 puck kernel: [ 1798.738148] RIP: 0010:[<ffffffff8147841e>] [<ffffffff8147841e>] free_async+0x1e/0x70
Dec 15 16:48:34 puck kernel: [ 1798.740134] RSP: 0018:ffff88005715fd78 EFLAGS: 00010296
Dec 15 16:48:34 puck kernel: [ 1798.742118] RAX: 00000000fffffff4 RBX: ffff88006fe8f900 RCX: 0000000000004118
Dec 15 16:48:34 puck kernel: [ 1798.744116] RDX: 0000000001000000 RSI: 0000000000016390 RDI: 0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.746087] RBP: ffff88005715fd88 R08: 0000000000000000 R09: ffffffff8146f22e
Dec 15 16:48:34 puck kernel: [ 1798.748018] R10: ffff88006e520ac0 R11: 0000000000000001 R12: ffff88005715fe28
Dec 15 16:48:34 puck kernel: [ 1798.749916] R13: ffff88005d31df00 R14: ffff88006fe8f900 R15: 00007f688c995cb8
Dec 15 16:48:34 puck kernel: [ 1798.751785] FS: 00007f68a366da40(0000) GS:ffff880100200000(0000) knlGS:0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.753659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 15 16:48:34 puck kernel: [ 1798.755509] CR2: 0000000000000000 CR3: 00000000706bb000 CR4: 00000000000406f0
Dec 15 16:48:34 puck kernel: [ 1798.757334] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.759124] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Dec 15 16:48:34 puck kernel: [ 1798.760871] Process FlyCap2 (pid: 2713, threadinfo ffff88005715e000, task ffff88006c675b80)
Dec 15 16:48:34 puck kernel: [ 1798.762605] Stack:
Dec 15 16:48:34 puck kernel: [ 1798.764297] ffff88005715fe28 0000000000000000 ffff88005715fe08 ffffffff81479058
Dec 15 16:48:34 puck kernel: [ 1798.766020] 0000000000000000 ffffea0000004000 ffff880000004118 0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.767750] ffff880000000001 ffff88006e520ac0 fffffff46fd81180 0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.769472] Call Trace:
Dec 15 16:48:34 puck kernel: [ 1798.771147] [<ffffffff81479058>] proc_do_submiturb+0x778/0xa00
Dec 15 16:48:34 puck kernel: [ 1798.772798] [<ffffffff8147a5fd>] usbdev_do_ioctl+0x24d/0x1200
Dec 15 16:48:34 puck kernel: [ 1798.774410] [<ffffffff8147b5de>] usbdev_ioctl+0xe/0x20
Dec 15 16:48:34 puck kernel: [ 1798.775975] [<ffffffff81189259>] do_vfs_ioctl+0x99/0x600
Dec 15 16:48:34 puck kernel: [ 1798.777534] [<ffffffff81189851>] sys_ioctl+0x91/0xa0
Dec 15 16:48:34 puck kernel: [ 1798.779088] [<ffffffff816247c2>] system_call_fastpath+0x16/0x1b
ec 15 16:48:34 puck kernel: [ 1798.780634] Code: 51 ff ff ff e9 29 ff ff ff 0f 1f 40 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 89 fb 48 8b 7f 18 e8 a6 ea c0 ff 4
8 8b 7b 20 <f0> ff 0f 0f 94 c0 84 c0 74 05 e8 d3 99 c1 ff 48 8b 43 40 48 8b
Dec 15 16:48:34 puck kernel: [ 1798.783970] RIP [<ffffffff8147841e>] free_async+0x1e/0x70
Dec 15 16:48:34 puck kernel: [ 1798.785630] RSP <ffff88005715fd78>
Dec 15 16:48:34 puck kernel: [ 1798.787274] CR2: 0000000000000000
Dec 15 16:48:34 puck kernel: [ 1798.794728] ---[ end trace 52894d3355f88d19 ]---
markup_oops.pl says the oops is in put_cred:
ffffffff81478401: 48 89 e5 mov %rsp,%rbp
ffffffff81478404: 53 push %rbx
ffffffff81478405: 48 83 ec 08 sub $0x8,%rsp
ffffffff81478409: e8 f2 c0 1a 00 callq ffffffff81624500 <mcount>
ffffffff8147840e: 48 89 fb mov %rdi,%rbx | %ebx => ffff88006fe8f900
put_pid(as->pid);
ffffffff81478411: 48 8b 7f 18 mov 0x18(%rdi),%rdi
ffffffff81478415: e8 a6 ea c0 ff callq ffffffff81086ec0 <put_pid>
put_cred(as->cred);
ffffffff8147841a: 48 8b 7b 20 mov 0x20(%rbx),%rdi | %edi => 0 %ebx = ffff88006fe8f900
*/
static inline int atomic_dec_and_test(atomic_t *v)
{
unsigned char c;
asm volatile(LOCK_PREFIX "decl %0; sete %1"
*ffffffff8147841e: f0 ff 0f lock decl (%rdi) | %edi = 0 <--- faulting instruction
ffffffff81478421: 0f 94 c0 sete %al
static inline void put_cred(const struct cred *_cred)
{
struct cred *cred = (struct cred *) _cred;
validate_creds(cred);
if (atomic_dec_and_test(&(cred)->usage))
ffffffff81478424: 84 c0 test %al,%al
ffffffff81478426: 74 05 je ffffffff8147842d <free_async+0x2d>
__put_cred(cred);
ffffffff81478428: e8 d3 99 c1 ff callq ffffffff81091e00 <__put_cred>
kfree(as->urb->transfer_buffer);
ffffffff8147842d: 48 8b 43 40 mov 0x40(%rbx),%rax
ffffffff81478431: 48 8b 78 68 mov 0x68(%rax),%rdi
ffffffff81478435: e8 a6 e1 ce ff callq ffffffff811665e0 <kfree>
kfree(as->urb->setup_packet);
ffffffff8147843a: 48 8b 43 40 mov 0x40(%rbx),%rax
ffffffff8147843e: 48 8b b8 90 00 00 00 mov 0x90(%rax),%rdi
ffffffff81478445: e8 96 e1 ce ff callq ffffffff811665e0 <kfree>
usb_free_urb(as->urb);
ffffffff8147844a: 48 8b 7b 40 mov 0x40(%rbx),%rdi
ffffffff8147844e: e8 0d 6b ff ff callq ffffffff8146ef60 <usb_free_urb>
This bug seems to have been introduced by commit
d178bc3a708f39cbfefc3fab37032d3f2511b4ec "user namespace: usb: make usb
urbs user namespace aware (v2)"
I'm not sure if this is right fix, but it does stop the oops.
Unfortunately, the Point Grey software still refuses to work, but it's a
closed source app, so I can't fix it.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
* 'for-gadget/next' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: (24 commits)
usb: dwc3: gadget: add support for SG lists
usb: dwc3: gadget: don't force 'LST' always
usb: dwc3: gadget: don't return anything on prepare trbs
usb: dwc3: gadget: re-factor dwc3_prepare_trbs()
usb: gadget: introduce support for sg lists
usb: renesas: pipe: convert a long if into a XOR operation
usb: gadget: remove useless depends on Kconfig
usb: gadget: s3c-hsudc: remove the_controller global
usb: gadget: s3c-hsudc: use release_mem_region instead of release_resource
usb: gadget: s3c-hsudc: Add regulator handling
usb: gadget: s3c-hsudc: use udc_start and udc_stop functions
usb: gadget: s3c-hsudc: move device registration to probe
usb: gadget: s3c-hsudc: add missing otg_put_transceiver in probe
usb: gadget: s3c-hsudc: add __devinit to probe function
usb: gadget: s3c-hsudc: move platform_data struct to global header
USB: EHCI: Add Marvell Host Controller driver
USB: OTG: add Marvell usb OTG driver support
usb: gadget: mv_udc: drop ARCH dependency
usb: gadget: mv_udc: fix bug in ep_dequeue
usb: gadget: enlarge maxburst bit width.
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
* 'for-next/dwc3' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb:
usb: dwc3: gadget: move us to Default State after reset
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
* 'for-next/musb' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb:
usb: musb: remove extern qualifier from musb_debug.h header
usb: musb: cleanup kconfig
usb: musb: trivial Kconfig cleanups
musb: omap2430: avoid pm_runtime_disable()
usb: musb: remove a bit of indentation
usb: musb: trivial cleanup
usb: musb: fix pm_runtime mismatch
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
* 'for-next/xceiv' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb:
usb: otg: trivial cleanups
|
|
Convert rtllib from registering the crypt drivers against rtllib_crypt
and instead register the against lib80211. The crypto functions have
R- prepended (R-CCMP, R-TKIP, R-WEP) so they will not clash with the
lib80211 versions.
We cannot use the lib80211 crypt drivers since the rtl8192e has some
hardware support that is not handled by the lib80211 crypt drivers.
Signed-off-by: Sean MacLennan <seanm@seanm.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Convert rtllib to use lib80211_crypt_info.
Signed-off-by: Sean MacLennan <seanm@seanm.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Convert rtllib_crypt_data to lib80211_crypt_data and
rtllib_crypt_ops to lib80211_crypt_ops.
This is almost a 1:1 replacement, only extra_prefix_len and
extra_postfix_len changed.
Signed-off-by: Sean MacLennan <seanm@seanm.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Add lib80211.h header file to rtllib.h and get it compiling.
Signed-off-by: Sean MacLennan <seanm@seanm.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This silently was working for many years and stopped working on
Niagara-T3 machines.
We need to set the MSIQ to VALID before we can set it's state to IDLE.
On Niagara-T3, setting the state to IDLE first was causing HV_EINVAL
errors. The hypervisor documentation says, rather ambiguously, that
the MSIQ must be "initialized" before one can set the state.
I previously understood this to mean merely that a successful setconf()
operation has been performed on the MSIQ, which we have done at this
point. But it seems to also mean that it has been set VALID too.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
add mei_watchdog_register/unregister wrappers for
cleaner encapsulation
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Uncached/writecombine buffers need to be clean before creating uc/wc
userspace mappings, lest dirty cache lines fall down and corrupt the
contents of the buffer.
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This patch removes the int return of function INTnsProcessData, because
nobody uses this return.
Signed-off-by: Marcos Paulo de Souza <marcos.mage@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Removed remnants of old function definitions which have since been
removed in earlier cleanup work.
Signed-off-by: Bart Westgeest <bart@elbrys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
The usbip_xmit function supported sending and receiving data, however
the sending part of the function was never used/executed. Renamed the
function to usbip_recv, and removed the unused code.
Signed-off-by: Bart Westgeest <bart@elbrys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
These callbacks are currently used by the individual buffer implementations to
ensure that the request_update callback is not issued while the buffer is in use.
But the core already provides sufficient measures to prevent this from happening
in the first place. So it is safe to remove them.
There is one functional change due to this patch. Since the buffer is no longer
marked as in use when the chrdev is opened, it is now possible to enable the
buffer while it is opened. This did not work before, because mark_param_change
did fail if the buffer was marked as in use.
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Right now we have a mark_param_change callback in the buffer access
functions struct, which should be called whenever the parameters (length,
bytes per datum) of the buffer change. But it is only called when the user
changes the buffer size, not when the bytes per datum change. Additionally each
buffer implementation already keeps track internally whether its parameters
have changed, making the call to mark_param_change after changing the buffer
length redundant. Since each buffer implementation knows best when one of its
parameters has changed just make tracking of this internal and drop the
mark_param_change callback.
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Currently none of the buffer implementations implements the enable() or
is_enable() nor does core code try to call these. So it is safe to remove them.
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
The flag is only cleared, never set or tested, so it is safe to remove it.
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Our buffer implementation does not support multiple concurrent readers. So we
have to ensure that a device is only opened once at a time. So do the same thing
we do for the event fd and introduce a per device busy flag. The flag gets set
when opening the device and gets cleared when closing the device. If a open is
attempted while the busy flag is set we return -EBUSY.
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
The buffer buffer storage is only update when enabling the buffer. Changing the
buffer size while the buffer is enabled will confuse the buffer in regard to
its actual buffer size and can cause potential memory corruption. Thus it is
only safe to modify the buffer size when the buffer is disabled.
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Currently we only disallow changing the scan elements, while the buffer is
enabled, in triggered buffer mode. This patch changes it to disallow it for all
buffered modes. Disabling or enabling scan elements while the buffer is enabled
will cause undefined behavior since the reader will not be able to tell samples
with the new and old scan element set apart and thus wont be able to extract
any meaningful data from the buffer.
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This patch removes the return of the function CARDbSetMediaChannel, that
always return TRUE value.
Signed-off-by: Marcos Paulo de Souza <marcos.mage@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This function always return TRUE, and it is not used by the funtions
who calls it.
Signed-off-by: Marcos Paulo de Souza <marcos.mage@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Fixes the following warning:
drivers/staging/iio/industrialio-buffer.c: In function ‘iio_scan_mask_query’:
drivers/staging/iio/industrialio-buffer.c:620: warning: unused variable ‘mask’
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This patch fixes some 80 chatacters limit warnings in the lowmemorykiller.c file
Signed-off-by: Marco Navarra <fromenglish@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This patch fixes a simple tab-space warning in binder.h found by checkpatch tool
Signed-off-by: Marco Navarra <fromenglish@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
gma_resume_display() wants 'struct pci_dev *' as it's parameter, so lets pass dev->pdev instead of dev. Fixes the following warning.
drivers/staging/gma500/power.c: In function ‘gma_power_begin’:
drivers/staging/gma500/power.c:269:3: warning: passing argument 1 of ‘gma_resume_display’ from incompatible pointer type
drivers/staging/gma500/power.c:99:13: note: expected ‘struct pci_dev *’ but argument is of type ‘struct drm_device *’
Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Variable IoBuffer.InputLength is chosen from userspace,
and can therefore be less than the intended size. In this
case,the memory from the kmalloc call is eventually cast
to a PBULKWRM_BUFFER. If the IoBuffer.InputLength does not
meet the minimum size of PBULKWRM_BUFFER, then we will get
a kernel Oops. To resolve this issue, this patch verifies
IoBuffer.InputLength meets the minimum size before invoking
the kmalloc call.
Signed-off-by: Kevin McKinney <klmckinney1@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This ioctl, IOCTL_BCM_GET_DRIVER_VERSION, is
responsible for sending the driver version
to userspace. However, the requested size stored
in IoBuffer.OutputLength may be incorrect.
Therefore, we altered the code to send the
exact length of the version, plus one for the
null character.
Signed-off-by: Kevin McKinney <klmckinney1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: Fix usb/isp1760 build on sparc
usb: gadget: epautoconf: do not change number of streams
usb: dwc3: core: fix cached revision on our structure
usb: musb: fix reset issue with full speed device
|
|
* 'upstream-linus' of git://github.com/jgarzik/libata-dev:
pata_of_platform: Add missing CONFIG_OF_IRQ dependency.
|
