s error using existing fallback oom_cfqq.
>
> Signed-off-by: Konstantin Khlebnikov
> ---
> block/cfq-iosched.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Looks good to me. Thanks for the patch.
Acked-by: Vivek Goyal
Vivek
>
> diff --git a/block/cfq-io
On Wed, Jan 28, 2015 at 10:10:59PM +, Scot Doyle wrote:
> On Wed, 28 Jan 2015, Vivek Goyal wrote:
> > On Wed, Jan 28, 2015 at 09:14:03PM +, Scot Doyle wrote:
> > > On Wed, 28 Jan 2015, Vivek Goyal wrote:
> > > > On Wed, Jan 28, 2015 at 04:49:34PM +01
On Wed, Jan 28, 2015 at 09:14:03PM +, Scot Doyle wrote:
> On Wed, 28 Jan 2015, Vivek Goyal wrote:
> > On Wed, Jan 28, 2015 at 04:49:34PM +0100, Michael Kerrisk (man-pages) wrote:
> > > Hello Vivek,
> > >
> > > >> I've made various adjust
On Wed, Jan 28, 2015 at 09:04:38AM +0100, Michael Kerrisk (man-pages) wrote:
Hi Michael,
[..]
> >> * the number of bytes copied from userspace is min(bufsz, memsz)
> >
> > Yes. bufsz can not be more than memsz. There is a check to validate
> > this in kernel.
> >
> > result = -EINVAL;
> >
On Wed, Jan 28, 2015 at 04:49:34PM +0100, Michael Kerrisk (man-pages) wrote:
> [Dropping Andi into CC, which I should have done to start with, since
> he wrote the original page, and might also have some comments]
>
> Hello Vivek,
>
> >> I've made various adjustments to the page in the light of y
On Fri, Jan 16, 2015 at 02:30:25PM +0100, Michael Kerrisk (man-pages) wrote:
[..]
>
Hi Michael,
Please find my responses below. Sorry, I got stuck in other work and
forgot about this thread.
> So, returning to the kexeec_segment structure:
>
>struct kexec_segment {
>
On Wed, Jan 07, 2015 at 10:17:56PM +0100, Michael Kerrisk (man-pages) wrote:
[..]
> >> .BR KEXEC_ON_CRASH " (since Linux 2.6.13)"
> >> Execute the new kernel automatically on a system crash.
> >> .\" FIXME Explain in more detail how KEXEC_ON_CRASH is actually used
>
> I wasn't expecting that you
On Mon, Jan 12, 2015 at 05:06:46PM +0100, Joerg Roedel wrote:
> On Mon, Jan 12, 2015 at 10:29:19AM -0500, Vivek Goyal wrote:
> > Kdump has the notion of backup region. Where certain parts of old kernels
> > memory can be moved to a different location (first 640K on x86 as of n
On Mon, Jan 12, 2015 at 04:22:08PM +0100, Joerg Roedel wrote:
> On Mon, Jan 12, 2015 at 03:06:20PM +0800, Li, Zhen-Hua wrote:
> > +
> > +#ifdef CONFIG_CRASH_DUMP
> > +
> > +/*
> > + * Fix Crashdump failure caused by leftover DMA through a hardware IOMMU
> > + *
> > + * Fixes the crashdump kernel to
On Fri, Jan 02, 2015 at 12:48:51PM -0600, Eric W. Biederman wrote:
> Alexander Kuleshov writes:
>
> > Signed-off-by: Alexander Kuleshov
> Acked-by: "Eric W. Biederman"
[ CC akpm ]
Simple fix.
Acked-by: Vivek Goyal
Thanks
Vivek
>
> > ---
> > kern
On Wed, Nov 26, 2014 at 02:17:09PM +, David Howells wrote:
>
> Here's a set of patches that does the following:
>
I compiled the kernel with these patches and booted into this kernel
without any issues.
FWIW,
Tested-by: Vivek Goyal
Thanks
Vivek
> (1) Extracts both
On Thu, Nov 20, 2014 at 04:54:14PM +, David Howells wrote:
[..]
> @@ -215,21 +219,42 @@ static int pkcs7_verify_sig_chain(struct pkcs7_message
> *pkcs7,
> /* Look through the X.509 certificates in the PKCS#7 message's
>* list to see if the next one is there.
>
On Thu, Nov 20, 2014 at 04:54:03PM +, David Howells wrote:
[..]
> diff --git a/crypto/asymmetric_keys/x509_parser.h
> b/crypto/asymmetric_keys/x509_parser.h
> index 3dfe6b5d6f0b..223b72344060 100644
> --- a/crypto/asymmetric_keys/x509_parser.h
> +++ b/crypto/asymmetric_keys/x509_parser.h
> @@
Tejun Heo
> Cc: Jens Axboe
> Cc: Vivek Goyal
> ---
> block/bio.c | 24 +++-
> include/linux/bio.h |3 +++
> 2 files changed, 26 insertions(+), 1 deletion(-)
>
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -1981,6 +1981,
ssociated with an online css for every subsystem except
> while the css_set update is propagating, task_get_css() retries till
> css_tryget_online() succeeds.
>
> This is a cleanup and shouldn't lead to noticeable behavior changes.
>
> Signed-off-by: Tejun Heo
> Cc: Li
On Mon, Nov 17, 2014 at 04:13:57PM -0500, Tejun Heo wrote:
[..]
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -1408,6 +1408,9 @@ int kblockd_schedule_delayed_work(struct
> int kblockd_schedule_delayed_work_on(int cpu, struct delayed_work *dwork,
> unsigned long delay);
>
>
On Mon, Nov 17, 2014 at 04:13:21PM -0500, Tejun Heo wrote:
> cgroup aware writeback support will require exposing some of blkcg
> details. In preprataion, move block/blk-cgroup.h to
> include/linux/blk-cgroup.h. This patch is pure file move.
>
> Signed-off-by: Tejun Heo
&g
On Thu, Nov 20, 2014 at 11:10:55AM -0500, Dave Jones wrote:
> On Wed, Nov 19, 2014 at 11:28:06AM -0500, Vivek Goyal wrote:
>
> > I am wondering may be in some cases we panic in second kernel and sit
> > there. Probably we should append a kernel command line automatically
>
On Thu, Nov 20, 2014 at 11:10:55AM -0500, Dave Jones wrote:
> On Wed, Nov 19, 2014 at 11:28:06AM -0500, Vivek Goyal wrote:
>
> > I am wondering may be in some cases we panic in second kernel and sit
> > there. Probably we should append a kernel command line automatically
>
On Wed, Nov 19, 2014 at 10:38:52AM -0500, Dave Jones wrote:
> On Wed, Nov 19, 2014 at 10:03:33AM -0500, Vivek Goyal wrote:
>
> > Not being able to capture the dump I can understand but having wedged
> > the machine so that it does not reboot after dump failure sounds bad.
>
On Wed, Nov 19, 2014 at 09:41:05AM -0500, Don Zickus wrote:
> On Tue, Nov 18, 2014 at 05:02:54PM -0500, Dave Jones wrote:
> > On Tue, Nov 18, 2014 at 04:55:40PM -0500, Don Zickus wrote:
> >
> > > > So here we mangle CPU3 in and lose the backtrace for cpu0, which might
> > > > be the real interes
On Fri, Nov 14, 2014 at 10:31:33AM +0900, HATAYAMA Daisuke wrote:
> From: Vivek Goyal
> Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in
> VMCOREINFO
> Date: Thu, 13 Nov 2014 09:25:48 -0500
>
> > On Thu, Nov 13, 2014 at 05:30:21PM +0900, HA
On Thu, Nov 13, 2014 at 05:30:21PM +0900, HATAYAMA, Daisuke wrote:
>
>
> (2014/11/13 17:06), Petr Tesarik wrote:
> >On Thu, 13 Nov 2014 09:17:09 +0900 (JST)
> >HATAYAMA Daisuke wrote:
> >
> >>From: Vivek Goyal
> >>Subject: Re: [PATCH] kd
On Wed, Nov 12, 2014 at 03:40:42PM +0900, HATAYAMA Daisuke wrote:
> Currently, VMCOREINFO note information reports the virtual address of
> phys_base that is assigned to symbol phys_base. But this doesn't make
> sense because to refer to value of the phys_base, it's necessary to
> get the value of
On Sun, Nov 09, 2014 at 08:17:49PM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Vivek (and all),
>
> Thanks for the kexec_file_load() patch [for the kexec_load(2) man page]
> that you quite some time ago sent. I have merged it and done some
> substantial editing as well. Could you please take
On Thu, Nov 06, 2014 at 01:57:36PM -0800, David Rientjes wrote:
[..]
> You see that doing
>
> if (panic_on_warn) {
> panic_on_warn = 0;
> panic(...);
> }
>
> is racy, I hope. If two threads WARN() at the same time, then there's
> nothing preventing a dou
On Fri, Oct 31, 2014 at 12:18:54PM -0700, Aditya Kali wrote:
[..]
> fs/kernfs/dir.c | 194
> ++-
> fs/kernfs/mount.c| 48 ++
> fs/proc/namespaces.c | 1 +
> include/linux/cgroup.h | 41 -
On Mon, Nov 03, 2014 at 09:32:23AM -0500, Prarit Bhargava wrote:
[..]
> +
> +static int __init panic_on_warn_setup(char *s)
> +{
> + /* Enabling this on a kdump kernel could cause a bogus panic. */
> + if (!is_kdump_kernel())
> + panic_on_warn = 1;
I think it would be better i
On Mon, Nov 03, 2014 at 08:32:42AM -0500, Prarit Bhargava wrote:
>
>
> On 10/30/2014 09:58 PM, Hedi Berriche wrote:
> > On Thu, Oct 30, 2014 at 17:06 Prarit Bhargava wrote:
> > | There have been several times where I have had to rebuild a kernel to
> > | cause a panic when hitting a WARN() in the
On Fri, Oct 31, 2014 at 10:42:51AM -0700, Andi Kleen wrote:
> > > +void __puthex(unsigned long value)
> > > +{
> > > + char alpha[2] = "0";
> > > + int bits;
> > > + unsigned char byte;
> >
> > what is 'byte' for? (unused)
>
> Well the whole function is unused. We don't normally add unused funct
On Tue, Oct 28, 2014 at 05:44:25AM -0700, Andi Kleen wrote:
> > > I suppose ... but that would mean I would have to explain to an end user
> > > the
> > > elaborate process of enabling kdb, inserting a break point, etc. The
> > > whole
> > > purpose of this is to let an end user panic on WARN()
On Tue, Oct 28, 2014 at 08:22:16AM -0400, Prarit Bhargava wrote:
>
>
> On 10/28/2014 08:16 AM, Andi Kleen wrote:
> > On Fri, Oct 24, 2014 at 08:53:27AM -0400, Prarit Bhargava wrote:
> >> There have been several times where I have had to rebuild a kernel to
> >> cause a panic when hitting a WARN()
t_phb_of_node
> >> decl")).
> >>
> >> Remove the "weak" attribute from the declarations so we always prefer a
> >> non-weak definition over the weak one, independent of link order.
> >>
> >> Fixes: be8a8d069e50 ("vmcore: introduce ELF he
On Wed, Oct 15, 2014 at 11:37:01AM +0800, Baoquan He wrote:
> On 10/14/14 at 08:49am, Vivek Goyal wrote:
> > On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
> > > On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote:
> > > > On 10/13/20
On Wed, Oct 15, 2014 at 10:14:31AM +0800, WANG Chao wrote:
> On 10/14/14 at 05:52pm, Vivek Goyal wrote:
> > On Tue, Oct 14, 2014 at 12:46:58PM +0800, WANG Chao wrote:
> > > Supress this unnecessary message during kernel re-build
> > > (CONFIG_KEXEC_FILE=y):
>
On Tue, Oct 14, 2014 at 12:46:58PM +0800, WANG Chao wrote:
> Supress this unnecessary message during kernel re-build
> (CONFIG_KEXEC_FILE=y):
>
> make[1]: `arch/x86/purgatory/kexec-purgatory.c' is up to date.
>
> Signed-off-by: WANG Chao
> ---
> arch/x86/purgatory/Makefile | 1 +
> 1 file chang
On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
> On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote:
> > On 10/13/2014 08:19 AM, Vivek Goyal wrote:
> > >>>
> > >>> This really shouldn't have happened this way on x86-64. It has
On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote:
> On 10/13/2014 08:19 AM, Vivek Goyal wrote:
> >>>
> >>> This really shouldn't have happened this way on x86-64. It has to happen
> >>> this way on i386, but I worry that this may be a se
On Mon, Oct 13, 2014 at 08:52:57AM -0400, Vivek Goyal wrote:
> On Sat, Oct 11, 2014 at 03:34:29AM -0700, H. Peter Anvin wrote:
> > On 10/10/2014 08:14 PM, Baoquan He wrote:
> > >On 10/08/14 at 03:27pm, Vivek Goyal wrote:
> > >>On Wed, Oct 08, 2014 at 08:09:59
On Sat, Oct 11, 2014 at 03:34:29AM -0700, H. Peter Anvin wrote:
> On 10/10/2014 08:14 PM, Baoquan He wrote:
> >On 10/08/14 at 03:27pm, Vivek Goyal wrote:
> >>On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
> >
> >>>Sorry... this makes no sense
gt; \# arch/x86/purgatory/purgatory.ro
>
> Add a .gitignore to block these files.
>
> Cc: x...@kernel.org
> Cc: Vivek Goyal
> Signed-off-by: Prarit Bhargava
[ CC akpm ]
Thanks Prarit.
Acked-by: Vivek Goyal
Vivek
> ---
> arch/x86/purgatory/.gitignore |2 ++
>
On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
> On 10/01/2014 06:52 AM, Vivek Goyal wrote:
> >
> > Hi Peter,
> >
> > I think there is some confusion. I will try to clarify.
> >
> > If we have 32bit signed overflow, we will not have
On Tue, Oct 07, 2014 at 12:21:30AM +, Geoff Levand wrote:
> linux/kexec.h now defines an IND_FLAGS macro. Remove the local powerpc
> definition and use the generic one.
>
> Signed-off-by: Geoff Levand
I think this patch should be merged in previous patch. I guess after
applying patch4, seri
On Tue, Oct 07, 2014 at 12:54:58PM +0900, Masanari Iida wrote:
> This patch remove unnecessary KERN_ERR from pr_err() within kexec.c.
>
> Signed-off-by: Masanari Iida
[cc akpm]
Thanks for the fix.
Acked-by: Vivek Goyal
Vivek
> ---
> kernel/kexec.c | 2 +-
> 1 file ch
ocation is chosen, then the relocation handling is needed.
> >
> > Signed-off-by: Baoquan He
> > Acked-by: Vivek Goyal
> > Acked-by: Kees Cook
> > Tested-by: Thomas D.
> > Cc: sta...@vger.kernel.org
>
> Could you clarify under what conditions we may e
On Mon, Sep 22, 2014 at 10:53:55PM -0400, CAI Qian wrote:
[..]
> > Why not simply let the respective service on the host do this job and
> > test only makes sure that kdump service is running. It feels little
> > out of place that a test is generating custom initramfs.
> Because not every distro w
e70acead ("resource: provide new functions to walk through
> resources")
One such problem was solved with following commit.
commit 800df627e2eabaf4a921d342a1d5162c843b7fc2
Author: Vivek Goyal
Date: Fri Aug 29 15:18:29 2014 -0700
resource: fix the case of null pointer acc
e70acead ("resource: provide new functions to walk through
> resources")
Hi Guenter,
Can you please provide backtrace of the crash.
Thanks
Vivek
> Cc: Vivek Goyal
> Cc: Andrew Morton
> Signed-off-by: Guenter Roeck
> ---
> The NULL check could be added elsewher
On Mon, Sep 22, 2014 at 09:00:00AM -0400, CAI Qian wrote:
>
>
> - Original Message -
> > From: "Vivek Goyal"
> > To: "CAI Qian"
> > Cc: "linux-kernel" , "ltp-list"
> > , "crash-utility"
> > , &qu
On Fri, Sep 19, 2014 at 05:52:25AM -0400, CAI Qian wrote:
> I plan to release an automated kdump testsuite that will be
So will this be a standalone test suit? Can it be merged with
something already existing say, LTP.
> focus on testing kernel and the crash utility. It should work
> for all majo
On Fri, Sep 19, 2014 at 09:22:36AM -0400, Vivek Goyal wrote:
> On Fri, Sep 19, 2014 at 05:52:25AM -0400, CAI Qian wrote:
> > I plan to release an automated kdump testsuite that will be
>
> So will this be a standalone test suit? Can it be merged with
> something already existi
age64_verify_sig'
was not declared. Should it be static?
arch/x86/kernel/kexec-bzimage64.c:546:23: warning: symbol 'kexec_bzImage64_ops'
was not declared. Should it be static?
CC: David Howells
Signed-off-by: Vivek Goyal
---
arch/x86/kernel/kexec-bzimage64.c | 15 ---
On Fri, Sep 12, 2014 at 05:56:12PM +0200, Thomas D. wrote:
> Hi,
>
> Vivek Goyal wrote:
> > You had reported kexec issues with CONFIG_RANDOMIZE_BASE=y. Does this
> > patch resolve the issue for you?
>
> Yup! Tested against kernel-3.16.2.
Thanks. Given this patch is
atch should make kexec and kdump working with kaslr
enabled (CONFIG_RANDOMIZE_BASE=y).
In case of kdump, we will need to pass "nokaslr" to make sure kernel
does not move from kexec chosen address.
In case of kexec, I think it should be ok to not pass "nokaslr". This
case is no different than any
On Fri, Sep 12, 2014 at 02:20:31PM +0800, Baoquan He wrote:
> Function handle_relocations() is used to do the relocations handling
> for i686 and kaslr of x86_64. For 32 bit the relocation handling is
> mandotary to perform. For x86_64 only when kaslr is enabled and a
> random kernel location is ch
On Fri, Sep 12, 2014 at 12:15:37AM +0200, Petr Tesarik wrote:
> On Thu, 11 Sep 2014 17:16:37 -0400
> Vivek Goyal wrote:
>
> > On Thu, Sep 11, 2014 at 10:43:30PM +0200, Petr Tesarik wrote:
> > > On Thu, 11 Sep 2014 16:01:10 -0400
> > > Vivek Goyal wrote:
> >
On Thu, Sep 11, 2014 at 10:43:30PM +0200, Petr Tesarik wrote:
> On Thu, 11 Sep 2014 16:01:10 -0400
> Vivek Goyal wrote:
>
> > On Fri, Sep 05, 2014 at 06:33:14PM +0200, Petr Tesarik wrote:
> > > On architectures that use percpu-vm, the percpu region is not guaranteed
&
On Fri, Sep 05, 2014 at 06:33:14PM +0200, Petr Tesarik wrote:
> On architectures that use percpu-vm, the percpu region is not guaranteed
> to be contiguous in physical space.
Petr,
Which are those arches?
> However, fs/proc/vmcore.c expects
> all ELF notes to be contiguous. If the ELF note happe
On Wed, Sep 10, 2014 at 11:27:16PM +0800, Baoquan He wrote:
> On 09/10/14 at 11:05am, Vivek Goyal wrote:
> > On Wed, Sep 10, 2014 at 07:41:38AM -0700, Kees Cook wrote:
> > > On Wed, Sep 10, 2014 at 7:30 AM, Vivek Goyal wrote:
> > > > So I would suggest that test a
s patch and remove __kexec_add_segment()
> since no one use it anymore.
>
> Signed-off-by: Baoquan He
Bao,
These 3 patches look good to me. I am assuming you have tested these
to make sure nothing is broken.
Acked-by: Vivek Goyal
Thanks
Vivek
> ---
> include/linux/kexec.h |
On Wed, Sep 10, 2014 at 07:41:38AM -0700, Kees Cook wrote:
> On Wed, Sep 10, 2014 at 7:30 AM, Vivek Goyal wrote:
> > So I would suggest that test and repost the other patch with proper
> > changelog
> > and that might be sufficient for now. Only other thing we will need is
On Wed, Sep 10, 2014 at 10:53:34PM +0800, Baoquan He wrote:
> On 09/10/14 at 10:30am, Vivek Goyal wrote:
> > On Wed, Sep 10, 2014 at 03:21:15PM +0800, Baoquan He wrote:
>
>
> > > In fact, I think below checking will be clearer and works too.
> > >
> >
On Wed, Sep 10, 2014 at 03:21:15PM +0800, Baoquan He wrote:
> On 09/09/14 at 03:28pm, Vivek Goyal wrote:
> > On Tue, Sep 09, 2014 at 08:53:29AM -0700, Kees Cook wrote:
>
> > > I still think this needs a test for the 32-bit case, since IUIC, it
> > > requir
On Wed, Sep 10, 2014 at 02:10:35PM +0800, Baoquan He wrote:
[..]
> > > diff --git a/arch/x86/boot/compressed/misc.c
> > > b/arch/x86/boot/compressed/misc.c
> > > index 57ab74d..887f404 100644
> > > --- a/arch/x86/boot/compressed/misc.c
> > > +++ b/arch/x86/boot/compressed/misc.c
> > > @@ -230,8 +
On Fri, Sep 05, 2014 at 10:08:17PM +0800, Baoquan He wrote:
> Now kaslr makes kernel image size changable, not the fixed size 512M.
> So KERNEL_IMAGE_SIZE need be exported to VMCOREINFO, otherwise makedumfile
> will crash.
>
> Signed-off-by: Baoquan He
This one sounds reasonable. CCing Atshushi.
On Fri, Sep 05, 2014 at 10:32:56AM -0700, Kees Cook wrote:
> On Fri, Sep 05, 2014 at 10:08:16PM +0800, Baoquan He wrote:
> > From: Dave Young
> >
> > X86 will pass setup_data region while necessary, these regions could be
> > overwitten by kernel due to kaslr.
> >
> > Thus iterate and add setup
On Sat, Sep 06, 2014 at 06:16:57AM +0800, Baoquan He wrote:
> On 09/05/14 at 10:16am, Kees Cook wrote:
> > On Fri, Sep 5, 2014 at 7:08 AM, Baoquan He wrote:
> > > diff --git a/arch/x86/boot/compressed/misc.c
> > > b/arch/x86/boot/compressed/misc.c
> > > index 7780a5b..d2a0eaa 100644
> > > --- a/a
On Tue, Sep 09, 2014 at 08:53:29AM -0700, Kees Cook wrote:
> On Mon, Sep 8, 2014 at 11:24 PM, Baoquan He wrote:
> > On 09/05/14 at 10:11am, Kees Cook wrote:
> >> I don't think this is correct. If you look at a02150610776 ("x86,
> >> relocs: Move ELF relocation handling to C"), we always did reloca
blkcg->css.serial_nr. Rename cfq_cgroup->blkcg_id to
> ->blkcg_serial_nr and @id in check_blkcg_changed() to @serial_nr for
> consistency.
>
> Signed-off-by: Tejun Heo
> Cc: Vivek Goyal
Looks good to me.
Acked-by: Vivek Goyal
Vivek
> ---
> block/blk-cgroup.c |
On Tue, Aug 26, 2014 at 05:33:28PM -0700, Geoff Levand wrote:
> Hi Vivek,
>
> On Mon, 2014-08-25 at 12:59 -0400, Vivek Goyal wrote:
> > Does arm64 has secureboot? If yes, then it might make sense to
> > enable the new syscall kexec_file_load() on arm64 instead of trying
&g
On Fri, Aug 22, 2014 at 06:37:10PM -0500, Michael Welling wrote:
> Without this patch the kexec-purgatory.c and purgatory.ro files are not
> removed after make mrproper.
>
> Signed-off-by: Michael Welling
Looks good to me.
Acked-by: Vivek Goyal
Vivek
> ---
> arch/x
ec kimage_entry items.
>
> Signed-off-by: Geoff Levand
Acked-by: Vivek Goyal
Vivek
> ---
> include/linux/kexec.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 8c628ca..a4758f9 100644
> --- a/include/l
te on the kimage entry list. The addition of
> these bit position macros in a common location will avoid duplicate
> definitions
> and the chance that changes to the IND_* flags will not be propagated to
> assembly files.
>
> Signed-off-by: Geoff Levand
Looks good to me.
Acked-by:
change switches the
> order of the conditional check, and cleans up the comments for the
> conditional. There is no functional change to the code.
>
> Signed-off-by: Geoff Levand
This is simple reorganization.
Acked-by: Vivek Goyal
Vivek
> ---
> kernel/kexec.c | 17 ++
On Fri, Aug 22, 2014 at 06:39:47PM +, Geoff Levand wrote:
> Remove the unneded declaration for a kexec_load() routine.
>
> Fixes errors like these when running 'make headers_check':
>
> include/uapi/linux/kexec.h: userspace cannot reference function or variable
> defined in the kernel
>
> S
On Fri, Aug 22, 2014 at 06:39:47PM +, Geoff Levand wrote:
> Hi,
>
> Here are a few minor fixups and enhancements for kexec support.
>
> Patch 3 and 4 that add preprocessor macros for the kimage list flags are
> ones that I use in the arm64 kexec support I am working on, so it would
> be nice
by: Thomas Glanzmann
Suggested-by: H. Peter Anvin
Signed-off-by: Vivek Goyal
---
arch/x86/purgatory/Makefile |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/arch/x86/purgatory/Makefile
===
--- linux-2.6.orig/arch/x86
On Wed, Aug 20, 2014 at 10:07:01AM -0500, H. Peter Anvin wrote:
> It says "32-bit mode" which means it is another issue: we are dropping -m64
> at some point.
Thanks hpa. I am not adding -m64 to kbuild flags at all. So 32bit tool
chain must be assuming -m32 by default, and probably that's the iss
2
>
> 08:10 < TJ-> Glanzmann: The purgatory code from kexec is specifying ".code64"
> 08:11 < TJ-> Glanzmann: so when your local 32-bit linker tries to deal with
> that ... it errors
> 08:14 < TJ-> Glanzmann: there's only one introducing the purgatory stu
On Mon, Aug 18, 2014 at 06:40:10PM +0100, Russell King - ARM Linux wrote:
> On Mon, Aug 18, 2014 at 01:15:40PM -0400, Vivek Goyal wrote:
> > On Fri, Aug 15, 2014 at 02:55:20PM +0100, Will Deacon wrote:
> > > What I meant was, if I wire it into asm-generic/unistd.h then it
On Thu, Aug 14, 2014 at 05:55:32PM +0800, HuKeping wrote:
>
>
> Add arm specific parts to kdump kernel documentation.
>
> v2 -> v3
> - fix some spelling mistakes
>
> Signed-off-by: Hu Keping
> ---
Acked-by: Vivek Goyal
On Fri, Aug 15, 2014 at 02:55:20PM +0100, Will Deacon wrote:
> On Tue, Aug 12, 2014 at 01:37:36PM +0100, Vivek Goyal wrote:
> > On Tue, Aug 12, 2014 at 12:10:30PM +0100, Will Deacon wrote:
> > > Hmm, so whilst I can easily wire-up the new syscall, it's pretty useless
> &
is
not recursive.
Signed-off-by: Vivek Goyal
---
arch/x86/Kbuild| 4 +---
arch/x86/Kconfig | 18 ++
arch/x86/Makefile | 5 +
arch/x86/kernel/Makefile | 2 +-
arch/x86/kernel/crash.c|
: Vivek Goyal
---
arch/arm/Kconfig | 2 --
arch/ia64/Kconfig| 2 --
arch/m68k/Kconfig| 2 --
arch/mips/Kconfig| 2 --
arch/powerpc/Kconfig | 2 --
arch/s390/Kconfig| 2 --
arch/sh/Kconfig | 2 --
arch/tile/Kconfig| 2 --
8 files changed, 16 deletions(-)
diff --git a/arch
on is introduced, now CONFIG_KEXEC does not have to
select CRYPTO. So I have put in a patch to remove select CRYPTO=y
from all the arches.
Thanks
Vivek
Vivek Goyal (2):
kexec: Create a new config option CONFIG_KEXEC_FILE for new syscall
kexec: Remove CONFIG_KEXEC dependency on crypto
arch/arm/Kc
#x27;s
> safe just use "if (crashk_low_res.end)" to check if it's exist. And this
> can make it consistent with other places of check.
>
> Signed-off-by: Baoquan He
This patch looks good.
Acked-by: Vivek Goyal
Vivek
> ---
> arch/x86/kernel/crash.c | 10 +++
On Tue, Aug 12, 2014 at 01:29:27PM +0800, Baoquan He wrote:
> In locate_mem_hole functions, a memory hole is located and added as
> kexec_segment. But from the name of locate_mem_hole, it should only
> take responsibility of searching a available memory hole to contain
> data of a specified size.
>
On Tue, Aug 12, 2014 at 04:49:35PM +0200, Richard Weinberger wrote:
> Am 12.08.2014 16:46, schrieb Vivek Goyal:
> > Richard and Daniel reported that UML is broken due to changes to resource
> > traversal functions. Problem is that iomem_resource.child can be null
> > and new c
w_thread_handler+0x81/0xa3
Reported-by: Daniel Walter
Tested-by: Richard Weinberger
Tested-by: Toralf Förster
Tested-by: Daniel Walter
Signed-off-by: Vivek Goyal
---
kernel/resource.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
Index: linux-2.6/kernel/resource.c
On Tue, Aug 12, 2014 at 12:10:30PM +0100, Will Deacon wrote:
> On Tue, Aug 12, 2014 at 11:27:34AM +0100, Will Deacon wrote:
> > On Mon, Aug 11, 2014 at 08:37:41PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, Aug 11, 2014 at 8:57 PM, Arnd Bergmann wrote:
> > > > On Monday 11 August 2014, Will Dea
On Mon, Aug 11, 2014 at 11:08:48AM -0700, H. Peter Anvin wrote:
> On 08/11/2014 11:02 AM, Vivek Goyal wrote:
> >
> > Hi hpa,
> >
> > I took it because kexec-tools uses it and in one of the committs Eric
> > gave following reasoning.
> >
> > On
On Mon, Aug 11, 2014 at 02:25:56PM +0200, Richard Weinberger wrote:
> Hi Vivek,
>
> Am 11.08.2014 14:22, schrieb Vivek Goyal:
> > On Sun, Aug 10, 2014 at 06:56:14PM +0200, Richard Weinberger wrote:
> >> Hi Vivek,
> >>
> >> Daniel Walter reported that U
On Mon, Aug 11, 2014 at 11:08:48AM -0700, H. Peter Anvin wrote:
> On 08/11/2014 11:02 AM, Vivek Goyal wrote:
> >
> > Hi hpa,
> >
> > I took it because kexec-tools uses it and in one of the committs Eric
> > gave following reasoning.
> >
> > On
On Mon, Aug 11, 2014 at 10:51:10AM -0700, H. Peter Anvin wrote:
> On 08/11/2014 10:40 AM, Shaun Ruffell wrote:
> > FYI, it looks like the following patch (committed in
> > 8fc5b4d4121c95482b2583) adds a new requirement to use at least gcc
> > 4.4 to build the kernel?
>
> Well, to build the kernel
m interested in
looking at backtrace.
Thanks
Vivek
> commit 8c86e70acead629aacb4afcd818add66bf6844d9
> Author: Vivek Goyal
> Date: Fri Aug 8 14:25:50 2014 -0700
>
> resource: provide new functions to walk through resources
>
> It dies in next_resource():
>
fabricate_name()).
>
> Reported-by: Dan Carpenter
> Signed-off-by: David Howells
Looks good to me.
Acked-by: Vivek Goyal
Thanks
Vivek
> ---
> crypto/asymmetric_keys/pkcs7_verify.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/crypto/asym
On Wed, Jul 09, 2014 at 02:24:07PM -0400, Vivek Goyal wrote:
> Well all the hard work is done in previous patches. Now bzImage loader
> has just call into that code and verify whether bzImage signature are
> valid or not.
>
> Also create two config options. First one is CONFIG_K
w.
Otherwise patch looks good to me from blk-throttle perspective.
Acked-by: Vivek Goyal
[..]
> +static bool tg_ensure_stats_cpu(struct throtl_grp *tg)
> +{
> + struct tg_stats_cpu __percpu *stats_cpu;
> + int cpu;
> +
> + if (likely(tg->stats_cpu))
>
stead of new offset
>
> Signed-off-by: Vitaly Kuznetsov
> Reviewed-by: Andrew Jones
This one looks good to me. Thanks.
Acked-by: Vivek Goyal
Vivek
> ---
> fs/proc/vmcore.c | 83
> ++--
> 1 file changed, 80 insert
On Thu, Jul 10, 2014 at 07:15:43PM +0200, Vitaly Kuznetsov wrote:
> We have a special check in read_vmcore() handler to check if the page was
> reported as ram or not by the hypervisor (pfn_is_ram()). However, when
> vmcore is read with mmap() no such check is performed. That can lead to
> unpredic
601 - 700 of 2045 matches
Mail list logo
