* Re: [PATCH v2] oom: fix integer overflow of points in oom_badness
From: KOSAKI Motohiro @ 2011-10-31 14:18 UTC (permalink / raw)
To: fhrbata
Cc: rientjes, linux-mm, linux-kernel, akpm, oleg, minchan.kim, stable,
eteo, pmatouse
In-Reply-To: <1320076569-23872-1-git-send-email-fhrbata@redhat.com>
(10/31/2011 11:56 AM), Frantisek Hrbata wrote:
> An integer overflow will happen on 64bit archs if task's sum of rss, swapents
> and nr_ptes exceeds (2^31)/1000 value. This was introduced by commit
>
> f755a04 oom: use pte pages in OOM score
>
> where the oom score computation was divided into several steps and it's no
> longer computed as one expression in unsigned long(rss, swapents, nr_pte are
> unsigned long), where the result value assigned to points(int) is in
> range(1..1000). So there could be an int overflow while computing
>
> 176 points *= 1000;
>
> and points may have negative value. Meaning the oom score for a mem hog task
> will be one.
>
> 196 if (points <= 0)
> 197 return 1;
>
> For example:
> [ 3366] 0 3366 35390480 24303939 5 0 0 oom01
> Out of memory: Kill process 3366 (oom01) score 1 or sacrifice child
>
> Here the oom1 process consumes more than 24303939(rss)*4096~=92GB physical
> memory, but it's oom score is one.
>
> In this situation the mem hog task is skipped and oom killer kills another and
> most probably innocent task with oom score greater than one.
>
> The points variable should be of type long instead of int to prevent the int
> overflow.
>
> Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com>
> ---
> mm/oom_kill.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 626303b..e9a1785 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -162,7 +162,7 @@ static bool oom_unkillable_task(struct task_struct *p,
> unsigned int oom_badness(struct task_struct *p, struct mem_cgroup *mem,
> const nodemask_t *nodemask, unsigned long totalpages)
> {
> - int points;
> + long points;
>
> if (oom_unkillable_task(p, mem, nodemask))
> return 0;
Good catch.
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Junio C Hamano @ 2011-10-31 17:19 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git@vger.kernel.org, Linux Kernel
In-Reply-To: <4EAEAE13.50101@atlas-elektronik.com>
Stefan Näwe <stefan.naewe@atlas-elektronik.com> writes:
>> * HTTP transport did not use pushurl correctly, and also did not tell
>> what host it is trying to authenticate with when asking for
>> credentials.
>> (merge deba493 jk/http-auth later to maint).
>
> This seems to break pushing with https for me.
> It never uses values from my '~/.netrc'.
> I'll come up with a detailed scenario later.
Thanks.
I have been pushing my updates out to code.google.com via authentication
token stored in ~/.netrc over https, so it would be nice to see what
breaks for you that works for me. There probably is something subtly
different.
^ permalink raw reply
* Re: [PATCH v2] oom: fix integer overflow of points in oom_badness
From: KOSAKI Motohiro @ 2011-10-31 14:18 UTC (permalink / raw)
To: fhrbata
Cc: rientjes, linux-mm, linux-kernel, akpm, oleg, minchan.kim, stable,
eteo, pmatouse
In-Reply-To: <1320076569-23872-1-git-send-email-fhrbata@redhat.com>
(10/31/2011 11:56 AM), Frantisek Hrbata wrote:
> An integer overflow will happen on 64bit archs if task's sum of rss, swapents
> and nr_ptes exceeds (2^31)/1000 value. This was introduced by commit
>
> f755a04 oom: use pte pages in OOM score
>
> where the oom score computation was divided into several steps and it's no
> longer computed as one expression in unsigned long(rss, swapents, nr_pte are
> unsigned long), where the result value assigned to points(int) is in
> range(1..1000). So there could be an int overflow while computing
>
> 176 points *= 1000;
>
> and points may have negative value. Meaning the oom score for a mem hog task
> will be one.
>
> 196 if (points <= 0)
> 197 return 1;
>
> For example:
> [ 3366] 0 3366 35390480 24303939 5 0 0 oom01
> Out of memory: Kill process 3366 (oom01) score 1 or sacrifice child
>
> Here the oom1 process consumes more than 24303939(rss)*4096~=92GB physical
> memory, but it's oom score is one.
>
> In this situation the mem hog task is skipped and oom killer kills another and
> most probably innocent task with oom score greater than one.
>
> The points variable should be of type long instead of int to prevent the int
> overflow.
>
> Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com>
> ---
> mm/oom_kill.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 626303b..e9a1785 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -162,7 +162,7 @@ static bool oom_unkillable_task(struct task_struct *p,
> unsigned int oom_badness(struct task_struct *p, struct mem_cgroup *mem,
> const nodemask_t *nodemask, unsigned long totalpages)
> {
> - int points;
> + long points;
>
> if (oom_unkillable_task(p, mem, nodemask))
> return 0;
Good catch.
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
^ permalink raw reply
* Re: [git pull] PCI changes
From: Jesse Barnes @ 2011-10-31 17:18 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linus Torvalds, linux-pci, linux-kernel
In-Reply-To: <201110290130.45150.rjw@sisk.pl>
[-- Attachment #1: Type: text/plain, Size: 3490 bytes --]
On Sat, 29 Oct 2011 01:30:44 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> Hi,
>
> On Friday, October 28, 2011, Jesse Barnes wrote:
> > Note! There are two branches available, see below.
> >
> > The following changes since commit
> > e9308cfd5ab4ade3d81cf591c7599c3a05a21b04:
> >
> > Merge branch 'gpio/merge' of git://git.secretlab.ca/git/linux-2.6 (2011-10-14 17:07:52 +1200)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci next-revert
> >
> > Probably the most exciting bits of this series are the MPS fixes and
> > Joerg's PASID stuff. But I don't think there's anything really risky
> > (i.e. no big resource management changes this time around).
> >
> > We found a problem on PPC with the latency setup changes, so this
> > branch includes reverts for those patches. However, another branch is
> > available with those patches rebased out if you prefer a cleaner
> > changelog. See below for the changelog and diffstat to expect from
> > that branch.
> >
> > Ben Hutchings (2):
> > PCI: Add Solarflare vendor ID and SFC4000 device IDs
> > PCI: Add quirk for known incorrect MPSS
> >
> > Benjamin Herrenschmidt (2):
> > PCI: Make pci_setup_bridge() non-static for use by arch code
> > pci: Clamp pcie_set_readrq() when using "performance" settings
> >
> > Jan Beulich (1):
> > x86: constify PCI raw ops structures
> >
> > Jesse Barnes (7):
> > Revert "PCI: latency timer doesn't apply to PCIe"
> > Revert "PCI: x86: use generic pcibios_set_master()"
> > Revert "PCI: sh: use generic pcibios_set_master()"
> > Revert "PCI: mn10300: use generic pcibios_set_master()"
> > Revert "PCI: mips: use generic pcibios_set_master()"
> > Revert "PCI: frv: use generic pcibios_set_master()"
> > Revert "PCI: Pull PCI 'latency timer' setup up into the core"
> >
> > Joerg Roedel (4):
> > PCI: Move ATS implementation into own file
> > PCI: Export ATS functions to modules
> > PCI: Add implementation for PRI capability
> > PCI: Add support for PASID capability
> >
> > Jon Mason (3):
> > PCI: Workaround for Intel MPS errata
> > PCI: enable MPS "performance" setting to properly handle bridge MPS
> > PCI: Clean-up MPS debug output
> >
> > Josh Boyer (1):
> > PCI quirk: mmc: Always check for lower base frequency quirk for Ricoh 1180:e823
> >
> > Myron Stowe (7):
> > PCI: Pull PCI 'latency timer' setup up into the core
> > PCI: frv: use generic pcibios_set_master()
> > PCI: mips: use generic pcibios_set_master()
> > PCI: mn10300: use generic pcibios_set_master()
> > PCI: sh: use generic pcibios_set_master()
> > PCI: x86: use generic pcibios_set_master()
> > PCI: latency timer doesn't apply to PCIe
> >
> > Prarit Bhargava (1):
> > PCI hotplug: acpiphp: Prevent deadlock on PCI-to-PCI bridge remove
> >
> > Rafael J. Wysocki (2):
> > PCI / PM: Extend PME polling to all PCI devices
> > PCI / PM: Remove unnecessary error variable from acpi_dev_run_wake()
>
> Any chance to push https://lkml.org/lkml/2011/10/21/192 any time soon?
>
> It pretty much is a necessary fix for a problem with _OSC after some
> recent changes.
Yeah, pushed to my for-linus branch, thanks Rafael.
--
Jesse Barnes, Intel Open Source Technology Center
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Crypto Update for 3.2
From: Linus Torvalds @ 2011-10-31 17:16 UTC (permalink / raw)
To: Randy Dunlap
Cc: Herbert Xu, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <4EAED00C.3010908@xenotime.net>
On Mon, Oct 31, 2011 at 9:42 AM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>
> Actually adds "select NET", a reverse dependency. :(
>
> Linus was quite vocal about not allowing MD to select BLOCK.
> See https://lkml.org/lkml/2011/8/10/527
> and https://lkml.org/lkml/2011/8/10/533
>
> To me this is very similar.
I do agree.
"select" makes sense when it's a way for a user to not have to care
about some small helper thing that is really not obvious for a casual
user.
But darn it, if somebody has said "no networking", then some random
small feature shouldn't suddenly select it.
IOW, it's about "relative importance". We should use "select" when
some feature that should be user-visible selects some details. And we
should use "depends on" when there's a major subsystem that some small
detail depends on.
So classic and obvious uses where "select" is appropriate is when a
driver needs some helper library to work (eg "select FW_LOADER" or
"select CRC32").
And a classic and obvious case where "depends on" is the appropriate
choice is when it depends on a major subsystem ("depends on PCI" or
"depends on USB" or "depends on X86").
And I think "NET" definitely falls into that second category - exactly
the same way "BLOCK" fell into it. You don't "select" major subsystems
- if somebody turned off the subsystem, we turn off the stuff that
depends on it.
(Of course, in reality, pretty much nobody turns off NET, I suspect.
But if some embedded place really doesn't want it, then damn it, we
shouldn't ask about the odd crypto user interfaces, because they
really aren't major enough, and the embedded platform is clearly
trying very hard to run small).
Linus
^ permalink raw reply
* Re: Crypto Update for 3.2
From: Linus Torvalds @ 2011-10-31 17:16 UTC (permalink / raw)
To: Randy Dunlap
Cc: Herbert Xu, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <4EAED00C.3010908@xenotime.net>
On Mon, Oct 31, 2011 at 9:42 AM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>
> Actually adds "select NET", a reverse dependency. :(
>
> Linus was quite vocal about not allowing MD to select BLOCK.
> See https://lkml.org/lkml/2011/8/10/527
> and https://lkml.org/lkml/2011/8/10/533
>
> To me this is very similar.
I do agree.
"select" makes sense when it's a way for a user to not have to care
about some small helper thing that is really not obvious for a casual
user.
But darn it, if somebody has said "no networking", then some random
small feature shouldn't suddenly select it.
IOW, it's about "relative importance". We should use "select" when
some feature that should be user-visible selects some details. And we
should use "depends on" when there's a major subsystem that some small
detail depends on.
So classic and obvious uses where "select" is appropriate is when a
driver needs some helper library to work (eg "select FW_LOADER" or
"select CRC32").
And a classic and obvious case where "depends on" is the appropriate
choice is when it depends on a major subsystem ("depends on PCI" or
"depends on USB" or "depends on X86").
And I think "NET" definitely falls into that second category - exactly
the same way "BLOCK" fell into it. You don't "select" major subsystems
- if somebody turned off the subsystem, we turn off the stuff that
depends on it.
(Of course, in reality, pretty much nobody turns off NET, I suspect.
But if some embedded place really doesn't want it, then damn it, we
shouldn't ask about the odd crypto user interfaces, because they
really aren't major enough, and the embedded platform is clearly
trying very hard to run small).
Linus
^ permalink raw reply
* Re: [PATCH 1/1] distro_tracking_fields: update packages tracking fields
From: Saul Wold @ 2011-10-31 17:10 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi
In-Reply-To: <406DBB9E-C6C4-4CAC-9A6B-6C796C5ACBA6@dominion.thruhere.net>
On 10/31/2011 10:06 AM, Koen Kooi wrote:
>
> Op 31 okt. 2011, om 18:04 heeft Saul Wold het volgende geschreven:
>
>> On 10/24/2011 07:49 PM, wenzong.fan@windriver.com wrote:
>>> From: Wenzong Fan<wenzong.fan@windriver.com>
>>>
>>> Update packages tracking fields including ccache, chkconfig.
>>>
>>> Signed-off-by: Wenzong Fan<wenzong.fan@windriver.com>
>>> ---
>>> .../conf/distro/include/distro_tracking_fields.inc | 12 ++++++++++++
>>> 1 files changed, 12 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc
>>> index 1f3540e..f053f87 100644
>>> --- a/meta/conf/distro/include/distro_tracking_fields.inc
>>> +++ b/meta/conf/distro/include/distro_tracking_fields.inc
>>> @@ -5976,6 +5976,18 @@ RECIPE_MANUAL_CHECK_DATE_pn-libsdl = "Jul 28, 2011"
>>> RECIPE_MAINTAINER_pn-libsdl = "Kai Kang<kai.kang@windriver.com>"
>>> DISTRO_PN_ALIAS_pn-libsdl = "Fedora=SDL Opensuse=SDL"
>>>
>>> +RECIPE_STATUS_pn-ccache = "green"
>>> +RECIPE_MAINTAINER_pn-ccache = "Wenzong Fan<wenzong.fan@windriver.com>"
>>> +RECIPE_LATEST_VERSION_pn-ccache = "3.1.6"
>>> +RECIPE_LAST_UPDATE_pn-ccache = "October 19, 2011"
>>> +RECIPE_MANUAL_CHECK_DATE_pn-ccache = "October 25, 2011"
>>> +
>> This should be MMM (as in Oct), not spelled out, please fix.
>>
>> (Koen: Yes I saw your email about the date, not address that at this time as we are re-thinking the whole distro_tracking_fields.inc file).
>
> When the month is spelled out ordering becomes less of an issue.
>
That's kind of why we chose this, we are still parsing this file, so
spelling can be an issue sometimes, which is why we want the MMM format.
Sau!
> regards,
>
> Koen
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCH 1/4] lib/oe/terminal: add support for XFCE's terminal emulator
From: Joshua Lock @ 2011-10-31 17:09 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <CABcZANkS9zDK-qLtMxHdn7SE29vTz+HPMwCUtf=yP-uuGV=Dtg@mail.gmail.com>
On 28/10/11 17:56, Chris Larson wrote:
> On Fri, Oct 28, 2011 at 4:42 PM, Joshua Lock <josh@linux.intel.com> wrote:
>> That's Terminal on Fedora and xfce4-terminal on Ubuntu/Debian... This
>> could get interesting!
>>
>> Signed-off-by: Joshua Lock <josh@linux.intel.com>
>> ---
>> meta/lib/oe/terminal.py | 21 +++++++++++++++++++++
>> 1 files changed, 21 insertions(+), 0 deletions(-)
>>
>> diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py
>> index 1455e8e..b90a1f2 100644
>> --- a/meta/lib/oe/terminal.py
>> +++ b/meta/lib/oe/terminal.py
>> @@ -57,6 +57,27 @@ class Gnome(XTerminal):
>> command = 'gnome-terminal --disable-factory -t "{title}" -x {command}'
>> priority = 2
>>
>> +class Xfce(XTerminal):
>> + def distro_name():
>> + import subprocess as sub
>> + try:
>> + p = sub.Popen(['lsb_release', '-i'], stdout=sub.PIPE,
>> + stderr=sub.PIPE)
>> + out, err = p.communicate()
>> + distro = out.split(':').strip()
>> + except:
>> + distro = "unknown"
>> + return distro
>> +
>> + # Upstream binary name is Terminal but Debian/Ubuntu use
>> + # xfce4-terminal to avoid possible(?) conflicts
>> + distro = distro_name()
>> + if distro == 'Ubuntu' or distro == 'Debian':
>> + command = 'xfce4-terminal -T "{title}" -e "{command}"'
>> + else:
>> + command = 'Terminal -T "{title}" -e "{command}"'
>> + priority = 2
>
> The first problem I see with this is you're calling lsb_release at
> module import time. Doing things like that is generally a no-no. I'd
> suggest shifting it into the constructor. Set up the command there as
> self.command, and be sure to call the superclass constructor as well,
> after the command bits. The other thing is, and I'm sure you just
> copied & pasted it from konsole, but we already import a fully
> functional Popen -- it's the superclass of all the terminal classes.
> So there's no need to pull in subprocess's version of it. And the
> defaults of the Popen we use ensure the output is captured, so there's
> no need for the sub.PIPE bits at all if you use that one. Simply do p
> = Popen(['lsb_release', '-i']).
Thanks for the feedback Chris. I'll roll your suggestions into a v2 today.
>
> Thanks for adding this, I'm sure folks using stock Xubuntu and the
> like will find this helpful (I'm an rxvt-unicode guy myself).
I figured that DE would be getting more popular, hence throwing a patch
together.
Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
^ permalink raw reply
* Re: what's the proper value for BB_NUMBER_THREADS?
From: Mark Hatle @ 2011-10-31 17:15 UTC (permalink / raw)
To: yocto
In-Reply-To: <alpine.DEB.2.02.1110301214180.915@localhost6.localdomain6>
On 10/30/11 11:15 AM, Robert P. J. Day wrote:
> On Sun, 30 Oct 2011, Christian Gagneraud wrote:
>
>> On 30/10/11 15:32, Robert P. J. Day wrote:
>>>
>>> all the docs recommend twice the number of cores (AFAICT), yet the
>>> template local.conf file suggests that, for a quad core, the value of
>>> 4 would be appropriate. shouldn't that say 8? same with
>>> PARALLEL_MAKE?
>>
>> Hi Robert,
>>
>> The Poky ref manual says (rule of thumb) x2 for BB_NUMBER_THREADS,
>> and x1.5 for PARALLEL_MAKE.
>
> if that's the case, anyone object to my submitting a patch to
> update local.conf.sample appropriately?
>
> rday
>
I agree the manual and local.conf files should match. The issue seems to be
that the perfect values are subjective. Things like memory, disk speed, chipset
latency, and of course processor speed/cores all affect the optimal setting.
But we do need a consistent rule of thumb.. I myself usually use x2 for both
THREADS and MAKE.
--Mark
^ permalink raw reply
* [RFC PATCH v3 10/10] fadump: Introduce config option for firmware assisted dump feature
From: Mahesh J Salgaonkar @ 2011-10-31 17:13 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel, Benjamin Herrenschmidt
Cc: Haren Myneni, Eric W. Biederman, Amerigo Wang, Milton Miller,
Anton Blanchard
In-Reply-To: <20111031170200.12259.27663.stgit@mars.in.ibm.com>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
This patch introduces a new config option CONFIG_FA_DUMP for firmware
assisted dump feature on Powerpc (ppc64) architecture.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/Kconfig | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6926b61..7ce773c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -379,6 +379,19 @@ config PHYP_DUMP
If unsure, say "N"
+config FA_DUMP
+ bool "Firmware-assisted dump"
+ depends on PPC64 && PPC_RTAS && CRASH_DUMP
+ help
+ A robust mechanism to get reliable kernel crash dump with
+ assistance from firmware. This approach does not use kexec,
+ instead firmware assists in booting the kdump kernel
+ while preserving memory contents. Firmware-assisted dump
+ is meant to be a kdump replacement offering robustness and
+ speed not possible without system firmware assistance.
+
+ If unsure, say "N"
+
config PPCBUG_NVRAM
bool "Enable reading PPCBUG NVRAM during boot" if PPLUS || LOPEC
default y if PPC_PREP
^ permalink raw reply related
* [RFC PATCH v3 10/10] fadump: Introduce config option for firmware assisted dump feature
From: Mahesh J Salgaonkar @ 2011-10-31 17:13 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel, Benjamin Herrenschmidt
Cc: Anton Blanchard, Eric W. Biederman, Milton Miller, Amerigo Wang
In-Reply-To: <20111031170200.12259.27663.stgit@mars.in.ibm.com>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
This patch introduces a new config option CONFIG_FA_DUMP for firmware
assisted dump feature on Powerpc (ppc64) architecture.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/Kconfig | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6926b61..7ce773c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -379,6 +379,19 @@ config PHYP_DUMP
If unsure, say "N"
+config FA_DUMP
+ bool "Firmware-assisted dump"
+ depends on PPC64 && PPC_RTAS && CRASH_DUMP
+ help
+ A robust mechanism to get reliable kernel crash dump with
+ assistance from firmware. This approach does not use kexec,
+ instead firmware assists in booting the kdump kernel
+ while preserving memory contents. Firmware-assisted dump
+ is meant to be a kdump replacement offering robustness and
+ speed not possible without system firmware assistance.
+
+ If unsure, say "N"
+
config PPCBUG_NVRAM
bool "Enable reading PPCBUG NVRAM during boot" if PPLUS || LOPEC
default y if PPC_PREP
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v3 03/13] qemu-timer: move common code to qemu_rearm_alarm_timer
From: Stefan Weil @ 2011-10-31 17:13 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: TeLeMan, qemu-devel
In-Reply-To: <j8lrtm$p3q$2@dough.gmane.org>
Am 31.10.2011 11:05, schrieb Paolo Bonzini:
> On 10/31/2011 08:23 AM, TeLeMan wrote:
>>> > static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
>>> > {
>>> > - if (!alarm_has_dynticks(t))
>>> > + int64_t nearest_delta_ns;
>>> > + assert(alarm_has_dynticks(t));
>> "mmtimer" and "win32" alarms have no rearm. Should we remove these
>> two alarms?
>
> Yes. I think with iothread they are broken, or almost broken.
>
> Paolo
They can't be more broken: I noticed today that QEMU on W32 aborts
with the default timer (mmtimer) very quickly.
Stefan
^ permalink raw reply
* [RFC PATCH v3 09/10] fadump: Invalidate the fadump registration during machine shutdown.
From: Mahesh J Salgaonkar @ 2011-10-31 17:12 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel, Benjamin Herrenschmidt
Cc: Haren Myneni, Eric W. Biederman, Amerigo Wang, Milton Miller,
Anton Blanchard
In-Reply-To: <20111031170200.12259.27663.stgit@mars.in.ibm.com>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
If dump is active during system reboot, shutdown or halt then invalidate
the fadump registration as it does not get invalidated automatically.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kernel/setup-common.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index ce35aaf..67e5caa 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -110,6 +110,14 @@ EXPORT_SYMBOL(ppc_do_canonicalize_irqs);
/* also used by kexec */
void machine_shutdown(void)
{
+#ifdef CONFIG_FA_DUMP
+ /*
+ * if fadump is active, cleanup the fadump registration before we
+ * shutdown.
+ */
+ fadump_cleanup();
+#endif
+
if (ppc_md.machine_shutdown)
ppc_md.machine_shutdown();
}
^ permalink raw reply related
* [RFC PATCH v3 09/10] fadump: Invalidate the fadump registration during machine shutdown.
From: Mahesh J Salgaonkar @ 2011-10-31 17:12 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel, Benjamin Herrenschmidt
Cc: Anton Blanchard, Eric W. Biederman, Milton Miller, Amerigo Wang
In-Reply-To: <20111031170200.12259.27663.stgit@mars.in.ibm.com>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
If dump is active during system reboot, shutdown or halt then invalidate
the fadump registration as it does not get invalidated automatically.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kernel/setup-common.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index ce35aaf..67e5caa 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -110,6 +110,14 @@ EXPORT_SYMBOL(ppc_do_canonicalize_irqs);
/* also used by kexec */
void machine_shutdown(void)
{
+#ifdef CONFIG_FA_DUMP
+ /*
+ * if fadump is active, cleanup the fadump registration before we
+ * shutdown.
+ */
+ fadump_cleanup();
+#endif
+
if (ppc_md.machine_shutdown)
ppc_md.machine_shutdown();
}
^ permalink raw reply related
* Re: [PATCH 1/1] distro_tracking_fields: update packages tracking fields
From: Koen Kooi @ 2011-10-31 17:06 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4EAED524.50306@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]
Op 31 okt. 2011, om 18:04 heeft Saul Wold het volgende geschreven:
> On 10/24/2011 07:49 PM, wenzong.fan@windriver.com wrote:
>> From: Wenzong Fan<wenzong.fan@windriver.com>
>>
>> Update packages tracking fields including ccache, chkconfig.
>>
>> Signed-off-by: Wenzong Fan<wenzong.fan@windriver.com>
>> ---
>> .../conf/distro/include/distro_tracking_fields.inc | 12 ++++++++++++
>> 1 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc
>> index 1f3540e..f053f87 100644
>> --- a/meta/conf/distro/include/distro_tracking_fields.inc
>> +++ b/meta/conf/distro/include/distro_tracking_fields.inc
>> @@ -5976,6 +5976,18 @@ RECIPE_MANUAL_CHECK_DATE_pn-libsdl = "Jul 28, 2011"
>> RECIPE_MAINTAINER_pn-libsdl = "Kai Kang<kai.kang@windriver.com>"
>> DISTRO_PN_ALIAS_pn-libsdl = "Fedora=SDL Opensuse=SDL"
>>
>> +RECIPE_STATUS_pn-ccache = "green"
>> +RECIPE_MAINTAINER_pn-ccache = "Wenzong Fan<wenzong.fan@windriver.com>"
>> +RECIPE_LATEST_VERSION_pn-ccache = "3.1.6"
>> +RECIPE_LAST_UPDATE_pn-ccache = "October 19, 2011"
>> +RECIPE_MANUAL_CHECK_DATE_pn-ccache = "October 25, 2011"
>> +
> This should be MMM (as in Oct), not spelled out, please fix.
>
> (Koen: Yes I saw your email about the date, not address that at this time as we are re-thinking the whole distro_tracking_fields.inc file).
When the month is spelled out ordering becomes less of an issue.
regards,
Koen
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]
^ permalink raw reply
* [RFC PATCH v3 08/10] fadump: Invalidate registration and release reserved memory for general use.
From: Mahesh J Salgaonkar @ 2011-10-31 17:11 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel, Benjamin Herrenschmidt
Cc: Haren Myneni, Eric W. Biederman, Amerigo Wang, Milton Miller,
Anton Blanchard
In-Reply-To: <20111031170200.12259.27663.stgit@mars.in.ibm.com>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
This patch introduces an sysfs interface '/sys/kernel/fadump_release_mem' to
invalidate the last fadump registration, invalidate '/proc/vmcore', release
the reserved memory for general use and re-register for future kernel dump.
Once the dump is copied to the disk, the userspace tool will echo 1 to
'/sys/kernel/fadump_release_mem'.
Release the reserved memory region excluding the size of the memory required
for future kernel dump registration.
Change in v3:
- Syncronize the fadump invalidation step to handle simultaneous writes to
/sys/kernel/fadump_release_mem.
Change in v2:
- Introduced cpu_notes_buf_free() function to free memory allocated for
cpu notes buffer.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/fadump.h | 3 +
arch/powerpc/kernel/fadump.c | 170 ++++++++++++++++++++++++++++++++++++-
2 files changed, 169 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
index 4a7d63e..2d983e8 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -196,6 +196,9 @@ extern int fadump_reserve_mem(void);
extern int setup_fadump(void);
extern int is_fadump_active(void);
extern void crash_fadump(struct pt_regs *, const char *);
+extern void fadump_cleanup(void);
+
+extern void vmcore_cleanup(void);
#else /* CONFIG_FA_DUMP */
static inline int is_fadump_active(void) { return 0; }
#endif
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4d42fe5..ecdf81b 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -33,6 +33,8 @@
#include <linux/debugfs.h>
#include <linux/seq_file.h>
#include <linux/crash_dump.h>
+#include <linux/kobject.h>
+#include <linux/sysfs.h>
#include <asm/page.h>
#include <asm/prom.h>
@@ -560,6 +562,19 @@ static void *cpu_notes_buf_alloc(unsigned long size)
return vaddr;
}
+static void cpu_notes_buf_free(unsigned long vaddr, unsigned long size)
+{
+ struct page *page;
+ unsigned long order, count, i;
+
+ order = get_order(size);
+ count = 1 << order;
+ page = virt_to_page(vaddr);
+ for (i = 0; i < count; i++)
+ ClearPageReserved(page + i);
+ __free_pages(page, order);
+}
+
/*
* Read CPU state dump data and convert it into ELF notes.
* The CPU dump starts with magic number "REGSAVE". NumCpusOffset should be
@@ -944,6 +959,131 @@ static int fadump_unregister_dump(struct fadump_mem_struct *fdm)
return 0;
}
+static int fadump_invalidate_dump(struct fadump_mem_struct *fdm)
+{
+ int rc = 0;
+ unsigned int wait_time;
+
+ pr_debug("Invalidating firmware-assisted dump registration\n");
+
+ /* TODO: Add upper time limit for the delay */
+ do {
+ rc = rtas_call(fw_dump.ibm_configure_kernel_dump, 3, 1, NULL,
+ FADUMP_INVALIDATE, fdm,
+ sizeof(struct fadump_mem_struct));
+
+ wait_time = rtas_busy_delay_time(rc);
+ if (wait_time)
+ mdelay(wait_time);
+ } while (wait_time);
+
+ if (rc) {
+ printk(KERN_ERR "Failed to invalidate firmware-assisted dump "
+ "rgistration. unexpected error(%d).\n", rc);
+ return rc;
+ }
+ fw_dump.dump_active = 0;
+ fdm_active = NULL;
+ return 0;
+}
+
+void fadump_cleanup(void)
+{
+ /* Invalidate the registration only if dump is active. */
+ if (fw_dump.dump_active) {
+ init_fadump_mem_struct(&fdm,
+ fdm_active->cpu_state_data.destination_address);
+ fadump_invalidate_dump(&fdm);
+ }
+}
+
+/*
+ * Release the memory that was reserved in early boot to preserve the memory
+ * contents. The released memory will be available for general use.
+ */
+static void fadump_release_memory(unsigned long begin, unsigned long end)
+{
+ unsigned long addr;
+ unsigned long ra_start, ra_end;
+
+ ra_start = fw_dump.reserve_dump_area_start;
+ ra_end = ra_start + fw_dump.reserve_dump_area_size;
+
+ for (addr = begin; addr < end; addr += PAGE_SIZE) {
+ /*
+ * exclude the dump reserve area. Will reuse it for next
+ * fadump registration.
+ */
+ if (addr <= ra_end && ((addr + PAGE_SIZE) > ra_start))
+ continue;
+
+ ClearPageReserved(pfn_to_page(addr >> PAGE_SHIFT));
+ init_page_count(pfn_to_page(addr >> PAGE_SHIFT));
+ free_page((unsigned long)__va(addr));
+ totalram_pages++;
+ }
+}
+
+static void fadump_invalidate_release_mem(void)
+{
+ unsigned long reserved_area_start, reserved_area_end;
+ unsigned long destination_address;
+
+ mutex_lock(&fadump_mutex);
+ if (!fw_dump.dump_active) {
+ mutex_unlock(&fadump_mutex);
+ return;
+ }
+
+ destination_address = fdm_active->cpu_state_data.destination_address;
+ fadump_cleanup();
+ mutex_unlock(&fadump_mutex);
+
+ /*
+ * Save the current reserved memory bounds we will require them
+ * later for releasing the memory for general use.
+ */
+ reserved_area_start = fw_dump.reserve_dump_area_start;
+ reserved_area_end = reserved_area_start +
+ fw_dump.reserve_dump_area_size;
+ /*
+ * Setup reserve_dump_area_start and its size so that we can
+ * reuse this reserved memory for Re-registration.
+ */
+ fw_dump.reserve_dump_area_start = destination_address;
+ fw_dump.reserve_dump_area_size = get_dump_area_size();
+
+ fadump_release_memory(reserved_area_start, reserved_area_end);
+ if (fw_dump.cpu_notes_buf) {
+ cpu_notes_buf_free((unsigned long)__va(fw_dump.cpu_notes_buf),
+ fw_dump.cpu_notes_buf_size);
+ fw_dump.cpu_notes_buf = 0;
+ fw_dump.cpu_notes_buf_size = 0;
+ }
+ /* Initialize the kernel dump memory structure for FAD registration. */
+ init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
+}
+
+static ssize_t fadump_release_memory_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ if (!fw_dump.dump_active)
+ return -EPERM;
+
+ if (buf[0] == '1') {
+ /*
+ * Take away the '/proc/vmcore'. We are releasing the dump
+ * memory, hence it will not be valid anymore.
+ */
+ vmcore_cleanup();
+ fadump_invalidate_release_mem();
+
+ } else
+ return -EINVAL;
+ return count;
+}
+
static ssize_t fadump_enabled_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
@@ -1003,10 +1143,13 @@ static int fadump_region_show(struct seq_file *m, void *private)
if (!fw_dump.fadump_enabled)
return 0;
+ mutex_lock(&fadump_mutex);
if (fdm_active)
fdm_ptr = fdm_active;
- else
+ else {
+ mutex_unlock(&fadump_mutex);
fdm_ptr = &fdm;
+ }
seq_printf(m,
"CPU : [%#016llx-%#016llx] %#llx bytes, "
@@ -1036,7 +1179,7 @@ static int fadump_region_show(struct seq_file *m, void *private)
if (!fdm_active ||
(fw_dump.reserve_dump_area_start ==
fdm_ptr->cpu_state_data.destination_address))
- return 0;
+ goto out;
/* Dump is active. Show reserved memory region. */
seq_printf(m,
@@ -1048,9 +1191,15 @@ static int fadump_region_show(struct seq_file *m, void *private)
fw_dump.reserve_dump_area_start,
fdm_ptr->cpu_state_data.destination_address -
fw_dump.reserve_dump_area_start);
+out:
+ if (fdm_active)
+ mutex_unlock(&fadump_mutex);
return 0;
}
+static struct kobj_attribute fadump_release_attr = __ATTR(fadump_release_mem,
+ 0200, NULL,
+ fadump_release_memory_store);
static struct kobj_attribute fadump_attr = __ATTR(fadump_enabled,
0444, fadump_enabled_show,
NULL);
@@ -1091,6 +1240,13 @@ static void fadump_init_files(void)
if (!debugfs_file)
printk(KERN_ERR "fadump: unable to create debugfs file"
" fadump_region\n");
+
+ if (fw_dump.dump_active) {
+ rc = sysfs_create_file(kernel_kobj, &fadump_release_attr.attr);
+ if (rc)
+ printk(KERN_ERR "fadump: unable to create sysfs file"
+ " fadump_release_mem (%d)\n", rc);
+ }
return;
}
@@ -1110,8 +1266,14 @@ int __init setup_fadump(void)
* If dump data is available then see if it is valid and prepare for
* saving it to the disk.
*/
- if (fw_dump.dump_active)
- process_fadump(fdm_active);
+ if (fw_dump.dump_active) {
+ /*
+ * if dump process fails then invalidate the registration
+ * and release memory before proceeding for re-registration.
+ */
+ if (process_fadump(fdm_active) < 0)
+ fadump_invalidate_release_mem();
+ }
/* Initialize the kernel dump memory structure for FAD registration. */
else if (fw_dump.reserve_dump_area_size)
init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
^ permalink raw reply related
* [RFC PATCH v3 08/10] fadump: Invalidate registration and release reserved memory for general use.
From: Mahesh J Salgaonkar @ 2011-10-31 17:11 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel, Benjamin Herrenschmidt
Cc: Anton Blanchard, Eric W. Biederman, Milton Miller, Amerigo Wang
In-Reply-To: <20111031170200.12259.27663.stgit@mars.in.ibm.com>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
This patch introduces an sysfs interface '/sys/kernel/fadump_release_mem' to
invalidate the last fadump registration, invalidate '/proc/vmcore', release
the reserved memory for general use and re-register for future kernel dump.
Once the dump is copied to the disk, the userspace tool will echo 1 to
'/sys/kernel/fadump_release_mem'.
Release the reserved memory region excluding the size of the memory required
for future kernel dump registration.
Change in v3:
- Syncronize the fadump invalidation step to handle simultaneous writes to
/sys/kernel/fadump_release_mem.
Change in v2:
- Introduced cpu_notes_buf_free() function to free memory allocated for
cpu notes buffer.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/fadump.h | 3 +
arch/powerpc/kernel/fadump.c | 170 ++++++++++++++++++++++++++++++++++++-
2 files changed, 169 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
index 4a7d63e..2d983e8 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -196,6 +196,9 @@ extern int fadump_reserve_mem(void);
extern int setup_fadump(void);
extern int is_fadump_active(void);
extern void crash_fadump(struct pt_regs *, const char *);
+extern void fadump_cleanup(void);
+
+extern void vmcore_cleanup(void);
#else /* CONFIG_FA_DUMP */
static inline int is_fadump_active(void) { return 0; }
#endif
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4d42fe5..ecdf81b 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -33,6 +33,8 @@
#include <linux/debugfs.h>
#include <linux/seq_file.h>
#include <linux/crash_dump.h>
+#include <linux/kobject.h>
+#include <linux/sysfs.h>
#include <asm/page.h>
#include <asm/prom.h>
@@ -560,6 +562,19 @@ static void *cpu_notes_buf_alloc(unsigned long size)
return vaddr;
}
+static void cpu_notes_buf_free(unsigned long vaddr, unsigned long size)
+{
+ struct page *page;
+ unsigned long order, count, i;
+
+ order = get_order(size);
+ count = 1 << order;
+ page = virt_to_page(vaddr);
+ for (i = 0; i < count; i++)
+ ClearPageReserved(page + i);
+ __free_pages(page, order);
+}
+
/*
* Read CPU state dump data and convert it into ELF notes.
* The CPU dump starts with magic number "REGSAVE". NumCpusOffset should be
@@ -944,6 +959,131 @@ static int fadump_unregister_dump(struct fadump_mem_struct *fdm)
return 0;
}
+static int fadump_invalidate_dump(struct fadump_mem_struct *fdm)
+{
+ int rc = 0;
+ unsigned int wait_time;
+
+ pr_debug("Invalidating firmware-assisted dump registration\n");
+
+ /* TODO: Add upper time limit for the delay */
+ do {
+ rc = rtas_call(fw_dump.ibm_configure_kernel_dump, 3, 1, NULL,
+ FADUMP_INVALIDATE, fdm,
+ sizeof(struct fadump_mem_struct));
+
+ wait_time = rtas_busy_delay_time(rc);
+ if (wait_time)
+ mdelay(wait_time);
+ } while (wait_time);
+
+ if (rc) {
+ printk(KERN_ERR "Failed to invalidate firmware-assisted dump "
+ "rgistration. unexpected error(%d).\n", rc);
+ return rc;
+ }
+ fw_dump.dump_active = 0;
+ fdm_active = NULL;
+ return 0;
+}
+
+void fadump_cleanup(void)
+{
+ /* Invalidate the registration only if dump is active. */
+ if (fw_dump.dump_active) {
+ init_fadump_mem_struct(&fdm,
+ fdm_active->cpu_state_data.destination_address);
+ fadump_invalidate_dump(&fdm);
+ }
+}
+
+/*
+ * Release the memory that was reserved in early boot to preserve the memory
+ * contents. The released memory will be available for general use.
+ */
+static void fadump_release_memory(unsigned long begin, unsigned long end)
+{
+ unsigned long addr;
+ unsigned long ra_start, ra_end;
+
+ ra_start = fw_dump.reserve_dump_area_start;
+ ra_end = ra_start + fw_dump.reserve_dump_area_size;
+
+ for (addr = begin; addr < end; addr += PAGE_SIZE) {
+ /*
+ * exclude the dump reserve area. Will reuse it for next
+ * fadump registration.
+ */
+ if (addr <= ra_end && ((addr + PAGE_SIZE) > ra_start))
+ continue;
+
+ ClearPageReserved(pfn_to_page(addr >> PAGE_SHIFT));
+ init_page_count(pfn_to_page(addr >> PAGE_SHIFT));
+ free_page((unsigned long)__va(addr));
+ totalram_pages++;
+ }
+}
+
+static void fadump_invalidate_release_mem(void)
+{
+ unsigned long reserved_area_start, reserved_area_end;
+ unsigned long destination_address;
+
+ mutex_lock(&fadump_mutex);
+ if (!fw_dump.dump_active) {
+ mutex_unlock(&fadump_mutex);
+ return;
+ }
+
+ destination_address = fdm_active->cpu_state_data.destination_address;
+ fadump_cleanup();
+ mutex_unlock(&fadump_mutex);
+
+ /*
+ * Save the current reserved memory bounds we will require them
+ * later for releasing the memory for general use.
+ */
+ reserved_area_start = fw_dump.reserve_dump_area_start;
+ reserved_area_end = reserved_area_start +
+ fw_dump.reserve_dump_area_size;
+ /*
+ * Setup reserve_dump_area_start and its size so that we can
+ * reuse this reserved memory for Re-registration.
+ */
+ fw_dump.reserve_dump_area_start = destination_address;
+ fw_dump.reserve_dump_area_size = get_dump_area_size();
+
+ fadump_release_memory(reserved_area_start, reserved_area_end);
+ if (fw_dump.cpu_notes_buf) {
+ cpu_notes_buf_free((unsigned long)__va(fw_dump.cpu_notes_buf),
+ fw_dump.cpu_notes_buf_size);
+ fw_dump.cpu_notes_buf = 0;
+ fw_dump.cpu_notes_buf_size = 0;
+ }
+ /* Initialize the kernel dump memory structure for FAD registration. */
+ init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
+}
+
+static ssize_t fadump_release_memory_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ if (!fw_dump.dump_active)
+ return -EPERM;
+
+ if (buf[0] == '1') {
+ /*
+ * Take away the '/proc/vmcore'. We are releasing the dump
+ * memory, hence it will not be valid anymore.
+ */
+ vmcore_cleanup();
+ fadump_invalidate_release_mem();
+
+ } else
+ return -EINVAL;
+ return count;
+}
+
static ssize_t fadump_enabled_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
@@ -1003,10 +1143,13 @@ static int fadump_region_show(struct seq_file *m, void *private)
if (!fw_dump.fadump_enabled)
return 0;
+ mutex_lock(&fadump_mutex);
if (fdm_active)
fdm_ptr = fdm_active;
- else
+ else {
+ mutex_unlock(&fadump_mutex);
fdm_ptr = &fdm;
+ }
seq_printf(m,
"CPU : [%#016llx-%#016llx] %#llx bytes, "
@@ -1036,7 +1179,7 @@ static int fadump_region_show(struct seq_file *m, void *private)
if (!fdm_active ||
(fw_dump.reserve_dump_area_start ==
fdm_ptr->cpu_state_data.destination_address))
- return 0;
+ goto out;
/* Dump is active. Show reserved memory region. */
seq_printf(m,
@@ -1048,9 +1191,15 @@ static int fadump_region_show(struct seq_file *m, void *private)
fw_dump.reserve_dump_area_start,
fdm_ptr->cpu_state_data.destination_address -
fw_dump.reserve_dump_area_start);
+out:
+ if (fdm_active)
+ mutex_unlock(&fadump_mutex);
return 0;
}
+static struct kobj_attribute fadump_release_attr = __ATTR(fadump_release_mem,
+ 0200, NULL,
+ fadump_release_memory_store);
static struct kobj_attribute fadump_attr = __ATTR(fadump_enabled,
0444, fadump_enabled_show,
NULL);
@@ -1091,6 +1240,13 @@ static void fadump_init_files(void)
if (!debugfs_file)
printk(KERN_ERR "fadump: unable to create debugfs file"
" fadump_region\n");
+
+ if (fw_dump.dump_active) {
+ rc = sysfs_create_file(kernel_kobj, &fadump_release_attr.attr);
+ if (rc)
+ printk(KERN_ERR "fadump: unable to create sysfs file"
+ " fadump_release_mem (%d)\n", rc);
+ }
return;
}
@@ -1110,8 +1266,14 @@ int __init setup_fadump(void)
* If dump data is available then see if it is valid and prepare for
* saving it to the disk.
*/
- if (fw_dump.dump_active)
- process_fadump(fdm_active);
+ if (fw_dump.dump_active) {
+ /*
+ * if dump process fails then invalidate the registration
+ * and release memory before proceeding for re-registration.
+ */
+ if (process_fadump(fdm_active) < 0)
+ fadump_invalidate_release_mem();
+ }
/* Initialize the kernel dump memory structure for FAD registration. */
else if (fw_dump.reserve_dump_area_size)
init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
^ permalink raw reply related
* Re: [PATCH] nfs: Fix unused variable warning.
From: Rakib Mullick @ 2011-10-31 17:12 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-kernel, linux-nfs, akpm
In-Reply-To: <1320074323.4714.2.camel@lade.trondhjem.org>
[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]
On Mon, Oct 31, 2011 at 9:18 PM, Trond Myklebust
<Trond.Myklebust@netapp.com> wrote:
> On Fri, 2011-10-28 at 16:36 +0600, Rakib Mullick wrote:
>
> This will still cause a warning if you compile without RPC_DEBUG (e.g.
> if CONFIG_SYSCTL isn't defined).
>
I didn't get any warning with CONFIG_SYSCTL=n.
> Since there is only one user, it seems better to just open-code the
> NFS_SERVER(data->inode) in the dprintk()...
Okay, it seems reasonable. We can simply remove 'server'. Please
consider the following patch (also attached, might have some white
space issue).
---
When CONFIG_NFS=y and CONFIG_NFS_V3_{,V4}=n we get the following warning.
fs/nfs/write.c: In function ‘nfs_writeback_done’:
fs/nfs/write.c:1246:21: warning: unused variable ‘server’
Remove the variable 'server' to fix the above warning.
Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
---
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 2219c88..a2e4b27 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1243,7 +1243,6 @@ void nfs_writeback_done(struct rpc_task *task,
struct nfs_write_data *data)
{
struct nfs_writeargs *argp = &data->args;
struct nfs_writeres *resp = &data->res;
- struct nfs_server *server = NFS_SERVER(data->inode);
int status;
dprintk("NFS: %5u nfs_writeback_done (status %d)\n",
@@ -1277,7 +1276,7 @@ void nfs_writeback_done(struct rpc_task *task,
struct nfs_write_data *data)
if (time_before(complain, jiffies)) {
dprintk("NFS: faulty NFS server %s:"
" (committed = %d) != (stable = %d)\n",
- server->nfs_client->cl_hostname,
+ data->inode->nfs_client->cl_hostname,
resp->verf->committed, argp->stable);
complain = jiffies + 300 * HZ;
}
[-- Attachment #2: nfs_unused_var_fix.patch --]
[-- Type: application/octet-stream, Size: 1139 bytes --]
When CONFIG_NFS=y and CONFIG_NFS_V3_{,V4}=n we get the following warning.
fs/nfs/write.c: In function ‘nfs_writeback_done’:
fs/nfs/write.c:1246:21: warning: unused variable ‘server’
Remove the variable 'server' to fix the above warning.
Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
---
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 2219c88..a2e4b27 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1243,7 +1243,6 @@ void nfs_writeback_done(struct rpc_task *task, struct nfs_write_data *data)
{
struct nfs_writeargs *argp = &data->args;
struct nfs_writeres *resp = &data->res;
- struct nfs_server *server = NFS_SERVER(data->inode);
int status;
dprintk("NFS: %5u nfs_writeback_done (status %d)\n",
@@ -1277,7 +1276,7 @@ void nfs_writeback_done(struct rpc_task *task, struct nfs_write_data *data)
if (time_before(complain, jiffies)) {
dprintk("NFS: faulty NFS server %s:"
" (committed = %d) != (stable = %d)\n",
- server->nfs_client->cl_hostname,
+ data->inode->nfs_client->cl_hostname,
resp->verf->committed, argp->stable);
complain = jiffies + 300 * HZ;
}
^ permalink raw reply related
* Re: Final disposition of the pNFSD tree
From: Benny Halevy @ 2011-10-31 17:12 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: NFS list
In-Reply-To: <4EA799BC.5050805@tonian.com>
I just released pnfs-all-3.1-2011-10-31 which is much stabler than
the 3.1-rc9+ versions.
If not too late, I think this would be the best version for you to test,
also with respect to the callback path which now works with the
revised layout stateid tracking mechanism.
Benny
On 2011-10-26 07:25, Benny Halevy wrote:
> On 2011-10-26 05:26, Boaz Harrosh wrote:
>> Benny what is the state of the PNFSD tree? Can you sign on it's stability for
>> a large scale testing or should I be using the nfsd-3.1 based tree?
>>
>
> Right now there is use after free of the layout stateid that I'm working on
> for which I'd like to have a fix ASAP, before the end of the week
> that is due to the latest work done on top of bfields' for-3.2 patch set
> that I merged-in.
>
>> As far as I could see. The last tree that did not have nfsd-3.2
>> new state patches was pnfs-all-3.1-rc8-2011-10-06.
>>
>> pnfs-all-3.1-rc9-2011-10-17 Had some of them, but I guess not the major
>> ones. (Should I test with this one?)
>
> Correct. This version should be fine as it doesn't contain the stuff
> I mentioned above. (looking at alloc_init_layout_state() tells)
>
>>
>> And pnfs-all-3.1-rc10-2011-10-18 (pnfs/pnfs-all-latest) has all of them.
>> Is it stable?
>
> Nope, I sent it out during the Bakeathon hoping I'd be able to stabilize it
> on the spot but failed to do so.
>
>>
>> My last heavy testing was actually on pnfs-all-3.1-rc6-2011-09-20. If I diff
>> that with pnfs-all-3.1-rc8-2011-10-06 on fs/nfsd/ I can still see huge amount
>> of for-nfsd-v3.2 changes. I know you have found some bugs, So I guess I'll stick
>> with the v3.1-rc6-pnfs based tree for the Server and v3.1 release Kernel + ore-v3.2
>> patches.
>
> Sounds like a valid plan, though I always appreciate testing of the latest code
> where possible. So if your testing with the older version goes fine and you still
> have some spare cycles to test the latest stable one it would be awesome.
>
>>
>> Do you think you will release a 3.1 based pnfs tree that is completely based on
>> the v3.1-nfsd version and the old pnfs tree, without any for-v3.2-pnfsd patches?
>
> No, I'll stabilize it as it is. It seems scary because of the use-after-free bug trashes
> memory and causes havoc but it ain't so bad...
>
> Benny
>
>>
>> Thanks
>> Boaz
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: root paths in packages
From: Mark Hatle @ 2011-10-31 17:12 UTC (permalink / raw)
To: yocto
In-Reply-To: <CALs2vtdUjnMxtTfhqPB2Teui4ZKmzzxRWfBxgU=qG9giUFAwrg@mail.gmail.com>
On 10/31/11 5:57 AM, Mike Tsukerman wrote:
> Hello,
>
> I've build rpm packages and met some interesting things.
> In the rpm all scripts and files include root paths from machine that i've build on.
> how can i change that?
Examples of the problem are definitely needed. There are some cases where
embedded paths simply refer to the place on the disk a source file or similar
came from during the build. Depending on where these references are, they may
be considered safe and acceptable. However, in most places something like this
would be considered an error.
--Mark
> --
> Best regards, Mike Tsukerman
>
> jabber: miketsukerman@gmail.com <mailto:miketsukerman@gmail.com>
> jabber: warzon@jabnet.org <mailto:warzon@jabnet.org>
> skype: w_a_r_z_o_n
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply
* [PATCH v2] drm: add some comments to drm_wait_vblank and drm_queue_vblank_event
From: Ilija Hadzic @ 2011-10-31 17:11 UTC (permalink / raw)
To: airlied, dri-devel
during the review of the fix for locks problems in drm_wait_vblank,
a couple of false concerns were raised about how the drm_vblank_get
and drm_vblank_put are used in this function; it turned out that the
code is correct and that it cannot be simplified
add a few comments to explain non-obvious flows in the code,
to prevent "false alarms" in the future
v2: incorporate comments received from Daniel Vetter
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
---
drivers/gpu/drm/drm_irq.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3830e9e..79c02da 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1124,6 +1124,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, int pipe,
trace_drm_vblank_event_delivered(current->pid, pipe,
vblwait->request.sequence);
} else {
+ /* drm_handle_vblank_events will call drm_vblank_put */
list_add_tail(&e->base.link, &dev->vblank_event_list);
vblwait->reply.sequence = vblwait->request.sequence;
}
@@ -1204,8 +1205,12 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
goto done;
}
- if (flags & _DRM_VBLANK_EVENT)
+ if (flags & _DRM_VBLANK_EVENT) {
+ /* must hold on to the vblank ref until the event fires
+ * drm_vblank_put will be called asynchronously
+ */
return drm_queue_vblank_event(dev, crtc, vblwait, file_priv);
+ }
if ((flags & _DRM_VBLANK_NEXTONMISS) &&
(seq - vblwait->request.sequence) <= (1<<23)) {
--
1.7.7
^ permalink raw reply related
* [RFC PATCH v3 07/10] fadump: Introduce cleanup routine to invalidate /proc/vmcore.
From: Mahesh J Salgaonkar @ 2011-10-31 17:11 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel, Benjamin Herrenschmidt
Cc: Haren Myneni, Eric W. Biederman, Amerigo Wang, Milton Miller,
Anton Blanchard
In-Reply-To: <20111031170200.12259.27663.stgit@mars.in.ibm.com>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
With the firmware-assisted dump support we don't require a reboot when we
are in second kernel after crash. The second kernel after crash is a normal
kernel boot and has knowledge about entire system RAM with the page tables
initialized for entire system RAM. Hence once the dump is saved to disk, we
can just release the reserved memory area for general use and continue
with second kernel as production kernel.
Hence when we release the reserved memory that contains dump data, the
'/proc/vmcore' will not be valid anymore. Hence this patch introduces
a cleanup routine that invalidates and removes the /proc/vmcore file. This
routine will be invoked before we release the reserved dump memory area.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
fs/proc/vmcore.c | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index cd99bf5..fae5526 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -699,3 +699,26 @@ static int __init vmcore_init(void)
return 0;
}
module_init(vmcore_init)
+
+/* Cleanup function for vmcore module. */
+void vmcore_cleanup(void)
+{
+ struct list_head *pos, *next;
+
+ if (proc_vmcore) {
+ remove_proc_entry(proc_vmcore->name, proc_vmcore->parent);
+ proc_vmcore = NULL;
+ }
+
+ /* clear the vmcore list. */
+ list_for_each_safe(pos, next, &vmcore_list) {
+ struct vmcore *m;
+
+ m = list_entry(pos, struct vmcore, list);
+ list_del(&m->list);
+ kfree(m);
+ }
+ kfree(elfcorebuf);
+ elfcorebuf = NULL;
+}
+EXPORT_SYMBOL_GPL(vmcore_cleanup);
^ permalink raw reply related
* [RFC PATCH v3 07/10] fadump: Introduce cleanup routine to invalidate /proc/vmcore.
From: Mahesh J Salgaonkar @ 2011-10-31 17:11 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel, Benjamin Herrenschmidt
Cc: Anton Blanchard, Eric W. Biederman, Milton Miller, Amerigo Wang
In-Reply-To: <20111031170200.12259.27663.stgit@mars.in.ibm.com>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
With the firmware-assisted dump support we don't require a reboot when we
are in second kernel after crash. The second kernel after crash is a normal
kernel boot and has knowledge about entire system RAM with the page tables
initialized for entire system RAM. Hence once the dump is saved to disk, we
can just release the reserved memory area for general use and continue
with second kernel as production kernel.
Hence when we release the reserved memory that contains dump data, the
'/proc/vmcore' will not be valid anymore. Hence this patch introduces
a cleanup routine that invalidates and removes the /proc/vmcore file. This
routine will be invoked before we release the reserved dump memory area.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
fs/proc/vmcore.c | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index cd99bf5..fae5526 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -699,3 +699,26 @@ static int __init vmcore_init(void)
return 0;
}
module_init(vmcore_init)
+
+/* Cleanup function for vmcore module. */
+void vmcore_cleanup(void)
+{
+ struct list_head *pos, *next;
+
+ if (proc_vmcore) {
+ remove_proc_entry(proc_vmcore->name, proc_vmcore->parent);
+ proc_vmcore = NULL;
+ }
+
+ /* clear the vmcore list. */
+ list_for_each_safe(pos, next, &vmcore_list) {
+ struct vmcore *m;
+
+ m = list_entry(pos, struct vmcore, list);
+ list_del(&m->list);
+ kfree(m);
+ }
+ kfree(elfcorebuf);
+ elfcorebuf = NULL;
+}
+EXPORT_SYMBOL_GPL(vmcore_cleanup);
^ permalink raw reply related
* [RFC PATCH v3 06/10] fadump: Add PT_NOTE program header for vmcoreinfo
From: Mahesh J Salgaonkar @ 2011-10-31 17:10 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel, Benjamin Herrenschmidt
Cc: Haren Myneni, Eric W. Biederman, Amerigo Wang, Milton Miller,
Anton Blanchard
In-Reply-To: <20111031170200.12259.27663.stgit@mars.in.ibm.com>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Introduce a PT_NOTE program header that points to physical address of
vmcoreinfo_note buffer declared in kernel/kexec.c. The vmcoreinfo
note buffer is populated during crash_fadump() at the time of system
crash.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kernel/fadump.c | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index c0ecd6a..4d42fe5 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -773,6 +773,19 @@ static void setup_crash_memory_ranges(void)
}
}
+/*
+ * If the given physical address falls within the boot memory region then
+ * return the relocated address that points to the dump region reserved
+ * for saving initial boot memory contents.
+ */
+static inline unsigned long relocate(unsigned long paddr)
+{
+ if (paddr > RMR_START && paddr < fw_dump.boot_memory_size)
+ return fdm.rmr_region.destination_address + paddr;
+ else
+ return paddr;
+}
+
static int create_elfcore_headers(char *bufp)
{
struct elfhdr *elf;
@@ -805,6 +818,22 @@ static int create_elfcore_headers(char *bufp)
/* Increment number of program headers. */
(elf->e_phnum)++;
+ /* setup ELF PT_NOTE for vmcoreinfo */
+ phdr = (struct elf_phdr *)bufp;
+ bufp += sizeof(struct elf_phdr);
+ phdr->p_type = PT_NOTE;
+ phdr->p_flags = 0;
+ phdr->p_vaddr = 0;
+ phdr->p_align = 0;
+
+ phdr->p_paddr = relocate(paddr_vmcoreinfo_note());
+ phdr->p_offset = phdr->p_paddr;
+ phdr->p_memsz = vmcoreinfo_max_size;
+ phdr->p_filesz = vmcoreinfo_max_size;
+
+ /* Increment number of program headers. */
+ (elf->e_phnum)++;
+
/* setup PT_LOAD sections. */
for (i = 0; i < crash_mem_ranges; i++) {
^ permalink raw reply related
* [RFC PATCH v3 06/10] fadump: Add PT_NOTE program header for vmcoreinfo
From: Mahesh J Salgaonkar @ 2011-10-31 17:10 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel, Benjamin Herrenschmidt
Cc: Anton Blanchard, Eric W. Biederman, Milton Miller, Amerigo Wang
In-Reply-To: <20111031170200.12259.27663.stgit@mars.in.ibm.com>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Introduce a PT_NOTE program header that points to physical address of
vmcoreinfo_note buffer declared in kernel/kexec.c. The vmcoreinfo
note buffer is populated during crash_fadump() at the time of system
crash.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kernel/fadump.c | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index c0ecd6a..4d42fe5 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -773,6 +773,19 @@ static void setup_crash_memory_ranges(void)
}
}
+/*
+ * If the given physical address falls within the boot memory region then
+ * return the relocated address that points to the dump region reserved
+ * for saving initial boot memory contents.
+ */
+static inline unsigned long relocate(unsigned long paddr)
+{
+ if (paddr > RMR_START && paddr < fw_dump.boot_memory_size)
+ return fdm.rmr_region.destination_address + paddr;
+ else
+ return paddr;
+}
+
static int create_elfcore_headers(char *bufp)
{
struct elfhdr *elf;
@@ -805,6 +818,22 @@ static int create_elfcore_headers(char *bufp)
/* Increment number of program headers. */
(elf->e_phnum)++;
+ /* setup ELF PT_NOTE for vmcoreinfo */
+ phdr = (struct elf_phdr *)bufp;
+ bufp += sizeof(struct elf_phdr);
+ phdr->p_type = PT_NOTE;
+ phdr->p_flags = 0;
+ phdr->p_vaddr = 0;
+ phdr->p_align = 0;
+
+ phdr->p_paddr = relocate(paddr_vmcoreinfo_note());
+ phdr->p_offset = phdr->p_paddr;
+ phdr->p_memsz = vmcoreinfo_max_size;
+ phdr->p_filesz = vmcoreinfo_max_size;
+
+ /* Increment number of program headers. */
+ (elf->e_phnum)++;
+
/* setup PT_LOAD sections. */
for (i = 0; i < crash_mem_ranges; i++) {
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.