On Thu, Aug 09, 2012 at 11:36:21AM +0200, Tomasz Stanislawski wrote:
> This patch adds reference counting on a module that exported dma-buf and
> implements its operations. This prevents the module from being unloaded while
> DMABUF file is in use.
Why force all of the modules to be changed "by
On 08/09, Srikar Dronamraju wrote:
>
> * Oleg Nesterov [2012-08-08 19:37:47]:
>
> > Add the new MMF_HAS_UPROBES flag. It is set by install_breakpoint()
> > and it is copied by dup_mmap(), uprobe_pre_sstep_notifier() checks
> > it to avoid the slow path if the task was never probed. Perhaps it
> >
On Mon, 6 Aug 2012, Shuah Khan wrote:
> +#ifdef CONFIG_DEBUG_VM
> +static int kmem_cache_sanity_check(const char *name, size_t size)
Why do we pass "size" in? AFAICT there is no need to.
> @@ -53,48 +93,17 @@ struct kmem_cache *kmem_cache_create(const char *name,
> size_t size, size_t align
>
Hi Benjamin:
Revision will be update later.
Benjamin Tissoires 於 2012/8/9 下午7:27 寫道：
> Hi Scott,
>
> we are getting closer. Just a few nitpicks:
>
> On Thu, Aug 9, 2012 at 11:22 AM, Scott Liu wrote:
>> Some of ELAN's production need to with set_idle commmand when reusme.
>
>
x86: fix ptrace.o compile error
Fix compiling Linux 2.6.32.59 with gcc 4.7.1 (Debian 7 testing). Mainline has
instead removed the "asmregparm" in ptrace.c (in fact, everywhere), but this
alternative seemed too invasive.
CC arch/x86/kernel/ptrace.o
arch/x86/kernel/ptrace.c:1472:17: error:
On 08/09/2012 04:10 PM, Takashi Iwai wrote:
For processing the firmware handling properly for built-in kernels,
implement an asynchronous firmware loading with
request_firmware_nowait(). This means that the codec probing is
deferred when the patch option is specified.
Signed-off-by: Takashi
On Thu, Aug 09, 2012 at 08:40:36AM -0500, Matt Sealey wrote:
> The reason they're set like that is legacy - that's how they're set up
> in a kernel
> (pre-DT) that we know works. Most of those ranges are directly from the
> Babbage
> reference and stay like that in the Babbage DT too - so
On Thu, 9 Aug 2012, Hanjun Guo wrote:
> Now, We have node masks for both N_NORMAL_MEMORY and
> N_HIGH_MEMORY to distinguish between normal and highmem on platforms such as
> x86.
> But we still don't have such a mechanism to distinguish between "normal" and
> "movable"
> memory.
What is the
For processing the firmware handling properly for built-in kernels,
implement an asynchronous firmware loading with
request_firmware_nowait(). This means that the codec probing is
deferred when the patch option is specified.
Signed-off-by: Takashi Iwai
---
v1->v2: drop superfluous
Hi Russell,
On 8/6/2012 7:14 AM, Russell King - ARM Linux wrote:
On Tue, Jul 31, 2012 at 07:04:39PM -0400, Cyril Chemparathy wrote:
This patch fixes up the types used when converting back and forth between
physical and virtual addresses.
Signed-off-by: Vitaly Andrianov
Signed-off-by: Cyril
On Thu, 9 Aug 2012 17:55:20 +0400
Marina Makienko wrote:
> The function blk_get_request() can return NULL in some cases. There are
> checks on it if function is called with argumetns one of which is
> GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
> blk_get_request() return NULL.
On 08/09/2012 02:20 AM, David Miller wrote:
From: ebied...@xmission.com (Eric W. Biederman)
Date: Tue, 07 Aug 2012 10:17:02 -0700
Since I am motivated to get things done, and since there has been much
grumbling about my patches not implementing tunables, I have added
tunable support on top of
On Mon, 2012-08-06 at 15:13 -0600, Shuah Khan wrote:
> kmem_cache_create() does cache integrity checks when CONFIG_DEBUG_VM
> is defined. These checks interspersed with the regular code path has
> lead to compile time warnings when compiled without CONFIG_DEBUG_VM
> defined. Restructuring the code
On Thu, Aug 9, 2012 at 8:55 AM, Yan, Zheng wrote:
> On 08/09/2012 08:51 AM, Stephane Eranian wrote:
>> Hi,
>>
>> I ran into a problem on my AMD box whereby I would hit the
>> WARN_ON_ONCE(cpuctx->cgrp) in perf_cgroup_switch().
>>
>> It took me a while to track this down. It turns out that the
>>
At Thu, 09 Aug 2012 15:54:04 +0200,
David Henningsson wrote:
>
> On 08/09/2012 03:36 PM, Takashi Iwai wrote:
> > +/* callback from request_firmware_nowait() */
> > +static void azx_firmware_cb(const struct firmware *fw, void *context)
> > +{
> > + struct snd_card *card = context;
> > + struct
On Thu, Aug 09, 2012 at 03:54:04PM +0200, David Henningsson wrote:
> On 08/09/2012 03:36 PM, Takashi Iwai wrote:
> >+/* callback from request_firmware_nowait() */
> >+static void azx_firmware_cb(const struct firmware *fw, void *context)
> >+{
> >+struct snd_card *card = context;
> >+struct
he function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
The function blk_get_request() can return NULL in some cases. There are
checks on it if function is called with argumetns one of which is
GFP_ATOMIC/GFP_NOIO/etc. If system couldn't find request
blk_get_request() return NULL.
But if there is function call with argument __GFP_WAIT
the system will
Subject: possible double free in edac_mc_alloc()
Reply-To:
User-Agent: Heirloom mailx 12.5 6/20/10
Hi,
coccinelle warns about:
+ drivers/edac/edac_mc.c:429:9-23: ERROR: reference preceded by free on line 429
and that line does look strange: the 'i' seems like a temporary value
used in
On 08/09/2012 03:36 PM, Takashi Iwai wrote:
+/* callback from request_firmware_nowait() */
+static void azx_firmware_cb(const struct firmware *fw, void *context)
+{
+ struct snd_card *card = context;
+ struct azx *chip = card->private_data;
+ struct pci_dev *pci = chip->pci;
+
On 08/09/2012 01:36 PM, Mark Brown wrote:
> On Thu, Aug 09, 2012 at 01:18:50PM +0300, Peter Ujfalusi wrote:
>> On 08/08/2012 05:49 PM, Mark Brown wrote:
>
>>> That makes sense if the GPIO is actively driven, open drain should be
>>> better here, but it's still a generic thing which it'd be nice
On Wed, Aug 08, 2012 at 09:57:44AM +0900, Minchan Kim wrote:
> [1] fixed bad deferring policy but made mistake about checking
> compact_order_failed in __compact_pgdat so it can't update
> compact_order_failed with new order. It ends up preventing working
> of deffering policy rightly. This patch
Changelog since V2
o Capture !MIGRATE_MOVABLE pages where possible
o Document the treatment of MIGRATE_MOVABLE pages while capturing
o Expand changelogs
Changelog since V1
o Dropped kswapd related patch, basically a no-op and regresses if fixed
(minchan)
o Expanded changelogs a little
If allocation fails after compaction then compaction may be deferred for
a number of allocation attempts. If there are subsequent failures,
compact_defer_shift is increased to defer for longer periods. This patch
uses that information to scale the number of pages reclaimed with
compact_defer_shift
From: Rik van Riel
This commit is already upstream as [7db8889a: mm: have order > 0 compaction
start off where it left]. It's included in this series to provide context
to the next patch as the series is based on 3.5.
Order > 0 compaction stops when enough free pages of the correct page
order
commit [7db8889a: mm: have order > 0 compaction start off where it left]
introduced a caching mechanism to reduce the amount work the free page
scanner does in compaction. However, it has a problem. Consider two process
simultaneously scanning free pages
While compaction is migrating pages to free up large contiguous blocks for
allocation it races with other allocation requests that may steal these
blocks or break them up. This patch alters direct compaction to capture a
suitable free page as soon as it becomes available to reduce this race. It
The comment about order applied when the check was
order > PAGE_ALLOC_COSTLY_ORDER which has not been the case since
[c5a73c3d: thp: use compaction for all allocation orders]. Fixing
the comment while I'm in the general area.
Signed-off-by: Mel Gorman
Reviewed-by: Rik van Riel
Reviewed-by:
On Thu, 2012-08-09 at 09:46 -0400, Steven Rostedt wrote:
> Peter and Masami
>
> During my final tests, I found that this change breaks the
> !DYNAMIC_FTRACE config. That is, when we don't do the run-time updates
> of mcount calls to nops, the compiler will use fentry but the code still
> uses
Peter and Masami
During my final tests, I found that this change breaks the
!DYNAMIC_FTRACE config. That is, when we don't do the run-time updates
of mcount calls to nops, the compiler will use fentry but the code still
uses mcount.
I fixed this in the patch below. But as you two have acked and
On Thu, Aug 9, 2012 at 5:19 AM, Mark Brown
wrote:
> On Tue, Aug 07, 2012 at 04:46:18PM -0500, Matt Sealey wrote:
>
> Yay for indentation! It'd be good to rewrite your DT so you could cut
> down on that, at the minute it's not good for legibility.
>
>> +
For processing the firmware handling properly for built-in kernels,
implement an asynchronous f/w loading with request_firmware_nowait().
This means that the codec probing is deferred when the patch option is
specified.
Signed-off-by: Takashi Iwai
---
v1->v2: drop superfluous
On Thu, Aug 09, 2012 at 02:46:37AM -0700, Michel Lespinasse wrote:
> On Fri, Jul 27, 2012 at 8:57 PM, John Stultz wrote:
> > v5:
> > * Drop intervaltree for prio_tree usage per Michel &
> > Dmitry's suggestions.
>
> Actually, I believe the ranges you need to track are non-overlapping, correct
* Oleg Nesterov [2012-08-08 19:37:52]:
> Nobody does set_orig_insn(verify => false), and I think nobody will.
> Remove this argument. IIUC set_orig_insn(verify => false) was needed
> to single-step without xol area.
>
> Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
> ---
>
* Oleg Nesterov [2012-08-08 19:37:47]:
> Add the new MMF_HAS_UPROBES flag. It is set by install_breakpoint()
> and it is copied by dup_mmap(), uprobe_pre_sstep_notifier() checks
> it to avoid the slow path if the task was never probed. Perhaps it
> makes sense to check it in
At Thu, 09 Aug 2012 15:26:56 +0200,
David Henningsson wrote:
>
> On 08/09/2012 03:11 PM, Takashi Iwai wrote:
>
> > @@ -3187,13 +3217,16 @@ static int __devinit azx_probe(struct pci_dev *pci,
> > if (patch[dev] && *patch[dev]) {
> > snd_printk(KERN_ERR SFX "Applying patch firmware
On Wednesday, August 08, 2012 05:00:26 PM Casey Schaufler wrote:
> On 8/8/2012 2:54 PM, Eric Dumazet wrote:
>
> By the way, once this proved to be an issue that involved
> more than just SELinux it needed to go onto the LSM list as
> well.
Yes, you're right.
> > On Wed, 2012-08-08 at 16:46
On 08/04/2012 02:07 PM, Namjae Jeon wrote:
> Update missing index files in block/00-INDEX.
Thanks, applied 1-3.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 08/09/2012 03:11 PM, Takashi Iwai wrote:
@@ -3187,13 +3217,16 @@ static int __devinit azx_probe(struct pci_dev *pci,
if (patch[dev] && *patch[dev]) {
snd_printk(KERN_ERR SFX "Applying patch firmware '%s'\n",
patch[dev]);
- err
On 08/05/2012 10:26 AM, Fengguang Wu wrote:
> Hi all,
>
> It seems this patch was silently forgotten, but the review comments have all
> been addressed: the patch has been split into two pieces and tests show no
> performance regressions (nor noticeable gains..).
>
> Thanks to Damien for
On 08/08/2012 11:38 PM, Tejun Heo wrote:
> Now that cancel_delayed_work() can be safely called from IRQ handlers,
> there's no reason to use __cancel_delayed_work(). Use
> cancel_delayed_work() instead of __cancel_delayed_work() and mark the
> latter deprecated.
>
> Signed-off-by: Tejun Heo
>
On 08/09/2012 07:28 AM, Shaohua Li wrote:
> The SCSI discard request merge never worked, and looks no solution for in
> future, let's disable it temporarily.
Thanks, applied!
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 08/09/2012 07:52 AM, Alexey Khoroshilov wrote:
> Do not leak memory by updating pointer with potentially NULL realloc return
> value.
>
> Found by Linux Driver Verification project (linuxtesting.org).
Thanks, applied.
--
Jens Axboe
--
To unsubscribe from this list: send the line
Alexey Khoroshilov writes:
> Do not leak memory by updating pointer with potentially NULL realloc return
> value.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
Acked-by: Jeff Moyer
--
To unsubscribe from this list: send the line
For processing the firmware handling properly for built-in kernels,
implement an asynchronous f/w loading with request_firmware_nowait().
This means that the codec probing is deferred when the patch option is
specified.
Signed-off-by: Takashi Iwai
---
sound/pci/hda/hda_codec.c | 2 +-
This is a preliminary work for the deferred probing for
request_firmware() errors at init.
This patch moves the call of request_firmware() to hda_intel.c, and
call it in the earlier stage of probing rather than
azx_probe_continue().
Signed-off-by: Takashi Iwai
---
sound/pci/hda/hda_codec.h |
Hi,
this is a series of patches to fix the firmware loading problem.
I split the changes to two for making clean what the patches do.
Basically it moves request_firmware() to hda_intel.c, then replaces it
with request_firmware_nowait(). Through a short testing, it seems
working fine here on my
On Thursday 09 August 2012 06:30 PM, Mark Brown wrote:
On Thu, Aug 09, 2012 at 05:57:03PM +0530, Laxman Dewangan wrote:
On Thursday 09 August 2012 06:08 PM, Mark Brown wrote:
The driver should just register all the regulators the chip has, it's
useful for diagnostic purposes if nothing else.
At Thu, 9 Aug 2012 14:49:04 +0200,
Thierry Reding wrote:
>
> On Thu, Aug 09, 2012 at 02:32:38PM +0200, Takashi Iwai wrote:
> > At Thu, 9 Aug 2012 12:34:30 +0200,
> > Thierry Reding wrote:
> > >
> > > On Thu, Aug 09, 2012 at 10:21:15AM +0200, Takashi Iwai wrote:
> > > > At Thu, 9 Aug 2012
This flag is used to indicate to the callees that this allocation is a
kernel allocation in process context, and should be accounted to
current's memcg. It takes numerical place of the of the recently removed
__GFP_NO_KSWAPD.
Signed-off-by: Glauber Costa
CC: Christoph Lameter
CC: Pekka Enberg
Because those architectures will draw their stacks directly from the
page allocator, rather than the slab cache, we can directly pass
__GFP_KMEMCG flag, and issue the corresponding free_pages.
This code path is taken when the architecture doesn't define
CONFIG_ARCH_THREAD_INFO_ALLOCATOR (only
Because the ultimate goal of the kmem tracking in memcg is to track slab
pages as well, we can't guarantee that we'll always be able to point a
page to a particular process, and migrate the charges along with it -
since in the common case, a page will contain data belonging to multiple
processes.
This patch introduces infrastructure for tracking kernel memory pages to
a given memcg. This will happen whenever the caller includes the flag
__GFP_KMEMCG flag, and the task belong to a memcg other than the root.
In memcontrol.h those functions are wrapped in inline accessors. The
idea is to
The current memcg slab cache management fails to present satisfatory
hierarchical behavior in the following scenario:
-> /cgroups/memory/A/B/C
* kmem limit set at A,
* A and B have no tasks,
* span a new task in in C.
Because kmem_accounted is a boolean that was not set for C, no
accounting
We can use jump labels to patch the code in or out when not used.
Because the assignment: memcg->kmem_accounted = true is done after the
jump labels increment, we guarantee that the root memcg will always be
selected until all call sites are patched (see memcg_kmem_enabled).
This guarantees that
When a process tries to allocate a page with the __GFP_KMEMCG flag, the
page allocator will call the corresponding memcg functions to validate
the allocation. Tasks in the root memcg can always proceed.
To avoid adding markers to the page - and a kmem flag that would
necessarily follow, as much
From: Suleiman Souhlal
We currently have a percpu stock cache scheme that charges one page at a
time from memcg->res, the user counter. When the kernel memory
controller comes into play, we'll need to charge more than that.
This is because kernel memory allocations will also draw from the user
From: Suleiman Souhlal
mem_cgroup_do_charge() was written before kmem accounting, and expects
three cases: being called for 1 page, being called for a stock of 32
pages, or being called for a hugepage. If we call for 2 or 3 pages (and
both the stack and several slabs used in process creation
This is just a cleanup patch for clarity of expression. In earlier
submissions, people asked it to be in a separate patch, so here it is.
[ v2: use named enum as type throughout the file as well ]
Signed-off-by: Glauber Costa
CC: Michal Hocko
CC: Johannes Weiner
Acked-by: Kamezawa Hiroyuki
Hi,
This is the first part of the kernel memory controller for memcg. It has been
discussed many times, and I consider this stable enough to be on tree. A follow
up to this series are the patches to also track slab memory. They are not
included here because I believe we could benefit from merging
This patch adds the basic infrastructure for the accounting of the slab
caches. To control that, the following files are created:
* memory.kmem.usage_in_bytes
* memory.kmem.limit_in_bytes
* memory.kmem.failcnt
* memory.kmem.max_usage_in_bytes
They have the same meaning of their user memory
On Thu, Aug 09, 2012 at 05:57:03PM +0530, Laxman Dewangan wrote:
> On Thursday 09 August 2012 06:08 PM, Mark Brown wrote:
> >The driver should just register all the regulators the chip has, it's
> >useful for diagnostic purposes if nothing else.
> Then probably we need to update our dts file
2012/8/9 Namhyung Kim :
> The usage like this is too specific and hard to use IMHO. How about
> putting it somehow into perf sched or new command?
>
> /me don't have an idea though. :-)
>
I'm going to add a script, so the usage will look like this:
$ perf script
Hi Greg, Felipe,
On Wed, 8 Aug 2012 15:34:27 +0200
Greg Kroah-Hartman wrote:
> On Wed, Aug 08, 2012 at 09:24:32AM +0300, Hiroshi Doyu wrote:
> > Add __debugfs_create_dir(), which takes data passed from caller.
>
> Why?
>
> > Signed-off-by: Hiroshi Doyu
> > ---
> > fs/debugfs/inode.c |
This is a fix for bug, introduced in 3.4 kernel by commit
1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d, which, among other things, replaced
simple sock_put() by sk_release_kernel(). Below is sequence, which leads to
oops for non-persistent devices:
tun_chr_close()
tun_detach()
On Thu, Aug 09, 2012 at 02:32:38PM +0200, Takashi Iwai wrote:
> At Thu, 9 Aug 2012 12:34:30 +0200,
> Thierry Reding wrote:
> >
> > On Thu, Aug 09, 2012 at 10:21:15AM +0200, Takashi Iwai wrote:
> > > At Thu, 9 Aug 2012 10:07:13 +0200,
> > > Thierry Reding wrote:
> > > >
> > > > On Thu, Aug 09,
On Thursday 09 August 2012 06:08 PM, Mark Brown wrote:
On Thu, Aug 09, 2012 at 05:49:49PM +0530, Laxman Dewangan wrote:
There may be possibility that some of regulator node is not
populated and that case, the idata will be NULL and hence regulator
registration can be bypass for that regulator.
Em 09-08-2012 09:00, Hans de Goede escreveu:
> Hi,
>
> My bad, sorry about this. Mauro's patch looks good.
Hmm...
menuconfig NEW_LEDS
bool "LED Support"
help
Say Y to enable Linux LED support. This allows control of supported
LEDs from both userspace and
On Thu, Aug 09, 2012 at 05:49:49PM +0530, Laxman Dewangan wrote:
> There may be possibility that some of regulator node is not
> populated and that case, the idata will be NULL and hence regulator
> registration can be bypass for that regulator.
The driver should just register all the regulators
On Thu, Aug 09, 2012 at 06:45:37AM +0300, Linus Torvalds wrote:
> On Wed, Aug 8, 2012 at 3:49 PM, Steven Rostedt wrote:
> >
> > No, CONFIG_HAVE_FENTRY just means fentry is supported, it does not mean
> > that it is being used. It only gets used if CC_USING_FENTRY is set,
> > which is set by the
On Thu, 2012-08-09 at 18:24 +0900, Masami Hiramatsu wrote:
> Yeah, it is really easy to fix that.
> But out of curiosity, would that be really a problem?
> I guess that host can access any guest page if need. If that
> is right, is that really insecure to leak randomly allocated
> unused page to
On Thursday 09 August 2012 02:48 AM, Stephen Warren wrote:
From: Gyungoh Yoo
The MAX8907 is an I2C-based power-management IC containing voltage
regulators, a reset controller, a real-time clock, and a touch-screen
+ for (i = 0; i< MAX8907_NUM_REGULATORS; i++) {
+
At Thu, 9 Aug 2012 12:34:30 +0200,
Thierry Reding wrote:
>
> On Thu, Aug 09, 2012 at 10:21:15AM +0200, Takashi Iwai wrote:
> > At Thu, 9 Aug 2012 10:07:13 +0200,
> > Thierry Reding wrote:
> > >
> > > On Thu, Aug 09, 2012 at 09:42:48AM +0200, Takashi Iwai wrote:
> > > > At Thu, 9 Aug 2012
This patch adds a user tool, "trace agent" for sending trace data of a guest to
a Host in low overhead. This agent has the following functions:
- splice a page of ring-buffer to read_pipe without memory copying
- splice the page from write_pipe to virtio-console without memory copying
- write
From: Masami Hiramatsu
Allocate scatterlist according to the current pipe size.
This allows splicing bigger buffer if the pipe size has
been changed by fcntl.
Changes in v2:
- Just a minor fix for avoiding a confliction with previous patch.
Signed-off-by: Masami Hiramatsu
---
From: Masami Hiramatsu
Use generic steal operation on pipe buffer to allow stealing
ring buffer's read page from pipe buffer.
Note that this could reduce the performance of splice on the
splice_write side operation without affinity setting.
Since the ring buffer's read pages are allocated on
From: Masami Hiramatsu
Wait if the port is not connected or full on splice
like as write is doing.
Signed-off-by: Masami Hiramatsu
---
drivers/char/virtio_console.c | 39 +++
1 files changed, 27 insertions(+), 12 deletions(-)
diff --git
From: Masami Hiramatsu
Add a failback memcpy path for unstealable pipe buffer.
If buf->ops->steal() fails, virtio-serial tries to
copy the page contents to an allocated page, instead
of just failing splice().
Signed-off-by: Masami Hiramatsu
---
drivers/char/virtio_console.c | 28
From: Masami Hiramatsu
Enable to use splice_write from pipe to virtio-console port.
This steals pages from pipe and directly send it to host.
Note that this may accelerate only the guest to host path.
Changes in v2:
- Use GFP_KERNEL instead of GFP_ATOMIC in syscall context function.
Hi All,
The following patch set provides a low-overhead system for collecting kernel
tracing data of guests by a host in a virtualization environment.
A guest OS generally shares some devices with other guests or a host, so
reasons of any problems occurring in a guest may be from other guests or
After walking rb tree, if vma is determined, prev vma has to be determined
based on vma; and rb_prev should be considered only if no vma determined.
Signed-off-by: Hillf Danton
---
--- a/mm/mmap.c Fri Aug 3 07:38:10 2012
+++ b/mm/mmap.c Mon Aug 6 20:10:18 2012
@@ -385,9 +385,13 @@
On Thu, 9 Aug 2012 20:57:14 +0900
Namjae Jeon wrote:
> Hi Jeff.
>
> I still found ESTALE error although patching these patch-set.
> Is test method correct that I try to run estale_test on each nfs
> server and client at the same time ?
>
> ./estale_test
> chmod: Stale NFS[ 281.72] #
On 08/09/2012 02:55 PM, Mark Brown wrote:
> On Mon, Jul 30, 2012 at 05:13:17PM +0300, Peter Ujfalusi wrote:
>
>> If the board needs the gpo driver, but in the driver(s) I need to check for
>> the existence of the "ti,twl6040-gpo" node and check if the status is "okay".
>> I think it is easier to
On 08/09/2012 12:43 PM, Wei Ni wrote:
> Hi, all
> I'm working on tegra wlan upstream issue.
> The tegra board use the Broadcom 4329 as wlan device, and the driver is
> the brcmfmac.
>
> This wlan driver support out-band-interrupt (OOB), I want to add DT
> support to use this OOB.
> I can add
On Thu, Aug 09, 2012 at 11:48:42AM +, Arnd Bergmann wrote:
> On Thursday 09 August 2012, Wei Ni wrote:
> > The wlan driver wish this flags include the IRQF_TRGGER_* information,
> > and it will use this flags to configure other hw settings. If it is
> > wrong, the wlan can't work.
You can
Commit a2c204 (timekeeping: Add suspend and resume of clock event devices)
added suspend and resume operations for clockevents but did not provide
stubs for these functions, breaking the build when clockevents are not
being built. Add the stubs.
Signed-off-by: Mark Brown
---
Hi,
My bad, sorry about this. Mauro's patch looks good. An alternative fix
would be to #ifdefify the led code in the drivers themselves.
Regards,
Hans
On 08/09/2012 01:38 PM, Mauro Carvalho Chehab wrote:
Em 08-08-2012 19:28, David Rientjes escreveu:
On Tue, 31 Jul 2012, Mauro Carvalho
Hi Jeff.
I still found ESTALE error although patching these patch-set.
Is test method correct that I try to run estale_test on each nfs
server and client at the same time ?
./estale_test
chmod: Stale NFS[ 281.72] # send signal from USER, SIG : 2,
estale_test(107)->estale_test(102)
On Mon, Jul 30, 2012 at 05:13:17PM +0300, Peter Ujfalusi wrote:
> If the board needs the gpo driver, but in the driver(s) I need to check for
> the existence of the "ti,twl6040-gpo" node and check if the status is "okay".
> I think it is easier to just get the value of "ti,use-gpo", if it exist
401 - 500 of 1336 matches
Mail list logo
