- 01 Dec, 2011 15 commits
-
-
Martyn Welch authored
The use of typedefs is discouraged, remove them. Signed-off-by:
Martyn Welch <martyn.welch@ge.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
K. Y. Srinivasan authored
The current code implemented a per-HBA memory pool mechanism. For IDE disks managed by this driver, there is a one to one correspondance between the block device and the associated virtual HBA and since currently only IDE devices can be the boot device, this addressed the deadlock issues that were raised during the review process. This patch implements a per-lun memory pool mechanism. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
K. Y. Srinivasan authored
Fix a bug in copy_from_bounce_buffer(). Signed-off-by:
-
K. Y. Srinivasan authored
Fix a bug in storvsc_command_completion() that leaks memory when scatter/gather lists are used on the "write" side. Signed-off-by:
-
K. Y. Srinivasan authored
The code in storvsc_device_alloc() is not needed as this would be done by default. Get rid of it. We still keep the function as we use this hook to allocate per-LUN memory pools in a later patch. Signed-off-by:
-
K. Y. Srinivasan authored
Disable clustering, since the host side on Hyper-V requires that each I/O element not exceed the page size. As part of this cleanup, get rid of the function to merge bvecs, as the primary reason for this function was to avoid having an element exceed the page size. Signed-off-by:
-
Haiyang Zhang authored
Add code to accept promiscuous mode setting, and pass it to RNDIS filter. Signed-off-by:
-
Haiyang Zhang authored
Signed-off-by:
-
Dan Carpenter authored
"line6" hasn't been set at this point and we should be using &interface->dev instead. Gcc would have complained about this if it weren't for the fact that we initialized line6 to NULL. I removed the initialization. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Stefan Hajnoczi <stefanha@gmail.com> Signed-off-by:
-
K. Y. Srinivasan authored
We need to properly add the hid device to correctly initialize the sysfs state. While this patch is against the staging tree; Jiri, please pick up this patch as you merge the Hyper-V mouse driver. Signed-off-by:
Fuzhou Chen <fuzhouch@microsoft.com> Signed-off-by:
-
Mathieu Desnoyers authored
* Dan Carpenter <dan.carpenter@oracle.com> wrote: > Sparse complains that these signed bitfields look "dubious". The > problem is that instead of being either 0 or 1 like people would expect, > signed one bit variables like this are either 0 or -1. It doesn't cause > a problem in this case but it's ugly so lets fix them. * walter harms (wharms@bfs.de) wrote: > hi, > This patch looks ok to me but this design is ugly by itself. > It should be replaced by an uchar uint whatever or use a > real bool (obviously not preferred by this programmes). bool :1, uchar :1 or uint :1 could make sense. uchar:1/bool:1 won't save any space here, because the surrounding fields are either uint or pointers, so alignment will just add padding. I try to use int/uint whenever possible because x86 CPUs tend to get less register false-dependencies when using instructions modifying the whole register (generated by using int/uint types) rather than only part of it (uchar/char/bool). I only use char/uchar/bool when there is a clear wanted space gain. The reason why I never use the bool type within a structure when I want a compact representation is that bool takes a whole byte just to represent one bit: struct usebitfield { int a; unsigned int f:1, g:1, h:1, i:1, j:1; int b; }; struct usebool { int a; bool f, g, h, i, j; int b; }; struct useboolbf { int a; bool f:1, g:1, h:1, i:1, j:1; int b; }; int main() { printf("bitfield %d bytes, bool %d bytes, boolbitfield %d bytes\n", sizeof(struct usebitfield), sizeof(struct usebool), sizeof(struct useboolbf)); } result: bitfield 12 bytes, bool 16 bytes, boolbitfield 12 bytes This is because each bool takes one byte, while the bitfields are put in units of "unsigned int" (or bool for the 3rd struct). So in this example, we need 5 bytes + 3 bytes alignment for the bool, but only 4 bytes to hold the "unsigned int" unit for the bitfields. The choice between bool and bitfields must also take into account the frequency of access to the variable, because bitfields require mask operations to access the selected bit(s). You will notice that none of these bitfields are accessed on the tracing fast-path: only in slow-paths. Therefore, space gain is more important than speed here. One might argue that I have so few of these fields here that it does not make an actual difference to go for bitfield or bool. I am just trying to choose types best suited for their intended purpose, ensuring they are future-proof and will allow simply adding more fields using the same type, as needed. So I guess I'll go for uint :1. Reported-by:Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Acked-by:
-
Mathieu Desnoyers authored
Needed to keep bissectability. Signed-off-by:
-
Mathieu Desnoyers authored
* Dan Carpenter <dan.carpenter@oracle.com> wrote: > The patch c844b2f5: "lttng lib: ring buffer" from Nov 28, 2011, > leads to the following Smatch complaint: > > drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c +86 > +lib_ring_buffer_mmap_buf() > warn: variable dereferenced before check 'buf' (see line 79) > > drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c > 78 unsigned long length = vma->vm_end - vma->vm_start; > 79 struct channel *chan = buf->backend.chan; > ^^^^^^^^^^^^^^^^^ > Dereference. > > 80 const struct lib_ring_buffer_config *config = chan->backend.config; > 81 unsigned long mmap_buf_len; > 82 > 83 if (config->output != RING_BUFFER_MMAP) > 84 return -EINVAL; > 85 > 86 if (!buf) > ^^^^ > Check. > > 87 return -EBADF; > 88 Let's move the NULL buf check to the file "open", where it belongs. The "open" file operation is the actual interface between lib ring buffer and the modules using it. Reported-by:
-
Mathieu Desnoyers authored
* Dan Carpenter <dan.carpenter@oracle.com> wrote: > The patch c844b2f5: "lttng lib: ring buffer" from Nov 28, 2011, > leads to the following Smatch complaint: > > drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c +33 > +lib_ring_buffer_fault() > warn: variable dereferenced before check 'buf' (see line 26) > > drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c > 25 struct lib_ring_buffer *buf = vma->vm_private_data; > 26 struct channel *chan = buf->backend.chan; > ^^^^^^^^^^^^^^^^^ > Dereference. > > 27 const struct lib_ring_buffer_config *config = chan->backend.config; > 28 pgoff_t pgoff = vmf->pgoff; > 29 struct page **page; > 30 void **virt; > 31 unsigned long offset, sb_bindex; > 32 > 33 if (!buf) > ^^^^ > Check. > > 34 return VM_FAULT_OOM; > 35 This check is performed at mapping setup time in lib_ring_buffer_mmap_buf() already, so we can safely remove this duplicata. Reported-by:
-
Mathieu Desnoyers authored
* Dan Carpenter <dan.carpenter@oracle.com> wrote: [...] > The patch c844b2f5: "lttng lib: ring buffer" from Nov 28, 2011, > leads to the following Smatch complaint: > > drivers/staging/lttng/lib/ringbuffer/ring_buffer_frontend.c +1150 > +lib_ring_buffer_print_buffer_errors() > warn: variable dereferenced before check 'chan' (see line 1143) > > drivers/staging/lttng/lib/ringbuffer/ring_buffer_frontend.c > 1142 { > 1143 const struct lib_ring_buffer_config *config = > +chan->backend.config; > > +^^^^^^^^^^^^^^^^^^^^ > Dereference. > > 1144 unsigned long write_offset, cons_offset; > 1145 > 1146 /* > 1147 * Can be called in the error path of allocation when > 1148 * trans_channel_data is not yet set. > 1149 */ > 1150 if (!chan) > ^^^^^^^^^ > Check. At first glance the comment seems out of date, I think check can > be removed safely. > > 1151 return; > 1152 /* Reported-by:
-
- 30 Nov, 2011 25 commits
-
-
Sean MacLennan authored
The "rtl8192e: Export symbols" patch exported three functions already exported by the rtl8192u driver. This patch renames the three functions: Dot11d_Init => dot11d_init HTUpdateSelfAndPeerSetting => HT_update_self_and_peer_setting IsLegalChannel => rtllib_legal_channel Signed-off-by:
Sean MacLennan <seanm@seanm.ca> Signed-off-by:
-
Colin Cross authored
Allow the board file to pass a boot info string through the platform data that is appended to the /proc/last_kmsg file. [moved the .h file to drivers/staging/android/ to be self-contained - gregkh] Signed-off-by:
Colin Cross <ccross@android.com> Signed-off-by:
-
JP Abgrall authored
(port from common android-2.6.39 commit: 11430f16545205c614dd5bd58e4a7ee630fc0f9f) events: (no change, 256) main: 64 -> 256 radio: 64 -> 256 system: 64 -> 256 Signed-off-by:
JP Abgrall <jpa@google.com> Signed-off-by:
-
Colin Cross authored
The arguments to shrink functions have changed, update lowmem_shrink to match. Signed-off-by:
-
Arve Hjønnevåg authored
Signed-off-by:
Arve Hjønnevåg <arve@android.com> Signed-off-by:
-
Colin Cross authored
Signed-off-by:
Colin Cross <ccross@google.com> Signed-off-by:
-
San Mehat authored
Now that we're murder-synchronous, this code path will never be called (and if it does, it doesn't tell us anything useful other than we killed a task that was already being killed by somebody else but hadn't gotten its' signal yet) Signed-off-by:
San Mehat <san@google.com> Signed-off-by:
-
Christopher Lais authored
binder_deferred_release was not unmapping the page from the buffer before freeing it, causing memory corruption. This only happened when page(s) had not been freed by binder_update_page_range, which properly unmaps the pages. This only happens on architectures with VIPT aliasing. To reproduce, create a program which opens, mmaps, munmaps, then closes the binder very quickly. This should leave a page allocated when the binder is released. When binder_deferrred_release is called on the close, the page will remain mapped to the address in the linear proc->buffer. Later, we may map the same physical page to a different virtual address that has different coloring, and this may cause aliasing to occur. PAGE_POISONING will greatly increase your chances of noticing any problems. Signed-off-by:
Christopher Lais <chris+android@zenthought.org> Signed-off-by:
-
San Mehat authored
This patch optimizes lowmemkiller to not do any work when it has an outstanding kill-request. This greatly reduces the pressure on the task_list lock (improving interactivity), as well as improving the vmscan performance when under heavy memory pressure (by up to 20x in tests). Note: For this enhancement to work, you need CONFIG_PROFILING Signed-off-by:
-
San Mehat authored
Under certain circumstances, a process can take awhile to handle a sig-kill (especially if it's in a scheduler group with a very low share ratio). When this occurs, lowmemkiller returns to vmscan indicating the process memory has been freed - even though the process is still waiting to die. Since the memory hasn't actually freed, lowmemkiller is called again shortly after, and picks the same process to die; regardless of the fact that it has already been 'scheduled' to die and the memory has already been reported to vmscan as having been freed. Solution is to check fatal_signal_pending() on the selected task, and if it's already pending destruction return; indicating to vmscan that no resources were freed on this pass. Signed-off-by:
-
Arve Hjønnevåg authored
Some drivers flush the global workqueue when closed. This would deadlock if the last reference to the file was released from the binder. Signed-off-by:
-
Mike Lockwood authored
The timed output device never previously checked the return value of sscanf, resulting in an uninitialized int being passed to enable() if input value was invalid. Signed-off-by:
Mike Lockwood <lockwood@android.com> Signed-off-by:
-
Arve Hjønnevåg authored
Signed-off-by:
-
Arve Hjønnevåg authored
Signed-off-by:
-
San Mehat authored
Signed-off-by:
-
Arve Hjønnevåg authored
Signed-off-by:
-
Arve Hjønnevåg authored
Signed-off-by:
-
San Mehat authored
[Note, this is part of a patch from Sam, just the drivers/staging/ portion, that adds a function that the apanic code calls, but the apanic code isn't here, so just include part of this to make merges and diffs easier and this keeps things self-contained - gregkh] Signed-off-by:
-
Greg Kroah-Hartman authored
It builds, so ship it! Cc: Arve Hjønnevåg <arve@android.com> Cc: Brian Swetland <swetland@google.com> Signed-off-by: -
Greg Kroah-Hartman authored
This reverts commit 2cdf99ce. It now builds, so this can be reverted. Cc: Arve Hjønnevåg <arve@android.com> Cc: Brian Swetland <swetland@google.com> Signed-off-by:
-
Colin Cross authored
Signed-off-by: -
Arve Hjønnevåg authored
Signed-off-by: -
Corentin Chary authored
Signed-off-by:
Corentin Chary <corentincj@iksaif.net> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit b0a0ccfa. Turns out I was wrong, we want these in the tree. Note, I've disabled the drivers from the build at the moment, so other patches can be applied to fix some build issues due to internal api changes since the code was removed from the tree. Cc: Arve Hjønnevåg <arve@android.com> Cc: Brian Swetland <swetland@google.com> Signed-off-by:
-
Sean MacLennan authored
Now that the rtl8192e driver is split up, it makes sense to keep the rtllib code in one directory and the rtl8192e specific code in another. This patch contains the split and the fixup of includes. Since rtl_core.h already included rtllib.h and dot11d.h, rtl_core.h was updated to point to the parent directory. All other references to rtllib.h and dot11d.h in the rtl8192e specific code where deleted rather than fixed. This leaves just one file that needs to know the real location of the rtllib includes. Signed-off-by:
-
