[GIT PULL] DMA-mapping fixups for v3.6-rc2
Hi Linus, I would like to ask for pulling a set of fixup patches for ARM dma-mapping extensions merged in v3.6-rc1. The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) with the top-most commit d9e0d149b5dcc2ef4688afc572b9906bcda941ef ARM: dma-mapping: fix incorrect freeing of atomic allocations are available in the git repository at: git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git fixes-for-linus-for-3.6-rc2 Thanks! Best regards Marek Szyprowski Samsung Poland R Center Patch summary: Aaro Koskinen (2): ARM: dma-mapping: fix atomic allocation alignment ARM: dma-mapping: fix incorrect freeing of atomic allocations Chris Brand (1): ARM: mm: fix MMU mapping of CMA regions arch/arm/mm/dma-mapping.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] bio: Fix potential memory leak in bio_find_or_create_slab()
Do not leak memory by updating pointer with potentially NULL realloc return
value.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
fs/bio.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/bio.c b/fs/bio.c
index 5eaa70c..3fb4380 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -73,7 +73,7 @@ static struct kmem_cache *bio_find_or_create_slab(unsigned
int extra_size)
{
unsigned int sz = sizeof(struct bio) + extra_size;
struct kmem_cache *slab = NULL;
- struct bio_slab *bslab;
+ struct bio_slab *bslab, *new_bio_slabs;
unsigned int i, entry = -1;
mutex_lock(_slab_lock);
@@ -97,11 +97,12 @@ static struct kmem_cache *bio_find_or_create_slab(unsigned
int extra_size)
if (bio_slab_nr == bio_slab_max && entry == -1) {
bio_slab_max <<= 1;
- bio_slabs = krealloc(bio_slabs,
-bio_slab_max * sizeof(struct bio_slab),
-GFP_KERNEL);
- if (!bio_slabs)
+ new_bio_slabs = krealloc(bio_slabs,
+bio_slab_max * sizeof(struct bio_slab),
+GFP_KERNEL);
+ if (!new_bio_slabs)
goto out_unlock;
+ bio_slabs = new_bio_slabs;
}
if (entry == -1)
entry = bio_slab_nr++;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/5] perf script: Add event_analyzing_sample.py as a sample for general event handling
On Thu, 9 Aug 2012 13:28:43 +0800, Feng Tang wrote: > On Thu, 9 Aug 2012 14:19:29 +0900 >> Btw, by any chance do you plan to add support to callchains? I think >> it's very nice to have. > > No, it's not on the plan list :). My next plan is to integrate the perf > script to the perf report framework, so that users can directly call > perf script inside perf report browser like running the annotation. > Sounds cool! Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] perf script python: Correct handler check and spelling errors
>From efbf00591514aa1d6134a3b940dc627d1a7cc8f8 Mon Sep 17 00:00:00 2001
From: Feng Tang
Date: Thu, 9 Aug 2012 12:50:56 +0800
Subject: [PATCH] perf script python: Correct handler check and spelling errors
Correct the checking for handler returned by PyDict_GetItemString(), also
fix some spelling error and remove some data code in event_analyzing_sample.py,
as suggested by Namhyung Kim.
v2: restore back the wrongly removed trace_unhandled() func
Signed-off-by: Feng Tang
---
.../Perf-Trace-Util/lib/Perf/Trace/EventClass.py |4 +-
.../perf/scripts/python/event_analyzing_sample.py | 30 ---
.../util/scripting-engines/trace-event-python.c|8 ++---
3 files changed, 18 insertions(+), 24 deletions(-)
diff --git
a/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
index 6372431..9e09857 100755
--- a/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
+++ b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
@@ -1,12 +1,12 @@
# EventClass.py
#
-# This is a libray defining some events typs classes, which could
+# This is a library defining some events types classes, which could
# be used by other scripts to analyzing the perf samples.
#
# Currently there are just a few classes defined for examples,
# PerfEvent is the base class for all perf event sample, PebsEvent
# is a HW base Intel x86 PEBS event, and user could add more SW/HW
-# event classes based on requriements.
+# event classes based on requirements.
import struct
diff --git a/tools/perf/scripts/python/event_analyzing_sample.py
b/tools/perf/scripts/python/event_analyzing_sample.py
index 46f05aa..163c39f 100644
--- a/tools/perf/scripts/python/event_analyzing_sample.py
+++ b/tools/perf/scripts/python/event_analyzing_sample.py
@@ -1,15 +1,15 @@
-# process_event.py: general event handler in python
+# event_analyzing_sample.py: general event handler in python
#
-# Current perf report is alreay very powerful with the anotation integrated,
+# Current perf report is already very powerful with the annotation integrated,
# and this script is not trying to be as powerful as perf report, but
# providing end user/developer a flexible way to analyze the events other
# than trace points.
#
# The 2 database related functions in this script just show how to gather
# the basic information, and users can modify and write their own functions
-# according to their specific requirment.
+# according to their specific requirement.
#
-# The first sample "show_general_events" just does a baisc grouping for all
+# The first function "show_general_events" just does a basic grouping for all
# generic events with the help of sqlite, and the 2nd one "show_pebs_ll" is
# for a x86 HW PMU event: PEBS with load latency data.
#
@@ -85,7 +85,7 @@ def process_event(param_dict):
else:
symbol = "Unknown_symbol"
-# Creat the event object and insert it to the right table in database
+# Create the event object and insert it to the right table in database
event = create_event(name, comm, dso, symbol, raw_buf)
insert_db(event)
@@ -109,7 +109,7 @@ def trace_end():
#
# As the event number may be very big, so we can't use linear way
-# to show the histgram in real number, but use a log2 algorithm.
+# to show the histogram in real number, but use a log2 algorithm.
#
def num2sym(num):
@@ -130,18 +130,18 @@ def show_general_events():
# Group by thread
commq = con.execute("select comm, count(comm) from gen_events group by
comm order by -count(comm)")
-print "\n%16s %8s %16s\n%s" % ("comm", "number", "histgram", "="*42)
+print "\n%16s %8s %16s\n%s" % ("comm", "number", "histogram", "="*42)
for row in commq:
print "%16s %8d %s" % (row[0], row[1], num2sym(row[1]))
# Group by symbol
-print "\n%32s %8s %16s\n%s" % ("symbol", "number", "histgram", "="*58)
+print "\n%32s %8s %16s\n%s" % ("symbol", "number", "histogram", "="*58)
symbolq = con.execute("select symbol, count(symbol) from gen_events
group by symbol order by -count(symbol)")
for row in symbolq:
print "%32s %8d %s" % (row[0], row[1], num2sym(row[1]))
# Group by dso
-print "\n%40s %8s %16s\n%s" % ("dso", "number", "histgram", "="*74)
+print "\n%40s %8s %16s\n%s" % ("dso", "number", "histogram", "="*74)
dsoq = con.execute("select dso, count(dso) from gen_events group by
dso order by -count(dso)")
for row in dsoq:
print "%40s %8d %s" % (row[0], row[1], num2sym(row[1]))
@@ -163,31 +163,27 @@ def show_pebs_ll():
# Group by thread
commq = con.execute("select comm, count(comm) from pebs_ll group by
comm order by -count(comm)")
-print "\n%16s %8s %16s\n%s" % ("comm", "number",
Re: [PATCH] pwm: Add missing static storage class specifiers in core.c file
On Thu, Aug 02, 2012 at 12:32:42PM +0530, Sachin Kamat wrote: > Fixes the following sparse warnings: > drivers/pwm/core.c:152:6: warning: > symbol 'of_pwmchip_add' was not declared. Should it be static? > drivers/pwm/core.c:165:6: warning: > symbol 'of_pwmchip_remove' was not declared. Should it be static? > > Signed-off-by: Sachin Kamat > --- > drivers/pwm/core.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) Applied, thanks. Thierry pgppAdlYOp6R9.pgp Description: PGP signature
Re: [PATCH v2] pwm: Add support for configuring the PWM polarity
On Tue, Jul 24, 2012 at 07:35:32PM +0530, Philip, Avinash wrote: > Some hardware supports inverting the polarity of the PWM signal. This > commit adds support to the PWM framework to allow users of the PWM API > to configure the polarity. Note that in order to reduce complexity, > changing the polarity of a PWM signal is only allowed while the PWM is > disabled. > > A practical example where this can prove useful is to simulate inversion > of the duty cycle. While inversion of polarity and duty cycle are not > exactly the same, the differences for most use-cases are negligible. > > Signed-off-by: Philip, Avinash > --- > changes in V2: > - Updates commit message > - Provides proper comments > - Removes usage of polarity variable. > - Removes encoding of polarity in flags > > Configuring polarity to be done with PWM device disabled, if not failure > reported. > > If PWM device is enabled while configuring polarity, disabling and > re_enabling make it complex. Whoever uses this API has to taken care of > the basic rules. > > Discussions related to this can found at > http://www.spinics.net/lists/kernel/msg1372110.html > > :100644 100644 ecb7690... f0a1db3... Mdrivers/pwm/core.c > :100644 100644 21d076c... 354764c... Minclude/linux/pwm.h > drivers/pwm/core.c | 22 ++ > include/linux/pwm.h | 23 +++ > 2 files changed, 45 insertions(+), 0 deletions(-) Applied, thanks. Thierry pgpaeDanjES9Q.pgp Description: PGP signature
Re: [PATCH v2] pwm: add devm_pwm_get() and devm_pwm_put()
On Wed, Aug 01, 2012 at 07:20:58PM +0900, Alexandre Courbot wrote: > Add resource managed variants of pwm_get() and pwm_put() for > convenience. Code is largely inspired by the equivalent devm functions > of the regulator framework. > > Signed-off-by: Alexandre Courbot Applied, with minor editorial fixups. Thanks. Thierry pgpT3iP2rTCIZ.pgp Description: PGP signature
Re: [PATCH v2 1/3] pwm: samsung: add missing device pointer to struct pwm_chip
On Fri, Aug 03, 2012 at 03:45:56PM +0900, Jingoo Han wrote: > This patch adds missing device pointer to struct pwm_chip. If the > device pointer is NULL, pwmchip_add() will return error. > > Signed-off-by: Jingoo Han Thanks, applied to for-next and master. Thierry pgpACRUwaGRj5.pgp Description: PGP signature
Re: [PATCH] pwm: Remove a redundant error message when devm_request_and_ioremap fails
On Fri, Aug 03, 2012 at 09:43:54PM +0800, Axel Lin wrote: > The implementation in devm_request_and_ioremap() already shows error message, > so no need to show dev_err again if devm_request_and_ioremap() fails. > > Signed-off-by: Axel Lin > Cc: Stephen Warren > Cc: Philip, Avinash > --- Applied, thanks. I'll carry this in for-next and master. I collect fixes in the latter and plan to submit them for 3.6. Thierry pgptvELDDfiFe.pgp Description: PGP signature
Re: [PATCH] perf script python: Correct handler check and spelling errors
On Thu, 9 Aug 2012 13:24:01 +0800, Feng Tang wrote:
> From 3332f03c6e8f641e26430a25704c364c2f30d833 Mon Sep 17 00:00:00 2001
> From: Feng Tang
> Date: Thu, 9 Aug 2012 12:50:56 +0800
> Subject: [PATCH] perf script python: Correct handler check and spelling errors
>
> Correct the checking for handler returned by PyDict_GetItemString(), also
> fix some spelling error and remove some data code in
> event_analyzing_sample.py,
> as suggested by Namhyung Kim.
>
> Signed-off-by: Feng Tang
> ---
[SNIP]
> -
> -def trace_unhandled(event_name, context, event_fields_dict):
> - print ' '.join(['%s=%s'%(k,str(v))for k,v in
> sorted(event_fields_dict.items())])
I guess we need to have the trace_unhandled as a safety net since it can
be called from the scripting-engine?
Thanks,
Namhyung
> -
> -def print_header(event_name, cpu, secs, nsecs, pid, comm):
> - print "%-20s %5u %05u.%09u %8u %-20s " % \
> - (event_name, cpu, secs, nsecs, pid, comm),
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
> b/tools/perf/util/scripting-engines/trace-event-python.c
> index 7e3f576..afba097 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> @@ -343,7 +343,7 @@ static void python_process_general_event(union perf_event
> *perf_event __unused,
>struct perf_sample *sample,
>struct perf_evsel *evsel,
>struct machine *machine __unused,
> - struct addr_location *al __unused)
> + struct addr_location *al)
> {
> PyObject *handler, *retval, *t, *dict;
> static char handler_name[64];
> @@ -352,7 +352,7 @@ static void python_process_general_event(union perf_event
> *perf_event __unused,
>
> /*
>* Use the MAX_FIELDS to make the function expandable, though
> - * currently there is only one itme for the tuple.
> + * currently there is only one item for the tuple.
>*/
> t = PyTuple_New(MAX_FIELDS);
> if (!t)
> @@ -365,10 +365,8 @@ static void python_process_general_event(union
> perf_event *perf_event __unused,
> snprintf(handler_name, sizeof(handler_name), "%s", "process_event");
>
> handler = PyDict_GetItemString(main_dict, handler_name);
> - if (handler && !PyCallable_Check(handler)) {
> - handler = NULL;
> + if (!handler || !PyCallable_Check(handler))
> goto exit;
> - }
>
> PyDict_SetItemString(dict, "ev_name",
> PyString_FromString(perf_evsel__name(evsel)));
> PyDict_SetItemString(dict, "attr", PyString_FromStringAndSize(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: snd_hda_intel bug during boot
Hi, Yes it used to work with 2.6 kernel. Ok I will do a bisect and try to find the source of the problem. I'll notify you if I'll find something but don't expect it to be fast cause the problem happens on my home laptop (pretty old and rusty :) ) and I also have a lot of other stuff to do. Regards, Alexei 2012/8/8 Jesper Juhl : > On Wed, 8 Aug 2012, Jesper Juhl wrote: > >> On Wed, 8 Aug 2012, Alexei Kornienko wrote: >> >> > Seems like I have a bug in audio driver on my laptop. Cause of this I >> > don't have any sound card detected. >> > Please find more details below: >> > >> > ** Version: >> > Linux version 3.2.0-29-generic-pae (buildd@roseapple) (gcc version >> > 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #46-Ubuntu SMP Fri Jul 27 >> > 17:25:43 UTC 2012 >> > >> Ok, so I openly admit that I have no clue as to what your problem might >> be. But, one thing I do know is that, a *lot* has changed since the 3.2 >> kernel you are running and the most recent stable (3.5) kernel. So, >> perhaps you could test the 3.5 kernel and tell us if you still see the >> problem with that one or not? >> If you are feeling adventurous you could also try a snapshot of the latest >> Linus (to become 3.6) kernel and tell us your experiences with that...? >> > Also, if this used to work with an older kernel, then it would probably > be helpful if you could do a "git bisect" between the older (working) > kernel version and your current (broken) kernel version in order to zoom > in on the commit that broke things for you. > > -- > Jesper Juhlhttp://www.chaosbits.net/ > Don't top-post http://www.catb.org/jargon/html/T/top-post.html > Plain text mails only, please. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/5] perf script: Add event_analyzing_sample.py as a sample for general event handling
On Thu, 9 Aug 2012 14:19:29 +0900
Namhyung Kim wrote:
> Hi,
>
> On Thu, 9 Aug 2012 12:30:07 +0800, Feng Tang wrote:
> > Hi Namhyung,
> >
> > Many thanks for your valuable comments, I'll fold the fixes into an
> > incremental patch.
> >
> > On Thu, 9 Aug 2012 10:30:34 +0900
> > Namhyung Kim wrote:
> >
> >> On Wed, 8 Aug 2012 17:57:55 +0800, Feng Tang wrote:
> >> > Currently only trace point events are supported in perf/python script,
> >> > the first 3 patches of this serie add the support for all types of
> >>
> >
> >> > +con = sqlite3.connect("/dev/shm/perf.db")
> >> > +con.isolation_level = None
> >> > +
> >> > +def trace_begin():
> >> > +print "In trace_begin:\n"
> >>
> >> It seems it's not aligned with other statements, and even not needed at
> >> all. Does it work?
> >
> > trace_begin() is a must have for a python script, the > trace_begin:\n"> is automatically generated from "perf script -g", I guess
> > its intension is to help developer debug their own patches. and same for
> > the trace_end().
> >
> I meant the print statement not trace_begin function :)
I see
>
> Btw, by any chance do you plan to add support to callchains? I think
> it's very nice to have.
No, it's not on the plan list :). My next plan is to integrate the perf
script to the perf report framework, so that users can directly call
perf script inside perf report browser like running the annotation.
Thanks,
Feng
>
> Thanks,
> Namhyung
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma-buf: add reference counting for exporter module
Hi Tomasz, On 8 August 2012 19:36, Daniel Vetter wrote: > On Wed, Aug 08, 2012 at 03:53:10PM +0200, Tomasz Stanislawski wrote: >> Hi Laurent, >> >> On 08/08/2012 03:35 PM, Laurent Pinchart wrote: >> > Hi Tomasz, >> > >> > Thanks for the patch. Thanks for the patch; may I ask you to split it into 2 patches (1 dma-buf and 1 drm) and submit? That ways, either Dave or I can take the patches for either pull request. With that, please feel free to add my Acked-by as well. >> > >> > On Wednesday 08 August 2012 12:17:41 Tomasz Stanislawski wrote: >> >> This patch adds reference counting on a module that exports dma-buf and >> >> implements its operations. This prevents the module from being unloaded >> >> while DMABUF file is in use. >> >> >> >> Signed-off-by: Tomasz Stanislawski >> >> --- >> >> Documentation/dma-buf-sharing.txt |3 ++- >> >> drivers/base/dma-buf.c | 10 +- >> >> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 + >> >> drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 + >> >> drivers/gpu/drm/nouveau/nouveau_prime.c|1 + >> >> drivers/gpu/drm/radeon/radeon_prime.c |1 + >> >> drivers/staging/omapdrm/omap_gem_dmabuf.c |1 + >> >> include/linux/dma-buf.h|2 ++ >> >> 8 files changed, 18 insertions(+), 2 deletions(-) >> >> >> [snip] >> >> >> @@ -96,6 +98,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct >> >> dma_buf_ops *ops, struct file *file; >> >> >> >>if (WARN_ON(!priv || !ops >> >> +|| !ops->owner >> >> Thank you for spotting this. >> I didn'y know that try_get_module returned true is module was NULL. >> >> BTW. Is it worth to add ".owner = THIS_MODULE," to all dma_buf >> exporters in this patch? > > Yeah, I think that makes sense. Otherwise it might get lost somewhere, > i.e. you can smash my Ack on this. > -Daniel > -- > Daniel Vetter > Mail: dan...@ffwll.ch > Mobile: +41 (0)79 365 57 48 -- Thanks and regards, Sumit Semwal. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/6] ARM: s3c24xx: use new PWM driver
Arnd Bergmann wrote: > > On Wednesday 08 August 2012, Kukjin Kim wrote: > > > diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach- > s3c24xx/Kconfig > > index e249611..d56b0f7 100644 > > --- a/arch/arm/mach-s3c24xx/Kconfig > > +++ b/arch/arm/mach-s3c24xx/Kconfig > > @@ -483,7 +483,7 @@ config MACH_NEO1973_GTA02 > > select I2C > > select POWER_SUPPLY > > select MACH_NEO1973 > > - select S3C2410_PWM > > + select S3C24XX_PWM > > select S3C_DEV_USB_HOST > > help > >Say Y here if you are using the Openmoko GTA02 / Freerunner GSM > > Phone > > @@ -493,7 +493,7 @@ config MACH_RX1950 > > select S3C24XX_DCLK > > select PM_H1940 if PM > > select I2C > > - select S3C2410_PWM > > + select S3C24XX_PWM > > select S3C_DEV_NAND > > select S3C2410_IOTIMING if S3C2440_CPUFREQ > > select S3C2440_XTAL_16934400 > > diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat- > samsung/Kconfig > > index 7aca31c..dcdfb77 100644 > > --- a/arch/arm/plat-samsung/Kconfig > > +++ b/arch/arm/plat-samsung/Kconfig > > @@ -403,7 +403,7 @@ config S5P_DEV_USB_EHCI > > > > config S3C24XX_PWM > > bool "PWM device support" > > - select HAVE_PWM > > + select PWM > > help > > Support for exporting the PWM timer blocks via the pwm device > > system > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > > index 8fc3808..c74d055 100644 > > --- a/drivers/pwm/Kconfig > > +++ b/drivers/pwm/Kconfig > > @@ -58,14 +58,12 @@ config PWM_PXA > > will be called pwm-pxa. > > > > config PWM_SAMSUNG > > - tristate "Samsung pwm support" > > + bool "Samsung PWM support" > > depends on PLAT_SAMSUNG > > + default y > > help > > Generic PWM framework driver for Samsung. > > > > - To compile this driver as a module, choose M here: the module > > - will be called pwm-samsung. > > - > > config PWM_TEGRA > > tristate "NVIDIA Tegra PWM support" > > depends on ARCH_TEGRA > > This approach has two disadvantages compared to mine: > > * When building for the samsung platforms other than rx1950 or gta02, > you can no longer have the PWM driver as a loadable module, for no > good reason. > OK I see, I'm still thinking the PWM driver can be selected in kernel menuconfig though. My concept is when PWM is selected on Samsung platforms by defconfig or manually enabling, PWM_SAMSUNG is selected automatically. In addition, current Samsung PWM driver cannot support module now because pwm_init() is called by arch_initcall(). I think, we can remove S3C24XX_PWM and just select PWM (or using HAVE_PWM) and PWM_SAMSUNG can be selected by enabling PWM in samsung platform next time :-) > * It is still possible to manually disable PWM_SAMSUNG, even on > rx1950 and gta02, because the Kconfig symbol is visible. > Yeah you're right, makes sense. > I've added a "Reported-by: Tushar Behera " > line to my version of the patch, but I would prefer to keep that > approach. I have also changed the patch to use the S3C24XX_PWM > symbol because that lets everyone migrate the defconfig files. > OK. > Do you want to give this patch some more testing, or should I keep > it in arm-soc? > Looks good to me, please keep going on. > --- > From 438b0cf94adb2528bdeeb71314f7be16512ea5b1 Mon Sep 17 00:00:00 2001 > From: Arnd Bergmann > Date: Sat, 4 Aug 2012 07:52:19 + > Subject: [PATCH] ARM: s3c24xx: use new PWM driver > > The samsung PWM driver has moved to the new PWM subsystem, which > changed the Kconfig symbol for that driver, but the rx1950 and > gta02 boards still uses the old one. > > Without this patch, building s3c2410_defconfig results in: > > arch/arm/mach-s3c24xx/built-in.o: In function `rx1950_lcd_power': > arch/arm/mach-s3c24xx/mach-rx1950.c:430: undefined reference to > `pwm_config' > arch/arm/mach-s3c24xx/mach-rx1950.c:431: undefined reference to > `pwm_disable' > arch/arm/mach-s3c24xx/mach-rx1950.c:437: undefined reference to > `pwm_config' > arch/arm/mach-s3c24xx/mach-rx1950.c:438: undefined reference to > `pwm_enable' > arch/arm/mach-s3c24xx/built-in.o: In function `rx1950_backlight_exit': > arch/arm/mach-s3c24xx/mach-rx1950.c:504: undefined reference to `pwm_free' > arch/arm/mach-s3c24xx/built-in.o: In function `rx1950_backlight_init': > arch/arm/mach-s3c24xx/mach-rx1950.c:487: undefined reference to > `pwm_request' > > Signed-off-by: Arnd Bergmann > Reported-by: Tushar Behera > Cc: Kukjin Kim > Acked-by: Kukjin Kim Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig > index e249611..d56b0f7 100644 > --- a/arch/arm/mach-s3c24xx/Kconfig > +++ b/arch/arm/mach-s3c24xx/Kconfig > @@ -483,7 +483,7 @@ config MACH_NEO1973_GTA02 > select I2C > select POWER_SUPPLY > select MACH_NEO1973 > - select S3C2410_PWM > + select S3C24XX_PWM > select
[PATCH] perf script python: Correct handler check and spelling errors
>From 3332f03c6e8f641e26430a25704c364c2f30d833 Mon Sep 17 00:00:00 2001
From: Feng Tang
Date: Thu, 9 Aug 2012 12:50:56 +0800
Subject: [PATCH] perf script python: Correct handler check and spelling errors
Correct the checking for handler returned by PyDict_GetItemString(), also
fix some spelling error and remove some data code in event_analyzing_sample.py,
as suggested by Namhyung Kim.
Signed-off-by: Feng Tang
---
.../Perf-Trace-Util/lib/Perf/Trace/EventClass.py |4 +-
.../perf/scripts/python/event_analyzing_sample.py | 33
.../util/scripting-engines/trace-event-python.c|8 ++---
3 files changed, 18 insertions(+), 27 deletions(-)
diff --git
a/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
index 6372431..9e09857 100755
--- a/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
+++ b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
@@ -1,12 +1,12 @@
# EventClass.py
#
-# This is a libray defining some events typs classes, which could
+# This is a library defining some events types classes, which could
# be used by other scripts to analyzing the perf samples.
#
# Currently there are just a few classes defined for examples,
# PerfEvent is the base class for all perf event sample, PebsEvent
# is a HW base Intel x86 PEBS event, and user could add more SW/HW
-# event classes based on requriements.
+# event classes based on requirements.
import struct
diff --git a/tools/perf/scripts/python/event_analyzing_sample.py
b/tools/perf/scripts/python/event_analyzing_sample.py
index 46f05aa..1bc 100644
--- a/tools/perf/scripts/python/event_analyzing_sample.py
+++ b/tools/perf/scripts/python/event_analyzing_sample.py
@@ -1,15 +1,15 @@
-# process_event.py: general event handler in python
+# event_analyzing_sample.py: general event handler in python
#
-# Current perf report is alreay very powerful with the anotation integrated,
+# Current perf report is already very powerful with the annotation integrated,
# and this script is not trying to be as powerful as perf report, but
# providing end user/developer a flexible way to analyze the events other
# than trace points.
#
# The 2 database related functions in this script just show how to gather
# the basic information, and users can modify and write their own functions
-# according to their specific requirment.
+# according to their specific requirement.
#
-# The first sample "show_general_events" just does a baisc grouping for all
+# The first function "show_general_events" just does a basic grouping for all
# generic events with the help of sqlite, and the 2nd one "show_pebs_ll" is
# for a x86 HW PMU event: PEBS with load latency data.
#
@@ -85,7 +85,7 @@ def process_event(param_dict):
else:
symbol = "Unknown_symbol"
-# Creat the event object and insert it to the right table in database
+# Create the event object and insert it to the right table in database
event = create_event(name, comm, dso, symbol, raw_buf)
insert_db(event)
@@ -109,7 +109,7 @@ def trace_end():
#
# As the event number may be very big, so we can't use linear way
-# to show the histgram in real number, but use a log2 algorithm.
+# to show the histogram in real number, but use a log2 algorithm.
#
def num2sym(num):
@@ -130,18 +130,18 @@ def show_general_events():
# Group by thread
commq = con.execute("select comm, count(comm) from gen_events group by
comm order by -count(comm)")
-print "\n%16s %8s %16s\n%s" % ("comm", "number", "histgram", "="*42)
+print "\n%16s %8s %16s\n%s" % ("comm", "number", "histogram", "="*42)
for row in commq:
print "%16s %8d %s" % (row[0], row[1], num2sym(row[1]))
# Group by symbol
-print "\n%32s %8s %16s\n%s" % ("symbol", "number", "histgram", "="*58)
+print "\n%32s %8s %16s\n%s" % ("symbol", "number", "histogram", "="*58)
symbolq = con.execute("select symbol, count(symbol) from gen_events
group by symbol order by -count(symbol)")
for row in symbolq:
print "%32s %8d %s" % (row[0], row[1], num2sym(row[1]))
# Group by dso
-print "\n%40s %8s %16s\n%s" % ("dso", "number", "histgram", "="*74)
+print "\n%40s %8s %16s\n%s" % ("dso", "number", "histogram", "="*74)
dsoq = con.execute("select dso, count(dso) from gen_events group by
dso order by -count(dso)")
for row in dsoq:
print "%40s %8d %s" % (row[0], row[1], num2sym(row[1]))
@@ -163,31 +163,24 @@ def show_pebs_ll():
# Group by thread
commq = con.execute("select comm, count(comm) from pebs_ll group by
comm order by -count(comm)")
-print "\n%16s %8s %16s\n%s" % ("comm", "number", "histgram", "="*42)
+print "\n%16s %8s %16s\n%s" %
[RFC]block: disable discard request merge temporarily
The SCSI discard request merge never worked, and looks no solution for in future, let's disable it temporarily. Signed-off-by: Shaohua Li diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index 4e72a9d..0e6efb1 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -601,7 +601,7 @@ static inline void blk_clear_rl_full(struct request_list *rl, bool sync) * it already be started by driver. */ #define RQ_NOMERGE_FLAGS \ - (REQ_NOMERGE | REQ_STARTED | REQ_SOFTBARRIER | REQ_FLUSH | REQ_FUA) + (REQ_NOMERGE | REQ_STARTED | REQ_SOFTBARRIER | REQ_FLUSH | REQ_FUA | REQ_DISCARD) #define rq_mergeable(rq) \ (!((rq)->cmd_flags & RQ_NOMERGE_FLAGS) && \ (((rq)->cmd_flags & REQ_DISCARD) || \ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/5] perf script: Add event_analyzing_sample.py as a sample for general event handling
Hi,
On Thu, 9 Aug 2012 12:30:07 +0800, Feng Tang wrote:
> Hi Namhyung,
>
> Many thanks for your valuable comments, I'll fold the fixes into an
> incremental patch.
>
> On Thu, 9 Aug 2012 10:30:34 +0900
> Namhyung Kim wrote:
>
>> On Wed, 8 Aug 2012 17:57:55 +0800, Feng Tang wrote:
>> > Currently only trace point events are supported in perf/python script,
>> > the first 3 patches of this serie add the support for all types of
>>
>
>> > +con = sqlite3.connect("/dev/shm/perf.db")
>> > +con.isolation_level = None
>> > +
>> > +def trace_begin():
>> > + print "In trace_begin:\n"
>>
>> It seems it's not aligned with other statements, and even not needed at
>> all. Does it work?
>
> trace_begin() is a must have for a python script, the trace_begin:\n">
> is automatically generated from "perf script -g", I guess its intension is
> to help developer debug their own patches. and same for the trace_end().
>
I meant the print statement not trace_begin function :)
Btw, by any chance do you plan to add support to callchains? I think
it's very nice to have.
Thanks,
Namhyung
>> > +def print_header(event_name, cpu, secs, nsecs, pid, comm):
>> > + print "%-20s %5u %05u.%09u %8u %-20s " % \
>> > + (event_name, cpu, secs, nsecs, pid, comm),
>>
>> It seems this function was not called anywhere.
>
> It is auto-generated too, and you are right, it is not needed at all,
> will remove it.
>
> Thanks,
> Feng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: What happened to TRIM support for raid linear/0/1/10?
2012/8/9 NeilBrown : > On Wed, 8 Aug 2012 13:10:51 + (GMT) Holger Kiehl > wrote: > >> Hello, >> >> I have been using the patches posted by Shaohua Li on 16th March 2012: >> >> http://lkml.indiana.edu/hypermail/linux/kernel/1203.2/00048.html >> >> for several month on a very busy file server (serving 9 million files >> with 5.3 TiB daily) without any problems. >> >> Is there any chance that these patches will go into the official kernel? >> Or what is the reason that these patches are no applied? > > I'm trying to appear to be an incompetent maintainer so that someone will > offer to take over. It isn't working yet. I'm probably scuttling the > attempt just by replying to this email - drat. > >> >> I have attached the patch set in one big patch for 3.5. Please do not >> use it since I am not sure if it is correct. Shaohua could you please >> take a look if it is correct and maybe post a new one? >> >> Personally, I would think that TRIM support MD would be a very good thing. > > Probably. Maybe if they get posted again I'll feel guilty and do something > about them. > > One issue that needs to be fixed is that a few places assumed that the > "discard_zeros_data" flag is always set, which is not the case (else we > wouldn't have that flag). That was only a couple of places though, not a > wide spread problem. The big problem is SATA discard request merge is broken, while doing MD discard will trigger discard request merge. In this form, I bet Neil will not accept the patches. So not the problem MD discard patch itself. Last time Martin said he is working on SCSI discard request merge patches. That isn't happened yet. Maybe I should ping Jens to disable discard request merge currently, it's broken for a long time anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: mutex: hung tasks on SMP platforms with asm-generic/mutex-xchg.h
On Tue, 7 Aug 2012, Will Deacon wrote:
> Hello,
>
> ARM recently moved to asm-generic/mutex-xchg.h for its mutex implementation
> after our previous implementation was found to be missing some crucial
> memory barriers. However, I'm seeing some problems running hackbench on
> SMP platforms due to the way in which the MUTEX_SPIN_ON_OWNER code operates.
>
> The symptoms are that a bunch of hackbench tasks are left waiting on an
> unlocked mutex and therefore never get woken up to claim it. I think this
> boils down to the following sequence:
>
>
> Task ATask BTask CLock value
> 0 1
> 1 lock()0
> 2 lock() 0
> 3 spin(A) 0
> 4 unlock() 1
> 5 lock()0
> 6 cmpxchg(1,0)0
> 7 contended()-1
> 8 lock()0
> 9 spin(C) 0
> 10 unlock() 1
> 11 cmpxchg(1,0) 0
> 12 unlock() 1
>
>
> At this point, the lock is unlocked, but Task B is in an uninterruptible
> sleep with nobody to wake it up.
>
> The following patch fixes the problem by ensuring we put the lock into
> the contended state if we acquire it from the spin loop on the slowpath
> but I'd like to be sure that this won't cause problems with other mutex
> implementations:
>
>
> diff --git a/kernel/mutex.c b/kernel/mutex.c
> index a307cc9..27b7887 100644
> --- a/kernel/mutex.c
> +++ b/kernel/mutex.c
> @@ -170,7 +170,7 @@ __mutex_lock_common(struct mutex *lock, long state,
> unsigned int subclass,
> if (owner && !mutex_spin_on_owner(lock, owner))
> break;
>
> - if (atomic_cmpxchg(>count, 1, 0) == 1) {
> + if (atomic_cmpxchg(>count, 1, -1) == 1) {
> lock_acquired(>dep_map, ip);
> mutex_set_owner(lock);
> preempt_enable();
>
>
> All comments welcome.
Well... after thinking about this for a while, I came to the conclusion
that the mutex_spin_on_owner code is indeed breaking the contract
between the xchg lock fast path and the slow path. The xchg fast path
will always set the count to 0 and rely on the slow path to restore a
possible pre-existing negative count. So the above change would be
needed for correctness in the xchg case, even if it always forces the
unlock into the slow path.
As I mentioned previously, we don't want to force the slow path in all
cases though. The atomic decrement based fast path doesn't need that,
so I'd suggest this fix instead:
diff --git a/include/asm-generic/mutex-xchg.h b/include/asm-generic/mutex-xchg.h
index 580a6d35c7..60964844c8 100644
--- a/include/asm-generic/mutex-xchg.h
+++ b/include/asm-generic/mutex-xchg.h
@@ -108,4 +108,6 @@ __mutex_fastpath_trylock(atomic_t *count, int
(*fail_fn)(atomic_t *))
return prev;
}
+#define __MUTEX_XCHG_FAST_PATH
+
#endif
diff --git a/kernel/mutex.c b/kernel/mutex.c
index a307cc9c95..c6a26a4f1c 100644
--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -161,6 +161,7 @@ __mutex_lock_common(struct mutex *lock, long state,
unsigned int subclass,
for (;;) {
struct task_struct *owner;
+ int locked_val;
/*
* If there's an owner, wait for it to either
@@ -170,7 +171,19 @@ __mutex_lock_common(struct mutex *lock, long state,
unsigned int subclass,
if (owner && !mutex_spin_on_owner(lock, owner))
break;
- if (atomic_cmpxchg(>count, 1, 0) == 1) {
+#ifdef __MUTEX_XCHG_FAST_PATH
+ /*
+* The fast path based on xchg sets a transient 0 count,
+* relying on the slow path to restore a possible
+* pre-existing contended count. Without checking the
+* waiters' list we must presume possible contension here.
+*/
+ locked_val = -1;
+#else
+ locked_val = 0;
+#endif
+
+ if (atomic_cmpxchg(>count, 1, locked_val) == 1) {
lock_acquired(>dep_map, ip);
mutex_set_owner(lock);
preempt_enable();
That would be needed for the stable tree as well.
A further cleanup could remove all definitions of
__mutex_slowpath_needs_to_unlock() given that they're all set to 1
except for the xchg fast path, in which case __MUTEX_XCHG_FAST_PATH
could be reused instead.
Of course that might tilt the balance towards using mutex-dec.h on ARM
v6 and above instead
v3.5 Oops in i2c_algo_bit.c:bit_xfer+0x23/0x870: i915 or i2c?
I'm trying to run a v3.5 kernel (plus some -stable patches from Ted Ts'o) on an Ubuntu system. Things are generally working except for the following Oops on each boot, which prevents the graphics system from loading. [ 36.187972] [drm] Initialized drm 1.1.0 20060810 [ 36.230306] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround [ 36.487606] i915 :00:02.0: setting latency timer to 64 [ 36.555464] [drm] GMBUS [i915 gmbus ssc] timed out, falling back to bit banging on pin 0 [ 36.555490] BUG: unable to handle kernel NULL pointer dereference at 0028 [ 36.555626] IP: [] bit_xfer+0x23/0x870 [i2c_algo_bit] [ 36.555701] PGD 212cb0067 PUD 212caf067 PMD 0 [ 36.555803] Oops: [#1] SMP [ 36.555885] CPU 3 [ 36.555907] Modules linked in: snd_seq_midi joydev i915(+) snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer snd_seq_device kvm_intel drm kvm snd serio_raw soundcore i2c_algo_bit snd_page_alloc lpc_ich video mei microcode mac_hid eeprom it87 hwmon_vid coretemp lp parport raid10 raid456 async_pq async_xor firewire_ohci firewire_core xor async_memcpy async_raid6_recov hid_microsoft floppy crc_itu_t r8169 pata_jmicron usbhid hid mptsas mptscsih mptbase scsi_transport_sas raid6_pq async_tx raid1 raid0 multipath linear [ 36.557232] [ 36.557271] Pid: 623, comm: modprobe Not tainted 3.5.0 #3 Gigabyte Technology Co., Ltd. H57M-USB3/H57M-USB3 [ 36.557398] RIP: 0010:[] [] bit_xfer+0x23/0x870 [i2c_algo_bit] [ 36.557493] RSP: :880212c6d648 EFLAGS: 00010296 [ 36.557544] RAX: 88021222c030 RBX: 880212c6d7e8 RCX: [ 36.557599] RDX: 0001 RSI: 880212c6d7e8 RDI: 88021222c030 [ 36.557655] RBP: 880212c6d6c8 R08: 0402 R09: [ 36.557710] R10: R11: 0006 R12: 0001 [ 36.557766] R13: 880212c6dfd8 R14: 0001 R15: 88021222c030 [ 36.557822] FS: 7f5a7b85b700() GS:88021fcc() knlGS: [ 36.557899] CS: 0010 DS: ES: CR0: 8005003b [ 36.557950] CR2: 0028 CR3: 000212cad000 CR4: 07e0 [ 36.558006] DR0: DR1: DR2: [ 36.558062] DR3: DR6: 0ff0 DR7: 0400 [ 36.558119] Process modprobe (pid: 623, threadinfo 880212c6c000, task 88020fdf5b80) [ 36.558197] Stack: [ 36.558239] 0001 880212c6dfd8 0001 00011222c000 [ 36.558380] 880212c6d6c8 8166341e 88020ff6ca72 000c510c0018 [ 36.558523] 880212c6d6d8 880212c6d698 0082 880212c6d7e8 [ 36.558671] Call Trace: [ 36.558719] [] ? printk+0x61/0x63 [ 36.558790] [] gmbus_xfer+0x56b/0x6f0 [i915] [ 36.558847] [] i2c_transfer+0x9c/0xe0 [ 36.558899] [] ? ep_poll_callback+0x10b/0x150 [ 36.558953] [] i2c_smbus_xfer_emulated+0x156/0x5d0 [ 36.559010] [] ? idr_get_empty_slot+0x115/0x320 [ 36.559064] [] i2c_smbus_xfer+0x113/0x130 [ 36.559118] [] ? _raw_spin_lock+0xe/0x20 [ 36.559173] [] ? klist_next+0x89/0x110 [ 36.559225] [] i2c_default_probe+0xeb/0x130 [ 36.559279] [] ? i2c_check_addr_busy+0x3b/0x60 [ 36.559332] [] i2c_do_add_adapter+0x1bb/0x290 [ 36.559382] [] ? sysfs_do_create_link+0xeb/0x200 [ 36.559433] [] ? put_device+0x17/0x20 [ 36.559482] [] ? __process_new_driver+0x30/0x30 [ 36.559535] [] __process_new_adapter+0x12/0x20 [ 36.559590] [] bus_for_each_drv+0x4e/0xa0 [ 36.559642] [] i2c_register_adapter+0x16d/0x270 [ 36.559696] [] i2c_add_adapter+0xa3/0xb0 [ 36.559759] [] intel_setup_gmbus+0xcc/0x1f0 [i915] [ 36.559821] [] i915_driver_load+0x2ac/0xb90 [i915] [ 36.559882] [] ? drm_get_minor+0x261/0x300 [drm] [ 36.559940] [] drm_get_pci_dev+0x186/0x2d0 [drm] [ 36.559995] [] ? default_spin_lock_flags+0x9/0x10 [ 36.560060] [] i915_pci_probe+0x16/0x20 [i915] [ 36.560115] [] local_pci_probe+0x5c/0xd0 [ 36.560168] [] pci_device_probe+0x111/0x120 [ 36.560221] [] driver_probe_device+0x7e/0x220 [ 36.560274] [] __driver_attach+0xab/0xb0 [ 36.560327] [] ? driver_probe_device+0x220/0x220 [ 36.560375] [] bus_for_each_dev+0x55/0x90 [ 36.560421] [] ? 0xa0322fff [ 36.560470] [] driver_attach+0x1e/0x20 [ 36.560522] [] bus_add_driver+0x198/0x270 [ 36.560573] [] ? 0xa0322fff [ 36.560625] [] driver_register+0x77/0x150 [ 36.560677] [] ? 0xa0322fff [ 36.560729] [] __pci_register_driver+0x5e/0xe0 [ 36.560784] [] ? 0xa0322fff [ 36.560839] [] drm_pci_init+0x11a/0x130 [drm] [ 36.560892] [] ? 0xa0322fff [ 36.560949] [] i915_init+0x8b/0x8d [i915] [ 36.561004] [] do_one_initcall+0x12a/0x180 [ 36.561057] [] sys_init_module+0x10b0/0x1f40 [ 36.56] [] ? free_notes_attrs+0x60/0x60 [ 36.561165] [] system_call_fastpath+0x16/0x1b [ 36.561218] Code:
RE: [PATCH] net: add new QCA alx ethernet driver
Hi Jeo
I only want to do some additional explanations to david. It makes nothing with
original patch.
Thanks
cloud
-Original Message-
From: Joe Perches [mailto:j...@perches.com]
Sent: 2012年8月9日 12:10
To: Ren, Cloud
Cc: da...@davemloft.net; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
qca-linux-team; nic-devel; Huang, Xiong; Hao-Ran Liu(Joseph Liu); Rodriguez,
Luis
Subject: RE: [PATCH] net: add new QCA alx ethernet driver
On Thu, 2012-08-09 at 02:27 +, Ren, Cloud wrote:
> Hi David,
[]
> The alx driver only supports two new nics(l1f/l2f) now. It doesn't supersede
> atl1c driver.
> Atl1c driver still supports old nics.
[]
> -Original Message-
> From: Ren, Cloud
> Sent: 2012年8月9日 18:15
[]
> This driver support two new ethernet chipsets:
[+400kb of entire original patch]
Did you really have to quote 400kb of original patch to make that prefixing
statement to David?
[]
> Signed-off-by: Joe Perches
I would prefer my name not be listed as a Signed-off-by.
I don't have a card, I never tested it, etc. What I did do is a light review
and made a couple of trivial patch suggestions about how you might make logging
code a bit smaller.
Thanks and cheers, Joe
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 2/5] x86/uprobes: implement x86 specific arch_uprobe_*_step
On Wed, Aug 08, 2012 at 04:53:45PM +0200, Oleg Nesterov wrote: > On 08/08, Sebastian Andrzej Siewior wrote: ... > >> ->insn[0] doesn't look right, we should skip the prefixes. insn_init() insn_get_opcode() if (OPCODE1() == 0x9d) is always the right way of doing it. ... > And in any case it would be better to re-use auprobe->fixups. Agreed. Ananth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] mm: introduce N_LRU_MEMORY to distinguish between normal and movable memory
From: Wu Jianguo Hi all, Now, We have node masks for both N_NORMAL_MEMORY and N_HIGH_MEMORY to distinguish between normal and highmem on platforms such as x86. But we still don't have such a mechanism to distinguish between "normal" and "movable" memory. As suggested by Christoph Lameter in threads http://marc.info/?l=linux-mm=134323057602484=2, we introduce N_LRU_MEMORY to distinguish between "normal" and "movable" memory. And this patch will fix the bug described as follow: When handling a memory node with only movable zone, function early_kmem_cache_node_alloc() will allocate a page from remote node but still increase object count on local node, which will trigger a BUG_ON() as below when hot-removing this memory node. Actually there's no need to create kmem_cache_node for memory node with only movable zone at all. [ cut here ] kernel BUG at mm/slub.c:3590! invalid opcode: [#1] SMP CPU 61 Modules linked in: autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 vfat fat dm_mirror dm_region_hash dm_log uinput iTCO_wdt iTCO_vendor_support coretemp hwmon kvm_intel kvm crc32c_intel ghash_clmulni_intel serio_raw pcspkr cdc_ether usbnet mii i2c_i801 i2c_core sg lpc_ich mfd_core shpchp ioatdma i7core_edac edac_core igb dca bnx2 ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif aesni_intel cryptd aes_x86_64 aes_generic bfa scsi_transport_fc scsi_tgt pata_acpi ata_generic ata_piix megaraid_sas dm_mod [last unloaded: microcode] Pid: 46287, comm: sh Not tainted 3.5.0-rc4-pgtable-00215-g35f0828-dirty #85 IBM System x3850 X5 -[7143O3G]-/Node 1, Processor Card RIP: 0010:[] [] slab_memory_callback+0x1ba/0x1c0 RSP: 0018:880efdcb7c68 EFLAGS: 00010202 RAX: 0001 RBX: 880f7ec06100 RCX: 00010041 RDX: 00010042 RSI: 880f7ec02000 RDI: 880f7ec06100 RBP: 880efdcb7c78 R08: 88107b6fb098 R09: 81160a00 R10: R11: R12: 0019 R13: fffb R14: R15: 81abe930 FS: 7f709f342700() GS:880f7f3a() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 003b5a874570 CR3: 000f0da2 CR4: 07e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process sh (pid: 46287, threadinfo 880efdcb6000, task 880f0fa5) Stack: 0004 880efdcb7da8 880efdcb7cb8 81524af5 0001 81a8b620 81a8b640 0004 880efdcb7da8 880efdcb7d08 8107a89a Call Trace: [] notifier_call_chain+0x55/0x80 [] __blocking_notifier_call_chain+0x5a/0x80 [] blocking_notifier_call_chain+0x16/0x20 [] memory_notify+0x1b/0x20 [] offline_pages+0x624/0x700 [] remove_memory+0x1e/0x20 [] memory_block_change_state+0x13c/0x2e0 [] ? alloc_pages_current+0xb6/0x120 [] store_mem_state+0xc2/0xd0 [] dev_attr_store+0x20/0x30 [] sysfs_write_file+0xef/0x170 [] vfs_write+0xc8/0x190 [] sys_write+0x51/0x90 [] system_call_fastpath+0x16/0x1b Code: 8b 3d cb fd c4 00 be d0 00 00 00 e8 71 de ff ff 48 85 c0 75 9c 48 c7 c7 c0 7f a5 81 e8 c0 89 f1 ff b8 0d 80 00 00 e9 69 fe ff ff <0f> 0b eb fe 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 RIP [] slab_memory_callback+0x1ba/0x1c0 RSP ---[ end trace 749e9e9a67c78c12 ]--- Signed-off-by: Wu Jianguo Signed-off-by: Jiang Liu --- arch/alpha/mm/numa.c |2 +- arch/m32r/mm/discontig.c |2 +- arch/m68k/mm/motorola.c |2 +- arch/parisc/mm/init.c|2 +- arch/tile/kernel/setup.c |2 +- arch/x86/mm/init_64.c|2 +- drivers/base/node.c |4 +++- include/linux/nodemask.h |5 +++-- mm/page_alloc.c | 10 -- 9 files changed, 20 insertions(+), 11 deletions(-) diff --git a/arch/alpha/mm/numa.c b/arch/alpha/mm/numa.c index 3973ae3..8402b29 100644 --- a/arch/alpha/mm/numa.c +++ b/arch/alpha/mm/numa.c @@ -313,7 +313,7 @@ void __init paging_init(void) zones_size[ZONE_DMA] = dma_local_pfn; zones_size[ZONE_NORMAL] = (end_pfn - start_pfn) - dma_local_pfn; } - node_set_state(nid, N_NORMAL_MEMORY); + node_set_state(nid, N_LRU_MEMORY); free_area_init_node(nid, zones_size, start_pfn, NULL); } diff --git a/arch/m32r/mm/discontig.c b/arch/m32r/mm/discontig.c index 2c468e8..4d76e19 100644 --- a/arch/m32r/mm/discontig.c +++ b/arch/m32r/mm/discontig.c @@ -149,7 +149,7 @@ unsigned long __init zone_sizes_init(void) zholes_size[ZONE_DMA] = mp->holes; holes += zholes_size[ZONE_DMA]; - node_set_state(nid, N_NORMAL_MEMORY); + node_set_state(nid, N_LRU_MEMORY); free_area_init_node(nid, zones_size, start_pfn, zholes_size);
Re: [Regression, post-3.5] System suspend broken on the Mackerel board
On Wed, Aug 08, 2012 at 11:23:04AM +0200, Rafael J. Wysocki wrote: > On Tuesday, August 07, 2012, Paul Mundt wrote: > > On Sun, Aug 05, 2012 at 12:02:43AM +0200, Rafael J. Wysocki wrote: > > > On Wednesday, August 01, 2012, Paul Mundt wrote: > > > > Turns out we can just collapse the probe/init stuff anyways, so this > > > > ought to fix it. I've verified that it fixes Morimoto-san's issue, my > > > > expectation is that the mackerel case is likewise getting tripped up but > > > > no one bothered implementing any error detecting logic for > > > > gpio_request() > > > > failing, so it doesn't fail gracefully. > > > > > > > > I'll be pushing this out to Linus shortly: > > > > > > Thanks, this helped. Resume works correctly on Mackerel with 3.6-rc1. > > > > > > However, I'm now seeing a different problem related to system suspend on > > > that, > > > board which is that sh7372_enter_a3sm_common() returns immediately, as > > > though > > > at least one of the wakeup signals was permanently asserted. This hadn't > > > happened before your last pull request was merged, so I suspect that one > > > of the irqdomain patches might introduce this behavior. > > > > > Ok, I'll back off the irqdomain selection until we have a chance to test > > it more on the other platforms. > > If you mean removing the select from drivers/sh/intc/Kconfig, that alone > doesn't > help. Reverting commit 1d6a21b0a672fb29b01ccf397d478e0541e17716 > (sh: intc: initial irqdomain support.) helps, though. > Yeah, I see what happened now. I inadvertently trampled the -EEXIST behaviour. I've taken care of it now, so hopefully you'll have better luck with -rc2! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/5] perf script: Add event_analyzing_sample.py as a sample for general event handling
Hi Namhyung,
Many thanks for your valuable comments, I'll fold the fixes into an
incremental patch.
On Thu, 9 Aug 2012 10:30:34 +0900
Namhyung Kim wrote:
> On Wed, 8 Aug 2012 17:57:55 +0800, Feng Tang wrote:
> > Currently only trace point events are supported in perf/python script,
> > the first 3 patches of this serie add the support for all types of
>
> > +con = sqlite3.connect("/dev/shm/perf.db")
> > +con.isolation_level = None
> > +
> > +def trace_begin():
> > + print "In trace_begin:\n"
>
> It seems it's not aligned with other statements, and even not needed at
> all. Does it work?
trace_begin() is a must have for a python script, the
is automatically generated from "perf script -g", I guess its intension is
to help developer debug their own patches. and same for the trace_end().
> > +def print_header(event_name, cpu, secs, nsecs, pid, comm):
> > + print "%-20s %5u %05u.%09u %8u %-20s " % \
> > + (event_name, cpu, secs, nsecs, pid, comm),
>
> It seems this function was not called anywhere.
It is auto-generated too, and you are right, it is not needed at all,
will remove it.
Thanks,
Feng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates for 3.6-rc2
The following changes since commit f4ba394c1b02e7fc2179fda8d3941a5b3b65efb6: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-08-08 20:06:43 +0300) are available in the git repository at: git://github.com/pmundt/linux-sh tags/sh-for-linus for you to fetch changes up to fa75ce649ee2600b117631f8794e0e7dbedb1d68: Merge branches 'sh/urgent' and 'sh/gpiolib' into sh-latest (2012-08-09 13:21:13 +0900) SuperH fixes for 3.6-rc2 Mike Frysinger (1): sh: dma: fix request_irq usage Paul Mundt (2): sh: intc: Handle domain association for sparseirq pre-allocated vectors. Merge branches 'sh/urgent' and 'sh/gpiolib' into sh-latest Phil Edworthy (1): sh: sh7269: Fix LCD pinmux arch/sh/drivers/dma/dma-sh.c| 2 +- arch/sh/include/cpu-sh2a/cpu/sh7269.h | 36 -- arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c | 195 +++- drivers/sh/intc/core.c | 27 - 4 files changed, 165 insertions(+), 95 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/4] ftrace: Do not test frame pointers if -mfentry is used
On 08/08/2012 08:45 PM, Linus Torvalds wrote: > > Btw, it might be lovely to consider the concept of "Kconfig variables > set by shell-scripts". > > We currently have a metric sh*t-ton of Makefile magic for testing > various things like this, and integrating it into Kconfig might be a > good idea. That way you would be able to use the Kconfig logic on > these things. > > Kconfig already has the "option env=XYZ" syntax for importing values > from the environment variables. Extending it to some kind of "option > shell=xyz" would allow for more complex interactions like this > (imagine testing compiler options and version dependencies in the > Kconfig files instead of the Makefiles)? > This is a Frequently Requested Feature over on the kbuild list... and it almost certainly would speed up the build given how many times the tests are currently run. Furthermore, it would let us base rules on the support existing, which we currently can't. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] net: add new QCA alx ethernet driver
On Thu, 2012-08-09 at 02:27 +, Ren, Cloud wrote: > Hi David, [] > The alx driver only supports two new nics(l1f/l2f) now. It doesn't supersede > atl1c driver. > Atl1c driver still supports old nics. [] > -Original Message- > From: Ren, Cloud > Sent: 2012年8月9日 18:15 [] > This driver support two new ethernet chipsets: [+400kb of entire original patch] Did you really have to quote 400kb of original patch to make that prefixing statement to David? [] > Signed-off-by: Joe Perches I would prefer my name not be listed as a Signed-off-by. I don't have a card, I never tested it, etc. What I did do is a light review and made a couple of trivial patch suggestions about how you might make logging code a bit smaller. Thanks and cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] gpio/omap: add *remove* callback in platform_driver
On Wed, Aug 8, 2012 at 10:40 PM, Kevin Hilman wrote: > Tarun Kanti DebBarma writes: > >> Add *remove* callback so that necessary cleanup operations are >> performed when device is unregistered. The device is deleted >> from the list and associated clock handle is released by >> calling clk_put() and irq descriptor is released using the >> irq_free_desc() api. >> >> Signed-off-by: Tarun Kanti DebBarma >> Reported-by: Paul Walmsley >> Reviewed-by: Jon Hunter >> Cc: Kevin Hilman >> Cc: Rajendra Nayak >> Cc: Santosh Shilimkar >> Cc: Cousson, Benoit >> Cc: Paul Walmsley >> --- >> v2: >> Baseline: >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> Commit: 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee (Linux 3.6-rc1) >> >> (1) Use irq_free_descs() instead of irq_free_desc(). >> Besides, irq_free_desc() was using wrong parameter, >> irq_base, instead of bank->irq. >> (2) irq_free_descs() moved outside spin_lock/unlock_*() >> in order to avoid exception warnings. >> >> (3) pm_runtime_disable() added so that bind can happen successfully >> >> Test Detail: >> Step 1: Unbind gpio.5 device in order to invoke the *remove* callback. >> #echo "omap_gpio.5" > sys/bus/platform/drivers/omap_gpio/unbind >> >> Step 2: Bind gpio.5 device and confirm probe() for the device succeeds. >> #echo "omap_gpio.5" > sys/bus/platform/drivers/omap_gpio/bind >> >> Step 3: Execute read/write GPIO test case. > > What happens when GPIOs are in use (requested)? If I try to unbind a currently active GPIO bank then I see an exception after the irq descriptor is freed by the remove. I believe this is expected because interrupt raised by the system would not be handled. [ 18.859405] irq_free_descs: calling free_desc(192)... [ 18.866180] irq_free_descs: calling free_desc(192)... [ 18.872680] irq_free_descs: calling free_desc(192)... [ 18.877990] irq_free_descs: calling free_desc(192)... [ 18.883270] irq_free_descs: calling free_desc(192)... [ 18.888549] irq_free_descs: calling free_desc(192)... [ 18.893859] irq_free_descs: calling free_desc(192)... [ 18.899139] irq_free_descs: calling free_desc(192)... [ 18.904418] irq_free_descs: calling free_desc(192)... [ 18.909729] irq_free_descs: calling free_desc(192)... [ 18.915008] irq_free_descs: calling free_desc(192)... [ 18.920288] irq_free_descs: calling free_desc(192)... [ 18.925598] irq_free_descs: calling free_desc(192)... [ 18.930877] irq_free_descs: calling free_desc(192)... [ 18.936157] irq_free_descs: calling free_desc(192)... [ 18.941467] irq_free_descs: calling free_desc(192)... [ 18.946746] irq_free_descs: calling free_desc(192)... [ 18.952026] irq_free_descs: calling free_desc(192)... [ 18.957336] irq_free_descs: calling free_desc(192)... [ 18.962615] irq_free_descs: calling free_desc(192)... [ 18.967895] irq_free_descs: calling free_desc(192)... [ 18.973205] irq_free_descs: calling free_desc(192)... [ 18.978485] irq_free_descs: calling free_desc(192)... [ 18.983764] irq_free_descs: calling free_desc(192)... [ 18.989074] irq_free_descs: calling free_desc(192)... [ 18.994354] irq_free_descs: calling free_desc(192)... [ 18.999633] irq_free_descs: calling free_desc(192)... [ 19.004913] irq_free_descs: calling free_desc(192)... [ 19.010223] irq_free_descs: calling free_desc(192)... [ 19.015502] irq_free_descs: calling free_desc(192)... [ 19.020782] irq_free_descs: calling free_desc(192)... [ 19.026092] irq_free_descs: calling free_desc(192)... [ 19.032440] irq 194, desc: c072f340, depth: 1, count: 0, unhandled: 0 [ 19.039154] ->handle_irq(): c00a3e08, handle_bad_irq+0x0/0x260 [ 19.045379] ->irq_data.chip(): c078ff7c, no_irq_chip+0x0/0x5c [ 19.051391] ->action(): ef0d42c0 [ 19.054748] ->action->handler(): c0399ee0, ks8851_irq+0x0/0x1c [ 19.060852]IRQ_NOPROBE set [ 19.064056] IRQ_NOREQUEST set [ 19.067230] Unable to handle kernel paging request at virtual address 203a6c9 [ 19.074768] pgd = c0004000 [ 19.077606] [203a6c99] *pgd= [ 19.081329] Internal error: Oops: 5 [#1] SMP ARM [ 19.086151] Modules linked in: [ 19.089355] CPU: 0Not tainted (3.6.0-rc1-3-g43a916d-dirty #885) [ 19.096374] PC is at gpio_irq_handler+0x7c/0x26c [ 19.101165] LR is at handle_bad_irq+0x1cc/0x260 [ 19.105895] pc : []lr : []psr: 6093 [ 19.105895] sp : c0725df8 ip : 6fc6 fp : 0001 [ 19.117889] r10: r9 : fa05502c r8 : 0020 [ 19.123352] r7 : r6 : r5 : r4 : ef0bbe10 [ 19.130157] r3 : ef0c1980 r2 : 203a6c65 r1 : 0034 r0 : [ 19.136993] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kel [ 19.144714] Control: 10c53c7d Table: ae89804a DAC: 0017 [ 19.150695] Process swapper/0 (pid: 0, stack limit = 0xc07242f8) [ 19.156982] Stack: (0xc0725df8 to 0xc0726000) [ 19.161529] 5de0: c0740 [ 19.170074] 5e00:
Re: [RFC PATCH 3/4] ftrace: Do not test frame pointers if -mfentry is used
On Thu, 2012-08-09 at 06:45 +0300, Linus Torvalds wrote: > On Wed, Aug 8, 2012 at 3:49 PM, Steven Rostedt wrote: > > > > No, CONFIG_HAVE_FENTRY just means fentry is supported, it does not mean > > that it is being used. It only gets used if CC_USING_FENTRY is set, > > which is set by the Makefile at time of compile. > > Btw, it might be lovely to consider the concept of "Kconfig variables > set by shell-scripts". > > We currently have a metric sh*t-ton of Makefile magic for testing > various things like this, and integrating it into Kconfig might be a > good idea. That way you would be able to use the Kconfig logic on > these things. > > Kconfig already has the "option env=XYZ" syntax for importing values > from the environment variables. Extending it to some kind of "option > shell=xyz" would allow for more complex interactions like this > (imagine testing compiler options and version dependencies in the > Kconfig files instead of the Makefiles)? I understand your pain. I think this 'test the environment in the makefile' is a bit of a hack. I've worked a little with the Kconfig infrastructure, but I wouldn't consider myself an expert. Would Kconfig be able to handle a change in environment? That is, if you change your compiler, would a normal make kick off Kconfig to update the configs for the new environment. Or would the user have to do some kind of 'make oldconfig' before that. Or is make 'oldconfig' performed at all compiles regardless now? One nice thing of having all these tests represented in the .config file, is that when a user produces a bug, when they send their config, we would be able to see much more information about their environment. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/4] ftrace: Do not test frame pointers if -mfentry is used
On Wed, Aug 8, 2012 at 3:49 PM, Steven Rostedt wrote: > > No, CONFIG_HAVE_FENTRY just means fentry is supported, it does not mean > that it is being used. It only gets used if CC_USING_FENTRY is set, > which is set by the Makefile at time of compile. Btw, it might be lovely to consider the concept of "Kconfig variables set by shell-scripts". We currently have a metric sh*t-ton of Makefile magic for testing various things like this, and integrating it into Kconfig might be a good idea. That way you would be able to use the Kconfig logic on these things. Kconfig already has the "option env=XYZ" syntax for importing values from the environment variables. Extending it to some kind of "option shell=xyz" would allow for more complex interactions like this (imagine testing compiler options and version dependencies in the Kconfig files instead of the Makefiles)? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Using vanilla kernels headers to do backport testing -- issues with memcpy()
On Wed, Aug 8, 2012 at 5:43 AM, Ozan Çağlayan wrote: > On Tue, Aug 7, 2012 at 10:28 PM, Luis R. Rodriguez > wrote: >> mcgrof@garbanzo ~/compat (git::master)$ objdump -T >> /home/mcgrof/compat-ksrc/lib/modules/3.4.4-030404-generic/build/scripts/genksyms/genksyms <-- snip --> >> Bleh: >> >> DF *UND* GLIBC_2.14 memcpy <-- snip --> > Can't we just rebuild genksyms in compat? I already have glibc 2.15 on > my system so I can't test this but normally this should adapt to the > build environment as it rebuilds and relinks the binary. Indeed! Implemented and pushed upstream: https://github.com/mcgrof/compat/commit/42faf2dc8d8bbbdc5b8913183fcd021a27e953c9 So if you run into this issue all you have to do now is run: ./bin/get-compat-kernels -r New users of the script will automatically have this run after it downloads and installs the kernel headers. Case closed, thanks :) Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What happened to TRIM support for raid linear/0/1/10?
On Wed, 8 Aug 2012 13:10:51 + (GMT) Holger Kiehl wrote: > Hello, > > I have been using the patches posted by Shaohua Li on 16th March 2012: > > http://lkml.indiana.edu/hypermail/linux/kernel/1203.2/00048.html > > for several month on a very busy file server (serving 9 million files > with 5.3 TiB daily) without any problems. > > Is there any chance that these patches will go into the official kernel? > Or what is the reason that these patches are no applied? I'm trying to appear to be an incompetent maintainer so that someone will offer to take over. It isn't working yet. I'm probably scuttling the attempt just by replying to this email - drat. > > I have attached the patch set in one big patch for 3.5. Please do not > use it since I am not sure if it is correct. Shaohua could you please > take a look if it is correct and maybe post a new one? > > Personally, I would think that TRIM support MD would be a very good thing. Probably. Maybe if they get posted again I'll feel guilty and do something about them. One issue that needs to be fixed is that a few places assumed that the "discard_zeros_data" flag is always set, which is not the case (else we wouldn't have that flag). That was only a couple of places though, not a wide spread problem. NeilBrown > > Regards, > Holger signature.asc Description: PGP signature
Re: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use
On Wed, Aug 8, 2012 at 8:19 PM, Kent Overstreet wrote: > In particular, if this change breaks anything then the new bio_split() > _will_ break things. > > We need to be clear about our interfaces; in this case bi_idx and > bi_vcnt, in particular. Either this is a safe change, or it's not. If > no one knows... that's a bigger problem, and not just for this patch... > > Fortunately this code actually has been tested quite a bit (and the bio > splitting code for even longer), and (somewhat to my surprise) I haven't > run into any bugs caused by it. Oh, it's worse than that - remember how bio_kmalloc() works for up to 1024 pages, but bio_alloc_bioset() only up to 256? We can already have situations where bios are allocated that are impossible to clone (or if we don't, it's only because of queue_limits. That's not sketchy at all.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use
On Wed, Aug 08, 2012 at 04:47:46PM -0700, Muthu Kumar wrote: > Tejun, > > This is changing the semantics of the clone. Sorry, I missed this > thread and replied separately. But anyway, replying it again here: > > > On Wed, Aug 8, 2012 at 4:28 PM, Tejun Heo wrote: > > On Mon, Aug 06, 2012 at 07:16:33PM -0400, Mikulas Patocka wrote: > >> Hi Kent > >> > >> When you change the semantics of an exported function, rename that > >> function. There may be external modules that use __bio_clone and this > >> change could silently introduce bugs in them. > >> > >> Otherwise, the patchset looks fine. > > > > I don't know. This doesn't change the main functionality and should > > be transparent unless the caller is doing something crazy. It *might* > > be nice to rename but I don't think that's a must here. > > > > Thanks. > > -- > You are changing the meaning of __bio_clone() here. In old code, the > number of io_vecs, bi_idx, bi_vcnt are preserved. But in this modified > code, you are mapping bio_src's bi_iovec[bi_idx] to bio_dests > bi_iovec[0] and also restricting the number of allocated io_vecs of > the clone. It may be useful for cases were we would like a identical > copy of the original bio (may not be in current code base, but this > implementation is definitely not what one would expect from the name > "clone"). The problem is that bio_clone() is used on bios that were not allocated or submitted by the cloning module. If some code somewher submits a bio that points to 500 pages, but by the time it gets to a driver it only points to 200 pages (say, because it was split), that clone should succeed; it shouldn't fail simply because it was trying to clone more than was necessary. Bios have certain (poorly documented) semantics, and if this breaks anything it's probably because that code was doing something crazy in the first place. In particular, if this change breaks anything then the new bio_split() _will_ break things. We need to be clear about our interfaces; in this case bi_idx and bi_vcnt, in particular. Either this is a safe change, or it's not. If no one knows... that's a bigger problem, and not just for this patch... Fortunately this code actually has been tested quite a bit (and the bio splitting code for even longer), and (somewhat to my surprise) I haven't run into any bugs caused by it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 040/122] batman-adv: fix skb->data assignment
On Tue, 2012-08-07 at 15:25 -0700, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.5-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Antonio Quartulli > > commit d2b6cc8e460494251442a877fcbc150faa175b4f upstream. [...] This is a duplicate of commit 2c995ff892313009e336ecc8ec3411022f5b1c39 which is already in 3.5. Please drop it. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
linux-next: Tree for Aug 9
Hi all, Changes since 20120807: Renamed tree: s5p to samsung The osd tree gained a conflict against the nfs tree. The tty tree still has its build failures for which I have disabled 2 staging drivers and applied a patch. It lost its conflicts. I have still reverted 3 commits from the signal tree at the request of the arm maintainer. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 193 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (f4ba394 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging kbuild-current/rc-fixes (f8f5701 Linux 3.5-rc1) Merging arm-current/fixes (b74253f ARM: 7479/1: mm: avoid NULL dereference when flushing gate_vma with VIVT caches) Merging m68k-current/for-linus (9e2760d m68k: Make sys_atomic_cmpxchg_32 work on classic m68k) Merging powerpc-merge/merge (ad36cb0 powerpc/kvm/book3s_32: Fix MTMSR_EERI macro) Merging sparc/master (a27032e sparc64: do not clobber personality flags in sys_sparc64_personality()) Merging net/master (f4ba394 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging sound-current/for-linus (012e7eb ALSA: hda - Fix double quirk for Quanta FL1 / Lenovo Ideapad) Merging pci-current/for-linus (314489b Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging wireless/master (50e2a30 iwlwifi: disable greenfield transmissions as a workaround) Merging driver-core.current/driver-core-linus (0d7614f Linux 3.6-rc1) Merging tty.current/tty-linus (0d7614f Linux 3.6-rc1) Merging usb.current/usb-linus (010ccce Merge tag 'fixes-for-v3.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging staging.current/staging-linus (a26f4dd staging: comedi: rtd520: ioremap'ed addresses are resource_size_t) Merging char-misc.current/char-misc-linus (0d7614f Linux 3.6-rc1) Merging input-current/for-linus (cf45b5a Merge branch 'next' into for-linus) Merging md-current/for-linus (58e94ae md/raid1: close some possible races on write errors during resync) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (76f16f8 crypto: hifn_795x - fix 64bit division and undefined __divdi3 on 32bit archs) Merging ide/master (39a50b4 Merge branch 'hfsplus') Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging arm/for-next (1a9b499 Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus) Merging
RE: [PATCH 1/1] proc: add /proc/pid/shmaps
On Thu, 9 Aug 2012, Ren, Qiaowei wrote: > On Wed, 8 Aug 2012, David Rientjes wrote: > > On Wed, 8 Aug 2012, Qiaowei Ren wrote: > > > > > Add a shmaps entry to /proc/pid: show information about shared memory in > > > an address space. > > > > > > People that use shared memory and want to perform an analyzing about it. > > > For example, judge whether any memory address is shared. This file just > > > contains 'share' part of /proc/pid/maps now. There are too many contents > > > in maps, and so we have to do a lot of analysis to obtain relative > > > information every time. > > > > > > Signed-off-by: Qiaowei Ren > > > > Nack as unnecessary; /proc/pid/maps already explicitly emits 's' for > > VM_MAYSHARE and 'p' otherwise so this information is already available to > > userspace. > > > > Thanks for your reply. There are so many contents in /proc/pid/maps, and > usually only a very small minority of those are about shared memory in > address space of every process. So I hope that a new file maybe provide some > convenience. Could you tell me how to get such information except analyzing > 'maps' file? You are joking? Please imagine what the kernel and /proc would look like if it provided a personally tailored /proc file to everybody who could not be bothered to parse the information already shown there. Sure, there is already lots of ugly and duplicative junk under /proc, which usually has to be kept to preserve back compatibility; but please do not try to add to it. There is sometimes an excuse if some fields of an existing /proc file are significantly more expensive for the kernel to compute than others: then a file which separates them can save processing. But that is definitely not the case here. A side issue would be whether parsing /proc/pid/maps for 's' VM_MAYSHARE mappings (or your equivalent patch) actually tells you what you want to know about "shared memory" - that would depend on what you really want to know, and what you mean by shared memory. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/11] perf scripts python: Add event_analyzing_sample.py as a sample for general event handling
Hi Arnaldo and Ingo,
On Wed, 8 Aug 2012 14:13:48 -0300, Arnaldo Carvalho de Melo wrote:
> From: Feng Tang
>
> Currently only trace point events are supported in perf/python script,
> the first 3 patches of this serie add the support for all types of
> events. This script is just a simple sample to show how to gather the
> basic information of the events and analyze them.
>
> This script will create one object for each event sample and insert them
> into a table in a database, then leverage the simple SQL commands to
> sort/group them. User can modify or write their brand new functions
> according to their specific requirment.
>
> Here is the sample of how to use the script:
>
> $ perf record -a tree
> $ perf script -s process_event.py
Please edit the script name to event_analyzing_sample.py at least to
prevent future confusion. For other issues, please see my review
comments on Feng's original posts. (They can be incremental.)
>
> There is 100 records in gen_events table
> Statistics about the general events grouped by thread/symbol/dso:
>
> comm number histgram
> ==
> swapper 56 ##
> tree 20 #
> perf 10
> sshd8
> kworker/7:24 ###
> ksoftirqd/71 #
> plugin-containe1 #
>
> symbol number histgram
> ==
>native_write_msr_safe 40 ##
> __lock_acquire8
> ftrace_graph_caller4 ###
>prepare_ftrace_return4 ###
> intel_idle3 ##
> native_sched_clock3 ##
> Unknown_symbol2 ##
> do_softirq2 ##
> lock_release2 ##
>lock_release_holdtime2 ##
>trace_graph_entry2 ##
> _IO_putc1 #
> __d_lookup_rcu1 #
> __do_fault1 #
> __schedule1 #
> _raw_spin_lock1 #
>delay_tsc1 #
> generic_exec_single1 #
> generic_fillattr1 #
>
> dso number histgram
> ==
>[kernel.kallsyms] 95 ###
> /lib/libc-2.12.1.so5 ###
>
> Signed-off-by: Feng Tang
> Cc: Andi Kleen
> Cc: David Ahern
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Robert Richter
> Cc: Stephane Eranian
> Link:
> http://lkml.kernel.org/r/1344419875-21665-6-git-send-email-feng.t...@intel.com
> Signed-off-by: Arnaldo Carvalho de Melo
> ---
> .../perf/scripts/python/event_analyzing_sample.py | 193
>
> 1 file changed, 193 insertions(+)
> create mode 100644 tools/perf/scripts/python/event_analyzing_sample.py
>
> diff --git a/tools/perf/scripts/python/event_analyzing_sample.py
> b/tools/perf/scripts/python/event_analyzing_sample.py
> new file mode 100644
> index 000..46f05aa
> --- /dev/null
> +++ b/tools/perf/scripts/python/event_analyzing_sample.py
> @@ -0,0 +1,193 @@
> +# process_event.py: general event handler in python
Hopefully here also.
Thanks,
Namhyung
> +#
> +# Current perf report is alreay very powerful with the anotation integrated,
> +# and this script is not trying to be as powerful as perf report, but
> +# providing end user/developer a flexible way to analyze the events other
> +# than trace points.
> +#
> +# The 2 database related functions in this script just show how to gather
> +# the basic information, and users can modify and write their own functions
> +# according to their specific requirment.
> +#
> +# The first sample "show_general_events" just does a baisc grouping for all
> +# generic events with the help of sqlite, and the 2nd one "show_pebs_ll" is
> +# for a x86 HW PMU event: PEBS with load latency data.
> +#
> +
> +import os
> +import sys
> +import math
> +import struct
> +import sqlite3
> +
> +sys.path.append(os.environ['PERF_EXEC_PATH'] + \
> +'/scripts/python/Perf-Trace-Util/lib/Perf/Trace')
> +
> +from perf_trace_context import *
> +from EventClass import *
> +
> +#
> +# If the perf.data has a big number of samples, then the insert operation
> +# will be very time consuming (about 10+ minutes for 1 samples) if the
> +# .db database is on disk. Move the .db file to RAM based FS to speedup
> +# the handling, which will cut the time down to several seconds.
> +#
> +con = sqlite3.connect("/dev/shm/perf.db")
> +con.isolation_level = None
> +
> +def trace_begin():
> +
Re: [PATCH v5 12/12] block: Only clone bio vecs that are in use
On Wed, Aug 08, 2012 at 04:30:07PM -0700, Tejun Heo wrote:
> Hello,
>
> On Mon, Aug 06, 2012 at 03:08:41PM -0700, Kent Overstreet wrote:
> > @@ -459,10 +460,10 @@ void __bio_clone(struct bio *bio, struct bio *bio_src)
> > bio->bi_sector = bio_src->bi_sector;
> > bio->bi_bdev = bio_src->bi_bdev;
> > bio->bi_flags |= 1 << BIO_CLONED;
> > + bio->bi_flags &= ~(1 << BIO_SEG_VALID);
>
> This isn't obvious at all. Why no explanation anywhere? Also it
> would be nice to update comments of the updated functions so that it's
> clear that only partial cloning happens.
Because it's not obvious to me, either - I had to grep around through a
fair amount of code to figure out the semantics of BIO_SEG_VALID and I
doubt I have it 100%. I'm also pretty sure it's not used consistently in
the existing code...
If it means what I think it means, it should be obvious - nr_segs isn't
valid because the number of pages in the iovec changed (though we didn't
bother to copy it over anyways. So it's not necessary if nr_segs = 0
means nr_segs isn't valid, but bleh).
Anyways. yeah. BIO_SEG_VALID should be documented, and if it was I think
this code would be fine.
I will update the comment for the partial cloning thing:
/**
* __bio_clone - clone a bio
* @bio: destination bio
* @bio_src: bio to clone
*
* Clone a Caller will own the returned bio, but not
* the actual data it points to. Reference count of returned
* bio will be one.
*
* We don't clone the entire bvec, just the part from bi_idx to b_vcnt
* (i.e. what the bio currently points to, so the new bio is still
* equivalent to the old bio).
*/
void __bio_clone(struct bio *bio, struct bio *bio_src)
{
memcpy(bio->bi_io_vec,
bio_iovec(bio_src),
bio_segments(bio_src) * sizeof(struct bio_vec));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/4] ftrace: Do not test frame pointers if -mfentry is used
(2012/08/08 21:49), Steven Rostedt wrote: > On Wed, 2012-08-08 at 13:34 +0900, Masami Hiramatsu wrote: >> >>> -#ifdef CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST >>> +#if defined(CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST) && >>> !defined(CC_USING_FENTRY) >> >> I think CONFIG_HAVE_FENTRY would better unselect >> CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST in arch/x86/Kconfig explicitly. > > No, CONFIG_HAVE_FENTRY just means fentry is supported, it does not mean > that it is being used. It only gets used if CC_USING_FENTRY is set, > which is set by the Makefile at time of compile. > > If CONFIG_HAVE_FENTRY is defined, a test is done to see if the gcc > compiling the kernel supports -mfentry. If it does, then it defines the > CC_USING_FENTRY macro, if not, the macro is not defined and the old way > is performed. > > If the old way is performed, even if CONFIG_HAVE_FENTRY is defined, then > we still need the above test. We can not have CONFIG_HAVE_FENTRY > unselect CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST. Ah, I see. OK, I don't see any other issue. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 11/12] block: Add bio_clone_bioset()
On Wed, Aug 08, 2012 at 04:21:20PM -0700, Tejun Heo wrote:
> On Mon, Aug 06, 2012 at 03:08:40PM -0700, Kent Overstreet wrote:
> > This consolidates some code, and will help in a later patch changing how
> > bio cloning works.
>
> I think it would be better to introduce bio_clone*() functions in a
> separate patch and convert the users in a different one.
>
> > /**
> > - * bio_clone - clone a bio
> > + * bio_clone_bioset - clone a bio
> > * @bio: bio to clone
> > * @gfp_mask: allocation priority
> > + * @bs: bio_set to allocate from
> > *
> > * Like __bio_clone, only also allocates the returned bio
> > */
> > -struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> > +struct bio *bio_clone_bioset(struct bio *bio, gfp_t gfp_mask,
> > +struct bio_set *bs)
> > {
> > - struct bio *b = bio_alloc(gfp_mask, bio->bi_max_vecs);
> > + struct bio *b = bio_alloc_bioset(gfp_mask, bio->bi_max_vecs, bs);
> >
> > if (!b)
> > return NULL;
> > @@ -485,7 +487,7 @@ struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> > if (bio_integrity(bio)) {
> > int ret;
> >
> > - ret = bio_integrity_clone(b, bio, gfp_mask, fs_bio_set);
> > + ret = bio_integrity_clone(b, bio, gfp_mask, bs);
> >
> > if (ret < 0) {
> > bio_put(b);
> > @@ -495,6 +497,12 @@ struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> >
> > return b;
> > }
> > +EXPORT_SYMBOL(bio_clone_bioset);
> > +
> > +struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> > +{
> > + return bio_clone_bioset(bio, gfp_mask, fs_bio_set);
> > +}
>
> So, bio_clone() loses its function comment. Also, does it even make
> sense to call bio_clone() from fs_bio_set?
I'll re add the function comment if you want, just for a single line
wrapper I don't know if it's worth the cost - comments get out of date,
and they're more stuff to wade through.
> Let's say it's so, then
> what's the difference from using _kmalloc variant?
bio_kmalloc() fails if nr_iovecs > 1024, bio_alloc_bioset() fails if
nr_iovecs > 256
and bio_alloc_bioset() is mempool backed, bio_kmalloc() is not.
AFAICT that's it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Consolidate bio_clone_bioset(), bio_kmalloc()
On Wed, Aug 08, 2012 at 04:15:52PM -0700, Tejun Heo wrote:
> > +struct bio *bio_clone_kmalloc(struct bio *bio, gfp_t gfp_mask)
> > +{
> > + struct bio *b = bio_kmalloc(gfp_mask, bio->bi_max_vecs);
>
> Can't we use %NULL bioset as an indication to allocate from kmalloc
> instead of duping interfaces like this?
So, if bio_clone_bioset(gfp, nr_iovecs, BIO_KMALLOC_POOL) just does
bio_kmalloc(), the rest just falls out naturally.
We could do this by either just having bio_clone_bioset() call
bio_kmalloc(), or consolidate them both into a single function.
I'm leaning towards the latter, because while looking at it I noticed a
couple subtle behavioural differences.
* bio_kmalloc(GFP_KERNEL, 0) sets bi_io_vec = bi_inline_vecs,
bio_alloc_bioset sets it to NULL. This is a bug waiting to happen, if it
isn't one already - bi_io_vec != NULL is exactly what bio_has_data()
checks.
* bio_alloc_bioset() could return a bio with bi_max_vecs greater than
requested if you asked for a bio with fewer than BIO_INLINE_VECS.
Unlikely to ever be a real problem, but subtle enough that I wouldn't
bet too much against it.
* bio_kmalloc() fails if asked for more than UIO_MAXIOV bvecs (wtf!?),
which is 1024; bio_alloc_bioset fails if asked for more than
BIO_MAX_PAGES (which is 256, and it'd probably take you a bit to see
where/why it fails).
So here's my initial stab at it. Tell me if you think this is too
contorted:
diff --git a/fs/bio.c b/fs/bio.c
index 22596af..c852665 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -295,34 +295,45 @@ EXPORT_SYMBOL(bio_reset);
**/
struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set *bs)
{
+ unsigned front_pad;
+ unsigned inline_vecs;
unsigned long idx = BIO_POOL_NONE;
struct bio_vec *bvl = NULL;
struct bio *bio;
void *p;
- p = mempool_alloc(bs->bio_pool, gfp_mask);
+ if (nr_iovecs > UIO_MAXIOV)
+ return NULL;
+
+ if (bs == BIO_KMALLOC_POOL) {
+ p = kmalloc(sizeof(struct bio) +
+ nr_iovecs * sizeof(struct bio_vec),
+ gfp_mask);
+ front_pad = 0;
+ inline_vecs = nr_iovecs;
+ } else {
+ p = mempool_alloc(bs->bio_pool, gfp_mask);
+ front_pad = bs->front_pad;
+ inline_vecs = BIO_INLINE_VECS;
+ }
+
if (unlikely(!p))
return NULL;
- bio = p + bs->front_pad;
+ bio = p + front_pad;
bio_init(bio);
- bio->bi_pool = bs;
-
- if (unlikely(!nr_iovecs))
- goto out_set;
- if (nr_iovecs <= BIO_INLINE_VECS) {
- bvl = bio->bi_inline_vecs;
- nr_iovecs = BIO_INLINE_VECS;
- } else {
+ if (nr_iovecs > inline_vecs) {
bvl = bvec_alloc_bs(gfp_mask, nr_iovecs, , bs);
if (unlikely(!bvl))
goto err_free;
- nr_iovecs = bvec_nr_vecs(idx);
bio->bi_flags |= 1 << BIO_OWNS_VEC;
+ } else if (nr_iovecs) {
+ bvl = bio->bi_inline_vecs;
}
-out_set:
+
+ bio->bi_pool = bs;
bio->bi_flags |= idx << BIO_POOL_OFFSET;
bio->bi_max_vecs = nr_iovecs;
bio->bi_io_vec = bvl;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH v2 1/2] dm: verity support data device offset (Linux 3.4.7)
On Thu, Aug 09, 2012 at 12:40:22AM +, Wesley Miaw wrote: > Apologies if the version increment is incorrect; I was not sure if the minor > or patch number should be incremented. I assume the different version number > is > what would be used to detect if the data offset option is supported. Thanks. Minor number is the correct thing to increment as you're retaining compatibility. (Your original version would have needed to increment the major number to indicate incompatibility with existing userspace code.) However, first you need to address the second part of Mikulas's email, namely to make the case for these changes rather than making no kernel changes and instead stacking the verity target over a linear target. To put this another way, your patch offers an alternative way to do something we think the existing kernel can already do, so you need to advance some reasons why you believe the new alternative method is worth adding to the kernel and explain this in the patch header. Alasdair -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 1/8] arm: vt8500: Add device tree files for VIA/Wondermedia SoC's
Add device tree files for VT8500, WM8505 and WM8650 SoC's and
reference boards.
Signed-off-by: Tony Prisk
---
arch/arm/boot/dts/vt8500-bv07.dts | 31 +
arch/arm/boot/dts/vt8500.dtsi | 99 +
arch/arm/boot/dts/wm8505-ref.dts | 31 +
arch/arm/boot/dts/wm8505.dtsi | 125 +
arch/arm/boot/dts/wm8650-mid.dts | 31 +
arch/arm/boot/dts/wm8650.dtsi | 95
6 files changed, 412 insertions(+)
create mode 100644 arch/arm/boot/dts/vt8500-bv07.dts
create mode 100644 arch/arm/boot/dts/vt8500.dtsi
create mode 100644 arch/arm/boot/dts/wm8505-ref.dts
create mode 100644 arch/arm/boot/dts/wm8505.dtsi
create mode 100644 arch/arm/boot/dts/wm8650-mid.dts
create mode 100644 arch/arm/boot/dts/wm8650.dtsi
diff --git a/arch/arm/boot/dts/vt8500-bv07.dts
b/arch/arm/boot/dts/vt8500-bv07.dts
new file mode 100644
index 000..20dda12
--- /dev/null
+++ b/arch/arm/boot/dts/vt8500-bv07.dts
@@ -0,0 +1,31 @@
+/*
+ * vt8500-bv07.dts - Device tree file for Benign BV07 Netbook
+ *
+ * Copyright (C) 2012 Tony Prisk
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+/include/ "vt8500.dtsi"
+
+/ {
+ model = "Benign BV07 Netbook";
+
+ /*
+* Display node is based on Sascha Hauer's patch on dri-devel.
+* Added a bpp property to calculate the size of the framebuffer
+* until the binding is formalized.
+*/
+ display {
+ xres = <800>;
+ yres = <480>;
+ left-margin = <88>;
+ right-margin = <40>;
+ hsync-len = <0>;
+ upper-margin = <32>;
+ lower-margin = <11>;
+ vsync-len = <1>;
+ bpp = <16>;
+ };
+};
diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
new file mode 100644
index 000..7a2fe0e
--- /dev/null
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -0,0 +1,99 @@
+/*
+ * vt8500.dtsi - Device tree file for VIA VT8500 SoC
+ *
+ * Copyright (C) 2012 Tony Prisk
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "via,vt8500";
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges;
+ interrupt-parent = <>;
+
+ intc: interrupt-controller@d814 {
+ compatible = "via,vt8500-intc";
+ interrupt-controller;
+ reg = <0xd814 0x1>;
+ #interrupt-cells = <1>;
+ };
+
+ gpio: gpio-controller@d811 {
+ compatible = "via,vt8500-gpio";
+ gpio-controller;
+ reg = <0xd811 0x1>;
+ #gpio-cells = <3>;
+ };
+
+ pmc@d813 {
+ compatible = "via,vt8500-pmc";
+ reg = <0xd813 0x1000>;
+ };
+
+ timer@d8130100 {
+ compatible = "via,vt8500-timer";
+ reg = <0xd8130100 0x28>;
+ interrupts = <36>;
+ };
+
+ ehci@d8007900 {
+ compatible = "via,vt8500-ehci";
+ reg = <0xd8007900 0x200>;
+ interrupts = <43>;
+ };
+
+ uhci@d8007b00 {
+ compatible = "platform-uhci";
+ reg = <0xd8007b00 0x200>;
+ interrupts = <43>;
+ };
+
+ fb@d800e400 {
+ compatible = "via,vt8500-fb";
+ reg = <0xd800e400 0x400>;
+ interrupts = <12>;
+ };
+
+ ge_rops@d8050400 {
+ compatible = "wm,prizm-ge-rops";
+ reg = <0xd8050400 0x100>;
+ };
+
+ uart@d820 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd820 0x1040>;
+ interrupts = <32>;
+ };
+
+ uart@d82b {
+ compatible = "via,vt8500-uart";
+ reg = <0xd82b 0x1040>;
+ interrupts = <33>;
+ };
+
+ uart@d821 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd821 0x1040>;
+ interrupts = <47>;
+ };
+
+ uart@d82c {
+ compatible = "via,vt8500-uart";
+ reg = <0xd82c 0x1040>;
+ interrupts = <50>;
+ };
+
+ rtc@d810 {
+ compatible = "via,vt8500-rtc";
+
Re: [PATCH v5 10/12] block: Add bio_clone_kmalloc()
On Wed, Aug 08, 2012 at 04:15:52PM -0700, Tejun Heo wrote:
> On Mon, Aug 06, 2012 at 03:08:39PM -0700, Kent Overstreet wrote:
>
> How about the following?
>
> There was no API to kmalloc bio and clone and osdblk was using
> explicit bio_kmalloc() + __bio_clone(). (my guess here) As this is
> inconvenient and there will be more users of it in the future, add
> bio_clone_kmalloc() and use it in osdblk.
Adding that.
>
> > Acked-by: Boaz Harrosh
> > Signed-off-by: Kent Overstreet
> > ---
> > drivers/block/osdblk.c |3 +--
> > fs/bio.c | 13 +
> > fs/exofs/ore.c |5 ++---
> > include/linux/bio.h|1 +
> > 4 files changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/block/osdblk.c b/drivers/block/osdblk.c
> > index 87311eb..1bbc681 100644
> > --- a/drivers/block/osdblk.c
> > +++ b/drivers/block/osdblk.c
> > @@ -266,11 +266,10 @@ static struct bio *bio_chain_clone(struct bio
> > *old_chain, gfp_t gfpmask)
> > struct bio *tmp, *new_chain = NULL, *tail = NULL;
> >
> > while (old_chain) {
> > - tmp = bio_kmalloc(gfpmask, old_chain->bi_max_vecs);
> > + tmp = bio_clone_kmalloc(old_chain, gfpmask);
> > if (!tmp)
> > goto err_out;
> >
> > - __bio_clone(tmp, old_chain);
> > tmp->bi_bdev = NULL;
> > gfpmask &= ~__GFP_WAIT;
> > tmp->bi_next = NULL;
> > diff --git a/fs/bio.c b/fs/bio.c
> > index f0c865b..77b9313 100644
> > --- a/fs/bio.c
> > +++ b/fs/bio.c
> > @@ -497,6 +497,19 @@ struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> > }
> > EXPORT_SYMBOL(bio_clone);
> >
>
> /**
>
> PLEASE.
>
> > +struct bio *bio_clone_kmalloc(struct bio *bio, gfp_t gfp_mask)
> > +{
> > + struct bio *b = bio_kmalloc(gfp_mask, bio->bi_max_vecs);
>
> Can't we use %NULL bioset as an indication to allocate from kmalloc
> instead of duping interfaces like this?
The two aren't mutually exclusive - but using BIO_KMALLOC_POOL instead
of separate interfaces is an excellent idea, I'll do that.
That means bio_clone_kmalloc will just become:
static inline struct bio *bio_clone_kmalloc(struct bio *bio,
gfp_t gfp_mask)
{
return bio_clone_bioset(bio, gfp_mask, BIO_KMALLOC_POOL)
}
(or maybe NULL there, I think using NULL for the interface makes sense,
I just don't want to use it for bi_pool).
Do you still want the /** for a one line wrapper like that?
>
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] VFS: d_obtain_alias needs to use "/" as default name.
NFS appears to use d_obtain_alias() to create the root dentry rather
than d_make_root. This can cause 'prepend_path()' to complain that the
root has a weird name if an NFS filesystem is lazily unmounted.
e.g. if "/mnt" is an NFS mount then
{ cd /mnt; umount -l /mnt ; ls -l /proc/self/cwd; }
will cause a WARN message like
WARNING: at /home/git/linux/fs/dcache.c:2624 prepend_path+0x1d7/0x1e0()
...
Root dentry has weird name <>
to appear in kernel logs.
So change d_obtain_alias() to use "/" rather than "" as the anonymous
name.
Signed-off-by: NeilBrown
diff --git a/fs/dcache.c b/fs/dcache.c
index 8086636..c959e41 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1579,7 +1579,7 @@ EXPORT_SYMBOL(d_find_any_alias);
*/
struct dentry *d_obtain_alias(struct inode *inode)
{
- static const struct qstr anonstring = { .name = "" };
+ static const struct qstr anonstring = QSTR_INIT("/", 1);
struct dentry *tmp;
struct dentry *res;
signature.asc
Description: PGP signature
[PATCHv2 0/8] *** ARM: Update arch-vt8500 to Devicetree ***
This patchset updates arch-vt8500 to devicetree and removes all the old-style code. Support for WM8650 has also been added. Example dts/dtsi files are given for the three currently supported models. Major changes: GPIO code has been converted to a platform_device and rewritten as WM8505 support was broken. Add support for WM8650 gpio controller. UHCI support was missing. Added this as a generic non-pci uhci controller as it doesn't require anything special. Should be usable by any system that doesn't have special requirements to get the UHCI controller working. Framebuffer code patched to support WM8650. The bindings for this are of concern but there doesn't seem to be a formalized binding yet. This patch is based off Sascha Hauer's current patch on the dri-devel mailing list and should be easily patched out when its finalized. Patchset based on Arnd's arm-soc/for-next branch. Could I get this reviewed, hopefully for inclusion into v3.7. Regards Tony Prisk Changes v2: Cleanup style/formatting errors Removed erroneous commit message about GPIO not being converted to devicetree Corrected arch-vt8500/irq.c header to correct filename Changed GPIO driver to use module_platform_driver() Renamed vt8500_gpio_bank_regs -> vt8500_gpio_bank_regoffsets Changed vt8500_gpio_bank_regoffset fields to unsigned int Changed bit-setting code to use BIT() macro Removed of_find_compatible() and use pdev->dev.of_node in _probe() Removed regoff field and related code - leftover from old design Added kerneldoc regarding struct vt8500_gpio_bank_regoffsets fields Update MODULE_LICENSE on all platform devices to "GPL v2" to match their headers Renamed dts board files to clarify product names Tony Prisk (8): arm: vt8500: Add device tree files for VIA/Wondermedia SoC's rtc: vt8500: Add devicetree support for vt8500-rtc serial: vt8500: Add devicetree support for vt8500-serial usb: vt8500: Add devicetree support for vt8500-ehci and -uhci. video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb arm: vt8500: Update arch-vt8500 to devicetree support. arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices ARM: vt8500: gpio: Devicetree support for arch-vt8500 Documentation/devicetree/bindings/arm/vt8500.txt | 15 + .../bindings/arm/vt8500/via,vt8500-intc.txt| 16 + .../bindings/arm/vt8500/via,vt8500-pmc.txt | 13 + .../bindings/arm/vt8500/via,vt8500-timer.txt | 15 + .../devicetree/bindings/gpio/gpio_vt8500.txt | 24 ++ .../devicetree/bindings/rtc/via,vt8500-rtc.txt | 15 + .../bindings/tty/serial/via,vt8500-uart.txt| 15 + .../devicetree/bindings/usb/platform-uhci.txt | 15 + .../devicetree/bindings/usb/via,vt8500-ehci.txt| 15 + .../devicetree/bindings/vendor-prefixes.txt|2 + .../devicetree/bindings/video/via,vt8500-fb.txt| 46 +++ .../devicetree/bindings/video/wm,prizm-ge-rops.txt | 13 + .../devicetree/bindings/video/wm,wm8505-fb.txt | 20 ++ arch/arm/Kconfig |2 + arch/arm/boot/dts/vt8500.dtsi | 99 ++ arch/arm/boot/dts/vt8500_ref.dts | 31 ++ arch/arm/boot/dts/wm8505.dtsi | 125 arch/arm/boot/dts/wm8505_ref.dts | 31 ++ arch/arm/boot/dts/wm8650.dtsi | 95 ++ arch/arm/boot/dts/wm8650_ref.dts | 31 ++ arch/arm/mach-vt8500/Kconfig | 72 + arch/arm/mach-vt8500/Makefile |9 +- arch/arm/mach-vt8500/bv07.c| 80 - arch/arm/mach-vt8500/common.h | 25 ++ arch/arm/mach-vt8500/devices-vt8500.c | 91 -- arch/arm/mach-vt8500/devices-wm8505.c | 99 -- arch/arm/mach-vt8500/devices.c | 270 - arch/arm/mach-vt8500/devices.h | 88 -- arch/arm/mach-vt8500/gpio.c| 240 --- arch/arm/mach-vt8500/include/mach/restart.h|4 +- arch/arm/mach-vt8500/include/mach/vt8500_irqs.h| 88 -- arch/arm/mach-vt8500/include/mach/vt8500_regs.h| 79 - arch/arm/mach-vt8500/include/mach/wm8505_irqs.h| 115 --- arch/arm/mach-vt8500/include/mach/wm8505_regs.h| 78 - arch/arm/mach-vt8500/irq.c | 160 +- arch/arm/mach-vt8500/restart.c | 54 arch/arm/mach-vt8500/timer.c | 56 +++- arch/arm/mach-vt8500/vt8500.c | 192 arch/arm/mach-vt8500/wm8505_7in.c | 79 - drivers/gpio/Kconfig |6 + drivers/gpio/Makefile |1 + drivers/gpio/gpio-vt8500.c | 318 drivers/rtc/rtc-vt8500.c |7 +
[PATCHv2 2/8] rtc: vt8500: Add devicetree support for vt8500-rtc
Signed-off-by: Tony Prisk
---
drivers/rtc/rtc-vt8500.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
index 9e94fb1..07bf193 100644
--- a/drivers/rtc/rtc-vt8500.c
+++ b/drivers/rtc/rtc-vt8500.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
/*
* Register definitions
@@ -302,12 +303,18 @@ static int __devexit vt8500_rtc_remove(struct
platform_device *pdev)
return 0;
}
+static const struct of_device_id wmt_dt_ids[] = {
+ { .compatible = "via,vt8500-rtc", },
+ {}
+};
+
static struct platform_driver vt8500_rtc_driver = {
.probe = vt8500_rtc_probe,
.remove = __devexit_p(vt8500_rtc_remove),
.driver = {
.name = "vt8500-rtc",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(wmt_dt_ids),
},
};
@@ -315,5 +322,5 @@ module_platform_driver(vt8500_rtc_driver);
MODULE_AUTHOR("Alexey Charkov ");
MODULE_DESCRIPTION("VIA VT8500 SoC Realtime Clock Driver (RTC)");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:vt8500-rtc");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 5/8] video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb
Update vt8500-fb, wm8505-fb and wmt-ge-rops to support device
tree bindings.
Small change in wm8505-fb.c to support WM8650 framebuffer color
format.
Signed-off-by: Tony Prisk
---
drivers/video/Kconfig |6 +--
drivers/video/vt8500lcdfb.c | 79 ++-
drivers/video/wm8505fb.c| 97 ---
drivers/video/wmt_ge_rops.c |9 +++-
4 files changed, 161 insertions(+), 30 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..b66d951 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1788,7 +1788,7 @@ config FB_AU1200
config FB_VT8500
bool "VT8500 LCD Driver"
- depends on (FB = y) && ARM && ARCH_VT8500 && VTWM_VERSION_VT8500
+ depends on (FB = y) && ARM && ARCH_VT8500
select FB_WMT_GE_ROPS
select FB_SYS_IMAGEBLIT
help
@@ -1797,11 +1797,11 @@ config FB_VT8500
config FB_WM8505
bool "WM8505 frame buffer support"
- depends on (FB = y) && ARM && ARCH_VT8500 && VTWM_VERSION_WM8505
+ depends on (FB = y) && ARM && ARCH_VT8500
select FB_WMT_GE_ROPS
select FB_SYS_IMAGEBLIT
help
- This is the framebuffer driver for WonderMedia WM8505
+ This is the framebuffer driver for WonderMedia WM8505/WM8650
integrated LCD controller.
source "drivers/video/geode/Kconfig"
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 2a5fe6e..d62234e 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -35,6 +35,13 @@
#include "vt8500lcdfb.h"
#include "wmt_ge_rops.h"
+#ifdef CONFIG_OF
+#include
+#include
+#include
+#endif
+
+
#define to_vt8500lcd_info(__info) container_of(__info, \
struct vt8500lcd_info, fb)
@@ -270,15 +277,21 @@ static int __devinit vt8500lcd_probe(struct
platform_device *pdev)
{
struct vt8500lcd_info *fbi;
struct resource *res;
- struct vt8500fb_platform_data *pdata = pdev->dev.platform_data;
void *addr;
int irq, ret;
+ struct fb_videomode of_mode;
+ struct device_node *np;
+ u32 bpp;
+ dma_addr_t fb_mem_phys;
+ unsigned long fb_mem_len;
+ void *fb_mem_virt;
+
ret = -ENOMEM;
fbi = NULL;
- fbi = kzalloc(sizeof(struct vt8500lcd_info) + sizeof(u32) * 16,
- GFP_KERNEL);
+ fbi = devm_kzalloc(>dev, sizeof(struct vt8500lcd_info)
+ + sizeof(u32) * 16, GFP_KERNEL);
if (!fbi) {
dev_err(>dev, "Failed to initialize framebuffer
device\n");
ret = -ENOMEM;
@@ -333,9 +346,45 @@ static int __devinit vt8500lcd_probe(struct
platform_device *pdev)
goto failed_free_res;
}
- fbi->fb.fix.smem_start = pdata->video_mem_phys;
- fbi->fb.fix.smem_len= pdata->video_mem_len;
- fbi->fb.screen_base = pdata->video_mem_virt;
+ np = of_find_node_by_name(NULL, "display");
+ if (!np) {
+ pr_err("%s: No display description in Device Tree\n", __func__);
+ ret = -EINVAL;
+ goto failed_free_res;
+ }
+
+ /*
+* This code is copied from Sascha Hauer's of_videomode helper
+* and can be replaced with a call to the helper once mainlined
+*/
+ ret = 0;
+ ret |= of_property_read_u32(np, "xres", _mode.xres);
+ ret |= of_property_read_u32(np, "yres", _mode.yres);
+ ret |= of_property_read_u32(np, "left-margin", _mode.left_margin);
+ ret |= of_property_read_u32(np, "right-margin", _mode.right_margin);
+ ret |= of_property_read_u32(np, "hsync-len", _mode.hsync_len);
+ ret |= of_property_read_u32(np, "upper-margin", _mode.upper_margin);
+ ret |= of_property_read_u32(np, "lower-margin", _mode.lower_margin);
+ ret |= of_property_read_u32(np, "vsync-len", _mode.vsync_len);
+ ret |= of_property_read_u32(np, "bpp", );
+ if (ret) {
+ pr_err("%s: Unable to read display properties\n", __func__);
+ goto failed_free_res;
+ }
+ of_mode.vmode = FB_VMODE_NONINTERLACED;
+
+ /* try allocating the framebuffer */
+ fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
+ fb_mem_virt = dma_alloc_coherent(>dev, fb_mem_len, _mem_phys,
+ GFP_KERNEL);
+ if (!fb_mem_virt) {
+ pr_err("%s: Failed to allocate framebuffer\n", __func__);
+ return -ENOMEM;
+ };
+
+ fbi->fb.fix.smem_start = fb_mem_phys;
+ fbi->fb.fix.smem_len= fb_mem_len;
+ fbi->fb.screen_base = fb_mem_virt;
fbi->palette_size = PAGE_ALIGN(512);
fbi->palette_cpu= dma_alloc_coherent(>dev,
@@ -370,10 +419,11 @@ static int __devinit
[PATCHv2 4/8] usb: vt8500: Add devicetree support for vt8500-ehci and -uhci.
Add devicetree support for vt8500-ehci.
Convert vt8500-uhci to a generic non-pci platform-uhci with
device tree support.
Signed-off-by: Tony Prisk
---
drivers/usb/host/Kconfig |4 +-
drivers/usb/host/ehci-vt8500.c | 25 --
drivers/usb/host/uhci-hcd.c |5 ++
drivers/usb/host/uhci-platform.c | 169 ++
4 files changed, 195 insertions(+), 8 deletions(-)
create mode 100644 drivers/usb/host/uhci-platform.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index dcfaaa9..d7a6b10 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -450,7 +450,7 @@ config USB_OHCI_LITTLE_ENDIAN
config USB_UHCI_HCD
tristate "UHCI HCD (most Intel and VIA) support"
- depends on USB && (PCI || SPARC_LEON)
+ depends on USB && (PCI || SPARC_LEON || ARCH_VT8500)
---help---
The Universal Host Controller Interface is a standard by Intel for
accessing the USB hardware in the PC (which is also called the USB
@@ -468,7 +468,7 @@ config USB_UHCI_HCD
config USB_UHCI_SUPPORT_NON_PCI_HC
bool
depends on USB_UHCI_HCD
- default y if SPARC_LEON
+ default y if (SPARC_LEON || ARCH_VT8500)
config USB_UHCI_BIG_ENDIAN_MMIO
bool
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
index c1eda73..0e1637b 100644
--- a/drivers/usb/host/ehci-vt8500.c
+++ b/drivers/usb/host/ehci-vt8500.c
@@ -16,6 +16,7 @@
*
*/
+#include
#include
static int ehci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
@@ -84,20 +85,23 @@ static const struct hc_driver vt8500_ehci_hc_driver = {
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
};
+static u64 wmt_ehci_dma_mask = DMA_BIT_MASK(32);
+
static int vt8500_ehci_drv_probe(struct platform_device *pdev)
{
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
struct resource *res;
+ int irq;
int ret;
if (usb_disabled())
return -ENODEV;
- if (pdev->resource[1].flags != IORESOURCE_IRQ) {
- pr_debug("resource[1] is not IORESOURCE_IRQ");
- return -ENOMEM;
- }
+ /* devicetree created devices don't specify a dma mask */
+ if (!pdev->dev.dma_mask)
+ pdev->dev.dma_mask = _ehci_dma_mask;
+
hcd = usb_create_hcd(_ehci_hc_driver, >dev, "VT8500");
if (!hcd)
return -ENOMEM;
@@ -134,8 +138,9 @@ static int vt8500_ehci_drv_probe(struct platform_device
*pdev)
ehci_reset(ehci);
- ret = usb_add_hcd(hcd, pdev->resource[1].start,
- IRQF_SHARED);
+ irq = platform_get_irq(pdev, 0);
+
+ ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret == 0) {
platform_set_drvdata(pdev, hcd);
return ret;
@@ -162,6 +167,11 @@ static int vt8500_ehci_drv_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id vt8500_ehci_ids[] = {
+ { .compatible = "via,vt8500-ehci", },
+ {}
+};
+
static struct platform_driver vt8500_ehci_driver = {
.probe = vt8500_ehci_drv_probe,
.remove = vt8500_ehci_drv_remove,
@@ -169,7 +179,10 @@ static struct platform_driver vt8500_ehci_driver = {
.driver = {
.name = "vt8500-ehci",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
};
MODULE_ALIAS("platform:vt8500-ehci");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index e4db350..5da5c99 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -846,6 +846,11 @@ static const char hcd_name[] = "uhci_hcd";
#define PLATFORM_DRIVERuhci_grlib_driver
#endif
+#ifdef CONFIG_ARCH_VT8500
+#include "uhci-platform.c"
+#define PLATFORM_DRIVERuhci_platform_driver
+#endif
+
#if !defined(PCI_DRIVER) && !defined(PLATFORM_DRIVER)
#error "missing bus glue for uhci-hcd"
#endif
diff --git a/drivers/usb/host/uhci-platform.c b/drivers/usb/host/uhci-platform.c
new file mode 100644
index 000..35ca094
--- /dev/null
+++ b/drivers/usb/host/uhci-platform.c
@@ -0,0 +1,169 @@
+/*
+ * Generic UHCI HCD (Host Controller Driver) for Platform Devices
+ *
+ * Copyright (c) 2011 Tony Prisk
+ *
+ * This file is based on uhci-grlib.c
+ * (C) Copyright 2004-2007 Alan Stern, st...@rowland.harvard.edu
+ */
+
+#include
+#include
+
+static int uhci_platform_init(struct usb_hcd *hcd)
+{
+ struct uhci_hcd *uhci = hcd_to_uhci(hcd);
+
+ uhci->rh_numports = uhci_count_ports(hcd);
+
+ /* Set up pointers to to generic functions */
+ uhci->reset_hc = uhci_generic_reset_hc;
+ uhci->check_and_reset_hc = uhci_generic_check_and_reset_hc;
+
+ /* No special actions need to be taken
[PATCHv2 8/8] arm: vt8500: gpio: Devicetree support for arch-vt8500
Converted the existing arch-vt8500 gpio to a platform_device.
Added support for WM8505 and WM8650 GPIO controllers.
Signed-off-by: Tony Prisk
---
drivers/gpio/Kconfig |6 +
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-vt8500.c | 313
3 files changed, 320 insertions(+)
create mode 100644 drivers/gpio/gpio-vt8500.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 542f0c0..3c8897a 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -183,6 +183,12 @@ config GPIO_STA2X11
Say yes here to support the STA2x11/ConneXt GPIO device.
The GPIO module has 128 GPIO pins with alternate functions.
+config GPIO_VT8500
+ bool "VIA/Wondermedia SoC GPIO Support"
+ depends on ARCH_VT8500
+ help
+ Say yes here to support the VT8500/WM8505/WM8650 GPIO controller.
+
config GPIO_XILINX
bool "Xilinx GPIO support"
depends on PPC_OF || MICROBLAZE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 0f55662..2c014b9 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_GPIO_TPS65912) += gpio-tps65912.o
obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
obj-$(CONFIG_GPIO_UCB1400) += gpio-ucb1400.o
obj-$(CONFIG_GPIO_VR41XX) += gpio-vr41xx.o
+obj-$(CONFIG_GPIO_VT8500) += gpio-vt8500.o
obj-$(CONFIG_GPIO_VX855) += gpio-vx855.o
obj-$(CONFIG_GPIO_WM831X) += gpio-wm831x.o
obj-$(CONFIG_GPIO_WM8350) += gpio-wm8350.o
diff --git a/drivers/gpio/gpio-vt8500.c b/drivers/gpio/gpio-vt8500.c
new file mode 100644
index 000..19b12d9
--- /dev/null
+++ b/drivers/gpio/gpio-vt8500.c
@@ -0,0 +1,313 @@
+/* linux/arch/arm/mach-vt8500/gpio.c
+ *
+ * Copyright (C) 2012 Tony Prisk
+ * Based on gpio.c:
+ * - Copyright (C) 2010 Alexey Charkov
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ We handle GPIOs by bank, each bank containing up to 32 GPIOs covered
+ by one set of registers (although not all may be valid).
+
+ Because different SoC's have different register offsets, we pass the
+ register offsets as data in vt8500_gpio_dt_ids[].
+
+ A value of NO_REG is used to indicate that this register is not
+ supported. Only used for ->en at the moment.
+*/
+
+#define NO_REG 0x
+
+/*
+ * struct vt8500_gpio_bank_regoffsets
+ * @en: offset to enable register of the bank
+ * @dir: offset to direction register of the bank
+ * @data_out: offset to the data out register of the bank
+ * @data_in: offset to the data in register of the bank
+ * @ngpio: highest valid pin in this bank
+ */
+
+struct vt8500_gpio_bank_regoffsets {
+ unsigned inten;
+ unsigned intdir;
+ unsigned intdata_out;
+ unsigned intdata_in;
+ unsigned char ngpio;
+};
+
+struct vt8500_gpio_data {
+ unsigned intnum_banks;
+ struct vt8500_gpio_bank_regoffsets banks[];
+};
+
+#define VT8500_BANK(__en, __dir, __out, __in, __ngpio) \
+{ \
+ .en = __en, \
+ .dir = __dir, \
+ .data_out = __out, \
+ .data_in = __in,\
+ .ngpio = __ngpio, \
+}
+
+static struct vt8500_gpio_data vt8500_data = {
+ .num_banks = 7,
+ .banks = {
+ VT8500_BANK(0x00, 0x20, 0x40, 0x60, 26),
+ VT8500_BANK(0x04, 0x24, 0x44, 0x64, 28),
+ VT8500_BANK(0x08, 0x28, 0x48, 0x68, 31),
+ VT8500_BANK(0x0C, 0x2C, 0x4C, 0x6C, 19),
+ VT8500_BANK(0x10, 0x30, 0x50, 0x70, 19),
+ VT8500_BANK(0x14, 0x34, 0x54, 0x74, 23),
+ VT8500_BANK(NO_REG, 0x3C, 0x5C, 0x7C, 9),
+ },
+};
+
+static struct vt8500_gpio_data wm8505_data = {
+ .num_banks = 10,
+ .banks = {
+ VT8500_BANK(0x40, 0x68, 0x90, 0xB8, 8),
+ VT8500_BANK(0x44, 0x6C, 0x94, 0xBC, 32),
+ VT8500_BANK(0x48, 0x70, 0x98, 0xC0, 6),
+ VT8500_BANK(0x4C, 0x74, 0x9C, 0xC4, 16),
+ VT8500_BANK(0x50, 0x78, 0xA0, 0xC8, 25),
+ VT8500_BANK(0x54, 0x7C, 0xA4, 0xCC, 5),
+
[PATCHv2 7/8] arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices
Bindings for gpio, interrupt controller, power management controller,
timer, realtime clock, serial uart, ehci and uhci controllers and
framebuffer controllers used on the arch-vt8500 platform.
Framebuffer binding also specifies a 'display' node which is required
for determining the lcd panel data.
Signed-off-by: Tony Prisk
---
Documentation/devicetree/bindings/arm/vt8500.txt | 15 +++
.../bindings/arm/vt8500/via,vt8500-intc.txt| 16 +++
.../bindings/arm/vt8500/via,vt8500-pmc.txt | 13 ++
.../bindings/arm/vt8500/via,vt8500-timer.txt | 15 +++
.../devicetree/bindings/gpio/gpio_vt8500.txt | 24 ++
.../devicetree/bindings/rtc/via,vt8500-rtc.txt | 15 +++
.../bindings/tty/serial/via,vt8500-uart.txt| 15 +++
.../devicetree/bindings/usb/platform-uhci.txt | 15 +++
.../devicetree/bindings/usb/via,vt8500-ehci.txt| 15 +++
.../devicetree/bindings/vendor-prefixes.txt|2 +
.../devicetree/bindings/video/via,vt8500-fb.txt| 46
.../devicetree/bindings/video/wm,prizm-ge-rops.txt | 13 ++
.../devicetree/bindings/video/wm,wm8505-fb.txt | 20 +
13 files changed, 224 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/vt8500.txt
create mode 100644
Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
create mode 100644
Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
create mode 100644
Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
create mode 100644 Documentation/devicetree/bindings/gpio/gpio_vt8500.txt
create mode 100644 Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt
create mode 100644
Documentation/devicetree/bindings/tty/serial/via,vt8500-uart.txt
create mode 100644 Documentation/devicetree/bindings/usb/platform-uhci.txt
create mode 100644 Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
create mode 100644 Documentation/devicetree/bindings/video/via,vt8500-fb.txt
create mode 100644 Documentation/devicetree/bindings/video/wm,prizm-ge-rops.txt
create mode 100644 Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
diff --git a/Documentation/devicetree/bindings/arm/vt8500.txt
b/Documentation/devicetree/bindings/arm/vt8500.txt
new file mode 100644
index 000..1b3b187
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500.txt
@@ -0,0 +1,15 @@
+VIA/Wondermedia VT8500 Platforms Device Tree Bindings
+---
+
+Boards with the VIA VT8500 SoC shall have the following properties:
+Required root node property:
+compatible = "via,vt8500";
+
+Boards with the Wondermedia WM8505 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8505";
+
+Boards with the Wondermedia WM8650 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8650";
+
diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
new file mode 100644
index 000..0a4ce10
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
@@ -0,0 +1,16 @@
+VIA/Wondermedia VT8500 Interrupt Controller
+-
+
+Required properties:
+- compatible : "via,vt8500-intc"
+- reg : Should contain 1 register ranges(address and length)
+- #interrupt-cells : should be <1>
+
+Example:
+
+ intc: interrupt-controller@d814 {
+ compatible = "via,vt8500-intc";
+ interrupt-controller;
+ reg = <0xd814 0x1>;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
new file mode 100644
index 000..521b9c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
@@ -0,0 +1,13 @@
+VIA/Wondermedia VT8500 Power Management Controller
+-
+
+Required properties:
+- compatible : "via,vt8500-pmc"
+- reg : Should contain 1 register ranges(address and length)
+
+Example:
+
+ pmc@d813 {
+ compatible = "via,vt8500-pmc";
+ reg = <0xd813 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
new file mode 100644
index 000..901c73f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
@@ -0,0 +1,15 @@
+VIA/Wondermedia VT8500 Timer
+-
+
+Required properties:
+- compatible : "via,vt8500-timer"
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : interrupt for the timer
+
+Example:
+
+ timer@d8130100 {
+ compatible
[PATCHv2 3/8] serial: vt8500: Add devicetree support for vt8500-serial
Signed-off-by: Tony Prisk
---
drivers/tty/serial/vt8500_serial.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index 2be006f..dee6715 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
/*
* UART Register offsets
@@ -603,12 +604,18 @@ static int __devexit vt8500_serial_remove(struct
platform_device *pdev)
return 0;
}
+static const struct of_device_id wmt_dt_ids[] = {
+ { .compatible = "via,vt8500-uart", },
+ {}
+};
+
static struct platform_driver vt8500_platform_driver = {
.probe = vt8500_serial_probe,
.remove = __devexit_p(vt8500_serial_remove),
.driver = {
.name = "vt8500_serial",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(wmt_dt_ids),
},
};
@@ -642,4 +649,4 @@ module_exit(vt8500_serial_exit);
MODULE_AUTHOR("Alexey Charkov ");
MODULE_DESCRIPTION("Driver for vt8500 serial device");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/3] mm: introduce compaction and migration for virtio ballooned pages
Hi Rafael,
On Wed, Aug 08, 2012 at 07:53:19PM -0300, Rafael Aquini wrote:
> Memory fragmentation introduced by ballooning might reduce significantly
> the number of 2MB contiguous memory blocks that can be used within a guest,
> thus imposing performance penalties associated with the reduced number of
> transparent huge pages that could be used by the guest workload.
>
> This patch introduces the helper functions as well as the necessary changes
> to teach compaction and migration bits how to cope with pages which are
> part of a guest memory balloon, in order to make them movable by memory
> compaction procedures.
>
> Signed-off-by: Rafael Aquini
> ---
> include/linux/mm.h | 17 +++
> mm/compaction.c| 131
> +
> mm/migrate.c | 30 +++-
> 3 files changed, 158 insertions(+), 20 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 311be90..18f978b 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1662,5 +1662,22 @@ static inline unsigned int
> debug_guardpage_minorder(void) { return 0; }
> static inline bool page_is_guard(struct page *page) { return false; }
> #endif /* CONFIG_DEBUG_PAGEALLOC */
>
> +#if (defined(CONFIG_VIRTIO_BALLOON) || \
> + defined(CONFIG_VIRTIO_BALLOON_MODULE)) && defined(CONFIG_COMPACTION)
> +extern bool isolate_balloon_page(struct page *);
> +extern bool putback_balloon_page(struct page *);
> +extern struct address_space *balloon_mapping;
> +
> +static inline bool movable_balloon_page(struct page *page)
> +{
> + return (page->mapping && page->mapping == balloon_mapping);
> +}
> +
> +#else
> +static inline bool isolate_balloon_page(struct page *page) { return false; }
> +static inline bool putback_balloon_page(struct page *page) { return false; }
> +static inline bool movable_balloon_page(struct page *page) { return false; }
> +#endif /* (VIRTIO_BALLOON || VIRTIO_BALLOON_MODULE) && CONFIG_COMPACTION */
> +
> #endif /* __KERNEL__ */
> #endif /* _LINUX_MM_H */
> diff --git a/mm/compaction.c b/mm/compaction.c
> index e78cb96..7372592 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include "internal.h"
>
> #if defined CONFIG_COMPACTION || defined CONFIG_CMA
> @@ -21,6 +22,90 @@
> #define CREATE_TRACE_POINTS
> #include
>
> +#if defined(CONFIG_VIRTIO_BALLOON) || defined(CONFIG_VIRTIO_BALLOON_MODULE)
> +/*
> + * Balloon pages special page->mapping.
> + * Users must properly allocate and initialize an instance of
> balloon_mapping,
> + * and set it as the page->mapping for balloon enlisted page instances.
> + * There is no need on utilizing struct address_space locking schemes for
> + * balloon_mapping as, once it gets initialized at balloon driver, it will
> + * remain just like a static reference that helps us on identifying a guest
> + * ballooned page by its mapping, as well as it will keep the 'a_ops'
> callback
> + * pointers to the functions that will execute the balloon page mobility
> tasks.
> + *
> + * address_space_operations necessary methods for ballooned pages:
> + * .migratepage- used to perform balloon's page migration (as is)
> + * .invalidatepage - used to isolate a page from balloon's page list
> + * .freepage - used to reinsert an isolated page to balloon's page
> list
> + */
> +struct address_space *balloon_mapping;
> +EXPORT_SYMBOL_GPL(balloon_mapping);
> +
> +static inline void __isolate_balloon_page(struct page *page)
> +{
> + page->mapping->a_ops->invalidatepage(page, 0);
> +}
> +
> +static inline void __putback_balloon_page(struct page *page)
> +{
> + page->mapping->a_ops->freepage(page);
> +}
> +
> +/* __isolate_lru_page() counterpart for a ballooned page */
> +bool isolate_balloon_page(struct page *page)
> +{
> + if (WARN_ON(!movable_balloon_page(page)))
> + return false;
> +
> + if (likely(get_page_unless_zero(page))) {
> + /*
> + * As balloon pages are not isolated from LRU lists, concurrent
> + * compaction threads can race against page migration functions
> + * move_to_new_page() & __unmap_and_move().
> + * In order to avoid having an already isolated balloon page
> + * being (wrongly) re-isolated while it is under migration,
> + * lets be sure we have the page lock before proceeding with
> + * the balloon page isolation steps.
> + */
> + if (likely(trylock_page(page))) {
> + /*
> + * A ballooned page, by default, has just one refcount.
> + * Prevent concurrent compaction threads from isolating
> + * an already isolated balloon page.
> + */
> + if (movable_balloon_page(page) &&
> + (page_count(page) == 2)) {
> +
Re: [ 029/109] batman-adv: fix skb->data assignment
On Tue, 2012-08-07 at 15:34 -0700, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Antonio Quartulli > > commit d2b6cc8e460494251442a877fcbc150faa175b4f upstream. [...] This was applied to David Miller's net-next, but then also on net as commit 2c995ff892313009e336ecc8ec3411022f5b1c39 upstream, which you've already applied as commit a7faba5c5263f9d8a31b3f542a0504552fa80932 in v3.4.5. This inserts the assignment a second time, which is harmless but weird. So please drop it. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Re: [dm-devel] [PATCH v2 2/2] dm: verity support data device offset (Linux 3.4.7)
On Thu, Aug 09, 2012 at 12:40:23AM +, Wesley Miaw wrote: > This isn't as polished because I pretty much just added support to do what I > needed. I'm not sure if the LKML is the right place to post, so let me know if > I should send this somewhere else. cryptsetup patches are best sent to the mailing list mentioned at the bottom of the project page http://code.google.com/p/cryptsetup/ viz. dm-cr...@saout.de. Alasdair -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 3/3] mm: add vm event counters for balloon pages compaction
On 08/08/2012 06:53 PM, Rafael Aquini wrote: This patch is only for testing report purposes and shall be dropped in case of the rest of this patchset getting accepted for merging. I wonder if it would make sense to just keep these statistics, so if a change breaks balloon migration in the future, we'll be able to see it... Signed-off-by: Rafael Aquini Acked-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 08/12] block: Introduce new bio_split()
On Wed, Aug 08, 2012 at 04:05:32PM -0700, Tejun Heo wrote:
> One more thing.
>
> On Mon, Aug 06, 2012 at 03:08:37PM -0700, Kent Overstreet wrote:
> > + if (bio_integrity(bio)) {
> > + bio_integrity_clone(ret, bio, gfp, bs);
> > + bio_integrity_trim(ret, 0, bio_sectors(ret));
> > + bio_integrity_trim(bio, bio_sectors(ret), bio_sectors(bio));
>
> Is this equivalent to bio_integrity_split() performance-wise?
Strictly speaking, no. But it has the advantage of being drastically
simpler - and the only one only worked for single page bios so I
would've had to come up with something new from scratch, and as
confusing as the integrity stuff is I wouldn't trust the result.
I'm skeptical that it's going to matter in practice given how much
iteration is done elsewhere in the course of processing a bio and given
that this stuff isn't used with high end SSDs...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/3] virtio_balloon: introduce migration primitives to balloon pages
On 08/08/2012 06:53 PM, Rafael Aquini wrote: Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. Besides making balloon pages movable at allocation time and introducing the necessary primitives to perform balloon page migration/compaction, this patch also introduces the following locking scheme to provide the proper synchronization and protection for struct virtio_balloon elements against concurrent accesses due to parallel operations introduced by memory compaction / page migration. - balloon_lock (mutex) : synchronizes the access demand to elements of struct virtio_balloon and its queue operations; - pages_lock (spinlock): special protection to balloon pages list against concurrent list handling operations; Signed-off-by: Rafael Aquini Reviewed-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/3] mm: introduce compaction and migration for virtio ballooned pages
On 08/08/2012 06:53 PM, Rafael Aquini wrote: Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch introduces the helper functions as well as the necessary changes to teach compaction and migration bits how to cope with pages which are part of a guest memory balloon, in order to make them movable by memory compaction procedures. Signed-off-by: Rafael Aquini Reviewed-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/5] perf script: Add event_analyzing_sample.py as a sample for general event handling
On Wed, 8 Aug 2012 17:57:55 +0800, Feng Tang wrote:
> Currently only trace point events are supported in perf/python script,
> the first 3 patches of this serie add the support for all types of
s/serie/series/
> events. This script is just a simple sample to show how to gather the
> basic information of the events and analyze them.
>
> This script will create one object for each event sample and insert
> them into a table in a database, then leverage the simple SQL commands
> to sort/group them. User can modify or write their brand new functions
> according to their specific requirment.
s/requirment/requirement/
>
> Here is the sample of how to use the script:
> feng@feng-i7:/dev/shm$perf record -a tree
> feng@feng-i7:/dev/shm$perf script -s process_event.py
s/process_event/event_analyzing_sample/
>
> -
> There is 100 records in gen_events table
> Statistics about the general events grouped by thread/symbol/dso:
>
> comm number histgram
> ==
> swapper 56 ##
> tree 20 #
> perf 10
> sshd8
> kworker/7:24 ###
> ksoftirqd/71 #
> plugin-containe1 #
>
> symbol number histgram
> ==
>native_write_msr_safe 40 ##
> __lock_acquire8
> ftrace_graph_caller4 ###
>prepare_ftrace_return4 ###
> intel_idle3 ##
> native_sched_clock3 ##
> Unknown_symbol2 ##
> do_softirq2 ##
> lock_release2 ##
>lock_release_holdtime2 ##
>trace_graph_entry2 ##
> _IO_putc1 #
> __d_lookup_rcu1 #
> __do_fault1 #
> __schedule1 #
> _raw_spin_lock1 #
>delay_tsc1 #
> generic_exec_single1 #
> generic_fillattr1 #
>
> dso number histgram
> ==
>[kernel.kallsyms] 95 ###
> /lib/libc-2.12.1.so5 ###
>
> Signed-off-by: Feng Tang
> ---
> .../perf/scripts/python/event_analyzing_sample.py | 193
>
> 1 files changed, 193 insertions(+), 0 deletions(-)
> create mode 100644 tools/perf/scripts/python/event_analyzing_sample.py
>
> diff --git a/tools/perf/scripts/python/event_analyzing_sample.py
> b/tools/perf/scripts/python/event_analyzing_sample.py
> new file mode 100644
> index 000..46f05aa
> --- /dev/null
> +++ b/tools/perf/scripts/python/event_analyzing_sample.py
> @@ -0,0 +1,193 @@
> +# process_event.py: general event handler in python
s/process_event/event_analyzing_sample/
> +#
> +# Current perf report is alreay very powerful with the anotation integrated,
s/alreay/already/ s/anotation/annotation/
> +# and this script is not trying to be as powerful as perf report, but
> +# providing end user/developer a flexible way to analyze the events other
> +# than trace points.
> +#
> +# The 2 database related functions in this script just show how to gather
> +# the basic information, and users can modify and write their own functions
> +# according to their specific requirment.
s/requirment/requirement/
> +#
> +# The first sample "show_general_events" just does a baisc grouping for all
s/sample/function/ s/baisc/basic/
> +# generic events with the help of sqlite, and the 2nd one "show_pebs_ll" is
> +# for a x86 HW PMU event: PEBS with load latency data.
> +#
> +
> +import os
> +import sys
> +import math
> +import struct
> +import sqlite3
> +
> +sys.path.append(os.environ['PERF_EXEC_PATH'] + \
> +'/scripts/python/Perf-Trace-Util/lib/Perf/Trace')
> +
> +from perf_trace_context import *
> +from EventClass import *
> +
> +#
> +# If the perf.data has a big number of samples, then the insert operation
> +# will be very time consuming (about 10+ minutes for 1 samples) if the
> +# .db database is on disk. Move the .db file to RAM based FS to speedup
> +# the handling, which will cut the time down to several seconds.
> +#
> +con = sqlite3.connect("/dev/shm/perf.db")
> +con.isolation_level = None
> +
> +def trace_begin():
> + print "In trace_begin:\n"
It seems it's not aligned with other statements, and even not needed at
all. Does it work?
> +
> +#
> +# Will create several tables at the start, pebs_ll is for PEBS data
> with
>
Re: [PATCH 3/5] mm: compaction: Capture a suitable high-order page immediately when it is made available
Hi Mel,
Just one questoin below.
On Wed, Aug 08, 2012 at 08:08:42PM +0100, Mel Gorman wrote:
> While compaction is migrating pages to free up large contiguous blocks for
> allocation it races with other allocation requests that may steal these
> blocks or break them up. This patch alters direct compaction to capture a
> suitable free page as soon as it becomes available to reduce this race. It
> uses similar logic to split_free_page() to ensure that watermarks are
> still obeyed.
>
> Signed-off-by: Mel Gorman
> Reviewed-by: Rik van Riel
> ---
> include/linux/compaction.h |4 +--
> include/linux/mm.h |1 +
> mm/compaction.c| 71
> +---
> mm/internal.h |1 +
> mm/page_alloc.c| 63 +--
> 5 files changed, 111 insertions(+), 29 deletions(-)
>
> diff --git a/include/linux/compaction.h b/include/linux/compaction.h
> index 51a90b7..5673459 100644
> --- a/include/linux/compaction.h
> +++ b/include/linux/compaction.h
> @@ -22,7 +22,7 @@ extern int sysctl_extfrag_handler(struct ctl_table *table,
> int write,
> extern int fragmentation_index(struct zone *zone, unsigned int order);
> extern unsigned long try_to_compact_pages(struct zonelist *zonelist,
> int order, gfp_t gfp_mask, nodemask_t *mask,
> - bool sync);
> + bool sync, struct page **page);
> extern int compact_pgdat(pg_data_t *pgdat, int order);
> extern unsigned long compaction_suitable(struct zone *zone, int order);
>
> @@ -64,7 +64,7 @@ static inline bool compaction_deferred(struct zone *zone,
> int order)
> #else
> static inline unsigned long try_to_compact_pages(struct zonelist *zonelist,
> int order, gfp_t gfp_mask, nodemask_t *nodemask,
> - bool sync)
> + bool sync, struct page **page)
> {
> return COMPACT_CONTINUE;
> }
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b36d08c..0812e86 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -454,6 +454,7 @@ void put_pages_list(struct list_head *pages);
>
> void split_page(struct page *page, unsigned int order);
> int split_free_page(struct page *page);
> +int capture_free_page(struct page *page, int alloc_order, int migratetype);
>
> /*
> * Compound pages have a destructor function. Provide a
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 95ca967..63af8d2 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -50,6 +50,41 @@ static inline bool migrate_async_suitable(int migratetype)
> return is_migrate_cma(migratetype) || migratetype == MIGRATE_MOVABLE;
> }
>
> +static void compact_capture_page(struct compact_control *cc)
> +{
> + unsigned long flags;
> + int mtype;
> +
> + if (!cc->page || *cc->page)
> + return;
> +
> + /* Speculatively examine the free lists without zone lock */
> + for (mtype = 0; mtype < MIGRATE_PCPTYPES; mtype++) {
> + int order;
> + for (order = cc->order; order < MAX_ORDER; order++) {
> + struct page *page;
> + struct free_area *area;
> + area = &(cc->zone->free_area[order]);
> + if (list_empty(>free_list[mtype]))
> + continue;
> +
> + /* Take the lock and attempt capture of the page */
> + spin_lock_irqsave(>zone->lock, flags);
> + if (!list_empty(>free_list[mtype])) {
> + page = list_entry(area->free_list[mtype].next,
> + struct page, lru);
> + if (capture_free_page(page, cc->order, mtype)) {
> + spin_unlock_irqrestore(>zone->lock,
> + flags);
> + *cc->page = page;
> + return;
> + }
> + }
> + spin_unlock_irqrestore(>zone->lock, flags);
> + }
> + }
> +}
> +
> /*
> * Isolate free pages onto a private freelist. Caller must hold zone->lock.
> * If @strict is true, will abort returning 0 on any invalid PFNs or non-free
> @@ -561,7 +596,6 @@ static isolate_migrate_t isolate_migratepages(struct zone
> *zone,
> static int compact_finished(struct zone *zone,
> struct compact_control *cc)
> {
> - unsigned int order;
> unsigned long watermark;
>
> if (fatal_signal_pending(current))
> @@ -586,14 +620,22 @@ static int compact_finished(struct zone *zone,
> return COMPACT_CONTINUE;
>
> /* Direct compactor: Is a suitable page free? */
> - for (order = cc->order; order < MAX_ORDER; order++) {
> -
Re: [PATCH v5 08/12] block: Introduce new bio_split()
On Wed, Aug 08, 2012 at 03:58:39PM -0700, Tejun Heo wrote:
> Hello,
>
> On Mon, Aug 06, 2012 at 03:08:37PM -0700, Kent Overstreet wrote:
> > /**
> > + * bio_split - split a bio
> > + * @bio: bio to split
> > + * @sectors: number of sectors to split from the front of @bio
> > + * @gfp: gfp mask
> > + * @bs:bio set to allocate from
> > + *
> > + * Allocates and returns a new bio which represents @sectors from the
> > start of
> > + * @bio, and updates @bio to represent the remaining sectors.
> > + *
> > + * If bio_sectors(@bio) was less than or equal to @sectors, returns @bio
> > + * unchanged.
>
> Umm I don't know. This is rather confusing. The function may
> return new or old bios? What's the rationale behind it? Return
> ERR_PTR(-EINVAL) instead?
Returning the old bio would be semantically equivalent to returning an
error, but IME when you're actually using it it does make sense and
leads to slightly cleaner code.
The reason is that when you're splitting, sectors is typically just the
maximum number of sectors you can handle here - you calculate the device
limit, or the number of sectors you can read from this location, or
whatever.
So the code ends up looking like:
while (1) {
split = bio_split(bio, sectors);
/* do some stuff to split and submit it */
/* check if that was the last split and break */
}
If bio_split returned an error, it'd make the code more convoluted -
you'd have to do work on either the split or the original bio, and then
repeat the same check later when it's time to break out of the loop.
>
> > + *
> > + * The newly allocated bio will point to @bio's bi_io_vec, if the split
> > was on a
> > + * bvec boundry; it is the caller's responsibility to ensure that @bio is
> > not
> > + * freed before the split.
>
> This is somewhat error-prone. Given how splits are used now, this
> might not be a big issue but it isn't difficult to imagine how this
> could go subtly wrong. More on this.
I can't find anything else in your emails on the subject...
So, I do agree, but there is a rationale:
Due to the way bio completions have to be chained, I'm not convinced
it's much of an issue in practice; if you're processing a bio by
splitting it, you can't complete it until all the splits have
completed, so you have to have a hook there.
In order for this to lead to a bug, you'd have to be cloning the
original bio (i.e. you can't be splitting a bio that someone else owns
and passed you, because that won't be freed until after you complete it)
and then you have to fail to put/free that clone in your hook, where
you're going to have other state to free too.
Cloning a bio and then not explicitly freeing it ought to be fairly
obviously wrong, IMO.
I think there's a more positive reason to do it this way long term, too.
I'm working towards getting rid of arbitrary restrictions in the block
layer, and forcing bio_split() to allocate the bvec introduces one;
allocating a bio with more than BIO_MAX_VECS will fail, and that _is_
the kind of tricky restriction that's likely to trip callers up (it's
certainly happened to me, I think multiple times).
Currently this is still an issue if the split isn't aligned on a bvec
boundary, but that's also fixable - by making the bvec immutable, which
would have a lot of other benefits too.
Making bio vecs immutable would also solve the original problem, because
cloning a bio would no longer clone the bvec as well - so the bvec the
split points to would _always_ be owned by something higher up that
couldn't free it until after the split completes.
>
> > + *
> > + * BIG FAT WARNING:
> > + *
> > + * If you're calling this from under generic_make_request() (i.e.
> > + * current->bio_list != NULL), you should mask out __GFP_WAIT and punt to
> > + * workqueue if the allocation fails. Otherwise, your code will probably
> > + * deadlock.
>
> If the condition is detectable, WARN_ON_ONCE() please.
Ok, I like that.
>
> > + * You can't allocate more than once from the same bio pool without
> > submitting
> > + * the previous allocations (so they'll eventually complete and deallocate
> > + * themselves), but if you're under generic_make_request() those previous
> > + * allocations won't submit until you return . And if you have to split
> > bios,
>^
> extra space
> > + * you should expect that some bios will require multiple splits.
> > + */
> > +struct bio *bio_split(struct bio *bio, int sectors,
> > + gfp_t gfp, struct bio_set *bs)
> > +{
> > + unsigned idx, vcnt = 0, nbytes = sectors << 9;
> > + struct bio_vec *bv;
> > + struct bio *ret = NULL;
> > +
> > + BUG_ON(sectors <= 0);
> > +
> > + if (sectors >= bio_sectors(bio))
> > + return bio;
> > +
> > + trace_block_split(bdev_get_queue(bio->bi_bdev), bio,
> > + bio->bi_sector + sectors);
> > +
> > +
Re: [PATCH v5 4/5] perf script: Add a python library EventClass.py
On Wed, 8 Aug 2012 17:57:54 +0800, Feng Tang wrote:
> This library defines several class types for perf events which could
> help to better analyze the event samples. Currently there are just a
> few classes, PerfEvent is the base class for all perf events, PebsEvent
> is a HW base Intel x86 PEBS event, and user could add more SW/HW event
> classes based on requriements.
>
> Signed-off-by: Feng Tang
> ---
> .../Perf-Trace-Util/lib/Perf/Trace/EventClass.py | 95
>
> 1 files changed, 95 insertions(+), 0 deletions(-)
> create mode 100755
> tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
>
> diff --git
> a/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
> b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
> new file mode 100755
> index 000..12cd773
> --- /dev/null
> +++ b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/EventClass.py
> @@ -0,0 +1,95 @@
> +# EventClass.py
> +#
> +# This is a libray defining some events typs classes, which could
s/typs/type/
> +# be used by other scripts to analyzing the perf samples.
> +#
> +# Currently there are just a few classes defined for examples,
> +# PerfEvent is the base class for all perf event sample, PebsEvent
> +# is a HW base Intel x86 PEBS event, and user could add more SW/HW
> +# event classes based on requriements.
s/requriements/requirements/
Thanks,
Namhyung
> +
> +import struct
> +
> +# Event types, user could add more here
> +EVTYPE_GENERIC = 0
> +EVTYPE_PEBS = 1 # Basic PEBS event
> +EVTYPE_PEBS_LL = 2 # PEBS event with load latency info
> +EVTYPE_IBS = 3
> +
> +#
> +# Currently we don't have good way to tell the event type, but by
> +# the size of raw buffer, raw PEBS event with load latency data's
> +# size is 176 bytes, while the pure PEBS event's size is 144 bytes.
> +#
> +def create_event(name, comm, dso, symbol, raw_buf):
> +if (len(raw_buf) == 144):
> +event = PebsEvent(name, comm, dso, symbol, raw_buf)
> +elif (len(raw_buf) == 176):
> +event = PebsNHM(name, comm, dso, symbol, raw_buf)
> +else:
> +event = PerfEvent(name, comm, dso, symbol, raw_buf)
> +
> +return event
> +
> +class PerfEvent(object):
> +event_num = 0
> +def __init__(self, name, comm, dso, symbol, raw_buf,
> ev_type=EVTYPE_GENERIC):
> +self.name = name
> +self.comm = comm
> +self.dso= dso
> +self.symbol = symbol
> +self.raw_buf= raw_buf
> +self.ev_type= ev_type
> +PerfEvent.event_num += 1
> +
> +def show(self):
> +print "PMU event: name=%12s, symbol=%24s, comm=%8s,
> dso=%12s" % (self.name, self.symbol, self.comm, self.dso)
> +
> +#
> +# Basic Intel PEBS (Precise Event-based Sampling) event, whose raw buffer
> +# contains the context info when that event happened: the EFLAGS and
> +# linear IP info, as well as all the registers.
> +#
> +class PebsEvent(PerfEvent):
> +pebs_num = 0
> +def __init__(self, name, comm, dso, symbol, raw_buf,
> ev_type=EVTYPE_PEBS):
> +tmp_buf=raw_buf[0:80]
> +flags, ip, ax, bx, cx, dx, si, di, bp, sp =
> struct.unpack('QQ', tmp_buf)
> +self.flags = flags
> +self.ip= ip
> +self.ax= ax
> +self.bx= bx
> +self.cx= cx
> +self.dx= dx
> +self.si= si
> +self.di= di
> +self.bp= bp
> +self.sp= sp
> +
> +PerfEvent.__init__(self, name, comm, dso, symbol, raw_buf,
> ev_type)
> +PebsEvent.pebs_num += 1
> +del tmp_buf
> +
> +#
> +# Intel Nehalem and Westmere support PEBS plus Load Latency info which lie
> +# in the four 64 bit words write after the PEBS data:
> +# Status: records the IA32_PERF_GLOBAL_STATUS register value
> +# DLA:Data Linear Address (EIP)
> +# DSE:Data Source Encoding, where the latency happens, hit or miss
> +# in L1/L2/L3 or IO operations
> +# LAT:the actual latency in cycles
> +#
> +class PebsNHM(PebsEvent):
> +pebs_nhm_num = 0
> +def __init__(self, name, comm, dso, symbol, raw_buf,
> ev_type=EVTYPE_PEBS_LL):
> +tmp_buf=raw_buf[144:176]
> +status, dla, dse, lat = struct.unpack('', tmp_buf)
> +self.status = status
> +self.dla = dla
> +self.dse = dse
> +self.lat = lat
> +
> +PebsEvent.__init__(self, name, comm, dso, symbol, raw_buf,
> ev_type)
> +PebsNHM.pebs_nhm_num += 1
> +del tmp_buf
> +
--
To unsubscribe from this list: send the line
Re: [PATCH v5 3/5] perf script/python: Pass event/thread/dso name and symbol info to event handler in python
On Wed, 8 Aug 2012 17:57:53 +0800, Feng Tang wrote:
> Also as suggested by Arnaldo, pack all these parameters to a dictionary,
> which is more expandable for adding new parameters while keeping the
> compatibility for old scripts.
>
Just minor nits.
> Signed-off-by: Feng Tang
> Cc: David Ahern
> Cc: Peter Zijlstra
> Cc: Robert Richter
> Cc: Andi Kleen
> Cc: Stephane Eranian
> ---
> .../util/scripting-engines/trace-event-python.c| 35 ---
> 1 files changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
> b/tools/perf/util/scripting-engines/trace-event-python.c
> index 24711b3..7e3f576 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> @@ -345,15 +345,23 @@ static void python_process_general_event(union
> perf_event *perf_event __unused,
>struct machine *machine __unused,
>struct addr_location *al __unused)
@al is used now.
> {
> - PyObject *handler, *retval, *t;
> + PyObject *handler, *retval, *t, *dict;
> static char handler_name[64];
> unsigned n = 0;
> - void *data = sample->raw_data;
> + struct thread *thread = al->thread;
>
> + /*
> + * Use the MAX_FIELDS to make the function expandable, though
> + * currently there is only one itme for the tuple.
s/itme/item/
Thanks,
Namhyung
> + */
> t = PyTuple_New(MAX_FIELDS);
> if (!t)
> Py_FatalError("couldn't create Python tuple");
>
> + dict = PyDict_New();
> + if (!dict)
> + Py_FatalError("couldn't create Python dictionary");
> +
> snprintf(handler_name, sizeof(handler_name), "%s", "process_event");
>
> handler = PyDict_GetItemString(main_dict, handler_name);
> @@ -362,11 +370,25 @@ static void python_process_general_event(union
> perf_event *perf_event __unused,
> goto exit;
> }
>
> - /* Pass 4 parameters: event_attr, perf_sample, raw data, thread name */
> - PyTuple_SetItem(t, n++, PyString_FromStringAndSize((void
> *)>attr, sizeof(evsel->attr)));
> - PyTuple_SetItem(t, n++, PyString_FromStringAndSize((void *)sample,
> sizeof(*sample)));
> - PyTuple_SetItem(t, n++, PyString_FromStringAndSize(data,
> sample->raw_size));
> + PyDict_SetItemString(dict, "ev_name",
> PyString_FromString(perf_evsel__name(evsel)));
> + PyDict_SetItemString(dict, "attr", PyString_FromStringAndSize(
> + (const char *)>attr, sizeof(evsel->attr)));
> + PyDict_SetItemString(dict, "sample", PyString_FromStringAndSize(
> + (const char *)sample, sizeof(*sample)));
> + PyDict_SetItemString(dict, "raw_buf", PyString_FromStringAndSize(
> + (const char *)sample->raw_data, sample->raw_size));
> + PyDict_SetItemString(dict, "comm",
> + PyString_FromString(thread->comm));
> + if (al->map) {
> + PyDict_SetItemString(dict, "dso",
> + PyString_FromString(al->map->dso->name));
> + }
> + if (al->sym) {
> + PyDict_SetItemString(dict, "symbol",
> + PyString_FromString(al->sym->name));
> + }
>
> + PyTuple_SetItem(t, n++, dict);
> if (_PyTuple_Resize(, n) == -1)
> Py_FatalError("error resizing Python tuple");
>
> @@ -374,6 +396,7 @@ static void python_process_general_event(union perf_event
> *perf_event __unused,
> if (retval == NULL)
> handler_call_die(handler_name);
> exit:
> + Py_DECREF(dict);
> Py_DECREF(t);
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/5] perf script: Add general python handler to process non-tracepoint events
Hi, Feng
On Wed, 8 Aug 2012 17:57:51 +0800, Feng Tang wrote:
> This patch just follows Robert Richter's idea and the commit 37a058ea0
> "perf script: Add generic perl handler to process events"
> to similarly add a python handler for general events other than tracepoints.
>
> For non-tracepoint events, this patch will try to find a function named
> "process_event" in the python script, and pass the event attribute,
> perf_sample, raw_data in format of raw string. And the python script can
> use "struct" module's unpack function to disasemble the needed info and
> process.
>
> Signed-off-by: Feng Tang
> Cc: Andi Kleen
> Cc: David Ahern
> Cc: Peter Zijlstra
> Cc: Robert Richter
> Cc: Stephane Eranian
> http://lkml.kernel.org/r/133839-14007-2-git-send-email-feng.t...@intel.com
> [ committer note: Fixed up wrt da37896, i.e. pevent parm in script event
> handlers ]
> Signed-off-by: Arnaldo Carvalho de Melo
> ---
> .../util/scripting-engines/trace-event-python.c| 59
> +++-
> 1 files changed, 58 insertions(+), 1 deletions(-)
>
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c
> b/tools/perf/util/scripting-engines/trace-event-python.c
> index df7d33d..b9010d8 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> @@ -32,6 +32,7 @@
> #include "../event.h"
> #include "../thread.h"
> #include "../trace-event.h"
> +#include "../evsel.h"
>
> PyMODINIT_FUNC initperf_trace_context(void);
>
> @@ -220,7 +221,7 @@ static inline struct event_format
> *find_cache_event(struct perf_evsel *evsel)
> return event;
> }
>
> -static void python_process_event(union perf_event *perf_event __unused,
> +static void python_process_tracepoint(union perf_event *perf_event __unused,
>struct perf_sample *sample,
>struct perf_evsel *evsel,
>struct machine *machine __unused,
> @@ -337,6 +338,62 @@ static void python_process_event(union perf_event
> *perf_event __unused,
> Py_DECREF(t);
> }
>
> +static void python_process_general_event(union perf_event *perf_event
> __unused,
> + struct perf_sample *sample,
> + struct perf_evsel *evsel,
> + struct machine *machine __unused,
> + struct thread *thread __unused)
> +{
> + PyObject *handler, *retval, *t;
> + static char handler_name[64];
> + unsigned n = 0;
> + void *data = sample->raw_data;
> +
> + t = PyTuple_New(MAX_FIELDS);
> + if (!t)
> + Py_FatalError("couldn't create Python tuple");
> +
> + snprintf(handler_name, sizeof(handler_name), "%s", "process_event");
> +
> + handler = PyDict_GetItemString(main_dict, handler_name);
> + if (handler && !PyCallable_Check(handler)) {
Shouldn't it be like below?
if (!handler || !PyCallable_Check(handler))
goto exit;
Otherwise we can end up calling PyObject_CallObject with NULL handler
if PyDict_GetItemString() returns NULL. And the handler won't be used
anymore so no need to set it to NULL (again).
Thanks,
Namhyung
> + handler = NULL;
> + goto exit;
> + }
> +
> + /* Pass 3 parameters: event_attr, perf_sample, raw data */
> + PyTuple_SetItem(t, n++, PyString_FromStringAndSize((void
> *)>attr, sizeof(evsel->attr)));
> + PyTuple_SetItem(t, n++, PyString_FromStringAndSize((void *)sample,
> sizeof(*sample)));
> + PyTuple_SetItem(t, n++, PyString_FromStringAndSize(data,
> sample->raw_size));
> +
> + if (_PyTuple_Resize(, n) == -1)
> + Py_FatalError("error resizing Python tuple");
> +
> + retval = PyObject_CallObject(handler, t);
> + if (retval == NULL)
> + handler_call_die(handler_name);
> +exit:
> + Py_DECREF(t);
> +}
> +
> +static void python_process_event(union perf_event *perf_event,
> + struct perf_sample *sample,
> + struct perf_evsel *evsel,
> + struct machine *machine,
> + struct thread *thread)
> +{
> + switch (evsel->attr.type) {
> + case PERF_TYPE_TRACEPOINT:
> + python_process_tracepoint(perf_event, sample, evsel,
> + machine, thread);
> + break;
> + /* Reserve for future process_hw/sw/raw APIs */
> + default:
> + python_process_general_event(perf_event, sample, evsel,
> + machine, thread);
> + }
> +}
> +
> static int run_start_sub(void)
> {
> PyObject *handler, *retval;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[BUG] perf: sharing of cpuctx between core and ibs PMU causes problems
Hi, I ran into a problem on my AMD box whereby I would hit the WARN_ON_ONCE(cpuctx->cgrp) in perf_cgroup_switch(). It took me a while to track this down. It turns out that the list_for_each_entry_rcu() loop had multiple iterations. That's normal, we have CPU PMU and IBS PMU. But what caused the warning to fire is that both the core and IBS PMU were pointing to the same cpuctx struct. Thus, the cpuctx->cgrp was already set in the second iteration. Is the warning a false positive? In perf_pmu_register(), there is a search for a matching pmu->task_ctx_nr. Given that the field is pointing to perf_hw_context for both cpu and IBS PMU, there is a match and therefore the cpuctx are shared. The question is: why do we have to share the cpuctx? Note that the same issue probably exists with the Intel uncore PMU. If we need to share, then the perf_cgroup_switch() code needs to change because, as it stands, it is doing the switching twice in this case. Either way something looks wrong here. Any idea? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] proc: add /proc/pid/shmaps
Thanks for your reply. There are so many contents in /proc/pid/maps, and usually only a very small minority of those are about shared memory in address space of every process. So I hope that a new file maybe provide some convenience. Could you tell me how to get such information except analyzing 'maps' file? -Original Message- From: David Rientjes [mailto:rient...@google.com] Sent: Thursday, August 09, 2012 5:10 AM To: Ren, Qiaowei Cc: Andrew Morton; Al Viro; Oleg Nesterov; Cyrill Gorcunov; Vasiliy Kulikov; Hugh Dickins; Naoya Horiguchi; Konstantin Khlebnikov; linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] proc: add /proc/pid/shmaps On Wed, 8 Aug 2012, Qiaowei Ren wrote: > Add a shmaps entry to /proc/pid: show information about shared memory in an > address space. > > People that use shared memory and want to perform an analyzing about it. For > example, judge whether any memory address is shared. This file just contains > 'share' part of /proc/pid/maps now. There are too many contents in maps, and > so we have to do a lot of analysis to obtain relative information every time. > > Signed-off-by: Qiaowei Ren Nack as unnecessary; /proc/pid/maps already explicitly emits 's' for VM_MAYSHARE and 'p' otherwise so this information is already available to userspace. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] perf: Teach perf tool to profile sleep times (v2)
On Wed, 8 Aug 2012 11:24:34 +0400, Andrey Wagin wrote: > 2012/8/8 Namhyung Kim : >> On Wed, 8 Aug 2012 09:02:18 +0400, Andrey Wagin wrote: >>> 2012/8/8 Namhyung Kim : > > $ ./perf record -e sched:sched_stat_sleep -e sched:sched_switch \ > -e sched:sched_process_exit -gP -o ~/perf.data.raw ~/foo >>> >>> Actually this string is not completed, because sched:sched_switch >>> should be filtered by state. >>> > [ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.015 MB /root/perf.data.raw (~661 > samples) ] > $ ./perf inject -v -s -i ~/perf.data.raw -o ~/perf.data > $ ./perf report -i ~/perf.data The usage like this is too specific and hard to use IMHO. How about putting it somehow into perf sched or new command? /me don't have an idea though. :-) >>> >>> I'm going to add a script, so the usage will look like this: >>> $ perf script record sched-stat -e sched:sched_stat_sleep >>> This command will collect sched_stat_* and proper sched_switch events >> >> ??? That means '-e sched:sched_stat_sleep' part can be removed from >> command line, no? > > No. My method works for all kind of sched_stat_* events, so you need > to specify an event type which should be traced. Ok, so can it be like 'perf script record sched-stat -t sleep '? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thermal: Fix potential NULL pointer accesses
On 二, 2012-08-07 at 22:36 -0700, Guenter Roeck wrote: > The type parameter in thermal_zone_device_register and > thermal_cooling_device_register can be NULL, indicating that no sysfs > attribute > for the type should be created. Only call strlen() and strcpy() on type if it > is > not NULL. > > This patch addresses Coverity #102180 and #102182: Dereference before null > check > > Signed-off-by: Guenter Roeck Acked-by: Zhang Rui > --- > Applies on top of > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git (thermal). > > drivers/thermal/thermal_sys.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c > index 5be8728..e69f76d 100644 > --- a/drivers/thermal/thermal_sys.c > +++ b/drivers/thermal/thermal_sys.c > @@ -900,7 +900,7 @@ thermal_cooling_device_register(char *type, void *devdata, > struct thermal_zone_device *pos; > int result; > > - if (strlen(type) >= THERMAL_NAME_LENGTH) > + if (type && strlen(type) >= THERMAL_NAME_LENGTH) > return ERR_PTR(-EINVAL); > > if (!ops || !ops->get_max_state || !ops->get_cur_state || > @@ -917,7 +917,7 @@ thermal_cooling_device_register(char *type, void *devdata, > return ERR_PTR(result); > } > > - strcpy(cdev->type, type); > + strcpy(cdev->type, type ? : ""); > mutex_init(>lock); > INIT_LIST_HEAD(>thermal_instances); > cdev->ops = ops; > @@ -1343,7 +1343,7 @@ struct thermal_zone_device > *thermal_zone_device_register(const char *type, > int count; > int passive = 0; > > - if (strlen(type) >= THERMAL_NAME_LENGTH) > + if (type && strlen(type) >= THERMAL_NAME_LENGTH) > return ERR_PTR(-EINVAL); > > if (trips > THERMAL_MAX_TRIPS || trips < 0 || mask >> trips) > @@ -1365,7 +1365,7 @@ struct thermal_zone_device > *thermal_zone_device_register(const char *type, > return ERR_PTR(result); > } > > - strcpy(tz->type, type); > + strcpy(tz->type, type ? : ""); > tz->ops = ops; > tz->device.class = _class; > tz->devdata = devdata; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH v2 2/2] dm: verity support data device offset (Linux 3.4.7)
On Aug 8, 2012, at 1:56 PM, Milan Broz wrote:
> On 08/08/2012 10:46 PM, Wesley Miaw wrote:
>
>> I did modify veritysetup on my own so the format and verify commands will
>> work with regular files on disk instead of having to mount through loop
>> devices.
>
> Which veritysetup? In upstream (cryptsetup repository) it allocates loop
> automatically.
> (And for userspace verification it doesn't need loop at all.)
>
> Anyway, please send a patch for userspace as well then ;-)
This isn't as polished because I pretty much just added support to do what I
needed. I'm not sure if the LKML is the right place to post, so let me know if
I should send this somewhere else.
Your previous email implied that veritysetup would need a way to determine if
the data offset option is supported; I did not modify veritysetup to support
this idea as I didn't need it.
Thanks.
From: Wesley Miaw
Allow veritysetup format and verify commands to directly operate on regular
files instead of requiring mounts through loop devices.
Signed-off-by: Wesley Miaw
---
cryptsetup/lib/internal.h|1
cryptsetup/lib/libcryptsetup.h | 22
cryptsetup/lib/libcryptsetup.sym |2
cryptsetup/lib/setup.c | 133 -
cryptsetup/lib/utils.c | 12 ++
cryptsetup/src/veritysetup.c | 23 +++--
6 files changed, 183 insertions(+), 10 deletions(-)
--- a/cryptsetup/lib/internal.h 2012-08-08 17:11:20.366392301 -0700
+++ b/cryptsetup/lib/internal.h 2012-08-06 16:17:35.154719491 -0700
@@ -76,6 +76,7 @@ ssize_t read_blockwise(int fd, void *_bu
ssize_t write_lseek_blockwise(int fd, char *buf, size_t count, off_t offset);
int device_ready(struct crypt_device *cd, const char *device, int mode);
int device_size(const char *device, uint64_t *size);
+int file_size(const char *filename, uint64_t *size);
unsigned crypt_getpagesize(void);
--- a/cryptsetup/lib/libcryptsetup.h2012-08-08 17:11:20.375392929 -0700
+++ b/cryptsetup/lib/libcryptsetup.h2012-08-06 16:17:35.159720699 -0700
@@ -56,6 +57,19 @@ struct crypt_device; /* crypt device han
int crypt_init(struct crypt_device **cd, const char *device);
/**
+ * Initial crypt device handle from a file and check if provided file exists.
+ *
+ * @param cd Returns pointer to crypt device handle.
+ * @param filename Path to the backing file.
+ *
+ * @return @e 0 on success or negative errno value otherwise.
+ *
+ * @note Note that logging is not initialized here, possible messages uses
+ * default log function.
+ */
+int crypt_initfile(struct crypt_device **cd, const char *filename);
+
+/**
* Initialize crypt device handle from provided active device name,
* and, optionally, from separate metadata (header) device
* and check if provided device exists.
@@ -237,6 +251,15 @@ void crypt_set_password_verify(struct cr
int crypt_set_data_device(struct crypt_device *cd, const char *device);
/**
+ * Set data file
+ * For VERITY it is data file when hash device is separated.
+ *
+ * @param cd crypt device handle
+ * @param filename path to data file
+ */
+int crypt_set_data_file(struct crypt_device *cd, const char *device);
+
+/**
* @defgroup rng "Cryptsetup RNG"
*
* @addtogroup rng
--- a/cryptsetup/lib/libcryptsetup.sym 2012-08-08 17:11:20.375392930 -0700
+++ b/cryptsetup/lib/libcryptsetup.sym 2012-08-06 16:17:35.160720941 -0700
@@ -1,6 +1,7 @@
CRYPTSETUP_1.0 {
global:
crypt_init;
+ crypt_initfile;
crypt_init_by_name;
crypt_init_by_name_and_header;
crypt_set_log_callback;
@@ -13,6 +14,7 @@ CRYPTSETUP_1.0 {
crypt_set_password_verify;
crypt_set_uuid;
crypt_set_data_device;
+ crypt_set_data_file;
crypt_memory_lock;
crypt_format;
--- a/cryptsetup/lib/setup.c2012-08-08 17:11:20.428396640 -0700
+++ b/cryptsetup/lib/setup.c2012-08-06 16:17:35.192728669 -0700
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
#include "libcryptsetup.h"
#include "luks.h"
@@ -585,6 +587,56 @@ bad:
return r;
}
+int crypt_initfile(struct crypt_device **cd, const char *filename)
+{
+ struct crypt_device *h = NULL;
+ int fd;
+ struct stat st;
+ int r;
+
+ if (!cd)
+ return -EINVAL;
+
+ if (stat(filename, ) < 0) {
+ log_err(NULL, _("File %s doesn't exist or access denied.\n"),
filename);
+ return -EINVAL;
+ }
+
+ log_dbg("Trying to open and write file %s.", filename);
+ fd = open(filename, O_RDWR);
+ if (fd < 0) {
+ log_err(NULL, _("Cannot open file %s for writeable access.\n"),
filename);
+ return -EINVAL;
+ }
+ close(fd);
+
+ log_dbg("Allocating crypt device %s context.", filename);
+
+ if (!(h = malloc(sizeof(struct crypt_device
+ return
Re: [dm-devel] [PATCH v2 1/2] dm: verity support data device offset (Linux 3.4.7)
On Aug 8, 2012, at 1:31 PM, Milan Broz wrote:
> On 08/08/2012 08:46 PM, Mikulas Patocka wrote:
>
>> The problem with the patch is that it changes interface to the userspace
>> tool. The userspace tool veritysetup already exists in recent cryptsetup
>> package, so we can't change the interface - you should change the patch so
>> that the starting data block is the last argument and the argument is
>> optional - so that it is compatible with the existing userspace too.
>
> yes. Please never change interface without at least increasing target version.
>
> I have to add userspace support as well to veritysetup and we need a way
> how to detect that option is supported by running kernel.
Apologies if the version increment is incorrect; I was not sure if the minor or
patch number should be incremented. I assume the different version number is
what would be used to detect if the data offset option is supported. Thanks.
From: Wesley Miaw
Add data device start block index as optional dm-verity target parameters to
support verity targets where the data does not begin at sector 0 of the block
device.
Also fix the hash block index computations so they take into account any data
offset.
Signed-off-by: Wesley Miaw
---
Documentation/device-mapper/verity.txt |8 ++-
drivers/md/dm-verity.c | 24 ++-
2 files changed, 26 insertions(+), 6 deletions(-)
--- a/drivers/md/dm-verity.c2012-08-07 16:03:03.778759000 -0700
+++ b/drivers/md/dm-verity.c2012-08-08 17:04:16.344682266 -0700
@@ -477,7 +477,7 @@ static int verity_map(struct dm_target *
return -EIO;
}
- if ((bio->bi_sector + bio_sectors(bio)) >>
+ if ((bio->bi_sector - v->data_start + bio_sectors(bio)) >>
(v->data_dev_block_bits - SECTOR_SHIFT) > v->data_blocks) {
DMERR_LIMIT("io out of range");
return -EIO;
@@ -491,7 +491,7 @@ static int verity_map(struct dm_target *
io->bio = bio;
io->orig_bi_end_io = bio->bi_end_io;
io->orig_bi_private = bio->bi_private;
- io->block = bio->bi_sector >> (v->data_dev_block_bits - SECTOR_SHIFT);
+ io->block = (bio->bi_sector - v->data_start) >> (v->data_dev_block_bits
- SECTOR_SHIFT);
io->n_blocks = bio->bi_size >> v->data_dev_block_bits;
bio->bi_end_io = verity_end_io;
@@ -646,6 +646,7 @@ static void verity_dtr(struct dm_target
*
*
* Hex string or "-" if no salt.
+ * Optional. The default is zero.
*/
static int verity_ctr(struct dm_target *ti, unsigned argc, char **argv)
{
@@ -671,8 +672,8 @@ static int verity_ctr(struct dm_target *
goto bad;
}
- if (argc != 10) {
- ti->error = "Invalid argument count: exactly 10 arguments
required";
+ if (argc != 10 && argc != 11) {
+ ti->error = "Invalid argument count: 10 or 11 arguments
required";
r = -EINVAL;
goto bad;
}
@@ -793,6 +794,19 @@ static int verity_ctr(struct dm_target *
}
}
+ if (argc == 11) {
+ if (sscanf(argv[10], "%llu%c", _ll, ) != 1 ||
+ num_ll << (v->data_dev_block_bits - SECTOR_SHIFT) !=
+ (sector_t)num_ll << (v->data_dev_block_bits -
SECTOR_SHIFT)) {
+ ti->error = "Invalid data start";
+ r = -EINVAL;
+ goto bad;
+ }
+ v->data_start = num_ll << (v->data_dev_block_bits -
SECTOR_SHIFT);
+ } else {
+ v->data_start = 0;
+ }
+
v->hash_per_block_bits =
fls((1 << v->hash_dev_block_bits) / v->digest_size) - 1;
@@ -875,7 +889,7 @@ bad:
static struct target_type verity_target = {
.name = "verity",
- .version= {1, 0, 0},
+ .version= {1, 1, 0},
.module = THIS_MODULE,
.ctr= verity_ctr,
.dtr= verity_dtr,
--- a/Documentation/device-mapper/verity.txt2012-08-08 11:02:48.558883756
-0700
+++ b/Documentation/device-mapper/verity.txt2012-08-08 16:50:04.114864090
-0700
@@ -11,6 +11,7 @@ Construction Parameters
+[]
This is the type of the on-disk hash format.
@@ -62,6 +63,10 @@ Construction Parameters
The hexadecimal encoding of the salt value.
+
+This is the offset, in -blocks, from the start of data_dev
+to the first block of the data.
+
Theory of operation
===
@@ -138,7 +143,8 @@ Set up a device:
# dmsetup create vroot --readonly --table \
"0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 "\
"4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\
-"1234"
+
Re: [PATCH] perf: Add a new sort order: SORT_INCLUSIVE (v6)
Hi, Arun
On Wed, 8 Aug 2012 12:16:30 -0700, Arun Sharma wrote:
> On 3/30/12 10:43 PM, Arun Sharma wrote:
>> [ Meant to include v6 ChangeLog as well. Technical difficulties.. ]
>>
>> v6 ChangeLog:
>>
>> rebased to tip:perf/core and fixed a minor problem in computing
>> the total period in hists__remove_entry_filter(). Needed to
>> use period_self instead of period.
>
> This patch breaks perf top (symptom: percentages > 100%). Fixed by the
> following patch.
>
> Namhyung: if you're still working on forward porting this, please add
> this fix to your queue.
>
Will do, thanks.
Namhyung
> -Arun
>
> commit 75a1c409a529c9741f8a2f493868d1fc7ce7e06d
> Author: Arun Sharma
> Date: Wed Aug 8 11:47:02 2012 -0700
>
>perf: update period_self as well on collapsing
> When running perf top, we have a series of incoming samples,
>which get aggregated in various user specified ways.
> Suppose function "foo" had the following samples:
>101, 103, 99, 105, ...
> ->period for the corresponding entry looks as follows:
>101, 204, 303, 408, ...
> However, due to this bug, ->period_self contains:
>101, 103, 99, 105, ...
> and therefore breaks the invariant period == period_self
>in the default mode (no sort inclusive).
> Since total_period is computed by summing up period_self,
> period/total_period can be > 100%
> Fix the bug by updating period_self as well.
> Signed-off-by: Arun Sharma
>
> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> index a2a8d91..adc891e 100644
> --- a/tools/perf/util/hist.c
> +++ b/tools/perf/util/hist.c
> @@ -462,6 +462,7 @@ static bool hists__collapse_insert_entry(struct
> hists *hists,
>
> if (!cmp) {
> iter->period += he->period;
> + iter->period_self += he->period_self;
> iter->nr_events += he->nr_events;
> if (symbol_conf.use_callchain) {
>
> callchain_cursor_reset(>callchain_cursor);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 01/12] block: Generalized bio pool freeing
On Wed, Aug 08, 2012 at 03:25:15PM -0700, Tejun Heo wrote:
> On Mon, Aug 06, 2012 at 03:08:30PM -0700, Kent Overstreet wrote:
> > @@ -422,7 +409,11 @@ void bio_put(struct bio *bio)
> > if (atomic_dec_and_test(>bi_cnt)) {
> > bio_disassociate_task(bio);
> > bio->bi_next = NULL;
> > - bio->bi_destructor(bio);
> > +
> > + if (bio->bi_pool)
> > + bio_free(bio, bio->bi_pool);
> > + else
> > + bio->bi_destructor(bio);
>
> So, this bi_pool overriding caller specified custom bi_destructor is
> rather unusual. I know why it's like that - the patch series is
> gradually replacing bi_destructor with bi_pool and removes
> bi_destructor eventually, but it would be far better if at least patch
> description says why this is unusual like this.
Ok, I'll stick a comment in there:
if (atomic_dec_and_test(>bi_cnt)) {
bio_disassociate_task(bio);
bio->bi_next = NULL;
/*
* This if statement is temporary - bi_pool is replacing
* bi_destructor, but bi_destructor will be taken out in another
* patch.
*/
if (bio->bi_pool)
bio_free(bio, bio->bi_pool);
else
bio->bi_destructor(bio);
}
>
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 05/12] block: Kill bi_destructor
On Wed, Aug 08, 2012 at 03:22:23PM -0700, Tejun Heo wrote:
> Hello,
>
> On Mon, Aug 06, 2012 at 03:08:34PM -0700, Kent Overstreet wrote:
> > Now that we've got generic code for freeing bios allocated from bio
> > pools, this isn't needed anymore.
> >
> > This also changes the semantics of bio_free() a bit - it now also frees
> > bios allocated by bio_kmalloc(). It's also no longer exported, as
> > without bi_destructor there should be no need for it to be called
> > anywhere else.
> >
> > v5: Switch to BIO_KMALLOC_POOL ((void *)~0), per Boaz
> >
> > Signed-off-by: Kent Overstreet
> > ---
> > diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
> > index 920ede2..19bf632 100644
> > --- a/drivers/block/drbd/drbd_main.c
> > +++ b/drivers/block/drbd/drbd_main.c
> > @@ -161,23 +161,12 @@ static const struct block_device_operations drbd_ops
> > = {
> > .release = drbd_release,
> > };
> >
> > -static void bio_destructor_drbd(struct bio *bio)
> > -{
> > - bio_free(bio, drbd_md_io_bio_set);
> > -}
> > -
> > struct bio *bio_alloc_drbd(gfp_t gfp_mask)
> > {
> > - struct bio *bio;
> > -
> > if (!drbd_md_io_bio_set)
> > return bio_alloc(gfp_mask, 1);
> >
> > - bio = bio_alloc_bioset(gfp_mask, 1, drbd_md_io_bio_set);
> > - if (!bio)
> > - return NULL;
> > - bio->bi_destructor = bio_destructor_drbd;
> > - return bio;
> > + return bio_alloc_bioset(gfp_mask, 1, drbd_md_io_bio_set);
> > }
>
> Does this chunk belong to this patch?
Hrm, that should've been in the first patch. Will move it.
>
> > @@ -56,6 +56,8 @@ static struct biovec_slab bvec_slabs[BIOVEC_NR_POOLS]
> > __read_mostly = {
> > */
> > struct bio_set *fs_bio_set;
> >
> > +#define BIO_KMALLOC_POOL ((void *) ~0)
>
> What's wrong with good ol' NULL?
If it's NULL, we can't distinguish between bios where that field wasn't
set (i.e. bios that were statically allocated somewhere) from bios that
were allocated by bio_kmalloc().
It's just there to make debugging easier - if bi_cnt goes to 0 on a bio
where it shouldn't we'll catch it at the BUG_ON() in bio_free() instead
of kfreeing a bad pointer.
>
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 05/12] block: Kill bi_destructor
On Mon, Aug 06, 2012 at 11:19:21PM -0400, Mike Snitzer wrote: > On Mon, Aug 06 2012 at 6:08pm -0400, > Kent Overstreet wrote: > > > Now that we've got generic code for freeing bios allocated from bio > > pools, this isn't needed anymore. > > > > This also changes the semantics of bio_free() a bit - it now also frees > > bios allocated by bio_kmalloc(). It's also no longer exported, as > > without bi_destructor there should be no need for it to be called > > anywhere else. > > Seems you forgot to remove bio_free's EXPORT_SYMBOL Whoops - thanks, fixed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] mm: have order > 0 compaction start near a pageblock with free pages
Hi Mel,
On Wed, Aug 08, 2012 at 08:08:44PM +0100, Mel Gorman wrote:
> commit [7db8889a: mm: have order > 0 compaction start off where it left]
> introduced a caching mechanism to reduce the amount work the free page
> scanner does in compaction. However, it has a problem. Consider two process
> simultaneously scanning free pages
>
> C
> Process A M S F
> |---|
> Process B M FS
>
> C is zone->compact_cached_free_pfn
> S is cc->start_pfree_pfn
> M is cc->migrate_pfn
> F is cc->free_pfn
>
> In this diagram, Process A has just reached its migrate scanner, wrapped
> around and updated compact_cached_free_pfn accordingly.
>
> Simultaneously, Process B finishes isolating in a block and updates
> compact_cached_free_pfn again to the location of its free scanner.
>
> Process A moves to "end_of_zone - one_pageblock" and runs this check
>
> if (cc->order > 0 && (!cc->wrapped ||
> zone->compact_cached_free_pfn >
> cc->start_free_pfn))
> pfn = min(pfn, zone->compact_cached_free_pfn);
>
> compact_cached_free_pfn is above where it started so the free scanner skips
> almost the entire space it should have scanned. When there are multiple
> processes compacting it can end in a situation where the entire zone is
> not being scanned at all. Further, it is possible for two processes to
> ping-pong update to compact_cached_free_pfn which is just random.
>
> Overall, the end result wrecks allocation success rates.
>
> There is not an obvious way around this problem without introducing new
> locking and state so this patch takes a different approach.
>
> First, it gets rid of the skip logic because it's not clear that it matters
> if two free scanners happen to be in the same block but with racing updates
> it's too easy for it to skip over blocks it should not.
>
> Second, it updates compact_cached_free_pfn in a more limited set of
> circumstances.
>
> If a scanner has wrapped, it updates compact_cached_free_pfn to the end
> of the zone. When a wrapped scanner isolates a page, it updates
> compact_cached_free_pfn to point to the highest pageblock it
> can isolate pages from.
Okay until here.
>
> If a scanner has not wrapped when it has finished isolated pages it
> checks if compact_cached_free_pfn is pointing to the end of the
> zone. If so, the value is updated to point to the highest
> pageblock that pages were isolated from. This value will not
> be updated again until a free page scanner wraps and resets
> compact_cached_free_pfn.
I tried to understand your intention of this part but unfortunately failed.
By this part, the problem you mentioned could happen again?
C
Process A M S F
|---|
Process B M FS
C is zone->compact_cached_free_pfn
S is cc->start_pfree_pfn
M is cc->migrate_pfn
F is cc->free_pfn
In this diagram, Process A has just reached its migrate scanner, wrapped
around and updated compact_cached_free_pfn to end of the zone accordingly.
Simultaneously, Process B finishes isolating in a block and peek
compact_cached_free_pfn position and know it's end of the zone so
update compact_cached_free_pfn to highest pageblock that pages were
isolated from.
Process A updates compact_cached_free_pfn to the highest pageblock which
was set by process B because process A has wrapped. It ends up big jump
without any scanning in process A.
No?
>
> This is not optimal and it can still race but the compact_cached_free_pfn
> will be pointing to or very near a pageblock with free pages.
>
> Signed-off-by: Mel Gorman
> Reviewed-by: Rik van Riel
> ---
> mm/compaction.c | 54 --
> 1 file changed, 28 insertions(+), 26 deletions(-)
>
> diff --git a/mm/compaction.c b/mm/compaction.c
> index be310f1..df50f73 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -419,6 +419,20 @@ static bool suitable_migration_target(struct page *page)
> }
>
> /*
> + * Returns the start pfn of the last page block in a zone. This is the
> starting
> + * point for full compaction of a zone. Compaction searches for free pages
> from
> + * the end of each zone, while isolate_freepages_block scans forward inside
> each
> + * page block.
> + */
> +static unsigned long start_free_pfn(struct zone *zone)
> +{
> + unsigned long free_pfn;
> + free_pfn = zone->zone_start_pfn + zone->spanned_pages;
> + free_pfn &= ~(pageblock_nr_pages-1);
> + return free_pfn;
> +}
> +
> +/*
> * Based on information in the current compact_control, find blocks
> * suitable for
Re: [PATCH v5 04/12] pktcdvd: Switch to bio_kmalloc()
On Wed, Aug 08, 2012 at 03:13:59PM -0700, Tejun Heo wrote:
> Hello,
>
> On Mon, Aug 06, 2012 at 03:08:33PM -0700, Kent Overstreet wrote:
> > This is prep work for killing bi_destructor - previously, pktcdvd had
> > its own pkt_bio_alloc which was basically duplication bio_kmalloc(),
> > necessitating its own bi_destructor implementation.
> >
> > v5: Un-reorder some functions, to make the patch easier to review
> >
> > Signed-off-by: Kent Overstreet
>
> Please Cc: the maintainers. Cc'ing Peter Osterlund and keeping the
> whole body for him.
Whoops, thanks.
> Generally looks good to me. How is this tested?
Untested - no hardware for it.
>
> Thanks.
>
> > ---
> > drivers/block/pktcdvd.c | 67
> > +++---
> > 1 files changed, 16 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> > index ba66e44..ae55f08 100644
> > --- a/drivers/block/pktcdvd.c
> > +++ b/drivers/block/pktcdvd.c
> > @@ -101,6 +101,8 @@ static struct dentry*pkt_debugfs_root = NULL; /*
> > /sys/kernel/debug/pktcdvd */
> > static int pkt_setup_dev(dev_t dev, dev_t* pkt_dev);
> > static int pkt_remove_dev(dev_t pkt_dev);
> > static int pkt_seq_show(struct seq_file *m, void *p);
> > +static void pkt_end_io_read(struct bio *bio, int err);
> > +static void pkt_end_io_packet_write(struct bio *bio, int err);
> >
> >
> >
> > @@ -522,38 +524,6 @@ static void pkt_bio_finished(struct pktcdvd_device *pd)
> > }
> > }
> >
> > -static void pkt_bio_destructor(struct bio *bio)
> > -{
> > - kfree(bio->bi_io_vec);
> > - kfree(bio);
> > -}
> > -
> > -static struct bio *pkt_bio_alloc(int nr_iovecs)
> > -{
> > - struct bio_vec *bvl = NULL;
> > - struct bio *bio;
> > -
> > - bio = kmalloc(sizeof(struct bio), GFP_KERNEL);
> > - if (!bio)
> > - goto no_bio;
> > - bio_init(bio);
> > -
> > - bvl = kcalloc(nr_iovecs, sizeof(struct bio_vec), GFP_KERNEL);
> > - if (!bvl)
> > - goto no_bvl;
> > -
> > - bio->bi_max_vecs = nr_iovecs;
> > - bio->bi_io_vec = bvl;
> > - bio->bi_destructor = pkt_bio_destructor;
> > -
> > - return bio;
> > -
> > - no_bvl:
> > - kfree(bio);
> > - no_bio:
> > - return NULL;
> > -}
> > -
> > /*
> > * Allocate a packet_data struct
> > */
> > @@ -567,10 +537,13 @@ static struct packet_data *pkt_alloc_packet_data(int
> > frames)
> > goto no_pkt;
> >
> > pkt->frames = frames;
> > - pkt->w_bio = pkt_bio_alloc(frames);
> > + pkt->w_bio = bio_kmalloc(GFP_KERNEL, frames);
> > if (!pkt->w_bio)
> > goto no_bio;
> >
> > + pkt->w_bio->bi_end_io = pkt_end_io_packet_write;
> > + pkt->w_bio->bi_private = pkt;
> > +
> > for (i = 0; i < frames / FRAMES_PER_PAGE; i++) {
> > pkt->pages[i] = alloc_page(GFP_KERNEL|__GFP_ZERO);
> > if (!pkt->pages[i])
> > @@ -581,9 +554,12 @@ static struct packet_data *pkt_alloc_packet_data(int
> > frames)
> > bio_list_init(>orig_bios);
> >
> > for (i = 0; i < frames; i++) {
> > - struct bio *bio = pkt_bio_alloc(1);
> > + struct bio *bio = bio_kmalloc(GFP_KERNEL, 1);
> > if (!bio)
> > goto no_rd_bio;
> > +
> > + bio->bi_end_io = pkt_end_io_read;
> > + bio->bi_private = pkt;
> > pkt->r_bios[i] = bio;
> > }
> >
> > @@ -,21 +1087,15 @@ static void pkt_gather_data(struct pktcdvd_device
> > *pd, struct packet_data *pkt)
> > * Schedule reads for missing parts of the packet.
> > */
> > for (f = 0; f < pkt->frames; f++) {
> > - struct bio_vec *vec;
> > -
> > int p, offset;
> > +
> > if (written[f])
> > continue;
> > +
> > bio = pkt->r_bios[f];
> > - vec = bio->bi_io_vec;
> > - bio_init(bio);
> > - bio->bi_max_vecs = 1;
> > - bio->bi_sector = pkt->sector + f * (CD_FRAMESIZE >> 9);
> > - bio->bi_bdev = pd->bdev;
> > - bio->bi_end_io = pkt_end_io_read;
> > - bio->bi_private = pkt;
> > - bio->bi_io_vec = vec;
> > - bio->bi_destructor = pkt_bio_destructor;
> > + bio_reset(bio);
> > + bio->bi_sector = pkt->sector + f * (CD_FRAMESIZE >> 9);
> > + bio->bi_bdev= pd->bdev;
> >
> > p = (f * CD_FRAMESIZE) / PAGE_SIZE;
> > offset = (f * CD_FRAMESIZE) % PAGE_SIZE;
> > @@ -1418,14 +1388,9 @@ static void pkt_start_write(struct pktcdvd_device
> > *pd, struct packet_data *pkt)
> > }
> >
> > /* Start the write request */
> > - bio_init(pkt->w_bio);
> > - pkt->w_bio->bi_max_vecs = PACKET_MAX_SIZE;
> > + bio_reset(pkt->w_bio);
> > pkt->w_bio->bi_sector = pkt->sector;
> > pkt->w_bio->bi_bdev = pd->bdev;
> > - pkt->w_bio->bi_end_io = pkt_end_io_packet_write;
> > - pkt->w_bio->bi_private = pkt;
> > - pkt->w_bio->bi_io_vec = bvec;
> > -
Re: [PATCH v5 03/12] block: Add bio_reset()
On Wed, Aug 08, 2012 at 03:11:29PM -0700, Tejun Heo wrote:
> Hello,
>
> On Mon, Aug 06, 2012 at 03:08:32PM -0700, Kent Overstreet wrote:
> > Reusing bios is something that's been highly frowned upon in the past,
> > but driver code keeps doing it anyways. If it's going to happen anyways,
> > we should provide a generic method.
> >
> > This'll help with getting rid of bi_destructor - drivers/block/pktcdvd.c
> > was open coding it, by doing a bio_init() and resetting bi_destructor.
> >
> > v5: Add a define BIO_RESET_BITS, to be very explicit about what parts of
> > bio->bi_flags are saved.
> >
> > Signed-off-by: Kent Overstreet
> > Change-Id: I4eb2975bd678d3be811d5423d0620b08020be9ff
>
> Please drop Change-Id. Die gerrit die.
Bah, missed that one.
> > +void bio_reset(struct bio *bio)
> > +{
> > + unsigned long flags = bio->bi_flags & (~0UL << BIO_RESET_BITS);
>
> How many flags are we talking about? If there aren't too many, I'd
> prefer explicit BIO_FLAGS_PRESERVED or whatever.
It mostly isn't actual flags that are preserved - the high bits of the
flags are used for indicating what slab the bvec was allocated from, and
that's the main thing that has to be preserved.
So that's why I went with defining the things that are reset instead of
the things that are preserved.
I would prefer if bitfields were used for at least BIO_POOL_IDX, but the
problem is flags is used as an atomic bit vector for BIO_UPTODATE.
But flags isn't treated as an atomic bit vector elsewhere -
bio_flagged() doesn't use test_bit(), and flags are set/cleared with
atomic bit operations in some places but not in others (probably _most_
of them are technically safe, but... ick).
>
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the osd tree with the nfs tree
Hi Boaz,
Today's linux-next merge of the osd tree got a conflict in
fs/nfs/nfs4proc.c between commit 47fbf7976e0b ("NFSv4.1: Remove a bogus
BUG_ON() in nfs4_layoutreturn_done") from the nfs tree and commit
d8e8b68405db ("pnfs: Don't BUG on info received from Server") from the
osd tree.
I just used the nfs tree version.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpIuxsNsmgsj.pgp
Description: PGP signature
Re: [PATCH] x86/pci: Allow x86 platforms to use translation offsets
On Wed, Aug 8, 2012 at 4:42 PM, wrote:
> From: Charlie Mear
>
> The memory range descriptors in the _CRS control method contain an
> address translation offset for host bridges. This value is used to
> translate addresses across the bridge. The support to use _TRA values
> is present for other architectures but not for X86 platforms.
>
> For existing X86 platforms the _TRA value is zero. Non zero _TRA values
> are expected on future X86 platforms and this change will register that
> value with the resource.
>
> Signed-off-by: Charlie Mear
> ---
> arch/x86/pci/acpi.c | 18 --
> 1 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 505acdd..37acbae 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -12,6 +12,7 @@ struct pci_root_info {
> char name[16];
> unsigned int res_num;
> struct resource *res;
> + u64 *res_offset;
resource_size_t * ?
> struct pci_sysdata sd;
> #ifdef CONFIG_PCI_MMCONFIG
> bool mcfg_added;
> @@ -306,6 +307,7 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> res->start = start;
> res->end = end;
> res->child = NULL;
> + info->res_offset[info->res_num] = addr.translation_offset;
>
> if (!pci_use_crs) {
> dev_printk(KERN_DEBUG, >bridge->dev,
> @@ -375,7 +377,8 @@ static void add_resources(struct pci_root_info *info,
> "ignoring host bridge window %pR (conflicts
> with %s %pR)\n",
> res, conflict->name, conflict);
> else
> - pci_add_resource(resources, res);
> + pci_add_resource_offset(resources, res,
> + info->res_offset[i]);
> }
> }
>
> @@ -383,6 +386,8 @@ static void free_pci_root_info_res(struct pci_root_info
> *info)
> {
> kfree(info->res);
> info->res = NULL;
> + kfree(info->res_offset);
> + info->res_offset = NULL;
> info->res_num = 0;
> }
>
> @@ -433,11 +438,20 @@ probe_pci_root_info(struct pci_root_info *info, struct
> acpi_device *device,
> return;
>
> size = sizeof(*info->res) * info->res_num;
> - info->res_num = 0;
> info->res = kmalloc(size, GFP_KERNEL);
> if (!info->res)
you need to info->res_num = 0 here
> return;
>
> + size = sizeof(*info->res_offset) * info->res_num;
> + info->res_offset = kmalloc(size, GFP_KERNEL);
> + if (!info->res_offset) {
> + kfree(info->res);
> + info->res = NULL;
> + return;
> + }
> + info->res_num = 0;
need to move it before: if (!info->res_offset) {
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NULL pointer dereference in selinux_ip_postroute_compat
On 8/8/2012 2:54 PM, Eric Dumazet wrote:
By the way, once this proved to be an issue that involved
more than just SELinux it needed to go onto the LSM list as
well.
> On Wed, 2012-08-08 at 16:46 -0400, Paul Moore wrote:
>> On Wednesday, August 08, 2012 10:32:52 PM Eric Dumazet wrote:
>>> On Wed, 2012-08-08 at 22:09 +0200, Eric Dumazet wrote:
On Wed, 2012-08-08 at 15:59 -0400, Eric Paris wrote:
> Seems wrong. We shouldn't ever need ifdef CONFIG_SECURITY in core
> code.
Sure but it seems include file misses an accessor for this.
We could add it on a future cleanup patch, as Paul mentioned.
>>> I cooked following patch.
>>> But smack/smack_lsm.c makes a reference to
>>> smk_of_current()... so it seems we are in a hole...
>>>
>>> It makes little sense to me to have any kind of security on this
>>> internal sockets.
>>>
>>> Maybe selinux should not crash if sk->sk_security is NULL ?
>> I realize our last emails probably passed each other mid-flight, but
>> hopefully
>> it explains why we can't just pass packets when sk->sk_security is NULL.
>>
>> Regardless, some quick comments below ...
>>
>>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>>> index 6c77f63..459eca6 100644
>>> --- a/security/selinux/hooks.c
>>> +++ b/security/selinux/hooks.c
>>> @@ -4289,10 +4289,13 @@ out:
>>> return 0;
>>> }
>>>
>>> -static int selinux_sk_alloc_security(struct sock *sk, int family, ...
>>> +static int selinux_sk_alloc_security(struct sock *sk, int family, ...
>>> {
>>> struct sk_security_struct *sksec;
>>>
>>> + if (check && sk->sk_security)
>>> + return 0;
>>> +
>>> sksec = kzalloc(sizeof(*sksec), priority);
>>> if (!sksec)
>>> return -ENOMEM;
>> I think I might replace the "check" boolean with a "kern/kernel" boolean so
>> that in addition to the allocation we can also initialize the socket to
>> SECINITSID_KERNEL/kernel_t here in the case when the boolean is set. The
>> only
>> place that would set the boolean to true would be ip_send_unicast_reply(),
>> all
>> other callers would set it to false.
>>
>>> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
>>> index 8221514..8965cf1 100644
>>> --- a/security/smack/smack_lsm.c
>>> +++ b/security/smack/smack_lsm.c
>>> @@ -1754,11 +1754,14 @@ static void smack_task_to_inode(struct task_struct
>>> *p, struct inode *inode) *
>>> * Returns 0 on success, -ENOMEM is there's no memory
>>> */
>>> -static int smack_sk_alloc_security(struct sock *sk, int family, gfp_t
>>> gfp_flags) +static int smack_sk_alloc_security(struct sock *sk, int family,
>>> gfp_t gfp_flags, bool check) {
>>> char *csp = smk_of_current();
>>> struct socket_smack *ssp;
>>>
>>> + if (check && sk->sk_security)
>>> + return 0;
>>> +
>>> ssp = kzalloc(sizeof(struct socket_smack), gfp_flags);
>>> if (ssp == NULL)
>>> return -ENOMEM;
>> In the case of Smack, when the kernel boolean is true I think the right
>> solution is to use smack_net_ambient.
I confess that my understanding of unicast is limited.
If the intention is to send an unlabeled packet then
indeed smack_net_ambient is the way to go.
>>
> cool, here the last version :
>
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 4e5a73c..4d8e454 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -1601,7 +1601,7 @@ struct security_operations {
> int (*socket_sock_rcv_skb) (struct sock *sk, struct sk_buff *skb);
> int (*socket_getpeersec_stream) (struct socket *sock, char __user
> *optval, int __user *optlen, unsigned len);
> int (*socket_getpeersec_dgram) (struct socket *sock, struct sk_buff
> *skb, u32 *secid);
> - int (*sk_alloc_security) (struct sock *sk, int family, gfp_t priority);
> + int (*sk_alloc_security) (struct sock *sk, int family, gfp_t priority,
> bool kernel);
Is there no information already available in the sock
that will tell us this is a unicast operation?
> void (*sk_free_security) (struct sock *sk);
> void (*sk_clone_security) (const struct sock *sk, struct sock *newsk);
> void (*sk_getsecid) (struct sock *sk, u32 *secid);
> @@ -2539,7 +2539,7 @@ int security_sock_rcv_skb(struct sock *sk, struct
> sk_buff *skb);
> int security_socket_getpeersec_stream(struct socket *sock, char __user
> *optval,
> int __user *optlen, unsigned len);
> int security_socket_getpeersec_dgram(struct socket *sock, struct sk_buff
> *skb, u32 *secid);
> -int security_sk_alloc(struct sock *sk, int family, gfp_t priority);
> +int security_sk_alloc(struct sock *sk, int family, gfp_t priority, bool
> kernel);
> void security_sk_free(struct sock *sk);
> void security_sk_clone(const struct sock *sk, struct sock *newsk);
> void security_sk_classify_flow(struct sock *sk, struct flowi *fl);
> @@ -2667,7 +2667,7 @@ static inline int
> security_socket_getpeersec_dgram(struct
Re: [PATCH v5 02/12] dm: Use bioset's front_pad for dm_rq_clone_bio_info
On Wed, Aug 08, 2012 at 03:06:12PM -0700, Tejun Heo wrote:
> Hello,
>
> On Mon, Aug 06, 2012 at 03:08:31PM -0700, Kent Overstreet wrote:
> > Previously, dm_rq_clone_bio_info needed to be freed by the bio's
> > destructor to avoid a memory leak in the blk_rq_prep_clone() error path.
> > This gets rid of a memory allocation and means we can kill
> > dm_rq_bio_destructor.
> >
> > Signed-off-by: Kent Overstreet
> > ---
> > drivers/md/dm.c | 31 +--
> > 1 files changed, 5 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> > index 40b7735..4014696 100644
> > --- a/drivers/md/dm.c
> > +++ b/drivers/md/dm.c
> > @@ -92,6 +92,7 @@ struct dm_rq_target_io {
> > struct dm_rq_clone_bio_info {
> > struct bio *orig;
> > struct dm_rq_target_io *tio;
> > + struct bio clone;
> > };
> ...
> > @@ -2696,7 +2674,8 @@ struct dm_md_mempools *dm_alloc_md_mempools(unsigned
> > type, unsigned integrity)
> > if (!pools->tio_pool)
> > goto free_io_pool_and_out;
> >
> > - pools->bs = bioset_create(pool_size, 0);
> > + pools->bs = bioset_create(pool_size,
> > + offsetof(struct dm_rq_clone_bio_info, orig));
> > if (!pools->bs)
> > goto free_tio_pool_and_out;
>
> I do like this approach much better but this isn't something
> super-obvious. Can we please explain what's going on? Especially,
> the comment above dm_rq_clone_bio_info is outright misleading now.
This look better to you?
/*
* For request-based dm - the bio clones we allocate are embedded in these
* structs.
*
* We allocate these with bio_alloc_bioset, using the front_pad parameter when
* the bioset is created - this means the bio has to come at the end of the
* struct.
*/
struct dm_rq_clone_bio_info {
struct bio *orig;
struct dm_rq_target_io *tio;
struct bio clone;
};
> Can someone more familiar review this one? Alasdir, Mike?
>
> Also, how was this tested?
Well, AFAICT the only request based dm target is multipath, and from the
documentation I've seen it doesn't appear to work without multipath
hardware, or at least I haven't seen it documented how. So, unless
there's another user I missed it's not been tested.
>
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] mm: vmscan: Scale number of pages reclaimed by reclaim/compaction based on failures
On Wed, Aug 08, 2012 at 09:51:12AM +0100, Mel Gorman wrote:
> On Wed, Aug 08, 2012 at 05:27:38PM +0900, Minchan Kim wrote:
> > On Wed, Aug 08, 2012 at 08:55:26AM +0100, Mel Gorman wrote:
> > > On Wed, Aug 08, 2012 at 10:48:24AM +0900, Minchan Kim wrote:
> > > > Hi Mel,
> > > >
> > > > Just out of curiosity.
> > > > What's the problem did you see? (ie, What's the problem do this patch
> > > > solve?)
> > >
> > > Everythign in this series is related to the problem in the leader - high
> > > order allocation success rates are lower. This patch increases the success
> > > rates when allocating under load.
> > >
> > > > AFAIUC, it seem to solve consecutive allocation success ratio through
> > > > getting several free pageblocks all at once in a process/kswapd
> > > > reclaim context. Right?
> > >
> > > Only pageblocks if it is order-9 on x86, it reclaims an amount that
> > > depends
> > > on an allocation size. This only happens during reclaim/compaction context
> > > when we know that a high-order allocation has recently failed. The
> > > objective
> > > is to reclaim enough order-0 pages so that compaction can succeed again.
> >
> > Your patch increases the number of pages to be reclaimed with considering
> > the number of fail case during deferring period and your test proved it's
> > really good. Without your patch, why can't VM reclaim enough pages?
>
> It could reclaim enough pages but it doesn't. nr_to_reclaim is
> SWAP_CLUSTER_MAX and that gets short-cutted in direct reclaim at least
> by
>
> if (sc->nr_reclaimed >= sc->nr_to_reclaim)
> goto out;
>
> I could set nr_to_reclaim in try_to_free_pages() of course and drive
> it from there but that's just different, not better. If driven from
> do_try_to_free_pages(), it is also possible that priorities will rise.
> When they reach DEF_PRIORITY-2, it will also start stalling and setting
> pages for immediate reclaim which is more disruptive than not desirable
> in this case. That is a more wide-reaching change than I would expect for
> this problem and could cause another regression related to THP requests
> causing interactive jitter.
Agreed.
I hope it should be added by changelog.
>
> > Other processes steal the pages reclaimed?
>
> Or the page it reclaimed were in pageblocks that could not be used.
>
> > Why I ask a question is that I want to know what's the problem at current
> > VM.
> >
>
> We cannot reliably tell in advance whether compaction is going to succeed
> in the future without doing a full scan of the zone which would be both
> very heavy and race with any allocation requests. Compaction needs free
> pages to succeed so the intention is to scale the number of pages reclaimed
> with the number of recent compaction failures.
> If allocation fails after compaction then compaction may be deferred for
> a number of allocation attempts. If there are subsequent failures,
> compact_defer_shift is increased to defer for longer periods. This patch
> uses that information to scale the number of pages reclaimed with
> compact_defer_shift until allocations succeed again.
>
> Signed-off-by: Mel Gorman
> ---
> mm/vmscan.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 66e4310..0cb2593 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1708,6 +1708,7 @@ static inline bool should_continue_reclaim(struct
> lruvec *lruvec,
> {
> unsigned long pages_for_compaction;
> unsigned long inactive_lru_pages;
> + struct zone *zone;
>
> /* If not in reclaim/compaction mode, stop */
> if (!in_reclaim_compaction(sc))
> @@ -1741,6 +1742,15 @@ static inline bool should_continue_reclaim(struct
> lruvec *lruvec,
>* inactive lists are large enough, continue reclaiming
>*/
> pages_for_compaction = (2UL << sc->order);
> +
> + /*
> + * If compaction is deferred for this order then scale the number of
this order? sc->order?
> + * pages reclaimed based on the number of consecutive allocation
> + * failures
> + */
> + zone = lruvec_zone(lruvec);
> + if (zone->compact_order_failed >= sc->order)
I can't understand this part.
We don't defer lower order than compact_order_failed by aff62249.
Do you mean lower order compaction context should be a lamb for
deferred higher order allocation request success? I think it's not fair
and even I can't understand rationale why it has to scale the number of pages
reclaimed with the number of recent compaction failture.
Your changelog just says "What we have to do, NOT Why we have to do".
> + pages_for_compaction <<= zone->compact_defer_shift;
> inactive_lru_pages = get_lru_size(lruvec, LRU_INACTIVE_FILE);
> if (nr_swap_pages > 0)
> inactive_lru_pages += get_lru_size(lruvec, LRU_INACTIVE_ANON);
> --
> 1.7.9.2
>
>
> --
> Mel Gorman
> SUSE Labs
>
> --
> To unsubscribe, send a message with
Re: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use
Tejun, This is changing the semantics of the clone. Sorry, I missed this thread and replied separately. But anyway, replying it again here: On Wed, Aug 8, 2012 at 4:28 PM, Tejun Heo wrote: > On Mon, Aug 06, 2012 at 07:16:33PM -0400, Mikulas Patocka wrote: >> Hi Kent >> >> When you change the semantics of an exported function, rename that >> function. There may be external modules that use __bio_clone and this >> change could silently introduce bugs in them. >> >> Otherwise, the patchset looks fine. > > I don't know. This doesn't change the main functionality and should > be transparent unless the caller is doing something crazy. It *might* > be nice to rename but I don't think that's a must here. > > Thanks. -- You are changing the meaning of __bio_clone() here. In old code, the number of io_vecs, bi_idx, bi_vcnt are preserved. But in this modified code, you are mapping bio_src's bi_iovec[bi_idx] to bio_dests bi_iovec[0] and also restricting the number of allocated io_vecs of the clone. It may be useful for cases were we would like a identical copy of the original bio (may not be in current code base, but this implementation is definitely not what one would expect from the name "clone"). May be, call this new implementation some thing else (and use it for bcache)? --- Like Mikulas pointed out, this is an exported function and silently changing the semantics will break external modules. Regards, Muthu > > -- > tejun > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 12/12] block: Only clone bio vecs that are in use
Hello, On Mon, Aug 06, 2012 at 03:08:41PM -0700, Kent Overstreet wrote: > @@ -459,10 +460,10 @@ void __bio_clone(struct bio *bio, struct bio *bio_src) > bio->bi_sector = bio_src->bi_sector; > bio->bi_bdev = bio_src->bi_bdev; > bio->bi_flags |= 1 << BIO_CLONED; > + bio->bi_flags &= ~(1 << BIO_SEG_VALID); This isn't obvious at all. Why no explanation anywhere? Also it would be nice to update comments of the updated functions so that it's clear that only partial cloning happens. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use
On Mon, Aug 06, 2012 at 07:16:33PM -0400, Mikulas Patocka wrote: > Hi Kent > > When you change the semantics of an exported function, rename that > function. There may be external modules that use __bio_clone and this > change could silently introduce bugs in them. > > Otherwise, the patchset looks fine. I don't know. This doesn't change the main functionality and should be transparent unless the caller is doing something crazy. It *might* be nice to rename but I don't think that's a must here. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 11/12] block: Add bio_clone_bioset()
On Mon, Aug 06, 2012 at 03:08:40PM -0700, Kent Overstreet wrote:
> This consolidates some code, and will help in a later patch changing how
> bio cloning works.
I think it would be better to introduce bio_clone*() functions in a
separate patch and convert the users in a different one.
> /**
> - * bio_clone - clone a bio
> + * bio_clone_bioset - clone a bio
> * @bio: bio to clone
> * @gfp_mask: allocation priority
> + * @bs: bio_set to allocate from
> *
> * Like __bio_clone, only also allocates the returned bio
> */
> -struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> +struct bio *bio_clone_bioset(struct bio *bio, gfp_t gfp_mask,
> + struct bio_set *bs)
> {
> - struct bio *b = bio_alloc(gfp_mask, bio->bi_max_vecs);
> + struct bio *b = bio_alloc_bioset(gfp_mask, bio->bi_max_vecs, bs);
>
> if (!b)
> return NULL;
> @@ -485,7 +487,7 @@ struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> if (bio_integrity(bio)) {
> int ret;
>
> - ret = bio_integrity_clone(b, bio, gfp_mask, fs_bio_set);
> + ret = bio_integrity_clone(b, bio, gfp_mask, bs);
>
> if (ret < 0) {
> bio_put(b);
> @@ -495,6 +497,12 @@ struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
>
> return b;
> }
> +EXPORT_SYMBOL(bio_clone_bioset);
> +
> +struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> +{
> + return bio_clone_bioset(bio, gfp_mask, fs_bio_set);
> +}
So, bio_clone() loses its function comment. Also, does it even make
sense to call bio_clone() from fs_bio_set? Let's say it's so, then
what's the difference from using _kmalloc variant?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM QoS: Add a metric : Bus Throughput.
+ Myungjoo Ham,
It used at devfreq. Mr. Ham can you explain it in detail?
Thank you,
Kyungmin Park
,
On 8/9/12, Rafael J. Wysocki wrote:
> On Wednesday, August 08, 2012, Jonghwa Lee wrote:
>> Bus throughput metric is added to PM QoS in order to control the
>> frequency of memory interfaces and busses with PM QoS.
>>
>> Signed-off-by: Jonghwa Lee
>> Signed-off-by: Kyungmin Park
>
> I said some time ago I didn't want any new global PM QoS classes to be
> added this way.
>
> Can you please post a driver patch using this new thing?
>
> Rafael
>
>
>> ---
>> include/linux/pm_qos.h |2 ++
>> kernel/power/qos.c | 15 ++-
>> 2 files changed, 16 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
>> index 233149c..6db4939 100644
>> --- a/include/linux/pm_qos.h
>> +++ b/include/linux/pm_qos.h
>> @@ -15,6 +15,7 @@ enum {
>> PM_QOS_CPU_DMA_LATENCY,
>> PM_QOS_NETWORK_LATENCY,
>> PM_QOS_NETWORK_THROUGHPUT,
>> +PM_QOS_BUS_DMA_THROUGHPUT,
>>
>> /* insert new class ID */
>> PM_QOS_NUM_CLASSES,
>> @@ -26,6 +27,7 @@ enum {
>> #define PM_QOS_NETWORK_LAT_DEFAULT_VALUE(2000 * USEC_PER_SEC)
>> #define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE 0
>> #define PM_QOS_DEV_LAT_DEFAULT_VALUE0
>> +#define PM_QOS_BUS_DMA_THROUGHPUT_DEFAULT_VALUE 0
>>
>> struct pm_qos_request {
>> struct plist_node node;
>> diff --git a/kernel/power/qos.c b/kernel/power/qos.c
>> index 6a031e6..75322cc 100644
>> --- a/kernel/power/qos.c
>> +++ b/kernel/power/qos.c
>> @@ -100,12 +100,25 @@ static struct pm_qos_object
>> network_throughput_pm_qos = {
>> .name = "network_throughput",
>> };
>>
>> +static BLOCKING_NOTIFIER_HEAD(bus_dma_throughput_notifier);
>> +static struct pm_qos_constraints bus_dma_tput_constraints = {
>> +.list = PLIST_HEAD_INIT(bus_dma_tput_constraints.list),
>> +.target_value = PM_QOS_BUS_DMA_THROUGHPUT_DEFAULT_VALUE,
>> +.default_value = PM_QOS_BUS_DMA_THROUGHPUT_DEFAULT_VALUE,
>> +.type = PM_QOS_MAX,
>> +.notifiers = _dma_throughput_notifier,
>> +};
>> +static struct pm_qos_object bus_dma_throughput_pm_qos = {
>> +.constraints = _dma_tput_constraints,
>> +.name = "bus_dma_throughput",
>> +};
>>
>> static struct pm_qos_object *pm_qos_array[] = {
>> _pm_qos,
>> _dma_pm_qos,
>> _lat_pm_qos,
>> -_throughput_pm_qos
>> +_throughput_pm_qos,
>> +_dma_throughput_pm_qos,
>> };
>>
>> static ssize_t pm_qos_power_write(struct file *filp, const char __user
>> *buf,
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 10/12] block: Add bio_clone_kmalloc()
On Mon, Aug 06, 2012 at 03:08:39PM -0700, Kent Overstreet wrote:
How about the following?
There was no API to kmalloc bio and clone and osdblk was using
explicit bio_kmalloc() + __bio_clone(). (my guess here) As this is
inconvenient and there will be more users of it in the future, add
bio_clone_kmalloc() and use it in osdblk.
> Acked-by: Boaz Harrosh
> Signed-off-by: Kent Overstreet
> ---
> drivers/block/osdblk.c |3 +--
> fs/bio.c | 13 +
> fs/exofs/ore.c |5 ++---
> include/linux/bio.h|1 +
> 4 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/block/osdblk.c b/drivers/block/osdblk.c
> index 87311eb..1bbc681 100644
> --- a/drivers/block/osdblk.c
> +++ b/drivers/block/osdblk.c
> @@ -266,11 +266,10 @@ static struct bio *bio_chain_clone(struct bio
> *old_chain, gfp_t gfpmask)
> struct bio *tmp, *new_chain = NULL, *tail = NULL;
>
> while (old_chain) {
> - tmp = bio_kmalloc(gfpmask, old_chain->bi_max_vecs);
> + tmp = bio_clone_kmalloc(old_chain, gfpmask);
> if (!tmp)
> goto err_out;
>
> - __bio_clone(tmp, old_chain);
> tmp->bi_bdev = NULL;
> gfpmask &= ~__GFP_WAIT;
> tmp->bi_next = NULL;
> diff --git a/fs/bio.c b/fs/bio.c
> index f0c865b..77b9313 100644
> --- a/fs/bio.c
> +++ b/fs/bio.c
> @@ -497,6 +497,19 @@ struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> }
> EXPORT_SYMBOL(bio_clone);
>
/**
PLEASE.
> +struct bio *bio_clone_kmalloc(struct bio *bio, gfp_t gfp_mask)
> +{
> + struct bio *b = bio_kmalloc(gfp_mask, bio->bi_max_vecs);
Can't we use %NULL bioset as an indication to allocate from kmalloc
instead of duping interfaces like this?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 09/12] block: Rework bio_pair_split()
Hello, On Mon, Aug 06, 2012 at 03:08:38PM -0700, Kent Overstreet wrote: > This changes bio_pair_split() to use the new bio_split() underneath, > which gets rid of the single page bio limitation. The various callers > are fixed up for the slightly different struct bio_pair, and to remove > the unnecessary checks. > > v5: Move extern declaration to proper patch, per Boaz I don't get this. Why can't bio_split() chain the split to the original one thus make bio_pair unnecessary? It's not like completing the split bio with the same end_io ever makes sense. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] remoteproc: add rproc_report_crash function to notify rproc crashes
This patch is exporting the rproc_report_crash function which can be used
to report a rproc crash to the remoteproc core. This function is specially
thought to be called by low-level remoteproc driver code in case of
detecting a crash (remoteproc is not functional anymore). Using this
function from another driver (non rproc driver) should be analyzed very
carefully most of the time that will be considered wrong.
rproc_report_crash function can be called from any context, that means,
it can be called from atomic context without any problem. The reporter
function is creating a new thread (workqueue work) in charge of handling
the crash (if possible).
Creating this new thread is done for two main reasons. First reason is
to be able to call it from atomic context, due to the fact that many
crashes trigger an interrupt, so this function can be called directly
from ISR context. Second reason is avoid any deadlock condition which
could happen if the rproc_report_crash function is called from a
function which is indirectly holding a rproc lock.
The reporter function is scheduling the crash handler task. This task
is thought to have some features like:
-remoteproc register dump
-remoteproc stack dump
-remoteproc core dump
-Saving of the remoteproc traces in order to be visible after the crash
-Reseting the remoteproc in order to make it functional again (hard recovery)
Right now, it is only printing the crash type which was detected. The
types of crashes are represented by an enum. I have only added mmufault
crash type. Remoteproc low-level drivers can add more types when needed.
Signed-off-by: Fernando Guzman Lugo
---
Documentation/remoteproc.txt |7 +++
drivers/remoteproc/remoteproc_core.c | 80 +++---
include/linux/remoteproc.h | 18
3 files changed, 98 insertions(+), 7 deletions(-)
diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index 23a09b8..e6469fd 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -129,6 +129,13 @@ int dummy_rproc_example(struct rproc *my_rproc)
Returns 0 on success and -EINVAL if @rproc isn't valid.
+ void rproc_report_crash(struct rproc *rproc, enum rproc_crash_type type)
+- Report a crash in a remoteproc
+ This function must be called every time a crash is detected by the
+ platform specific rproc implementation. This should not be called from a
+ non-remoteproc driver. This function can be called from atomic/interrupt
+ context.
+
5. Implementation callbacks
These callbacks should be provided by platform-specific remoteproc
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index d5c2dbf..3a6f1a1 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -50,6 +50,18 @@ typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
void *, int avail);
/* Unique indices for remoteproc devices */
static DEFINE_IDA(rproc_dev_index);
+static const char * const rproc_crash_names[] = {
+ [RPROC_MMUFAULT]= "mmufault",
+};
+
+/* translate rproc_crash_type to string */
+static const char *rproc_crash_to_string(enum rproc_crash_type type)
+{
+ if (type < ARRAY_SIZE(rproc_crash_names))
+ return rproc_crash_names[type];
+ return "unkown";
+}
+
/*
* This is the IOMMU fault handler we register with the IOMMU API
* (when relevant; not all remote processors access memory through
@@ -57,19 +69,17 @@ static DEFINE_IDA(rproc_dev_index);
*
* IOMMU core will invoke this handler whenever the remote processor
* will try to access an unmapped device address.
- *
- * Currently this is mostly a stub, but it will be later used to trigger
- * the recovery of the remote processor.
*/
static int rproc_iommu_fault(struct iommu_domain *domain, struct device *dev,
unsigned long iova, int flags, void *token)
{
+ struct rproc *rproc = token;
+
dev_err(dev, "iommu fault: da 0x%lx flags 0x%x\n", iova, flags);
- /*
-* Let the iommu core know we're not really handling this fault;
-* we just plan to use this as a recovery trigger.
-*/
+ rproc_report_crash(rproc, RPROC_MMUFAULT);
+
+ /* Let the iommu core know we're not really handling this fault; */
return -ENOSYS;
}
@@ -872,6 +882,34 @@ out:
}
/**
+ * rproc_crash_handler_work() - handle a crash
+ *
+ * This function needs to handle everything related to a crash, like cpu
+ * registers and stack dump, information to help to debug the fatal error, etc.
+ */
+static void rproc_crash_handler_work(struct work_struct *work)
+{
+ struct rproc *rproc = container_of(work, struct rproc, crash_handler);
+ struct device *dev = >dev;
+
+ dev_dbg(dev, "enter %s\n", __func__);
+
+ mutex_lock(>lock);
+ if (rproc->state == RPROC_CRASHED || rproc->state == RPROC_OFFLINE) {
+
[PATCH 2/3] remoteproc: recover a remoteproc when it has crashed
This patch is introducing rproc_trigger_recover function which is in
charge of recovering the rproc. One way to recover the rproc after a crash
is resetting all its virtio devices. Doing that, all rpmsg drivers are
restored along with the rpmsg devices and that also causes the reset of
the remoteproc making the rpmsg communication with the remoteproc
functional again. So far, rproc_trigger_recover function is only resetting
all virtio devices, if in the future other rproc features are introduced
and need to be reset too, rproc_trigger_recover function should take care
of that.
Signed-off-by: Fernando Guzman Lugo
---
drivers/remoteproc/remoteproc_core.c | 28 +++-
drivers/remoteproc/remoteproc_internal.h |1 +
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3a6f1a1..c879069 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -882,6 +882,32 @@ out:
}
/**
+ * rproc_trigger_recover() - recover a remoteproc
+ * @rproc: the remote processor
+ *
+ * The recovery is done by reseting all the virtio devices, that way all the
+ * rpmsg drivers will be reseted along with the remote processor making the
+ * remoteproc functional again.
+ *
+ * This function can sleep, so that it cannot be called from atomic context.
+ */
+int rproc_trigger_recover(struct rproc *rproc)
+{
+ struct rproc_vdev *rvdev, *rvtmp;
+
+ dev_err(>dev, "recovering %s\n", rproc->name);
+
+ /* clean up remote vdev entries */
+ list_for_each_entry_safe(rvdev, rvtmp, >rvdevs, node)
+ rproc_remove_virtio_dev(rvdev);
+
+ /* run rproc_fw_config_virtio to create vdevs again */
+ return request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
+ rproc->firmware, >dev, GFP_KERNEL,
+ rproc, rproc_fw_config_virtio);
+}
+
+/**
* rproc_crash_handler_work() - handle a crash
*
* This function needs to handle everything related to a crash, like cpu
@@ -906,7 +932,7 @@ static void rproc_crash_handler_work(struct work_struct
*work)
++rproc->crash_cnt, rproc->name);
mutex_unlock(>lock);
- /* TODO: handle crash */
+ rproc_trigger_recover(rproc);
}
/**
diff --git a/drivers/remoteproc/remoteproc_internal.h
b/drivers/remoteproc/remoteproc_internal.h
index a690ebe..d9c0730 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -63,6 +63,7 @@ void rproc_free_vring(struct rproc_vring *rvring);
int rproc_alloc_vring(struct rproc_vdev *rvdev, int i);
void *rproc_da_to_va(struct rproc *rproc, u64 da, int len);
+int rproc_trigger_recover(struct rproc *rproc);
static inline
int rproc_fw_sanity_check(struct rproc *rproc, const struct firmware *fw)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] net/stmmac: mark probe function as __devinit
From: Arnd Bergmann Date: Wed, 8 Aug 2012 16:47:24 +0200 > Driver probe functions are generally __devinit so they will be > discarded after initialization for non-hotplug kernels. > This was found by a new warning after patch 6a228452d "stmmac: Add > device-tree support" adds a new __devinit function that is called > from stmmac_pltfr_probe. > > Without this patch, building socfpga_defconfig results in: > > WARNING: drivers/net/ethernet/stmicro/stmmac/stmmac.o(.text+0x5d4c): Section > mismatch in reference from the function stmmac_pltfr_probe() to the function > .devinit.text:stmmac_probe_config_dt() > The function stmmac_pltfr_probe() references > the function __devinit stmmac_probe_config_dt(). > This is often because stmmac_pltfr_probe lacks a __devinit > annotation or the annotation of stmmac_probe_config_dt is wrong. > > Signed-off-by: Arnd Bergmann > Cc: Stefan Roese > Cc: Giuseppe Cavallaro > Cc: David S. Miller > Cc: net...@vger.kernel.org Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] remoteproc: create debugfs entry to disable/enable recovery dynamically
Add a debugfs entry (named recovery) so that recovery can be disabled
dynamically at runtime. This entry is very useful when you are trying to
debug a rproc crash. Without this a recovery will take place making
impossible to debug the issue.
Original idea from Ohad Ben-Cohen and contributions from
Subramaniam Chanderashekarapuram
Example:
-disabling recovery:
$ echo disabled > /remoteproc/remoteproc0/recovery
-enabling recovery:
$ echo enabled > /remoteproc/remoteproc0/recovery
-in case you have disabled recovery and you want to continue
debugging you can recover the remoteproc once using recover.
This will not change the state of the recovery entry, it will
only recovery the rproc if its state is RPROC_CRASHED
$ echo recover > /remoteproc/remoteproc0/recovery
Signed-off-by: Fernando Guzman Lugo
---
drivers/remoteproc/remoteproc_core.c|3 +-
drivers/remoteproc/remoteproc_debugfs.c | 83 +++
include/linux/remoteproc.h |2 +
3 files changed, 87 insertions(+), 1 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index c879069..0b52169 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -932,7 +932,8 @@ static void rproc_crash_handler_work(struct work_struct
*work)
++rproc->crash_cnt, rproc->name);
mutex_unlock(>lock);
- rproc_trigger_recover(rproc);
+ if (!rproc->recovery_disabled)
+ rproc_trigger_recover(rproc);
}
/**
diff --git a/drivers/remoteproc/remoteproc_debugfs.c
b/drivers/remoteproc/remoteproc_debugfs.c
index 0383385..aa95cde 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -28,6 +28,9 @@
#include
#include
#include
+#include
+
+#include "remoteproc_internal.h"
/* remoteproc debugfs parent dir */
static struct dentry *rproc_dbg;
@@ -111,6 +114,84 @@ static const struct file_operations rproc_name_ops = {
.llseek = generic_file_llseek,
};
+/* expose recovery flag via debugfs */
+static ssize_t rproc_recovery_read(struct file *filp, char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ struct rproc *rproc = filp->private_data;
+ char *buf = rproc->recovery_disabled ? "disabled\n" : "enabled\n";
+
+ return simple_read_from_buffer(userbuf, count, ppos, buf, strlen(buf));
+}
+
+
+/*
+ * Writing to the recovey debugfs entry we can change the behavior of the
+ * recovery dynamically. The default value of this entry is "enabled".
+ *
+ * There are 3 possible options you can write to the recovery debug entry:
+ * "enabled", "disabled" and "recover"
+ *
+ * enabled:In this case recovery will be enabled, every time there is a
+ * rproc crashed the rproc will be recovered. If recovery has been
+ * disabled and it crashed and you enable recovery it will be
+ * recover as soon as you enable recovery.
+ * disabled: In this case recovery will be disabled, that means if a rproc
+ * crashes it will remain in crashed state. Therefore the rproc
+ * won't be functional any more. But this option is used for
+ * debugging purposes. Otherwise, debugging a crash would not be
+ * possible.
+ * recover:This function will trigger a recovery without taking care of
+ * the recovery state (enabled/disabled) and without changing it.
+ * This useful for the cases when you are debugging a crash and
+ * after enabling recovery you get another crash immediately. As
+ * the recovery state will be enabled it will recover the rproc
+ * without let you debug the new crash. So, it is recommended to
+ * disabled recovery, then starting debugging and use "recovery"
+ * command while still debugging and when you are done then you
+ * case use enabled command.
+ */
+static ssize_t rproc_recovery_write(struct file *filp,
+ const char __user *user_buf, size_t count, loff_t *ppos)
+{
+ struct rproc *rproc = filp->private_data;
+ char buf[10];
+ int ret;
+
+ if (count > sizeof(buf))
+ return count;
+
+ ret = copy_from_user(buf, user_buf, count);
+ if (ret)
+ return ret;
+
+ /* remove end of line */
+ if (buf[count - 1] == '\n')
+ buf[count - 1] = '\0';
+
+ if (!strncmp(buf, "enabled", count)) {
+ rproc->recovery_disabled = false;
+ /* if rproc has crashed trigger recovery */
+ if (rproc->state == RPROC_CRASHED)
+ rproc_trigger_recover(rproc);
+ } else if (!strncmp(buf, "disabled", count)) {
+ rproc->recovery_disabled = true;
+ } else if (!strncmp(buf, "recover", count)) {
+ /* if rproc has crashed trigger recovery */
+
Re: [PATCH] lpc_eth: remove obsolete ifdefs
From: Roland Stigge Date: Wed, 8 Aug 2012 15:18:54 +0200 > The #ifdefs regarding CONFIG_ARCH_LPC32XX_MII_SUPPORT and > CONFIG_ARCH_LPC32XX_IRAM_FOR_NET are obsolete since the symbols have been > removed from Kconfig and replaced by devicetree based configuration. > > Signed-off-by: Roland Stigge Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] remoteproc: introduce rproc recovery
These set of patches make possible the remoteproc recover after a crash. This is a hard recovery, that means the remoteproc is reset and it will start from the beginning. When a crash happen all the virtio devices are destroyed. Therefore, both rpmsg drivers and devices are gracefully removed which also cause rproc users become 0 and the remoteproc is turned off. After the virtio devices are destroyed the crash handler function will read the virtio information from the firmware in order to recreate the virtio devices that will boot the remoteproc and everything will be functional again. Fernando Guzman Lugo (3): remoteproc: add rproc_report_crash function to notify rproc crashes remoteproc: recover a remoteproc when it has crashed remoteproc: create debugfs entry to disable/enable recovery dynamically Documentation/remoteproc.txt |7 ++ drivers/remoteproc/remoteproc_core.c | 107 -- drivers/remoteproc/remoteproc_debugfs.c | 83 +++ drivers/remoteproc/remoteproc_internal.h |1 + include/linux/remoteproc.h | 20 ++ 5 files changed, 211 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/core: Fix potential memory leak in dev_set_alias()
From: Alexey Khoroshilov Date: Wed, 8 Aug 2012 14:33:25 +0400 > Do not leak memory by updating pointer with potentially NULL realloc return > value. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 08/12] block: Introduce new bio_split()
One more thing.
On Mon, Aug 06, 2012 at 03:08:37PM -0700, Kent Overstreet wrote:
> + if (bio_integrity(bio)) {
> + bio_integrity_clone(ret, bio, gfp, bs);
> + bio_integrity_trim(ret, 0, bio_sectors(ret));
> + bio_integrity_trim(bio, bio_sectors(ret), bio_sectors(bio));
Is this equivalent to bio_integrity_split() performance-wise?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
