[PATCH 8/8] perf tools: Fix LIBNUMA build with glibc 2.12 and older.
From: Vinson Lee The tokens MADV_HUGEPAGE and MADV_NOHUGEPAGE are not available with glibc 2.12 and older. Define these tokens if they are not already defined. This patch fixes these build errors with older versions of glibc. CC bench/numa.o bench/numa.c: In function ‘alloc_data’: bench/numa.c:334: error: ‘MADV_HUGEPAGE’ undeclared (first use in this function) bench/numa.c:334: error: (Each undeclared identifier is reported only once bench/numa.c:334: error: for each function it appears in.) bench/numa.c:341: error: ‘MADV_NOHUGEPAGE’ undeclared (first use in this function) make: *** [bench/numa.o] Error 1 Signed-off-by: Vinson Lee Acked-by: Ingo Molnar Cc: Ingo Molnar Cc: Irina Tirdea Cc: Paul Mackerras Cc: Pekka Enberg Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1363214064-4671-2-git-send-email-v...@twitter.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/bench/bench.h | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/tools/perf/bench/bench.h b/tools/perf/bench/bench.h index a5223e6..0fdc852 100644 --- a/tools/perf/bench/bench.h +++ b/tools/perf/bench/bench.h @@ -1,6 +1,30 @@ #ifndef BENCH_H #define BENCH_H +/* + * The madvise transparent hugepage constants were added in glibc + * 2.13. For compatibility with older versions of glibc, define these + * tokens if they are not already defined. + * + * PA-RISC uses different madvise values from other architectures and + * needs to be special-cased. + */ +#ifdef __hppa__ +# ifndef MADV_HUGEPAGE +# define MADV_HUGEPAGE67 +# endif +# ifndef MADV_NOHUGEPAGE +# define MADV_NOHUGEPAGE 68 +# endif +#else +# ifndef MADV_HUGEPAGE +# define MADV_HUGEPAGE14 +# endif +# ifndef MADV_NOHUGEPAGE +# define MADV_NOHUGEPAGE 15 +# endif +#endif + extern int bench_numa(int argc, const char **argv, const char *prefix); extern int bench_sched_messaging(int argc, const char **argv, const char *prefix); extern int bench_sched_pipe(int argc, const char **argv, const char *prefix); -- 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/
[PATCH 6/8] perf probe: Fix segfault
From: Ananth N Mavinakayanahalli Fix segfault in perf probe due to a bug introduced by commit d8639f068 (perf tools: Stop using 'self' in strlist). Signed-off-by: Ananth N Mavinakayanahalli Acked-by: Srikar Dronamraju Cc: Srikar Dronamraju Link: http://lkml.kernel.org/r/20130312090217.gc4...@in.ibm.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/strlist.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/perf/util/strlist.c b/tools/perf/util/strlist.c index 55433aa..eabdce0 100644 --- a/tools/perf/util/strlist.c +++ b/tools/perf/util/strlist.c @@ -143,7 +143,7 @@ struct strlist *strlist__new(bool dupstr, const char *list) slist->rblist.node_delete = strlist__node_delete; slist->dupstr= dupstr; - if (slist && strlist__parse_list(slist, list) != 0) + if (list && strlist__parse_list(slist, list) != 0) goto out_error; } -- 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/
[PATCH 1/8] perf annotate: Fix build with NO_NEWT=1
From: Michael Ellerman Commit 18c9e5c "Make it to be able to skip unannotatable symbols" broke the build with NO_NEWT=1: CC builtin-annotate.o builtin-annotate.c: In function 'hists__find_annotations': builtin-annotate.c:161:4: error: duplicate case value builtin-annotate.c:154:4: error: previously used here make: *** [builtin-annotate.o] Error 1 This is because without NEWT support K_LEFT is #defined to -1 in utils/hist.h Fix it by shifting the K_LEFT/K_RIGHT #defines out of the likely range of error values. Signed-off-by: Michael Ellerman Cc: Feng Tang Cc: Namhyung Kim Cc: Namhyung Kim Link: http://lkml.kernel.org/r/1361854923-1814-1-git-send-email-mich...@ellerman.id.au Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/hist.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h index 3862468..609a115 100644 --- a/tools/perf/util/hist.h +++ b/tools/perf/util/hist.h @@ -208,8 +208,8 @@ static inline int script_browse(const char *script_opt __maybe_unused) return 0; } -#define K_LEFT -1 -#define K_RIGHT -2 +#define K_LEFT -1000 +#define K_RIGHT -2000 #endif #ifdef GTK2_SUPPORT -- 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: MTD : Kernel oops when remounting ubifs as read/write
On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote: > > Is this size larger than the allocated buffer ? > > I believe so. Err, I mean, the buffer is large enough. I do not believe there is a stupid bug like too small buffer. This code has worked for years and I do not think it was changes much. The oops may be cause by memory corruption - some of your drivers may corrupt memory. You need to spend more time debugging this carefully. Do you have fastmap UBI feature enabled? -- Best Regards, Artem Bityutskiy -- 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: MTD : Kernel oops when remounting ubifs as read/write
On Thu, 2013-03-14 at 12:02 +, Mark Jackson wrote: > But there's also a call to crc with a size of 122880 bytes, and that's > when the oops occurs. > This is when we do the atomic LEB change. > Is this size larger than the allocated buffer ? I believe so. -- Best Regards, Artem Bityutskiy -- 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 00/44] ldisc patchset
On Thu, Mar 14, 2013 at 4:42 AM, Peter Hurley wrote: > On Thu, 2013-03-14 at 00:25 -0700, Michel Lespinasse wrote: >> Its not too late to run away from it and preserve your sanity (as well >> as that of the next person working on the tty layer :) > > The long-term plan is to migrate it to lib so it won't be a maintenance > burden to tty. That only moves the problem though, and makes sense only if we know of another place where an unfair rwsem is desired... -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- 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/2] usb: dwc3: exynos: Use of_platform API to create dwc3 core pdev
On Thu, Mar 14, 2013 at 4:21 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Mar 14, 2013 at 04:14:57PM +0530, Vivek Gautam wrote:
>> @@ -170,7 +155,6 @@ static int dwc3_exynos_remove(struct platform_device
>> *pdev)
>> {
>> struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
>>
>> - platform_device_unregister(exynos->dwc3);
>
> don't you want to do what Kishon did here and have:
>
> static int dwc3_exynos_remove_child(struct device *dev, void *unused)
> {
> struct platform_device *pdev = to_platform_device(dev);
>
> platform_device_unregister(pdev);
>
> return 0;
> }
>
> device_for_each_child(&pdev->dev, NULL, dwc3_exynos_remove_child);
>
> ???
Hmm, right. We need to do that. :-)
>
> --
> balbi
--
Thanks & Regards
Vivek
--
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 2/2] pinctrl/nomadik: Fix checkpatch errors
Fixes the following types of checkpatch errors:
ERROR: space required after that ',' (ctx:VxV)
ERROR: space prohibited before that close parenthesis ')'
Signed-off-by: Sachin Kamat
---
drivers/pinctrl/pinctrl-nomadik.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik.c
b/drivers/pinctrl/pinctrl-nomadik.c
index 2328baa..267d81c 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -1565,8 +1565,8 @@ static int nmk_dt_add_map_configs(struct pinctrl_map
**map,
return 0;
}
-#define NMK_CONFIG_PIN(x,y) { .property = x, .config = y, }
-#define NMK_CONFIG_PIN_ARRAY(x,y) { .property = x, .choice = y, \
+#define NMK_CONFIG_PIN(x, y) { .property = x, .config = y, }
+#define NMK_CONFIG_PIN_ARRAY(x, y) { .property = x, .choice = y, \
.size = ARRAY_SIZE(y), }
static const unsigned long nmk_pin_input_modes[] = {
@@ -2068,7 +2068,7 @@ static int nmk_pin_config_set(struct pinctrl_dev
*pctldev, unsigned pin,
pin, cfg, pullnames[pull], slpmnames[slpm],
output ? "output " : "input",
output ? (val ? "high" : "low") : "",
- lowemi ? "on" : "off" );
+ lowemi ? "on" : "off");
clk_enable(nmk_chip->clk);
bit = pin % NMK_GPIO_PER_CHIP;
--
1.7.4.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/
[PATCH 1/2] pinctrl/nomadik-db8500: Fix checkpatch errors
Silences the following type of checkpatch errors:
ERROR: space required after that ',' (ctx:VxV)
Signed-off-by: Sachin Kamat
---
drivers/pinctrl/pinctrl-nomadik-db8500.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik-db8500.c
b/drivers/pinctrl/pinctrl-nomadik-db8500.c
index 30b4da9..c748407 100644
--- a/drivers/pinctrl/pinctrl-nomadik-db8500.c
+++ b/drivers/pinctrl/pinctrl-nomadik-db8500.c
@@ -466,7 +466,7 @@ static const unsigned mc1_a_1_pins[] = { DB8500_PIN_AH16,
DB8500_PIN_AG15,
DB8500_PIN_AJ15, DB8500_PIN_AG14, DB8500_PIN_AF13, DB8500_PIN_AG13,
DB8500_PIN_AH15 };
static const unsigned mc1_a_2_pins[] = { DB8500_PIN_AH16, DB8500_PIN_AJ15,
- DB8500_PIN_AG14, DB8500_PIN_AF13, DB8500_PIN_AG13,DB8500_PIN_AH15 };
+ DB8500_PIN_AG14, DB8500_PIN_AF13, DB8500_PIN_AG13, DB8500_PIN_AH15 };
static const unsigned mc1dir_a_1_pins[] = { DB8500_PIN_AH13, DB8500_PIN_AG12,
DB8500_PIN_AH12, DB8500_PIN_AH11 };
static const unsigned hsir_a_1_pins[] = { DB8500_PIN_AG10, DB8500_PIN_AH10,
@@ -663,7 +663,7 @@ static const unsigned hwobs_oc4_1_pins[] = {
DB8500_PIN_D17, DB8500_PIN_D16,
DB8500_PIN_D21, DB8500_PIN_D20, DB8500_PIN_C20, DB8500_PIN_B21,
DB8500_PIN_C21, DB8500_PIN_A22, DB8500_PIN_B24, DB8500_PIN_C22 };
-#define DB8500_PIN_GROUP(a,b) { .name = #a, .pins = a##_pins, \
+#define DB8500_PIN_GROUP(a, b) { .name = #a, .pins = a##_pins, \
.npins = ARRAY_SIZE(a##_pins), .altsetting = b }
static const struct nmk_pingroup nmk_db8500_groups[] = {
--
1.7.4.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: zsmalloc limitations and related topics
On 03/14/2013 06:59 AM, Seth Jennings wrote: On 03/13/2013 03:02 PM, Dan Magenheimer wrote: From: Robert Jennings [mailto:r...@linux.vnet.ibm.com] Subject: Re: zsmalloc limitations and related topics Hi Robert -- Thanks for the well-considered reply! * Dan Magenheimer (dan.magenhei...@oracle.com) wrote: Hi all -- I've been doing some experimentation on zsmalloc in preparation for my topic proposed for LSFMM13 and have run across some perplexing limitations. Those familiar with the intimate details of zsmalloc might be well aware of these limitations, but they aren't documented or immediately obvious, so I thought it would be worthwhile to air them publicly. I've also included some measurements from the experimentation and some related thoughts. (Some of the terms here are unusual and may be used inconsistently by different developers so a glossary of definitions of the terms used here is appended.) ZSMALLOC LIMITATIONS Zsmalloc is used for two zprojects: zram and the out-of-tree zswap. Zsmalloc can achieve high density when "full". But: 1) Zsmalloc has a worst-case density of 0.25 (one zpage per four pageframes). The design of the allocator results in a trade-off between best case density and the worst-case which is true for any allocator. For zsmalloc, the best case density with a 4K page size is 32.0, or 177.0 for a 64K page size, based on storing a set of zero-filled pages compressed by lzo1x-1. Right. Without a "representative workload", we have no idea whether either my worst-case or your best-case will be relevant. (As an aside, I'm measuring zsize=28 bytes for a zero page... Seth has repeatedly said 103 bytes and I think this is reflected in your computation above. Maybe it is 103 for your hardware compression engine? Else, I'm not sure why our numbers would be different.) I rechecked this and found my measurement was flawed. It was based on compressing a zero-filled file with lzop -1. The file size is 107 but, as I recently discovered, contains LZO metadata as well. Using lzop -l, I got that the compressed size of the data (not the file), is 44 bytes. So still not what you are observing but closer. $ dd if=/dev/zero of=zero.page bs=4k count=1 $ lzop -1 zero.page $ lzop -l zero.page.lzo method compressed uncompr. ratio uncompressed_name LZO1X-1(15)44 4096 1.1% zero.page 2) When not full and especially when nearly-empty _after_ being full, density may fall below 1.0 as a result of fragmentation. True and there are several ways to address this including defragmentation, fewer class sizes in zsmalloc, aging, and/or writeback of zpages in sparse zspages to free pageframes during normal writeback. Yes. And add pageframe-reclaim to this list of things that zsmalloc should do but currently cannot do. The real question is why is pageframe-reclaim a requirement? What operation needs this feature? AFAICT, the pageframe-reclaim requirements is derived from the assumption that some external control path should be able to tell zswap/zcache to evacuate a page, like the shrinker interface. But this introduces a new and complex problem in designing a policy that doesn't shrink the zpage pool so aggressively that it is useless. Unless there is another reason for this functionality I'm missing. Perhaps it's needed if the user want to enable/disable the memory compression feature dynamically. Eg, use it as a module instead of recompile the kernel or even reboot the system. 3) Zsmalloc has a density of exactly 1.0 for any number of zpages with zsize >= 0.8. For this reason zswap does not cache pages which in this range. It is not enforced in the allocator because some users may be forced to store these pages; users like zram. Again, without a "representative" workload, we don't know whether or not it is important to manage pages with zsize >= 0.8. You are simply dismissing it as unnecessary because zsmalloc can't handle them and because they don't appear at any measurable frequency in kernbench or SPECjbb. (Zbud _can_ efficiently handle these larger pages under many circumstances... but without a "representative" workload, we don't know whether or not those circumstances will occur.) The real question is not whether any workload would operate on pages that don't compress to 80%. Any workload that operates on pages of already compressed or encrypted data would do this. The question is, is it worth it to store those pages in the compressed cache since the effective reclaim efficiency approaches 0. Hmm.. Yes, i'd prefer to skip those pages at first glance. 4) Zsmalloc contains several compile-time parameters; the best value of these parameters may be very workload dependent. The parameters fall into two major areas, handle computation and class size. The handle can be abstracted away, eliminating the compile-time parameters. The class-size tunable could be changed to a default value with the optio
Re: [PATCH v2] USB: ehci-s5p: Fix phy reset
On 14.03.2013, at 04:38, Doug Anderson wrote: > Alexander, > > On Wed, Mar 13, 2013 at 4:59 PM, Alexander Graf wrote: >> On my Exynos 5 based Arndale system, I need to pull the reset line down >> and then let it go up again to actually perform a reset. Without that >> reset, I can't find any USB hubs on my bus, rendering the USB controller >> useless. >> >> We also only need to reset the line after the phy node has been found. >> This way we don't accidently reserve the vbus GPIO pin, but later on >> defer the creation of our controller, because the phy device tree node >> hasn't been probed yet. >> >> This patch implements the above logic, making EHCI and OHCI work on >> Arndale systems for me. >> >> Signed-off-by: Alexander Graf >> CC: Vivek Gautam >> CC: Jingoo Han >> CC: Alan Stern >> CC: Kukjin Kim >> CC: Felipe Balbi >> CC: Greg Kroah-Hartman >> CC: Doug Anderson >> >> --- >> >> v1 -> v2: >> >> - remove gpio_free call >> - move reset logic after phy node search > > Seems fine to me. I guess the earlier problem you wrote about was the > probe failure, then? Well, the problem I wrote about was that when I do * probe -> reset phy * probe gets deferred * deferred probe -> can't reset phy because the pin is already in use Then I get the same breakage again. However, if I do * probe * probe gets deferred * deferred probe -> reset phy Then everything works just fine. > I think that the reason I don't tend to get the > probe failure is that I've got my device tree ordered differently so > that the phy gets initted in a different order. Odd - I get the deferral regardless of how I order my device tree :). Alex > > I'll send up the devm_ patch atop this. > > Reviewed-by: Doug Anderson > > Thanks! :) > > -Doug -- 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: MTD : Kernel oops when remounting ubifs as read/write
On 14/03/13 11:23, Artem Bityutskiy wrote: > On Thu, 2013-03-14 at 11:15 +, Mark Jackson wrote: >> [ 28.538525] [d08ea004] *pgd=8f045811, *pte=, *ppte= >> [ 28.545173] Internal error: Oops: 7 [#1] ARM >> [ 28.549685] CPU: 0Not tainted >> (3.8.0-next-20130225-2-g678576f-dirty #40) >> [ 28.557595] PC is at crc32_le+0x50/0x168 >> [ 28.561735] LR is at ubi_eba_atomic_leb_change+0x1b4/0x410 >> [ 28.567523] pc : []lr : []psr: 2013 >> [ 28.567523] sp : cf385de0 ip : 180a985a fp : c054f840 >> [ 28.579632] r10: c054f040 r9 : c054fc40 r8 : 158a1232 >> [ 28.585141] r7 : 4d506705 r6 : 9324fd72 r5 : 4dc8a10b r4 : 4c162691 >> [ 28.592025] r3 : c054e040 r2 : c054f440 r1 : d08ea000 r0 : 4c8ee09f >> [ 28.598912] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment >> user >> [ 28.606439] Control: 10c5387d Table: 8f3b8019 DAC: 0015 >> [ 28.612501] Process mount (pid: 659, stack limit = 0xcf384238) >> [ 28.618652] Stack: (0xcf385de0 to 0xcf386000) >> [ 28.623254] 5de0: cf2f8554 d08e6e8c 180a9e88 5a257c4f 58399ee9 >> c8d98a08 bb0ee864 >> [ 28.631886] 5e00: eae10678 c054fc40 c054f040 c054f840 cf2f8000 >> d08caffc 3c00 >> [ 28.640517] 5e20: cf2f8000 cf357c00 000c cf2ec000 >> 000c cf2f8554 >> [ 28.649148] 5e40: d08cb000 0001e000 d08cb000 8000 >> 0001e000 >> [ 28.657779] 5e60: 000c d08cb000 0080 000c 000c >> 0020 >> [ 28.666409] 5e80: 8000 c026c41c 0001e000 cf33 cf33 d08cb000 >> 0001e000 c0179b14 >> [ 28.675042] 5ea0: 000d c0177a68 0001e000 cf33 cf330b20 >> 000d c0179698 >> [ 28.683672] 5ec0: cf33 cf330a9c cf385f48 c0175170 >> 0001 6013 >> [ 28.692303] 5ee0: cf32c800 cf385f48 >> 0020 c00c9e24 >> [ 28.700934] 5f00: 00100100 00200200 cf3a6c80 8000 cf384000 00208020 >> cf01a200 >> [ 28.709564] 5f20: cf32c800 c00e3d6c 000c cf32c840 >> c0013968 cf31fb80 >> [ 28.718195] 5f40: 000c cf01a210 ce828858 000c cf3ac000 >> 000a18b4 >> [ 28.726827] 5f60: 00208020 c0013968 cf384000 0003 c00e3e40 >> c0071e24 >> [ 28.735459] 5f80: cf31fb80 cf31fbc0 a010 >> bed87b68 b6ff148c >> [ 28.744091] 5fa0: 0015 c00137c0 bed87b68 000a18b4 000a18c0 >> 000a18c2 00208020 >> [ 28.752720] 5fc0: bed87b68 b6ff148c 0015 >> 0003 >> [ 28.761350] 5fe0: b6fa3f48 bed87a64 00042994 b6fa3f58 a010 000a18b4 >> >> [ 28.769989] [] (crc32_le+0x50/0x168) from [] >> (0xcf2f8000) >> [ 28.777522] Code: e58d8008 0a26 e1a0c005 e58d2004 (e5916004) >> [ 28.784029] ---[ end trace f50f53afffe647f1 ]--- > > OK, this is an independent problem which, as I think, has nothing to do > with the first one. > > I do not know why crc32 oopses on your system. You need to investigate > this. I believe this is not UBI/UBIFS's fault. > > One theory could be that UBI uses vmalloc'ed buffers for the atomic > update operation, and submits the buffer to the MTD layer for the I/O. > If your NAND driver is trying to DMA this memory, you may be in trouble, > because vmalloced memory is often not DMA-able on many systems, > especially ARM systems which do not have coherent cache support. Hmmm ... bit stuck then !?! I've added some debug in ubi_eba_atomic_leb_change(), to simply show the values being passed to crc32(), and the crc is being called several times with the same buff memory pointer and a size of 2048 bytes. But there's also a call to crc with a size of 122880 bytes, and that's when the oops occurs. Is this size larger than the allocated buffer ? Regards Mark J. --- # mount -o remount,rw / [ 24.609350] UBIFS: start fixing up free space [ 24.613979] uffs 1 [ 24.616098] ffs 1 [ 24.618138] ffs 2 [ 24.620250] fl 1 : lnum = 1, len = 2048 [ 24.624740] fl 2 [ 24.627010] uealc crc32 : d08cb000 2048 [ 24.631153] uealc crc_x [ 24.636597] fl 1 : lnum = 2, len = 2048 [ 24.641048] fl 2 [ 24.643019] uealc crc32 : d08cb000 2048 [ 24.647088] uealc crc_x [ 24.650789] ffs 3 [ 24.652881] ffs 4 [ 24.654911] fl 1 : lnum = 3, len = 2048 [ 24.659316] fl 2 [ 24.661278] uealc crc32 : d08cb000 2048 [ 24.665336] uealc crc_x [ 24.672101] ffs 5 [ 24.674146] fl 1 : lnum = 7, len = 2048 [ 24.678543] fl 2 [ 24.680505] uealc crc32 : d08cb000 2048 [ 24.684574] uealc crc_x [ 24.688744] ffs 6 [ 24.690801] ffs 7 [ 24.692831] ffs 7a : lnum = 10 [ 24.696386] ffs 7b [ 24.698560] ffs 7c [ 24.700682] ffs 7a : lnum = 11 [ 24.703901] ffs 7b [ 24.706019] ffs 7c [ 24.708137] ffs 7a : lnum = 12 [ 24.711384] ffs 7b [ 24.713503] ffs 7c [ 24.715622] ffs 7d : c->leb_size = 126976, lprops->free = 4096 [ 24.7218
Re: [PATCH v2] USB: ehci-s5p: Fix phy reset
On 14.03.2013, at 05:19, Thomas Abraham wrote:
> On 14 March 2013 05:29, Alexander Graf wrote:
>> On my Exynos 5 based Arndale system, I need to pull the reset line down
>> and then let it go up again to actually perform a reset. Without that
>> reset, I can't find any USB hubs on my bus, rendering the USB controller
>> useless.
>>
>> We also only need to reset the line after the phy node has been found.
>> This way we don't accidently reserve the vbus GPIO pin, but later on
>> defer the creation of our controller, because the phy device tree node
>> hasn't been probed yet.
>>
>> This patch implements the above logic, making EHCI and OHCI work on
>> Arndale systems for me.
>>
>> Signed-off-by: Alexander Graf
>> CC: Vivek Gautam
>> CC: Jingoo Han
>> CC: Alan Stern
>> CC: Kukjin Kim
>> CC: Felipe Balbi
>> CC: Greg Kroah-Hartman
>> CC: Doug Anderson
>>
>> ---
>>
>> v1 -> v2:
>>
>> - remove gpio_free call
>> - move reset logic after phy node search
>>
>> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
>> index 20ebf6a..b29b2b8 100644
>> --- a/drivers/usb/host/ehci-s5p.c
>> +++ b/drivers/usb/host/ehci-s5p.c
>> @@ -103,9 +103,14 @@ static void s5p_setup_vbus_gpio(struct platform_device
>> *pdev)
>>if (!gpio_is_valid(gpio))
>>return;
>>
>> - err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
>> - if (err)
>> + /* reset pulls the line down, then up again */
>> + err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio");
>> + if (err) {
>>dev_err(&pdev->dev, "can't request ehci vbus gpio %d", gpio);
>> + return;
>> + }
>> + mdelay(1);
>> + __gpio_set_value(gpio, 1);
>> }
>>
>> static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
>> @@ -131,8 +136,6 @@ static int s5p_ehci_probe(struct platform_device *pdev)
>>if (!pdev->dev.coherent_dma_mask)
>>pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>
>> - s5p_setup_vbus_gpio(pdev);
>> -
>>s5p_ehci = devm_kzalloc(&pdev->dev, sizeof(struct s5p_ehci_hcd),
>>GFP_KERNEL);
>>if (!s5p_ehci)
>> @@ -152,6 +155,8 @@ static int s5p_ehci_probe(struct platform_device *pdev)
>>s5p_ehci->otg = phy->otg;
>>}
>>
>> + s5p_setup_vbus_gpio(pdev);
>> +
>>s5p_ehci->dev = &pdev->dev;
>>
>>hcd = usb_create_hcd(&s5p_ehci_hc_driver, &pdev->dev,
>
> Hi Alexander,
>
> This change, though it works for Exynos5250 based Arndale board, does
> not actually seem correct. On Arndale board, the on-board 4-port usb
> hub is self powered and hence the vbus 'enable' gpio line from
> Exynos5250 SoC is instead used as a "reset" signal for the on-board
> usb hub (and not as the vbus enable signal).
>
> Whereas, the driver uses the gpio used in 's5p_setup_vbus_gpio'
> function as just a mechanism to enable vbus for downstream devices. So
> the driver should not be modified as above to handle the board
> specific behavior.
>
> Instead, what needs to be done is, remove the "samsung,vbus-gpio"
> property from the usb2.0 node in dts files (this property is optional)
> for Arndale board. Then, during the machine_init, perform the reset
> sequencing as required.
>
> Ideally, the reset sequencing for the on-board AX88760 usb hub should
> have been handled in the driver for this device. I have not checked if
> there is a driver for this in the kernel.
I can see your point, but as I mentioned earlier there seems to be some timing
issue here. By simply doing the reset a few ms earlier (in the first probe,
before the driver detects that it needs to defer probing), I already can't find
the hub on the bus later.
So I'm assuming that the same thing would also happen if I put it even earlier
in machine init.
The change in this patch actually does a reset even on non-Arndale boards. By
taking away power and returning power to the line, the chip will most likely
have reset :). So even on non-Arndale boards, this should get the USB phy into
a clean state regardless of where the bootloader left it, right?
Alex
--
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] sched,trace: Allow tracing the preemption decision on wakeup
On Thu, 2013-03-14 at 10:48 +0100, Peter Zijlstra wrote:
> Thomas noted that we do the wakeup preemption check after the wakeup
> trace point, this means the tracepoint cannot test/report this decision;
> which is rather important for latency sensitive workloads. Therefore
> move the tracepoint after doing the preemption check.
>
> Suggested-by: Thomas Gleixner
> Signed-off-by: Peter Zijlstra
Acked-by: Steven Rostedt
> ---
> kernel/sched/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b36635e..849deb9 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1288,8 +1288,8 @@ static void ttwu_activate(struct rq *rq, struct
> task_struct *p, int en_flags)
> static void
> ttwu_do_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
> {
> - trace_sched_wakeup(p, true);
> check_preempt_curr(rq, p, wake_flags);
> + trace_sched_wakeup(p, true);
>
> p->state = TASK_RUNNING;
> #ifdef CONFIG_SMP
>
--
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 v8 07/12] gpio: palmas: add in GPIO support for palmas charger
On 13/03/13 14:15, Linus Walleij wrote:
Sorry for slow replies :-(
On Thu, Mar 7, 2013 at 2:17 PM, Ian Lartey wrote:
+static int palmas_gpio_read(struct palmas *palmas, unsigned int reg,
+ int gpio, unsigned int *dest)
I don't like "int gpio" here, please use "int offset".
This is not a global GPIO number, it is an offset in the local gpio_chip,
right?
Correct.
+{
+ /* registers for second bank are identical and offset by 0x9 */
+ if (gpio > 7)
+ reg += PALMAS_GPIO_DATA_IN2;
+
+ return palmas_read(palmas, PALMAS_GPIO_BASE, reg, dest);
+}
+
+static int palmas_gpio_write(struct palmas *palmas, unsigned int reg,
+ int gpio, unsigned int data)
+{
+ /* registers for second bank are identical and offset by 0x9 */
+ if (gpio > 7)
+ reg += PALMAS_GPIO_DATA_IN2;
+
+ return palmas_write(palmas, PALMAS_GPIO_BASE, reg, data);
+}
+
+static int palmas_gpio_update_bits(struct palmas *palmas, unsigned int reg,
+ int gpio, unsigned int mask, unsigned int data)
+{
+ /* registers for second bank are identical and offset by 0x9 */
+ if (gpio > 7)
+ reg += PALMAS_GPIO_DATA_IN2;
+
+ return palmas_update_bits(palmas, PALMAS_GPIO_BASE, reg, mask, data);
+}
- ret = palmas_read(palmas, PALMAS_GPIO_BASE, PALMAS_GPIO_DATA_IN, &val);
+ ret = palmas_gpio_read(palmas, PALMAS_GPIO_DATA_IN, offset, &val);
(Obviously you are passing the offset.)
+ ret = palmas_gpio_write(palmas, PALMAS_GPIO_SET_DATA_OUT,
+ offset, BIT(offset % 8));
(..)
+ ret = palmas_gpio_write(palmas, PALMAS_GPIO_CLEAR_DATA_OUT,
+ offset, BIT(offset % 8));
(...)
+ ret = palmas_gpio_update_bits(palmas, PALMAS_GPIO_DATA_DIR,
+ offset, 1 << (offset % 8), 1 << (offset % 8));
Why aren't you using the BIT() macro here too?
Further: if these functions are always used like this, with offset
and some BIT() or (1 << (offset % 8)) why don't you move that
latter part into the static helper and just pass offset into the
helper?
Good points - I missed the other bit shifts.
Yours,
Linus Walleij
Thanks
Ian
--
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 v2] wait while adding MMC host to ensure root mounts
On 14/03/13 08:08, Namjae Jeon wrote:> 2013/3/14, Sergey Yanovich : Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Have you ever tried to use rootwait or rootdelay on command line ? If no, You can use them. Those options work. However, they introduce a delay in the range of hundreds milliseconds and seconds respectively. They delay is not required. If a cards is present, mmc_rescan will return synchronously with card initialized. prepare_namespace() uses wait_for_device_probe(). The latter assumes that all "known devices" have initialized by the time it returns. MMC is not currently delivering on the assumptions. It will with the patch applied. -- 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] x84: reenable DEBUG_TLBFLUSH for X86_32
s/x84:/x86:/ in summary, of course. Paul Bolle -- 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] x84: reenable DEBUG_TLBFLUSH for X86_32
CONFIG_INVLPG got removed in commit
094ab1db7cb7833cd4c820acd868fc26acf3f08e ("x86, 386 removal: Remove
CONFIG_INVLPG"). That commit left one instance of CONFIG_INVLPG
untouched, effectively disabling DEBUG_TLBFLUSH for X86_32. Since all
currently supported X86 CPU's should now be able to support that option,
just drop the entire sub-dependency.
Signed-off-by: Paul Bolle
---
0) Untested! This needs testing by the subsection of people running
DEBUG_TLBFLUSH on X86_32. I'm not in that subsection.
1) I actually wonder whether this check was needed in the first place.
It seems that the code depending on CONFIG_DEBUG_TLBFLUSH in
arch/x86/mm/tlb.c was actually safe to be called on any X86 CPU, since
it used to test for cpu_has_invlpg. But none of that matters anymore.
arch/x86/Kconfig.debug | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index b322f12..16f7383 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -131,7 +131,7 @@ config DOUBLEFAULT
config DEBUG_TLBFLUSH
bool "Set upper limit of TLB entries to flush one-by-one"
- depends on DEBUG_KERNEL && (X86_64 || X86_INVLPG)
+ depends on DEBUG_KERNEL
---help---
X86-only for now.
--
1.7.11.7
--
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 -tip v2 1/2] [BUGFIX] kprobes: make hash_64() as always inlined
Because hash_64() is called from the get_kprobe() inside
int3 handler, kernel causes int3 recursion and crashes if
kprobes user puts a probe on it.
Usually hash_64() is inlined into caller function, but in
some cases, it has instances by gcc's interprocedural
constant propagation.
This patch uses __always_inline instead of inline to
prevent gcc from doing such things.
Changes in v2:
- Use __always_inline instead of using __kprobes
Signed-off-by: Masami Hiramatsu
Reported-by: Timo Juhani Lindfors
Cc: "David S. Miller"
Cc: Nadia Yvette Chambers
Cc: Pavel Emelyanov
Cc: Jiri Kosina
Cc: Ananth N Mavinakayanahalli
Cc: Ingo Molnar
Cc: Linus Torvalds
---
include/linux/hash.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/hash.h b/include/linux/hash.h
index 61c97ae..f09a0ae 100644
--- a/include/linux/hash.h
+++ b/include/linux/hash.h
@@ -15,6 +15,7 @@
*/
#include
+#include
/* 2^31 + 2^29 - 2^25 + 2^22 - 2^19 - 2^16 + 1 */
#define GOLDEN_RATIO_PRIME_32 0x9e370001UL
@@ -31,7 +32,7 @@
#error Wordsize not 32 or 64
#endif
-static inline u64 hash_64(u64 val, unsigned int bits)
+static __always_inline u64 hash_64(u64 val, unsigned int bits)
{
u64 hash = val;
--
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 -tip v2 2/2] [BUGFIX] kprobes/x86: Check Interrupt Flag modifier when registering probe
Currently kprobes check whether the copied instruction modifies
IF (interrupt flag) on each probe hit. This means not only
introducing overhead but also involving inat_get_opcode_attribute
into kprobes hot path, and it can cause an infinit recursive
call (and kernel panic in the end).
Actually, since the copied instruction itself never be modified
on the buffer, it is needless to analyze the instruction every
probe hit.
To fix this issue, we checks it only once when registering probe
and store the result on ainsn->if_modifier.
Signed-off-by: Masami Hiramatsu
Reported-by: Timo Juhani Lindfors
Cc: "David S. Miller"
Cc: Ananth N Mavinakayanahalli
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Steven Rostedt
Cc: Linus Torvalds
---
arch/x86/include/asm/kprobes.h |1 +
arch/x86/kernel/kprobes/core.c |5 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kprobes.h b/arch/x86/include/asm/kprobes.h
index d3ddd17..5a6d287 100644
--- a/arch/x86/include/asm/kprobes.h
+++ b/arch/x86/include/asm/kprobes.h
@@ -77,6 +77,7 @@ struct arch_specific_insn {
* a post_handler or break_handler).
*/
int boostable;
+ bool if_modifier;
};
struct arch_optimized_insn {
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 3f06e61..7bfe318 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -375,6 +375,9 @@ static void __kprobes arch_copy_kprobe(struct kprobe *p)
else
p->ainsn.boostable = -1;
+ /* Check whether the instruction modifies Interrupt Flag or not */
+ p->ainsn.if_modifier = is_IF_modifier(p->ainsn.insn);
+
/* Also, displacement change doesn't affect the first byte */
p->opcode = p->ainsn.insn[0];
}
@@ -434,7 +437,7 @@ static void __kprobes set_current_kprobe(struct kprobe *p,
struct pt_regs *regs,
__this_cpu_write(current_kprobe, p);
kcb->kprobe_saved_flags = kcb->kprobe_old_flags
= (regs->flags & (X86_EFLAGS_TF | X86_EFLAGS_IF));
- if (is_IF_modifier(p->ainsn.insn))
+ if (p->ainsn.if_modifier)
kcb->kprobe_saved_flags &= ~X86_EFLAGS_IF;
}
--
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/
makedumpfile: benchmark on mmap() with /proc/vmcore
Hello, I did benchmark makedumpfile performance with mmap() on /proc/vmcore on 32GB memory system. Even smaller than terabytes memory, it's possible to see performance improvement precisely to some amount. However, it's definitely necessary to see how performance is changed on terabyte-class memory system. Of course, I'll do it and I'm reserving the system now, but it's restricted on 2TB memory system. If anyone wants to see performance on more memory system, please help. In summary, this benchmark shows the improvement from 4.5 seconds to 0.6 seconds for filtering processing on 32GB memory. Roughly, this corresponds to 19.2 seconds on 1TB memory. = Machine spec - CPU: Intel(R) Xeon(R) CPU E7- 4820 @ 2.00GHz (4 sockets, 8 cores) (*) - memory: 32GB - vmcore size: 31.7GB - kernel - 3.9-rc1 with the patch set in: http://lists.infradead.org/pipermail/kexec/2013-March/008092.html - 3.8.2-206.fc18.x86_64 for makedumpfile v1.5.1 - kexec tools: commit: 53bb3029557936ed12960e7cc2619a20ee7d382b # v2.0.4-rc1 failed to be compiled. (*) only 1 cpu is used in the 2nd kernel now. = Makedumpfile I used the following three versions of makedumpfile: - v1.5.1 - cyclic mode + free pages filtering on mem_map array was introduced. - v1.5.2 - 8-slot cache was introduced - v1.5.2-map: git map branch - mmap() on /proc/vmcore. - To use mmap, specify --map-size option. = How to measure I collected time contained in makedumpfile's report message as follows: $ makedumpfile --message-level 31 -p -d 31 /proc/vmcore vmcore-pd31 ... STEP [Checking for memory holes ] : 0.163673 seconds STEP [Excluding unnecessary pages] : 1.321702 seconds STEP [Excluding free pages ] : 0.489022 seconds STEP [Copying data ] : 26.221380 seconds The message starting with "STEP [Excluding" corresponds to the message of filtering processing. - STEP [Excluding unnecessary pages] corresponds to the time for mem_map array logic. - STEP [Excluding free pages ] corresponds to the time for free list logic. I didn't collect times for other two messages here. The message is displayed multiple times in cyclic mode, exactly the same number of cycles. But note that throughout this benchmark, the number of cycles is 1. Much more memory system must need more cycles. = Benchmark Result v1.5.1 | cyclic| non-cyclic| non-cyclic | | unnecessary pages | unnecessary pages | free pages | |---+---+| | 4.618960 | 4.443426 | 1.058048 | v1.5.2 | cyclic| non-cyclic| non-cyclic | | unnecessary pages | unnecessary pages | free pages | |---+---+| | 1.438702 | 1.321702 | 0.489022 | v1.5.2 with mmap | map size |cyclic |non-cyclic | non-cyclic | |(KiB) | unnecessary pages | unnecessary pages | free pages | |--+---+---+| |4 | 1.319516 | 1.171109 | 0.247905 | |8 | 0.977871 | 0.847379 | 0.253978 | | 16 | 0.798567 | 0.676428 | 0.261278 | | 32 | 0.712903 | 0.576884 | 0.267791 | | 64 | 0.660195 | 0.544579 | 0.266696 | | 128 | 0.635026 | 0.503244 | 0.279830 | | 256 | 0.618651 | 0.486801 | 0.304053 | | 512 | 0.612802 | 0.479643 | 0.350388 | | 1024 | 0.606328 | 0.480465 | 0.434638 | | 2048 | 0.604407 | 0.473270 | 0.555480 | | 4096 | 0.602786 | 0.471901 | 0.745003 | | 8192 | 0.598396 | 0.468123 | 1.264968 | |16384 | 0.598102 | 0.467604 | 2.604322 | |32768 | 0.597832 | 0.469231 | 5.336002 | = Discussion - From v1.5.2 to v1.5.1, simple 8-slot cache mechanism was introduced. By this, access time to /proc/vmcore for paging is reduced from about 4.5 to about 1.5. - On v1.5.2 with mmap: if map size is 4KB, the perforamce looks similar to v1.5.2's ioremap case. If large enough map size is specified, there's no longer pernalty due to TLB flush caused by ioremap/iounmap from access to /proc/vmcore. - In non-cyclic mode, it takes about 0.5 second to filter a whole mem_map array. - In cyclic mode, it takes about 0.6 second to filter a whole mem_map array. What is the additional 0.1 second compared to the one in non-cyclic mode? One of the reasons is that in cyclic mode, filtering processing includes the case for free pages in addition to other kind of memory. That is, it's part the below: makedumpfile.c:__exclude_unnecessary_pages /* * Exclude the free page managed by a buddy */ if ((info->dump_level & DL_EXCLUDE_FREE) && info->fla
Re: [PATCH 2/3] pwm: pwm-tiecap: Add device-tree binding support for da850 SOC
On 3/14/2013 4:02 PM, Philip Avinash wrote:
> ECAP IP is used in da850 SOC's also. Hence adds ECAP device tree binding
> support for da850.
>
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Rob Landley
> Signed-off-by: Philip Avinash
> ---
> :100644 100644 131e8c1... fcbd3c1... M
> Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
> :100644 100644 22e96e2... e0d96c8... Mdrivers/pwm/pwm-tiecap.c
> .../devicetree/bindings/pwm/pwm-tiecap.txt |2 +-
> drivers/pwm/pwm-tiecap.c |1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
> b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
> index 131e8c1..fcbd3c1 100644
> --- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
> +++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
> @@ -1,7 +1,7 @@
> TI SOC ECAP based APWM controller
>
> Required properties:
> -- compatible: Must be "ti,am33xx-ecap"
> +- compatible: Must be "ti,am33xx-ecap" or "ti,da850-ecap"
> - #pwm-cells: Should be 3. Number of cells being used to specify PWM
> property.
>First cell specifies the per-chip index of the PWM to use, the second
>cell is the period in nanoseconds and bit 0 in the third cell is used to
> diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
> index 22e96e2..e0d96c8 100644
> --- a/drivers/pwm/pwm-tiecap.c
> +++ b/drivers/pwm/pwm-tiecap.c
> @@ -197,6 +197,7 @@ static const struct pwm_ops ecap_pwm_ops = {
>
> static const struct of_device_id ecap_of_match[] = {
> { .compatible = "ti,am33xx-ecap" },
> + { .compatible = "ti,da850-ecap" },
> {},
You add a new compatible, but don't really show any changes in driver in
this series. So why can't we simply use ti,am33xx-ecap on DA850 too?
Thanks,
Sekhar
--
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 00/44] ldisc patchset
On Thu, 2013-03-14 at 00:25 -0700, Michel Lespinasse wrote: > On Wed, Mar 13, 2013 at 6:12 PM, Peter Hurley > wrote: > > On Wed, 2013-03-13 at 04:36 -0700, Michel Lespinasse wrote: > >> Have you considered building your ldlock based on lib/rwsem-spinlock.c > >> instead ? i.e. having an internal spinlock to protect the ldisc > >> reference count and the reader and writer queues. This would seem much > >> simpler get right. The downside would be that a spinlock would be > >> taken for a short time whenever an ldisc reference is taken or > >> released. I don't expect that the internal spinlock would get > >> significant contention ? > > > > That would have been too easy :) > > > > TBH, I hadn't considered it until I was most the way through a working > > atomic version. I had already split the reader/writer wait lists. And > > figured out how to always use the wait bias for every waiting reader and > > writer -- rather than the rwsem way of testing for an empty list -- > > which made the timeout handling easier. > > > > At the time, the only thing that I was still struggling with was > > recursion, and the spinlock flavor wasn't going to fix that. So I just > > kept with the atomic flavor. > > Its not too late to run away from it and preserve your sanity (as well > as that of the next person working on the tty layer :) The long-term plan is to migrate it to lib so it won't be a maintenance burden to tty. -- 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/12] rwsem: wake all readers when first waiter is a reader
On Thu, 2013-03-14 at 00:03 -0700, Michel Lespinasse wrote:
> On Mon, Mar 11, 2013 at 04:36:47PM -0400, Peter Hurley wrote:
> >
> > On Wed, 2013-03-06 at 15:21 -0800, Michel Lespinasse wrote:
> > > + retry_reader_grants:
> > > + oldcount = rwsem_atomic_update(adjustment, sem) - adjustment;
> > > + if (unlikely(oldcount < RWSEM_WAITING_BIAS)) {
> > > + /* A writer stole the lock. Undo our reader grants. */
> > > + if (rwsem_atomic_update(-adjustment, sem) < RWSEM_WAITING_BIAS)
> > > + goto out;
> > > + /* The writer left. Retry waking readers. */
> > > + goto retry_reader_grants;
> > > + }
> >
> > This can be reduced to single looping cmpxchg in the grant reversal
> > path; then if reversing the grant fails, the count can simply be
> > re-tested for grant success, rather than trying to atomically re-grant.
> > For example, with a helper function, rwsem_cmpxchg():
> >
> > static inline int rwsem_cmpxchg(long *old, long new, struct rw_semaphore
> > *sem)
> > {
> > long tmp = *old;
> > *old = cmpxchg(&sem->count, *old, new);
> > return tmp == *old;
> > }
> >
> > ... then above becomes ...
> >
> > count = rwsem_atomic_update(adjustment, sem);
> > do {
> > if (count - adjustment >= RWSEM_WAITING_BIAS)
> > break;
> > if (rwsem_cmpxchg(&count, count - adjustment, sem))
> > goto out; /* or simply return sem */
> > } while (1);
> >
> > < wake up readers >
>
> This would work, but I don't see a benefit as we still end up with a
> retry loop. Also, the loop would have to retry whenever the counter
> value changed instead of only when writer(s) appear or are removed.
It's a minor optimization in that, while the count is unstable, this CPU
will stay here and while it does so, it's only inflicting one bus lock
rather than two. Feel free to ignore it.
> > Also, this series and the original rwsem can mistakenly sleep reader(s)
> > when the lock is transitioned from writer-owned to waiting readers-owned
> > with no waiting writers. For example,
> >
> >
> > CPU 0 | CPU 1
> > |
> > | down_write()
> >
> > ... CPU 1 has the write lock for the semaphore.
> > Meanwhile, 1 or more down_read(s) are attempted and fail;
> > these are put on the wait list.
>
> I'm not sure of the relevance of these other down_read() calls -
> please note that as these extra readers are put on the wait list,
> their +read_bias adjustments are canceled so that the count value
> ends up at write_bias + waiting_bias (for a total active count of 1)
The relevance of the waiting readers is that when CPU 1 drops the writer
___and grabs the spin lock___, it then wakes up these already-waiting
readers (CPU 0 is still parked in down_read_failed() waiting to acquire
the spin lock).
When CPU 1 wakes up these readers, the sem count goes > 0 and the
waiting list is emptied. CPU 1 then drops the spin lock and leaves
up_write().
CPU 0 has been spinning on the wait_lock during this time. It now
acquires the lock, and discovers the wait list is empty and ups the
adjustment(+wait bias). The count is already (+ # of waiting readers) so
it never does the wake up.
> > Then ...
> >
> > down_read() | up_write()
> > local = atomic_update(+read_bias) |
> > local <= 0? | local = atomic_update(-write_bias)
> > if (true) | local < 0?
> > down_read_failed() | if (true)
> > | wake()
> > | grab wait_lock
> > wait for wait_lock| wake all readers
> > | release wait_lock
> >
> > ... At this point, sem->count > 0 and the wait list is empty,
> > but down_read_failed() will sleep the reader.
> >
> > In this case, CPU 0 has observed the sem count with the write lock (and
> > the other waiters) and so is detoured to down_read_failed(). But if
> > CPU 0 can't grab the wait_lock before the up_write() does (via
> > rwsem_wake()), then down_read_failed() will wake no one and sleep the
> > reader.
>
> Actually - down_read_failed() will insert the reader on the wait_list
> and do an atomic update(-read_bias). If there are no active lockers at
> the time of that atomic update, it calls __rwsem_do_wake() to unqueued
> the first queued waiter - which may well be itself.
>
> In your specific example, __rwsem_do_wake() will wake the previously queued
> readers as well as current.
Hopefully my comments above make it clear that there are no queued
readers once CPU 0 can advance with the spin lock in down_read_failed().
> > Unfortunately, this means readers and writers which observe the sem
> > count after the adjustment is committed by CPU 0 in down_re
Re: [PATCH 1/3] pwm: davinci: Add Kconfig support for ECAP & EHRPWM devices
On 3/14/2013 4:02 PM, Philip Avinash wrote: > Add EHRPWM and ECAP support build support for DAVINCI_DA850 platforms. > > Also, since DAVINCI platforms doesn't support TI-PWM-Subsystem module, > remove the select option for CONFIG_PWM_TIPWMSS. > > Also, update CONFIG_PWM_TIPWMSS compiler directive appropriately in > pwm-tipwmss.h to fix the below compiler error upon removal of > CONFIG_PWM_TIPWMSS for Davinci platforms. > > drivers/pwm/pwm-tiecap.c: In function 'ecap_pwm_probe': > drivers/pwm/pwm-tiecap.c:263:4: error: 'PWMSS_ECAPCLK_EN' undeclared > (first use in this function) > drivers/pwm/pwm-tiecap.c:263:4: note: each undeclared identifier > is reported only once for each function it appears in > drivers/pwm/pwm-tiecap.c:264:17: error: 'PWMSS_ECAPCLK_EN_ACK' > undeclared (first use in this function) > drivers/pwm/pwm-tiecap.c: In function 'ecap_pwm_remove': > drivers/pwm/pwm-tiecap.c:291:49: error: 'PWMSS_ECAPCLK_STOP_REQ' > undeclared (first use in this function) > make[2]: *** [drivers/pwm/pwm-tiecap.o] Error 1 > make[1]: *** [drivers/pwm] Error 2 > make: *** [drivers] Error 2 > > Signed-off-by: Philip Avinash > config PWM_TIECAP > tristate "ECAP PWM support" > - depends on SOC_AM33XX > - select PWM_TIPWMSS > + depends on SOC_AM33XX || ARCH_DAVINCI_DA850 Having such narrow dependencies is wrong. The same device is present on DaVinci DA830 too. A depends on should not be required at all since the driver should build on all architectures. But I have seen resistance to doing that since users don't like to see configuration options totally irrelevant for the architecture they are building for. So may be take a middle path and do 'depends on ARCH_ARM'? Thanks, Sekhar -- 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 v3] mm/hugetlb: fix total hugetlbfs pages count when memory overcommit accouting
Changelog:
v2 -> v3:
* update patch description, spotted by Michal
v1 -> v2:
* update patch description, spotted by Michal
"hugetlb_total_pages is used for overcommit calculations but the
current implementation considers only default hugetlb page size (which
is either the first defined hugepage size or the one specified by
default_hugepagesz kernel boot parameter).
If the system is configured for more than one hugepage size (which is
possible since a137e1cc hugetlbfs: per mount huge page sizes) then
the overcommit estimation done by __vm_enough_memory (resp. shown by
meminfo_proc_show) is not precise - there is an impression of more
available/allowed memory. This can lead to an unexpected ENOMEM/EFAULT
resp. SIGSEGV when memory is accounted."
The patch should also push to 2.6.27 stable tree.
Testcase:
boot: hugepagesz=1G hugepages=1
the default overcommit ratio is 50
before patch:
egrep 'CommitLimit' /proc/meminfo
CommitLimit: 55434168 kB
after patch:
egrep 'CommitLimit' /proc/meminfo
CommitLimit: 54909880 kB
Signed-off-by: Wanpeng Li
---
mm/hugetlb.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index cdb64e4..9e25040 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2124,8 +2124,11 @@ int hugetlb_report_node_meminfo(int nid, char *buf)
/* Return the number pages of memory we physically have, in PAGE_SIZE units. */
unsigned long hugetlb_total_pages(void)
{
- struct hstate *h = &default_hstate;
- return h->nr_huge_pages * pages_per_huge_page(h);
+ struct hstate *h;
+ unsigned long nr_total_pages = 0;
+ for_each_hstate(h)
+ nr_total_pages += h->nr_huge_pages * pages_per_huge_page(h);
+ return nr_total_pages;
}
static int hugetlb_acct_memory(struct hstate *h, long delta)
--
1.7.11.7
--
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 2/3] leds: add camera LED triggers
Some LED devices support flash/torch functionality through the LED subsystem.
This patch enables direct LED trigger controls by the driver.
Flash on/off and torch on/off can be done simply by other driver space.
Two trigger APIs are added, ledtrig_flash_ctrl() and ledtrig_torch_ctrl().
Signed-off-by: Milo(Woogyom) Kim
---
drivers/leds/trigger/Kconfig |8 +
drivers/leds/trigger/Makefile |1 +
drivers/leds/trigger/ledtrig-camera.c | 57 +
include/linux/leds.h |8 +
4 files changed, 74 insertions(+)
create mode 100644 drivers/leds/trigger/ledtrig-camera.c
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index eaa286d..49794b4 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -100,4 +100,12 @@ config LEDS_TRIGGER_TRANSIENT
GPIO/PWM based hardware.
If unsure, say Y.
+config LEDS_TRIGGER_CAMERA
+ tristate "LED Camera Flash/Torch Trigger"
+ depends on LEDS_TRIGGERS
+ help
+ This allows LEDs to be controlled as a camera flash/torch device.
+ This enables direct flash/torch on/off by the driver, kernel space.
+ If unsure, say Y.
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 554e46e..1abf48d 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_LEDS_TRIGGER_GPIO) += ledtrig-gpio.o
obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o
obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o
obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
+obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
diff --git a/drivers/leds/trigger/ledtrig-camera.c
b/drivers/leds/trigger/ledtrig-camera.c
new file mode 100644
index 000..9bd73a8
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-camera.c
@@ -0,0 +1,57 @@
+/*
+ * Camera Flash and Torch On/Off Trigger
+ *
+ * based on ledtrig-ide-disk.c
+ *
+ * Copyright 2013 Texas Instruments
+ *
+ * Author: Milo(Woogyom) Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+DEFINE_LED_TRIGGER(ledtrig_flash);
+DEFINE_LED_TRIGGER(ledtrig_torch);
+
+void ledtrig_flash_ctrl(bool on)
+{
+ enum led_brightness brt = on ? LED_FULL : LED_OFF;
+
+ led_trigger_event(ledtrig_flash, brt);
+}
+EXPORT_SYMBOL_GPL(ledtrig_flash_ctrl);
+
+void ledtrig_torch_ctrl(bool on)
+{
+ enum led_brightness brt = on ? LED_FULL : LED_OFF;
+
+ led_trigger_event(ledtrig_torch, brt);
+}
+EXPORT_SYMBOL_GPL(ledtrig_torch_ctrl);
+
+static int __init ledtrig_camera_init(void)
+{
+ led_trigger_register_simple("flash", &ledtrig_flash);
+ led_trigger_register_simple("torch", &ledtrig_torch);
+ return 0;
+}
+module_init(ledtrig_camera_init);
+
+static void __exit ledtrig_camera_exit(void)
+{
+ led_trigger_unregister_simple(ledtrig_torch);
+ led_trigger_unregister_simple(ledtrig_flash);
+}
+module_exit(ledtrig_camera_exit);
+
+MODULE_DESCRIPTION("LED Trigger for Camera Flash/Torch Control");
+MODULE_AUTHOR("Milo Kim");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 2d8c0b4..0287ab2 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -218,6 +218,14 @@ extern void ledtrig_ide_activity(void);
static inline void ledtrig_ide_activity(void) {}
#endif
+#if defined(CONFIG_LEDS_TRIGGER_CAMERA) ||
defined(CONFIG_LEDS_TRIGGER_CAMERA_MODULE)
+extern void ledtrig_flash_ctrl(bool on);
+extern void ledtrig_torch_ctrl(bool on);
+#else
+static inline void ledtrig_flash_ctrl(bool on) {}
+static inline void ledtrig_torch_ctrl(bool on) {}
+#endif
+
/*
* Generic LED platform data for describing LED names and default triggers.
*/
--
1.7.9.5
Best Regards,
Milo
--
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 3/3] leds: lm355x, lm3642: support camera LED triggers for flash and torch
LM355x and LM3642 support flash and torch functionality.
(Camera driver) (LED trigger for camera) (LED driver)
Turn on the flash ...> ledtrig_flash_ctrl(true) ...> LM355x or LM3642
brightness ctrl
Flash/torch LEDs are controlled by other driver using LED camera trigger
APIs, ledtrig_flash_ctrl()/ledtrig_torch_ctrl().
Then, actual device control is activated by each LED driver such like
LM355x or LM3642.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/leds/leds-lm355x.c |2 ++
drivers/leds/leds-lm3642.c |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/leds/leds-lm355x.c b/drivers/leds/leds-lm355x.c
index 4117235..d81a8e7 100644
--- a/drivers/leds/leds-lm355x.c
+++ b/drivers/leds/leds-lm355x.c
@@ -477,6 +477,7 @@ static int lm355x_probe(struct i2c_client *client,
chip->cdev_flash.name = "flash";
chip->cdev_flash.max_brightness = 16;
chip->cdev_flash.brightness_set = lm355x_strobe_brightness_set;
+ chip->cdev_flash.default_trigger = "flash";
err = led_classdev_register((struct device *)
&client->dev, &chip->cdev_flash);
if (err < 0)
@@ -486,6 +487,7 @@ static int lm355x_probe(struct i2c_client *client,
chip->cdev_torch.name = "torch";
chip->cdev_torch.max_brightness = 8;
chip->cdev_torch.brightness_set = lm355x_torch_brightness_set;
+ chip->cdev_torch.default_trigger = "torch";
err = led_classdev_register((struct device *)
&client->dev, &chip->cdev_torch);
if (err < 0)
diff --git a/drivers/leds/leds-lm3642.c b/drivers/leds/leds-lm3642.c
index 9f428d9..f361bbe 100644
--- a/drivers/leds/leds-lm3642.c
+++ b/drivers/leds/leds-lm3642.c
@@ -363,6 +363,7 @@ static int lm3642_probe(struct i2c_client *client,
chip->cdev_flash.name = "flash";
chip->cdev_flash.max_brightness = 16;
chip->cdev_flash.brightness_set = lm3642_strobe_brightness_set;
+ chip->cdev_flash.default_trigger = "flash";
err = led_classdev_register((struct device *)
&client->dev, &chip->cdev_flash);
if (err < 0) {
@@ -380,6 +381,7 @@ static int lm3642_probe(struct i2c_client *client,
chip->cdev_torch.name = "torch";
chip->cdev_torch.max_brightness = 8;
chip->cdev_torch.brightness_set = lm3642_torch_brightness_set;
+ chip->cdev_torch.default_trigger = "torch";
err = led_classdev_register((struct device *)
&client->dev, &chip->cdev_torch);
if (err < 0) {
--
1.7.9.5
Best Regards,
Milo
--
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 0/3] leds: replace macros with inline functions and support camera LED triggers
Patch v2 (1) LED trigger macros are replaced with inline function in case of !CONFIG_LED_TRIGGERS and !CONFIG_LEDS_TRIGGER_IDE_DISK. (2) Use an inline function when CONFIG_LEDS_TRIGGER_CAMERA is not configured. Patch v1 Initial patch Milo(Woogyom) Kim (3): leds: trigger: use inline functions instead of macros leds: add camera LED triggers leds: lm355x, lm3642: support camera LED triggers for flash and torch drivers/leds/leds-lm355x.c|2 ++ drivers/leds/leds-lm3642.c|2 ++ drivers/leds/trigger/Kconfig |8 + drivers/leds/trigger/Makefile |1 + drivers/leds/trigger/ledtrig-camera.c | 57 + include/linux/leds.h | 33 --- include/linux/mmc/host.h |2 -- 7 files changed, 92 insertions(+), 13 deletions(-) create mode 100644 drivers/leds/trigger/ledtrig-camera.c -- 1.7.9.5 Best Regards, Milo -- 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 1/3] leds: trigger: use inline functions instead of macros
Macros are used in case that an inline function doesn't work.
Otherwise, use an empty inline function.
(a) Case of !CONFIG_LEDS_TRIGGERS
Following macros are replaced with inline functions.
led_trigger_register_simple()
led_trigger_unregister_simple()
led_trigger_event()
To make inline types, the structure, 'led_trigger' should be defined.
This structure has no member at all.
(b) Case of !CONFIG_LEDS_TRIGGER_IDE_DISK
ledtrig_ide_activity() macro is replaced with an inline function as well.
(c) DEFINE_LED_TRIGGER() and DEFINE_LED_TRIGGER_GLOBAL()
Struct 'led_trigger' is defined both cases, with CONFIG_LEDS_TRIGGERS and
without CONFIG_LEDS_TRIGGERS.
Those macros are moved out of CONFIG_LED_TRIGGERS because of no-dependency
on CONFIG_LEDS_TRIGGERS.
(d) Fix build errors in mmc-core driver
After replacing macros with inline functions, following build errors occur.
(condition: CONFIG_LEDS_TRIGGERS is not set)
drivers/mmc/core/core.c: In function 'mmc_request_done':
drivers/mmc/core/core.c:164:25: error: 'struct mmc_host' has no member named
'led'
drivers/mmc/core/core.c: In function 'mmc_start_request':
drivers/mmc/core/core.c:254:24: error: 'struct mmc_host' has no member named
'led'
make[3]: *** [drivers/mmc/core/core.o] Error 1
The reason of these errors is non-existent member variable, 'led'.
It is only valid when CONFIG_LEDS_TRIGGERS is set.
But now, it can be used without this dependency.
To fix build errors, member 'led' is always used without its config option in
'include/linux/mmc/host.h'.
Signed-off-by: Milo(Woogyom) Kim
---
include/linux/leds.h | 25 ++---
include/linux/mmc/host.h |2 --
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 0d9b5ee..2d8c0b4 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -142,6 +142,10 @@ extern void led_set_brightness(struct led_classdev
*led_cdev,
/*
* LED Triggers
*/
+/* Registration functions for simple triggers */
+#define DEFINE_LED_TRIGGER(x) static struct led_trigger *x;
+#define DEFINE_LED_TRIGGER_GLOBAL(x) struct led_trigger *x;
+
#ifdef CONFIG_LEDS_TRIGGERS
#define TRIG_NAME_MAX 50
@@ -164,9 +168,6 @@ struct led_trigger {
extern int led_trigger_register(struct led_trigger *trigger);
extern void led_trigger_unregister(struct led_trigger *trigger);
-/* Registration functions for simple triggers */
-#define DEFINE_LED_TRIGGER(x) static struct led_trigger *x;
-#define DEFINE_LED_TRIGGER_GLOBAL(x) struct led_trigger *x;
extern void led_trigger_register_simple(const char *name,
struct led_trigger **trigger);
extern void led_trigger_unregister_simple(struct led_trigger *trigger);
@@ -199,20 +200,22 @@ extern void led_trigger_rename_static(const char *name,
#else
-/* Triggers aren't active - null macros */
-#define DEFINE_LED_TRIGGER(x)
-#define DEFINE_LED_TRIGGER_GLOBAL(x)
-#define led_trigger_register_simple(x, y) do {} while(0)
-#define led_trigger_unregister_simple(x) do {} while(0)
-#define led_trigger_event(x, y) do {} while(0)
+/* Trigger has no members */
+struct led_trigger {};
-#endif
+/* Trigger inline empty functions */
+static inline void led_trigger_register_simple(const char *name,
+ struct led_trigger **trigger) {}
+static inline void led_trigger_unregister_simple(struct led_trigger *trigger)
{}
+static inline void led_trigger_event(struct led_trigger *trigger,
+ enum led_brightness event) {}
+#endif /* CONFIG_LEDS_TRIGGERS */
/* Trigger specific functions */
#ifdef CONFIG_LEDS_TRIGGER_IDE_DISK
extern void ledtrig_ide_activity(void);
#else
-#define ledtrig_ide_activity() do {} while(0)
+static inline void ledtrig_ide_activity(void) {}
#endif
/*
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index d6f20cc..357e80e 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -341,9 +341,7 @@ struct mmc_host {
mmc_pm_flag_t pm_flags; /* requested pm features */
-#ifdef CONFIG_LEDS_TRIGGERS
struct led_trigger *led; /* activity led */
-#endif
#ifdef CONFIG_REGULATOR
boolregulator_enabled; /* regulator state */
--
1.7.9.5
Best Regards,
Milo
--
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] staging: ccg: remove two outdated dependencies
On Thu, Mar 14, 2013 at 12:09:53PM +0100, Paul Bolle wrote: > On Thu, 2013-03-14 at 13:59 +0300, Dan Carpenter wrote: > > Your patch is fine as is, but if you wanted to send a follow on > > patch to break the depend mess into separate lines, that would also > > be welcome. :) > > Well, now that you somehow managed to review this patch the urge to > clean this line up has suddenly diminished. But maybe you're lucky and > this will not pass Greg. > This CCG driver was mentioned in the latest lwn kernel page so I was just looking at it. And I looked at it for a minute or two. And then I started backing away slowly... :P regards, dan carpenter -- 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] perf, tools: Make perf stat -I ... CSV output flat
On Wed, Mar 13, 2013 at 5:56 PM, Andi Kleen wrote:
> On Wed, Mar 13, 2013 at 02:19:05PM +0100, Stephane Eranian wrote:
>> On Thu, Mar 7, 2013 at 3:43 AM, Andi Kleen wrote:
>> > From: Andi Kleen
>> >
>> > The new perf stat interval code is quite useful, especially when the
>> > data is post processed. Unfortunately the default -x, output is not
>> > very friendly to programs when it contains more than one event.
>> >
>> > Each event is printed on its own line, each keyed with the time.
>> >
>> > You cannot directly feed it to gnuplot or into R to
>> > compare different events at a specific point in time.
>> >
>> > This patch normalizes the output so that a single line contains all
>> > the events for a given time period. Each event is an own column.
>> >
>> > With that it's quite easy to do plots and other analysis,
>> > as this is the normalized format many data processing programs expect.
>> >
>> > This is not fully normalized yet, as per cpu counts also
>> > end up on the same line (fixing this would be more intrusive)
>> > But good enough for most purposes.
>> >
>> > The non CSV output is not changed.
>> >
>> > Example:
>> >
>> > $ perf stat -o /tmp/x.csv -I 100 -x, bc <<< 2^40 > /dev/null
>> > $ gnuplot
>> > gnuplot> set datafile separator ","
>> > gnuplot> set terminal dumb
>> > gnuplot> plot "/tmp/x.csv" every ::3 using 1:3
>> >
>> > 110
>> > +++-+-++-+-+++
>> > + + +"/tmp/x.csv" every ::3 using 1:3 A
>> > +
>> > 100 ++ AAAAAAAA AAAA
>> > ++
>> >90 ++
>> > ++
>> > |
>> > |
>> >80 ++
>> > ++
>> > |
>> > |
>> >70 ++
>> > ++
>> > |
>> > |
>> >60 ++
>> > ++
>> >50 ++
>> > ++
>> > |
>> > |
>> >40 ++
>> > ++
>> > |
>> > |
>> >30 ++
>> > ++
>> > |
>> > |
>> >20 ++
>> > ++
>> >10 ++
>> > ++
>> > + + + ++ + +A
>> > +
>> > 0
>> > +++-+-++-+-+++
>> > 0.2 0.4 0.6 0.8 11.2 1.4
>> > 1.6
>> >
>> > Cc: eran...@google.com
>> > ---
>> > tools/perf/builtin-stat.c | 118
>> > +++--
>> > 1 files changed, 82 insertions(+), 36 deletions(-)
>> >
>> > diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
>> > index e6f4d1d..81d704a 100644
>> > --- a/tools/perf/builtin-stat.c
>> > +++ b/tools/perf/builtin-stat.c
>> > @@ -66,8 +66,10 @@
>> > #define CNTR_NOT_COUNTED ""
>> >
>> > static void print_stat(int argc, const char **argv);
>> > -static void print_counter_aggr(struct perf_evsel *counter, char *prefix);
>> > -static void print_counter(struct perf_evsel *counter, char *prefix);
>> > +static void print_counter_aggr(struct perf_evsel *counter, char *prefix,
>> > int delim,
>> > + int name);
>> > +static void print_counter(struct perf_evsel *counter, char *prefix, int
>> > delim,
>> > + int name);
>> > static void print_aggr_socket(char *prefix);
>> >
>> > /* Default events used for perf stat -T */
>> > @@ -343,6 +345,7 @@ static void print_interval(void)
>> > struct perf_stat *ps;
>> > struct timespec ts, rs;
>> > char prefix[64];
>> > + int delim = '\n';
>> >
>> > if (no_aggr) {
>> > list_for_each_entry(counter, &evsel_list->entries, node) {
>> > @@ -373,15 +376,23 @@ static void print_interval(void)
>> > if (++num_print_interval == 25)
>> > num_print_interval = 0;
>> >
>> > + if (csv_output) {
>> > + delim = ',';
>> > + fprintf(output, "%s,", prefix);
>> > + prefix[0] = 0;
>> > + }
>> > +
>> > if (aggr_socket)
>> > print_aggr_socket(prefix);
>> > else if (no_aggr) {
Re: linux-next: manual merge of the signal tree with the modules tree
On 14/03/13 06:27, Stephen Rothwell wrote:
> Hi Al,
>
> Today's linux-next merge of the signal tree got a conflict in
> include/asm-generic/unistd.h between commit 837718bfd28b
> ("CONFIG_SYMBOL_PREFIX: cleanup") from the modules tree and commit
> e1b5bb6d1236 ("consolidate cond_syscall and SYSCALL_ALIAS declarations")
> from the signal tree.
>
> The latter moved the cond_syscall stuff to linkage.h, so I applied the
> following patch as a merge fixup and can carry the fix as necessary (no
> action is required). I am not sure if this is completely correct or all
> that is needed.
FYI, I've tested that symbol prefix stuff works on linux-next for metag
(after fixes applied from Rusty's latest symbol prefix patch).
Al: your signal tree still breaks symbol prefixed arches due to stuff
like this in kernel/sys_ni.i:
asm(".weak\t" "CONFIG_SYMBOL_PREFIXsys_quotactl" "\n\t.set\t"
"CONFIG_SYMBOL_PREFIXsys_quotactl" ","
"CONFIG_SYMBOL_PREFIXsys_ni_syscall");;
Cheers
James
signature.asc
Description: OpenPGP digital signature
Re: MTD : Kernel oops when remounting ubifs as read/write
On Thu, 2013-03-14 at 11:15 +, Mark Jackson wrote: > [ 28.538525] [d08ea004] *pgd=8f045811, *pte=, *ppte= > [ 28.545173] Internal error: Oops: 7 [#1] ARM > [ 28.549685] CPU: 0Not tainted > (3.8.0-next-20130225-2-g678576f-dirty #40) > [ 28.557595] PC is at crc32_le+0x50/0x168 > [ 28.561735] LR is at ubi_eba_atomic_leb_change+0x1b4/0x410 > [ 28.567523] pc : []lr : []psr: 2013 > [ 28.567523] sp : cf385de0 ip : 180a985a fp : c054f840 > [ 28.579632] r10: c054f040 r9 : c054fc40 r8 : 158a1232 > [ 28.585141] r7 : 4d506705 r6 : 9324fd72 r5 : 4dc8a10b r4 : 4c162691 > [ 28.592025] r3 : c054e040 r2 : c054f440 r1 : d08ea000 r0 : 4c8ee09f > [ 28.598912] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment > user > [ 28.606439] Control: 10c5387d Table: 8f3b8019 DAC: 0015 > [ 28.612501] Process mount (pid: 659, stack limit = 0xcf384238) > [ 28.618652] Stack: (0xcf385de0 to 0xcf386000) > [ 28.623254] 5de0: cf2f8554 d08e6e8c 180a9e88 5a257c4f 58399ee9 > c8d98a08 bb0ee864 > [ 28.631886] 5e00: eae10678 c054fc40 c054f040 c054f840 cf2f8000 > d08caffc 3c00 > [ 28.640517] 5e20: cf2f8000 cf357c00 000c cf2ec000 > 000c cf2f8554 > [ 28.649148] 5e40: d08cb000 0001e000 d08cb000 8000 > 0001e000 > [ 28.657779] 5e60: 000c d08cb000 0080 000c 000c > 0020 > [ 28.666409] 5e80: 8000 c026c41c 0001e000 cf33 cf33 d08cb000 > 0001e000 c0179b14 > [ 28.675042] 5ea0: 000d c0177a68 0001e000 cf33 cf330b20 > 000d c0179698 > [ 28.683672] 5ec0: cf33 cf330a9c cf385f48 c0175170 > 0001 6013 > [ 28.692303] 5ee0: cf32c800 cf385f48 > 0020 c00c9e24 > [ 28.700934] 5f00: 00100100 00200200 cf3a6c80 8000 cf384000 00208020 > cf01a200 > [ 28.709564] 5f20: cf32c800 c00e3d6c 000c cf32c840 > c0013968 cf31fb80 > [ 28.718195] 5f40: 000c cf01a210 ce828858 000c cf3ac000 > 000a18b4 > [ 28.726827] 5f60: 00208020 c0013968 cf384000 0003 c00e3e40 > c0071e24 > [ 28.735459] 5f80: cf31fb80 cf31fbc0 a010 > bed87b68 b6ff148c > [ 28.744091] 5fa0: 0015 c00137c0 bed87b68 000a18b4 000a18c0 > 000a18c2 00208020 > [ 28.752720] 5fc0: bed87b68 b6ff148c 0015 > 0003 > [ 28.761350] 5fe0: b6fa3f48 bed87a64 00042994 b6fa3f58 a010 000a18b4 > > [ 28.769989] [] (crc32_le+0x50/0x168) from [] > (0xcf2f8000) > [ 28.777522] Code: e58d8008 0a26 e1a0c005 e58d2004 (e5916004) > [ 28.784029] ---[ end trace f50f53afffe647f1 ]--- OK, this is an independent problem which, as I think, has nothing to do with the first one. I do not know why crc32 oopses on your system. You need to investigate this. I believe this is not UBI/UBIFS's fault. One theory could be that UBI uses vmalloc'ed buffers for the atomic update operation, and submits the buffer to the MTD layer for the I/O. If your NAND driver is trying to DMA this memory, you may be in trouble, because vmalloced memory is often not DMA-able on many systems, especially ARM systems which do not have coherent cache support. -- Best Regards, Artem Bityutskiy -- 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] caif: remove caif_shm
On Fri, 2013-03-08 at 10:56 +0100, Erwan Yvin wrote:
> caif_shm is an old implementation
And it has been unbuildable since release v3.5, due to commit
29746f48d1b2e903b23daf8cc951fcb47ff0110e ("ARM: ux500: delete U5500
support").
> caif_shm will be replaced by caif_virtio
>
> Signed-off-by: Erwan Yvin
> Acked-by: Sjur Brendeland
Paul Bolle
--
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: MTD : Kernel oops when remounting ubifs as read/write
On 14/03/13 10:30, Artem Bityutskiy wrote:
> On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote:
>> On 14/03/13 09:13, Artem Bityutskiy wrote:
>>> On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
Sorry ... this just locks up the unit.
>>>
>>> OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
>>> below. The patch I proposed did not get the error path correctly, but it
>>> does fix the issue.
>>>
>>> I think what you treat as "lockup" is the fixup process. UBIFS basically
>>> reads the entire UBI volume and writes it back. And it uses the atomic
>>> change UBI service, which means it also calculates CRC of everything it
>>> writes. And this all just takes a lot of time. This has to be done only
>>> once on the first mount.
>>
>> Okay ... I've retried, but how long is "a lot of time" ?
>>
>> I've waited 15 minutes and still nothing.
>>
>> And I can see that there's no activity on the NAND chip select !?!
>>
>> I'll put some debug info into the fixup routines to see if I can trace
>> what's going on.
>
> Just to make sure - try this last patch I sent. I did test it with
> nandsim at least, and I am sure it works. I did not test at all the
> first one.
>
> And yes, debug messages would be useful, just do not forget to add the
> 'ignore_loglevel' kernel boot option, otherwise you won't see the
> messages on your console, since they are of KERN_DEBUG level.
>
> You may have other issues which cause lockup, e.g., in driver level. It
> makes sense to validate your flash with MTD test modules.
My first initial findings ...
I added some simple printk(KERN_INFO) lines to fixup_free_space(), and when
I remount, it gets as far as:-
printk(KERN_INFO "ffs 7\n");
/* Fixup LEBs in the main area */
for (lnum = c->main_first; lnum < c->leb_cnt; lnum++) {
lprops = ubifs_lpt_lookup(c, lnum);
if (IS_ERR(lprops)) {
err = PTR_ERR(lprops);
goto out;
}
if (lprops->free > 0) {
err = fixup_leb(c, lnum, c->leb_size - lprops->free);
if (err)
goto out;
}
}
out:
printk(KERN_INFO "ffs x\n");
ubifs_release_lprops(c);
return err;
}
... before we get an oops with crc32_le(). See the full log below.
I'll keep digging ...
Regards
Mark J.
---
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-next-20130225-2-g678576f-dirty
(mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #40 Thu Mar 14
10:58:28 GMT 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI
AM335x BeagleBone
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c059c7b0, node_mem_map
c0ac6000
[0.00] Normal zone: 512 pages used for memmap
[0.00] Normal zone: 0 pages reserved
[0.00] Normal zone: 65280 pages, LIFO batch:15
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 64768
[0.00] Kernel command line: console=ttyO0,115200n8 noinitrd ip=off
mem=256M rootwait=1 ubi.mtd=6,2048 rootfstype=ubifs root=ubi0:rootfs
ignore_loglevel
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Memory: 255MB = 255MB total
[0.00] Memory: 247768k/247768k available, 14376k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB)
[0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB)
[0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[0.00] .text : 0xc0008000 - 0xc05194ac (5190 kB)
[0.00] .init : 0xc051a000 - 0xc054bfbc ( 200 kB)
[0.00] .data : 0xc054c000 - 0xc059d360 ( 325 kB)
[0.00].bss : 0xc059d360 - 0xc0ac21a0 (5268 kB)
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
interrupts
[0.00] Total of 128 interrupts on 1 active controller
[0.00] OMAP clockevent sou
Re: [PATCH 1/9] vfs: add i_op->dentry_open()
On Wed, Mar 13, 2013 at 11:44 PM, Andrew Morton
wrote:
> On Wed, 13 Mar 2013 15:16:25 +0100 Miklos Szeredi wrote:
>
>> From: Miklos Szeredi
>>
>> Add a new inode operation i_op->dentry_open(). This is for stacked
>> filesystems
>> that want to return a struct file from a different filesystem.
>>
>> ...
>>
>> +/**
>> + * vfs_open - open the file at the given path
>> + * @path: path to open
>> + * @filp: newly allocated file with f_flag initialized
>> + * @cred: credentials to use
>> + */
>> +int vfs_open(const struct path *path, struct file *filp,
>> + const struct cred *cred)
>> +{
>> + struct inode *inode = path->dentry->d_inode;
>> +
>> + if (inode->i_op->dentry_open)
>> + return inode->i_op->dentry_open(path->dentry, filp, cred);
>> + else {
>> + filp->f_path = *path;
>> + return do_dentry_open(filp, NULL, cred);
>> + }
>> +}
>
> This looks like it will add some overhead to dentry_open(). That long
> walk path->dentry->d_inode->i_op->dentry_open, particularly. Can we do
> anything? Using filp->f_inode might save a tad.
filp->f_inode is initialized in do_dentry_open. But we can move that
to callers.
Adding an IOP_DENTRY_OPEN flag should take care of the rest.
> It's unfortunate and a bit ugly that ->dentry_open() and
> do_dentry_open() don't have the same arguments. One would expect and
> like them to do so, and this difference raises suspicions about design
> warts.
Hmm, the basic reason for the difference is that filesystems should
not have access to the vfsmount part of the path.
Otherwise it would be trivial to make them match up.
>
> If they _did_ have the same signature then we could perhaps populate
> ->dentry_open with do_dentry_open by default and avoid the `if'.
Except there's no way to add a default i_op, AFAIK.
>
> The test of inode->i_op->dentry_open could do with an unlikely(), but
> that won't save us :(
>
>> +EXPORT_SYMBOL(vfs_open);
>
> Did you consider EXPORT_SYMBOL_GPL()?
It is not clear to me what to base that decision on. Either one is fine by me.
Thanks,
Miklos
--
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 EDAC] i7300_edac: Fix memory detection in single mode
When the machine is on single mode, only branch 0 channel 0
is valid. However, the code is not honouring it:
[ 1952.639341] EDAC DEBUG: i7300_get_mc_regs: Memory controller operating on
single mode
...
[ 1952.639351] EDAC DEBUG: i7300_init_csrows: AMB-present CH0 = 0x1:
[ 1952.639353] EDAC DEBUG: i7300_init_csrows: AMB-present CH1 = 0x0:
[ 1952.639355] EDAC DEBUG: i7300_init_csrows: AMB-present CH2 = 0x0:
[ 1952.639358] EDAC DEBUG: i7300_init_csrows: AMB-present CH3 = 0x0:
...
[ 1952.639360] EDAC DEBUG: decode_mtr: MTR0 CH0: DIMMs are Present (mtr)
[ 1952.639362] EDAC DEBUG: decode_mtr: WIDTH: x8
[ 1952.639363] EDAC DEBUG: decode_mtr: ELECTRICAL THROTTLING is enabled
[ 1952.639364] EDAC DEBUG: decode_mtr: NUMBANK: 4 bank(s)
[ 1952.639366] EDAC DEBUG: decode_mtr: NUMRANK: single
[ 1952.639367] EDAC DEBUG: decode_mtr: NUMROW: 16,384 - 14 rows
[ 1952.639368] EDAC DEBUG: decode_mtr: NUMCOL: 1,024 - 10 columns
[ 1952.639370] EDAC DEBUG: decode_mtr: SIZE: 512 MB
[ 1952.639371] EDAC DEBUG: decode_mtr: ECC code is 8-byte-over-32-byte
SECDED+ code
[ 1952.639373] EDAC DEBUG: decode_mtr: Scrub algorithm for x8 is on
enhanced mode
[ 1952.639374] EDAC DEBUG: decode_mtr: MTR0 CH1: DIMMs are Present (mtr)
[ 1952.639376] EDAC DEBUG: decode_mtr: WIDTH: x8
[ 1952.639377] EDAC DEBUG: decode_mtr: ELECTRICAL THROTTLING is enabled
[ 1952.639379] EDAC DEBUG: decode_mtr: NUMBANK: 4 bank(s)
[ 1952.639380] EDAC DEBUG: decode_mtr: NUMRANK: single
[ 1952.639381] EDAC DEBUG: decode_mtr: NUMROW: 16,384 - 14 rows
[ 1952.639383] EDAC DEBUG: decode_mtr: NUMCOL: 1,024 - 10 columns
[ 1952.639384] EDAC DEBUG: decode_mtr: SIZE: 512 MB
[ 1952.639385] EDAC DEBUG: decode_mtr: ECC code is 8-byte-over-32-byte
SECDED+ code
[ 1952.639387] EDAC DEBUG: decode_mtr: Scrub algorithm for x8 is on
enhanced mode
...
[ 1952.639449] EDAC DEBUG: print_dimm_size: channel 0 | channel 1
| channel 2 | channel 3 |
[ 1952.639451] EDAC DEBUG: print_dimm_size:
-
[ 1952.639453] EDAC DEBUG: print_dimm_size: csrow/SLOT 0 512 MB | 512 MB
|0 MB |0 MB |
[ 1952.639456] EDAC DEBUG: print_dimm_size: csrow/SLOT 1 0 MB |0 MB
|0 MB |0 MB |
[ 1952.639458] EDAC DEBUG: print_dimm_size: csrow/SLOT 2 0 MB |0 MB
|0 MB |0 MB |
[ 1952.639460] EDAC DEBUG: print_dimm_size: csrow/SLOT 3 0 MB |0 MB
|0 MB |0 MB |
[ 1952.639462] EDAC DEBUG: print_dimm_size: csrow/SLOT 4 0 MB |0 MB
|0 MB |0 MB |
[ 1952.639464] EDAC DEBUG: print_dimm_size: csrow/SLOT 5 0 MB |0 MB
|0 MB |0 MB |
[ 1952.639466] EDAC DEBUG: print_dimm_size: csrow/SLOT 6 0 MB |0 MB
|0 MB |0 MB |
[ 1952.639468] EDAC DEBUG: print_dimm_size: csrow/SLOT 7 0 MB |0 MB
|0 MB |0 MB |
[ 1952.639470] EDAC DEBUG: print_dimm_size:
-
Instead of detecting a single memory at channel 0, it is showing
twice the memory.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/edac/i7300_edac.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/edac/i7300_edac.c b/drivers/edac/i7300_edac.c
index 087c27b..9004c64 100644
--- a/drivers/edac/i7300_edac.c
+++ b/drivers/edac/i7300_edac.c
@@ -750,15 +750,23 @@ static int i7300_init_csrows(struct mem_ctl_info *mci)
struct i7300_dimm_info *dinfo;
int rc = -ENODEV;
int mtr;
- int ch, branch, slot, channel;
+ int ch, branch, slot, channel, max_channel, max_branch;
struct dimm_info *dimm;
pvt = mci->pvt_info;
edac_dbg(2, "Memory Technology Registers:\n");
+ if (IS_SINGLE_MODE(pvt->mc_settings_a)) {
+ max_branch = 1;
+ max_channel = 1;
+ } else {
+ max_branch = MAX_BRANCHES;
+ max_channel = MAX_CH_PER_BRANCH;
+ }
+
/* Get the AMB present registers for the four channels */
- for (branch = 0; branch < MAX_BRANCHES; branch++) {
+ for (branch = 0; branch < max_branch; branch++) {
/* Read and dump branch 0's MTRs */
channel = to_channel(0, branch);
pci_read_config_word(pvt->pci_dev_2x_0_fbd_branch[branch],
@@ -767,6 +775,9 @@ static int i7300_init_csrows(struct mem_ctl_info *mci)
edac_dbg(2, "\t\tAMB-present CH%d = 0x%x:\n",
channel, pvt->ambpresent[channel]);
+ if (max_channel == 1)
+ continue;
+
channel = to_channel(1, branch);
pci_read_config_word(pvt->pci_dev_2x_0_fbd_branch[branch],
AMBPRESENT
Re: [PATCH] staging: ccg: remove two outdated dependencies
On Thu, 2013-03-14 at 13:59 +0300, Dan Carpenter wrote: > Your patch is fine as is, but if you wanted to send a follow on > patch to break the depend mess into separate lines, that would also > be welcome. :) Well, now that you somehow managed to review this patch the urge to clean this line up has suddenly diminished. But maybe you're lucky and this will not pass Greg. > Reviewed-by: Dan Carpenter Thanks. Paul Bolle -- 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] mm/hugetlb: fix total hugetlbfs pages count when memory overcommit accouting
On Thu 14-03-13 18:49:49, Wanpeng Li wrote:
> Changelog:
> v1 -> v2:
> * update patch description, spotted by Michal
>
> hugetlb_total_pages() does not account for all the supported hugepage
> sizes.
> This can lead to incorrect calculation of the total number of
> page frames used by hugetlb. This patch corrects the issue.
Sorry to be so picky but this doesn't tell us much. Why do we need to
have the total number of hugetlb pages?
What about the following:
"hugetlb_total_pages is used for overcommit calculations but the
current implementation considers only default hugetlb page size (which
is either the first defined hugepage size or the one specified by
default_hugepagesz kernel boot parameter).
If the system is configured for more than one hugepage size (which is
possible since a137e1cc hugetlbfs: per mount huge page sizes) then
the overcommit estimation done by __vm_enough_memory (resp. shown by
meminfo_proc_show) is not precise - there is an impression of more
available/allowed memory. This can lead to an unexpected ENOMEM/EFAULT
resp. SIGSEGV when memory is accounted."
I think this is also worth pushing to the stable tree (it goes back to
2.6.27)
> Testcase:
> boot: hugepagesz=1G hugepages=1
> before patch:
> egrep 'CommitLimit' /proc/meminfo
> CommitLimit: 55434168 kB
> after patch:
> egrep 'CommitLimit' /proc/meminfo
> CommitLimit: 54909880 kB
This gives some more confusion to a reader because there is only
something like 500M difference here without any explanation.
>
> Signed-off-by: Wanpeng Li
> ---
> mm/hugetlb.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index cdb64e4..9e25040 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2124,8 +2124,11 @@ int hugetlb_report_node_meminfo(int nid, char *buf)
> /* Return the number pages of memory we physically have, in PAGE_SIZE units.
> */
> unsigned long hugetlb_total_pages(void)
> {
> - struct hstate *h = &default_hstate;
> - return h->nr_huge_pages * pages_per_huge_page(h);
> + struct hstate *h;
> + unsigned long nr_total_pages = 0;
> + for_each_hstate(h)
> + nr_total_pages += h->nr_huge_pages * pages_per_huge_page(h);
> + return nr_total_pages;
> }
>
> static int hugetlb_acct_memory(struct hstate *h, long delta)
> --
> 1.7.11.7
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
Michal Hocko
SUSE Labs
--
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 02/88] nfsd: Fix memleak
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: majianpeng commit 2d32b29a1c2830f7c42caa8258c714acd983961f upstream. When free nfs-client, it must free the ->cl_stateids. Signed-off-by: Jianpeng Ma Signed-off-by: J. Bruce Fields Signed-off-by: Luis Henriques --- fs/nfsd/nfs4state.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index 6ca92b1..c4daf96 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -1090,6 +1090,8 @@ free_client(struct nfs4_client *clp) } free_svc_cred(&clp->cl_cred); kfree(clp->cl_name.data); + idr_remove_all(&clp->cl_stateids); + idr_destroy(&clp->cl_stateids); kfree(clp); } -- 1.8.1.2 -- 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 03/88] iommu/amd: Initialize device table after dma_ops
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Joerg Roedel
commit f528d980c17b8714aedc918ba86e058af914d66b upstream.
When dma_ops are initialized the unity mappings are
created. The init_device_table_dma() function makes sure DMA
from all devices is blocked by default. This opens a short
window in time where DMA to unity mapped regions is blocked
by the IOMMU. Make sure this does not happen by initializing
the device table after dma_ops.
Signed-off-by: Joerg Roedel
Signed-off-by: Shuah Khan
Signed-off-by: Luis Henriques
---
drivers/iommu/amd_iommu_init.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index eadc6b5..9e5096a 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -1572,9 +1572,6 @@ int __init amd_iommu_init_hardware(void)
if (amd_iommu_pd_alloc_bitmap == NULL)
goto free;
- /* init the device table */
- init_device_table();
-
/*
* let all alias entries point to itself
*/
@@ -1655,6 +1652,7 @@ out:
*/
static int __init amd_iommu_init(void)
{
+ struct amd_iommu *iommu;
int ret = 0;
ret = amd_iommu_init_hardware();
@@ -1673,6 +1671,12 @@ static int __init amd_iommu_init(void)
if (ret)
goto free;
+ /* init the device table */
+ init_device_table();
+
+ for_each_iommu(iommu)
+ iommu_flush_all_caches(iommu);
+
amd_iommu_init_api();
x86_platform.iommu_shutdown = disable_iommus;
--
1.8.1.2
--
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 05/88] target: Add missing mapped_lun bounds checking during make_mappedlun setup
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Bellinger
commit fbbf8555a986ed31e54f006b6cc637ea4ff1425b upstream.
This patch adds missing bounds checking for the configfs provided
mapped_lun value during target_fabric_make_mappedlun() setup ahead
of se_lun_acl initialization.
This addresses a potential OOPs when using a mapped_lun value that
exceeds the hardcoded TRANSPORT_MAX_LUNS_PER_TPG-1 value within
se_node_acl->device_list[].
Reported-by: Jan Engelhardt
Cc: Jan Engelhardt
Signed-off-by: Nicholas Bellinger
Signed-off-by: Luis Henriques
---
drivers/target/target_core_fabric_configfs.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/target/target_core_fabric_configfs.c
b/drivers/target/target_core_fabric_configfs.c
index c42143b..8b07a88 100644
--- a/drivers/target/target_core_fabric_configfs.c
+++ b/drivers/target/target_core_fabric_configfs.c
@@ -358,6 +358,14 @@ static struct config_group *target_fabric_make_mappedlun(
ret = -EINVAL;
goto out;
}
+ if (mapped_lun > (TRANSPORT_MAX_LUNS_PER_TPG-1)) {
+ pr_err("Mapped LUN: %lu exceeds TRANSPORT_MAX_LUNS_PER_TPG"
+ "-1: %u for Target Portal Group: %u\n", mapped_lun,
+ TRANSPORT_MAX_LUNS_PER_TPG-1,
+ se_tpg->se_tpg_tfo->tpg_get_tag(se_tpg));
+ ret = -EINVAL;
+ goto out;
+ }
lacl = core_dev_init_initiator_node_lun_acl(se_tpg, se_nacl,
mapped_lun, &ret);
--
1.8.1.2
--
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 01/88] omap_vout: find_vma() needs ->mmap_sem held
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Al Viro
commit 55ee64b30a38d688232e5eb2860467dddc493573 upstream.
Walking rbtree while it's modified is a Bad Idea(tm); besides,
the result of find_vma() can be freed just as it's getting returned
to caller. Fortunately, it's easy to fix - just take ->mmap_sem a bit
earlier (and don't bother with find_vma() at all if virtp >= PAGE_OFFSET -
in that case we don't even look at its result).
While we are at it, what prevents VIDIOC_PREPARE_BUF calling
v4l_prepare_buf() -> (e.g) vb2_ioctl_prepare_buf() -> vb2_prepare_buf() ->
__buf_prepare() -> __qbuf_userptr() -> vb2_vmalloc_get_userptr() -> find_vma(),
AFAICS without having taken ->mmap_sem anywhere in process? The code flow
is bloody convoluted and depends on a bunch of things done by initialization,
so I certainly might've missed something...
Signed-off-by: Al Viro
Cc: Sakari Ailus
Cc: Laurent Pinchart
Cc: Archit Taneja
Cc: Prabhakar Lad
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Luis Henriques
---
drivers/media/video/omap/omap_vout.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 88cf9d9..89f354e 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -206,19 +206,21 @@ static u32 omap_vout_uservirt_to_phys(u32 virtp)
struct vm_area_struct *vma;
struct mm_struct *mm = current->mm;
- vma = find_vma(mm, virtp);
/* For kernel direct-mapped memory, take the easy way */
- if (virtp >= PAGE_OFFSET) {
- physp = virt_to_phys((void *) virtp);
- } else if (vma && (vma->vm_flags & VM_IO) && vma->vm_pgoff) {
+ if (virtp >= PAGE_OFFSET)
+ return virt_to_phys((void *) virtp);
+
+ down_read(¤t->mm->mmap_sem);
+ vma = find_vma(mm, virtp);
+ if (vma && (vma->vm_flags & VM_IO) && vma->vm_pgoff) {
/* this will catch, kernel-allocated, mmaped-to-usermode
addresses */
physp = (vma->vm_pgoff << PAGE_SHIFT) + (virtp - vma->vm_start);
+ up_read(¤t->mm->mmap_sem);
} else {
/* otherwise, use get_user_pages() for general userland pages */
int res, nr_pages = 1;
struct page *pages;
- down_read(¤t->mm->mmap_sem);
res = get_user_pages(current, current->mm, virtp, nr_pages, 1,
0, &pages, NULL);
--
1.8.1.2
--
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 07/88] btrfs: Init io_lock after cloning btrfs device struct
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 1cba0cdf5e4dbcd9e5fa5b54d7a028e55e2ca057 upstream. __btrfs_close_devices() clones btrfs device structs with memcpy(). Some of the fields in the clone are reinitialized, but it's missing to init io_lock. In mainline this goes unnoticed, but on RT it leaves the plist pointing to the original about to be freed lock struct. Initialize io_lock after cloning, so no references to the original struct are left. Reported-and-tested-by: Mike Galbraith Signed-off-by: Thomas Gleixner Signed-off-by: Chris Mason Signed-off-by: Luis Henriques --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 037e0bb..2208f0f 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -575,6 +575,7 @@ static int __btrfs_close_devices(struct btrfs_fs_devices *fs_devices) new_device->writeable = 0; new_device->in_fs_metadata = 0; new_device->can_discard = 0; + spin_lock_init(&new_device->io_lock); list_replace_rcu(&device->dev_list, &new_device->dev_list); call_rcu(&device->rcu, free_device); -- 1.8.1.2 -- 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 14/88] ARM: fix scheduling while atomic warning in alignment handling code
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Russell King
commit b255188f90e2bade1bd11a986dd1ca4861869f4d upstream.
Paolo Pisati reports that IPv6 triggers this warning:
BUG: scheduling while atomic: swapper/0/0/0x4100
Modules linked in:
[] (unwind_backtrace+0x0/0xf0) from []
(__schedule_bug+0x48/0x5c)
[] (__schedule_bug+0x48/0x5c) from []
(__schedule+0x700/0x740)
[] (__schedule+0x700/0x740) from []
(__cond_resched+0x24/0x34)
[] (__cond_resched+0x24/0x34) from []
(_cond_resched+0x3c/0x44)
[] (_cond_resched+0x3c/0x44) from []
(do_alignment+0x178/0x78c)
[] (do_alignment+0x178/0x78c) from []
(do_DataAbort+0x34/0x98)
[] (do_DataAbort+0x34/0x98) from [] (__dabt_svc+0x40/0x60)
Exception stack(0xc0763d70 to 0xc0763db8)
3d60: e97e805e e97e806e 2c00 1100
3d80: ea86bb00 002c 0011 e97e807e c076d2a8 e97e805e e97e806e 002c
3da0: 3d00 c0763dbc c04b98fc c02a8490 0113
[] (__dabt_svc+0x40/0x60) from []
(__csum_ipv6_magic+0x8/0xc8)
Fix this by using probe_kernel_address() stead of __get_user().
Reported-by: Paolo Pisati
Tested-by: Paolo Pisati
Signed-off-by: Russell King
Signed-off-by: Luis Henriques
---
arch/arm/mm/alignment.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 9107231..fc000e3 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -750,7 +750,6 @@ do_alignment(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
unsigned long instr = 0, instrptr;
int (*handler)(unsigned long addr, unsigned long instr, struct pt_regs
*regs);
unsigned int type;
- mm_segment_t fs;
unsigned int fault;
u16 tinstr = 0;
int isize = 4;
@@ -761,16 +760,15 @@ do_alignment(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
instrptr = instruction_pointer(regs);
- fs = get_fs();
- set_fs(KERNEL_DS);
if (thumb_mode(regs)) {
- fault = __get_user(tinstr, (u16 *)(instrptr & ~1));
+ u16 *ptr = (u16 *)(instrptr & ~1);
+ fault = probe_kernel_address(ptr, tinstr);
if (!fault) {
if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
IS_T32(tinstr)) {
/* Thumb-2 32-bit */
u16 tinst2 = 0;
- fault = __get_user(tinst2, (u16 *)(instrptr+2));
+ fault = probe_kernel_address(ptr + 1, tinst2);
instr = (tinstr << 16) | tinst2;
thumb2_32b = 1;
} else {
@@ -779,8 +777,7 @@ do_alignment(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
}
}
} else
- fault = __get_user(instr, (u32 *)instrptr);
- set_fs(fs);
+ fault = probe_kernel_address(instrptr, instr);
if (fault) {
type = TYPE_FAULT;
--
1.8.1.2
--
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 15/88] doc, xen: Mention 'earlyprintk=xen' in the documentation.
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: Konrad Rzeszutek Wilk commit 2482a92e7d17187301d7313cfe5021b13393a0b4 upstream. The earlyprintk for Xen PV guests utilizes a simple hypercall (console_io) to provide output to Xen emergency console. Note that the Xen hypervisor should be booted with 'loglevel=all' to output said information. Reported-by: H. Peter Anvin Signed-off-by: Konrad Rzeszutek Wilk Link: http://lkml.kernel.org/r/1361825650-14031-2-git-send-email-konrad.w...@oracle.com Signed-off-by: H. Peter Anvin Signed-off-by: Luis Henriques --- Documentation/kernel-parameters.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index a92c5eb..65f25d7 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -760,6 +760,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. earlyprintk=[X86,SH,BLACKFIN] earlyprintk=vga + earlyprintk=xen earlyprintk=serial[,ttySn[,baudrate]] earlyprintk=ttySn[,baudrate] earlyprintk=dbgp[debugController#] @@ -777,6 +778,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. The VGA output is eventually overwritten by the real console. + The xen output can only be used by Xen PV guests. + ekgdboc=[X86,KGDB] Allow early kernel console debugging ekgdboc=kbd -- 1.8.1.2 -- 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 16/88] doc, kernel-parameters: Document 'console=hvc'
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: Konrad Rzeszutek Wilk commit a2fd6419174470f5ae6383f5037d0ee21ed9833f upstream. Both the PowerPC hypervisor and Xen hypervisor can utilize the hvc driver. Cc: Greg KH Signed-off-by: Konrad Rzeszutek Wilk Link: http://lkml.kernel.org/r/1361825650-14031-3-git-send-email-konrad.w...@oracle.com Signed-off-by: H. Peter Anvin Signed-off-by: Luis Henriques --- Documentation/kernel-parameters.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 65f25d7..912785c 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -570,6 +570,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. UART at the specified I/O port or MMIO address, switching to the matching ttyS device later. The options are the same as for ttyS, above. + hvc Use the hypervisor console device . This is for + both Xen and PowerPC hypervisors. If the device connected to the port is not a TTY but a braille device, prepend "brl," before the device type, for instance -- 1.8.1.2 -- 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 17/88] sony-laptop: fully enable SNY controlled modems
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: Mattia Dongili commit 3ec1c3983d73b1e3d4cfd72afab94c34eceafe8a upstream. The call to handlers 0x124 and 0x135 (rfkill control) seems to take a bitmask to control various states of the device. For our rfkill we need a fully on/off. SVZ1311Z9R/X's LTE modem needs more bits up. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47751 Signed-off-by: Mattia Dongili Signed-off-by: Matthew Garrett Signed-off-by: Luis Henriques --- drivers/platform/x86/sony-laptop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c index d4a6172..edbb51f 100644 --- a/drivers/platform/x86/sony-laptop.c +++ b/drivers/platform/x86/sony-laptop.c @@ -1528,7 +1528,7 @@ static int sony_nc_rfkill_set(void *data, bool blocked) int argument = sony_rfkill_address[(long) data] + 0x100; if (!blocked) - argument |= 0x03; + argument |= 0x07; return sony_call_snc_handle(sony_rfkill_handle, argument, &result); } -- 1.8.1.2 -- 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 19/88] cifs: ensure that cifs_get_root() only traverses directories
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Jeff Layton
commit ce2ac52105aa663056dfc17966ebed1bf93e6e64 upstream.
Kjell Braden reported this oops:
[ 833.211970] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 833.212816] IP: [< (null)>] (null)
[ 833.213280] PGD 1b9b2067 PUD e9f7067 PMD 0
[ 833.213874] Oops: 0010 [#1] SMP
[ 833.214344] CPU 0
[ 833.214458] Modules linked in: des_generic md4 nls_utf8 cifs vboxvideo drm
snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi
snd_seq_midi_event snd_seq bnep rfcomm snd_timer bluetooth snd_seq_device ppdev
snd vboxguest parport_pc joydev mac_hid soundcore snd_page_alloc psmouse
i2c_piix4 serio_raw lp parport usbhid hid e1000
[ 833.215629]
[ 833.215629] Pid: 1752, comm: mount.cifs Not tainted
3.0.0-rc7-bisectcifs-fec11dd9a0+ #18 innotek GmbH VirtualBox/VirtualBox
[ 833.215629] RIP: 0010:[<>] [< (null)>]
(null)
[ 833.215629] RSP: 0018:8800119c9c50 EFLAGS: 00010282
[ 833.215629] RAX: a02186c0 RBX: 88000c427780 RCX:
[ 833.215629] RDX: RSI: 88000c427780 RDI: 88000c4362e8
[ 833.215629] RBP: 8800119c9c88 R08: 88001fc15e30 R09: d69515c7
[ 833.215629] R10: a0201972 R11: 88000e8f6a28 R12: 88000c4362e8
[ 833.215629] R13: R14: R15: 88001181aaa6
[ 833.215629] FS: 7f2986171700() GS:88001fc0()
knlGS:
[ 833.215629] CS: 0010 DS: ES: CR0: 8005003b
[ 833.215629] CR2: CR3: 1b982000 CR4: 06f0
[ 833.215629] DR0: DR1: DR2:
[ 833.215629] DR3: DR6: 0ff0 DR7: 0400
[ 833.215629] Process mount.cifs (pid: 1752, threadinfo 8800119c8000, task
88001c1c16f0)
[ 833.215629] Stack:
[ 833.215629] 8116a9b5 8800119c9c88 81178075
0286
[ 833.215629] 88000c4276c0 8800119c9ce8
8800119c9cc8
[ 833.215629] 8116b06e 88001bc6fc00 88000c4276c0
88000c4276c0
[ 833.215629] Call Trace:
[ 833.215629] [] ? d_alloc_and_lookup+0x45/0x90
[ 833.215629] [] ? d_lookup+0x35/0x60
[ 833.215629] [] __lookup_hash.part.14+0x9e/0xc0
[ 833.215629] [] lookup_one_len+0x146/0x1e0
[ 833.215629] [] ? _raw_spin_lock+0xe/0x20
[ 833.215629] [] cifs_do_mount+0x26d/0x500 [cifs]
[ 833.215629] [] mount_fs+0x43/0x1b0
[ 833.215629] [] vfs_kern_mount+0x6a/0xd0
[ 833.215629] [] do_kern_mount+0x54/0x110
[ 833.215629] [] do_mount+0x262/0x840
[ 833.215629] [] ? __get_free_pages+0xe/0x50
[ 833.215629] [] ? copy_mount_options+0x3a/0x180
[ 833.215629] [] sys_mount+0x8d/0xe0
[ 833.215629] [] system_call_fastpath+0x16/0x1b
[ 833.215629] Code: Bad RIP value.
[ 833.215629] RIP [< (null)>] (null)
[ 833.215629] RSP
[ 833.215629] CR2:
[ 833.238525] ---[ end trace ec00758b8d44f529 ]---
When walking down the path on the server, it's possible to hit a
symlink. The path walking code assumes that the caller will handle that
situation properly, but cifs_get_root() isn't set up for it. This patch
prevents the oops by simply returning an error.
A better solution would be to try and chase the symlinks here, but that's
fairly complicated to handle.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=53221
Reported-and-tested-by: Kjell Braden
Signed-off-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Luis Henriques
---
fs/cifs/cifsfs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index 8b6e344..745c306 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -567,6 +567,11 @@ cifs_get_root(struct smb_vol *vol, struct super_block *sb)
dentry = ERR_PTR(-ENOENT);
break;
}
+ if (!S_ISDIR(dir->i_mode)) {
+ dput(dentry);
+ dentry = ERR_PTR(-ENOTDIR);
+ break;
+ }
/* skip separators */
while (*s == sep)
--
1.8.1.2
--
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 20/88] iscsi-target: Fix immediate queue starvation regression with DATAIN
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Bellinger
commit fd3a9025c0349bc9b01d627529f54e6e1e389015 upstream.
This patch addresses a v3.5+ regression in iscsi-target where TX thread
process context -> handle_response_queue() execution is allowed to run
unbounded while servicing constant outgoing flow of ISTATE_SEND_DATAIN
response state.
This ends up preventing memory release of StatSN acknowledged commands
in a timely manner when under heavy large block streaming DATAIN
workloads.
The regression bug was initially introduced with:
commit 6f3c0e69a9c20441bdc6d3b2d18b83b244384ec6
Author: Andy Grover
Date: Tue Apr 3 15:51:09 2012 -0700
target/iscsi: Refactor target_tx_thread immediate+response queue loops
Go ahead and follow original iscsi_target_tx_thread() logic and check
to break for immediate queue processing after each DataIN Sequence and/or
Response PDU has been sent.
Reported-by: Benjamin ESTRABAUD
Cc: Andy Grover
Signed-off-by: Nicholas Bellinger
Signed-off-by: Luis Henriques
---
drivers/target/iscsi/iscsi_target.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
index ac41f04..3e7ac0c 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -3608,6 +3608,10 @@ check_rsp_state:
spin_lock_bh(&cmd->istate_lock);
cmd->i_state = ISTATE_SENT_STATUS;
spin_unlock_bh(&cmd->istate_lock);
+
+ if (atomic_read(&conn->check_immediate_queue))
+ return 1;
+
continue;
} else if (ret == 2) {
/* Still must send status,
@@ -3697,7 +3701,7 @@ check_rsp_state:
}
if (atomic_read(&conn->check_immediate_queue))
- break;
+ return 1;
}
return 0;
@@ -3741,12 +3745,15 @@ restart:
signal_pending(current))
goto transport_err;
+get_immediate:
ret = handle_immediate_queue(conn);
if (ret < 0)
goto transport_err;
ret = handle_response_queue(conn);
- if (ret == -EAGAIN)
+ if (ret == 1)
+ goto get_immediate;
+ else if (ret == -EAGAIN)
goto restart;
else if (ret < 0)
goto transport_err;
--
1.8.1.2
--
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/
[stable request] TTY: do not reset master's packet mode
Hi, please include the patch below to all maintained stable trees. commit b81273a132177edd806476b953f6afeb17b786d5 Author: Jiri Slaby Date: Tue Jan 15 23:26:22 2013 +0100 TTY: do not reset master's packet mode thanks, -- js suse labs -- 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 23/88] block: fix ext_devt_idr handling
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Tomas Henzl
commit 7b74e912785a11572da43292786ed07ada7e3e0c upstream.
While adding and removing a lot of disks disks and partitions this
sometimes shows up:
WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted)
Hardware name:
sysfs: cannot create duplicate filename '/dev/block/259:751'
Modules linked in: raid1 autofs4 bnx2fc cnic uio fcoe libfcoe libfc 8021q
scsi_transport_fc scsi_tgt garp stp llc sunrpc cpufreq_ondemand powernow_k8
freq_table mperf ipv6 dm_mirror dm_region_hash dm_log power_meter microcode
dcdbas serio_raw amd64_edac_mod edac_core edac_mce_amd i2c_piix4 i2c_core
k10temp bnx2 sg ixgbe dca mdio ext4 mbcache jbd2 dm_round_robin sr_mod cdrom
sd_mod crc_t10dif ata_generic pata_acpi pata_atiixp ahci mptsas mptscsih
mptbase scsi_transport_sas dm_multipath dm_mod [last unloaded: scsi_wait_scan]
Pid: 44103, comm: async/16 Not tainted 2.6.32-195.el6.x86_64 #1
Call Trace:
warn_slowpath_common+0x87/0xc0
warn_slowpath_fmt+0x46/0x50
sysfs_add_one+0xc9/0x130
sysfs_do_create_link+0x12b/0x170
sysfs_create_link+0x13/0x20
device_add+0x317/0x650
idr_get_new+0x13/0x50
add_partition+0x21c/0x390
rescan_partitions+0x32b/0x470
sd_open+0x81/0x1f0 [sd_mod]
__blkdev_get+0x1b6/0x3c0
blkdev_get+0x10/0x20
register_disk+0x155/0x170
add_disk+0xa6/0x160
sd_probe_async+0x13b/0x210 [sd_mod]
add_wait_queue+0x46/0x60
async_thread+0x102/0x250
default_wake_function+0x0/0x20
async_thread+0x0/0x250
kthread+0x96/0xa0
child_rip+0xa/0x20
kthread+0x0/0xa0
child_rip+0x0/0x20
This most likely happens because dev_t is freed while the number is
still used and idr_get_new() is not protected on every use. The fix
adds a mutex where it wasn't before and moves the dev_t free function so
it is called after device del.
Signed-off-by: Tomas Henzl
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
[ luis: adjust context ]
Signed-off-by: Luis Henriques
---
block/genhd.c | 6 +-
block/partition-generic.c | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 9cf5583..9433636 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -420,14 +420,18 @@ int blk_alloc_devt(struct hd_struct *part, dev_t *devt)
do {
if (!idr_pre_get(&ext_devt_idr, GFP_KERNEL))
return -ENOMEM;
+ mutex_lock(&ext_devt_mutex);
rc = idr_get_new(&ext_devt_idr, part, &idx);
+ mutex_unlock(&ext_devt_mutex);
} while (rc == -EAGAIN);
if (rc)
return rc;
if (idx > MAX_EXT_DEVT) {
+ mutex_lock(&ext_devt_mutex);
idr_remove(&ext_devt_idr, idx);
+ mutex_unlock(&ext_devt_mutex);
return -EBUSY;
}
@@ -644,7 +648,6 @@ void del_gendisk(struct gendisk *disk)
disk_part_iter_exit(&piter);
invalidate_partition(disk, 0);
- blk_free_devt(disk_to_dev(disk)->devt);
set_capacity(disk, 0);
disk->flags &= ~GENHD_FL_UP;
@@ -662,6 +665,7 @@ void del_gendisk(struct gendisk *disk)
if (!sysfs_deprecated)
sysfs_remove_link(block_depr, dev_name(disk_to_dev(disk)));
device_del(disk_to_dev(disk));
+ blk_free_devt(disk_to_dev(disk)->devt);
}
EXPORT_SYMBOL(del_gendisk);
diff --git a/block/partition-generic.c b/block/partition-generic.c
index 6df5d69..7b8b8d1 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -249,11 +249,11 @@ void delete_partition(struct gendisk *disk, int partno)
if (!part)
return;
- blk_free_devt(part_devt(part));
rcu_assign_pointer(ptbl->part[partno], NULL);
rcu_assign_pointer(ptbl->last_lookup, NULL);
kobject_put(part->holder_dir);
device_del(part_to_dev(part));
+ blk_free_devt(part_devt(part));
hd_struct_put(part);
}
--
1.8.1.2
--
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 v3]Perf: Fix Makefile to clean all object files
Hi again,
On Thu, 14 Mar 2013 17:14:28 +0800, chenggang wrote:
> From: Chenggang Qin
>
> If we execute "make clean" in perf's directory, many object files cannot be
> cleaned in the current version.
> For example:
> While we run "make clean" in perf's directory, and run the command:
> "fine ./ -name "*.o""
> we will get:
>
> ./arch/x86/util/unwind.o
> ./arch/x86/util/header.o
> ./arch/x86/util/dwarf-regs.o
> ./util/scripting-engines/trace-event-python.o
> ./util/scripting-engines/trace-event-perl.o
> ./util/probe-finder.o
> ./util/dwarf-aux.o
> ./util/unwind.o
> ... ...
>
> These ".o" files are not cleaned.
>
> The reason is:
> These object files are added into "BUILTIN_OBJS" while "make" process check
> the environment.
> If the make command is "clean", the environment check process is not
> executed. So,
> these object files will not be added into "BUILTIN_OBJS" while we execute
> "make clean".
s/BUILTIN/LIB/g
>
> This patch fixed this problem.
> We only add a command:
> "find . -name "*.o" -exec rm -f {} \;"
I think the path should be $(OUTPUT) rather than ".". How about this?
find $(OUTPUT) -name "*.o" -delete
Thanks,
Namhyung
>
> Cc: David Ahern
> Cc: Peter Zijlstra
> Cc: Paul Mackerras
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> Cc: Arjan van de Ven
> Cc: Namhyung Kim
> Cc: Yanmin Zhang
> Cc: Wu Fengguang
> Cc: Mike Galbraith
> Cc: Andrew Morton
> Signed-off-by: Chenggang Qin
>
> ---
> tools/perf/Makefile |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> index a2108ca..dec08ba 100644
> --- a/tools/perf/Makefile
> +++ b/tools/perf/Makefile
> @@ -1174,6 +1174,7 @@ clean: $(LIBTRACEEVENT)-clean
> $(RM) $(OUTPUT)util/*-bison*
> $(RM) $(OUTPUT)util/*-flex*
> $(python-clean)
> + $(FIND) . -name "*.o" -exec rm -f {} \;
>
> .PHONY: all install clean strip $(LIBTRACEEVENT)
> .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
--
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 22/88] ocfs2: ac->ac_allow_chain_relink=0 won't disable group relink
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: "Xiaowei.Hu"
commit 309a85b6861fedbb48a22d45e0e079d1be993b3a upstream.
ocfs2_block_group_alloc_discontig() disables chain relink by setting
ac->ac_allow_chain_relink = 0 because it grabs clusters from multiple
cluster groups.
It doesn't keep the credits for all chain relink,but
ocfs2_claim_suballoc_bits overrides this in this call trace:
ocfs2_block_group_claim_bits()->ocfs2_claim_clusters()->
__ocfs2_claim_clusters()->ocfs2_claim_suballoc_bits()
ocfs2_claim_suballoc_bits set ac->ac_allow_chain_relink = 1; then call
ocfs2_search_chain() one time and disable it again, and then we run out
of credits.
Fix is to allow relink by default and disable it in
ocfs2_block_group_alloc_discontig.
Without this patch, End-users will run into a crash due to run out of
credits, backtrace like this:
RIP: 0010:[] []
jbd2_journal_dirty_metadata+0x164/0x170 [jbd2]
RSP: 0018:8801b919b5b8 EFLAGS: 00010246
RAX: RBX: 88022139ddc0 RCX: 880159f652d0
RDX: 880178aa3000 RSI: 880159f652d0 RDI: 880087f09bf8
RBP: 8801b919b5e8 R08: R09:
R10: 1e00 R11: 000150b0 R12: 880159f652d0
R13: 8801a0cae908 R14: 880087f09bf8 R15: 88018d177800
FS: 7fc9b0b6b6e0() GS:88022fd4() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0040819c CR3: 000184017000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process dd (pid: 9945, threadinfo 8801b919a000, task 880149a264c0)
Call Trace:
ocfs2_journal_dirty+0x2f/0x70 [ocfs2]
ocfs2_relink_block_group+0x111/0x480 [ocfs2]
ocfs2_search_chain+0x455/0x9a0 [ocfs2]
...
Signed-off-by: Xiaowei.Hu
Reviewed-by: Srinivas Eeda
Cc: Mark Fasheh
Cc: Joel Becker
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Luis Henriques
---
fs/ocfs2/suballoc.c | 7 +++
fs/ocfs2/suballoc.h | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c
index f169da4..b7e74b5 100644
--- a/fs/ocfs2/suballoc.c
+++ b/fs/ocfs2/suballoc.c
@@ -642,7 +642,7 @@ ocfs2_block_group_alloc_discontig(handle_t *handle,
* cluster groups will be staying in cache for the duration of
* this operation.
*/
- ac->ac_allow_chain_relink = 0;
+ ac->ac_disable_chain_relink = 1;
/* Claim the first region */
status = ocfs2_block_group_claim_bits(osb, handle, ac, min_bits,
@@ -1823,7 +1823,7 @@ static int ocfs2_search_chain(struct ocfs2_alloc_context
*ac,
* Do this *after* figuring out how many bits we're taking out
* of our target group.
*/
- if (ac->ac_allow_chain_relink &&
+ if (!ac->ac_disable_chain_relink &&
(prev_group_bh) &&
(ocfs2_block_group_reasonably_empty(bg, res->sr_bits))) {
status = ocfs2_relink_block_group(handle, alloc_inode,
@@ -1928,7 +1928,6 @@ static int ocfs2_claim_suballoc_bits(struct
ocfs2_alloc_context *ac,
victim = ocfs2_find_victim_chain(cl);
ac->ac_chain = victim;
- ac->ac_allow_chain_relink = 1;
status = ocfs2_search_chain(ac, handle, bits_wanted, min_bits,
res, &bits_left);
@@ -1947,7 +1946,7 @@ static int ocfs2_claim_suballoc_bits(struct
ocfs2_alloc_context *ac,
* searching each chain in order. Don't allow chain relinking
* because we only calculate enough journal credits for one
* relink per alloc. */
- ac->ac_allow_chain_relink = 0;
+ ac->ac_disable_chain_relink = 1;
for (i = 0; i < le16_to_cpu(cl->cl_next_free_rec); i ++) {
if (i == victim)
continue;
diff --git a/fs/ocfs2/suballoc.h b/fs/ocfs2/suballoc.h
index b8afabf..a36d0aa 100644
--- a/fs/ocfs2/suballoc.h
+++ b/fs/ocfs2/suballoc.h
@@ -49,7 +49,7 @@ struct ocfs2_alloc_context {
/* these are used by the chain search */
u16ac_chain;
- intac_allow_chain_relink;
+ intac_disable_chain_relink;
group_search_t *ac_group_search;
u64ac_last_group;
--
1.8.1.2
--
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 21/88] ocfs2: fix ocfs2_init_security_and_acl() to initialize acl correctly
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Jeff Liu
commit 32918dd9f19e5960af4cdfa41190bb843fb2247b upstream.
We need to re-initialize the security for a new reflinked inode with its
parent dirs if it isn't specified to be preserved for ocfs2_reflink().
However, the code logic is broken at ocfs2_init_security_and_acl()
although ocfs2_init_security_get() succeed. As a result,
ocfs2_acl_init() does not involked and therefore the default ACL of
parent dir was missing on the new inode.
Note this was introduced by 9d8f13ba3 ("security: new
security_inode_init_security API adds function callback")
To reproduce:
set default ACL for the parent dir(ocfs2 in this case):
$ setfacl -m default:user:jeff:rwx ../ocfs2/
$ getfacl ../ocfs2/
# file: ../ocfs2/
# owner: jeff
# group: jeff
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:jeff:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
$ touch a
$ getfacl a
# file: a
# owner: jeff
# group: jeff
user::rw-
group::rw-
other::r--
Before patching, create reflink file b from a, the user
default ACL entry(user:jeff:rwx)was missing:
$ ./ocfs2_reflink a b
$ getfacl b
# file: b
# owner: jeff
# group: jeff
user::rw-
group::rw-
other::r--
In this case, the end user can also observed an error message at syslog:
(ocfs2_reflink,3229,2):ocfs2_init_security_and_acl:7193 ERROR: status = 0
After applying this patch, create reflink file c from a:
$ ./ocfs2_reflink a c
$ getfacl c
# file: c
# owner: jeff
# group: jeff
user::rw-
user:jeff:rwx #effective:rw-
group::r-x #effective:r--
mask::rw-
other::r--
Test program:
/* Usage: reflink */
#include
#include
#include
#include
#include
#include
#include
#include
#include
static int
reflink_file(char const *src_name, char const *dst_name,
bool preserve_attrs)
{
int fd;
#ifndef REFLINK_ATTR_NONE
# define REFLINK_ATTR_NONE 0
#endif
#ifndef REFLINK_ATTR_PRESERVE
# define REFLINK_ATTR_PRESERVE 1
#endif
#ifndef OCFS2_IOC_REFLINK
struct reflink_arguments {
uint64_t old_path;
uint64_t new_path;
uint64_t preserve;
};
# define OCFS2_IOC_REFLINK _IOW ('o', 4, struct reflink_arguments)
#endif
struct reflink_arguments args = {
.old_path = (unsigned long) src_name,
.new_path = (unsigned long) dst_name,
.preserve = preserve_attrs ? REFLINK_ATTR_PRESERVE :
REFLINK_ATTR_NONE,
};
fd = open(src_name, O_RDONLY);
if (fd < 0) {
fprintf(stderr, "Failed to open %s: %s\n",
src_name, strerror(errno));
return -1;
}
if (ioctl(fd, OCFS2_IOC_REFLINK, &args) < 0) {
fprintf(stderr, "Failed to reflink %s to %s: %s\n",
src_name, dst_name, strerror(errno));
return -1;
}
}
int
main(int argc, char *argv[])
{
if (argc != 3) {
fprintf(stdout, "Usage: %s source dest\n", argv[0]);
return 1;
}
return reflink_file(argv[1], argv[2], 0);
}
Signed-off-by: Jie Liu
Reviewed-by: Tao Ma
Cc: Mimi Zohar
Cc: Joel Becker
Cc: Mark Fasheh
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Luis Henriques
---
fs/ocfs2/xattr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 0ba9ea1..2e3ea30 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -7189,7 +7189,7 @@ int ocfs2_init_security_and_acl(struct inode *dir,
struct buffer_head *dir_bh = NULL;
ret = ocfs2_init_security_get(inode, dir, qstr, NULL);
- if (!ret) {
+ if (ret) {
mlog_errno(ret);
goto leave;
}
--
1.8.1.2
--
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] staging: ccg: remove two outdated dependencies
On Thu, Mar 14, 2013 at 11:17:04AM +0100, Paul Bolle wrote: > 1) This patch is rather hard to review. That is because the "depends on" > line is rather hard to read. Perhaps the easiest way to review is to do > git grep -n "\bUSB_FILE_STORAGE\(_TEST\)\?\b" > > before and after applying this patch. But that doesn't catch possible > other, unwanted, changes. Maybe we need to split up the "depends on" > line before removing these two negative entries. Your patch is fine as is, but if you wanted to send a follow on patch to break the depend mess into separate lines, that would also be welcome. :) Reviewed-by: Dan Carpenter regards, dan carpenter -- 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 25/88] block: fix synchronization and limit check in blk_alloc_devt()
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Tejun Heo
commit ce23bba842aee98092225d9576dba47c82352521 upstream.
idr allocation in blk_alloc_devt() wasn't synchronized against lookup
and removal, and its limit check was off by one - 1 << MINORBITS is
the number of minors allowed, not the maximum allowed minor.
Add locking and rename MAX_EXT_DEVT to NR_EXT_DEVT and fix limit
checking.
Signed-off-by: Tejun Heo
Acked-by: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Luis Henriques
---
block/genhd.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 9433636..60108d9 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -25,7 +25,7 @@ static DEFINE_MUTEX(block_class_lock);
struct kobject *block_depr;
/* for extended dynamic devt allocation, currently only one major is used */
-#define MAX_EXT_DEVT (1 << MINORBITS)
+#define NR_EXT_DEVT(1 << MINORBITS)
/* For extended devt allocation. ext_devt_mutex prevents look up
* results from going away underneath its user.
@@ -422,19 +422,16 @@ int blk_alloc_devt(struct hd_struct *part, dev_t *devt)
return -ENOMEM;
mutex_lock(&ext_devt_mutex);
rc = idr_get_new(&ext_devt_idr, part, &idx);
+ if (!rc && idx >= NR_EXT_DEVT) {
+ idr_remove(&ext_devt_idr, idx);
+ rc = -EBUSY;
+ }
mutex_unlock(&ext_devt_mutex);
} while (rc == -EAGAIN);
if (rc)
return rc;
- if (idx > MAX_EXT_DEVT) {
- mutex_lock(&ext_devt_mutex);
- idr_remove(&ext_devt_idr, idx);
- mutex_unlock(&ext_devt_mutex);
- return -EBUSY;
- }
-
*devt = MKDEV(BLOCK_EXT_MAJOR, blk_mangle_minor(idx));
return 0;
}
--
1.8.1.2
--
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 26/88] firewire: add minor number range check to fw_device_init()
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Tejun Heo
commit 3bec60d511179853138836ae6e1b61fe34d9235f upstream.
fw_device_init() didn't check whether the allocated minor number isn't
too large. Fail if it goes overflows MINORBITS.
Signed-off-by: Tejun Heo
Suggested-by: Stefan Richter
Acked-by: Stefan Richter
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Luis Henriques
---
drivers/firewire/core-device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c
index 4d460ef..ee901e2 100644
--- a/drivers/firewire/core-device.c
+++ b/drivers/firewire/core-device.c
@@ -1010,6 +1010,10 @@ static void fw_device_init(struct work_struct *work)
ret = idr_pre_get(&fw_device_idr, GFP_KERNEL) ?
idr_get_new(&fw_device_idr, device, &minor) :
-ENOMEM;
+ if (minor >= 1 << MINORBITS) {
+ idr_remove(&fw_device_idr, minor);
+ minor = -ENOSPC;
+ }
up_write(&fw_device_rwsem);
if (ret < 0)
--
1.8.1.2
--
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 24/88] idr: fix a subtle bug in idr_get_next()
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Tejun Heo
commit 6cdae7416a1c45c2ce105a78187d9b7e8feb9e24 upstream.
The iteration logic of idr_get_next() is borrowed mostly verbatim from
idr_for_each(). It walks down the tree looking for the slot matching
the current ID. If the matching slot is not found, the ID is
incremented by the distance of single slot at the given level and
repeats.
The implementation assumes that during the whole iteration id is aligned
to the layer boundaries of the level closest to the leaf, which is true
for all iterations starting from zero or an existing element and thus is
fine for idr_for_each().
However, idr_get_next() may be given any point and if the starting id
hits in the middle of a non-existent layer, increment to the next layer
will end up skipping the same offset into it. For example, an IDR with
IDs filled between [64, 127] would look like the following.
[ 0 64 ... ]
// |
||
NULL[ 64 ... 127 ]
If idr_get_next() is called with 63 as the starting point, it will try
to follow down the pointer from 0. As it is NULL, it will then try to
proceed to the next slot in the same level by adding the slot distance
at that level which is 64 - making the next try 127. It goes around the
loop and finds and returns 127 skipping [64, 126].
Note that this bug also triggers in idr_for_each_entry() loop which
deletes during iteration as deletions can make layers go away leaving
the iteration with unaligned ID into missing layers.
Fix it by ensuring proceeding to the next slot doesn't carry over the
unaligned offset - ie. use round_up(id + 1, slot_distance) instead of
id += slot_distance.
Signed-off-by: Tejun Heo
Reported-by: David Teigland
Cc: KAMEZAWA Hiroyuki
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Luis Henriques
---
lib/idr.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lib/idr.c b/lib/idr.c
index 4046e29..e90d2d0 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -625,7 +625,14 @@ void *idr_get_next(struct idr *idp, int *nextidp)
return p;
}
- id += 1 << n;
+ /*
+* Proceed to the next layer at the current level. Unlike
+* idr_for_each(), @id isn't guaranteed to be aligned to
+* layer boundary at this point and adding 1 << n may
+* incorrectly skip IDs. Make sure we jump to the
+* beginning of the next layer using round_up().
+*/
+ id = round_up(id + 1, 1 << n);
while (n < fls(id)) {
n += IDR_BITS;
p = *--paa;
--
1.8.1.2
--
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] sched: wakeup buddy
On Wed, 2013-03-13 at 11:07 +0800, Michael Wang wrote: > However, we already figure out the logical that wakeup related task > could benefit from closely running, this could promise us somewhat > reliable benefit. I'm not convinced that the 2 task wakeup scenario is the only sane scenario. Imagine a ring of 3 tasks that wakes each other, if the machine is loaded enough, those 3 tasks might fit a single cpu just fine -- esp. if one of those is always idle. But your strict 1:1 wakeup relation thing will completely fail to detect this. > IMHO, that sounds a little easier for users than to make the decision on > tell me how long to pull tasks together, they may be confused... Users shouldn't ever need/want/etc.. rely on this. They should just run their programs and be (reasonably) happy. > In summary, I think we have two point here need to be considered: > > 1. what about the missed optimize timing, that may benefit >some workload (although we haven't found such workload yet). Missed optimize; as in not calling wake_affine() due to the throttle? If we're calling it at such a high frequency it is very likely the next call isn't very far away. > 2. how many benefit could wake_affine() stuff bring to us, >if limit rate benefit us, why don't we remove it? It could bring the same benefit but at lower overhead, what's the point of computing the same value over and over again? Also, the rate limit thing naturally works for the soft/hard-irq case. Now, there's another detail I thought up, one could only limit the wake_affine() calls once it starts returning false. -- 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 28/88] sysctl: fix null checking in bin_dn_node_address()
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: Xi Wang commit df1778be1a33edffa51d094eeda87c858ded6560 upstream. The null check of `strchr() + 1' is broken, which is always non-null, leading to OOB read. Instead, check the result of strchr(). Signed-off-by: Xi Wang Cc: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Luis Henriques --- kernel/sysctl_binary.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c index a650694..9f9aa32 100644 --- a/kernel/sysctl_binary.c +++ b/kernel/sysctl_binary.c @@ -1194,9 +1194,10 @@ static ssize_t bin_dn_node_address(struct file *file, /* Convert the decnet address to binary */ result = -EIO; - nodep = strchr(buf, '.') + 1; + nodep = strchr(buf, '.'); if (!nodep) goto out; + ++nodep; area = simple_strtoul(buf, NULL, 10); node = simple_strtoul(nodep, NULL, 10); -- 1.8.1.2 -- 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 v4]Perf: Fix Makefile to clean all object files
From: Chenggang Qin
If we execute "make clean" in perf's directory, many object files cannot be
cleaned in the current version.
For example:
While we run "make clean" in perf's directory, and run the command:
"fine ./ -name "*.o""
we will get:
./arch/x86/util/unwind.o
./arch/x86/util/header.o
./arch/x86/util/dwarf-regs.o
./util/scripting-engines/trace-event-python.o
./util/scripting-engines/trace-event-perl.o
./util/probe-finder.o
./util/dwarf-aux.o
./util/unwind.o
... ...
These ".o" files are not cleaned.
The reason is:
These object files are added into "BUILTIN_OBJS" while "make" process check the
environment.
If the make command is "clean", the environment check process is not executed.
So,
these object files will not be added into "BUILTIN_OBJS" while we execute "make
clean".
This patch fixed this problem.
We only add a command:
"find . -name "*.o" -exec rm -f {} \;"
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Arjan van de Ven
Cc: Namhyung Kim
Cc: Yanmin Zhang
Cc: Wu Fengguang
Cc: Mike Galbraith
Cc: Andrew Morton
Signed-off-by: Chenggang Qin
---
tools/perf/Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index a2108ca..dec08ba 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -1174,6 +1174,7 @@ clean: $(LIBTRACEEVENT)-clean
$(RM) $(OUTPUT)util/*-bison*
$(RM) $(OUTPUT)util/*-flex*
$(python-clean)
+ $(FIND) $(OUTPUT) -name "*.o" -delete
.PHONY: all install clean strip $(LIBTRACEEVENT)
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
--
1.7.8.rc2.5.g815b
--
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 30/88] target/pscsi: Fix page increment
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Asias He
commit 472b72f2db7831d7dbe22ffdff4adee3bd49b05d upstream.
The page++ is wrong. It makes bio_add_pc_page() pointing to a wrong page
address if the 'while (len > 0 && data_len > 0) { ... }' loop is
executed more than one once.
Signed-off-by: Asias He
Signed-off-by: Nicholas Bellinger
Signed-off-by: Luis Henriques
---
drivers/target/target_core_pscsi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/target/target_core_pscsi.c
b/drivers/target/target_core_pscsi.c
index 4ce2cf6..1835d84 100644
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -1000,7 +1000,6 @@ static int pscsi_map_sg(struct se_cmd *cmd, struct
scatterlist *sgl,
bio = NULL;
}
- page++;
len -= bytes;
data_len -= bytes;
off = 0;
--
1.8.1.2
--
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 31/88] xen/pat: Disable PAT using pat_enabled value.
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Konrad Rzeszutek Wilk
commit c79c49826270b8b0061b2fca840fc3f013c8a78a upstream.
The git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
(xen/pat: Disable PAT support for now) explains in details why
we want to disable PAT for right now. However that
change was not enough and we should have also disabled
the pat_enabled value. Otherwise we end up with:
mmap-example:3481 map pfn expected mapping type write-back for
[mem 0x0001-0x00010fff], got uncached-minus
[ cut here ]
WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
untrack_pfn+0xb8/0xd0()
mem 0x0001-0x00010fff], got uncached-minus
[ cut here ]
WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
untrack_pfn+0xb8/0xd0()
...
Pid: 3481, comm: mmap-example Tainted: GF 3.8.0-6-generic #13-Ubuntu
Call Trace:
[] warn_slowpath_common+0x7f/0xc0
[] warn_slowpath_null+0x1a/0x20
[] untrack_pfn+0xb8/0xd0
[] unmap_single_vma+0xac/0x100
[] unmap_vmas+0x49/0x90
[] exit_mmap+0x98/0x170
[] mmput+0x64/0x100
[] dup_mm+0x445/0x660
[] copy_process.part.22+0xa5f/0x1510
[] do_fork+0x91/0x350
[] sys_clone+0x16/0x20
[] stub_clone+0x69/0x90
[] ? system_call_fastpath+0x1a/0x1f
---[ end trace 4918cdd0a4c9fea4 ]---
(a similar message shows up if you end up launching 'mcelog')
The call chain is (as analyzed by Liu, Jinsong):
do_fork
--> copy_process
--> dup_mm
--> dup_mmap
--> copy_page_range
--> track_pfn_copy
--> reserve_pfn_range
--> line 624: flags != want_flags
It comes from different memory types of page table (_PAGE_CACHE_WB) and MTRR
(_PAGE_CACHE_UC_MINUS).
Stefan Bader dug in this deep and found out that:
"That makes it clearer as this will do
reserve_memtype(...)
--> pat_x_mtrr_type
--> mtrr_type_lookup
--> __mtrr_type_lookup
And that can return -1/0xff in case of MTRR not being enabled/initialized. Which
is not the case (given there are no messages for it in dmesg). This is not equal
to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
It looks like the problem starts early in reserve_memtype:
if (!pat_enabled) {
/* This is identical to page table setting without PAT */
if (new_type) {
if (req_type == _PAGE_CACHE_WC)
*new_type = _PAGE_CACHE_UC_MINUS;
else
*new_type = req_type & _PAGE_CACHE_MASK;
}
return 0;
}
This would be what we want, that is clearing the PWT and PCD flags from the
supported flags - if pat_enabled is disabled."
This patch does that - disabling PAT.
Reported-by: Sander Eikelenboom
Reported-and-Tested-by: Konrad Rzeszutek Wilk
Reported-and-Tested-by: Stefan Bader
Signed-off-by: Konrad Rzeszutek Wilk
[ luis: adjust context ]
Signed-off-by: Luis Henriques
---
arch/x86/xen/enlighten.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index c1656e0..18b55fa 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -65,6 +65,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_ACPI
#include
@@ -1368,6 +1369,14 @@ asmlinkage void __init xen_start_kernel(void)
pgd = (pgd_t *)xen_start_info->pt_base;
+#ifdef CONFIG_X86_PAT
+ /*
+* For right now disable the PAT. We should remove this once
+* git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
+* (xen/pat: Disable PAT support for now) is reverted.
+*/
+ pat_enabled = 0;
+#endif
/* Don't do the full vcpu_info placement stuff until we have a
possible map and a non-dummy shared_info. */
per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
--
1.8.1.2
--
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 08/88] NFS: Don't allow NFS silly-renamed files to be deleted, no signal
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit 5a7a613a47a715711b3f2d3322a0eac21d459166 upstream.
Commit 73ca100 broke the code that prevents the client from deleting
a silly renamed dentry. This affected "delete on last close"
semantics as after that commit, nothing prevented removal of
silly-renamed files. As a result, a process holding a file open
could easily get an ESTALE on the file in a directory where some
other process issued 'rm -rf some_dir_containing_the_file' twice.
Before the commit, any attempt at unlinking silly renamed files would
fail inside may_delete() with -EBUSY because of the
DCACHE_NFSFS_RENAMED flag. The following testcase demonstrates
the problem:
tail -f /nfsmnt/dir/file &
rm -rf /nfsmnt/dir
rm -rf /nfsmnt/dir
# second removal does not fail, 'tail' process receives ESTALE
The problem with the above commit is that it unhashes the old and
new dentries from the lookup path, even in the normal case when
a signal is not encountered and it would have been safe to call
d_move. Unfortunately the old dentry has the special
DCACHE_NFSFS_RENAMED flag set on it. Unhashing has the
side-effect that future lookups call d_alloc(), allocating a new
dentry without the special flag for any silly-renamed files. As a
result, subsequent calls to unlink silly renamed files do not fail
but allow the removal to go through. This will result in ESTALE
errors for any other process doing operations on the file.
To fix this, go back to using d_move on success.
For the signal case, it's unclear what we may safely do beyond d_drop.
Reported-by: Dave Wysochanski
Signed-off-by: Trond Myklebust
Acked-by: Jeff Layton
Signed-off-by: Luis Henriques
---
fs/nfs/unlink.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index 3210a03..2781563 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -336,20 +336,14 @@ static void nfs_async_rename_done(struct rpc_task *task,
void *calldata)
struct inode *old_dir = data->old_dir;
struct inode *new_dir = data->new_dir;
struct dentry *old_dentry = data->old_dentry;
- struct dentry *new_dentry = data->new_dentry;
if (!NFS_PROTO(old_dir)->rename_done(task, old_dir, new_dir)) {
rpc_restart_call_prepare(task);
return;
}
- if (task->tk_status != 0) {
+ if (task->tk_status != 0)
nfs_cancel_async_unlink(old_dentry);
- return;
- }
-
- d_drop(old_dentry);
- d_drop(new_dentry);
}
/**
@@ -550,6 +544,18 @@ nfs_sillyrename(struct inode *dir, struct dentry *dentry)
error = rpc_wait_for_completion_task(task);
if (error == 0)
error = task->tk_status;
+ switch (error) {
+ case 0:
+ /* The rename succeeded */
+ nfs_set_verifier(dentry, nfs_save_change_attribute(dir));
+ d_move(dentry, sdentry);
+ break;
+ case -ERESTARTSYS:
+ /* The result of the rename is unknown. Play it safe by
+* forcing a new lookup */
+ d_drop(dentry);
+ d_drop(sdentry);
+ }
rpc_put_task(task);
out_dput:
dput(sdentry);
--
1.8.1.2
--
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 18/88] x86: Make sure we can boot in the case the BDA contains pure garbage
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: "H. Peter Anvin"
commit 7c10093692ed2e6f318387d96b829320aa0ca64c upstream.
On non-BIOS platforms it is possible that the BIOS data area contains
garbage instead of being zeroed or something equivalent (firmware
people: we are talking of 1.5K here, so please do the sane thing.)
We need on the order of 20-30K of low memory in order to boot, which
may grow up to < 64K in the future. We probably want to avoid the
lowest of the low memory. At the same time, it seems extremely
unlikely that a legitimate EBDA would ever reach down to the 128K
(which would require it to be over half a megabyte in size.) Thus,
pick 128K as the cutoff for "this is insane, ignore." We may still
end up reserving a bunch of extra memory on the low megabyte, but that
is not really a major issue these days. In the worst case we lose
512K of RAM.
This code really should be merged with trim_bios_range() in
arch/x86/kernel/setup.c, but that is a bigger patch for a later merge
window.
Reported-by: Darren Hart
Signed-off-by: H. Peter Anvin
Cc: Matt Fleming
Link: http://lkml.kernel.org/n/tip-oebml055yyfm8yxmria09...@git.kernel.org
Signed-off-by: Luis Henriques
---
arch/x86/kernel/head.c | 53 --
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/arch/x86/kernel/head.c b/arch/x86/kernel/head.c
index 48d9d4e..992f442 100644
--- a/arch/x86/kernel/head.c
+++ b/arch/x86/kernel/head.c
@@ -5,8 +5,6 @@
#include
#include
-#define BIOS_LOWMEM_KILOBYTES 0x413
-
/*
* The BIOS places the EBDA/XBDA at the top of conventional
* memory, and usually decreases the reported amount of
@@ -16,17 +14,30 @@
* chipset: reserve a page before VGA to prevent PCI prefetch
* into it (errata #56). Usually the page is reserved anyways,
* unless you have no PS/2 mouse plugged in.
+ *
+ * This functions is deliberately very conservative. Losing
+ * memory in the bottom megabyte is rarely a problem, as long
+ * as we have enough memory to install the trampoline. Using
+ * memory that is in use by the BIOS or by some DMA device
+ * the BIOS didn't shut down *is* a big problem.
*/
+
+#define BIOS_LOWMEM_KILOBYTES 0x413
+#define LOWMEM_CAP 0x9f000U/* Absolute maximum */
+#define INSANE_CUTOFF 0x2U/* Less than this = insane */
+
void __init reserve_ebda_region(void)
{
unsigned int lowmem, ebda_addr;
- /* To determine the position of the EBDA and the */
- /* end of conventional memory, we need to look at */
- /* the BIOS data area. In a paravirtual environment */
- /* that area is absent. We'll just have to assume */
- /* that the paravirt case can handle memory setup */
- /* correctly, without our help. */
+ /*
+* To determine the position of the EBDA and the
+* end of conventional memory, we need to look at
+* the BIOS data area. In a paravirtual environment
+* that area is absent. We'll just have to assume
+* that the paravirt case can handle memory setup
+* correctly, without our help.
+*/
if (paravirt_enabled())
return;
@@ -37,19 +48,23 @@ void __init reserve_ebda_region(void)
/* start of EBDA area */
ebda_addr = get_bios_ebda();
- /* Fixup: bios puts an EBDA in the top 64K segment */
- /* of conventional memory, but does not adjust lowmem. */
- if ((lowmem - ebda_addr) <= 0x1)
- lowmem = ebda_addr;
+ /*
+* Note: some old Dells seem to need 4k EBDA without
+* reporting so, so just consider the memory above 0x9f000
+* to be off limits (bugzilla 2990).
+*/
+
+ /* If the EBDA address is below 128K, assume it is bogus */
+ if (ebda_addr < INSANE_CUTOFF)
+ ebda_addr = LOWMEM_CAP;
- /* Fixup: bios does not report an EBDA at all. */
- /* Some old Dells seem to need 4k anyhow (bugzilla 2990) */
- if ((ebda_addr == 0) && (lowmem >= 0x9f000))
- lowmem = 0x9f000;
+ /* If lowmem is less than 128K, assume it is bogus */
+ if (lowmem < INSANE_CUTOFF)
+ lowmem = LOWMEM_CAP;
- /* Paranoia: should never happen, but... */
- if ((lowmem == 0) || (lowmem >= 0x10))
- lowmem = 0x9f000;
+ /* Use the lower of the lowmem and EBDA markers as the cutoff */
+ lowmem = min(lowmem, ebda_addr);
+ lowmem = min(lowmem, LOWMEM_CAP); /* Absolute cap */
/* reserve all memory between lowmem and the 1MB mark */
memblock_reserve(lowmem, 0x10 - lowmem);
--
1.8.1.2
--
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.t
[PATCH 09/88] SUNRPC: Don't start the retransmission timer when out of socket space
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit a9a6b52ee1baa865283a91eb8d443ee91adfca56 upstream.
If the socket is full, we're better off just waiting until it empties,
or until the connection is broken. The reason why we generally don't
want to time out is that the call to xprt->ops->release_xprt() will
trigger a connection reset, which isn't helpful...
Let's make an exception for soft RPC calls, since they have to provide
timeout guarantees.
Signed-off-by: Trond Myklebust
Signed-off-by: Luis Henriques
---
net/sunrpc/xprt.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index 6329ff3..b4efb51 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -485,13 +485,17 @@ EXPORT_SYMBOL_GPL(xprt_wake_pending_tasks);
* xprt_wait_for_buffer_space - wait for transport output buffer to clear
* @task: task to be put to sleep
* @action: function pointer to be executed after wait
+ *
+ * Note that we only set the timer for the case of RPC_IS_SOFT(), since
+ * we don't in general want to force a socket disconnection due to
+ * an incomplete RPC call transmission.
*/
void xprt_wait_for_buffer_space(struct rpc_task *task, rpc_action action)
{
struct rpc_rqst *req = task->tk_rqstp;
struct rpc_xprt *xprt = req->rq_xprt;
- task->tk_timeout = req->rq_timeout;
+ task->tk_timeout = RPC_IS_SOFT(task) ? req->rq_timeout : 0;
rpc_sleep_on(&xprt->pending, task, action);
}
EXPORT_SYMBOL_GPL(xprt_wait_for_buffer_space);
--
1.8.1.2
--
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 10/88] storvsc: Initialize the sglist
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: "K. Y. Srinivasan"
commit 9d2696e658ef4f209955ddaa987d43f1a1bd81a1 upstream.
Properly initialize scatterlist before using it.
Signed-off-by: K. Y. Srinivasan
Signed-off-by: James Bottomley
Signed-off-by: Luis Henriques
---
drivers/scsi/storvsc_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 0144078..9f4e560 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -467,6 +467,7 @@ static struct scatterlist *create_bounce_buffer(struct
scatterlist *sgl,
if (!bounce_sgl)
return NULL;
+ sg_init_table(bounce_sgl, num_pages);
for (i = 0; i < num_pages; i++) {
page_buf = alloc_page(GFP_ATOMIC);
if (!page_buf)
--
1.8.1.2
--
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 13/88] ARM: VFP: fix emulation of second VFP instruction
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: Russell King commit 5e4ba617c1b584b2e376f31a63bd4e734109318a upstream. Martin Storsjö reports that the sequence: ee312ac1vsub.f32s4, s3, s2 ee702ac0vsub.f32s5, s1, s0 e59f0028ldr r0, [pc, #40] ee111a90vmovr1, s3 on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5) where s3 is a denormal and s2 is zero results in incorrect behaviour - the instruction "vsub.f32 s5, s1, s0" is not executed: VFP: bounce: trigger ee111a90 fpexc d780 VFP: emulate: INST=0xee312ac1 SCR=0x ... As we can see, the instruction triggering the exception is the "vmov" instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to properly take account of the FPEXC_FP2V flag in FPEXC. This is because the test for the second instruction register being valid is bogus, and will always skip emulation of the second instruction. Reported-by: Martin Storsjö Tested-by: Martin Storsjö Signed-off-by: Russell King Signed-off-by: Luis Henriques --- arch/arm/vfp/vfpmodule.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c index 3b44e0d..5dfbb0b 100644 --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -413,7 +413,7 @@ void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) * If there isn't a second FP instruction, exit now. Note that * the FPEXC.FP2V bit is valid only if FPEXC.EX is 1. */ - if (fpexc ^ (FPEXC_EX | FPEXC_FP2V)) + if ((fpexc & (FPEXC_EX | FPEXC_FP2V)) != (FPEXC_EX | FPEXC_FP2V)) goto exit; /* -- 1.8.1.2 -- 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 11/88] dc395x: uninitialized variable in device_alloc()
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: Dan Carpenter commit 208afec4f3be8c51ad6eebe6611dd6d2ad2fa298 upstream. This bug was introduced back in bitkeeper days in 2003. We use "dcb->dev_mode" before it has been initialized. Signed-off-by: Dan Carpenter Acked-by: Oliver Neukum Signed-off-by: James Bottomley Signed-off-by: Luis Henriques --- drivers/scsi/dc395x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c index 13aeca3..48105fc 100644 --- a/drivers/scsi/dc395x.c +++ b/drivers/scsi/dc395x.c @@ -3747,13 +3747,13 @@ static struct DeviceCtlBlk *device_alloc(struct AdapterCtlBlk *acb, dcb->max_command = 1; dcb->target_id = target; dcb->target_lun = lun; + dcb->dev_mode = eeprom->target[target].cfg0; #ifndef DC395x_NO_DISCONNECT dcb->identify_msg = IDENTIFY(dcb->dev_mode & NTC_DO_DISCONNECT, lun); #else dcb->identify_msg = IDENTIFY(0, lun); #endif - dcb->dev_mode = eeprom->target[target].cfg0; dcb->inquiry7 = 0; dcb->sync_mode = 0; dcb->min_nego_period = clock_period[period_index]; -- 1.8.1.2 -- 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 12/88] ALSA: bt87x: Make load_all parameter working again
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Takashi Iwai
commit aacfddfdadb3540651d263245069631f341e953a upstream.
Along with a clean up commit [e9f66d9b9: ALSA: pci: clean up using
module_pci_driver()], bt87x driver lost the functionality of load_all
parameter. This patch does a partial revert of the commit only for
bt87x.c to recover it.
Reported-by: Clemens Ladisch
Signed-off-by: Takashi Iwai
[ luis: adjust context ]
Signed-off-by: Luis Henriques
---
sound/pci/bt87x.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/sound/pci/bt87x.c b/sound/pci/bt87x.c
index b6a95ee..62d6163 100644
--- a/sound/pci/bt87x.c
+++ b/sound/pci/bt87x.c
@@ -836,6 +836,8 @@ static struct {
{0x7063, 0x2000}, /* pcHDTV HD-2000 TV */
};
+static struct pci_driver driver;
+
/* return the id of the card, or a negative value if it's blacklisted */
static int __devinit snd_bt87x_detect_card(struct pci_dev *pci)
{
@@ -962,11 +964,24 @@ static DEFINE_PCI_DEVICE_TABLE(snd_bt87x_default_ids) = {
{ }
};
-static struct pci_driver bt87x_driver = {
+static struct pci_driver driver = {
.name = KBUILD_MODNAME,
.id_table = snd_bt87x_ids,
.probe = snd_bt87x_probe,
.remove = __devexit_p(snd_bt87x_remove),
};
-module_pci_driver(bt87x_driver);
+static int __init alsa_card_bt87x_init(void)
+{
+ if (load_all)
+ driver.id_table = snd_bt87x_default_ids;
+ return pci_register_driver(&driver);
+}
+
+static void __exit alsa_card_bt87x_exit(void)
+{
+ pci_unregister_driver(&driver);
+}
+
+module_init(alsa_card_bt87x_init)
+module_exit(alsa_card_bt87x_exit)
--
1.8.1.2
--
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 29/88] nbd: fsync and kill block device on shutdown
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: Paolo Bonzini commit 3a2d63f87989e01437ba994df5f297528c353d7d upstream. There are two problems with shutdown in the NBD driver. 1: Receiving the NBD_DISCONNECT ioctl does not sync the filesystem. This patch adds the sync operation into __nbd_ioctl()'s NBD_DISCONNECT handler. This is useful because BLKFLSBUF is restricted to processes that have CAP_SYS_ADMIN, and the NBD client may not possess it (fsync of the block device does not sync the filesystem, either). 2: Once we clear the socket we have no guarantee that later reads will come from the same backing storage. The patch adds calls to kill_bdev() in __nbd_ioctl()'s socket clearing code so the page cache is cleaned, lest reads that hit on the page cache will return stale data from the previously-accessible disk. Example: # qemu-nbd -r -c/dev/nbd0 /dev/sr0 # file -s /dev/nbd0 /dev/stdin: # UDF filesystem data (version 1.5) etc. # qemu-nbd -d /dev/nbd0 # qemu-nbd -r -c/dev/nbd0 /dev/sda # file -s /dev/nbd0 /dev/stdin: # UDF filesystem data (version 1.5) etc. While /dev/sda has: # file -s /dev/sda /dev/sda: x86 boot sector; etc. Signed-off-by: Paolo Bonzini Acked-by: Paul Clements Cc: Alex Bligh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [ luis: adjust context ] Signed-off-by: Luis Henriques --- drivers/block/nbd.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index 3c4c225..7f25e24 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -584,12 +584,20 @@ static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd, struct request sreq; dev_info(disk_to_dev(nbd->disk), "NBD_DISCONNECT\n"); + if (!nbd->sock) + return -EINVAL; + mutex_unlock(&nbd->tx_lock); + fsync_bdev(bdev); + mutex_lock(&nbd->tx_lock); blk_rq_init(NULL, &sreq); sreq.cmd_type = REQ_TYPE_SPECIAL; nbd_cmd(&sreq) = NBD_CMD_DISC; + + /* Check again after getting mutex back. */ if (!nbd->sock) return -EINVAL; + nbd_send_req(nbd, &sreq); return 0; } @@ -603,6 +611,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd, nbd_clear_que(nbd); BUG_ON(!list_empty(&nbd->queue_head)); BUG_ON(!list_empty(&nbd->waiting_queue)); + kill_bdev(bdev); if (file) fput(file); return 0; @@ -683,6 +692,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd, nbd->file = NULL; nbd_clear_que(nbd); dev_warn(disk_to_dev(nbd->disk), "queue cleared\n"); + kill_bdev(bdev); if (file) fput(file); nbd->bytesize = 0; -- 1.8.1.2 -- 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] arm: davinci: clock node support for ECAP & EHRPWM
Add clock node support for ECAP and EHRPWM modules.
Also adds dummy clock for EHRWPM TBCLK to comply with pwm-tiehrpwm
driver.
Signed-off-by: Philip Avinash
---
:100644 100644 0c4a26d... 891d075... M arch/arm/mach-davinci/da850.c
arch/arm/mach-davinci/da850.c | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 0c4a26d..891d075 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -383,6 +383,27 @@ static struct clk dsp_clk = {
.flags = PSC_LRST | PSC_FORCE,
};
+static struct clk ehrpwm_clk = {
+ .name = "ehrpwm",
+ .parent = &pll0_sysclk2,
+ .lpsc = DA8XX_LPSC1_PWM,
+ .gpsc = 1,
+ .flags = DA850_CLK_ASYNC3,
+};
+
+static struct clk ehrpwm_tbclk = {
+ .name = "ehrpwm_tbclk",
+ .parent = NULL,
+};
+
+static struct clk ecap_clk = {
+ .name = "ecap",
+ .parent = &pll0_sysclk2,
+ .lpsc = DA8XX_LPSC1_ECAP,
+ .gpsc = 1,
+ .flags = DA850_CLK_ASYNC3,
+};
+
static struct clk_lookup da850_clks[] = {
CLK(NULL, "ref", &ref_clk),
CLK(NULL, "pll0", &pll0_clk),
@@ -430,6 +451,9 @@ static struct clk_lookup da850_clks[] = {
CLK("vpif", NULL, &vpif_clk),
CLK("ahci", NULL, &sata_clk),
CLK("davinci-rproc.0", NULL, &dsp_clk),
+ CLK("ehrpwm", "fck", &ehrpwm_clk),
+ CLK("ehrpwm", "tbclk",&ehrpwm_tbclk),
+ CLK("ecap", "fck", &ecap_clk),
CLK(NULL, NULL, NULL),
};
--
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/
[PATCH 32/88] xen/pci: We don't do multiple MSI's.
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Konrad Rzeszutek Wilk
commit 884ac2978a295b7df3c4a686d3bff6932460 upstream.
There is no hypercall to setup multiple MSI per PCI device.
As such with these two new commits:
- 08261d87f7d1b6253ab3223756625a5c74532293
PCI/MSI: Enable multiple MSIs with pci_enable_msi_block_auto()
- 5ca72c4f7c412c2002363218901eba5516c476b1
AHCI: Support multiple MSIs
we would call the PHYSDEVOP_map_pirq 'nvec' times with the same
contents of the PCI device. Sander discovered that we would get
the same PIRQ value 'nvec' times and return said values to the
caller. That of course meant that the device was configured only
with one MSI and AHCI would fail with:
ahci :00:11.0: version 3.0
xen: registering gsi 19 triggering 0 polarity 1
xen: --> pirq=19 -> irq=19 (gsi=19)
(XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 ->
IRQ 19 Mode:1 Active:1)
ahci :00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
ahci :00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
ahci: probe of :00:11.0 failed with error -22
That is b/c in ahci_host_activate the second call to
devm_request_threaded_irq would return -EINVAL as we passed in
(on the second run) an IRQ that was never initialized.
Reported-and-Tested-by: Sander Eikelenboom
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Luis Henriques
---
arch/x86/pci/xen.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 56ab749..94e7662 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -162,6 +162,9 @@ static int xen_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
struct msi_desc *msidesc;
int *v;
+ if (type == PCI_CAP_ID_MSI && nvec > 1)
+ return 1;
+
v = kzalloc(sizeof(int) * max(1, nvec), GFP_KERNEL);
if (!v)
return -ENOMEM;
@@ -220,6 +223,9 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
struct msi_desc *msidesc;
struct msi_msg msg;
+ if (type == PCI_CAP_ID_MSI && nvec > 1)
+ return 1;
+
list_for_each_entry(msidesc, &dev->msi_list, list) {
__read_msi_msg(msidesc, &msg);
pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
@@ -263,6 +269,9 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev,
int nvec, int type)
int ret = 0;
struct msi_desc *msidesc;
+ if (type == PCI_CAP_ID_MSI && nvec > 1)
+ return 1;
+
list_for_each_entry(msidesc, &dev->msi_list, list) {
struct physdev_map_pirq map_irq;
domid_t domid;
--
1.8.1.2
--
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 34/88] dm snapshot: add missing module aliases
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Mikulas Patocka
commit 23cb21092eb9dcec9d3604b68d95192b79915890 upstream.
Add module aliases so that autoloading works correctly if the user
tries to activate "snapshot-origin" or "snapshot-merge" targets.
Reference: https://bugzilla.redhat.com/889973
Reported-by: Chao Yang
Signed-off-by: Mikulas Patocka
Signed-off-by: Alasdair G Kergon
Signed-off-by: Luis Henriques
---
drivers/md/dm-snap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 6f75887..5f4659e 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -2327,3 +2327,5 @@ module_exit(dm_snapshot_exit);
MODULE_DESCRIPTION(DM_NAME " snapshot target");
MODULE_AUTHOR("Joe Thornber");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("dm-snapshot-origin");
+MODULE_ALIAS("dm-snapshot-merge");
--
1.8.1.2
--
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 35/88] ext4: convert number of blocks to clusters properly
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Lukas Czerner
commit 810da240f221d64bf90020f25941b05b378186fe upstream.
We're using macro EXT4_B2C() to convert number of blocks to number of
clusters for bigalloc file systems. However, we should be using
EXT4_NUM_B2C().
Signed-off-by: Lukas Czerner
Signed-off-by: "Theodore Ts'o"
Signed-off-by: CAI Qian
[ caiqian: Adjust context; dropped change to ext4_calculate_overhead() ]
Signed-off-by: Luis Henriques
---
fs/ext4/balloc.c | 2 +-
fs/ext4/mballoc.c | 8
fs/ext4/resize.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
index 2f2e0da..92e68b3 100644
--- a/fs/ext4/balloc.c
+++ b/fs/ext4/balloc.c
@@ -635,7 +635,7 @@ ext4_fsblk_t ext4_count_free_clusters(struct super_block
*sb)
brelse(bitmap_bh);
printk(KERN_DEBUG "ext4_count_free_clusters: stored = %llu"
", computed = %llu, %llu\n",
- EXT4_B2C(EXT4_SB(sb), ext4_free_blocks_count(es)),
+ EXT4_NUM_B2C(EXT4_SB(sb), ext4_free_blocks_count(es)),
desc_count, bitmap_count);
return bitmap_count;
#else
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index b5f8b5f..3631fbf 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -3430,7 +3430,7 @@ ext4_mb_new_inode_pa(struct ext4_allocation_context *ac)
win = offs;
ac->ac_b_ex.fe_logical = ac->ac_o_ex.fe_logical -
- EXT4_B2C(sbi, win);
+ EXT4_NUM_B2C(sbi, win);
BUG_ON(ac->ac_o_ex.fe_logical < ac->ac_b_ex.fe_logical);
BUG_ON(ac->ac_o_ex.fe_len > ac->ac_b_ex.fe_len);
}
@@ -4574,7 +4574,7 @@ do_more:
EXT4_BLOCKS_PER_GROUP(sb);
count -= overflow;
}
- count_clusters = EXT4_B2C(sbi, count);
+ count_clusters = EXT4_NUM_B2C(sbi, count);
bitmap_bh = ext4_read_block_bitmap(sb, block_group);
if (!bitmap_bh) {
err = -EIO;
@@ -4807,11 +4807,11 @@ int ext4_group_add_blocks(handle_t *handle, struct
super_block *sb,
ext4_group_desc_csum_set(sb, block_group, desc);
ext4_unlock_group(sb, block_group);
percpu_counter_add(&sbi->s_freeclusters_counter,
- EXT4_B2C(sbi, blocks_freed));
+ EXT4_NUM_B2C(sbi, blocks_freed));
if (sbi->s_log_groups_per_flex) {
ext4_group_t flex_group = ext4_flex_group(sbi, block_group);
- atomic_add(EXT4_B2C(sbi, blocks_freed),
+ atomic_add(EXT4_NUM_B2C(sbi, blocks_freed),
&sbi->s_flex_groups[flex_group].free_clusters);
}
diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index 4c31b71..86261ca 100644
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -1165,7 +1165,7 @@ static int ext4_setup_new_descs(handle_t *handle, struct
super_block *sb,
ext4_inode_table_set(sb, gdp, group_data->inode_table);
ext4_free_group_clusters_set(sb, gdp,
-EXT4_B2C(sbi,
group_data->free_blocks_count));
+ EXT4_NUM_B2C(sbi, group_data->free_blocks_count));
ext4_free_inodes_set(sb, gdp, EXT4_INODES_PER_GROUP(sb));
gdp->bg_flags = cpu_to_le16(*bg_flags);
ext4_group_desc_csum_set(sb, group, gdp);
@@ -1263,7 +1263,7 @@ static void ext4_update_super(struct super_block *sb,
/* Update the free space counts */
percpu_counter_add(&sbi->s_freeclusters_counter,
- EXT4_B2C(sbi, free_blocks));
+ EXT4_NUM_B2C(sbi, free_blocks));
percpu_counter_add(&sbi->s_freeinodes_counter,
EXT4_INODES_PER_GROUP(sb) * flex_gd->count);
@@ -1272,7 +1272,7 @@ static void ext4_update_super(struct super_block *sb,
sbi->s_log_groups_per_flex) {
ext4_group_t flex_group;
flex_group = ext4_flex_group(sbi, group_data[0].group);
- atomic_add(EXT4_B2C(sbi, free_blocks),
+ atomic_add(EXT4_NUM_B2C(sbi, free_blocks),
&sbi->s_flex_groups[flex_group].free_clusters);
atomic_add(EXT4_INODES_PER_GROUP(sb) * flex_gd->count,
&sbi->s_flex_groups[flex_group].free_inodes);
--
1.8.1.2
--
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 36/88] ata_piix: reenable MS Virtual PC guests
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Olaf Hering
commit d9904344fc4052fbe7e4dc137eba0dcdadf326bd upstream.
An earlier commit cd006086fa5d91414d8ff9ff2b78fbb593878e3c ("ata_piix:
defer disks to the Hyper-V drivers by default") broke MS Virtual PC
guests. Hyper-V guests and Virtual PC guests have nearly identical DMI
info. As a result the driver does currently ignore the emulated hardware
in Virtual PC guests and defers the handling to hv_blkvsc. Since Virtual
PC does not offer paravirtualized drivers no disks will be found in the
guest.
One difference in the DMI info is the product version. This patch adds a
match for MS Virtual PC 2007 and "unignores" the emulated hardware.
This was reported for openSuSE 12.1 in bugzilla:
https://bugzilla.novell.com/show_bug.cgi?id=737532
Here is a detailed list of DMI info from example guests:
hwinfo --bios:
virtual pc guest:
System Info: #1
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "VS2005R2"
Serial: "3178-9905-1533-4840-9282-0569-59"
UUID: undefined, but settable
Wake-up: 0x06 (Power Switch)
Board Info: #2
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "5.0"
Serial: "3178-9905-1533-4840-9282-0569-59"
Chassis Info: #3
Manufacturer: "Microsoft Corporation"
Version: "5.0"
Serial: "3178-9905-1533-4840-9282-0569-59"
Asset Tag: "7188-3705-6309-9738-9645-0364-00"
Type: 0x03 (Desktop)
Bootup State: 0x03 (Safe)
Power Supply State: 0x03 (Safe)
Thermal State: 0x01 (Other)
Security Status: 0x01 (Other)
win2k8 guest:
System Info: #1
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "7.0"
Serial: "9106-3420-9819-5495-1514-2075-48"
UUID: undefined, but settable
Wake-up: 0x06 (Power Switch)
Board Info: #2
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "7.0"
Serial: "9106-3420-9819-5495-1514-2075-48"
Chassis Info: #3
Manufacturer: "Microsoft Corporation"
Version: "7.0"
Serial: "9106-3420-9819-5495-1514-2075-48"
Asset Tag: "7076-9522-6699-1042-9501-1785-77"
Type: 0x03 (Desktop)
Bootup State: 0x03 (Safe)
Power Supply State: 0x03 (Safe)
Thermal State: 0x01 (Other)
Security Status: 0x01 (Other)
win2k12 guest:
System Info: #1
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "7.0"
Serial: "8179-1954-0187-0085-3868-2270-14"
UUID: undefined, but settable
Wake-up: 0x06 (Power Switch)
Board Info: #2
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "7.0"
Serial: "8179-1954-0187-0085-3868-2270-14"
Chassis Info: #3
Manufacturer: "Microsoft Corporation"
Version: "7.0"
Serial: "8179-1954-0187-0085-3868-2270-14"
Asset Tag: "8374-0485-4557-6331-0620-5845-25"
Type: 0x03 (Desktop)
Bootup State: 0x03 (Safe)
Power Supply State: 0x03 (Safe)
Thermal State: 0x01 (Other)
Security Status: 0x01 (Other)
Signed-off-by: Olaf Hering
Signed-off-by: Jeff Garzik
Signed-off-by: Luis Henriques
---
drivers/ata/ata_piix.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 3c809bf..36b5276 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -1577,12 +1577,31 @@ static void piix_ignore_devices_quirk(struct ata_host
*host)
},
{ } /* terminate list */
};
- const struct dmi_system_id *dmi = dmi_first_match(ignore_hyperv);
+ static const struct dmi_system_id allow_virtual_pc[] = {
+ {
+ /* In MS Virtual PC guests the DMI ident is nearly
+* identical to a Hyper-V guest. One difference is the
+* product version which is used here to identify
+* a Virtual PC guest. This entry allows ata_piix to
+* drive the emulated hardware.
+*/
+ .ident = "MS Virtual PC 2007",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR,
+ "Microsoft Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Virtual Machine"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "VS2005R2"),
+ },
+ },
+ { } /* terminate list */
+ };
+ const struct dmi_system_id *ignore = dmi_first_match(ignore_hyperv);
+ const struct dmi_system_id *allow = dmi_first_match(allow_virtual_pc);
- if (dmi && prefer_ms_hyperv) {
+ if (ignore && !allow && prefer_ms_hyperv) {
host->flags |= ATA_HOST_IGNORE_ATA;
dev_info(host
[PATCH 39/88] ata_piix: IDE-mode SATA patch for Intel Avoton DeviceIDs
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Seth Heasley
commit aaa515277db9585eeb4fdeb4637b9f9df50a1dd9 upstream.
This patch adds the IDE-mode SATA DeviceIDs for the Intel Avoton SOC.
Signed-off-by: Seth Heasley
Signed-off-by: Jeff Garzik
Signed-off-by: Luis Henriques
---
drivers/ata/ata_piix.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 36b5276..5e01966 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -331,6 +331,14 @@ static const struct pci_device_id piix_pci_tbl[] = {
{ 0x8086, 0x8c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (DH89xxCC) */
{ 0x8086, 0x2326, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ /* SATA Controller IDE (Avoton) */
+ { 0x8086, 0x1f20, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+ /* SATA Controller IDE (Avoton) */
+ { 0x8086, 0x1f21, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+ /* SATA Controller IDE (Avoton) */
+ { 0x8086, 0x1f30, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ /* SATA Controller IDE (Avoton) */
+ { 0x8086, 0x1f31, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
{ } /* terminate list */
};
--
1.8.1.2
--
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 40/88] ata_piix: Add Device IDs for Intel Wellsburg PCH
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: James Ralston
commit 3aee8bc52c415aba8148f144e5e5359b0fd75dd1 upstream.
This patch adds the IDE-mode SATA Device IDs for the Intel Wellsburg PCH
Signed-off-by: James Ralston
Signed-off-by: Jeff Garzik
Signed-off-by: Luis Henriques
---
drivers/ata/ata_piix.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 5e01966..47bd6ab 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -339,6 +339,15 @@ static const struct pci_device_id piix_pci_tbl[] = {
{ 0x8086, 0x1f30, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (Avoton) */
{ 0x8086, 0x1f31, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ /* SATA Controller IDE (Wellsburg) */
+ { 0x8086, 0x8d00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+ /* SATA Controller IDE (Wellsburg) */
+ { 0x8086, 0x8d08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ /* SATA Controller IDE (Wellsburg) */
+ { 0x8086, 0x8d60, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+ /* SATA Controller IDE (Wellsburg) */
+ { 0x8086, 0x8d68, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+
{ } /* terminate list */
};
--
1.8.1.2
--
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 2/3] ARM: davinci: da850: Enable EHRPWM TBCLK from CFG_CHIP1
da850 platforms require TBCLK synchronization in CFG_CHIP1 register for
TBCLK enable in EHRPWM modules. Enabling of TBCLK is done only if EHRPWM
DT node status is set to "okay" DT blob.
Also adds macro definitions for DA8XX_EHRPWM_TBCLKSYNC and
DA8XX_CFGCHIP1_REG.
Signed-off-by: Philip Avinash
---
:100644 100644 6b7a0a2... 72466ab... M arch/arm/mach-davinci/da8xx-dt.c
:100644 100644 de439b7... be77ce2... M
arch/arm/mach-davinci/include/mach/da8xx.h
arch/arm/mach-davinci/da8xx-dt.c | 15 +++
arch/arm/mach-davinci/include/mach/da8xx.h |1 +
2 files changed, 16 insertions(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 6b7a0a2..72466ab 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -19,6 +19,7 @@
#include
#define DA8XX_NUM_UARTS3
+#define DA8XX_EHRPWM_TBCLKSYNC BIT(12)
void __init da8xx_uart_clk_enable(void)
{
@@ -47,10 +48,24 @@ struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
static void __init da850_init_machine(void)
{
+ struct device_node *ehrpwm_np;
+ const char *ehrpwm_compat = "ti,da850-ehrpwm";
+ void __iomem *cfg_chip1_base;
+
+ cfg_chip1_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP1_REG);
+
of_platform_populate(NULL, of_default_bus_match_table,
da850_auxdata_lookup, NULL);
da8xx_uart_clk_enable();
+
+ for_each_compatible_node(ehrpwm_np, NULL, ehrpwm_compat)
+ if (of_device_is_available(ehrpwm_np)) {
+ /* Enable TBCLK synchronization for EHRWPM modules */
+ writel(readl(cfg_chip1_base) | DA8XX_EHRPWM_TBCLKSYNC,
+ cfg_chip1_base);
+ break;
+ }
}
static const char *da850_boards_compat[] __initdata = {
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
b/arch/arm/mach-davinci/include/mach/da8xx.h
index de439b7..be77ce2 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -55,6 +55,7 @@ extern unsigned int da850_max_speed;
#define DA8XX_SYSCFG0_VIRT(x) (da8xx_syscfg0_base + (x))
#define DA8XX_JTAG_ID_REG 0x18
#define DA8XX_CFGCHIP0_REG 0x17c
+#define DA8XX_CFGCHIP1_REG 0x180
#define DA8XX_CFGCHIP2_REG 0x184
#define DA8XX_CFGCHIP3_REG 0x188
--
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 2/2] usb: dwc3: exynos: use clk_prepare_enable and clk_disable_unprepare
Hi, On Thu, Mar 14, 2013 at 04:14:58PM +0530, Vivek Gautam wrote: > Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare > calls as required by common clock framework. > > Signed-off-by: Vivek Gautam > CC: Felipe Balbi > CC: Kukjin Kim > --- > drivers/usb/dwc3/dwc3-exynos.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c > index 66ca9ac..b03f609 100644 > --- a/drivers/usb/dwc3/dwc3-exynos.c > +++ b/drivers/usb/dwc3/dwc3-exynos.c > @@ -129,7 +129,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev) > exynos->dev = dev; > exynos->clk = clk; > > - clk_enable(exynos->clk); > + clk_prepare_enable(exynos->clk); eventually we need to pass this clock handling to dwc3/core.c. Just make sure it's optional since not all platforms need it. I guess the best way would be to handle clocks via ->runtime_suspend()/->runtime_resume() ?? -- balbi signature.asc Description: Digital signature
[PATCH 1/1] mfd: palmas: Add power off control
Hook up "pm_power_off" to palmas power off routine if there is DT
property "ti,system-power-controller" defined, so platform which is
powered by this regulator can be powered off properly.
Based on work by:
Mallikarjun Kasoju
Signed-off-by: Bill Huang
---
drivers/mfd/palmas.c | 25 +++--
include/linux/mfd/palmas.h |1 +
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index bbdbc50..ee8180d 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -283,6 +283,22 @@ static void palmas_dt_to_pdata(struct device_node *node,
pdata->power_ctrl = PALMAS_POWER_CTRL_NSLEEP_MASK |
PALMAS_POWER_CTRL_ENABLE1_MASK |
PALMAS_POWER_CTRL_ENABLE2_MASK;
+
+ pdata->pm_off = of_property_read_bool(node,
+ "ti,system-power-controller");
+}
+
+static struct palmas *palmas_dev;
+static void palmas_power_off(void)
+{
+ unsigned int addr;
+
+ if (!palmas_dev)
+ return;
+
+ addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);
+
+ regmap_update_bits(palmas_dev->regmap[0], addr, 1, 0);
}
static int palmas_i2c_probe(struct i2c_client *i2c,
@@ -435,10 +451,15 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
*/
if (node) {
ret = of_platform_populate(node, NULL, NULL, &i2c->dev);
- if (ret < 0)
+ if (ret < 0) {
goto err_irq;
- else
+ } else {
+ if (pdata->pm_off && !pm_power_off) {
+ palmas_dev = palmas;
+ pm_power_off = palmas_power_off;
+ }
return ret;
+ }
}
children = kmemdup(palmas_children, sizeof(palmas_children),
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index a4d13d7..a447e54 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -232,6 +232,7 @@ struct palmas_platform_data {
*/
int mux_from_pdata;
u8 pad1, pad2;
+ bool pm_off;
struct palmas_pmic_platform_data *pmic_pdata;
struct palmas_gpadc_platform_data *gpadc_pdata;
--
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/
[PATCH 43/88] fs: cachefiles: add support for large files in filesystem caching
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Justin Lecher
commit 98c350cda2c14a343d34ea01a3d9c24fea5ec66d upstream.
Support the caching of large files.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=31182
Signed-off-by: Justin Lecher
Signed-off-by: Suresh Jayaraman
Tested-by: Suresh Jayaraman
Acked-by: David Howells
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
[ luis: adjust context ]
Signed-off-by: Luis Henriques
---
fs/cachefiles/rdwr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cachefiles/rdwr.c b/fs/cachefiles/rdwr.c
index 0e3c092..b4d2438 100644
--- a/fs/cachefiles/rdwr.c
+++ b/fs/cachefiles/rdwr.c
@@ -918,7 +918,7 @@ int cachefiles_write_page(struct fscache_storage *op,
struct page *page)
* own time */
dget(object->backer);
mntget(cache->mnt);
- file = dentry_open(object->backer, cache->mnt, O_RDWR,
+ file = dentry_open(object->backer, cache->mnt, O_RDWR | O_LARGEFILE,
cache->cache_cred);
if (IS_ERR(file)) {
ret = PTR_ERR(file);
--
1.8.1.2
--
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 45/88] usb hid quirks for Masterkit MA901 usb radio
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Alexey Klimov
commit 0322bd3980b3ebf7dde8474e22614cb443d6479a upstream.
Don't let Masterkit MA901 USB radio be handled by usb hid drivers.
This device will be handled by radio-ma901.c driver.
Signed-off-by: Alexey Klimov
Acked-by: Hans Verkuil
Acked-by: Jiri Kosina
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Luis Henriques
---
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 3cb5c99..52bc936 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2012,6 +2012,7 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_HYBRID) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_HEATCONTROL) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_BEATPAD)
},
+ { HID_USB_DEVICE(USB_VENDOR_ID_MASTERKIT,
USB_DEVICE_ID_MASTERKIT_MA901RADIO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MCC, USB_DEVICE_ID_MCC_PMD1024LS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MCC, USB_DEVICE_ID_MCC_PMD1208LS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICKIT1) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index dc48cd1..de39a12 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -532,6 +532,9 @@
#define USB_VENDOR_ID_MADCATZ 0x0738
#define USB_DEVICE_ID_MADCATZ_BEATPAD 0x4540
+#define USB_VENDOR_ID_MASTERKIT0x16c0
+#define USB_DEVICE_ID_MASTERKIT_MA901RADIO 0x05df
+
#define USB_VENDOR_ID_MCC 0x09db
#define USB_DEVICE_ID_MCC_PMD1024LS0x0076
#define USB_DEVICE_ID_MCC_PMD1208LS0x007a
--
1.8.1.2
--
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 41/88] ata_piix: Add Device IDs for Intel Lynx Point-LP PCH
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: James Ralston
commit 389cd784969e9148fedcde0608f15bd74d6b769e upstream.
This patch adds the IDE-mode SATA Device IDs for the Intel Lynx Point-LP PCH
Signed-off-by: James Ralston
Signed-off-by: Jeff Garzik
Signed-off-by: Luis Henriques
---
drivers/ata/ata_piix.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 47bd6ab..fe5973f 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -329,6 +329,14 @@ static const struct pci_device_id piix_pci_tbl[] = {
{ 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (Lynx Point) */
{ 0x8086, 0x8c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ /* SATA Controller IDE (Lynx Point-LP) */
+ { 0x8086, 0x9c00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+ /* SATA Controller IDE (Lynx Point-LP) */
+ { 0x8086, 0x9c01, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+ /* SATA Controller IDE (Lynx Point-LP) */
+ { 0x8086, 0x9c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ /* SATA Controller IDE (Lynx Point-LP) */
+ { 0x8086, 0x9c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (DH89xxCC) */
{ 0x8086, 0x2326, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (Avoton) */
--
1.8.1.2
--
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/2] usb: dwc3: exynos: Use of_platform API to create dwc3 core pdev
Hi,
On Thu, Mar 14, 2013 at 04:14:57PM +0530, Vivek Gautam wrote:
> @@ -170,7 +155,6 @@ static int dwc3_exynos_remove(struct platform_device
> *pdev)
> {
> struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
>
> - platform_device_unregister(exynos->dwc3);
don't you want to do what Kishon did here and have:
static int dwc3_exynos_remove_child(struct device *dev, void *unused)
{
struct platform_device *pdev = to_platform_device(dev);
platform_device_unregister(pdev);
return 0;
}
device_for_each_child(&pdev->dev, NULL, dwc3_exynos_remove_child);
???
--
balbi
signature.asc
Description: Digital signature
[PATCH 46/88] pstore: Avoid deadlock in panic and emergency-restart path
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Seiji Aguchi
commit 9f244e9cfd70c7c0f82d3c92ce772ab2a92d9f64 upstream.
[Issue]
When pstore is in panic and emergency-restart paths, it may be blocked
in those paths because it simply takes spin_lock.
This is an example scenario which pstore may hang up in a panic path:
- cpuA grabs psinfo->buf_lock
- cpuB panics and calls smp_send_stop
- smp_send_stop sends IRQ to cpuA
- after 1 second, cpuB gives up on cpuA and sends an NMI instead
- cpuA is now in an NMI handler while still holding buf_lock
- cpuB is deadlocked
This case may happen if a firmware has a bug and
cpuA is stuck talking with it more than one second.
Also, this is a similar scenario in an emergency-restart path:
- cpuA grabs psinfo->buf_lock and stucks in a firmware
- cpuB kicks emergency-restart via either sysrq-b or hangcheck timer.
And then, cpuB is deadlocked by taking psinfo->buf_lock again.
[Solution]
This patch avoids the deadlocking issues in both panic and emergency_restart
paths by introducing a function, is_non_blocking_path(), to check if a cpu
can be blocked in current path.
With this patch, pstore is not blocked even if another cpu has
taken a spin_lock, in those paths by changing from spin_lock_irqsave
to spin_trylock_irqsave.
In addition, according to a comment of emergency_restart() in kernel/sys.c,
spin_lock shouldn't be taken in an emergency_restart path to avoid
deadlock. This patch fits the comment below.
/**
* emergency_restart - reboot the system
*
* Without shutting down any hardware or taking any locks
* reboot the system. This is called when we know we are in
* trouble so this is our best effort to reboot. This is
* safe to call in interrupt context.
*/
void emergency_restart(void)
Signed-off-by: Seiji Aguchi
Acked-by: Don Zickus
Signed-off-by: Tony Luck
Signed-off-by: Luis Henriques
---
fs/pstore/platform.c | 35 +--
include/linux/pstore.h | 6 ++
2 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 03ce7a9..e1f4f8a 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -88,6 +88,27 @@ static const char *get_reason_str(enum kmsg_dump_reason
reason)
}
}
+bool pstore_cannot_block_path(enum kmsg_dump_reason reason)
+{
+ /*
+* In case of NMI path, pstore shouldn't be blocked
+* regardless of reason.
+*/
+ if (in_nmi())
+ return true;
+
+ switch (reason) {
+ /* In panic case, other cpus are stopped by smp_send_stop(). */
+ case KMSG_DUMP_PANIC:
+ /* Emergency restart shouldn't be blocked by spin lock. */
+ case KMSG_DUMP_EMERG:
+ return true;
+ default:
+ return false;
+ }
+}
+EXPORT_SYMBOL_GPL(pstore_cannot_block_path);
+
/*
* callback from kmsg_dump. (s2,l2) has the most recently
* written bytes, older bytes are in (s1,l1). Save as much
@@ -106,10 +127,12 @@ static void pstore_dump(struct kmsg_dumper *dumper,
why = get_reason_str(reason);
- if (in_nmi()) {
- is_locked = spin_trylock(&psinfo->buf_lock);
- if (!is_locked)
- pr_err("pstore dump routine blocked in NMI, may corrupt
error record\n");
+ if (pstore_cannot_block_path(reason)) {
+ is_locked = spin_trylock_irqsave(&psinfo->buf_lock, flags);
+ if (!is_locked) {
+ pr_err("pstore dump routine blocked in %s path, may
corrupt error record\n"
+ , in_nmi() ? "NMI" : why);
+ }
} else
spin_lock_irqsave(&psinfo->buf_lock, flags);
oopscount++;
@@ -135,9 +158,9 @@ static void pstore_dump(struct kmsg_dumper *dumper,
total += hsize + len;
part++;
}
- if (in_nmi()) {
+ if (pstore_cannot_block_path(reason)) {
if (is_locked)
- spin_unlock(&psinfo->buf_lock);
+ spin_unlock_irqrestore(&psinfo->buf_lock, flags);
} else
spin_unlock_irqrestore(&psinfo->buf_lock, flags);
}
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index e1461e1..318cca1 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -54,12 +54,18 @@ struct pstore_info {
#ifdef CONFIG_PSTORE
extern int pstore_register(struct pstore_info *);
+extern bool pstore_cannot_block_path(enum kmsg_dump_reason reason);
#else
static inline int
pstore_register(struct pstore_info *psi)
{
return -ENODEV;
}
+static inline bool
+pstore_cannot_block_path(enum kmsg_dump_reason reason)
+{
+ return false;
+}
#endif
#endif /*_LINUX_PSTORE_H*/
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
[PATCH 47/88] unbreak automounter support on 64-bit kernel with 32-bit userspace (v2)
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: Helge Deller commit 4f4ffc3a5398ef9bdbb32db04756d7d34e356fcf upstream. automount-support is broken on the parisc architecture, because the existing architecture is similiar to other 64bit Linux targets where we have to define autofs_wqt_t (which is passed back and forth to user space) as int type which has a size of 32bit across 32 and 64bit kernels. During the discussion on the mailing list, H. Peter Anvin suggested to invert the #if list since only specific platforms (specifically those who do not have a 32bit userspace, like IA64 and Alpha) should have autofs_wqt_t as unsigned long type. This suggestion is probably the best way to go, since Arm64 (and maybe others?) seems to have a non-working automounter. So in the long run even for other new upcoming architectures this inverted check seem to be the best solution, since it will not require them to change this #if again (unless they are 64bit only). Signed-off-by: Helge Deller Acked-by: H. Peter Anvin Acked-by: Ian Kent Acked-by: Catalin Marinas CC: James Bottomley CC: Rolf Eike Beer [ luis: adjusted file name ] Signed-off-by: Luis Henriques --- include/linux/auto_fs.h | 24 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/include/linux/auto_fs.h b/include/linux/auto_fs.h index da64e15..92bb651 100644 --- a/include/linux/auto_fs.h +++ b/include/linux/auto_fs.h @@ -31,25 +31,17 @@ #define AUTOFS_MIN_PROTO_VERSION AUTOFS_PROTO_VERSION /* - * Architectures where both 32- and 64-bit binaries can be executed - * on 64-bit kernels need this. This keeps the structure format - * uniform, and makes sure the wait_queue_token isn't too big to be - * passed back down to the kernel. - * - * This assumes that on these architectures: - * mode 32 bit64 bit - * - - * int 32 bit32 bit - * long 32 bit64 bit - * - * If so, 32-bit user-space code should be backwards compatible. + * The wait_queue_token (autofs_wqt_t) is part of a structure which is passed + * back to the kernel via ioctl from userspace. On architectures where 32- and + * 64-bit userspace binaries can be executed it's important that the size of + * autofs_wqt_t stays constant between 32- and 64-bit Linux kernels so that we + * do not break the binary ABI interface by changing the structure size. */ -#if defined(__sparc__) || defined(__mips__) || defined(__x86_64__) \ - || defined(__powerpc__) || defined(__s390__) -typedef unsigned int autofs_wqt_t; -#else +#if defined(__ia64__) || defined(__alpha__) /* pure 64bit architectures */ typedef unsigned long autofs_wqt_t; +#else +typedef unsigned int autofs_wqt_t; #endif /* Packet types */ -- 1.8.1.2 -- 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 49/88] workqueue: consider work function when searching for busy work items
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Tejun Heo
commit a2c1c57be8d9fd5b716113c8991d3d702eeacf77 upstream.
To avoid executing the same work item concurrenlty, workqueue hashes
currently busy workers according to their current work items and looks
up the the table when it wants to execute a new work item. If there
already is a worker which is executing the new work item, the new item
is queued to the found worker so that it gets executed only after the
current execution finishes.
Unfortunately, a work item may be freed while being executed and thus
recycled for different purposes. If it gets recycled for a different
work item and queued while the previous execution is still in
progress, workqueue may make the new work item wait for the old one
although the two aren't really related in any way.
In extreme cases, this false dependency may lead to deadlock although
it's extremely unlikely given that there aren't too many self-freeing
work item users and they usually don't wait for other work items.
To alleviate the problem, record the current work function in each
busy worker and match it together with the work item address in
find_worker_executing_work(). While this isn't complete, it ensures
that unrelated work items don't interact with each other and in the
very unlikely case where a twisted wq user triggers it, it's always
onto itself making the culprit easy to spot.
Signed-off-by: Tejun Heo
Reported-by: Andrey Isakov
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51701
Signed-off-by: Luis Henriques
---
kernel/workqueue.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index a6a4c90..dd488af 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -128,6 +128,7 @@ struct worker {
};
struct work_struct *current_work; /* L: work being processed */
+ work_func_t current_func; /* L: current_work's fn */
struct cpu_workqueue_struct *current_cwq; /* L: current_work's cwq */
struct list_headscheduled; /* L: scheduled works */
struct task_struct *task; /* I: worker task */
@@ -838,7 +839,8 @@ static struct worker *__find_worker_executing_work(struct
global_cwq *gcwq,
struct hlist_node *tmp;
hlist_for_each_entry(worker, tmp, bwh, hentry)
- if (worker->current_work == work)
+ if (worker->current_work == work &&
+ worker->current_func == work->func)
return worker;
return NULL;
}
@@ -848,9 +850,27 @@ static struct worker *__find_worker_executing_work(struct
global_cwq *gcwq,
* @gcwq: gcwq of interest
* @work: work to find worker for
*
- * Find a worker which is executing @work on @gcwq. This function is
- * identical to __find_worker_executing_work() except that this
- * function calculates @bwh itself.
+ * Find a worker which is executing @work on @gcwq by searching
+ * @gcwq->busy_hash which is keyed by the address of @work. For a worker
+ * to match, its current execution should match the address of @work and
+ * its work function. This is to avoid unwanted dependency between
+ * unrelated work executions through a work item being recycled while still
+ * being executed.
+ *
+ * This is a bit tricky. A work item may be freed once its execution
+ * starts and nothing prevents the freed area from being recycled for
+ * another work item. If the same work item address ends up being reused
+ * before the original execution finishes, workqueue will identify the
+ * recycled work item as currently executing and make it wait until the
+ * current execution finishes, introducing an unwanted dependency.
+ *
+ * This function checks the work item address, work function and workqueue
+ * to avoid false positives. Note that this isn't complete as one may
+ * construct a work function which can introduce dependency onto itself
+ * through a recycled work item. Well, if somebody wants to shoot oneself
+ * in the foot that badly, there's only so much we can do, and if such
+ * deadlock actually occurs, it should be easy to locate the culprit work
+ * function.
*
* CONTEXT:
* spin_lock_irq(gcwq->lock).
@@ -1807,7 +1827,6 @@ __acquires(&gcwq->lock)
struct global_cwq *gcwq = cwq->gcwq;
struct hlist_head *bwh = busy_worker_head(gcwq, work);
bool cpu_intensive = cwq->wq->flags & WQ_CPU_INTENSIVE;
- work_func_t f = work->func;
int work_color;
struct worker *collision;
#ifdef CONFIG_LOCKDEP
@@ -1838,6 +1857,7 @@ __acquires(&gcwq->lock)
debug_work_deactivate(work);
hlist_add_head(&worker->hentry, bwh);
worker->current_work = work;
+ worker->current_func = work->func;
worker->current_cwq = cwq;
work_color = get_work_color(work);
@@ -1875,7 +1
[PATCH v2] mm/hugetlb: fix total hugetlbfs pages count when memory overcommit accouting
Changelog:
v1 -> v2:
* update patch description, spotted by Michal
hugetlb_total_pages() does not account for all the supported hugepage
sizes. This can lead to incorrect calculation of the total number of
page frames used by hugetlb. This patch corrects the issue.
Testcase:
boot: hugepagesz=1G hugepages=1
before patch:
egrep 'CommitLimit' /proc/meminfo
CommitLimit: 55434168 kB
after patch:
egrep 'CommitLimit' /proc/meminfo
CommitLimit: 54909880 kB
Signed-off-by: Wanpeng Li
---
mm/hugetlb.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index cdb64e4..9e25040 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2124,8 +2124,11 @@ int hugetlb_report_node_meminfo(int nid, char *buf)
/* Return the number pages of memory we physically have, in PAGE_SIZE units. */
unsigned long hugetlb_total_pages(void)
{
- struct hstate *h = &default_hstate;
- return h->nr_huge_pages * pages_per_huge_page(h);
+ struct hstate *h;
+ unsigned long nr_total_pages = 0;
+ for_each_hstate(h)
+ nr_total_pages += h->nr_huge_pages * pages_per_huge_page(h);
+ return nr_total_pages;
}
static int hugetlb_acct_memory(struct hstate *h, long delta)
--
1.7.11.7
--
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 42/88] exec: use -ELOOP for max recursion depth
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
commit d740269867021faf4ce38a449353d2b986c34a67 upstream.
To avoid an explosion of request_module calls on a chain of abusive
scripts, fail maximum recursion with -ELOOP instead of -ENOEXEC. As soon
as maximum recursion depth is hit, the error will fail all the way back
up the chain, aborting immediately.
This also has the side-effect of stopping the user's shell from attempting
to reexecute the top-level file as a shell script. As seen in the
dash source:
if (cmd != path_bshell && errno == ENOEXEC) {
*argv-- = cmd;
*argv = cmd = path_bshell;
goto repeat;
}
The above logic was designed for running scripts automatically that lacked
the "#!" header, not to re-try failed recursion. On a legitimate -ENOEXEC,
things continue to behave as the shell expects.
Additionally, when tracking recursion, the binfmt handlers should not be
involved. The recursion being tracked is the depth of calls through
search_binary_handler(), so that function should be exclusively responsible
for tracking the depth.
Signed-off-by: Kees Cook
Cc: halfdog
Cc: P J P
Cc: Alexander Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
[ luis: backport to 3.5 ]
Signed-off-by: Luis Henriques
---
fs/binfmt_em86.c| 1 -
fs/binfmt_misc.c| 8 +---
fs/binfmt_script.c | 4 +---
fs/exec.c | 10 +-
include/linux/binfmts.h | 2 --
5 files changed, 7 insertions(+), 18 deletions(-)
diff --git a/fs/binfmt_em86.c b/fs/binfmt_em86.c
index 2790c7e..575796a 100644
--- a/fs/binfmt_em86.c
+++ b/fs/binfmt_em86.c
@@ -42,7 +42,6 @@ static int load_em86(struct linux_binprm *bprm,struct pt_regs
*regs)
return -ENOEXEC;
}
- bprm->recursion_depth++; /* Well, the bang-shell is implicit... */
allow_write_access(bprm->file);
fput(bprm->file);
bprm->file = NULL;
diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index 772428d..233dcb4 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -117,10 +117,6 @@ static int load_misc_binary(struct linux_binprm *bprm,
struct pt_regs *regs)
if (!enabled)
goto _ret;
- retval = -ENOEXEC;
- if (bprm->recursion_depth > BINPRM_MAX_RECURSION)
- goto _ret;
-
/* to keep locking time low, we copy the interpreter string */
read_lock(&entries_lock);
fmt = check_file(bprm);
@@ -200,9 +196,7 @@ static int load_misc_binary(struct linux_binprm *bprm,
struct pt_regs *regs)
if (retval < 0)
goto _error;
- bprm->recursion_depth++;
-
- retval = search_binary_handler (bprm, regs);
+ retval = search_binary_handler(bprm, regs);
if (retval < 0)
goto _error;
diff --git a/fs/binfmt_script.c b/fs/binfmt_script.c
index df49d48..8ae4be1 100644
--- a/fs/binfmt_script.c
+++ b/fs/binfmt_script.c
@@ -22,15 +22,13 @@ static int load_script(struct linux_binprm *bprm,struct
pt_regs *regs)
char interp[BINPRM_BUF_SIZE];
int retval;
- if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!') ||
- (bprm->recursion_depth > BINPRM_MAX_RECURSION))
+ if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!'))
return -ENOEXEC;
/*
* This section does the #! interpretation.
* Sorta complicated, but hopefully it will work. -TYT
*/
- bprm->recursion_depth++;
allow_write_access(bprm->file);
fput(bprm->file);
bprm->file = NULL;
diff --git a/fs/exec.c b/fs/exec.c
index 5ee73d2..858423a 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1398,6 +1398,10 @@ int search_binary_handler(struct linux_binprm
*bprm,struct pt_regs *regs)
struct linux_binfmt *fmt;
pid_t old_pid, old_vpid;
+ /* This allows 4 levels of binfmt rewrites before failing hard. */
+ if (depth > 5)
+ return -ELOOP;
+
retval = security_bprm_check(bprm);
if (retval)
return retval;
@@ -1422,12 +1426,8 @@ int search_binary_handler(struct linux_binprm
*bprm,struct pt_regs *regs)
if (!try_module_get(fmt->module))
continue;
read_unlock(&binfmt_lock);
+ bprm->recursion_depth = depth + 1;
retval = fn(bprm, regs);
- /*
-* Restore the depth counter to its starting value
-* in this call, so we don't have to rely on every
-* load_binary function to restore it on return.
-*/
bprm->recursion_depth = depth;
if (retval >= 0) {
if (depth == 0) {
diff --git a/include/linux/binfmts
[PATCH 44/88] fuse: don't WARN when nlink is zero
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: Miklos Szeredi commit dfca7cebc2679f3d129f8e680a8f199a7ad16e38 upstream. drop_nlink() warns if nlink is already zero. This is triggerable by a buggy userspace filesystem. The cure, I think, is worse than the disease so disable the warning. Reported-by: Tero Roponen Signed-off-by: Miklos Szeredi Signed-off-by: Luis Henriques --- fs/fuse/dir.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c index 334e0b1..f6e4bc8 100644 --- a/fs/fuse/dir.c +++ b/fs/fuse/dir.c @@ -645,7 +645,14 @@ static int fuse_unlink(struct inode *dir, struct dentry *entry) spin_lock(&fc->lock); fi->attr_version = ++fc->attr_version; - drop_nlink(inode); + /* +* If i_nlink == 0 then unlink doesn't make sense, yet this can +* happen if userspace filesystem is careless. It would be +* difficult to enforce correct nlink usage so just ignore this +* condition here +*/ + if (inode->i_nlink > 0) + drop_nlink(inode); spin_unlock(&fc->lock); fuse_invalidate_attr(inode); fuse_invalidate_attr(dir); -- 1.8.1.2 -- 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 37/88] nfsd: add get_uint for u32's
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: "J. Bruce Fields"
commit a007c4c3e943ecc054a806c259d95420a188754b upstream.
I don't think there's a practical difference for the range of values
these interfaces should see, but it would be safer to be unambiguous.
Signed-off-by: J. Bruce Fields
Signed-off-by: Luis Henriques
---
fs/nfsd/export.c | 6 +++---
include/linux/sunrpc/cache.h | 16
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
index ba23349..1114463 100644
--- a/fs/nfsd/export.c
+++ b/fs/nfsd/export.c
@@ -398,7 +398,7 @@ fsloc_parse(char **mesg, char *buf, struct
nfsd4_fs_locations *fsloc)
int migrated, i, err;
/* listsize */
- err = get_int(mesg, &fsloc->locations_count);
+ err = get_uint(mesg, &fsloc->locations_count);
if (err)
return err;
if (fsloc->locations_count > MAX_FS_LOCATIONS)
@@ -456,7 +456,7 @@ static int secinfo_parse(char **mesg, char *buf, struct
svc_export *exp)
return -EINVAL;
for (f = exp->ex_flavors; f < exp->ex_flavors + listsize; f++) {
- err = get_int(mesg, &f->pseudoflavor);
+ err = get_uint(mesg, &f->pseudoflavor);
if (err)
return err;
/*
@@ -465,7 +465,7 @@ static int secinfo_parse(char **mesg, char *buf, struct
svc_export *exp)
* problem at export time instead of when a client fails
* to authenticate.
*/
- err = get_int(mesg, &f->flags);
+ err = get_uint(mesg, &f->flags);
if (err)
return err;
/* Only some flags are allowed to differ between flavors: */
diff --git a/include/linux/sunrpc/cache.h b/include/linux/sunrpc/cache.h
index f5fd616..dd2bb84 100644
--- a/include/linux/sunrpc/cache.h
+++ b/include/linux/sunrpc/cache.h
@@ -228,6 +228,22 @@ static inline int get_int(char **bpp, int *anint)
return 0;
}
+static inline int get_uint(char **bpp, unsigned int *anint)
+{
+ char buf[50];
+ int len = qword_get(bpp, buf, sizeof(buf));
+
+ if (len < 0)
+ return -EINVAL;
+ if (len == 0)
+ return -ENOENT;
+
+ if (kstrtouint(buf, 0, anint))
+ return -EINVAL;
+
+ return 0;
+}
+
/*
* timestamps kept in the cache are expressed in seconds
* since boot. This is the best for measuring differences in
--
1.8.1.2
--
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 38/88] asus-laptop: Do not call HWRS on init
3.5.7.8 -stable review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
commit cb7da022450cdaaebd33078b6b32fb7dd2aaf6db upstream.
Since commit 8871e99f89b7 ('asus-laptop: HRWS/HWRS typo'), module
initialisation is very slow on the Asus UL30A. The HWRS method takes
about 12 seconds to run, and subsequent initialisation also seems to
be delayed. Since we don't really need the result, don't bother
calling it on init. Those who are curious can still get the result
through the 'infos' device attribute.
Update the comment about HWRS in show_infos().
Reported-by: ryan
References: http://bugs.debian.org/692436
Signed-off-by: Ben Hutchings
Signed-off-by: Corentin Chary
Signed-off-by: Matthew Garrett
Signed-off-by: Luis Henriques
---
drivers/platform/x86/asus-laptop.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index 110c777..12da810 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -860,8 +860,10 @@ static ssize_t show_infos(struct device *dev,
/*
* The HWRS method return informations about the hardware.
* 0x80 bit is for WLAN, 0x100 for Bluetooth.
+* 0x40 for WWAN, 0x10 for WIMAX.
* The significance of others is yet to be found.
-* If we don't find the method, we assume the device are present.
+* We don't currently use this for device detection, and it
+* takes several seconds to run on some systems.
*/
rv = acpi_evaluate_integer(asus->handle, "HWRS", NULL, &temp);
if (!ACPI_FAILURE(rv))
@@ -1682,7 +1684,7 @@ static int asus_laptop_get_info(struct asus_laptop *asus)
{
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *model = NULL;
- unsigned long long bsts_result, hwrs_result;
+ unsigned long long bsts_result;
char *string = NULL;
acpi_status status;
@@ -1744,17 +1746,6 @@ static int asus_laptop_get_info(struct asus_laptop *asus)
if (*string)
pr_notice(" %s model detected\n", string);
- /*
-* The HWRS method return informations about the hardware.
-* 0x80 bit is for WLAN, 0x100 for Bluetooth,
-* 0x40 for WWAN, 0x10 for WIMAX.
-* The significance of others is yet to be found.
-*/
- status =
- acpi_evaluate_integer(asus->handle, "HWRS", NULL, &hwrs_result);
- if (!ACPI_FAILURE(status))
- pr_notice(" HWRS returned %x", (int)hwrs_result);
-
if (!acpi_check_handle(asus->handle, METHOD_WL_STATUS, NULL))
asus->have_rsts = true;
--
1.8.1.2
--
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 33/88] xenbus: fix compile failure on ARM with Xen enabled
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: Steven Noonan commit 45e27161c62216c163880d7aed751cb55a65c8e9 upstream. Adding an include of linux/mm.h resolves this: drivers/xen/xenbus/xenbus_client.c: In function ‘xenbus_map_ring_valloc_hvm’: drivers/xen/xenbus/xenbus_client.c:532:66: error: implicit declaration of function ‘page_to_section’ [-Werror=implicit-function-declaration] Signed-off-by: Steven Noonan Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Luis Henriques --- drivers/xen/xenbus/xenbus_client.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c index b3e146e..1a77f2b 100644 --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -30,6 +30,7 @@ * IN THE SOFTWARE. */ +#include #include #include #include -- 1.8.1.2 -- 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] Platform support for EHRPWM & ECAP devices in Davinci.
Add platform support for EHRPWM and ECAP by providing clock nodes and device tree nodes. This series depends on [1] and [2] and is available for testing at [3] [1] http://gitorious.org/linux-davinci/linux-davinci/trees/davinci-for-v3.9/dt-2 [2] https://gitorious.org/linux-pwm/linux-pwm/trees/for-next [3] https://github.com/avinashphilip/am335x_linux/tree/davinci-for-v3.9_soc_pwm Philip Avinash (3): arm: davinci: clock node support for ECAP & EHRPWM ARM: davinci: da850: Enable EHRPWM TBCLK from CFG_CHIP1 ARM: davinci: da850: add EHRPWM & ECAP DT node arch/arm/boot/dts/da850.dtsi | 30 arch/arm/mach-davinci/da850.c | 24 ++ arch/arm/mach-davinci/da8xx-dt.c | 20 +++ arch/arm/mach-davinci/include/mach/da8xx.h |1 + 4 files changed, 75 insertions(+) -- 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/
[PATCH 48/88] vhost: fix length for cross region descriptor
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: "Michael S. Tsirkin" commit bd97120fc3d1a11f3124c7c9ba1d91f51829eb85 upstream. If a single descriptor crosses a region, the second chunk length should be decremented by size translated so far, instead it includes the full descriptor length. Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Luis Henriques --- drivers/vhost/vhost.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 112156f..6da514b 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -1077,7 +1077,7 @@ static int translate_desc(struct vhost_dev *dev, u64 addr, u32 len, } _iov = iov + ret; size = reg->memory_size - addr + reg->guest_phys_addr; - _iov->iov_len = min((u64)len, size); + _iov->iov_len = min((u64)len - s, size); _iov->iov_base = (void __user *)(unsigned long) (reg->userspace_addr + addr - reg->guest_phys_addr); s += size; -- 1.8.1.2 -- 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 -next] linux/linkage.h: fix symbol prefix handling
On 14/03/13 04:00, Rusty Russell wrote:
> From: Rusty Russell
> Subject: CONFIG_SYMBOL_PREFIX: cleanup.
>
> We have CONFIG_SYMBOL_PREFIX, which three archs define to the string
> "_". But Al Viro broke this in "consolidate cond_syscall and
> SYSCALL_ALIAS declarations" (in linux-next), and he's not the first to
> do so.
>
> Using CONFIG_SYMBOL_PREFIX is awkward, since we usually just want to
> prefix it so something. So various places define helpers which are
> defined to nothing if CONFIG_SYMBOL_PREFIX isn't set:
>
> 1) include/asm-generic/unistd.h defines __SYMBOL_PREFIX.
> 2) include/asm-generic/vmlinux.lds.h defines VMLINUX_SYMBOL(sym)
> 3) include/linux/export.h defines MODULE_SYMBOL_PREFIX.
> 4) include/linux/kernel.h defines SYMBOL_PREFIX (which differs from #7)
> 5) kernel/modsign_certificate.S defines ASM_SYMBOL(sym)
> 6) scripts/modpost.c defines MODULE_SYMBOL_PREFIX
> 7) scripts/Makefile.lib defines SYMBOL_PREFIX on the commandline if
>CONFIG_SYMBOL_PREFIX is set, so that we have a non-string version
>for pasting.
>
> (arch/h8300/include/asm/linkage.h defines SYMBOL_NAME(), too).
>
> Let's solve this properly:
> 1) No more generic prefix, just CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX.
> 2) Make linux/export.h usable from asm.
> 3) Define VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR().
> 4) Make everyone use them.
>
> Signed-off-by: Rusty Russell
Reviewed-by: James Hogan
Tested-by: James Hogan (metag)
The only other special case of symbol prefixing I'm aware of is in
scripts/genksyms/genksyms.c. It makes the decision at runtime based
on the --arch=$ARCH argument, and is the only use of the arch argument:
> if ((strcmp(arch, "h8300") == 0) || (strcmp(arch, "blackfin") == 0) ||
> (strcmp(arch, "metag") == 0))
> mod_prefix = "_";
Does the patch below look reasonable in addition to your patch?
(Note: I'm not sure if genksyms is only used internally or whether
it's API should be kept stable?).
Thanks
James
Subject: [PATCH] genksyms: pass symbol-prefix instead of arch
Pass symbol-prefix to genksyms instead of arch, so that the decision
what symbol prefix to use is kept in one place.
Basically genksyms used to take a -a $ARCH argument and it used that to
determine whether to add an underscore symbol prefix. It's now changed
to take a -s $SYMBOL_PREFIX argument so that the caller decides whether
a symbol prefix is required. The build system then uses
CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX to determine whether to pass the
argument.
Signed-off-by: James Hogan
---
scripts/Makefile.build | 3 ++-
scripts/genksyms/genksyms.c | 18 +++---
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 0e801c3..d5d859c 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -211,7 +211,8 @@ $(obj)/%.i: $(src)/%.c FORCE
cmd_gensymtypes = \
$(CPP) -D__GENKSYMS__ $(c_flags) $< | \
-$(GENKSYMS) $(if $(1), -T $(2)) -a $(ARCH) \
+$(GENKSYMS) $(if $(1), -T $(2)) \
+ $(patsubst y,-s _,$(CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX)) \
$(if $(KBUILD_PRESERVE),-p)\
-r $(firstword $(wildcard $(2:.symtypes=.symref) /dev/null))
diff --git a/scripts/genksyms/genksyms.c b/scripts/genksyms/genksyms.c
index d25e4a1..88632df 100644
--- a/scripts/genksyms/genksyms.c
+++ b/scripts/genksyms/genksyms.c
@@ -45,7 +45,6 @@ int in_source_file;
static int flag_debug, flag_dump_defs, flag_reference, flag_dump_types,
flag_preserve, flag_warnings;
-static const char *arch = "";
static const char *mod_prefix = "";
static int errors;
@@ -731,7 +730,7 @@ static void genksyms_usage(void)
{
fputs("Usage:\n" "genksyms [-adDTwqhV] > /path/to/.tmp_obj.ver\n" "\n"
#ifdef __GNU_LIBRARY__
- " -a, --archSelect architecture\n"
+ " -s, --symbol-prefix Select symbol prefix\n"
" -d, --debug Increment the debug level (repeatable)\n"
" -D, --dumpDump expanded symbol defs (for debugging
only)\n"
" -r, --reference file Read reference symbols from a file\n"
@@ -742,7 +741,7 @@ static void genksyms_usage(void)
" -h, --helpPrint this message\n"
" -V, --version Print the release version\n"
#else /* __GNU_LIBRARY__ */
- " -aSelect architecture\n"
+ " -sSelect symbol prefix\n"
" -dIncrement the debug level (repeatable)\n"
" -DDump expanded symbol defs (for debugging
only)\n"
" -r file Read reference symbols from a file\n"
@@
[PATCH 52/88] md: fix two bugs when attempting to resize RAID0 array.
3.5.7.8 -stable review patch. If anyone has any objections, please let me know. -- From: NeilBrown commit a64685399181780998281fe07309a94b25dd24c3 upstream. You cannot resize a RAID0 array (in terms of making the devices bigger), but the code doesn't entirely stop you. So: disable setting of the available size on each device for RAID0 and Linear devices. This must not change as doing so can change the effective layout of data. Make sure that the size that raid0_size() reports is accurate, but rounding devices sizes to chunk sizes. As the device sizes cannot change now, this isn't so important, but it is best to be safe. Without this change: mdadm --grow /dev/md0 -z max mdadm --grow /dev/md0 -Z max then read to the end of the array can cause a BUG in a RAID0 array. These bugs have been present ever since it became possible to resize any device, which is a long time. So the fix is suitable for any -stable kerenl. Signed-off-by: NeilBrown Signed-off-by: Luis Henriques --- drivers/md/md.c| 3 +++ drivers/md/raid0.c | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index b7a551d..8a6f63c 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -3057,6 +3057,9 @@ rdev_size_store(struct md_rdev *rdev, const char *buf, size_t len) } else if (!sectors) sectors = (i_size_read(rdev->bdev->bd_inode) >> 9) - rdev->data_offset; + if (!my_mddev->pers->resize) + /* Cannot change size for RAID0 or Linear etc */ + return -EINVAL; } if (sectors < my_mddev->dev_sectors) return -EINVAL; /* component must fit device */ diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c index de63a1f..08e1734 100644 --- a/drivers/md/raid0.c +++ b/drivers/md/raid0.c @@ -402,7 +402,8 @@ static sector_t raid0_size(struct mddev *mddev, sector_t sectors, int raid_disks "%s does not support generic reshape\n", __func__); rdev_for_each(rdev, mddev) - array_sectors += rdev->sectors; + array_sectors += (rdev->sectors & + ~(sector_t)(mddev->chunk_sectors-1)); return array_sectors; } -- 1.8.1.2 -- 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/
