On Thu, May 23, 2013 at 03:55:58AM +0800, Xiao Guangrong wrote:
> It is only used to zap the obsolete page. Since the obsolete page
> will not be used, we need not spend time to find its unsync children
> out. Also, we delete the page from shadow page cache so that the page
> is completely
Hi all,
There will be no linux-next release tomorrow.
Changes since 20130522:
The crypto tree still had its build failure so I used the version from
next-20130520.
The vhost tree lost its build failure.
I have
when CONFIG_VMWARE_VMCI=m:
ERROR: "memcpy_toiovec" [drivers/misc/vmw_vmci/vmw_vmci.ko] undefined!
ERROR: "memcpy_fromiovec" [drivers/misc/vmw_vmci/vmw_vmci.ko] undefined!
Changing iovec.o from lib-y to obj-y fixes the build errors.
---
From: Randy Dunlap
Fix build error io vmw_vmci.ko by
Allocate ELF headers on page-size boundary using __get_free_pages()
instead of kmalloc().
Later patch will merge PT_NOTE entries into a single unique one and
decrease the buffer size actually used. Keep original buffer size in
variable elfcorebuf_sz_orig to kfree the buffer later and actually
The reasons why we don't allocate ELF note segment in the 1st kernel
(old memory) on page boundary is to keep backward compatibility for
old kernels, and that if doing so, we waste not a little memory due to
round-up operation to fit the memory to page boundary since most of
the buffers are in
Now ELF note segment has been copied in the buffer on vmalloc
memory. To allow user process to remap the ELF note segment buffer
with remap_vmalloc_page, the corresponding VM area object has to have
VM_USERMAP flag set.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 14 ++
Treat memory chunks referenced by PT_LOAD program header entries in
page-size boundary in vmcore_list. Formally, for each range [start,
end], we set up the corresponding vmcore object in vmcore_list to
[rounddown(start, PAGE_SIZE), roundup(end, PAGE_SIZE)].
This change affects layout of
We want to allocate ELF note segment buffer on the 2nd kernel in
vmalloc space and remap it to user-space in order to reduce the risk
that memory allocation fails on system with huge number of CPUs and so
with huge ELF note segment that exceeds 11-order block size.
Although there's already
This patch introduces mmap_vmcore().
Don't permit writable nor executable mapping even with mprotect()
because this mmap() is aimed at reading crash dump memory.
Non-writable mapping is also requirement of remap_pfn_range() when
mapping linear pages on non-consecutive physical pages; see
On 23 May 2013 02:46, Jonathan Cameron wrote:
> On 05/20/2013 06:09 PM, Doug Anderson wrote:
>> Naveen,
>>
>> On Sun, May 19, 2013 at 11:34 PM, Naveen Krishna Chatradhi
>> wrote:
>>> The exynos_adc device structure was wrongly extracted from the dev*
>>> correcting the same.
>>>
>>> Using the
The previous patches newly added holes before each chunk of memory and
the holes need to be count in vmcore file size. There are two ways to
count file size in such a way:
1) supporse m as a poitner to the last vmcore object in vmcore_list.
, then file size is (m->offset + m->size), or
2)
Rewrite part of read_vmcore() that reads objects in vmcore_list in the
same way as part reading ELF headers, by which some duplicated and
redundant codes are removed.
Signed-off-by: HATAYAMA Daisuke
Acked-by: Vivek Goyal
---
fs/proc/vmcore.c | 68
Currently, __find_vmap_area searches for the kernel VM area starting
at a given address. This patch changes this behavior so that it
searches for the kernel VM area to which the address belongs. This
change is needed by remap_vmalloc_range_partial to be introduced in
later patch that receives any
Currently, read to /proc/vmcore is done by read_oldmem() that uses
ioremap/iounmap per a single page. For example, if memory is 1GB,
ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144
times. This causes big performance degradation due to repeated page
table changes, TLB flush and
On 05/23/2013 11:54 AM, Rusty Russell wrote:
> Chen Gang writes:
>> > Hello Maintainers:
>> >
>> > Please help check the patch whether OK or not, when you have time.
> Hi Chen,
>
> There's nothing *wrong* with the patch, but I don't think it's
> worthwhile. If this were your very first
Original report:
http://oss.sgi.com/archives/xfs/2013-05/msg00683.html
Also seen on Power7:
http://marc.info/?l=linux-kernel=136927904900692=2
CAI Qian
- Original Message -
> From: "Dave Chinner"
> To: "CAI Qian"
> Cc: "LKML" , sta...@vger.kernel.org,
> x...@oss.sgi.com
> Sent:
Kees Cook writes:
> This reduces the size of the stack frame when calling request_module().
> Performing the sprintf before the call is not needed.
>
> Signed-off-by: Kees Cook
I like the patch. If dwmw2 doesn't grab it, Andrew please take.
Thanks,
Rusty.
> ---
>
Chen Gang writes:
> Hello Maintainers:
>
> Please help check the patch whether OK or not, when you have time.
Hi Chen,
There's nothing *wrong* with the patch, but I don't think it's
worthwhile. If this were your very first kernel patch, I'd probably
apply it just to encourage you, but
On Wed, May 22, 2013 at 11:48:51PM -0400, Vince Weaver wrote:
>
> In case anyone cares, the Oops is happening here:
>
> 1a56: 48 c1 e8 0c shr$0xc,%rax
> 1a5a: 48 ff c0inc%rax
> > 1a5d: f0 48 29 45 60 lock sub
Reviewed-by: Tang Chen
Thanks. :)
On 05/23/2013 06:06 AM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
As noted by Tang Chen, the last_online field in struct memory_block
introduced by commit 4960e05 (Driver core: Introduce offline/online
callbacks for memory blocks) is not really
- Original Message -
> From: "Dave Chinner"
> To: "CAI Qian"
> Cc: "LKML" , sta...@vger.kernel.org,
> x...@oss.sgi.com
> Sent: Thursday, May 23, 2013 11:46:11 AM
> Subject: Re: 3.9.2: xfstests triggered panic
>
> On Wed, May 22, 2013 at 11:16:56PM -0400, CAI Qian wrote:
> > -
On Wed, May 22, 2013 at 11:16:56PM -0400, CAI Qian wrote:
> - Original Message -
> > From: "Dave Chinner"
> > To: "CAI Qian"
> > Cc: "LKML" , sta...@vger.kernel.org,
> > x...@oss.sgi.com
> > Sent: Wednesday, May 22, 2013 5:53:00 PM
> > Subject: Re: 3.9.2: xfstests triggered panic
> >
>
Jason Wang writes:
> Commit 55257d72bd1c51f25106350f4983ec19f62ed1fa (virtio-net: fill only rx
> queues which are being used) only does the napi enabling during open for
> curr_queue_pairs. This will break multiqueue receiving since napi of new
> queues
> were still disabled after changing the
In case anyone cares, the Oops is happening here:
1a56: 48 c1 e8 0c shr$0xc,%rax
1a5a: 48 ff c0inc%rax
> 1a5d: f0 48 29 45 60 lock sub %rax,0x60(%rbp)
1a62: 49 8b 46 40 mov0x40(%r14),%rax
Which
> On 05/21/2013 04:03 PM, Dave Jones wrote:
>
> [ 72.318133] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x6
> [ 132.446449] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x6
> [ 192.573101] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x6
> [ 252.702055] microcode: Microcode Update
"J. Bruce Fields" writes:
> On Wed, May 22, 2013 at 11:35:56AM -0700, Eric W. Biederman wrote:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>>
>> > I am missing a lot of context here and capturing the context of a
>> > process at time time we mount the filesystem and reconstituing it in
Signed-off-by: Jason Wang
---
drivers/net/macvtap.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 06b10a5..6a4af74 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -31,10 +31,6 @@
*
This patch adds TUNSETQUEUE ioctl to let userspace can temporarily disable or
enable a queue of macvtap. This is used to be compatible at API layer of tuntap
to simplify the userspace to manage the queues.
This is done by just introduce a pointer detached which was set when the queue
were
To be same with tap.
Signed-off-by: Jason Wang
---
include/linux/if_macvlan.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index e47ad46..32e943a 100644
--- a/include/linux/if_macvlan.h
+++
Though the queue were in fact created by open(), we still need to add this check
to be compatible with tuntap which can let mgmt software use a single API to
manage queues. This patch only validates the device name and moves the TUNSETIFF
to a helper.
Signed-off-by: Jason Wang
---
Tuntap return -EBADFD when TUNGETIFF fails, we should return the same value.
Signed-off-by: Jason Wang
---
drivers/net/macvtap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 59e9605..ce1c72a 100644
---
Factor out the device holding logic to a macvtap_get_vlan(), this will be also
used by multiqueue API.
Signed-off-by: Jason Wang
---
drivers/net/macvtap.c | 26 +++---
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/net/macvtap.c
Linear search were used in both get_slot() and macvtap_get_queue(), this is
because:
- macvtap didn't reshuffle the array of taps when create or destroy a queue, so
when adding a new queue, macvtap must do linear search to find a location for
the new queue. This will also complicate the
Signed-off-by: Jason Wang
---
include/linux/if_macvlan.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index 84dde1d..e47ad46 100644
--- a/include/linux/if_macvlan.h
+++ b/include/linux/if_macvlan.h
@@ -8,7 +8,7
- Original Message -
> From: "Greg KH"
> To: "CAI Qian"
> Cc: "Li Zefan" , "LKML" ,
> "Dave Jones" ,
> sta...@vger.kernel.org
> Sent: Wednesday, May 22, 2013 11:30:24 PM
> Subject: Re: 3.9.2: trinity triggered oops
>
> On Wed, May 22, 2013 at 04:40:45PM +0800, Li Zefan wrote:
> > On
Hi all:
This series implements a fully tuntap compatiable API which could be used by
userspace to manage multi macvtap queues. The main parts is to add TUNSETQUEUE
ioctl support for macvtap.
Patch 1 - 4 was some tuntap compatibility and misc cleanups.
Patch 5 removes the linear search in macvtap
- Original Message -
> From: "Dave Chinner"
> To: "CAI Qian"
> Cc: "LKML" , sta...@vger.kernel.org,
> x...@oss.sgi.com
> Sent: Wednesday, May 22, 2013 5:53:00 PM
> Subject: Re: 3.9.2: xfstests triggered panic
>
> On Wed, May 22, 2013 at 04:39:58AM -0400, CAI Qian wrote:
> >
On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
>> Some drivers can be built on more platforms than they run on. This
>> causes users and distributors packaging burden when they have to
>> manually deselect some drivers from their
On 05/20/2013 04:54:53 PM, Linus Torvalds wrote:
So it's been just over a week, and -rc2 is out.
For being an -rc2, it's not unreasonably sized, but I did take a few
pulls that I wouldn't have taken later in the rc series. So it's not
exactly small either. We've got arch updates (PPC, MIPS,
Hi Catalin,
On 2013/05/22 18:47, Catalin Marinas wrote:
> On Wed, May 22, 2013 at 03:37:17AM +0100, Damian Hobson-Garcia wrote:
>> Hello,
>> On 2013/04/30 12:01, Damian Hobson-Garcia wrote:
>>> Most architectures that define CONFIG_HAVE_DMA=y, have implementations for
>>> both dma_alloc_attrs()
On 05/22/2013 04:46 PM, Viresh Kumar wrote:
Sorry for being late buddy..
On 16 May 2013 11:44, Xiaoguang Chen wrote:
On 05/13/2013 06:47 PM, Xiaoguang Chen wrote:
Why is the mail came this way.. You forwarded it?
I didn't see your reponse, So I once replied this mail once.:)
cpufreq
On Thu, May 23, 2013 at 12:28 AM, Takashi Iwai wrote:
> When a system goes to reboot/shutdown, it tries to disable the
> usermode helper via usermodehelper_disable(). This might be blocked
> when a driver tries to load a firmware beforehand and it's stuck by
> some reason. For example, dell_rbu
Hi Arnaldo,
Good to see you :)
On Wed, 22 May 2013 11:52:15 +0200, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 22, 2013 at 05:27:36PM +0900, Namhyung Kim escreveu:
>> From: Namhyung Kim
>>
>> Add a new column for showing callchain overhead. I feel like it's
>> more natural than having those
On Wed, 2013-05-22 at 20:46 +0200, Michael Großhäuser wrote:
> Zhang Rui wrote:
>
> > On Wed, 2013-05-15 at 12:26 +0800, Zhang Rui wrote:
> >> please
> >>
> >> On Tue, 2013-05-14 at 21:18 -0700, Sonny Rao wrote:
> >> > Hi, I've seen a regression in kernels since 3.7 on x86 devices where
> >> >
On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
> Some drivers can be built on more platforms than they run on. This
> causes users and distributors packaging burden when they have to
> manually deselect some drivers from their allmodconfigs. Or sometimes
> it is even impossible to
On Tue, 2013-05-21 at 10:31 +0900, jonghwa3@samsung.com wrote:
> On 2013년 05월 21일 00:57, Zhang, Rui wrote:
>
> >
> >
> >> -Original Message-
> >> From: Jonghwa Lee [mailto:jonghwa3@samsung.com]
> >> Sent: Saturday, May 18, 2013 5:51 PM
> >> To: linux...@vger.kernel.org
> >> Cc:
Without this memory barrier, the file-storage thread may fail to
escape from the following while loop, because it may observe new
common->thread_wakeup_needed and old bh->state which are updated by
the callback functions.
/* Wait for the CBW to arrive */
while (bh->state !=
于 2013年05月22日 20:59, Arnd Bergmann 写道:
> On Wednesday 22 May 2013, Huang Shijie wrote:
>> 于 2013年05月21日 13:43, Shawn Guo 写道:
>>> It seems we can find it out from "reg" property, so that we can save
>>> this property?
>>>
>> we may have several devices attaching to the weim, each device has its
>>
On 05/22/2013 10:55 PM, Mike Galbraith wrote:
> On Wed, 2013-05-22 at 17:25 +0800, Michael Wang wrote:
>
>> I've not test the hackbench with wakeup-buddy before, will do it this
>> time, I suppose the 15% illegal income will suffered, anyway, it's
>> illegal :)
>
Thanks, Mike, these are very
On Tue, 2013-05-21 at 12:40 +0900, jonghwa3@samsung.com wrote:
> On 2013년 05월 21일 01:00, Zhang, Rui wrote:
>
> >
> >
> >> -Original Message-
> >> From: Jonghwa Lee [mailto:jonghwa3@samsung.com]
> >> Sent: Saturday, May 18, 2013 5:51 PM
> >> To: linux...@vger.kernel.org
> >> Cc:
Hi Mel & Seth,
On 05/21/2013 04:10 PM, Mel Gorman wrote:
> On Mon, May 20, 2013 at 10:42:25AM -0500, Seth Jennings wrote:
>> On Mon, May 20, 2013 at 02:54:39PM +0100, Mel Gorman wrote:
>>> On Sun, May 19, 2013 at 03:52:19PM -0500, Seth Jennings wrote:
My first guess is that the external
Change log:
v2->v3
- Fix the RCU lock problem found by Al Viro.
- Rebase the code to the latest v3.10-rc1 linux mainline.
- Remove patch 4 which may be problematic if the dentry is deleted.
- Rerun performance measurement using 3.10-rc1 kernel.
v1->v2
- Include performance improvement in
The d_path() and related kernel functions currently take a writer
lock on rename_lock because they need to follow pointers. By changing
rename_lock to be the new sequence read/write lock, a reader lock
can be taken and multiple d_path() threads can proceed concurrently
without blocking each other.
On Mon, May 20, 2013 at 03:46:59PM +0200, Laurent Pinchart wrote:
> Hi Axel,
>
> Thank you for the patch.
>
> On Monday 20 May 2013 21:45:41 Axel Lin wrote:
> > Signed-off-by: Axel Lin
>
> Acked-by: Laurent Pinchart
Thanks. I have queued this up for v3.11 in the pinmux branch
of my renesas
The current sequence lock supports 2 types of lock users:
1. A reader who wants a consistent set of information and is willing
to retry if the information changes. The information that the
reader needs cannot contain pointers, because any writer could
invalidate a pointer that a reader
The current code takes the dentry's d_lock lock whenever the d_count
reference count is being updated. In reality, nothing big really
happens until d_count goes to 0 in dput(). So it is not necessary to
take the lock if the reference count won't go to 0.
Without using a lock, multiple threads may
On 05/23/2013 05:18 AM, Andrew Morton wrote:
> On Fri, 10 May 2013 18:12:26 +0800 Chen Gang wrote:
>
>> >
>> > If both 'tree' and 'watch' are valid, need call audit_put_tree(), just
>> > like the upper area has done within function audit_add_rule().
>> >
>> > Signed-off-by: Chen Gang
>> > ---
From: Sukadev Bhattiprolu
Date: Wed, 22 May 2013 17:42:38 -0700
Subject: [PATCH] Rename cpu_map__all() to cpu_map__empty().
The CPU map is in an "empty" (or not-applicable) state when monitoring
specific threads.
cpu_map__all() returns true if the CPU map is in this empty state (i.e
for the
On 2013/5/23 6:29, David Brown wrote:
> On Wed, May 22, 2013 at 01:58:39PM +0800, Libo Chen wrote:
>
>> > ping...
> This is the first I've seen this patch. The original appears to have
> been sent to Andrew Morton and lkml. I'll reply with an Ack there.
>
> David
Regards
Libo
--
To
On 05/15/2013 02:51 PM, John Stultz wrote:
On 05/15/2013 02:38 PM, Todd Poynor wrote:
Add support for clocks CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM,
thereby enabling wakeup alarm timers via file descriptors.
Signed-off-by: Todd Poynor
This all looks great to me and has been on my own
Currently save_microcode_in_initrd() is declared in vendor neutural
microcode.h file, but defined in vendor specific
microcode_intel_early.c file. Vendor abstract it out to
microcode_core_early.c with a wrapper function.
Signed-off-by: Jacob Shin
---
arch/x86/include/asm/microcode_intel.h |
The following patchset adds early microcode patch loading support on
AMD systems, on top of the framework introduced by:
https://lkml.org/lkml/2012/12/21/193
Jacob Shin (2):
x86/microcode: vendor abstract out save_microcode_in_initrd()
x86/microcode: early microcode patch loading support on
Add support for early microcode patch loading on AMD.
Signed-off-by: Jacob Shin
---
arch/x86/Kconfig | 14 +-
arch/x86/include/asm/microcode_amd.h | 14 ++
arch/x86/kernel/microcode_amd.c| 335
On Wed, May 22, 2013 at 11:00:51AM +0200, Peter Zijlstra wrote:
> On Wed, May 22, 2013 at 01:31:08AM -0700, David Miller wrote:
> > From: Peter Zijlstra
> > Date: Wed, 22 May 2013 09:54:38 +0200
> >
> > > On Wed, May 22, 2013 at 02:50:30PM +0900, Simon Horman wrote:
> > >> Add a helper that for
During resume, we call hpet_rtc_timer_init after masking an irq bit in hpet.
This will cause the call to hpet_disable_rtc_channel to be undone if RTC_AIE is
the only bit not masked.
Signed-off-by: Derek Basehore
---
drivers/rtc/rtc-cmos.c | 5 -
1 file changed, 4 insertions(+), 1
On Wed, May 22, 2013 at 01:09:52PM -0700, H. Peter Anvin wrote:
> Dave Jones wrote:
>
> >On Wed, May 22, 2013 at 12:03:04PM -0700, H. Peter Anvin wrote:
> > > On 05/21/2013 04:03 PM, Dave Jones wrote:
> > > > In 3.10-rc2 I see this happening..
> > > >
> > > > [ 72.318133] microcode:
On 05/23/2013 12:19 AM, Peter Zijlstra wrote:
> On Wed, May 22, 2013 at 02:33:17PM +0100, Russell King - ARM Linux wrote:
>> > On Wed, May 22, 2013 at 11:11:56AM +0200, Peter Zijlstra wrote:
>>> > > On Mon, May 20, 2013 at 03:48:53PM +0800, Chen Gang wrote:
> > >
> > > When neither
On Thu, May 23, 2013 at 07:17:37AM +0900, Tejun Heo wrote:
> > No, it doesn't. You can use SCM_RIGHTS, and pass a file descriptor for
> > the device node to an unprivileged program. You can choose the
> > users/groups that are allowed to access the device. In either case, the
> > privileged
Hi Igor,
On Wed, 22 May 2013 15:53:32 +0200 Igor Mammedov wrote:
>
> after fixing conflict between
> 0902a9044 "Driver core: Use generic offline/online
> for CPU offline/online"
>
> and
>
> 1c4e2d70a "cpu: make sure that cpu/online file created
> before KOBJ_ADD is emitted"
>
> there was left
This cleans up the gpio-msm-v2 driver of all the global define usage.
The number of gpios are now defined in the device tree. This enables
adding irqdomain support as well.
Signed-off-by: Rohit Vaswani
---
.../devicetree/bindings/gpio/gpio-msm.txt | 26 +++
MSM_TLMM_BASE is currently not mapped by 8x60. Remove it.
Signed-off-by: Rohit Vaswani
---
arch/arm/mach-msm/include/mach/msm_iomap-8x60.h |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
Remove gpiomux-v2 as it's not being used and make way for future improvements.
Signed-off-by: Rohit Vaswani
---
arch/arm/mach-msm/Kconfig| 13 +++-
arch/arm/mach-msm/Makefile |6 +--
arch/arm/mach-msm/gpiomux-8x60.c | 19
arch/arm/mach-msm/gpiomux-v2.c |
Hi Linus,
Could this series go through David's tree or is there a better way to do this?
It would be great if I can have you ack for the gpio patch.
Thanks,
Rohit
Rohit Vaswani (3):
ARM: msm: Remove gpiomux-v2 and re-organize MSM_GPIOMUX configs
ARM: msm: Remove unused and unmapped
ping ...
在 2013-04-25四的 15:00 +0800，liguang写道：
> seems we should comment DEBUG as above comment said:
> "/* un-comment DEBUG to enable pr_debug() statements */"
>
> now, pr_debug is already enabled as DEBUG been defined.
>
> Signed-off-by: liguang
> ---
> drivers/idle/intel_idle.c |2 +-
>
ping ...
again.
在 2013-02-25一的 10:38 +0800，liguang写道：
> just do some trivial changes to make acpi's numa info
> operation more cleaner.
>
> ChangeLog
>
> v3->v4
> 1.fix srat_disabled function
> spotted by Yasuaki Ishimatsu
>
> v2->v3
> 1. rebase on linux-next
> 2. bring back lost
> In any case while letting it run I got the following OOPS on
> Linux 3.10-rc2
Included below is test code (based on the fuzzer output) that reliably
OOPSes my core2 machine. It's a bit long, but I'm remote from the
machine now so I can't refine it (as the code locked up the machine the
These registers have been documented since the driver was originally
submitted so expose them.
Signed-off-by: Mark Brown
---
I'll add this to the pull request I sent yesterday.
drivers/mfd/wm5110-tables.c |8
include/linux/mfd/arizona/registers.h |3 +++
2 files
Commit bfd428d ("net: ethernet: sun: initialize variables directly")
dropped the only loop that was using i but did not remove the actual
variable, therefore causing a warning when building. This patch drops
the now redundant line.
Reported-by: Stephen Rothwell
Signed-off-by: Emilio López
---
Commit e998fd4 ("net: ethernet: korina: initialize variables directly")
dropped the only loop that was using i but did not remove the actual
variable, therefore causing a warning when building. This patch drops
the now redundant line.
Signed-off-by: Emilio López
---
Commit 3b0aaef ("net: ethernet: apple: initialize variables directly")
dropped the only loop that was using i but did not remove the actual
variable, therefore causing a warning when building. This patch drops
the now redundant line.
Signed-off-by: Emilio López
---
On Thu, May 23, 2013 at 08:09:33AM +1000, Dave Chinner wrote:
> On Wed, May 22, 2013 at 12:19:46PM -0400, Dave Jones wrote:
> > On Wed, May 22, 2013 at 10:22:52AM -0400, Dave Jones wrote:
> > > On Wed, May 22, 2013 at 03:51:47PM +1000, Dave Chinner wrote:
> > >
> > > > > Tomorrow I'll
This reduces the size of the stack frame when calling request_module().
Performing the sprintf before the call is not needed.
Signed-off-by: Kees Cook
---
drivers/mtd/chips/gen_probe.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/chips/gen_probe.c
The mm-of-the-moment snapshot 2013-05-22-16-40 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Wed, 22 May 2013, Kent Yoder wrote:
> Signed-off-by: Kent Yoder
> ---
> v2: Replace Kent with other so that NX isn't unmaintained,
> leave tpmdd-devel as maintainer for TPM
>
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
I already applied your first patch.
On Wed, 22 May 2013, Kent Yoder wrote:
>
> Signed-off-by: Kent Yoder
Applied.
--
James Morris
--
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 http://vger.kernel.org/majordomo-info.html
On Wed, 2013-05-22 at 23:16 +0300, Or Gerlitz wrote:
[...]
> all in all, we will look into returning -EPROBE_DEFER from the VF
> when they identify the problematic situation -- so for how much time
> this is deferred? or if this isn't time based what the logical
> condition which once met the VF
On Wed, 22 May 2013, Kent Yoder wrote:
> Hi James,
>
> The following changes since commit 4726e8fa1dcad533362475ebf91f70d5b6b6292f:
>
> security: clarify cap_inode_getsecctx description (2013-05-12 21:32:38
> +1000)
>
> are available in the git repository at:
>
>
Ted,
Do you have a status for this patch?
Thanks,
Paul
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Wed, 2013-05-22 at 00:20 -0700, Andrew Morton wrote:
> > +#ifdef CONFIG_SMP
> > +extern int vm_committed_as_batch;
> > +
> > +static inline void mm_compute_batch(void)
> > +{
> > +int nr = num_present_cpus();
> > +int batch = max(32, nr*2);
> > +
> > +/* batch size set
23.05.2013 02:22, Andrew Morton пишет:
> On Sun, 12 May 2013 18:25:06 +0400 Dmitry Osipenko wrote:
>
>> Use device_init_wakeup() instead of device_set_wakeup_capable() and move it
>> before rtc dev registering. This fixes issue with alarmtimer that checks
>> wakeup
>> capability with
On Wednesday, May 22, 2013 02:59:11 PM Jiri Slaby wrote:
> From: Vasiliy Kulikov
>
> User space pointer may not be dereferenced. Use get_user()/put_user()
> instead and check their return codes.
>
> Signed-off-by: Vasiliy Kulikov
> Signed-off-by: Thomas Renninger
> Signed-off-by: Jiri Slaby
Use device_init_wakeup() instead of device_set_wakeup_capable() and move it
before rtc dev registering. This fixes alarmtimer not registered when tps6586x
rtc is the only wakeup compatible rtc in the system.
Signed-off-by: Dmitry Osipenko
---
V2: changed description
drivers/rtc/rtc-tps6586x.c
On Wednesday, May 22, 2013 03:14:43 PM Greg Kroah-Hartman wrote:
> On Thu, May 23, 2013 at 12:06:50AM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > As noted by Tang Chen, the last_online field in struct memory_block
> > introduced by commit 4960e05 (Driver core: Introduce
This is the backported patch I submitted previously. Hopefully this
time around it won't be too messed up, I'm using Thunderbird instead of
the web interface. I have applied it successfully and without warnings
against 3.4.46. It builds, but is otherwise untested beyond what I did
when I
On Wed, 22 May 2013 15:43:22 -0700, Andrew Morton wrote:
> On Wed, 22 May 2013 17:04:16 -0400 J__rn Engel wrote:
>
> > > > Documentation/block/blockconsole.txt| 94
> > > > Documentation/block/blockconsole/bcon_tail | 62 +++
> > > >
On Wed, 22 May 2013 17:04:16 -0400 J__rn Engel wrote:
> > > Documentation/block/blockconsole.txt| 94
> > > Documentation/block/blockconsole/bcon_tail | 62 +++
> > > Documentation/block/blockconsole/mkblockconsole | 29 ++
> >
> > We really need somewhere better to
On 05/22/2013 03:32 PM, Aaro Koskinen wrote:
Hi,
On Thu, May 02, 2013 at 01:48:12PM -0700, David Daney wrote:
From: David Daney
As noted by Thomas Gleixner:
commit cdbedc61c8 (mips: Use generic idle loop) broke MIPS as I did
not realize that MIPS wants to invoke the wait
On Wed, 22 May 2013 13:48:22 -0700, Andrew Morton wrote:
> On Thu, 9 May 2013 16:43:00 -0400 Joern Engel wrote:
>
> > Console driver similar to netconsole, except it writes to a block
> > device. Can be useful in a setup where netconsole, for whatever
> > reasons, is impractical.
>
> It would
On Wed, May 22, 2013 at 02:54:57PM -0700, Jay Vosburgh wrote:
> Smart Weblications GmbH - Florian Wiessner wrote:
>
> >Am 22.05.2013 22:04, schrieb Greg KH:
> >
> >
> >>>
> >>>
Hi,
On Thu, May 02, 2013 at 01:48:12PM -0700, David Daney wrote:
> From: David Daney
>
> As noted by Thomas Gleixner:
>
>commit cdbedc61c8 (mips: Use generic idle loop) broke MIPS as I did
>not realize that MIPS wants to invoke the wait instructions with
>interrupts enabled.
>
>
1 - 100 of 1464 matches
Mail list logo
