For the architectures with it's own module_alloc(), if module init
size is zero, avoiding module_alloc_update_bounds() and memset()
no-op calls also eliminates warn_alloc_failed() zero-size warning
in __vmalloc_node_range().
Signed-off-by: Dmitry Antipov <dmitry.antipov(a)linaro.org>
---
kernel/module.c | 31 +++++++++++++++++--------------
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 2c93276..bbe1c5b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2644,20 +2644,23 @@ static int move_module(struct module *mod, struct load_info *info)
memset(ptr, 0, mod->core_size);
mod->module_core = ptr;
- ptr = module_alloc_update_bounds(mod->init_size);
- /*
- * The pointer to this block is stored in the module structure
- * which is inside the block. This block doesn't need to be
- * scanned as it contains data and code that will be freed
- * after the module is initialized.
- */
- kmemleak_ignore(ptr);
- if (!ptr && mod->init_size) {
- module_free(mod, mod->module_core);
- return -ENOMEM;
- }
- memset(ptr, 0, mod->init_size);
- mod->module_init = ptr;
+ if (mod->init_size) {
+ ptr = module_alloc_update_bounds(mod->init_size);
+ /*
+ * The pointer to this block is stored in the module structure
+ * which is inside the block. This block doesn't need to be
+ * scanned as it contains data and code that will be freed
+ * after the module is initialized.
+ */
+ kmemleak_ignore(ptr);
+ if (!ptr) {
+ module_free(mod, mod->module_core);
+ return -ENOMEM;
+ }
+ memset(ptr, 0, mod->init_size);
+ mod->module_init = ptr;
+ } else
+ mod->module_init = NULL;
/* Transfer each section which specifies SHF_ALLOC */
pr_debug("final section addresses:\n");
--
1.7.7.5
Hi everyone,
Any chance the linux-linaro-*-lt-samsung kernel trees will get updated
(soon)? By the way, is there a daily/nightly build source for these trees? I
am eager to try them out.
TIA - Vic
Gents,
For some time now I am trying to build android from the linaro repos.
Sofar I never succedded, it always resulted in build failures or it doesn't
boot.
So what did it do:
I tried the 11.12 release staging and tracking. Got the last to build after
switching to the 4.6 toolchain (nowhere documented) and
added an include to the png.c file (it misted a math.h include, weird).
It only didn't boot correctly because the kernel failed to initialise the
GPU.
So I switched to the 12.01 release. First used the "release-12.01" branch,
build failure. Then switched to the "linaro_android_4.0.3" branch
Used the same as mentioned in the build service build overview. Also used
the same setup as mentioned in the build service.
Build fails.
Odd thing is that someone must be able to get a successfull build because
ready available images do exist.
So how did these get build? How do I get a good build?
Cheers,
Hedwin
PS, below the build error in the 12.01 release:
workCoreTests_install_verifier_good_intermediates/package.apk)
com.google.doclava.apicheck.ApiParseException: Error parsing API
at
com.google.doclava.apicheck.XmlApiFile.parseApi(XmlApiFile.java:60)
at com.google.doclava.apicheck.ApiCheck.parseApi(ApiCheck.java:152)
at
com.google.doclava.apicheck.ApiCheck.convertToXml(ApiCheck.java:234)
at com.google.doclava.apicheck.ApiCheck.main(ApiCheck.java:64)
Caused by: org.xml.sax.SAXParseException: Content is not allowed in prolog.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388)
at
com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1039)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at
com.google.doclava.apicheck.XmlApiFile.parseApi(XmlApiFile.java:54)
... 3 more
Error parsing API: frameworks/base/api/current.txt
make: *** [out/target/common/obj/APPS/SignatureTest_intermediates/api.xml]
Error 1
make: *** Waiting for unfinished jobs....
Enclosed please find the link to the Weekly Status report & meeting
minutes
for the Power Management working group for the week ending 2012-01-27
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2012-01-26
== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2012-01-25
== Summary ==
(For details, see the Weekly Status Report and Meeting Minutes )
* Linaro Connect sessions planning & setup
* http://summit.ubuntu.com/lcq1-12/track/linaro-power/
* Common Clock
* Working on changing the code based on feedback from v2-v4 submission,
quite a bit of code change for v5.
* About 50% done on converting OMAP4 to use the new code.
* Thermal Management
* Working on fine tuning of cpufreq/cpuhotplug based cooling devices to
be now instance based (needed for multi core systems)
* Submitted V4 of imx thermal driver
* hrtimer
* Continue working on implementing core high-res timers feature to
return time spent in usleep_range()
* cpuidle
* Submitted at91 standby functions
* Implemented cpuidle WFI state for ux500 based on common framework
* Working on dynamic init function for the common cpuidle code will add
to the next version
* Sched_mc
* Preparing for the scheduler mini-summit at Connect
* Taking measurement on the new sched_mc patch before submitting it,
will try to summit the
patch before connect and cc the attendees of the mini-summit
* Issue
* Team is not getting fast enough feedback on their patches.
Best regards,
Mounir
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
HI.
I'm building a LAVA service for running fast models. Quite soon (*)
we'll be ready to open an alpha access. Right now you will need to
bring your own root filesystem and kernel image to use it. With that
in mind I wanted to start a discussion about the state of A15 support
in Linaro kernel(s). I need to understand two things:
1) Are we ready to do automatic builds for A15 kernels?
2) If so, which configs and trees should we consider
Thanks
Zygmunt Krynicki
(I'm aware that there is a thread on linaro-dev discussing this exact
topic; this is a request for specific information, so I decided to start
a new thread)
Hello,
As has been pointed out elsewhere, it is very difficult to find
the exact git tree that corresponds to a kernel release. Currently the
problem I am having is that the 11.11 linaro kernel release
(linux-linaro-lt-omap_3.1.0-1402.5~oneiric1) works well on my new board,
but later kernels do not. While I can download the kernel tarball for
3.1.0-1402.5 from launchpad, I would much prefer to use the git tree
that it was produced from. Can anybody tell me exactly which git tree
was used to create that kernel, and which tag/branch I should be looking at?
Thanks,
--
Chris Lalancette
For everyone who packages kernel trees:
I've had some questions about getting the source for linaro kernel
packaged, and it seems that this is still not straightforward:
Getting the debian package source (i.e., flat tarball) for a binary
kernel is possible, but only if it is a non-superseded version.
Working out which source package you need is non-obvious (You have to
check for installed kernel packages, and guess which source package
you need, based on that. Non-linaro folks may not understand the
difference between the various meta- and real kernel packages and may
get pretty confused along the way.)
Finding the git tree and the relevant commit to reproduce the source
(including that for superseded kernels) is hard or impossible. It
requires guesswork and/or specific knowledge about the way the
relevant team manages their trees. For some platforms, it looks like
there may be no single tree containing the packaged kernel at all, in
which case you would also need more guesswork and/or scripts or help
from the relevant landing team in order actually to reproduce a
release.
Am I correct in these conclusions?
If so, here's a proposal -- I welcome people's comments (and please do
say if any of these problems are actually solved already!):
For every binary kernel package (.deb) publicly released by any linaro
team, including those produced by the platform team and the landing
teams:
1) The source package's control file must contain a Vcs-Git entry
2) The Vcs-Git entry must reference a git tree which contains the
_exact_ source code which appears in the source package.
* Such a tree must exist and must be publicly readable. It does not
have to be on git.linaro.org (though this is the recommended place).
* Referring to git://git.linaro.org/ubuntu/linux-linaro.git is not
acceptable, unless that repo is populated with the real source for
that specific kernel as well as the packaging.
* Manufacturing the source package from the contents of multiple
repositories or branches at source package upload time is not
acceptable, unless the result is also recorded as a tagged commit in
the repository referenced by the Vcs-Git entry in the debian/control
file contained in that same commit. The commit must have full
history: importing tarballs directly into a repository for the purpose
of release tagging is not acceptable.
* Referring to a tree which does not contain the whole contents of
the debian source package (for example, debian/ and other packaging
files/dirs are missing) is not acceptable.
3) Tagging of packaged kernels must be done in a standard way.
* I recommend <source package name>_<package version>, matching the
Source field of debian/control and the version number of the most
recent debian/changelog entry respectively (which must both be present
in the repository as a consequence of (2)). If we want to avoid
namespace pollution, we probably want to add a prefix such as debian/
or ubuntu/ to the tag name to indicate that the tag describes the
source for a published .deb package. If so, we must standardise that
prefix so that it is identical in all out trees.
* Tree maintainers are of course free to add any other additional
tags for their own use if they want to.
All teams already do release tagging of some sort, but the lack of
consistency creates difficulties when anyone from outside the team
tries to understand that team's trees.
* We _could_ standardise the following, but it is not essential:
* ubuntu/<release>: The tagged source for the _original_ kernel
which was distributed in <release> (where <release> is a linaro
monthly release such as 11.12 or 12.01)
4) No specific branch naming requirements exist.
* Release tags do not necessarily need to appear on any branch.
* We _could_ standardise the following, but it is not essential:
* ubuntu/latest - the tagged packaged source for the most recent
kernel release made from this tree
(In the above, we could choose a diferent prefix instead of ubuntu/,
but as described in (3) ,this should be chosen globally and _not_ on a
per-tree basis).
Cheers
---Dave