[PATCH V2 2/7] perf, x86: Basic Haswell LBR call stack support
From: "Yan, Zheng"
The new HSW call stack feature provides a facility such that
unfiltered call data will be collected as normal, but as return
instructions are executed the last captured branch record is
popped from the LBR stack. Thus, branch information relative to
leaf functions will not be captured, while preserving the call
stack information of the main line execution path.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.h | 7 ++-
arch/x86/kernel/cpu/perf_event_intel.c | 2 +-
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 89 ++
3 files changed, 74 insertions(+), 24 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index ea6749a..a555a2c 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -413,7 +413,10 @@ struct x86_pmu {
};
enum {
- PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+ PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+ PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE,
+
+ PERF_SAMPLE_BRANCH_CALL_STACK = 1U <<
PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT,
};
#define x86_add_quirk(func_) \
@@ -635,6 +638,8 @@ void intel_pmu_lbr_init_atom(void);
void intel_pmu_lbr_init_snb(void);
+void intel_pmu_lbr_init_hsw(void);
+
int intel_pmu_setup_lbr_filter(struct perf_event *event);
int p4_pmu_init(void);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index 8d981c3..727fd74 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2353,7 +2353,7 @@ __init int intel_pmu_init(void)
memcpy(hw_cache_event_ids, snb_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
- intel_pmu_lbr_init_nhm();
+ intel_pmu_lbr_init_hsw();
x86_pmu.event_constraints = intel_hsw_event_constraints;
x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints;
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 7d9ae5f..9d35c54 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -31,6 +31,7 @@ enum {
#define LBR_IND_JMP_BIT6 /* do not capture indirect jumps */
#define LBR_REL_JMP_BIT7 /* do not capture relative jumps */
#define LBR_FAR_BIT8 /* do not capture far branches */
+#define LBR_CALL_STACK_BIT 9 /* enable call stack */
#define LBR_KERNEL (1 << LBR_KERNEL_BIT)
#define LBR_USER (1 << LBR_USER_BIT)
@@ -41,6 +42,7 @@ enum {
#define LBR_REL_JMP(1 << LBR_REL_JMP_BIT)
#define LBR_IND_JMP(1 << LBR_IND_JMP_BIT)
#define LBR_FAR(1 << LBR_FAR_BIT)
+#define LBR_CALL_STACK (1 << LBR_CALL_STACK_BIT)
#define LBR_PLM (LBR_KERNEL | LBR_USER)
@@ -66,24 +68,25 @@ enum {
* x86control flow changes include branches, interrupts, traps, faults
*/
enum {
- X86_BR_NONE = 0, /* unknown */
-
- X86_BR_USER = 1 << 0, /* branch target is user */
- X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
-
- X86_BR_CALL = 1 << 2, /* call */
- X86_BR_RET = 1 << 3, /* return */
- X86_BR_SYSCALL = 1 << 4, /* syscall */
- X86_BR_SYSRET = 1 << 5, /* syscall return */
- X86_BR_INT = 1 << 6, /* sw interrupt */
- X86_BR_IRET = 1 << 7, /* return from interrupt */
- X86_BR_JCC = 1 << 8, /* conditional */
- X86_BR_JMP = 1 << 9, /* jump */
- X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
- X86_BR_IND_CALL = 1 << 11,/* indirect calls */
- X86_BR_ABORT= 1 << 12,/* transaction abort */
- X86_BR_INTX = 1 << 13,/* in transaction */
- X86_BR_NOTX = 1 << 14,/* not in transaction */
+ X86_BR_NONE = 0, /* unknown */
+
+ X86_BR_USER = 1 << 0, /* branch target is user */
+ X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
+
+ X86_BR_CALL = 1 << 2, /* call */
+ X86_BR_RET = 1 << 3, /* return */
+ X86_BR_SYSCALL = 1 << 4, /* syscall */
+ X86_BR_SYSRET = 1 << 5, /* syscall return */
+ X86_BR_INT = 1 << 6, /* sw interrupt */
+ X86_BR_IRET = 1 << 7, /* return from interrupt */
+ X86_BR_JCC = 1 << 8, /* conditional */
+ X86_BR_JMP = 1 << 9, /* jump */
+ X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
+ X86_BR_IND_CALL = 1 << 11,/* indirect calls */
+ X86_BR_ABORT= 1 << 12,/* transaction abort */
+ X86_BR_INTX = 1 << 13,/* in transaction */
+ X86_BR_NOTX = 1 << 14,/* not in transaction */
[PATCH V2 7/7] perf, x86: Discard zero length call entries in LBR call stack
From: "Yan, Zheng"
Zero length calls may confuse the hardware and make the recorded
call stack incorrect. Try fixing the call stack by discarding
zero length call entries.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 4879904..012ddca 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -86,7 +86,8 @@ enum {
X86_BR_ABORT= 1 << 12,/* transaction abort */
X86_BR_INTX = 1 << 13,/* in transaction */
X86_BR_NOTX = 1 << 14,/* not in transaction */
- X86_BR_CALL_STACK = 1 << 15,/* call stack */
+ X86_BR_ZERO_CALL= 1 << 15,/* zero length call */
+ X86_BR_CALL_STACK = 1 << 16,/* call stack */
};
#define X86_BR_PLM (X86_BR_USER | X86_BR_KERNEL)
@@ -103,13 +104,15 @@ enum {
X86_BR_JMP |\
X86_BR_IRQ |\
X86_BR_ABORT|\
-X86_BR_IND_CALL)
+X86_BR_IND_CALL |\
+X86_BR_ZERO_CALL)
#define X86_BR_ALL (X86_BR_PLM | X86_BR_ANY)
#define X86_BR_ANY_CALL \
(X86_BR_CALL|\
X86_BR_IND_CALL|\
+X86_BR_ZERO_CALL |\
X86_BR_SYSCALL |\
X86_BR_IRQ |\
X86_BR_INT)
@@ -625,6 +628,12 @@ static int branch_type(unsigned long from, unsigned long
to, int abort)
ret = X86_BR_INT;
break;
case 0xe8: /* call near rel */
+ insn_get_immediate();
+ if (insn.immediate1.value == 0) {
+ /* zero length call */
+ ret = X86_BR_ZERO_CALL;
+ break;
+ }
case 0x9a: /* call far absolute */
ret = X86_BR_CALL;
break;
--
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/
RE: [PATCH v2 net-next 1/2] r8169: enable ALDPS for power saving
Francois Romieu [mailto:rom...@fr.zoreil.com]
[...]
> > +static void r810x_aldps_disable(struct rtl8169_private *tp)
> > +{
> > + rtl_writephy(tp, 0x1f, 0x);
> > + rtl_writephy(tp, 0x18, 0x0310);
> > + msleep(100);
> > +}
>
> rtl8402_hw_phy_config used a msleep(20). Meguesses it won't
> hurt, right ?
No, it won't hurt. The delay make suer there is enough time to pause ALDPS.
Best Regards,
Hayes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net-next 1/2] r8169: enable ALDPS for power saving
Francois Romieu [mailto:rom...@fr.zoreil.com] [...] > It would be nice to state these things in the commit message, namely: > - ALDPS should never be enabled for the RTL8105e > - none of the firmware-free chipsets support ALDPS > - neither do the RTL8168d/8111d Excuse me. I don't understand why the RTL8105e shouldn't enable ALDPS. Best Regards, Hayes -- 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] PWM: Add SPEAr PWM chip driver support
On Mon, Oct 22, 2012 at 02:20:26PM +0200, Lars-Peter Clausen wrote:
> On 10/22/2012 09:55 AM, Thierry Reding wrote:
> > On Mon, Oct 22, 2012 at 11:51:11AM +0530, Viresh Kumar wrote:
> >> On 22 October 2012 11:36, Shiraz Hashim wrote:
> >>> On Mon, Oct 22, 2012 at 09:39:21AM +0530, viresh kumar wrote:
> On Mon, Oct 22, 2012 at 9:21 AM, Shiraz Hashim
> wrote:
> >>
> > +static int spear_pwm_remove(struct platform_device *pdev)
> > +{
> > + struct spear_pwm_chip *pc = platform_get_drvdata(pdev);
> > + int i;
> > +
> > + for (i = 0; i < NUM_PWM; i++) {
> > + struct pwm_device *pwm = >chip.pwms[i];
> > +
> > + if (test_bit(PWMF_ENABLED, >flags)) {
> > + spear_pwm_writel(pc, i, PWMCR, 0);
> > + clk_disable(pc->clk);
> > + }
> > + }
> > +
> > + /* clk was prepared in probe, hence unprepare it here */
> > + clk_unprepare(pc->clk);
>
> I believe you need to remove the chip first and then do above to
> avoid any race conditions, that might occur.
> >>>
> >>> I am afraid, I would loose all chips and their related information
> >>> (PWMF_ENABLED) then.
> >>
> >> I have just checked core's code, and yes you are correct.
> >> Now i have another doubt :)
> >>
> >> Why shouldn't you do this instead:
> >>
> >>for (i = 0; i < NUM_PWM; i++)
> >> pwm_diable(>chip.pwms[i]);
> >>
> >> And, why should we put above code in pwmchip_remove() instead, so that
> >> pwm drivers don't need to do all this?
> >>
> >> @Thierry: Your inputs are required here :)
> >
> > We could probably do that in the core. I've had some discussions about
> > this with Lars-Peter (Cc'ed) who also had doubts about how this is
> > currently handled.
> >
> > The problem is that the core driver code ignores errors from the
> > driver's .remove() callback, so actually returning the error of
> > pwmchip_remove() here isn't terribly useful. I had actually assumed
> > (without checking the code) that the device wouldn't be removed if an
> > error was returned, but that isn't true.
> >
> > IIRC Lars-Peter suggested that we do reference counting on PWM devices
> > so that they could stay around after the module is unloaded but return
> > errors (-ENODEV?) on all operations to make sure users are aware of them
> > disappearing.
> >
> > What you're proposing is different, however. If we put that code in the
> > core it will mean that once the module is unloaded, all PWM devices will
> > be disabled. There is currently code in the core that prevents the chip
> > from being removed if one or more PWM devices are busy. But as explained
> > above, with the current core code this return value isn't useful at all.
> >
> > This needs to be addressed, but I'm not quite sure how yet. Obviously it
> > cannot be solved in the core, because the PWM devices may be provided by
> > real hotpluggable devices, so just preventing the driver from being
> > removed won't help.
>
> In my opinion it would make sense to put this into the PWM core. Even if the
> device is still physically connected, e.g. because it is a on-SoC device, it
> should be stopped if the device is removed. You do not want the PWM device
> to continue to provide it's service (which is the PWM signal) after the
> device has been removed. This means this is something that needs to be
> implemented by every PWM driver.
Alright. Let's keep it in the driver for now and I'll remove it once I
get around to implementing the functionality in the core.
Thierry
pgpwZzldkQzR8.pgp
Description: PGP signature
[RESEND PATCH] module: Fix kallsyms to show the last symbol properly
This patch fixes a bug that the last symbol in the .symtab section of
kernel modules is not displayed with /proc/kallsyms. This happens
because the first symbol is processed twice before and inside the loop
without incrementing "src".
This bug exists since the following commit was introduced.
module: reduce symbol table for loaded modules (v2)
commit: 4a4962263f07d14660849ec134ee42b63e95ea9a
This patch is tested on 3.7-rc2 kernel with the simple test module by the
below steps, to check if all the core symbols appear in /proc/kallsyms.
[Test steps]
1. Compile the test module, like below.
(My compiler tends to put a function named with 18 charactors,
like zz, at the end of .symtab section.
I don't know why, though.)
# cat tp.c
#include
#include
void zz(void) {}
static int init_tp(void)
{
return 0;
}
static void exit_tp(void) {}
module_init(init_tp);
module_exit(exit_tp);
MODULE_LICENSE("GPL");
# cat Makefile
KERNEL_RELEASE=$(shell uname -r)
BUILDDIR := /lib/modules/$(KERNEL_RELEASE)/source
obj-m := tp.o
all:
$(MAKE) -C $(BUILDDIR) M=$(PWD) V=1 modules
clean:
$(MAKE) -C $(BUILDDIR) M=$(PWD) V=1 clean
# make
2. Check if the target symbol, zz in this case,
is located at the last entry.
# readelf -s tp.ko | tail
18: 002011 FUNCLOCAL DEFAULT2 exit_tp
19: 12 OBJECT LOCAL DEFAULT4 __mod_license15
20: 0 FILELOCAL DEFAULT ABS tp.mod.c
21: 000c 9 OBJECT LOCAL DEFAULT4 __module_depends
22: 001545 OBJECT LOCAL DEFAULT4 __mod_vermagic5
23: 600 OBJECT GLOBAL DEFAULT8 __this_module
24: 002011 FUNCGLOBAL DEFAULT2 cleanup_module
25: 001013 FUNCGLOBAL DEFAULT2 init_module
26: 0 NOTYPE GLOBAL DEFAULT UND mcount
27: 11 FUNCGLOBAL DEFAULT2 zz
3. Load the module.
# insmod tp.ko
4. Check if all the core symbols are shown /proc/kallsyms properly.
[Before my patch applied]
# grep "\[tp\]" /proc/kallsyms
a0135010 t init_tp [tp]
a0135020 t exit_tp [tp]
a0137000 d __this_module[tp]
a0135020 t cleanup_module [tp]
a0135010 t init_module [tp]
(The last entry, or zz, is not shown.)
[After my patch applied]
# grep "\[tp\]" /proc/kallsyms
a0135010 t init_tp [tp]
a0135020 t exit_tp [tp]
a0137000 d __this_module[tp]
a0135020 t cleanup_module [tp]
a0135010 t init_module [tp]
a0135000 t zz [tp]
(The last entry, or zz, is shown properly.)
Signed-off-by: Masaki Kimura
---
kernel/module.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/module.c b/kernel/module.c
index 6085f5e..1a48ffe 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2293,7 +2293,11 @@ static void layout_symtab(struct module *mod, struct
load_info *info)
src = (void *)info->hdr + symsect->sh_offset;
nsrc = symsect->sh_size / sizeof(*src);
- /* Compute total space required for the core symbols' strtab. */
+ /*
+* Compute total space required for the core symbols' strtab.
+* We start searching core symbols from the second entry.
+*/
+ src++;
for (ndst = i = strtab_size = 1; i < nsrc; ++i, ++src)
if (is_core_symbol(src, info->sechdrs, info->hdr->e_shnum)) {
strtab_size += strlen(>strtab[src->st_name]) + 1;
@@ -2334,6 +2338,8 @@ static void add_kallsyms(struct module *mod, const struct
load_info *info)
src = mod->symtab;
*dst = *src;
*s++ = 0;
+ /* We start searching core symbols from the second entry. */
+ src++;
for (ndst = i = 1; i < mod->num_symtab; ++i, ++src) {
if (!is_core_symbol(src, info->sechdrs, info->hdr->e_shnum))
continue;
--
1.7.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4] PWM: Add SPEAr PWM chip driver support
On Mon, Oct 22, 2012 at 04:36:41PM +0530, Shiraz Hashim wrote:
[...]
> +struct spear_pwm_chip {
> + void __iomem *mmio_base;
> + struct clk *clk;
> + struct pwm_chip chip;
My editor shows a tab between pwm_chip and chip. This should really be a
space.
> + ret = pwmchip_add(>chip);
> + if (ret < 0) {
> + dev_err(>dev, "pwmchip_add() failed: %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(pc->clk);
> + if (ret < 0)
> + return pwmchip_remove(>chip);
I think in order to fix the potential race condition that Viresh
mentioned we should move the clk_prepare_enable() before the
pwmchip_add(), but don't forget to disable and unprepare the clock if
pwmchip_add() fails.
Actually, can't we make it a clk_prepare() only at this point and move
the clk_enable() and clk_disable() into the if block below? In case the
compatible value is not "st,spear1340-pwm" we don't need the clock
enabled.
> +
> + if (of_device_is_compatible(np, "st,spear1340-pwm")) {
> + /*
> + * Following enables PWM chip, channels would still be
> + * enabled individually through their control register
> + */
> + val = readl_relaxed(pc->mmio_base + PWMMCR);
> + val |= PWMMCR_PWM_ENABLE;
> + writel_relaxed(val, pc->mmio_base + PWMMCR);
> +
Oh, and a spurious newline here... =)
> + }
> +
> + /* only disable the clk and leave it prepared */
> + clk_disable(pc->clk);
This can go into the if block to match the clk_enable().
Thierry
pgpaMIyao45I9.pgp
Description: PGP signature
Re: [PATCH v5] posix timers: allocate timer id per process
* Eric Dumazet wrote: > On Wed, 2012-10-24 at 00:33 +0200, Thomas Gleixner wrote: > > On Tue, 23 Oct 2012, Eric Dumazet wrote: > > > > > On Tue, 2012-10-23 at 23:47 +0200, Thomas Gleixner wrote: > > > > > > > Not so good to me. > > > > > > > > > Signed-off-by: Eric Dumazet > > > > > > > > And that should be either an Acked-by or a Reviewed-by. You can't sign > > > > off on patches which have not been submitted or transported by you. > > > > > > I actually gave some input, provided a hash function, and so on. > > > > > > So this SOB was valid. I do that all the time. > > > > Not really. I recommend you to read the relevant file in Documentation > > which covers what can have your SOB. > > OK I did that again, and found this : > > The Signed-off-by: tag indicates that the signer was involved in the > development of the patch, or that he/she was in the patch's delivery > path. > > > And I was involved in the development of the patch. > > I understand you dont like it at all, so I'll remember not trying to > help anymore in this area. No, you are simply wrong and Linus would (rightfully) complain to *Thomas* if he added a SOB like that and pushed such a faulty commit to him. Linus has complained about such SOBs before and Thomas would be wrong to put them into commits. SOBs get added if you are the developer of the patch or if you are actually one of the 'hops' in the route of the patch that gets it to Thomas. SOBs don't get added over email like you did and what Thomas pointed out was simply a maintainer's job to point out. Adding credits for helping development get added via different tags, not via SOBs. Thanks, Ingo -- 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] Replace the type check code with typecheck() in kfifo_in
Am Mittwoch, den 24.10.2012, 11:41 +0800 schrieb Wei Yang:
> In kfifo_in marco, one piece of code which is arounded by if(0) will check the
> type of __tmp->ptr_const and __buf. If they are different type, there will
> output a warning during compiling. This piece of code is not self explaining
> and a little bit hard to understand.
>
> Based on Andrew Morton's suggestion, this patch replace this with typecheck()
> which will be easy to understand.
>
> In the same file, there are several places with the same code style. This
> patch change them too.
>
> Signed-off-by: Wei Yang
> Reviewed-by: Andrew Morton
> Reviewed-by: richard -rw- weinberger
> ---
> include/linux/kfifo.h | 22 +-
> 1 files changed, 5 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
> index 10308c6..680c293 100644
> --- a/include/linux/kfifo.h
> +++ b/include/linux/kfifo.h
> @@ -390,10 +390,7 @@ __kfifo_int_must_check_helper( \
> unsigned int __ret; \
> const size_t __recsize = sizeof(*__tmp->rectype); \
> struct __kfifo *__kfifo = &__tmp->kfifo; \
> - if (0) { \
> - typeof(__tmp->ptr_const) __dummy __attribute__ ((unused)); \
> - __dummy = (typeof(__val))NULL; \
> - } \
> + typecheck(typeof(__tmp->ptr_const), __val); \
> if (__recsize) \
> __ret = __kfifo_in_r(__kfifo, __val, sizeof(*__val), \
> __recsize); \
> @@ -433,7 +430,7 @@ __kfifo_uint_must_check_helper( \
> const size_t __recsize = sizeof(*__tmp->rectype); \
> struct __kfifo *__kfifo = &__tmp->kfifo; \
> if (0) \
> - __val = (typeof(__tmp->ptr))0; \
> + __val = (typeof(__tmp->ptr))NULL; \
> if (__recsize) \
> __ret = __kfifo_out_r(__kfifo, __val, sizeof(*__val), \
> __recsize); \
> @@ -512,10 +509,7 @@ __kfifo_uint_must_check_helper( \
> unsigned long __n = (n); \
> const size_t __recsize = sizeof(*__tmp->rectype); \
> struct __kfifo *__kfifo = &__tmp->kfifo; \
> - if (0) { \
> - typeof(__tmp->ptr_const) __dummy __attribute__ ((unused)); \
> - __dummy = (typeof(__buf))NULL; \
> - } \
> + typecheck(typeof(__tmp->ptr_const), __buf);\
> (__recsize) ?\
> __kfifo_in_r(__kfifo, __buf, __n, __recsize) : \
> __kfifo_in(__kfifo, __buf, __n); \
> @@ -565,10 +559,7 @@ __kfifo_uint_must_check_helper( \
> unsigned long __n = (n); \
> const size_t __recsize = sizeof(*__tmp->rectype); \
> struct __kfifo *__kfifo = &__tmp->kfifo; \
> - if (0) { \
> - typeof(__tmp->ptr) __dummy = NULL; \
> - __buf = __dummy; \
> - } \
> + typecheck(typeof(__tmp->ptr), __buf); \
> (__recsize) ?\
> __kfifo_out_r(__kfifo, __buf, __n, __recsize) : \
> __kfifo_out(__kfifo, __buf, __n); \
> @@ -777,10 +768,7 @@ __kfifo_uint_must_check_helper( \
> unsigned long __n = (n); \
> const size_t __recsize = sizeof(*__tmp->rectype); \
> struct __kfifo *__kfifo = &__tmp->kfifo; \
> - if (0) { \
> - typeof(__tmp->ptr) __dummy __attribute__ ((unused)) = NULL; \
> - __buf = __dummy; \
> - } \
> + typecheck(typeof(__tmp->ptr), __buf); \
> (__recsize) ? \
> __kfifo_out_peek_r(__kfifo, __buf, __n, __recsize) : \
> __kfifo_out_peek(__kfifo, __buf, __n); \
Acked-by: Stefani Seibold
--
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 V4] PWM: Add SPEAr PWM chip driver support
On Mon, Oct 22, 2012 at 07:25:45PM +0530, Viresh Kumar wrote:
> On 22 October 2012 16:36, Shiraz Hashim wrote:
> > Add support for PWM chips present on SPEAr platforms. These PWM
> > chips support 4 channel output with programmable duty cycle and
> > frequency.
> >
> > More details on these PWM chips can be obtained from relevant
> > chapter of reference manual, present at following[1] location.
> >
> > 1. http://www.st.com/internet/mcu/product/251211.jsp
> >
> > Cc: Thierry Reding
> > Signed-off-by: Shiraz Hashim
> > Signed-off-by: Viresh Kumar
> > Reviewed-by: Vipin Kumar
>
> Acked-by: Viresh Kumar
>
> > diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm/pwm-spear.c
> > +static int spear_pwm_probe(struct platform_device *pdev)
> > +{
>
> > + ret = pwmchip_add(>chip);
> > + if (ret < 0) {
> > + dev_err(>dev, "pwmchip_add() failed: %d\n", ret);
> > + return ret;
> > + }
>
> Sorry couldn't think of this complex situation earlier :(
>
> Can it happen that we get a request for a pwm here and its config or enable
> gets called...?
>
> If yes, then we must call clk_prepare() before doing pwmchip_add?? Otherwise
> you will see a crash :)
>
> @Thierry: Can this happen?
Yeah, it's very unlikely to happen, but it could. See my reply to the
patch.
Thierry
pgprkqPNAr0tc.pgp
Description: PGP signature
Re: [PATCH 2/2] firmware loader: introduce kernel parameter to customize fw search path
On Wed, Oct 24, 2012 at 11:31:16AM +0800, Ming Lei wrote: > On Wed, Oct 24, 2012 at 11:18 AM, Greg Kroah-Hartman > wrote: > > > > Ick, no, not another kernel boot parameter. I would prefer the /proc/ > > file solution instead, just like /proc/sys/kernel/hotplug is. > > OK, got it, but we could use the module parameter(firmware_class.path > via kernel command) to customize the search path too, couldn't we? Yes, but why? Let's not overdesign this, get the basics working and then, if someone really needs it, we can add it. thanks, greg k-h -- 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] pwm: vt8500: Update vt8500 PWM driver support
On Wed, Oct 24, 2012 at 04:46:58PM +1300, Tony Prisk wrote: > This patch updates pwm-vt8500.c to support devicetree probing and > make use of the common clock subsystem. > > A binding document describing the PWM controller found on > arch-vt8500 is also included. > > Signed-off-by: Tony Prisk > --- > v2/v3: > Fix errors/coding style as pointed out by Thierry Reding. > > .../devicetree/bindings/pwm/vt8500-pwm.txt | 17 > drivers/pwm/pwm-vt8500.c | 86 > ++-- > 2 files changed, 80 insertions(+), 23 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt Looking real good now. One last comment though and I think I'm ready to take this... > + err = clk_enable(vt8500->clk); > + if (err < 0) > + dev_err(chip->dev, "failed to enable clock\n"); > + return -EBUSY; > + }; Why do you return EBUSY instead of err? Thierry pgp6P4aMnBFoJ.pgp Description: PGP signature
Re: [RFC PATCH] gpiolib: add gpio get direction support
On Tue, Oct 23, 2012 at 1:06 PM, Mathias Nyman wrote: > [Me] >> Anyway, if the callback is only called internally in the GPIOlib >> why are you making the function public to the entire >> kernel > > Thought I'd do it the same was as gpio_direction_output() and > gpio_direction_input(), but if there is no need for getting the direction > outside gpiolob then it can be skipped. Main motivation was to get correct > direction values in debug and sysfs after boot. OK then keep them static til the day they are needed. > gpiolib currently uses cached values of gpio_direction_output/input() in > sysfs. If the .get_direction callback exists it is used to refresh the > cached values. OK! (I'm not yet familiar enough with gpiolib as you can see ...) Yours, Linus Walleij -- 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] pidns: limit the nesting depth of pid namespaces
2012/10/24 Andrew Morton :
> On Fri, 12 Oct 2012 16:30:42 +0400
> Andrew Vagin wrote:
>
>> 'struct pid' is a "variable sized struct" - a header with an array
>> of upids at the end.
>>
>> A size of the array depends on a level (depth) of pid namespaces. Now
>> a level of pidns is not limited, so 'struct pid' can be more than one
>> page.
>>
>> Looks reasonable, that it should be less than a page. MAX_PIS_NS_LEVEL
>> is not calculated from PAGE_SIZE, because in this case it depends on
>> architectures, config options and it will be reduced, if someone adds a
>> new fields in struct pid or struct upid.
>>
>> I suggest to set MAX_PIS_NS_LEVEL = 32, because it saves ability to
>> expand "struct pid" and it's more than enough for all known for me
>> use-cases. When someone finds a reasonable use case, we can add a
>> config option or a sysctl parameter.
>>
>> In addition it will reduce effect of another problem, when we have many
>> nested namespaces and the oldest one starts dying. zap_pid_ns_processe
>> will be called for each namespace and find_vpid will be called for each
>> process in a namespace. find_vpid will be called minimum max_level^2 / 2
>> times. The reason of that is that when we found a bit in pidmap, we
>> can't determine this pidns is top for this process or it isn't.
>>
>> vpid is a heavy operation, so a fork bomb, which create many nested
>> namespace, can do a system inaccessible for a long time.
>>
>> --- a/kernel/pid_namespace.c
>> +++ b/kernel/pid_namespace.c
>> @@ -70,12 +70,18 @@ err_alloc:
>> return NULL;
>> }
>>
>> +/* MAX_PID_NS_LEVEL is needed for limiting size of 'struct pid' */
>> +#define MAX_PID_NS_LEVEL 32
>> +
>> static struct pid_namespace *create_pid_namespace(struct pid_namespace
>> *parent_pid_ns)
>> {
>> struct pid_namespace *ns;
>> unsigned int level = parent_pid_ns->level + 1;
>> int i, err = -ENOMEM;
>>
>> + if (level > MAX_PID_NS_LEVEL)
>> + goto out;
>> +
>> ns = kmem_cache_zalloc(pid_ns_cachep, GFP_KERNEL);
>> if (ns == NULL)
>> goto out;
>
> hm, OK. This will kind-of fix the free_pid_ns()-excessive-recursion
> issue which we already fixed by other means ;)
I caught both problems with help of an one program, which create many
nested namespaces. Actually this patch prevents another problem. A few
thousand nested namespaces is destroyed for more than one minutes and
in this period a system is inaccessible.
>
> I don't think this problem is serious enough to bother backporting into
> -stable but I guess we can/should do it in 3.7. Agree?
Yes.
>
> I think that returning -ENOMEM in response to an excessive nesting
> attempt is misleading - the system *didn't* run out of memory. EINVAL
> is better?
I chose ENOMEM by analogy with max_pid. When a new PID can not be
allocated, ENOMEM is returned too.
>
>
>
> From: Andrew Morton
> Subject: pidns-limit-the-nesting-depth-of-pid-namespaces-fix
>
> return -EINVAL in response to excessive nesting, not -ENOMEM
>
> Cc: "Eric W. Biederman"
> Cc: Andrew Vagin
> Cc: Cyrill Gorcunov
> Cc: Oleg Nesterov
> Cc: Pavel Emelyanov
> Signed-off-by: Andrew Morton
> ---
>
> kernel/pid_namespace.c |8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff -puN
> kernel/pid_namespace.c~pidns-limit-the-nesting-depth-of-pid-namespaces-fix
> kernel/pid_namespace.c
> ---
> a/kernel/pid_namespace.c~pidns-limit-the-nesting-depth-of-pid-namespaces-fix
> +++ a/kernel/pid_namespace.c
> @@ -78,11 +78,15 @@ static struct pid_namespace *create_pid_
> {
> struct pid_namespace *ns;
> unsigned int level = parent_pid_ns->level + 1;
> - int i, err = -ENOMEM;
> + int i;
> + int err;
>
> - if (level > MAX_PID_NS_LEVEL)
> + if (level > MAX_PID_NS_LEVEL) {
> + err = -EINVAL;
> goto out;
> + }
>
> + err = -ENOMEM;
> ns = kmem_cache_zalloc(pid_ns_cachep, GFP_KERNEL);
> if (ns == NULL)
> goto out;
> _
>
--
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/3] staging/sbe-2t3e3: Use netdev_ printks in main.c
On Wed, Oct 24, 2012 at 1:15 PM, Greg Kroah-Hartman wrote: > On Wed, Oct 24, 2012 at 12:05:28PM +0900, YAMANE Toshiaki wrote: >> fixed below checkpatch warning. >> - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then >> pr_err(... to printk(KERN_ERR ... >> >> Signed-off-by: YAMANE Toshiaki > > I never got the 3/3 patch in this series :( I know! # thanks, I will learn more ways to send patch -- Regards, YAMANE Toshiaki -- 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 00/16 v2] f2fs: introduce flash-friendly file system
> On Wed, Oct 24, 2012 at 08:18:36AM +0900, Jaegeuk Kim wrote: > > > On Tue, Oct 23, 2012 at 11:26:59AM -0700, Greg KH wrote: > > > > On Tue, Oct 23, 2012 at 11:21:53AM +0900, Jaegeuk Kim wrote: > > > > > mkfs.f2fs > > > > > = > > > > > > > > > > The file system formatting tool, "mkfs.f2fs", is available from the > > > > > following > > > > > download page: > > > > > http://sourceforge.net/projects/f2fs-tools/ > > > > > > > > Is there a git tree of this tool somewhere, so I don't have to > > > > constantly suffer the sf.net download interface every time I want to get > > > > the latest version? > > > > > > Oh, and where do we report bugs for this tool? I just formatted a usb > > > stick with the mkfs.f2fs program, and it did not fully erase the old > > > filesystem that was on there (iso9660), so when I mounted it, it did so > > > in iso9660 mode, not f2fs mode. > > > > > > > Any suggestion for reporting bugs? > > Maybe via a mailing list? > > Mailing list is fine. > > > What version did you use? (1.1.0 is correct.) > > I used 1.1.0 > > > The reason we found was due to the 0'th block, so we fixed that in v1.1.0. > > Hm, that's what I used. I zeroed out the whole usb disk and tried again > and it worked then, I was trying to debug the kernel changes, not the > userspace tool, so I didn't spend much time on it :) > > But, if you do get a public git tree up, I will at the very least, > provide a patch to handle '-h' properly for mkfs, that should work... > Ok, thank you very much. > thanks, > > greg k-h --- Jaegeuk Kim Samsung -- 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 00/16 v2] f2fs: introduce flash-friendly file system
> -Original Message- > From: 'Greg KH' [mailto:gre...@linuxfoundation.org] > Sent: Wednesday, October 24, 2012 12:01 PM > To: Jaegeuk Kim > Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; > v...@zeniv.linux.org.uk; > a...@arndb.de; ty...@mit.edu; chur@samsung.com; cm224@samsung.com; > jooyoung.hw...@samsung.com > Subject: Re: [PATCH 00/16 v2] f2fs: introduce flash-friendly file system > Importance: High > > On Wed, Oct 24, 2012 at 08:14:44AM +0900, Jaegeuk Kim wrote: > > > On Tue, Oct 23, 2012 at 11:21:53AM +0900, Jaegeuk Kim wrote: > > > > mkfs.f2fs > > > > = > > > > > > > > The file system formatting tool, "mkfs.f2fs", is available from the > > > > following > > > > download page: http://sourceforge.net/projects/f2fs-tools/ > > > > > > Is there a git tree of this tool somewhere, so I don't have to > > > constantly suffer the sf.net download interface every time I want to get > > > the latest version? > > > > I'd love to do like that. > > I've managed a git tree for tools in house only, due to the company secret. > > Would you suggest something for this? > > I can do managing the tree outside though. > > git.kernel.org can work, so can github, and also, you have a sf.net > project, why not use the git tree it provides you? Right now it is > empty. > Ok, I'll make a tree in sf.net. :) > thanks, > > greg k-h --- Jaegeuk Kim Samsung -- 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: [Request for review] Revised delete_module(2) manual page
Hi Michael, On Sun, Oct 21, 2012 at 5:36 AM, Michael Kerrisk (man-pages) wrote: > Ping! > > Rusty (et al.) I'm pretty sure the new page text is okay, but I would > like someone knowledgeable to confirm. One more thing: > .SH "SEE ALSO" > .BR create_module (2), > .BR init_module (2), > .BR query_module (2), > .BR lsmod (8), > .BR rmmod (8) Shouldn't we remove the reference to query_module(2) and create_module(2)? They don't exist anymore (and I miss a bigger warning on their man pages). Last, I think there should be a ref here to modprobe (because of -r flag), not lsmod. The rest looks good. Lucas De Marchi -- 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: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)
On Tue, Oct 23, 2012 at 11:27:09PM -0500, Eric Sandeen wrote: > > Ok, fair enough. If the BBU is working, nobarrier is ok; I don't trust > journal_async_commit, but that doesn't mean this isn't a regression. Note that Toralf has reported almost exactly the same set of symptoms, but he's using an external USB stick --- and as far as I know he wasn't using nobarrier and/or the journal_async_commit. Toralf, can you confirm what, if any, mount options you were using when you saw it. I've been looking at this some more, and there's one other thing that the short circuit code does, which is neglects setting the JBD2_FLUSHED flag, which is used by the commit code to know when it needs to reset the s_start fields in the superblock when we make our next commit. However, this would only happen if the short circuit code is getting hit some time other than when the file system is getting unmounted --- and that's what Eric and I can't figure out how it might be happening. Journal flushes outside of an unmount does happen as part of online resizing, the FIBMAP ioctl, or when the file system is frozen. But it didn't sound like Toralf or Nix was using any of those features. (Toralf, Nix, please correct me if my assumptions here is wrong). So here's a replacement patch which essentially restores the effects of eeecef0af5e while still keeping the optimization and fixing the read/only testing issue which eeecef0af5e is trying to fix up. It also have a debugging printk that will trigger so we can perhaps have a better chance of figuring out what might be going on. Toralf, Nix, if you could try applying this patch (at the end of this message), and let me know how and when the WARN_ON triggers, and if it does, please send the empty_bug_workaround plus the WARN_ON(1) report. I know about the case where a file system is mounted and then immediately unmounted, but we don't think that's the problematic case. If you see any other cases where WARN_ON is triggering, it would be really good to know - Ted P.S. This is a list of all of the commits between v3.6.1 and v3.6.2 (there were no ext4-related changes between v3.6.2 and v3.6.3), and a quick analysis of the patch. The last commit, 14b4ed2, is the only one that I could see as potentially being problematic, which is why I've been pushing so hard on this one even though my original analysis doesn't seem to be correct, and Eric and I can't see how the change in 14b4ed2 could be causing the fs corruption. Online Defrag = 22a5672 ext4: online defrag is not supported for journaled files ba57d9e ext4: move_extent code cleanup No behavioral change unless e4defrag has been used. Online Resize = 5018ddd ext4: avoid duplicate writes of the backup bg descriptor blocks 256ae46 ext4: don't copy non-existent gdt blocks when resizing 416a688 ext4: ignore last group w/o enough space when resizing instead of BUG'ing No observable change unless online resizing (e2resize) has been used Other Commits = 92b7722 ext4: fix mtime update in nodelalloc mode Changes where we call file_update_time() 34414b2 ext4: fix fdatasync() for files with only i_size changes Forces the inode changes to be commited if only i_sync changes when fdatasync() is called. No changes except performance impact to fdatasync() and correctness after a system crash. 12ebdf0 ext4: always set i_op in ext4_mknod() Fixes a bug if CONFIG_EXT4_FS_XATTR is not defined; no change if CONFIG_EXT4_FS_XATTR is defined 2fdb112 ext4: fix crash when accessing /proc/mounts concurrently Remove an erroneous "static" for an function so it is allocated on the stack; fixes a bug if two processes cat /proc/mounts at the same time 1638f1f ext4: fix potential deadlock in ext4_nonda_switch() Fixes a circular lock dependency 14b4ed2 jbd2: don't write superblock when if its empty If journal->s_start is zero, we may not update journal->s_sequence when it might be needed. (But we at the moement we can't see how this could lead to the reported fs corruptions.) commit cb57108637e01ec2f02d9311cedc3013e96f25d4 Author: Theodore Ts'o Date: Wed Oct 24 01:01:41 2012 -0400 jbd2: fix a potential fs corrupting bug in jbd2_mark_journal_empty Fix a potential file system corrupting bug which was introduced by commit eeecef0af5ea4efd763c9554cf2bd80fc4a0efd3: jbd2: don't write superblock when if its empty. We should only skip writing the journal superblock if there is nothing to do --- not just when s_start is zero. This has caused users to report file system corruptions in ext4 that look like this: EXT4-fs error (device sdb3): ext4_mb_generate_buddy:741: group 436, 22902 clusters in bitmap, 22901 in gd JBD2: Spotted dirty metadata buffer (dev = sdb3, blocknr = 0). There's a risk of filesystem corruption in case of system crash. after the file system has been
[PATCH v2] staging/comedi: Use dev_ printks in drivers/vmk80xx.c
fixed below checkpatch warning.
- Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to
printk(KERN_INFO ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/comedi/drivers/vmk80xx.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/comedi/drivers/vmk80xx.c
b/drivers/staging/comedi/drivers/vmk80xx.c
index df277aa..3664907 100644
--- a/drivers/staging/comedi/drivers/vmk80xx.c
+++ b/drivers/staging/comedi/drivers/vmk80xx.c
@@ -1371,12 +1371,11 @@ static int vmk80xx_usb_probe(struct usb_interface *intf,
if (dev->board.model == VMK8061_MODEL) {
vmk80xx_read_eeprom(dev, IC3_VERSION);
- printk(KERN_INFO "comedi#: vmk80xx: %s\n", dev->fw.ic3_vers);
+ dev_info(>dev, "%s\n", dev->fw.ic3_vers);
if (vmk80xx_check_data_link(dev)) {
vmk80xx_read_eeprom(dev, IC6_VERSION);
- printk(KERN_INFO "comedi#: vmk80xx: %s\n",
- dev->fw.ic6_vers);
+ dev_info(>dev, "%s\n", dev->fw.ic6_vers);
} else {
dbgcm("comedi#: vmk80xx: no conn. to CPU\n");
}
@@ -1387,8 +1386,8 @@ static int vmk80xx_usb_probe(struct usb_interface *intf,
dev->probed = 1;
- printk(KERN_INFO "comedi#: vmk80xx: board #%d [%s] now attached\n",
- dev->count, dev->board.name);
+ dev_info(>dev, "board #%d [%s] now attached\n",
+dev->count, dev->board.name);
mutex_unlock(_mutex);
@@ -1422,8 +1421,8 @@ static void vmk80xx_usb_disconnect(struct usb_interface
*intf)
kfree(dev->usb_rx_buf);
kfree(dev->usb_tx_buf);
- printk(KERN_INFO "comedi#: vmk80xx: board #%d [%s] now detached\n",
- dev->count, dev->board.name);
+ dev_info(>dev, "board #%d [%s] now detached\n",
+dev->count, dev->board.name);
up(>limit_sem);
mutex_unlock(_mutex);
--
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] ARM: dma-mapping: fix build warning in __dma_alloc()
Fix build warning in __dma_alloc() as below:
arch/arm/mm/dma-mapping.c: In function '__dma_alloc':
arch/arm/mm/dma-mapping.c:653:29: warning: 'page' may be used uninitialized in
this function [-Wuninitialized]
Signed-off-by: Jingoo Han
---
arch/arm/mm/dma-mapping.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 477a2d2..58bc3e4 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -610,7 +610,7 @@ static void *__dma_alloc(struct device *dev, size_t size,
dma_addr_t *handle,
gfp_t gfp, pgprot_t prot, bool is_coherent, const void
*caller)
{
u64 mask = get_coherent_dma_mask(dev);
- struct page *page;
+ struct page *page = NULL;
void *addr;
#ifdef CONFIG_DMA_API_DEBUG
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] DMA: PL330: Free memory allocated for peripheral channels
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
> The allocated memory for peripheral channels is not being freed upon
> failure in probe and in module's remove funtion. It will lead to memory
> leakage. Hence free the allocated memory.
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/dma/pl330.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 2ebd4cd..10c6b6a 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2962,7 +2962,7 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> ret = dma_async_device_register(pd);
> if (ret) {
> dev_err(>dev, "unable to register DMAC\n");
> - goto probe_err4;
> + goto probe_err5;
> }
>
> dev_info(>dev,
> @@ -2975,6 +2975,8 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
>
> return 0;
>
> +probe_err5:
> + kfree(pdmac->peripherals);
> probe_err4:
> pl330_del(pi);
> probe_err3:
> @@ -3025,6 +3027,7 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> res = >res;
> release_mem_region(res->start, resource_size(res));
>
> + kfree(pdmac->peripherals);
> kfree(pdmac);
>
> return 0;
This looks fine, but if you use devm_ functions then you dont need to do
all this.
Can you do that conversion instead?
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] Thermal: Add ST-Ericsson db8500 thermal dirver.
On 23 October 2012 02:51, Francesco Lavra wrote:
> On 10/22/2012 02:02 PM, Hongbo Zhang wrote:
> [...]
+static irqreturn_t prcmu_low_irq_handler(int irq, void *irq_data)
+{
+ struct db8500_thermal_zone *pzone = irq_data;
+ struct db8500_thsens_platform_data *ptrips;
+ unsigned long next_low, next_high;
+ unsigned int idx;
+
+ ptrips = pzone->trip_tab;
+ idx = pzone->cur_index;
+ if (unlikely(idx == 0))
+ /* Meaningless for thermal management, ignoring it */
+ return IRQ_HANDLED;
+
+ if (idx == 1) {
+ next_high = ptrips->trip_points[0].temp;
+ next_low = PRCMU_DEFAULT_LOW_TEMP;
+ } else {
+ next_high = ptrips->trip_points[idx-1].temp;
+ next_low = ptrips->trip_points[idx-2].temp;
+ }
+
+ pzone->cur_index -= 1;
+ pzone->cur_temp_pseudo = (next_high + next_low)/2;
+
+ prcmu_stop_temp_sense();
+ prcmu_config_hotmon((u8)(next_low/1000), (u8)(next_high/1000));
+ prcmu_start_temp_sense(PRCMU_DEFAULT_MEASURE_TIME);
+
+ pr_debug("PRCMU set max %ld, set min %ld\n", next_high, next_low);
+
+ pzone->trend = THERMAL_TREND_DROPPING;
+ schedule_work(>therm_work);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t prcmu_high_irq_handler(int irq, void *irq_data)
+{
+ struct db8500_thermal_zone *pzone = irq_data;
+ struct db8500_thsens_platform_data *ptrips;
+ unsigned long next_low, next_high;
+ unsigned int idx;
+
+ ptrips = pzone->trip_tab;
+ idx = pzone->cur_index;
+
+ if (idx < ptrips->num_trips - 1) {
+ next_high = ptrips->trip_points[idx+1].temp;
+ next_low = ptrips->trip_points[idx].temp;
+
+ pzone->cur_index += 1;
+ pzone->cur_temp_pseudo = (next_high + next_low)/2;
+
+ prcmu_stop_temp_sense();
+ prcmu_config_hotmon((u8)(next_low/1000),
(u8)(next_high/1000));
+ prcmu_start_temp_sense(PRCMU_DEFAULT_MEASURE_TIME);
+
+ pr_debug("PRCMU set max %ld, min %ld\n", next_high,
next_low);
+ }
+
+ if (idx == ptrips->num_trips - 1)
>>>
>>> } else if ()
>> There is no else condition here, because it it the highest critical
>> trip point, system will be shut down in thermal_work.
>> But I'd like to add some comments here to state this situation.
>
> I didn't mean adding a new else condition, what I meant is that if the
> first condition (idx < ptrips->num_trips - 1) is verified, then there is
> no need to check for the second condition (idx == ptrips->num_trips -
> 1). So I was thinking of changing the code to:
>
> if (idx < ptrips->num_trips - 1)
> ...
> else if (idx == ptrips->num_trips - 1)
> ...
>
> Sorry if I wasn't clear.
Got it, thanks.
>
>>>
+ pzone->cur_temp_pseudo = ptrips->trip_points[idx].temp + 1;
+
+ pzone->trend = THERMAL_TREND_RAISING;
+ schedule_work(>therm_work);
+
+ return IRQ_HANDLED;
+}
+
+static void db8500_thermal_work(struct work_struct *work)
+{
+ enum thermal_device_mode cur_mode;
+ struct db8500_thermal_zone *pzone;
+
+ pzone = container_of(work, struct db8500_thermal_zone, therm_work);
+
+ mutex_lock(>th_lock);
+ cur_mode = pzone->mode;
+ mutex_unlock(>th_lock);
+
+ if (cur_mode == THERMAL_DEVICE_DISABLED) {
+ pr_warn("Warning: thermal function disabled.\n");
+ return;
+ }
+
+ thermal_zone_device_update(pzone->therm_dev);
+ pr_debug("db8500_thermal_work finished.\n");
+}
+
+static int __devinit db8500_thermal_probe(struct platform_device *pdev)
+{
+ struct db8500_thermal_zone *pzone = NULL;
+ struct db8500_thsens_platform_data *ptrips;
+ int low_irq, high_irq, ret = 0;
+ unsigned long dft_low, dft_high;
+
+ pzone = devm_kzalloc(>dev,
+ sizeof(struct db8500_thermal_zone), GFP_KERNEL);
+ if (!pzone)
+ return -ENOMEM;
+
+ pzone->thsens_pdev = pdev;
+
+ low_irq = platform_get_irq_byname(pdev, "IRQ_HOTMON_LOW");
+ if (low_irq < 0) {
+ pr_err("Get IRQ_HOTMON_LOW failed.\n");
+ return low_irq;
+ }
+
+ ret = devm_request_threaded_irq(>dev, low_irq, NULL,
+ prcmu_low_irq_handler,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT, "dbx500_temp_low", pzone);
+ if (ret < 0) {
+ pr_err("Failed to allocate temp low irq.\n");
+
Re: [PATCH v2 4/4] DMA: PL330: unregister dma_device in module's remove function
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote: > unregister dma_device in module's remove function. > > Signed-off-by: Inderpal Singh > --- > drivers/dma/pl330.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c > index 4b7a34d..e7dc040 100644 > --- a/drivers/dma/pl330.c > +++ b/drivers/dma/pl330.c > @@ -3017,6 +3017,8 @@ static int __devexit pl330_remove(struct amba_device > *adev) > return -EBUSY; > } > > + dma_async_device_unregister(>ddma); > + > amba_set_drvdata(adev, NULL); > > list_for_each_entry_safe(pch, _p, >ddma.channels, Ok with this one :) Tried applying but didn't work out. You would need to regenerate this one. Thanks -- Vinod Koul Intel Corp. -- 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: Process Hang in __read_seqcount_begin
On Tue, 2012-10-23 at 17:15 -0700, Peter LaDow wrote:
> (Sorry for the subject change, but I wanted to try and pull in those
> who work on RT issues, and the subject didn't make that obvious.
> Please search for the same subject without the RT Linux trailing
> text.)
>
> Well, more information. Even with SMP enabled (and presumably the
> migrate_enable having calls to preempt_disable), we still got the
> lockup in iptables-restore. I did more digging, and it looks like the
> complete stack trace includes a call from iptables-restore (through
> setsockopt with IPT_SO_SET_ADD_COUNTERS). This seems to be a
> potential multiple writer case where the counters are updated through
> the syscall and the kernel is updating the counters as it filters
> packets.
>
> I think there might be a race on the update to xt_recseq.sequence,
> since the RT patches remove the spinlock in seqlock_t. Thus multiple
> writers can corrupt the sequence count.
> And I thought the SMP
> configuration would disable preemption when local_bh_disable() is
> called. And indeed, looking at the disassembly, I see
> preempt_disable() (though optimized, goes to add_preempt_count() ) is
> being called.
>
> Yet we still see the lockup in the get_counters() in iptables. Which,
> it seems, is because of some sort of problem with the sequence. It
> doesn't appear to be related to the preemption, and perhaps there is
> some other corruption of the sequence counter happening. But the only
> places I see it modified is in xt_write_recseq_begin and
> xt_write_recseq_end, which is only in the netfilter code
> (ip6_tables.c, ip_tables.c, and arp_tables.c). And every single call
> is preceeded by a call to local_bh_disable().
>
> This problem is a huge one for us. And so far I'm unable to track
> down how this is occurring.
>
> Any other tips? I presume this is the proper place for RT issues.
Hmm...
Could you try following patch ?
diff --git a/include/linux/netfilter/x_tables.h
b/include/linux/netfilter/x_tables.h
index 8d674a7..053f9e7 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -471,30 +471,24 @@ DECLARE_PER_CPU(seqcount_t, xt_recseq);
*
* Begin packet processing : all readers must wait the end
* 1) Must be called with preemption disabled
- * 2) softirqs must be disabled too (or we should use this_cpu_add())
* Returns :
* 1 if no recursion on this cpu
* 0 if recursion detected
*/
static inline unsigned int xt_write_recseq_begin(void)
{
- unsigned int addend;
-
+ unsigned int old, new;
+ seqcount_t *ptr = &__get_cpu_var(xt_recseq);
/*
* Low order bit of sequence is set if we already
* called xt_write_recseq_begin().
*/
- addend = (__this_cpu_read(xt_recseq.sequence) + 1) & 1;
-
- /*
-* This is kind of a write_seqcount_begin(), but addend is 0 or 1
-* We dont check addend value to avoid a test and conditional jump,
-* since addend is most likely 1
-*/
- __this_cpu_add(xt_recseq.sequence, addend);
- smp_wmb();
-
- return addend;
+ old = ptr->sequence;
+ new = old | 1;
+ /* Note : cmpxchg() is a memory barrier, we dont need smp_wmb() */
+ if (old != new && cmpxchg(>sequence, old, new) == old)
+ return 1;
+ return 0;
}
/**
--
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 3/4] DMA: PL330: Balance module remove function with probe
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
> Since peripheral channel resources are not being allocated at probe,
> no need to flush the channels and free the resources in remove function.
> In case, the channel is in use by some client, return EBUSY.
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/dma/pl330.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index bf71ff7..4b7a34d 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -3009,18 +3009,21 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> if (!pdmac)
> return 0;
>
> + /* check if any client is using any channel */
> + list_for_each_entry(pch, >ddma.channels,
> + chan.device_node) {
> +
> + if (pch->chan.client_count)
> + return -EBUSY;
> + }
> +
> while (!list_empty(>desc_pool)) {
Did you get this code executed?
I think No.
The dmaengine holds the reference to channels, so if they are in use and
not freed by client your remove wont be called. So this check is
redundant
--
Vinod Koul
Intel Corp.
--
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: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)
On 10/23/12 11:15 PM, Nix wrote: > On 24 Oct 2012, Eric Sandeen uttered the following: > >> On 10/23/12 3:57 PM, Nix wrote: >>> The only unusual thing about the filesystems on this machine are that >>> they have hardware RAID-5 (using the Areca driver), so I'm mounting with >>> 'nobarrier': >> >> I should have read more. :( More questions follow: >> >> * Does the Areca have a battery backed write cache? > > Yes (though I'm not powering off, just rebooting). Battery at 100% and > happy, though the lack of power-off means it's not actually getting > used, since the cache is obviously mains-backed as well. > >> * Are you crashing or rebooting cleanly? > > Rebooting cleanly, everything umounted happily including /home and /var. > >> * Do you see log recovery messages in the logs for this filesystem? > > My memory says yes, but nothing seems to be logged when this happens > (though with my logs on the first filesystem damaged by this, this is > rather hard to tell, they're all quite full of NULs by now). > > I'll double-reboot tomorrow via the faulty kernel and check, unless I > get asked not to in the interim. (And then double-reboot again to fsck > everything...) > >>> the full set of options for all my ext4 filesystems are: >>> >>> rw,nosuid,nodev,relatime,journal_checksum,journal_async_commit,nobarrier,quota, >>> usrquota,grpquota,commit=30,stripe=16,data=ordered,usrquota,grpquota >> >> ok journal_async_commit is off the reservation a bit; that's really not >> tested, and Jan had serious reservations about its safety. > > OK, well, I've been 'testing' it for years :) No problems until now. (If > anything, I was more concerned about journal_checksum. I thought that > had actually been implicated in corruption before now...) It had, but I fixed it AFAIK; OTOH, we turned it off by default after that episode. >> * Can you reproduce this w/o journal_async_commit? > > I can try! Ok, fair enough. If the BBU is working, nobarrier is ok; I don't trust journal_async_commit, but that doesn't mean this isn't a regression. Thanks for the answers... onward. :) -Eric -- 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 2/4] DMA: PL330: Change allocation method to properly free DMA descriptors
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
> In probe, memory for multiple DMA descriptors were being allocated at once
> and then it was being split and added into DMA pool one by one. The address
> of this memory allocation is not being saved anywhere. To free this memory,
> the address is required. Initially the first node of the pool will be
> pointed by this address but as we use this pool the descs will shuffle and
> hence we will lose the track of the address.
>
> This patch does following:
>
> 1. Allocates DMA descs one by one and then adds them to pool so that all
>descs can be fetched and memory freed one by one. This way runtime
>added descs can also be freed.
> 2. Free DMA descs in case of error in probe and in module's remove function
For probe, again you have cleaner code by using devm_kzalloc.
On 1, if we use the devm_kzalloc then we don't need to allocate in
chunks right?
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/dma/pl330.c | 35 +--
> 1 file changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 10c6b6a..bf71ff7 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2541,20 +2541,20 @@ static int add_desc(struct dma_pl330_dmac *pdmac,
> gfp_t flg, int count)
> if (!pdmac)
> return 0;
>
> - desc = kmalloc(count * sizeof(*desc), flg);
> - if (!desc)
> - return 0;
> + for (i = 0; i < count; i++) {
> + desc = kmalloc(sizeof(*desc), flg);
> + if (!desc)
> + break;
> + _init_desc(desc);
>
> - spin_lock_irqsave(>pool_lock, flags);
> + spin_lock_irqsave(>pool_lock, flags);
>
> - for (i = 0; i < count; i++) {
> - _init_desc([i]);
> - list_add_tail([i].node, >desc_pool);
> - }
> + list_add_tail(>node, >desc_pool);
>
> - spin_unlock_irqrestore(>pool_lock, flags);
> + spin_unlock_irqrestore(>pool_lock, flags);
> + }
>
> - return count;
> + return i;
> }
>
> static struct dma_pl330_desc *
> @@ -2857,6 +2857,7 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> struct dma_pl330_platdata *pdat;
> struct dma_pl330_dmac *pdmac;
> struct dma_pl330_chan *pch;
> + struct dma_pl330_desc *desc;
> struct pl330_info *pi;
> struct dma_device *pd;
> struct resource *res;
> @@ -2978,6 +2979,12 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> probe_err5:
> kfree(pdmac->peripherals);
> probe_err4:
> + while (!list_empty(>desc_pool)) {
> + desc = list_entry(pdmac->desc_pool.next,
> + struct dma_pl330_desc, node);
> + list_del(>node);
> + kfree(desc);
> + }
> pl330_del(pi);
> probe_err3:
> free_irq(irq, pi);
> @@ -2994,6 +3001,7 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> {
> struct dma_pl330_dmac *pdmac = amba_get_drvdata(adev);
> struct dma_pl330_chan *pch, *_p;
> + struct dma_pl330_desc *desc;
> struct pl330_info *pi;
> struct resource *res;
> int irq;
> @@ -3015,6 +3023,13 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> pl330_free_chan_resources(>chan);
> }
>
> + while (!list_empty(>desc_pool)) {
> + desc = list_entry(pdmac->desc_pool.next,
> + struct dma_pl330_desc, node);
> + list_del(>node);
> + kfree(desc);
> + }
> +
> pi = >pif;
>
> pl330_del(pi);
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Oct 24
Hi all, Changes since 201201023: The wireless-next tree lost its conflicts. The pm tree gained a build failure for which I applied a patch. The tty tree gained a build failure for which I disabled a staging driver. The usb tree lost its build failure. The akpm tree still has its 2 build failures for which I reverted some commits. It also lost a patch that turned up elsewhere. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 205 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (2d1f4c8 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux) Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux) Merging kbuild-current/rc-fixes (b1e0d8b kbuild: Fix gcc -x syntax) Merging arm-current/fixes (b43b1ff Merge tag 'fixes-for-rmk' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc into fixes) Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp) Merging powerpc-merge/merge (83dac59 cpuidle/powerpc: Fix snooze state problem in the cpuidle design on pseries.) Merging sparc/master (43c422e apparmor: fix apparmor OOPS in audit_log_untrustedstring+0x1c/0x40) Merging net/master (37561f6 tcp: Reject invalid ack_seq to Fast Open sockets) Merging sound-current/for-linus (21b3de8 ALSA: als3000: check for the kzalloc return value) Merging pci-current/for-linus (0ff9514 PCI: Don't print anything while decoding is disabled) Merging wireless/master (290eddc Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging driver-core.current/driver-core-linus (d28d388 firmware loader: sync firmware cache by async_synchronize_full_domain) Merging tty.current/tty-linus (6f0c058 Linux 3.7-rc2) Merging usb.current/usb-linus (3b6054d usb hub: send clear_tt_buffer_complete events when canceling TT clear work) Merging staging.current/staging-linus (b3ca610 staging: ramster: depends on NET) Merging char-misc.current/char-misc-linus (ddffeb8 Linux 3.7-rc1) Merging input-current/for-linus (0cc8d6a Merge branch 'next' into for-linus) Merging md-current/for-linus (72f36d5 md: refine reporting of resync/reshape delays.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (c9f97a2 crypto: x86/glue_helper - fix storing of new IV in CBC encryption) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging asm-generic/master (c37d615 Merge branch 'disintegrate-asm-generic' of
Re: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)
On 24 Oct 2012, Eric Sandeen uttered the following: > On 10/23/12 3:57 PM, Nix wrote: >> The only unusual thing about the filesystems on this machine are that >> they have hardware RAID-5 (using the Areca driver), so I'm mounting with >> 'nobarrier': > > I should have read more. :( More questions follow: > > * Does the Areca have a battery backed write cache? Yes (though I'm not powering off, just rebooting). Battery at 100% and happy, though the lack of power-off means it's not actually getting used, since the cache is obviously mains-backed as well. > * Are you crashing or rebooting cleanly? Rebooting cleanly, everything umounted happily including /home and /var. > * Do you see log recovery messages in the logs for this filesystem? My memory says yes, but nothing seems to be logged when this happens (though with my logs on the first filesystem damaged by this, this is rather hard to tell, they're all quite full of NULs by now). I'll double-reboot tomorrow via the faulty kernel and check, unless I get asked not to in the interim. (And then double-reboot again to fsck everything...) >> the full set of options for all my ext4 filesystems are: >> >> rw,nosuid,nodev,relatime,journal_checksum,journal_async_commit,nobarrier,quota, >> usrquota,grpquota,commit=30,stripe=16,data=ordered,usrquota,grpquota > > ok journal_async_commit is off the reservation a bit; that's really not > tested, and Jan had serious reservations about its safety. OK, well, I've been 'testing' it for years :) No problems until now. (If anything, I was more concerned about journal_checksum. I thought that had actually been implicated in corruption before now...) > * Can you reproduce this w/o journal_async_commit? I can try! -- NULL && (void) -- 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/3] staging/sbe-2t3e3: Use netdev_ printks in main.c
On Wed, Oct 24, 2012 at 12:05:28PM +0900, YAMANE Toshiaki wrote: > fixed below checkpatch warning. > - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then > pr_err(... to printk(KERN_ERR ... > > Signed-off-by: YAMANE Toshiaki I never got the 3/3 patch in this series :( greg k-h -- 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: android: binder: Fixed multi-line strings
On Tue, Oct 23, 2012 at 03:13:38PM +0530, Anmol Sarma wrote: > >From 949ecac6fcd58ffa6d02f6761058dbcfb1c2ba42 Mon Sep 17 00:00:00 2001 > From: Anmol Sarma > Date: Tue, 23 Oct 2012 13:47:14 +0530 > Subject: [PATCH] Staging: android: binder: Strings cleanup > > Changed all user visible multi-line stings to single line. No you didn't: > @@ -420,12 +422,12 @@ static void binder_set_nice(long nice) > } > min_nice = 20 - current->signal->rlim[RLIMIT_NICE].rlim_cur; > binder_debug(BINDER_DEBUG_PRIORITY_CAP, > - "binder: %d: nice value %ld not allowed use " > + "%d: nice value %ld not allowed use " >"%ld instead\n", current->pid, nice, min_nice); That's a multi-line string :( And you sent 2 copies of this patch, why? Care to try again? greg k-h -- 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: linux-next: build failure after merge of the final tree (pm tree related)
Yes. We already do the patch to fix the warning yesterday after get the
information from Fengguang's "0-DAY kernel build testing". But do not refresh
linux-next so quickly.
Thanks for the information and patch, Stephen!
-Youquan
-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
Sent: Wednesday, October 24, 2012 11:44 AM
To: Rafael J. Wysocki
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Song, Youquan;
Rik van Riel
Subject: linux-next: build failure after merge of the final tree (pm tree
related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allnoconfig) failed like this:
In file included from arch/powerpc/kernel/idle.c:27:0:
include/linux/tick.h: In function 'menu_hrtimer_cancel':
include/linux/tick.h:148:48: error: 'return' with a value, in function
returning void [-Werror]
Several of these :-(
Caused by commit 25d77b76d7ae ("cpuidle: Quickly notice prediction failure for
repeat mode") from the pm tree. This build has CONFIG_CPU_IDLE_GOV_MENU turned
off. For changes that are obviously affected by CONFIG options, please test
build with the CONFIG option on and off.
I have applied the following patch for today:
From: Stephen Rothwell
Date: Wed, 24 Oct 2012 14:40:47 +1100
Subject: [PATCH] cpuidle: fix up but return type for inline function
Fixes this error when CONFIG_CPU_IDLE_GOV_MENU is not enabled:
In file included from arch/powerpc/kernel/idle.c:27:0:
include/linux/tick.h: In function 'menu_hrtimer_cancel':
include/linux/tick.h:148:48: error: 'return' with a value, in function
returning void [-Werror]
Signed-off-by: Stephen Rothwell
---
include/linux/tick.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/tick.h b/include/linux/tick.h index 8867424..40d123e
100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -145,7 +145,7 @@ static inline u64 get_cpu_iowait_time_us(int cpu, u64
*unused) { return -1; } # ifdef CONFIG_CPU_IDLE_GOV_MENU extern void
menu_hrtimer_cancel(void); # else -static inline void
menu_hrtimer_cancel(void) { return -1; }
+static inline void menu_hrtimer_cancel(void) { }
# endif /* CONFIG_CPU_IDLE_GOV_MENU */
#endif
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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] pwm: vt8500: Update vt8500 PWM driver support
On Wed, 2012-10-24 at 00:14 +0200, Thierry Reding wrote:
> On Tue, Oct 23, 2012 at 07:10:24AM +1300, Tony Prisk wrote:
> [...]
> > @@ -87,6 +98,11 @@ static int vt8500_pwm_enable(struct pwm_chip *chip,
> > struct pwm_device *pwm)
> > {
> > struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
> >
> > + if (!clk_enable(vt8500->clk)) {
> > + dev_err(chip->dev, "failed to enable clock\n");
> > + return -EBUSY;
> > + };
> > +
>
> I don't think that works. The clock API returns 0 on success and a
> negative error code on failure. So this should rather be something like:
>
> err = clk_enable(vt8500->clk);
> if (err < 0) {
> dev_err(chip->dev, "failed to enable clock: %d\n", err);
> return err;
> }
>
> > @@ -123,6 +153,12 @@ static int __devinit pwm_probe(struct platform_device
> > *pdev)
> > chip->chip.ops = _pwm_ops;
> > chip->chip.base = -1;
> > chip->chip.npwm = VT8500_NR_PWMS;
> > + chip->clk = devm_clk_get(>dev, NULL);
> > +
>
> The blank line should go above the call to devm_clk_get().
>
> > + if (IS_ERR_OR_NULL(chip->clk)) {
> > + dev_err(>dev, "clock source not specified\n");
> > + return PTR_ERR(chip->clk);
> > + }
> [...]
> > + if (!clk_prepare(chip->clk)) {
> > + dev_err(>dev, "failed to prepare clock\n");
> > + return -EBUSY;
> > + }
> > +
>
> Same comment here. I wonder how this code can work, since if the clock
> is properly prepared, then it will return 0, and the above will return
> -EBUSY.
>
> > ret = pwmchip_add(>chip);
> > - if (ret < 0)
> > + if (ret < 0) {
> > + dev_err(>dev, "failed to add pwmchip\n");
>
> Error messages can be considered prose, so this should be: "failed to
> add PWM chip".
>
> Thierry
I don't know why none of this caused a failure when boot tested. The
clock should have been disabled 'automagically' at bootup, and never
reenabled. *shrug* Fixed in new patch v3 (didn't notice there was
already a v3).
Regards
Tony P
--
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] pwm: vt8500: Update vt8500 PWM driver support
This patch updates pwm-vt8500.c to support devicetree probing and
make use of the common clock subsystem.
A binding document describing the PWM controller found on
arch-vt8500 is also included.
Signed-off-by: Tony Prisk
---
v2/v3:
Fix errors/coding style as pointed out by Thierry Reding.
.../devicetree/bindings/pwm/vt8500-pwm.txt | 17
drivers/pwm/pwm-vt8500.c | 86 ++--
2 files changed, 80 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
new file mode 100644
index 000..bcc6367
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -0,0 +1,17 @@
+VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
+
+Required properties:
+- compatible: should be "via,vt8500-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: should be 2. The first cell specifies the per-chip index
+ of the PWM to use and the second cell is the period in nanoseconds.
+- clocks: phandle to the PWM source clock
+
+Example:
+
+pwm1: pwm@d822 {
+ #pwm-cells = <2>;
+ compatible = "via,vt8500-pwm";
+ reg = <0xd822 0x1000>;
+ clocks = <>;
+};
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index ad14389..2ecd70f 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -1,7 +1,8 @@
/*
* drivers/pwm/pwm-vt8500.c
*
- * Copyright (C) 2010 Alexey Charkov
+ * Copyright (C) 2012 Tony Prisk
+ * Copyright (C) 2010 Alexey Charkov
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -21,14 +22,24 @@
#include
#include
#include
+#include
#include
-#define VT8500_NR_PWMS 4
+#include
+#include
+#include
+
+/*
+ * SoC architecture allocates register space for 4 PWMs but only
+ * 2 are currently implemented.
+ */
+#define VT8500_NR_PWMS 2
struct vt8500_chip {
struct pwm_chip chip;
void __iomem *base;
+ struct clk *clk;
};
#define to_vt8500_chip(chip) container_of(chip, struct vt8500_chip, chip)
@@ -52,7 +63,7 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
unsigned long long c;
unsigned long period_cycles, prescale, pv, dc;
- c = 2500/2; /* wild guess --- need to implement clocks */
+ c = clk_get_rate(vt8500->clk);
c = c * period_ns;
do_div(c, 10);
period_cycles = c;
@@ -85,8 +96,15 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
static int vt8500_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
+ int err;
struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
+ err = clk_enable(vt8500->clk);
+ if (err < 0)
+ dev_err(chip->dev, "failed to enable clock\n");
+ return -EBUSY;
+ };
+
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(5, vt8500->base + (pwm->hwpwm << 4));
return 0;
@@ -98,6 +116,8 @@ static void vt8500_pwm_disable(struct pwm_chip *chip, struct
pwm_device *pwm)
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(0, vt8500->base + (pwm->hwpwm << 4));
+
+ clk_disable(vt8500->clk);
}
static struct pwm_ops vt8500_pwm_ops = {
@@ -107,12 +127,24 @@ static struct pwm_ops vt8500_pwm_ops = {
.owner = THIS_MODULE,
};
-static int __devinit pwm_probe(struct platform_device *pdev)
+static const struct of_device_id vt8500_pwm_dt_ids[] = {
+ { .compatible = "via,vt8500-pwm", },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, vt8500_pwm_dt_ids);
+
+static int vt8500_pwm_probe(struct platform_device *pdev)
{
struct vt8500_chip *chip;
struct resource *r;
+ struct device_node *np = pdev->dev.of_node;
int ret;
+ if (!np) {
+ dev_err(>dev, "invalid devicetree node\n");
+ return -EINVAL;
+ }
+
chip = devm_kzalloc(>dev, sizeof(*chip), GFP_KERNEL);
if (chip == NULL) {
dev_err(>dev, "failed to allocate memory\n");
@@ -124,6 +156,12 @@ static int __devinit pwm_probe(struct platform_device
*pdev)
chip->chip.base = -1;
chip->chip.npwm = VT8500_NR_PWMS;
+ chip->clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR_OR_NULL(chip->clk)) {
+ dev_err(>dev, "clock source not specified\n");
+ return PTR_ERR(chip->clk);
+ }
+
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
dev_err(>dev, "no memory resource defined\n");
@@ -131,18 +169,26 @@ static int __devinit pwm_probe(struct platform_device
*pdev)
}
chip->base =
Re: process hangs on do_exit when oom happens
On Wed, Oct 24, 2012 at 1:43 AM, Balbir Singh wrote: > On Tue, Oct 23, 2012 at 3:45 PM, Michal Hocko wrote: >> On Tue 23-10-12 18:10:33, Qiang Gao wrote: >>> On Tue, Oct 23, 2012 at 5:50 PM, Michal Hocko wrote: >>> > On Tue 23-10-12 15:18:48, Qiang Gao wrote: >>> >> This process was moved to RT-priority queue when global oom-killer >>> >> happened to boost the recovery of the system.. >>> > >>> > Who did that? oom killer doesn't boost the priority (scheduling class) >>> > AFAIK. >>> > >>> >> but it wasn't get properily dealt with. I still have no idea why where >>> >> the problem is .. >>> > >>> > Well your configuration says that there is no runtime reserved for the >>> > group. >>> > Please refer to Documentation/scheduler/sched-rt-group.txt for more >>> > information. >>> > >> [...] >>> maybe this is not a upstream-kernel bug. the centos/redhat kernel >>> would boost the process to RT prio when the process was selected >>> by oom-killer. >> >> This still looks like your cpu controller is misconfigured. Even if the >> task is promoted to be realtime. > > > Precisely! You need to have rt bandwidth enabled for RT tasks to run, > as a workaround please give the groups some RT bandwidth and then work > out the migration to RT and what should be the defaults on the distro. > > Balbir see https://patchwork.kernel.org/patch/719411/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the final tree (pm tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allnoconfig) failed like this:
In file included from arch/powerpc/kernel/idle.c:27:0:
include/linux/tick.h: In function 'menu_hrtimer_cancel':
include/linux/tick.h:148:48: error: 'return' with a value, in function
returning void [-Werror]
Several of these :-(
Caused by commit 25d77b76d7ae ("cpuidle: Quickly notice prediction
failure for repeat mode") from the pm tree. This build has
CONFIG_CPU_IDLE_GOV_MENU turned off. For changes that are obviously
affected by CONFIG options, please test build with the CONFIG option on
and off.
I have applied the following patch for today:
From: Stephen Rothwell
Date: Wed, 24 Oct 2012 14:40:47 +1100
Subject: [PATCH] cpuidle: fix up but return type for inline function
Fixes this error when CONFIG_CPU_IDLE_GOV_MENU is not enabled:
In file included from arch/powerpc/kernel/idle.c:27:0:
include/linux/tick.h: In function 'menu_hrtimer_cancel':
include/linux/tick.h:148:48: error: 'return' with a value, in function
returning void [-Werror]
Signed-off-by: Stephen Rothwell
---
include/linux/tick.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/tick.h b/include/linux/tick.h
index 8867424..40d123e 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -145,7 +145,7 @@ static inline u64 get_cpu_iowait_time_us(int cpu, u64
*unused) { return -1; }
# ifdef CONFIG_CPU_IDLE_GOV_MENU
extern void menu_hrtimer_cancel(void);
# else
-static inline void menu_hrtimer_cancel(void) { return -1; }
+static inline void menu_hrtimer_cancel(void) { }
# endif /* CONFIG_CPU_IDLE_GOV_MENU */
#endif
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpE2R0cizhs0.pgp
Description: PGP signature
Re: [PATCH 2/5] ARM: tegra: dts: add slink controller dt entry
On Fri, 2012-10-19 at 09:56 -0600, Stephen Warren wrote:
> On 10/19/2012 03:10 AM, Laxman Dewangan wrote:
> > On Friday 19 October 2012 04:11 AM, Stephen Warren wrote:
> >> On 10/18/2012 04:56 AM, Laxman Dewangan wrote:
> >>> Add slink controller details in the dts file of
> >>> Tegra20 and Tegra30.
> >>> diff --git a/arch/arm/boot/dts/tegra20.dtsi
> >>> b/arch/arm/boot/dts/tegra20.dtsi
> >>> +slink@7000d400 {
> >>> +compatible = "nvidia,tegra20-slink";
> >>> +reg =<0x7000d400 0x200>;
> >>> +interrupts =<0 59 0x04>;
> >>> +nvidia,dma-req-sel =<15>;
> >
>
> (Oh, you need a space before and after the = in all the lines above)
>
> >> I thought the common DT DMA bindings were going to be in 3.7, and hence
> >> we could just use them here rather than inventing another custom
> >> property for this purpose?
> >
> > Adding Vinod here.
> >
> > I looked the dma devicetree bingind document and did not found the
> > generic binding name. Howvere, for arm-pl330.txt, it is explained as ...
>
> That's not the generic bindings. I guess they didn't get merged then. I
> guess we can continue with custom bindings until they are.
Yes they are in topic topic/dmaengine_dt in my tree. Will be merged once
we sort out slave apis.
--
Vinod Koul
Intel Corp.
--
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] Replace the type check code with typecheck() in kfifo_in
In kfifo_in marco, one piece of code which is arounded by if(0) will check the
type of __tmp->ptr_const and __buf. If they are different type, there will
output a warning during compiling. This piece of code is not self explaining
and a little bit hard to understand.
Based on Andrew Morton's suggestion, this patch replace this with typecheck()
which will be easy to understand.
In the same file, there are several places with the same code style. This
patch change them too.
Signed-off-by: Wei Yang
Reviewed-by: Andrew Morton
Reviewed-by: richard -rw- weinberger
---
include/linux/kfifo.h | 22 +-
1 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
index 10308c6..680c293 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -390,10 +390,7 @@ __kfifo_int_must_check_helper( \
unsigned int __ret; \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) { \
- typeof(__tmp->ptr_const) __dummy __attribute__ ((unused)); \
- __dummy = (typeof(__val))NULL; \
- } \
+ typecheck(typeof(__tmp->ptr_const), __val); \
if (__recsize) \
__ret = __kfifo_in_r(__kfifo, __val, sizeof(*__val), \
__recsize); \
@@ -433,7 +430,7 @@ __kfifo_uint_must_check_helper( \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
if (0) \
- __val = (typeof(__tmp->ptr))0; \
+ __val = (typeof(__tmp->ptr))NULL; \
if (__recsize) \
__ret = __kfifo_out_r(__kfifo, __val, sizeof(*__val), \
__recsize); \
@@ -512,10 +509,7 @@ __kfifo_uint_must_check_helper( \
unsigned long __n = (n); \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) { \
- typeof(__tmp->ptr_const) __dummy __attribute__ ((unused)); \
- __dummy = (typeof(__buf))NULL; \
- } \
+ typecheck(typeof(__tmp->ptr_const), __buf);\
(__recsize) ?\
__kfifo_in_r(__kfifo, __buf, __n, __recsize) : \
__kfifo_in(__kfifo, __buf, __n); \
@@ -565,10 +559,7 @@ __kfifo_uint_must_check_helper( \
unsigned long __n = (n); \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) { \
- typeof(__tmp->ptr) __dummy = NULL; \
- __buf = __dummy; \
- } \
+ typecheck(typeof(__tmp->ptr), __buf); \
(__recsize) ?\
__kfifo_out_r(__kfifo, __buf, __n, __recsize) : \
__kfifo_out(__kfifo, __buf, __n); \
@@ -777,10 +768,7 @@ __kfifo_uint_must_check_helper( \
unsigned long __n = (n); \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) { \
- typeof(__tmp->ptr) __dummy __attribute__ ((unused)) = NULL; \
- __buf = __dummy; \
- } \
+ typecheck(typeof(__tmp->ptr), __buf); \
(__recsize) ? \
__kfifo_out_peek_r(__kfifo, __buf, __n, __recsize) : \
__kfifo_out_peek(__kfifo, __buf, __n); \
--
1.7.5.4
--
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] dmaengine: imx-dma: fix missing unlock on error in imxdma_xfer_desc()
On Sun, 2012-10-21 at 19:58 +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Add the missing unlock on the error handling path in function
> imxdma_xfer_desc().
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/dma/imx-dma.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
> index f11b5b2..7d9554c 100644
> --- a/drivers/dma/imx-dma.c
> +++ b/drivers/dma/imx-dma.c
> @@ -474,8 +474,10 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
> slot = i;
> break;
> }
> - if (slot < 0)
> + if (slot < 0) {
> + spin_unlock_irqrestore(>lock, flags);
> return -EBUSY;
> + }
>
> imxdma->slots_2d[slot].xsr = d->x;
> imxdma->slots_2d[slot].ysr = d->y;
>
>
> --
Thanks applied
--
Vinod Koul
Intel Corp.
--
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] firmware loader: introduce kernel parameter to customize fw search path
On Wed, Oct 24, 2012 at 11:18 AM, Greg Kroah-Hartman wrote: > > Ick, no, not another kernel boot parameter. I would prefer the /proc/ > file solution instead, just like /proc/sys/kernel/hotplug is. OK, got it, but we could use the module parameter(firmware_class.path via kernel command) to customize the search path too, couldn't we? > > But, that really wouldn't work for boot time, so, again just like > hotplug works, make it also a Kconfig option for those distros that > build their own kernels and keep their firmware in odd places, or don't > have a /lib/ directory, can override it easily. Sound like still a solution, :-) If you agree on module parameter, that might be more flexible, IMO Thanks, -- Ming Lei -- 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 041/193] drivers/dma: remove CONFIG_EXPERIMENTAL
On Tue, 2012-10-23 at 13:01 -0700, Kees Cook wrote: > This config item has not carried much meaning for a while now and is > almost always enabled by default. As agreed during the Linux kernel > summit, remove it. > > CC: Vinod Koul > CC: Dan Williams > Signed-off-by: Kees Cook > --- > drivers/dma/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig > index 677cd6e..dc8f4d1 100644 > --- a/drivers/dma/Kconfig > +++ b/drivers/dma/Kconfig > @@ -51,7 +51,7 @@ config ASYNC_TX_ENABLE_CHANNEL_SWITCH > > config AMBA_PL08X > bool "ARM PrimeCell PL080 or PL081 support" > - depends on ARM_AMBA && EXPERIMENTAL > + depends on ARM_AMBA > select DMA_ENGINE > select DMA_VIRTUAL_CHANNELS > help Applied thanks -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()
On Tue, 2012-10-23 at 23:49 +0100, Grant Likely wrote:
> > +enum dmaengine_apis {
> > + DMAENGINE_MEMCPY= 0x0001,
> > + DMAENGINE_XOR = 0x0002,
> > + DMAENGINE_XOR_VAL = 0x0004,
> > + DMAENGINE_PQ= 0x0008,
> > + DMAENGINE_PQ_VAL= 0x0010,
> > + DMAENGINE_MEMSET= 0x0020,
> > + DMAENGINE_SLAVE = 0x0040,
> > + DMAENGINE_CYCLIC= 0x0080,
> > + DMAENGINE_INTERLEAVED = 0x0100,
> > + DMAENGINE_SG= 0x0200,
> > +};
>
> Actually, one more comment. Why the new enum? Why can't the
> dma_transaction_type enum be used directly along with dma_cap_mask_t?
Some of the capabilities above are not there in dma_caps_t like DMA_SG.
Also DMA_INTERRUPT and DMA_PRIVATE would not make much sense here.
BUT would help to keep things simpler if have one definition which
includes all.
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()
On Tue, 2012-10-23 at 15:54 -0700, Dan Williams wrote:
> > +struct dmaengine_chan_caps {
> > + enum dmaengine_apis ops;
> > + int seg_nr;
> > + int seg_len;
> > +};
>
> This makes sense for the potentially dynamic capability properties
> that get set after configuration, but why do we need the operation
> types here? They can be retrieved from the parent device.
I was thinking that each channel can have different capabilities.
You can assign one channel for mempcy operations exclusively and some
others for slave usage exclusively.
I believe some h/w do have such assignment so would help in doing that.
--
Vinod Koul
Intel Corp.
--
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] firmware loader: introduce kernel parameter to customize fw search path
On Wed, Oct 24, 2012 at 10:49:53AM +0800, Ming Lei wrote: > This patch introduces one kernel parameter of 'fw_path' to support > customizing firmware image search path, so that people can use its > own firmware path if the default built-in paths can't meet their demand[1]. > > [1], https://lkml.org/lkml/2012/10/11/337 > > Cc: Linus Torvalds > Signed-off-by: Ming Lei Ick, no, not another kernel boot parameter. I would prefer the /proc/ file solution instead, just like /proc/sys/kernel/hotplug is. But, that really wouldn't work for boot time, so, again just like hotplug works, make it also a Kconfig option for those distros that build their own kernels and keep their firmware in odd places, or don't have a /lib/ directory, can override it easily. thanks, greg k-h -- 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/comedi: Use dev_ printks in drivers/vmk80xx.c
On Tue, Oct 23, 2012 at 4:45 AM, Greg Kroah-Hartman wrote: > Note, when you resend please enumerate what version of the patch this > is, otherwise I can get very confused. Sorry, I am going to watch out for it from the next. -- Regards, YAMANE Toshiaki -- 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] brw_mutex: big read-write mutex
On Fri, Oct 19, 2012 at 06:54:41PM -0400, Mikulas Patocka wrote: > > > On Fri, 19 Oct 2012, Peter Zijlstra wrote: > > > > Yes, I tried this approach - it involves doing LOCK instruction on read > > > lock, remembering the cpu and doing another LOCK instruction on read > > > unlock (which will hopefully be on the same CPU, so no cacheline bouncing > > > happens in the common case). It was slower than the approach without any > > > LOCK instructions (43.3 seconds seconds for the implementation with > > > per-cpu LOCKed access, 42.7 seconds for this implementation without > > > atomic > > > instruction; the benchmark involved doing 512-byte direct-io reads and > > > writes on a ramdisk with 8 processes on 8-core machine). > > > > So why is that a problem? Surely that's already tons better then what > > you've currently got. > > Percpu rw-semaphores do not improve performance at all. I put them there > to avoid performance regression, not to improve performance. > > All Linux kernels have a race condition - when you change block size of a > block device and you read or write the device at the same time, a crash > may happen. This bug is there since ever. Recently, this bug started to > cause major trouble - multiple high profile business sites report crashes > because of this race condition. > > You can fix this race by using a read lock around I/O paths and write lock > around block size changing, but normal rw semaphore cause cache line > bouncing when taken for read by multiple processors and I/O performance > degradation because of it is measurable. This doesn't sound like a new problem. Hasn't this global access, single modifier exclusion problem been solved before in the VFS? e.g. mnt_want_write()/mnt_make_readonly() Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS after deleting file on ext4 filesystem
On Tue, Oct 23, 2012 at 08:50:22PM -0400, Nick Bowler wrote: > Hi folks, > > I just saw an ext4 oops on one of my machines after a couple months of > uptime, on Linux 3.5.2. I doubt I will be able to reproduce the problem > easily so I'm just posting this in case anyone can tell what's going on. Fixed in v3.5.3 or later kernels. (Commit 2cd45bebc56a) - Ted -- 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] staging/sbe-2t3e3: Use netdev_ printks in main.c
fixed below checkpatch warning. - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ... Signed-off-by: YAMANE Toshiaki --- drivers/staging/sbe-2t3e3/main.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/staging/sbe-2t3e3/main.c b/drivers/staging/sbe-2t3e3/main.c index f3dbef6..c8e0398 100644 --- a/drivers/staging/sbe-2t3e3/main.c +++ b/drivers/staging/sbe-2t3e3/main.c @@ -135,9 +135,10 @@ void t3e3_read_card_serial_number(struct channel *sc) for (i = 0; i < 3; i++) sc->ether.card_serial_number[i] = t3e3_eeprom_read_word(sc, 10 + i); - printk(KERN_INFO "SBE wanPMC-2T3E3 serial number: %04X%04X%04X\n", - sc->ether.card_serial_number[0], sc->ether.card_serial_number[1], - sc->ether.card_serial_number[2]); + netdev_info(sc->dev, "SBE wanPMC-2T3E3 serial number: %04X%04X%04X\n", + sc->ether.card_serial_number[0], + sc->ether.card_serial_number[1], + sc->ether.card_serial_number[2]); } /* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] posix timers: allocate timer id per process
On Wed, 2012-10-24 at 00:33 +0200, Thomas Gleixner wrote: > On Tue, 23 Oct 2012, Eric Dumazet wrote: > > > On Tue, 2012-10-23 at 23:47 +0200, Thomas Gleixner wrote: > > > > > Not so good to me. > > > > > > > Signed-off-by: Eric Dumazet > > > > > > And that should be either an Acked-by or a Reviewed-by. You can't sign > > > off on patches which have not been submitted or transported by you. > > > > I actually gave some input, provided a hash function, and so on. > > > > So this SOB was valid. I do that all the time. > > Not really. I recommend you to read the relevant file in Documentation > which covers what can have your SOB. OK I did that again, and found this : The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path. And I was involved in the development of the patch. I understand you dont like it at all, so I'll remember not trying to help anymore in this area. -- 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 00/16 v2] f2fs: introduce flash-friendly file system
On Wed, Oct 24, 2012 at 08:18:36AM +0900, Jaegeuk Kim wrote: > > On Tue, Oct 23, 2012 at 11:26:59AM -0700, Greg KH wrote: > > > On Tue, Oct 23, 2012 at 11:21:53AM +0900, Jaegeuk Kim wrote: > > > > mkfs.f2fs > > > > = > > > > > > > > The file system formatting tool, "mkfs.f2fs", is available from the > > > > following > > > > download page: http://sourceforge.net/projects/f2fs-tools/ > > > > > > Is there a git tree of this tool somewhere, so I don't have to > > > constantly suffer the sf.net download interface every time I want to get > > > the latest version? > > > > Oh, and where do we report bugs for this tool? I just formatted a usb > > stick with the mkfs.f2fs program, and it did not fully erase the old > > filesystem that was on there (iso9660), so when I mounted it, it did so > > in iso9660 mode, not f2fs mode. > > > > Any suggestion for reporting bugs? > Maybe via a mailing list? Mailing list is fine. > What version did you use? (1.1.0 is correct.) I used 1.1.0 > The reason we found was due to the 0'th block, so we fixed that in v1.1.0. Hm, that's what I used. I zeroed out the whole usb disk and tried again and it worked then, I was trying to debug the kernel changes, not the userspace tool, so I didn't spend much time on it :) But, if you do get a public git tree up, I will at the very least, provide a patch to handle '-h' properly for mkfs, that should work... thanks, greg k-h -- 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 00/16 v2] f2fs: introduce flash-friendly file system
On Wed, Oct 24, 2012 at 08:14:44AM +0900, Jaegeuk Kim wrote: > > On Tue, Oct 23, 2012 at 11:21:53AM +0900, Jaegeuk Kim wrote: > > > mkfs.f2fs > > > = > > > > > > The file system formatting tool, "mkfs.f2fs", is available from the > > > following > > > download page:http://sourceforge.net/projects/f2fs-tools/ > > > > Is there a git tree of this tool somewhere, so I don't have to > > constantly suffer the sf.net download interface every time I want to get > > the latest version? > > I'd love to do like that. > I've managed a git tree for tools in house only, due to the company secret. > Would you suggest something for this? > I can do managing the tree outside though. git.kernel.org can work, so can github, and also, you have a sf.net project, why not use the git tree it provides you? Right now it is empty. thanks, greg k-h -- 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: usbview 2.0 release
On Tue, Oct 23, 2012 at 10:17:22AM +0530, Anil Nair wrote: > Hello Greg, > > > No, debugfs needs to be mounted at /sys/kernel/debug/ Is it not mounted > > that way for you? Perhaps it is mounted with root-only access (default > > for 3.7-rc1 and newer kernels)? > > Yes you are right i verified "/sys/kernel/debug" has root-only access. > The kernel version i am using is 3.0.0-26-generic(Default kernel > provided by ubuntu 11.10 amd64). > > > I should just port the thing to use libusb instead of debugfs, but > > that's a larger job for such a low-priority tool. > > If you don't mind i would like to give it a try, though most of the > terminologies i don't know but i would like to give it a try, just > guide me on way of doing it thats all. Look at how the lsusb tool walks the list of all USB devices in the system, using libusb, and port that code over to usbview, replacing the big "walk and parse the devices file" functionality. It shouldn't be that hard, if you run into any problems, please let me know. thanks, greg k-h -- 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] staging/sbe-2t3e3: Use netdev_ or dev_ or pr_ printks in module.c
fixed below checkpatch warning.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
- WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then
pr_warn(... to printk(KERN_WARNING ...
and add pr_fmt.
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/sbe-2t3e3/module.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/sbe-2t3e3/module.c
b/drivers/staging/sbe-2t3e3/module.c
index 8adb178..8e1a043 100644
--- a/drivers/staging/sbe-2t3e3/module.c
+++ b/drivers/staging/sbe-2t3e3/module.c
@@ -10,6 +10,8 @@
* This code is based on a driver written by SBE Inc.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -66,7 +68,7 @@ static int __devinit t3e3_init_channel(struct channel
*channel, struct pci_dev *
dev = alloc_hdlcdev(channel);
if (!dev) {
- printk(KERN_ERR "SBE 2T3E3" ": Out of memory\n");
+ pr_err("Out of memory\n");
err = -ENOMEM;
goto free_regions;
}
@@ -96,7 +98,8 @@ static int __devinit t3e3_init_channel(struct channel
*channel, struct pci_dev *
err = request_irq(dev->irq, _intr, IRQF_SHARED, dev->name, dev);
if (err) {
- printk(KERN_WARNING "%s: could not get irq: %d\n", dev->name,
dev->irq);
+ netdev_warn(channel->dev, "%s: could not get irq: %d\n",
+ dev->name, dev->irq);
goto unregister_dev;
}
@@ -144,7 +147,7 @@ static int __devinit t3e3_init_card(struct pci_dev *pdev,
const struct pci_devic
break; /* found the second channel */
if (!pdev1) {
- printk(KERN_ERR "SBE 2T3E3" ": Can't find the second
channel\n");
+ dev_err(>dev, "Can't find the second channel\n");
return -EFAULT;
}
channels = 2;
@@ -153,7 +156,7 @@ static int __devinit t3e3_init_card(struct pci_dev *pdev,
const struct pci_devic
card = kzalloc(sizeof(struct card) + channels * sizeof(struct channel),
GFP_KERNEL);
if (!card) {
- printk(KERN_ERR "SBE 2T3E3" ": Out of memory\n");
+ dev_err(>dev, "Out of memory\n");
return -ENOBUFS;
}
--
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: Re: [Pv-drivers] 3.7-rc2 regression : file copied to CIFS-mounted directory corrupted
Hi,
--- Original Message ---
Sender : Eric Dumazet
Date : 2012-10-24 04:39 (GMT+09:00)
Title : Re: [Pv-drivers] 3.7-rc2 regression : file copied to CIFS-mounted
directory corrupted
On Tue, 2012-10-23 at 15:50 +0200, Eric Dumazet wrote:
> Only the skb head is handled in the code you copy/pasted.
>
> You need to generalize that to code in lines ~754
>
>
> Then, the number of estimated descriptors is bad :
>
> /* conservatively estimate # of descriptors to use */
> count = VMXNET3_TXD_NEEDED(skb_headlen(skb)) +
> skb_shinfo(skb)->nr_frags + 1;
>
>
> Yes, you need a more precise estimation and vmxnet3_map_pkt() should
> eventually split too big frags.
raw patch would be :
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index ce9d4f2..0ae1bcc 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -744,28 +744,43 @@ vmxnet3_map_pkt(struct sk_buff *skb, struct
vmxnet3_tx_ctx *ctx,
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
const struct skb_frag_struct *frag = _shinfo(skb)->frags[i];
+ u32 buf_size;
- tbi = tq->buf_info + tq->tx_ring.next2fill;
- tbi->map_type = VMXNET3_MAP_PAGE;
- tbi->dma_addr = skb_frag_dma_map(>pdev->dev, frag,
- 0, skb_frag_size(frag),
- DMA_TO_DEVICE);
+ buf_offset = 0;
+ len = skb_frag_size(frag);
+ while (len) {
+ tbi = tq->buf_info + tq->tx_ring.next2fill;
+ if (len < VMXNET3_MAX_TX_BUF_SIZE) {
+ buf_size = len;
+ dw2 |= len;
+ } else {
+ buf_size = VMXNET3_MAX_TX_BUF_SIZE;
+ /* spec says that for TxDesc.len, 0 == 2^14 */
+ }
+ tbi->map_type = VMXNET3_MAP_PAGE;
+ tbi->dma_addr = skb_frag_dma_map(>pdev->dev, frag,
+ buf_offset, buf_size,
+ DMA_TO_DEVICE);
- tbi->len = skb_frag_size(frag);
+ tbi->len = buf_size;
- gdesc = tq->tx_ring.base + tq->tx_ring.next2fill;
- BUG_ON(gdesc->txd.gen == tq->tx_ring.gen);
+ gdesc = tq->tx_ring.base + tq->tx_ring.next2fill;
+ BUG_ON(gdesc->txd.gen == tq->tx_ring.gen);
- gdesc->txd.addr = cpu_to_le64(tbi->dma_addr);
- gdesc->dword[2] = cpu_to_le32(dw2 | skb_frag_size(frag));
- gdesc->dword[3] = 0;
+ gdesc->txd.addr = cpu_to_le64(tbi->dma_addr);
+ gdesc->dword[2] = cpu_to_le32(dw2);
+ gdesc->dword[3] = 0;
- dev_dbg(>netdev->dev,
- "txd[%u]: 0x%llu %u %u\n",
- tq->tx_ring.next2fill, le64_to_cpu(gdesc->txd.addr),
- le32_to_cpu(gdesc->dword[2]), gdesc->dword[3]);
- vmxnet3_cmd_ring_adv_next2fill(>tx_ring);
- dw2 = tq->tx_ring.gen << VMXNET3_TXD_GEN_SHIFT;
+ dev_dbg(>netdev->dev,
+ "txd[%u]: 0x%llu %u %u\n",
+ tq->tx_ring.next2fill, le64_to_cpu(gdesc->txd.addr),
+ le32_to_cpu(gdesc->dword[2]), gdesc->dword[3]);
+ vmxnet3_cmd_ring_adv_next2fill(>tx_ring);
+ dw2 = tq->tx_ring.gen << VMXNET3_TXD_GEN_SHIFT;
+
+ len -= buf_size;
+ buf_offset += buf_size;
+ }
}
ctx->eop_txd = gdesc;
@@ -886,6 +901,18 @@ vmxnet3_prepare_tso(struct sk_buff *skb,
}
}
+static int txd_estimate(const struct sk_buff *skb)
+{
+ int count = VMXNET3_TXD_NEEDED(skb_headlen(skb)) + 1;
+ int i;
+
+ for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ const struct skb_frag_struct *frag = _shinfo(skb)->frags[i];
+
+ count += VMXNET3_TXD_NEEDED(skb_frag_size(frag));
+ }
+ return count;
+}
/*
* Transmits a pkt thru a given tq
@@ -914,9 +941,7 @@ vmxnet3_tq_xmit(struct sk_buff *skb, struct
vmxnet3_tx_queue *tq,
union Vmxnet3_GenericDesc tempTxDesc;
#endif
- /* conservatively estimate # of descriptors to use */
- count = VMXNET3_TXD_NEEDED(skb_headlen(skb)) +
- skb_shinfo(skb)->nr_frags + 1;
+ count = txd_estimate(skb);
ctx.ipv4 = (vlan_get_protocol(skb) == cpu_to_be16(ETH_P_IP));
--- Original Message End ---
Hi, Eric,
your raw patch seemed to fix the issue. But after ~200 runs, copied file has
been corrupted again.
# cmp -l /home/local.bin /mnt/cifs/new.bin | awk '{printf "%08X %02X %02X\n",
$1, strtonum(0$2), strtonum(0$3)}' > diff.log
I compared the difference between source and copied file. Size of file is
45872732 bytes (= 0x2BBF65C).
Among them, 4096 (0x1000) bytes are different, from 0x2B96001 to 0x2B97000.
Instead of original data, 0x00 was copied in those area.
patch applied on top of 2d1f4c8e ("Merge branch 'drm-fixes' of
git://people.freedesktop.org/~airlied/linux").
Regards,
Jongman Heo.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: linux-next: build failure after merge of the tty tree
On Wed, Oct 24, 2012 at 01:28:27PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/staging/dgrp/dgrp_net_ops.c: In function 'dgrp_input':
> drivers/staging/dgrp/dgrp_net_ops.c:216:27: error: 'struct tty_struct' has no
> member named 'real_raw'
> drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
> member named 'read_cnt'
> drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
> member named 'read_cnt'
> drivers/staging/dgrp/dgrp_net_ops.c:261:30: error: 'struct tty_struct' has no
> member named 'real_raw'
> drivers/staging/dgrp/dgrp_net_ops.c:276:28: error: 'struct tty_struct' has no
> member named 'real_raw'
>
> Caused by commits 53c5ee2cfb4d ("TTY: move ldisc data from tty_struct:
> simple members") and ba2e68ac6157 ("TTY: move ldisc data from tty_struct:
> read_* and echo_* and canon_* stuff") interacting with commit
> 0b52b7497271 ("staging: Add dgrp driver for Digi Realport devices") now
> in Linus' tree.
>
> I disabled building of the dgrp driver for now using this merge fix patch:
>
> From: Stephen Rothwell
> Date: Wed, 24 Oct 2012 13:25:29 +1100
> Subject: [PATCH] staging: disable dgrp driver since it is broken by tty
> changes
>
> drivers/staging/dgrp/dgrp_net_ops.c: In function 'dgrp_input':
> drivers/staging/dgrp/dgrp_net_ops.c:216:27: error: 'struct tty_struct' has no
> member named 'real_raw'
> drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
> member named 'read_cnt'
> drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
> member named 'read_cnt'
> drivers/staging/dgrp/dgrp_net_ops.c:261:30: error: 'struct tty_struct' has no
> member named 'real_raw'
> drivers/staging/dgrp/dgrp_net_ops.c:276:28: error: 'struct tty_struct' has no
> member named 'real_raw'
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/staging/dgrp/Kconfig |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/dgrp/Kconfig b/drivers/staging/dgrp/Kconfig
> index 39f4bb6..7d378c2 100644
> --- a/drivers/staging/dgrp/Kconfig
> +++ b/drivers/staging/dgrp/Kconfig
> @@ -2,6 +2,7 @@ config DGRP
> tristate "Digi Realport driver"
> default n
> depends on SYSFS
> + depends on BROKEN
Thanks, that makes sense for now, hopefully Jiri will return from his
conference and fix this driver up.
greg k-h
--
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] firmware loader: introduce kernel parameter to customize fw search path
This patch introduces one kernel parameter of 'fw_path' to support
customizing firmware image search path, so that people can use its
own firmware path if the default built-in paths can't meet their demand[1].
[1], https://lkml.org/lkml/2012/10/11/337
Cc: Linus Torvalds
Signed-off-by: Ming Lei
---
Documentation/firmware_class/README |1 +
Documentation/kernel-parameters.txt |9 +
drivers/base/firmware_class.c | 24 ++--
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/Documentation/firmware_class/README
b/Documentation/firmware_class/README
index 815b711..af63ad3 100644
--- a/Documentation/firmware_class/README
+++ b/Documentation/firmware_class/README
@@ -22,6 +22,7 @@
- calls request_firmware(_entry, $FIRMWARE, device)
- kernel searchs the fimware image with name $FIRMWARE directly
in the below search path of root filesystem:
+ User customized search path by kernel parameter of 'fw_path'
"/lib/firmware/updates/" UTS_RELEASE,
"/lib/firmware/updates",
"/lib/firmware/" UTS_RELEASE,
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 9776f06..d1125c5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -52,6 +52,7 @@ parameter is applicable:
EVM Extended Verification Module
FB The frame buffer device is enabled.
FTRACE Function tracing enabled.
+ FW The firmware loader is enabled.
GCOVGCOV profiling is enabled.
HW Appropriate hardware is enabled.
IA-64 IA-64 architecture is enabled.
@@ -843,6 +844,14 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Format: ,,,
See also Documentation/fault-injection/.
+ fw_path=[FW]
+ Customized firmware image search path for kernel
+ direct loading, which has higher priority than
+ built-in default search path.
+ Format: , length < 256
+ direcory path, such as /lib/firmware.
+ See Documentation/firmware_class/README.
+
floppy= [HW]
See Documentation/blockdev/floppy.txt.
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8945f4e..e7db931 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -274,6 +274,17 @@ static const char *fw_path[] = {
"/lib/firmware"
};
+static char fw_path_para[256];
+static int __init customized_path(char *str)
+{
+ if (strlen(str) < 256)
+ strlcpy(fw_path_para, str, sizeof(fw_path_para));
+ return 1;
+}
+__setup("fw_path=", customized_path);
+module_param_string(path, fw_path_para, sizeof(fw_path_para), 0644);
+MODULE_PARM_DESC(path, "customized firmware image search path with a higher
priority than default path");
+
/* Don't inline this: 'struct kstat' is biggish */
static noinline long fw_file_size(struct file *file)
{
@@ -313,9 +324,18 @@ static bool fw_get_filesystem_firmware(struct firmware_buf
*buf)
bool success = false;
char *path = __getname();
- for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
+ for (i = -1; i < ARRAY_SIZE(fw_path); i++) {
struct file *file;
- snprintf(path, PATH_MAX, "%s/%s", fw_path[i], buf->fw_id);
+
+ if (i < 0) {
+ if (!fw_path_para[0]) /* No customized path */
+ continue;
+ snprintf(path, PATH_MAX, "%s/%s", fw_path_para,
+buf->fw_id);
+ } else {
+ snprintf(path, PATH_MAX, "%s/%s", fw_path[i],
+buf->fw_id);
+ }
file = filp_open(path, O_RDONLY, 0);
if (IS_ERR(file))
--
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 1/2] firmware loader: document kernel direct loading
This patch adds description on recently introduced direct firmware
loading by Linus.
Cc: Linus Torvalds
Signed-off-by: Ming Lei
---
Documentation/firmware_class/README | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/Documentation/firmware_class/README
b/Documentation/firmware_class/README
index 7eceaff..815b711 100644
--- a/Documentation/firmware_class/README
+++ b/Documentation/firmware_class/README
@@ -18,32 +18,40 @@
High level behavior (mixed):
- kernel(driver): calls request_firmware(_entry, $FIRMWARE, device)
-
- userspace:
+ 1), kernel(driver):
+ - calls request_firmware(_entry, $FIRMWARE, device)
+ - kernel searchs the fimware image with name $FIRMWARE directly
+ in the below search path of root filesystem:
+ "/lib/firmware/updates/" UTS_RELEASE,
+ "/lib/firmware/updates",
+ "/lib/firmware/" UTS_RELEASE,
+ "/lib/firmware"
+ - If found, goto 7), else goto 2)
+
+ 2), userspace:
- /sys/class/firmware/xxx/{loading,data} appear.
- hotplug gets called with a firmware identifier in $FIRMWARE
and the usual hotplug environment.
- hotplug: echo 1 > /sys/class/firmware/xxx/loading
- kernel: Discard any previous partial load.
+ 3), kernel: Discard any previous partial load.
- userspace:
+ 4), userspace:
- hotplug: cat appropriate_firmware_image > \
/sys/class/firmware/xxx/data
- kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
+ 5), kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
comes in.
- userspace:
+ 6), userspace:
- hotplug: echo 0 > /sys/class/firmware/xxx/loading
- kernel: request_firmware() returns and the driver has the firmware
+ 7), kernel: request_firmware() returns and the driver has the firmware
image in fw_entry->{data,size}. If something went wrong
request_firmware() returns non-zero and fw_entry is set to
NULL.
- kernel(driver): Driver code calls release_firmware(fw_entry) releasing
+ 8), kernel(driver): Driver code calls release_firmware(fw_entry) releasing
the firmware image and any related resource.
High level behavior (driver code):
--
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 11/16] f2fs: add inode operations for special inodes
On Wed, Oct 17, 2012 at 12:50:11PM +, Arnd Bergmann wrote: > On Tuesday 16 October 2012, Jaegeuk Kim wrote: > > > IIRC, fs2fs uses 4k inodes, so IMO per-inode xattr tress with > > > internal storage before spilling to an external block is probably > > > the best approach to take... > > > > Yes, indeed this is the best approach to f2fs's xattr. > > Apart from giving fs hints, it is worth enough to optimize later. > > I've thought a bit more about how this could be represented efficiently > in 4KB nodes. This would require a significant change of the way you > represent inodes, but can improve a number of things at the same time. > > The idea is to replace the fixed area in the inode that contains block > pointers with an extensible TLV (type/length/value) list that can contain > multiple variable-length fields, like this. You've just re-invented inode forks... ;) > All TLVs together with the > fixed-length inode data can fill a 4KB block. > > The obvious types would be: > > * Direct file contents if the file is less than a block > * List of block pointers, as before, minimum 1, maximum until the end > of the block > * List of indirect pointers, now also a variable length, similar to the > list of block pointers > * List of double-indirect block pointers > * direct xattr: zero-terminated attribute name followed by contents > * indirect xattr: zero-terminated attribute name followed by up to > 16 block pointers to store a maximum of 64KB sized xattrs > > This could be extended later to cover additional types, e.g. a list > of erase block pointers, triple-indirect blocks or extents. An inode fork doesn't care about the data in it - it's just an independent block mapping index. i.e. inline, direct, indirect, double indirect. The data in the fork is managed externally to the format of the fork. e.g. XFS has two forks - one for storing data (file data, directory contents, etc) and the other for storing attributes. The main issue with supporting an arbitrary number of forks is space management of the inode literal area. e.g. one fork is in inline format (e.g. direct file contents) and then we add an attribute. The attribute won't fit inline, nor will an extent form fork header, so the inline data fork has to be converted to extent format before the xattr can be added. Now scale that problem up to an arbitrary number of forks > As a variation of this, it would also be nice to turn around the order > in which the pointers are walked, to optimize for space and for growing > files, rather than for reading the beginning of a file. With this, you > can represent a 9 KB file using a list of two block pointers, and 1KB > of direct data, all in the inode. When the user adds another byte, you > only need to rewrite the inode. Similarly, a 5 MB file would have a > single indirect node (covering block pointers for 4 MB), plus 256 > separate block pointers (covering the last megabyte), and a 5 GB file > can be represented using 1 double-indirect node and 256 indirect nodes, > and each of them can still be followed by direct "tail" data and > extended attributes. I'm not sure that the resultant code complexity is worth saving an extra block here and there. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build warning in Linus' tree
Hi Mauro,
After merging the origin tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c: In function 'dvb_usb_ctrl_feed':
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:291:12: warning: 'ret' may be used
uninitialized in this function [-Wuninitialized]
Which points out some badly formatted and blocked code ...
Probably introduced by commit 62a5f449cab5 ("[media] dvb_usb_v2: refactor
dvb_usb_ctrl_feed() logic").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpYSZuCKAtlN.pgp
Description: PGP signature
Re: [GIT PULL v2] extcon fixes for Linux 3.7
On Tue, Oct 23, 2012 at 05:18:20PM +0900, MyungJoo Ham wrote: > > > Hello Greg, > > Please pull: > The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: > > Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) > > are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/mzx/extcon.git bugfixes > git://git.kernel.org/pub/scm/linux/kernel/git/mzx/extcon.git > tags/fixes-for-3.7 Why two things to pull from? I just pulled from the last one, that worked properly for me, was signed, and showed the same diffstat. I've pulled and pushed it out now. thanks, greg k-h -- 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/5] Thermal: do bind operation after thermal zone or cooling device register returns.
On 24 October 2012 06:13, Francesco Lavra wrote:
> Hi,
> On 10/23/2012 10:23 AM, Hongbo Zhang wrote:
>> Hi Francesco,
>> I found out more points about this issue.
>>
>> [1]
>> cdev should be ready when get_max_state callback be called, otherwise
>> parameter cdev is useless, imagine there may be cases that
>> get_max_state call back is shared by more than one cooling devices of
>> same kind, like this:
>> common_get_max_state(*cdev, *state)
>> {
>> if (cdev == cdev1) *state = 3;
>> else if (cdev == cdev) *state = 5;
>> else
>> }
>>
>> [2]
>> In my cpufreq cooling case(in fact cdev is not used to calculate
>> max_state), the cooling_cpufreq_list should be ready when
>> get_max_state call back is called. In this patch I defer the binding
>> when registration finished, but this is not perfect now, see this
>> routine in cpufreq_cooling_register:
>>
>> thermal_cooling_device_register;
>> at this time: thermal_bind_work -> get_max_state -> get NULL
>> cooling_cpufreq_list
>> and then: list_add_tail(_dev->node, _cpufreq_list)
>> This is due to we cannot know exactly when the bind work is executed.
>> (and this can be fixed by moving mutex_lock(_cpufreq_lock)
>> aheadof thermal_cooling_device_register and other corresponding
>> modifications, but I found another way as below)
>>
>> [3]
>> Root cause of this problem is calling get_max_state in register -> bind
>> routine.
>> Better solution is to add another parameter in cooling device register
>> function, also add a max_state member in struct cdev, like:
>> thermal_cooling_device_register(char *type, void *devdata, const
>> struct thermal_cooling_device_ops *ops, unsigned long max_state)
>> and then in the bind function:
>> if(cdev->max_state)
>> max_state = cdev->max_state;
>> else
>> cdev->get_max_state(cdev, _state)
>>
>> It is common sense that the cooling driver should know its cooling
>> max_state(ability) before registration, and it can be offered when
>> register.
>> I think this way doesn't change both thermal and cooling layer much,
>> it is more clear.
>> I will update this patch soon.
>
> I still believe the thermal layer doesn't need any change to work around
> this problem, and I still believe that when a cooling device is being
> registered, all of its ops should be fully functional.
> The problem with the cpufreq cooling device driver is that its callbacks
> use the internal list of devices to retrieve the struct
> cpufreq_cooling_device instance corresponding to a given struct
> thermal_cooling_device. This is not necessary, because the struct
> thermal_cooling_device has a private data pointer (devdata) which in
> this case is exactly a reference to the struct cpufreq_cooling_device
> instance the callbacks are looking for. In fact, I think the
> cooling_cpufreq_list is not necessary at all, and should be removed from
> the cpufreq cooling driver.
> So the 3 callbacks, instead of iterating through the device list, should
> have something like:
> struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
> That would do the trick.
Hi Francesco,
When I found out this issue, I was hesitating to select the best
solution among several ideas.
It is clear now after talk with you, I will send patch for cpufreq
cooling layer.
Thank you.
>
> --
> Francesco
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 04/10] sched: Introduce priority-based task migration filter
在 2012-10-09二的 17:40 +0100，Morten Rasmussen写道：
> On Thu, Oct 04, 2012 at 07:27:00AM +0100, Viresh Kumar wrote:
> > On 22 September 2012 00:02, wrote:
> >
> > > +config SCHED_HMP_PRIO_FILTER
> > > + bool "(EXPERIMENTAL) Filter HMP migrations by task priority"
> > > + depends on SCHED_HMP
> >
> > Should it depend on EXPERIMENTAL?
> >
> > > + help
> > > + Enables task priority based HMP migration filter. Any task with
> > > + a NICE value above the threshold will always be on low-power
> > > cpus
> > > + with less compute capacity.
> > > +
> > > +config SCHED_HMP_PRIO_FILTER_VAL
> > > + int "NICE priority threshold"
> > > + default 5
> > > + depends on SCHED_HMP_PRIO_FILTER
> > > +
> > > config HAVE_ARM_SCU
> > > bool
> > > help
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index 490f1f0..8f0f3b9 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -3129,9 +3129,12 @@ static int __init hmp_cpu_mask_setup(void)
> > > * hmp_down_threshold: max. load allowed for tasks migrating to a slower
> > > cpu
> > > * The default values (512, 256) offer good responsiveness, but may need
> > > * tweaking suit particular needs.
> > > + *
> > > + * hmp_up_prio: Only up migrate task with high priority ( > > */
> > > unsigned int hmp_up_threshold = 512;
> > > unsigned int hmp_down_threshold = 256;
hmp_*_threshold maybe sysctl_hmp_*_threshold,
and appear at /proc/sys/kernel,
so, can be adjusted to be rational.
> > > +unsigned int hmp_up_prio =
> > > NICE_TO_PRIO(CONFIG_SCHED_HMP_PRIO_FILTER_VAL);
> > >
> > > static unsigned int hmp_up_migration(int cpu, struct sched_entity *se);
> > > static unsigned int hmp_down_migration(int cpu, struct sched_entity *se);
> > > @@ -5491,6 +5494,12 @@ static unsigned int hmp_up_migration(int cpu,
> > > struct sched_entity *se)
> > > if (hmp_cpu_is_fastest(cpu))
> > > return 0;
> > >
> > > +#ifdef CONFIG_SCHED_HMP_PRIO_FILTER
> > > + /* Filter by task priority */
> > > + if (p->prio >= hmp_up_prio)
> > > + return 0;
> > > +#endif
> > > +
> > > if (cpumask_intersects(_faster_domain(cpu)->cpus,
> > > tsk_cpus_allowed(p))
> > > && se->avg.load_avg_ratio > hmp_up_threshold) {
> > > @@ -5507,6 +5516,12 @@ static unsigned int hmp_down_migration(int cpu,
> > > struct sched_entity *se)
> > > if (hmp_cpu_is_slowest(cpu))
> > > return 0;
> > >
> > > +#ifdef CONFIG_SCHED_HMP_PRIO_FILTER
> > > + /* Filter by task priority */
> > > + if (p->prio >= hmp_up_prio)
> > > + return 1;
> > > +#endif
> >
> > Even if below cpumask_intersects() fails?
> >
>
> No. Good catch :)
>
> > > if (cpumask_intersects(_slower_domain(cpu)->cpus,
> > > tsk_cpus_allowed(p))
> > > && se->avg.load_avg_ratio < hmp_down_threshold) {
> >
> > --
> > viresh
> >
>
> Thanks,
> Morten
>
> --
> 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/
--
liguanglig.f...@cn.fujitsu.com
FNST linux kernel team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the tty tree
Hi Greg,
After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/staging/dgrp/dgrp_net_ops.c: In function 'dgrp_input':
drivers/staging/dgrp/dgrp_net_ops.c:216:27: error: 'struct tty_struct' has no
member named 'real_raw'
drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
member named 'read_cnt'
drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
member named 'read_cnt'
drivers/staging/dgrp/dgrp_net_ops.c:261:30: error: 'struct tty_struct' has no
member named 'real_raw'
drivers/staging/dgrp/dgrp_net_ops.c:276:28: error: 'struct tty_struct' has no
member named 'real_raw'
Caused by commits 53c5ee2cfb4d ("TTY: move ldisc data from tty_struct:
simple members") and ba2e68ac6157 ("TTY: move ldisc data from tty_struct:
read_* and echo_* and canon_* stuff") interacting with commit
0b52b7497271 ("staging: Add dgrp driver for Digi Realport devices") now
in Linus' tree.
I disabled building of the dgrp driver for now using this merge fix patch:
From: Stephen Rothwell
Date: Wed, 24 Oct 2012 13:25:29 +1100
Subject: [PATCH] staging: disable dgrp driver since it is broken by tty
changes
drivers/staging/dgrp/dgrp_net_ops.c: In function 'dgrp_input':
drivers/staging/dgrp/dgrp_net_ops.c:216:27: error: 'struct tty_struct' has no
member named 'real_raw'
drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
member named 'read_cnt'
drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
member named 'read_cnt'
drivers/staging/dgrp/dgrp_net_ops.c:261:30: error: 'struct tty_struct' has no
member named 'real_raw'
drivers/staging/dgrp/dgrp_net_ops.c:276:28: error: 'struct tty_struct' has no
member named 'real_raw'
Signed-off-by: Stephen Rothwell
---
drivers/staging/dgrp/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/dgrp/Kconfig b/drivers/staging/dgrp/Kconfig
index 39f4bb6..7d378c2 100644
--- a/drivers/staging/dgrp/Kconfig
+++ b/drivers/staging/dgrp/Kconfig
@@ -2,6 +2,7 @@ config DGRP
tristate "Digi Realport driver"
default n
depends on SYSFS
+ depends on BROKEN
---help---
Support for Digi Realport devices. These devices allow you to
access remote serial ports as if they are local tty devices. This
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgppps6H5SaZZ.pgp
Description: PGP signature
Re: [PATCH v2 2/4] zynq: move static peripheral mappings
On 2012-10-23 15:53 -0500, Josh Cartwright wrote:
> On Tue, Oct 23, 2012 at 03:09:23PM -0500, Rob Herring wrote:
> > On 10/23/2012 09:50 AM, Arnd Bergmann wrote:
> > > On Monday 22 October 2012, Josh Cartwright wrote:
> > >> -#define SCU_PERIPH_PHYS 0xF8F0
> > >> -#define SCU_PERIPH_VIRT SCU_PERIPH_PHYS
> > >> +#define SCU_PERIPH_PHYS 0xF8F0
> > >> +#define SCU_PERIPH_SIZE SZ_8K
> > >> +#define SCU_PERIPH_VIRT (PL310_L2CC_VIRT - SCU_PERIPH_SIZE)
> > >
> > > And your patch 3 already obsoletes this mapping.
> >
> > Actually, it's probably still needed. The smp platform code typically
> > reads the number of cores from the SCU and the mapping has to be in
> > place before ioremap is up. I don't think there is an architected way to
> > get the number of cores, but it would be nice to avoid this early SCU
> > access. We could also mandate getting the core count from DT instead.
> >
> > Also, the physical address can be read with this on A9's:
> >
> > asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
>
> For the sake of the zynq cleanups, I think it may still make sense to
> remove the SCU peripheral mappings for now. By the time we're ready to
> push in SMP support for zynq, maybe we can tackle the problem of how to
> solve the SCU mapping problem generically.
Then the static mapping can be removed if and when the we "solve the SCU
mapping problem generically". There's no point in removing it until
then since it doesn't cause any actual problems, does it?
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] zynq: move static peripheral mappings
On 2012-10-23 11:26 -0500, Josh Cartwright wrote: > On Tue, Oct 23, 2012 at 02:50:11PM +, Arnd Bergmann wrote: > > On Monday 22 October 2012, Josh Cartwright wrote: > > > Shifting them up into the vmalloc region prevents the following warning, > > > when booting a zynq qemu target with more than 512mb of RAM: > > > > > > BUG: mapping for 0xe000 at 0xe000 out of vmalloc space > > > > > > In addition, it allows for reuse of these mappings when the proper > > > drivers issue requests via ioremap(). > > > > > > Signed-off-by: Josh Cartwright > > > > This looks like a bug fix that should be backported to older kernels, > > so it would be good to add 'Cc: sta...@vger.kernel.org' below your > > Signed-off-by. > > Will-do, thanks. Just FYI, I sent a patch to fix the same bug a while back https://patchwork.kernel.org/patch/1156361/ together with other patches to fix early printk on the ZC702 serial console. Admittedly, I dropped the ball on these as other issues came up so I was away from the Zynq for a while. However, I'm now getting back on the Zynq and have a bunch of patches to make it all work on the ZC702 board. I've respun the ZC702 early boot fixes against newer git but they're obviously going to conflict with this series. Should I resend them anyway? > > > -#define TTC0_PHYS0xF8001000 > > > -#define TTC0_VIRTTTC0_PHYS > > > +#define TTC0_PHYS0xF8001000 > > > +#define TTC0_SIZESZ_4K > > > +#define TTC0_VIRT(UART0_VIRT - TTC0_SIZE) > > > > It's quite likely that this does not have to be a fixed mapping > > any more. Just have a look at how drivers/clocksource/dw_apb_timer_of.c > > calls of_iomap() to get the address. > > Yes, this is already on my list of plans. The in-tree TTC driver > unfortunately doesn't yet support device tree bindings. Are you > comfortable waiting on the DT-ification of the TTC in a follow-up > patchset? I also have a DT binding for the TTC driver, I can send that. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOPS after deleting file on ext4 filesystem
Hi folks, I just saw an ext4 oops on one of my machines after a couple months of uptime, on Linux 3.5.2. I doubt I will be able to reproduce the problem easily so I'm just posting this in case anyone can tell what's going on. Going by the timing, and the call trace, it is presumably related to the fact that I had rm'd a ~12G file shortly before the last log entry. The filesystem is aged somewhat and close to full (hence why I was deleting the file in the first place). However, I'm not certain of the *exact* timeline because I didn't notice that the system had crashed until the next day. In case it matters, fs recovery after resetting the box resulted in hundreds of messages like: EXT4-fs (md127): ext4_orphan_cleanup: deleting unreferenced inode 12058658 I took a photo of the oops text that was on screen and posted it here: http://i.imgur.com/7DfIP.jpg For convenience (and the benefit of list archives), I've transcribed the oops, but I could have easily fat-fingered something so the only the photo is authoritative. BUG: unable to handle kernel NULL pointer dereference at 0028 IP: [] ext4_ext_remove_space+0x725/0x9db [ext4] PGD 1043f067 PUD 1078f067 PMD 0 Oops: [#1] PREEMPT CPU 0 Modules linked in: nls_iso8859_1 nls_cp437 vfat fat usb_storage nls_utf8 isofs it87 hwmon_vid sha1_generic hmac aes_generic cbc cts crypto_blkcipher cryptomgr aead nfs nfsd exportfs lockd bridge stp ipv6 llc iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables ext2 snd_pcm_oss snd_mixer_oss snd_emu10k1_synth snd_emux_synth snd_seq_midi_emul snd_seq_virmidi snd_seq_midi_event snd_seq rpcsec_gss_krb5 auth_rpcgss sunrpc tun raid456 async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx sg firewire_sbp2 loop snd_emu10k1 sr_mod snd_hwdep snd_util_mem snd_ac97_codec ac9_bus snd_rawmidi snd_seq_device snd_pcm snd_page_alloc snd_timer snd ftdi_sio cdrom epic100 firewire_ohci emu10k1_gp firewire_core gameport crc_itu_t soundcore forcedeth k8temp usbserial mii powernow_k8 floppy pata_amd mperf evdev i2c_nforce2 ext4 crc16 jbd2 crypto_hash crypto_algapi crypto mbcache raid1 md_mod Pid: 13628, comm: rm Not tainted 3.5.2 #107 ASUSTek Computer Inc. K8N-E-Deluxe/'K8N-E-Deluxe' RIP: 0010:[] [] ext4_ext_remove_space+0x725/0x9db [ext4] RSP: 0018:8800105cfca8 EFLAGS: 00010246 RAX: RBX: 88006d5db5f0 RCX: 0002 RDX: 0001 RSI: 0001 RDI: 073f313e RBP: 8800105cfd88 R08: 073f313e R09: 03e8 R10: 1600 R11: 88007b930180 R12: 8800588e4d68 R13: 88004d002000 R14: 88006d5db5c0 R15: FS: 7f1e400b8700() GS:81623000() knlGS:f757a6c0 CS: 0010 DS: ES: CR0: 8005003b CR2: 0028 CR3: 7c6ec000 CR4: 07f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process rm (pid: 13628, threadinfo 8800105ce00, task 8800718e7230) Stack: 88000133bde0 8800588e4d68 8800219d2300 880017ebf3d8 8800105cfd50 0003 04549000 8800fff5 105cfd50 88006d5db648 8800588e4cc8 080080006a88 Call Trace: [] ext4_ext_truncate+0xcd/0x173 [ext4] [] ? ext4_mark_inode_dirty+0x13e/0x168 [ext4] [] ext4_truncate+0x46/0x51 [ext4] [] ext4_evict_inode+0x276/0x363 [ext4] [] ? ext4_da_writepages+0x423/0x423 [ext4] [] evict+0xb6/0x182 [] iput+0x1fb/0x203 [] do_unlinkat+0x10b/0x161 [] sys_unlinkat+0x24/0x26 [] system_call_fastpath+0x1a/0x1f Code: e1 ff ff 48 63 5d bc 48 6b db 30 48 03 5d b0 e9 f1 00 00 00 48 63 55 bc 48 6b da 30 48 03 5d b0 48 83 7b 20 00 75 0c 48 8b 43 28 <48> 8b 40 28 48 89 43 20 48 8b 43 18 48 85 c0 75 1f 48 8b 43 20 RIP [] ext4_ext_remove_space+0x725/0x9db [ext4] RSP CR2: 0028 Thanks, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] regmap for for v3.7
On Tue, Oct 23, 2012 at 11:58 AM, Mark Brown wrote: > > Hrm, appears nobody else ever actually checks these things... it's a > new subkey on my existing key, I've pushed it up to subkeys.pgp.net and > also attach a copy. Sorry about that. NP. Looks good now, Linus -- 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 4:56 AM, Al Viro wrote: > > How about git commit --allow-empty, with > "belated ACK for Don't bother. It's not that important, and it's just distracting. It's not like this is vital information. If you pushed it out without the ack, it's out without the ack. Big deal. Linus -- 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 1/2] Replace if statement with WARN_ON_ONCE() in cmci_rediscover().
Hi Luck, Borislav, OK, since you all think it is not necessary, I think I will drop patch1. And thanks for your comments. :) So, how about patch2 ? If you need more detail, please tell me. Thanks. :) On 10/24/2012 12:16 AM, Luck, Tony wrote: First of all, I do think I was answering your question. As I said before, if an online cpu == dying here, there must be something wrong. Am I right here ? Yes - but there is a fuzzy line over where it is good to check for "something wrong" or whether to trust that the caller of the function knew what they were doing. For example we trust that "dying" is a valid cpu number. If we were super-paranoid that someone might change the code and call us with a bad argument, we might add: BUG_ON(dying< 0 || dying>= MAX_NR_CPUS); This would certainly help debug the case if someone did make a bogus change ... but I think it is clear that this test is way past the fuzzy line and into pointless. Back to the case in question: do we think there is a credible case where the "dying" cpu can show up in our "for_each_cpu_online()" loop? The original author of the code was worried enough to make a test, but thought that the appropriate action was to silently skip it. You want to add a WARN_ON, which will cause users who read the console logs to worry, but that most users will never see. -Tony -- 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: [ANNOUNCE] 3.6.3-rt6
On Tue, Oct 23, 2012 at 5:06 PM, Thomas Gleixner wrote: > Dear RT Folks, > > I'm pleased to announce the 3.6.3-rt6 release. rt6 is just an update > to 3.6.3. The not announced 3.6.2-rt5 is an intermediate release with > a single change. > > Changes since 3.6.2-rt4: > > * Make the early printk changes work (hopefully) everywhere > > The new patch queue also contains a non code change (according to > Pauls) which adds a missing subject line to a powerpc patch. The rt5 and rt6 changes are now present in the 3.6-rt-patches repo. Given the above, there is currently nothing for me to queue on a separate "-fixes" branch against rt6. The master branch works as-is. http://git.kernel.org/?p=linux/kernel/git/paulg/3.6-rt-patches.git;a=summary Paul. -- > > The delta patch against 3.6.2-rt4 is appended below and can be found > here: > > > http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/incr/patch-3.6.2-rt4-rt5.patch.xz > > The RT patch against 3.6.3 can be found here: > > > http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.3-rt6.patch.xz > > The split quilt queue is available at: > > > http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patches-3.6.3-rt6.tar.xz > > Enjoy, > > tglx > > --> -- 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Jeff King wrote: > On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote: > > > The resulting notes are stored in a separate > > > revision-controlled branch > > > > Which branch(es) is/are that ? What are the semantics of that? [...] Nice feature. Can a later commit be eventually be made to reference some set of notes added so far, so they become part of the whole history signed by the HEAD SHA1? hence pulled/pushed automatically as well. Otherwise do you not end up with a forever growing separate tree of notes that loses some of the properties of being behind the head SHA1 (and perhaps less scalable in manageability)? Also that way notes are separate only temporarily. As for automating the inclusion of notes in the flow, can that be conditional on some pattern in the note, so that e.g. the Acked-by's get included and folded in automatically, whereas others do not, according to settings? -Marc -- 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 04:02:49AM +0300, Linus Torvalds wrote: > On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner wrote: > >> > >> It is spelled: > >> > >> git notes add -m SHA1 > > > > Cool! > > Don't use them for anything global. > > Use them for local codeflow, but don't expect them to be distributed. > It's a separate "flow", and while it *can* be distributed, it's not > going to be for the kernel, for example. So no, don't start using this > to ack things, because the acks *will* get lost. How about git commit --allow-empty, with "belated ACK for Acked-by: <...> " as commit message? I mean, that ought to work and propagate sanely, but I'm really not sure if that's something in a good taste and should be allowed as a common practice... -- 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 for-3.7] mm, numa: avoid setting zone_reclaim_mode unless a node is sufficiently distant
Commit 957f822a0ab9 ("mm, numa: reclaim from all nodes within reclaim
distance") caused zone_reclaim_mode to be set for all systems where two
nodes are within RECLAIM_DISTANCE of each other. This is the opposite of
what we actually want: zone_reclaim_mode should be set if two nodes are
sufficiently distant.
Reported-by: Julian Wollrath
Signed-off-by: David Rientjes
---
mm/page_alloc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1809,10 +1809,10 @@ static void __paginginit init_zone_allows_reclaim(int
nid)
int i;
for_each_online_node(i)
- if (node_distance(nid, i) <= RECLAIM_DISTANCE) {
+ if (node_distance(nid, i) <= RECLAIM_DISTANCE)
node_set(i, NODE_DATA(nid)->reclaim_nodes);
+ else
zone_reclaim_mode = 1;
- }
}
#else /* CONFIG_NUMA */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] xen/pvh: bootup and setup related changes.
On Tue, 23 Oct 2012 14:07:06 +0100
Stefano Stabellini wrote:
> On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini wrote:
> > > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > From: Mukesh Rathor
> > > >
> > > > for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn;
> > > > pfn++) { unsigned long mfn = pfn_to_mfn(pfn);
> > > > @@ -100,6 +104,7 @@ static unsigned long __init
> > > > xen_do_chunk(unsigned long start, .domid= DOMID_SELF
> > > > };
> > > > unsigned long len = 0;
> > > > + int xlated_phys =
> > > > xen_feature(XENFEAT_auto_translated_physmap); unsigned long pfn;
> > > > int ret;
> > > >
> > > > @@ -113,7 +118,7 @@ static unsigned long __init
> > > > xen_do_chunk(unsigned long start, continue;
> > > > frame = mfn;
> > > > } else {
> > > > - if (mfn != INVALID_P2M_ENTRY)
> > > > + if (!xlated_phys && mfn !=
> > > > INVALID_P2M_ENTRY) continue;
> > > > frame = pfn;
> > > > }
> > >
> > > Shouldn't we add a "!xlated_phys &&" to the other case as well?
> >
> > No. That is handled in xen_pvh_identity_map_chunk which
> > just does a xen_set_clr_mmio_pvh_pte call for the "released"
> > pages. But that is a bit of ... well, extra logic. I think
> > if we did this it would work and look much nicer:
>
> Yes, I think that this version looks better
But doesn't boot:
(XEN) vmx_hybrid.c:710:d0 Dom:0 EPT violation 0x181 (r--/---), gpa
0x00bf421e1c, mfn 0x, type 4.
(XEN) p2m-ept.c:642:d0 Walking EPT tables for domain 0 gfn bf421
(XEN) p2m-ept.c:648:d0 gfn exceeds max_mapped_pfn 4b062
(XEN) vmx_hybrid.c:717:d0 --- GLA 0xff477e1c
I'll have to debug it, or we can go back to the prev version, which
I don't think is that un-pretty :).
Mukesh
--
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 REGRESSION FIX] dw_dmac: make driver's endianness configurable
Hi Andrew, On 10/24/2012 7:12 AM, Andrew Morton wrote: > On Sun, 14 Oct 2012 15:54:13 +0800 > Hein Tibosch wrote: > >> The dw_dmac was originally developed for avr32 to be used with the Synopsys >> DesignWare AHB DMA controller. Starting from 2.6.38, access to the device's >> i/o >> memory was done with the little-endian readl/writel functions(1) >> >> This broke the driver for the avr32 platform, because it needs big (native) >> endian accessors. >> This patch makes the endianness configurable using 'DW_DMAC_BIG_ENDIAN_IO', >> which will default be true for AVR32 > Do we think this bug should be fixed in earlier kernel versions? > > If so, the patch might need to be tweaked for 3.6 and earlier, which > don't have the dma_read_byaddr() definition. The 'bug' only affected avr32 (AP700x) users. I think there won't be much demand for it. Beside that, there were more breakages after 2.6.38, which have only recently been fixed in 3.7-rc1 These patches should then be back-ported as well: http://www.spinics.net/lists/linux-mmc/msg16104.html http://www.gossamer-threads.com/lists/linux/kernel/1603537 Thanks, Hein -- 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] mm: readahead: remove redundant ra_pages in file_ra_state
Hi Chen,
On Wed, Oct 24, 2012 at 9:02 AM, Ni zhan Chen wrote:
> On 10/23/2012 09:41 PM, YingHang Zhu wrote:
>>
>> Sorry for the annoying, I forgot ccs in the previous mail.
>> Thanks,
>> Ying Zhu
>> Hi Chen,
>>
>> On Tue, Oct 23, 2012 at 9:21 PM, Ni zhan Chen
>> wrote:
>>>
>>> On 10/23/2012 08:46 PM, Ying Zhu wrote:
Hi,
Recently we ran into the bug that an opened file's ra_pages does not
synchronize with it's backing device's when the latter is changed
with blockdev --setra, the application needs to reopen the file
to know the change, which is inappropriate under our circumstances.
>>>
>>>
>>> Could you tell me in which function do this synchronize stuff?
>>
>> With this patch we use bdi.ra_pages directly, so change bdi.ra_pages also
>> change an opened file's ra_pages.
>>>
>>>
This bug is also mentioned in scst (generic SCSI target subsystem for
Linux)'s
README file.
This patch tries to unify the ra_pages in struct file_ra_state
and struct backing_dev_info. Basically current readahead algorithm
will ramp file_ra_state.ra_pages up to bdi.ra_pages once it detects the
>>>
>>>
>>> You mean ondemand readahead algorithm will do this? I don't think so.
>>> file_ra_state_init only called in btrfs path, correct?
>>
>> No, it's also called in do_dentry_open.
>>>
>>>
read mode is sequential. Then all files sharing the same backing device
have the same max value bdi.ra_pages set in file_ra_state.
>>>
>>>
>>> why remove file_ra_state? If one file is read sequential and another file
>>> is
>>> read ramdom, how can use the global bdi.ra_pages to indicate the max
>>> readahead window of each file?
>>
>> This patch does not remove file_ra_state, an file's readahead window
>> is determined
>> by it's backing device.
>
>
> As Dave said, backing device readahead window doesn't tend to change
> dynamically, but file readahead window does, it will change when sequential
> read, random read, thrash, interleaved read and so on occur.
>
I agree about what you and Dave said totally and the point here is
not about how readahead
algorithm does. It's about those file systems using a abstract bdi
instead of the actual
devices, thus the bdi.ra_pages does not really reflect the backing
storage's read IO bandwidth.
AFAIK btrfs also has a abstract bdi to manage the many backing
devices, so I think btrfs also
has this problem. As for a further comment, btrfs may spread a file's
contents across the managed
backing devices, so maybe offset (0, x) and (x+1, y) land on different
disks and have different readahead
abilities, in this case the file's max readahead pages should change
accordingly.
Perhaps in reality we seldom meet this heterogenous stroage architecture.
Thanks,
Ying Zhu
>>>
Applying this means the flags POSIX_FADV_NORMAL and
POSIX_FADV_SEQUENTIAL
in fadivse will only set file reading mode without signifying the
max readahead size of the file. The current apporach adds no additional
overhead in read IO path, IMHO is the simplest solution.
Any comments are welcome, thanks in advance.
>>>
>>>
>>> Could you show me how you test this patch?
>>
>> This patch brings no perfmance gain, just fixs some functional bugs.
>> By reading a 500MB file, the default max readahead size of the
>> backing device was 128KB, after applying this patch, the read file's
>> max ra_pages
>> changed when I tuned the device's read ahead size with blockdev.
>>>
>>>
Thanks,
Ying Zhu
Signed-off-by: Ying Zhu
---
include/linux/fs.h |1 -
mm/fadvise.c |2 --
mm/filemap.c | 17 +++--
mm/readahead.c |8
4 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 17fd887..36303a5 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -991,7 +991,6 @@ struct file_ra_state {
unsigned int async_size;/* do asynchronous readahead
when
there are only # of pages
ahead
*/
- unsigned int ra_pages; /* Maximum readahead window */
unsigned int mmap_miss; /* Cache miss stat for mmap
accesses */
loff_t prev_pos;/* Cache last read() position
*/
};
diff --git a/mm/fadvise.c b/mm/fadvise.c
index 469491e..75e2378 100644
--- a/mm/fadvise.c
+++ b/mm/fadvise.c
@@ -76,7 +76,6 @@ SYSCALL_DEFINE(fadvise64_64)(int fd, loff_t offset,
loff_t len, int advice)
switch (advice) {
case POSIX_FADV_NORMAL:
- file->f_ra.ra_pages = bdi->ra_pages;
spin_lock(>f_lock);
file->f_mode &= ~FMODE_RANDOM;
spin_unlock(>f_lock);
@@ -87,7 +86,6 @@
Re: [next:akpm 155/157] drivers/char/random.c:827:3: warning: format '%zd' expects argument of type 'signed size_t', but argument 7 has type 'size_t'
[add CC to mn10300/cris arch lists]
On Wed, Oct 24, 2012 at 08:56:12AM +0800, Fengguang Wu wrote:
> On Tue, Oct 23, 2012 at 02:53:58PM -0700, Andrew Morton wrote:
> > On Tue, 23 Oct 2012 18:16:58 +0800
> > Fengguang Wu wrote:
> >
> > > Hi Jiri,
> > >
> > > FYI, there are new compile warnings show up in
> > >
> > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > > akpm
> > > head: dbfe0815b4af06cc4ca6cd12b17e2d13ffaaf991
> > > commit: 0b1f5a647784c406ee33a6ddd3bb6382a2278111 [155/157] random: fix
> > > debug format strings
> > > config: mn10300-asb2364_defconfig # make ARCH=mn10300 asb2364_defconfig
> > >
> > > All warnings:
> > >
> > > drivers/char/random.c: In function 'xfer_secondary_pool':
> > > drivers/char/random.c:827:3: warning: format '%zd' expects argument of
> > > type 'signed size_t', but argument 7 has type 'size_t' [-Wformat]
> > > drivers/char/random.c: In function 'account':
> > > drivers/char/random.c:859:2: warning: format '%zd' expects argument of
> > > type 'signed size_t', but argument 5 has type 'size_t' [-Wformat]
> > > drivers/char/random.c:881:2: warning: format '%zd' expects argument of
> > > type 'signed size_t', but argument 5 has type 'size_t' [-Wformat]
> > > drivers/char/random.c: In function 'random_read':
> > > drivers/char/random.c:1141:3: warning: format '%zd' expects argument of
> > > type 'signed size_t', but argument 5 has type 'int' [-Wformat]
> > > drivers/char/random.c:1145:3: warning: format '%zd' expects argument of
> > > type 'signed size_t', but argument 5 has type 'int' [-Wformat]
> > > drivers/char/random.c:1145:3: warning: format '%zd' expects argument of
> > > type 'signed size_t', but argument 6 has type 'size_t' [-Wformat]
> > > drivers/char/random.c: In function 'write_pool':
> > > drivers/char/random.c:1213:11: warning: comparison of distinct pointer
> > > types lacks a cast [enabled by default]
> > >
> >
> > Ah, I get it. %zd vs %zu. This?
>
> With the patch, there are still errors (below). I think the reason of the
> warnings is, (size_t * 8) makes it an (int) because the constant 8 is (int).
Sorry (size_t * 8) becomes (unsigned int) because (size_t) is (unsigned int).
And the problem is specific to mn10300/cris: (size_t * 8) is no longer (size_t),
which triggers the gcc warnings discussed here.
Thanks,
Fengguang
> CC drivers/char/random.o
> /c/wfg/linux/drivers/char/random.c: In function 'xfer_secondary_pool':
> /c/wfg/linux/drivers/char/random.c:827:3: warning: format '%zu' expects
> argument of type 'size_t', but argument 7 has type 'unsigned int' [-Wformat]
> /c/wfg/linux/drivers/char/random.c: In function 'account':
> /c/wfg/linux/drivers/char/random.c:859:2: warning: format '%zu' expects
> argument of type 'size_t', but argument 5 has type 'unsigned int' [-Wformat]
> /c/wfg/linux/drivers/char/random.c:881:2: warning: format '%zu' expects
> argument of type 'size_t', but argument 5 has type 'unsigned int' [-Wformat]
> /c/wfg/linux/drivers/char/random.c: In function 'random_read':
> /c/wfg/linux/drivers/char/random.c:1141:3: warning: format '%zu' expects
> argument of type 'size_t', but argument 5 has type 'int' [-Wformat]
> /c/wfg/linux/drivers/char/random.c:1145:3: warning: format '%zu' expects
> argument of type 'size_t', but argument 5 has type 'int' [-Wformat]
> /c/wfg/linux/drivers/char/random.c:1145:3: warning: format '%zu' expects
> argument of type 'size_t', but argument 6 has type 'unsigned int' [-Wformat]
>
> And that behavior is depending on arch. Changing %zu to %u will make
> mn10300/parisc/i386 etc. archs compile cleanly, however x86_64 goes
> wrong like this:
>
> /c/wfg/linux/drivers/char/random.c:827:3: warning: format ‘%u’ expects
> argument of type ‘unsigned int’, but argument 7 has type ‘size_t’ [-Wformat]
>
> So in x86_64, (size_t * 8) is still of type size_t.
>
> Thanks,
> Fengguang
> ---
> >
> > From: Andrew Morton
> > Subject: random-fix-debug-format-strings-fix
> >
> > s/%zd/%zu/ for unsigned `size_t'
> >
> > Cc: Jiri Kosina
> > Cc: Theodore Ts'o
> > Signed-off-by: Andrew Morton
> > ---
> >
> > drivers/char/random.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff -puN drivers/char/random.c~random-fix-debug-format-strings-fix
> > drivers/char/random.c
> > --- a/drivers/char/random.c~random-fix-debug-format-strings-fix
> > +++ a/drivers/char/random.c
> > @@ -825,7 +825,7 @@ static void xfer_secondary_pool(struct e
> > bytes = min_t(int, bytes, sizeof(tmp));
> >
> > DEBUG_ENT("going to reseed %s with %d bits "
> > - "(%zd of %d requested)\n",
> > + "(%zu of %d requested)\n",
> > r->name, bytes * 8, nbytes * 8, r->entropy_count);
> >
> > bytes = extract_entropy(r->pull, tmp, bytes,
> > @@ -856,7 +856,7 @@ static size_t account(struct entropy_sto
> > spin_lock_irqsave(>lock, flags);
> >
> >
Re: [PATCH RFC] mm/swap: automatic tuning for swapin readahead
On Tue, Oct 23, 2012 at 09:41:00AM -0400, Rik van Riel wrote: > On 10/23/2012 01:51 AM, Shaohua Li wrote: > > >I have no strong point against the global state method. But I'd agree making > >the > >heuristic simple is preferred currently. I'm happy about the patch if the > >'+1' > >is removed. > > Without the +1, how will you figure out when to re-enable readahead? Below code in swapin_nr_pages can recover it. + if (offset == prev_offset + 1 || offset == prev_offset - 1) + pages <<= 1; Not perfect, but should work in some sort. This reminds me to think if pagereadahead flag is really required, hit in swap cache is a more reliable way to count readahead hit, and as Hugh mentioned, swap isn't vma bound. Thanks, Shaohua -- 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: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)
On 10/23/12 3:57 PM, Nix wrote: > (I'd provide more sample errors, but this bug has been eating > newly-written logs in /var all day, so not much has survived.) > > I rebooted into 3.6.1 rescue mode and fscked everything: lots of > orphans, block group corruption and cross-linked files. The problems did > not recur upon booting from 3.6.1 into 3.6.1 again. It is quite clear > that metadata changes made in 3.6.3 are not making it to disk reliably, > thus leading to corrupted filesystems marked clean on reboot into other > kernels: pretty much every file appended to in 3.6.3 loses some or all > of its appended data, and newly allocated blocks often end up > cross-linked between multiple files. > > The curious thing is this doesn't affect every filesystem: for a while > it affected only /var, and now it's affecting only /var and /home. The > massive writes to the ext4 filesystem mounted on /usr/src seem to have > gone off without incident: fsck reports no problems. > > > The only unusual thing about the filesystems on this machine are that > they have hardware RAID-5 (using the Areca driver), so I'm mounting with > 'nobarrier': I should have read more. :( More questions follow: * Does the Areca have a battery backed write cache? * Are you crashing or rebooting cleanly? * Do you see log recovery messages in the logs for this filesystem? > the full set of options for all my ext4 filesystems are: > > rw,nosuid,nodev,relatime,journal_checksum,journal_async_commit,nobarrier,quota, > usrquota,grpquota,commit=30,stripe=16,data=ordered,usrquota,grpquota ok journal_async_commit is off the reservation a bit; that's really not tested, and Jan had serious reservations about its safety. * Can you reproduce this w/o journal_async_commit? -Eric > If there's anything I can do to help, I'm happy to do it, once I've > restored my home directory from backup :( > > > tune2fs output for one of the afflicted filesystems (after fscking): > > tune2fs 1.42.2 (9-Apr-2012) > Filesystem volume name: home > Last mounted on: /home > Filesystem UUID: 95bd22c2-253c-456f-8e36-b6cfb9ecd4ef > Filesystem magic number: 0xEF53 > Filesystem revision #:1 (dynamic) > Filesystem features: has_journal ext_attr resize_inode dir_index > filetype needs_recovery extent flex_bg sparse_super large_file huge_file > uninit_bg dir_nlink extra_isize > Filesystem flags: signed_directory_hash > Default mount options:(none) > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 3276800 > Block count: 13107200 > Reserved block count: 655360 > Free blocks: 5134852 > Free inodes: 3174777 > First block: 0 > Block size: 4096 > Fragment size:4096 > Reserved GDT blocks: 20 > Blocks per group: 32768 > Fragments per group: 32768 > Inodes per group: 8192 > Inode blocks per group: 512 > RAID stripe width:16 > Flex block group size:64 > Filesystem created: Tue May 26 21:29:41 2009 > Last mount time: Tue Oct 23 21:32:07 2012 > Last write time: Tue Oct 23 21:32:07 2012 > Mount count: 2 > Maximum mount count: 20 > Last checked: Tue Oct 23 21:22:16 2012 > Check interval: 15552000 (6 months) > Next check after: Sun Apr 21 21:22:16 2013 > Lifetime writes: 1092 GB > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 256 > Required extra isize: 28 > Desired extra isize: 28 > Journal inode:8 > First orphan inode: 1572907 > Default directory hash: half_md4 > Directory Hash Seed: a201983d-d8a3-460b-93ca-eb7804b62c23 > Journal backup: inode blocks > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT4-fs error w/ external USB drive
Toralf, Are you using any kind of special mount options on your usb stick? Thanks, - Ted -- 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 004/193] Documentation/laptops: remove CONFIG_EXPERIMENTAL
On Tue, Oct 23, 2012 at 01:01:17PM -0700, Kees Cook wrote: > This config item has not carried much meaning for a while now and is > almost always enabled by default. As agreed during the Linux kernel > summit, remove it. I am not really involved in this, other than the fact that I made some small changes to this documentation file. Thus, I recuse myself from having to review/make a decision on this patch! :-) Thanks. Kumar > CC: Rob Landley > CC: Kumar Appaiah > CC: Randy Dunlap > Signed-off-by: Kees Cook > --- > Documentation/laptops/thinkpad-acpi.txt |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/laptops/thinkpad-acpi.txt > b/Documentation/laptops/thinkpad-acpi.txt > index 9d66682..cf7bc6c 100644 > --- a/Documentation/laptops/thinkpad-acpi.txt > +++ b/Documentation/laptops/thinkpad-acpi.txt > @@ -1398,7 +1398,7 @@ Sysfs notes: > EXPERIMENTAL: UWB > - > > -This feature is marked EXPERIMENTAL because it has not been extensively > +This feature is considered EXPERIMENTAL because it has not been extensively > tested and validated in various ThinkPad models yet. The feature may not > work as expected. USE WITH CAUTION! To use this feature, you need to supply > the experimental=1 parameter when loading the module. > -- > 1.7.9.5 -- Kumar Appaiah -- 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 098/193] drivers/net/usb: remove CONFIG_EXPERIMENTAL
From: Kees Cook Date: Tue, 23 Oct 2012 15:53:27 -0700 > On Tue, Oct 23, 2012 at 1:15 PM, Greg Kroah-Hartman > wrote: >> On Tue, Oct 23, 2012 at 01:02:51PM -0700, Kees Cook wrote: >>> This config item has not carried much meaning for a while now and is >>> almost always enabled by default. As agreed during the Linux kernel >>> summit, remove it. >>> >>> CC: Greg Kroah-Hartman >>> Signed-off-by: Kees Cook >>> --- >>> drivers/net/usb/Kconfig | 16 +++- >>> 1 file changed, 7 insertions(+), 9 deletions(-) >> >> Acked-by: Greg Kroah-Hartman >> >> But note, drivers/net/usb/ is handled by netdev@, not by me, so I can't >> take this, sorry. > > Sounds good. David, do you want me to carry this with the others? Yes. -- 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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner wrote: >> >> It is spelled: >> >> git notes add -m SHA1 > > Cool! Don't use them for anything global. Use them for local codeflow, but don't expect them to be distributed. It's a separate "flow", and while it *can* be distributed, it's not going to be for the kernel, for example. So no, don't start using this to ack things, because the acks *will* get lost. Linus -- 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] mm: readahead: remove redundant ra_pages in file_ra_state
On 10/23/2012 09:41 PM, YingHang Zhu wrote:
Sorry for the annoying, I forgot ccs in the previous mail.
Thanks,
Ying Zhu
Hi Chen,
On Tue, Oct 23, 2012 at 9:21 PM, Ni zhan Chen wrote:
On 10/23/2012 08:46 PM, Ying Zhu wrote:
Hi,
Recently we ran into the bug that an opened file's ra_pages does not
synchronize with it's backing device's when the latter is changed
with blockdev --setra, the application needs to reopen the file
to know the change, which is inappropriate under our circumstances.
Could you tell me in which function do this synchronize stuff?
With this patch we use bdi.ra_pages directly, so change bdi.ra_pages also
change an opened file's ra_pages.
This bug is also mentioned in scst (generic SCSI target subsystem for
Linux)'s
README file.
This patch tries to unify the ra_pages in struct file_ra_state
and struct backing_dev_info. Basically current readahead algorithm
will ramp file_ra_state.ra_pages up to bdi.ra_pages once it detects the
You mean ondemand readahead algorithm will do this? I don't think so.
file_ra_state_init only called in btrfs path, correct?
No, it's also called in do_dentry_open.
read mode is sequential. Then all files sharing the same backing device
have the same max value bdi.ra_pages set in file_ra_state.
why remove file_ra_state? If one file is read sequential and another file is
read ramdom, how can use the global bdi.ra_pages to indicate the max
readahead window of each file?
This patch does not remove file_ra_state, an file's readahead window
is determined
by it's backing device.
As Dave said, backing device readahead window doesn't tend to change
dynamically, but file readahead window does, it will change when
sequential read, random read, thrash, interleaved read and so on occur.
Applying this means the flags POSIX_FADV_NORMAL and
POSIX_FADV_SEQUENTIAL
in fadivse will only set file reading mode without signifying the
max readahead size of the file. The current apporach adds no additional
overhead in read IO path, IMHO is the simplest solution.
Any comments are welcome, thanks in advance.
Could you show me how you test this patch?
This patch brings no perfmance gain, just fixs some functional bugs.
By reading a 500MB file, the default max readahead size of the
backing device was 128KB, after applying this patch, the read file's
max ra_pages
changed when I tuned the device's read ahead size with blockdev.
Thanks,
Ying Zhu
Signed-off-by: Ying Zhu
---
include/linux/fs.h |1 -
mm/fadvise.c |2 --
mm/filemap.c | 17 +++--
mm/readahead.c |8
4 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 17fd887..36303a5 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -991,7 +991,6 @@ struct file_ra_state {
unsigned int async_size;/* do asynchronous readahead when
there are only # of pages ahead
*/
- unsigned int ra_pages; /* Maximum readahead window */
unsigned int mmap_miss; /* Cache miss stat for mmap
accesses */
loff_t prev_pos;/* Cache last read() position */
};
diff --git a/mm/fadvise.c b/mm/fadvise.c
index 469491e..75e2378 100644
--- a/mm/fadvise.c
+++ b/mm/fadvise.c
@@ -76,7 +76,6 @@ SYSCALL_DEFINE(fadvise64_64)(int fd, loff_t offset,
loff_t len, int advice)
switch (advice) {
case POSIX_FADV_NORMAL:
- file->f_ra.ra_pages = bdi->ra_pages;
spin_lock(>f_lock);
file->f_mode &= ~FMODE_RANDOM;
spin_unlock(>f_lock);
@@ -87,7 +86,6 @@ SYSCALL_DEFINE(fadvise64_64)(int fd, loff_t offset,
loff_t len, int advice)
spin_unlock(>f_lock);
break;
case POSIX_FADV_SEQUENTIAL:
- file->f_ra.ra_pages = bdi->ra_pages * 2;
spin_lock(>f_lock);
file->f_mode &= ~FMODE_RANDOM;
spin_unlock(>f_lock);
diff --git a/mm/filemap.c b/mm/filemap.c
index a4a5260..e7e4409 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1058,11 +1058,15 @@ EXPORT_SYMBOL(grab_cache_page_nowait);
* readahead(R+4...B+3) => bang => read(R+4) => read(R+5) => ..
*
* It is going insane. Fix it by quickly scaling down the readahead
size.
+ * It's hard to estimate how the bad sectors lay out, so to be
conservative,
+ * set the read mode in random.
*/
static void shrink_readahead_size_eio(struct file *filp,
struct file_ra_state *ra)
{
- ra->ra_pages /= 4;
+ spin_lock(>f_lock);
+ filp->f_mode |= FMODE_RANDOM;
+ spin_unlock(>f_lock);
}
/**
@@ -1527,12 +1531,12 @@ static void do_sync_mmap_readahead(struct
vm_area_struct *vma,
/* If we don't want any read-ahead, don't bother */
if (VM_RandomReadHint(vma))
return;
Re: [PATCH v2] epoll: Support for disabling items, and a self-test app.
On 10/23/12 6:26 AM, Michael Kerrisk (man-pages) wrote: On 10/23/12 10:23 AM, Paton J. Lewis wrote: [Re-sending without HTML formatting; all vger.kernel.org destination addresses bounced my original response.] On 10/16/12 8:12 AM, Michael Kerrisk (man-pages) wrote: [CC += linux-api@] Thank you; is this sufficient to coordinate the required changes to the glibc version of epoll.h? I'm not sure. With a bit of luck, someone at glibc might monitor that list. Hello Paton, On Thu, Aug 23, 2012 at 11:15 PM, Paton J. Lewis wrote: From: "Paton J. Lewis" Enhanced epoll_ctl to support EPOLL_CTL_DISABLE, which disables an epoll item. If epoll_ctl doesn't return -EBUSY in this case, it is then safe to delete the epoll item in a multi-threaded environment. Also added a new test_epoll self- test app to both demonstrate the need for this feature and test it. (There's a lot of background missing from this version of the patch that was included in the previous version [http://thread.gmane.org/gmane.linux.kernel/1311457]. It helps to include the full rationale with a revised patch--best not to assume that someone has the context of past mails when reading a revised patch.) I was trying to present the same information in a more concise manner. I was hoping that the test application would provide a clearer description of the problem and the solution. However, I can include some of my original prose from the v1 email in the next revision's email if you think that would be helpful. Yes, it would be a good idea. I've taken a look at this patch as it currently stands in 3.7-rc1, and done a bit of testing. (By the way, the test program tools/testing/selftests/epoll/test_epoll.c does not compile...) Sorry, the test program compiled against commit ecca5c3acc0d0933d89abc44e60afb0cc8170e35 from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git, which I believe was the current head commit when I emailed the v2 patch in August. I thought that git's format-patch command would include the necessary information so people could see which commit the diff was created from. Should I be pulling from a different repository or working on a different branch? Since this is my first patch submission and I have essentially zero experience with git, I would appreciate any guidance you could provide here. I'm not expert enough to provide guidance, unfortunately. I'd just make sure that the program gets updated with any future patch revision. I should have added that the changes to fix the program were fairly trivial (but they involved a misnamed variable--it looks like you did a scan renaming a variable but didn't catch all instances, so I'm not sure how the test program could have ever compiled in the form that was committed), and I did get it going. Sorry, that error arose from my lack of experience with git and its format-patch command. I created the patch without first committing the final fix to my branch. There are one or two places where the behavior seems a little strange, so I have a question or two at the end of this mail. But other than that, I want to check my understanding so that the interface can be correctly documented. Just to go though my understanding, the problem is the following scenario in a multithreaded application: 1. Multiple threads are performing epoll_wait() operations, and maintaining a user-space cache that contains information corresponding to each file descriptor being monitored by epoll_wait(). 2. At some point, a thread wants to delete (EPOLL_CTL_DEL) a file descriptor from the epoll interest list, and delete the corresponding record from the user-space cache. 3. The problem with (2) is that some other thread may have previously done an epoll_wait() that retrieved information about the fd in question, and may be in the middle of using information in the cache that relates to that fd. Thus, there is a potential race. 4. The race can't solved purely in user space, because doing so would require applying a mutex across the epoll_wait() call, which would of course blow thread concurrency. Right? Yes, that is an accurate description of the problem. Okay. Your solution is the EPOLL_CTL_DISABLE operation. I want to confirm my understanding about how to use this flag, since the description that has accompanied the patches so far has been a bit sparse 0. In the scenario you're concerned about, deleting a file descriptor means (safely) doing the following: (a) Deleting the file descriptor from the epoll interest list using EPOLL_CTL_DEL (b) Deleting the corresponding record in the user-space cache 1. It's only meaningful to use this EPOLL_CTL_DISABLE in conjunction with EPOLLONESHOT. 2. Using EPOLL_CTL_DISABLE without using EPOLLONESHOT in conjunction is a logical error. 3. The correct way to code multithreaded applications using EPOLL_CTL_DISABLE and EPOLLONESHOT is as follows: a.
Re: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)
On 10/23/12 5:19 PM, Theodore Ts'o wrote:
> On Tue, Oct 23, 2012 at 09:57:08PM +0100, Nix wrote:
>>
>> It is now quite clear that this is a bug introduced by one or more of
>> the post-3.6.1 ext4 patches (which have all been backported at least to
>> 3.5, so the problem is probably there too).
>>
>> [ 60.290844] EXT4-fs error (device dm-3): ext4_mb_generate_buddy:741:
>> group 202, 1583 clusters in bitmap, 1675 in gd
>> [ 60.291426] JBD2: Spotted dirty metadata buffer (dev = dm-3, blocknr =
>> 0). There's a risk of filesystem corruption in case of system crash.
>>
>
> I think I've found the problem. I believe the commit at fault is commit
> 14b4ed22a6 (upstream commit eeecef0af5e):
>
> jbd2: don't write superblock when if its empty
>
> which first appeared in v3.6.2.
>
> The reason why the problem happens rarely is that the effect of the
> buggy commit is that if the journal's starting block is zero, we fail
> to truncate the journal when we unmount the file system. This can
> happen if we mount and then unmount the file system fairly quickly,
> before the log has a chance to wrap.After the first time this has
> happened, it's not a disaster, since when we replay the journal, we'll
> just replay some extra transactions. But if this happens twice, the
> oldest valid transaction will still not have gotten updated, but some
> of the newer transactions from the last mount session will have gotten
> written by the very latest transacitons, and when we then try to do
> the extra transaction replays, the metadata blocks can end up getting
> very scrambled indeed.
I'm stumped by this; maybe Ted can see if I'm missing something.
(and Nix, is there anything special about your fs? Any nondefault
mkfs or mount options, external journal, inordinately large fs, or
anything like that?)
The suspect commit added this in jbd2_mark_journal_empty():
/* Is it already empty? */
if (sb->s_start == 0) {
read_unlock(>j_state_lock);
return;
}
thereby short circuiting the function.
But Ted's suggestion that mounting the fs, doing a little work, and
unmounting before we wrap would lead to this doesn't make sense to
me. When I do a little work, s_start is at 1, not 0. We start
the journal at s_first:
load_superblock()
journal->j_first = be32_to_cpu(sb->s_first);
And when we wrap the journal, we wrap back to j_first:
jbd2_journal_next_log_block():
if (journal->j_head == journal->j_last)
journal->j_head = journal->j_first;
and j_first comes from s_first, which is set at journal creation
time to be "1" for an internal journal.
So s_start == 0 sure looks special to me; so far I can only see that
we get there if we've been through jbd2_mark_journal_empty() already,
though I'm eyeballing jbd2_journal_get_log_tail() as well.
Ted's proposed patch seems harmless but so far I don't understand
what problem it fixes, and I cannot recreate getting to
jbd2_mark_journal_empty() with a dirty log and s_start == 0.
-Eric
> *Sigh*. My apologies for not catching this when I reviewed this
> patch. I believe the following patch should fix the bug; once it's
> reviewed by other ext4 developers, I'll push this to Linus ASAP.
>
> - Ted
>
> commit 26de1ba5acc39f0ab57ce1ed523cb128e4ad73a4
> Author: Theodore Ts'o
> Date: Tue Oct 23 18:15:22 2012 -0400
>
> jbd2: fix a potential fs corrupting bug in jbd2_mark_journal_empty
>
> Fix a potential file system corrupting bug which was introduced by
> commit eeecef0af5ea4efd763c9554cf2bd80fc4a0efd3: jbd2: don't write
> superblock when if its empty.
>
> We should only skip writing the journal superblock if there is nothing
> to do --- not just when s_start is zero.
>
> This has caused users to report file system corruptions in ext4 that
> look like this:
>
> EXT4-fs error (device sdb3): ext4_mb_generate_buddy:741: group 436, 22902
> clusters in bitmap, 22901 in gd
> JBD2: Spotted dirty metadata buffer (dev = sdb3, blocknr = 0). There's a
> risk of filesystem corruption in case of system crash.
>
> after the file system has been corrupted.
>
> Signed-off-by: "Theodore Ts'o"
> Cc: sta...@vger.kernel.org
>
> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
> index 0f16edd..0064181 100644
> --- a/fs/jbd2/journal.c
> +++ b/fs/jbd2/journal.c
> @@ -1351,18 +1351,20 @@ void jbd2_journal_update_sb_log_tail(journal_t
> *journal, tid_t tail_tid,
> static void jbd2_mark_journal_empty(journal_t *journal)
> {
> journal_superblock_t *sb = journal->j_superblock;
> + __be32 new_tail_sequence;
>
> BUG_ON(!mutex_is_locked(>j_checkpoint_mutex));
> read_lock(>j_state_lock);
> - /* Is it already empty? */
> - if (sb->s_start == 0) {
> + new_tail_sequence = cpu_to_be32(journal->j_tail_sequence);
> + /* Nothing to do? */
> + if
[PATCH] arm: l2cc: doc: fix device tree example typo
The list of attributes above details the use of the 'filter-ranges'
property, but the example improperly used 'filter-latency'. Make these
consistent by fixing up the example.
Signed-off-by: Josh Cartwright
---
Documentation/devicetree/bindings/arm/l2cc.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt
b/Documentation/devicetree/bindings/arm/l2cc.txt
index 7ca5216..7c3ee3a 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -37,7 +37,7 @@ L2: cache-controller {
reg = <0xfff12000 0x1000>;
arm,data-latency = <1 1 1>;
arm,tag-latency = <2 2 2>;
-arm,filter-latency = <0x8000 0x800>;
+arm,filter-ranges = <0x8000 0x800>;
cache-unified;
cache-level = <2>;
interrupts = <45>;
--
1.8.0
--
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 17/23] cx23885: Replace memcpy with struct assignment
(CCed Steven Toth and Devin Heitmueller) On Tue, Oct 23, 2012 at 7:16 PM, Andy Walls wrote: > On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote: >> This kind of memcpy() is error-prone. Its replacement with a struct >> assignment is prefered because it's type-safe and much easier to read. >> >> Found by coccinelle. Hand patched and reviewed. >> Tested by compilation only. >> >> A simplified version of the semantic match that finds this problem is as >> follows: (http://coccinelle.lip6.fr/) >> >> // >> @@ >> identifier struct_name; >> struct struct_name to; >> struct struct_name from; >> expression E; >> @@ >> -memcpy(&(to), &(from), E); >> +to = from; >> // >> >> Signed-off-by: Peter Senna Tschudin >> Signed-off-by: Ezequiel Garcia > > This patch looks OK to me. You forgot to CC: Steven Toth and/or Devin > Heitmueller (I can't remember who did the VBI work.) Done, thank you. Ezequiel -- 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 04/23] sn9c102: Replace memcpy with struct assignment
On Tue, Oct 23, 2012 at 4:57 PM, Ezequiel Garcia wrote: > This kind of memcpy() is error-prone. Its replacement with a struct > assignment is prefered because it's type-safe and much easier to read. > > Found by coccinelle. Hand patched and reviewed. > Tested by compilation only. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) > > // > @@ > identifier struct_name; > struct struct_name to; > struct struct_name from; > expression E; > @@ > -memcpy(&(to), &(from), E); > +to = from; > // > > Signed-off-by: Peter Senna Tschudin > Signed-off-by: Ezequiel Garcia > --- > drivers/media/usb/sn9c102/sn9c102_core.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/usb/sn9c102/sn9c102_core.c > b/drivers/media/usb/sn9c102/sn9c102_core.c > index 5bfc8e2..4cae6f8 100644 > --- a/drivers/media/usb/sn9c102/sn9c102_core.c > +++ b/drivers/media/usb/sn9c102/sn9c102_core.c > @@ -2824,7 +2824,7 @@ sn9c102_vidioc_querybuf(struct sn9c102_device* cam, > void __user * arg) > b.index >= cam->nbuffers || cam->io != IO_MMAP) > return -EINVAL; > > - memcpy(, >frame[b.index].buf, sizeof(b)); > + b = cam->frame[b.index].buf; > > if (cam->frame[b.index].vma_use_count) > b.flags |= V4L2_BUF_FLAG_MAPPED; > @@ -2927,7 +2927,7 @@ sn9c102_vidioc_dqbuf(struct sn9c102_device* cam, struct > file* filp, > > f->state = F_UNUSED; > > - memcpy(, >buf, sizeof(b)); > + b = f->buf; > if (f->vma_use_count) > b.flags |= V4L2_BUF_FLAG_MAPPED; > Andy: you got me thinking on performance. Most patches are initialization or setup code. Here we patch a xxx_vidioc_dqbuf() function. Is this a speed sensitive path? I still think this change can't hurt performance, but I may be wrong! Ezequiel -- 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] Energy/power monitoring within the kernel
Hi, On Tuesday, October 23, 2012 06:30:49 PM Pawel Moll wrote: > Greetings All, > > More and more of people are getting interested in the subject of power > (energy) consumption monitoring. We have some external tools like > "battery simulators", energy probes etc., but some targets can measure > their power usage on their own. > > Traditionally such data should be exposed to the user via hwmon sysfs > interface, and that's exactly what I did for "my" platform - I have > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good > enough to draw pretty graphs in userspace. Everyone was happy... > > Now I am getting new requests to do more with this data. In particular > I'm asked how to add such information to ftrace/perf output. Why? What is the gain? Perf events can be triggered at any point in the kernel. A cpufreq event is triggered when the frequency gets changed. CPU idle events are triggered when the kernel requests to enter an idle state or exits one. When would you trigger a thermal or a power event? There is the possibility of (critical) thermal limits. But if I understand this correctly you want this for debugging and I guess you have everything interesting one can do with temperature values: - read the temperature - draw some nice graphs from the results Hm, I guess I know what you want to do: In your temperature/energy graph, you want to have some dots when relevant HW states (frequency, sleep states, DDR power,...) changed. Then you are able to see the effects over a timeline. So you have to bring the existing frequency/idle perf events together with temperature readings Cleanest solution could be to enhance the exisiting userspace apps (pytimechart/perf timechart) and let them add another line (temperature/energy), but the data would not come from perf, but from sysfs/hwmon. Not sure whether this works out with the timechart tools. Anyway, this sounds like a userspace only problem. Thomas -- 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] Energy/power monitoring within the kernel
Hi, On Tuesday, October 23, 2012 06:30:49 PM Pawel Moll wrote: > Greetings All, > > More and more of people are getting interested in the subject of power > (energy) consumption monitoring. We have some external tools like > "battery simulators", energy probes etc., but some targets can measure > their power usage on their own. > > Traditionally such data should be exposed to the user via hwmon sysfs > interface, and that's exactly what I did for "my" platform - I have > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good > enough to draw pretty graphs in userspace. Everyone was happy... > > Now I am getting new requests to do more with this data. In particular > I'm asked how to add such information to ftrace/perf output. Why? What is the gain? Perf events can be triggered at any point in the kernel. A cpufreq event is triggered when the frequency gets changed. CPU idle events are triggered when the kernel requests to enter an idle state or exits one. When would you trigger a thermal or a power event? There is the possibility of (critical) thermal limits. But if I understand this correctly you want this for debugging and I guess you have everything interesting one can do with temperature values: - read the temperature - draw some nice graphs from the results Hm, I guess I know what you want to do: In your temperature/energy graph, you want to have some dots when relevant HW states (frequency, sleep states, DDR power,...) changed. Then you are able to see the effects over a timeline. So you have to bring the existing frequency/idle perf events together with temperature readings Cleanest solution could be to enhance the exisiting userspace apps (pytimechart/perf timechart) and let them add another line (temperature/energy), but the data would not come from perf, but from sysfs/hwmon. Not sure whether this works out with the timechart tools. Anyway, this sounds like a userspace only problem. Thomas -- 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 173/193] net/mac80211: remove CONFIG_EXPERIMENTAL
Hi All, On Tue, 23 Oct 2012 13:22:23 -0700 Kees Cook wrote: > > On Tue, Oct 23, 2012 at 1:16 PM, David Miller wrote: > > From: Johannes Berg > > Date: Tue, 23 Oct 2012 22:15:50 +0200 > > > >> On Tue, 2012-10-23 at 13:04 -0700, Kees Cook wrote: > >>> This config item has not carried much meaning for a while now and is > >>> almost always enabled by default. As agreed during the Linux kernel > >>> summit, remove it. > >>> > >>> CC: "John W. Linville" > >>> CC: Johannes Berg > >>> CC: "David S. Miller" > >>> Signed-off-by: Kees Cook > >> > >> Acked-by: Johannes Berg > >> > >> Presumably somebody is going to submit a git tree with the entire series > >> and you don't want me to pick up this piece, right? > > > > He better not expect us to take this stuff. > > I'm going to do whatever each maintainer wants. :) > > Sounds like you guys would like me to carry these in my tree, so I'll > add them to linux-next. I would much prefer that they are merged via each maintainers tree as that will eliminate the inevitable conflicts (for which I will bear the pain :-(). These are not big hard patches and have no dependencies on anything, so what is the problem? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp4WeTxWFjk1.pgp Description: PGP signature
Re: drm i915 hangs on heavy io load
Hi Dave, hi Chris,
thanks for your answers.
On Di, 23 Okt 2012, Dave Airlie wrote:
> Does booting with i915.i915_enable_rc6=0 help?
No,booted with that, it happened again on a completely idle
system (well, I believe completely idle, I was doing the
dishes ;-)
[12437.995026] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[12437.995034] [drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[12438.000213] [drm:init_ring_common] *ERROR* failed to set render ring head to
zero ctl head 5ee06f14 tail start 3000
[12438.054894] [drm:init_ring_common] *ERROR* render ring initialization failed
ctl 0001f001 head 5ee06f14 tail start 3000
[12439.583064] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[12439.583176] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[12439.583182] [drm:i915_reset] *ERROR* Failed to reset chip.
New output see here:
http://www.logic.at/people/preining/i915_error_state.gz
> http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa-pile=0d5fed2de763b49bb1a90140758153481f043757
> is the missing ingredient.
I am compiling a kernel with this patch based on current git now.
Should I still use the above kernel cmd argument (i915...rc6=0)
or try without it?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
What are you talking about?
Never mind, eat the fruit.
You know, this place almost looks like the Garden of Eden.
Eat the fruit.
Sounds quite like it too.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
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 5/5] zynq: move static peripheral mappings
Shifting them up into the vmalloc region prevents the following warning,
when booting a zynq qemu target with more than 512mb of RAM:
BUG: mapping for 0xe000 at 0xe000 out of vmalloc space
In addition, it allows for reuse of these mappings when the proper
drivers issue requests via ioremap().
Signed-off-by: Josh Cartwright
Cc: John Linn
---
arch/arm/mach-zynq/common.c| 6 +++---
arch/arm/mach-zynq/include/mach/zynq_soc.h | 23 +--
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index ba48f06..ba8d14f 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -73,12 +73,12 @@ static struct map_desc io_desc[] __initdata = {
{
.virtual= TTC0_VIRT,
.pfn= __phys_to_pfn(TTC0_PHYS),
- .length = SZ_4K,
+ .length = TTC0_SIZE,
.type = MT_DEVICE,
}, {
.virtual= SCU_PERIPH_VIRT,
.pfn= __phys_to_pfn(SCU_PERIPH_PHYS),
- .length = SZ_8K,
+ .length = SCU_PERIPH_SIZE,
.type = MT_DEVICE,
},
@@ -86,7 +86,7 @@ static struct map_desc io_desc[] __initdata = {
{
.virtual= UART0_VIRT,
.pfn= __phys_to_pfn(UART0_PHYS),
- .length = SZ_4K,
+ .length = UART0_SIZE,
.type = MT_DEVICE,
},
#endif
diff --git a/arch/arm/mach-zynq/include/mach/zynq_soc.h
b/arch/arm/mach-zynq/include/mach/zynq_soc.h
index 218283a..c6b9b67 100644
--- a/arch/arm/mach-zynq/include/mach/zynq_soc.h
+++ b/arch/arm/mach-zynq/include/mach/zynq_soc.h
@@ -15,27 +15,30 @@
#ifndef __MACH_XILINX_SOC_H__
#define __MACH_XILINX_SOC_H__
+#include
+
#define PERIPHERAL_CLOCK_RATE 250
-/* For now, all mappings are flat (physical = virtual)
+/* Static peripheral mappings are mapped at the top of the
+ * vmalloc region
*/
-#define UART0_PHYS 0xE000
-#define UART0_VIRT UART0_PHYS
+#define UART0_PHYS 0xE000
+#define UART0_SIZE SZ_4K
+#define UART0_VIRT (VMALLOC_END - UART0_SIZE)
-#define TTC0_PHYS 0xF8001000
-#define TTC0_VIRT TTC0_PHYS
+#define TTC0_PHYS 0xF8001000
+#define TTC0_SIZE SZ_4K
+#define TTC0_VIRT (UART0_VIRT - TTC0_SIZE)
-#define SCU_PERIPH_PHYS0xF8F0
-#define SCU_PERIPH_VIRTSCU_PERIPH_PHYS
+#define SCU_PERIPH_PHYS0xF8F0
+#define SCU_PERIPH_SIZESZ_8K
+#define SCU_PERIPH_VIRT(TTC0_VIRT - SCU_PERIPH_SIZE)
/* The following are intended for the devices that are mapped early */
#define TTC0_BASE IOMEM(TTC0_VIRT)
#define SCU_PERIPH_BASEIOMEM(SCU_PERIPH_VIRT)
-/*
- * Mandatory for CONFIG_LL_DEBUG, UART is mapped virtual = physical
- */
#define LL_UART_PADDR UART0_PHYS
#define LL_UART_VADDR UART0_VIRT
--
1.8.0
--
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 4/5] ARM: annotate VMALLOC_END definition with _AC
This makes the definition of VMALLOC_END suitable for use within assembly code. This is necessary to allow the use of VMALLOC_END in defining where the early uart is mapped for use with DEBUG_LL. Signed-off-by: Josh Cartwright --- arch/arm/include/asm/pgtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h index 08c1231..72904a2 100644 --- a/arch/arm/include/asm/pgtable.h +++ b/arch/arm/include/asm/pgtable.h @@ -40,7 +40,7 @@ */ #define VMALLOC_OFFSET (8*1024*1024) #define VMALLOC_START (((unsigned long)high_memory + VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1)) -#define VMALLOC_END0xff00UL +#define VMALLOC_END_AC(0xff00,UL) #define LIBRARY_TEXT_START 0x0c00 -- 1.8.0 -- 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 3/5] zynq: remove use of CLKDEV_LOOKUP
The Zynq support in mainline does not (yet) make use of any of the
generic clk or clk lookup functionality. Remove what is upstream for
now, until the out-of-tree implementation is in suitable form for
merging.
An important side effect of this patch is that it allows the building of
a Zynq kernel without running into unresolved symbol problems:
drivers/built-in.o: In function `amba_get_enable_pclk':
clkdev.c:(.text+0x444): undefined reference to `clk_enable'
drivers/built-in.o: In function `amba_remove':
clkdev.c:(.text+0x488): undefined reference to `clk_disable'
drivers/built-in.o: In function `amba_probe':
clkdev.c:(.text+0x540): undefined reference to `clk_disable'
drivers/built-in.o: In function `amba_device_add':
clkdev.c:(.text+0x77c): undefined reference to `clk_disable'
drivers/built-in.o: In function `enable_clock':
clkdev.c:(.text+0x29738): undefined reference to `clk_enable'
drivers/built-in.o: In function `disable_clock':
clkdev.c:(.text+0x29778): undefined reference to `clk_disable'
drivers/built-in.o: In function `__pm_clk_remove':
clkdev.c:(.text+0x297f8): undefined reference to `clk_disable'
drivers/built-in.o: In function `pm_clk_suspend':
clkdev.c:(.text+0x29bc8): undefined reference to `clk_disable'
drivers/built-in.o: In function `pm_clk_resume':
clkdev.c:(.text+0x29c28): undefined reference to `clk_enable'
make[2]: *** [vmlinux] Error 1
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
Signed-off-by: Josh Cartwright
Cc: John Linn
---
arch/arm/Kconfig | 1 -
arch/arm/mach-zynq/common.c | 1 -
arch/arm/mach-zynq/include/mach/clkdev.h | 32
3 files changed, 34 deletions(-)
delete mode 100644 arch/arm/mach-zynq/include/mach/clkdev.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cce4f8d..de70d99 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -946,7 +946,6 @@ config ARCH_ZYNQ
bool "Xilinx Zynq ARM Cortex A9 Platform"
select ARM_AMBA
select ARM_GIC
- select CLKDEV_LOOKUP
select CPU_V7
select GENERIC_CLOCKEVENTS
select ICST
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 056091a..ba48f06 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -31,7 +31,6 @@
#include
#include
-#include
#include "common.h"
static struct of_device_id zynq_of_bus_ids[] __initdata = {
diff --git a/arch/arm/mach-zynq/include/mach/clkdev.h
b/arch/arm/mach-zynq/include/mach/clkdev.h
deleted file mode 100644
index c6e73d8..000
--- a/arch/arm/mach-zynq/include/mach/clkdev.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * arch/arm/mach-zynq/include/mach/clkdev.h
- *
- * Copyright (C) 2011 Xilinx, Inc.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#ifndef __MACH_CLKDEV_H__
-#define __MACH_CLKDEV_H__
-
-#include
-
-struct clk {
- unsigned long rate;
- const struct clk_ops*ops;
- const struct icst_params *params;
- void __iomem*vcoreg;
-};
-
-#define __clk_get(clk) ({ 1; })
-#define __clk_put(clk) do { } while (0)
-
-#endif
--
1.8.0
--
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 2/5] zynq: use pl310 device tree bindings
The Zynq has a PL310 L2 cache controller. Convert in-tree uses to using
the device tree.
Signed-off-by: Josh Cartwright
Cc: John Linn
---
arch/arm/boot/dts/zynq-ep107.dts | 9 +
arch/arm/mach-zynq/common.c| 9 +
arch/arm/mach-zynq/include/mach/zynq_soc.h | 4
3 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-ep107.dts b/arch/arm/boot/dts/zynq-ep107.dts
index 7bfff4a..87204d7 100644
--- a/arch/arm/boot/dts/zynq-ep107.dts
+++ b/arch/arm/boot/dts/zynq-ep107.dts
@@ -44,6 +44,15 @@
<0xF8F00100 0x100>;
};
+ L2: cache-controller {
+ compatible = "arm,pl310-cache";
+ reg = <0xF8F02000 0x1000>;
+ arm,data-latency = <2 3 2>;
+ arm,tag-latency = <2 3 2>;
+ cache-unified;
+ cache-level = <2>;
+ };
+
uart0: uart@e000 {
compatible = "xlnx,xuartps";
reg = <0xE000 0x1000>;
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index d73963b..056091a 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -45,12 +45,10 @@ static struct of_device_id zynq_of_bus_ids[] __initdata = {
*/
static void __init xilinx_init_machine(void)
{
-#ifdef CONFIG_CACHE_L2X0
/*
* 64KB way size, 8-way associativity, parity disabled
*/
- l2x0_init(PL310_L2CC_BASE, 0x0206, 0xF0F0);
-#endif
+ l2x0_of_init(0x0206, 0xF0F0);
of_platform_bus_probe(NULL, zynq_of_bus_ids, NULL);
}
@@ -83,11 +81,6 @@ static struct map_desc io_desc[] __initdata = {
.pfn= __phys_to_pfn(SCU_PERIPH_PHYS),
.length = SZ_8K,
.type = MT_DEVICE,
- }, {
- .virtual= PL310_L2CC_VIRT,
- .pfn= __phys_to_pfn(PL310_L2CC_PHYS),
- .length = SZ_4K,
- .type = MT_DEVICE,
},
#ifdef CONFIG_DEBUG_LL
diff --git a/arch/arm/mach-zynq/include/mach/zynq_soc.h
b/arch/arm/mach-zynq/include/mach/zynq_soc.h
index 3d1c6a6..218283a 100644
--- a/arch/arm/mach-zynq/include/mach/zynq_soc.h
+++ b/arch/arm/mach-zynq/include/mach/zynq_soc.h
@@ -25,9 +25,6 @@
#define TTC0_PHYS 0xF8001000
#define TTC0_VIRT TTC0_PHYS
-#define PL310_L2CC_PHYS0xF8F02000
-#define PL310_L2CC_VIRTPL310_L2CC_PHYS
-
#define SCU_PERIPH_PHYS0xF8F0
#define SCU_PERIPH_VIRTSCU_PERIPH_PHYS
@@ -35,7 +32,6 @@
#define TTC0_BASE IOMEM(TTC0_VIRT)
#define SCU_PERIPH_BASEIOMEM(SCU_PERIPH_VIRT)
-#define PL310_L2CC_BASEIOMEM(PL310_L2CC_VIRT)
/*
* Mandatory for CONFIG_LL_DEBUG, UART is mapped virtual = physical
--
1.8.0
--
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 1/5] zynq: use GIC device tree bindings
The Zynq uses the cortex-a9-gic. This eliminates the need to hardcode
register addresses.
Signed-off-by: Josh Cartwright
Cc: John Linn
---
arch/arm/boot/dts/zynq-ep107.dts | 8 +---
arch/arm/mach-zynq/common.c| 7 ++-
arch/arm/mach-zynq/include/mach/zynq_soc.h | 2 --
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-ep107.dts b/arch/arm/boot/dts/zynq-ep107.dts
index 37ca192..7bfff4a 100644
--- a/arch/arm/boot/dts/zynq-ep107.dts
+++ b/arch/arm/boot/dts/zynq-ep107.dts
@@ -36,10 +36,12 @@
ranges;
intc: interrupt-controller@f8f01000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
interrupt-controller;
- compatible = "arm,gic";
- reg = <0xF8F01000 0x1000>;
- #interrupt-cells = <2>;
+ reg = <0xF8F01000 0x1000>,
+ <0xF8F00100 0x100>;
};
uart0: uart@e000 {
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index ab5cfdd..d73963b 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -55,12 +55,17 @@ static void __init xilinx_init_machine(void)
of_platform_bus_probe(NULL, zynq_of_bus_ids, NULL);
}
+static struct of_device_id irq_match[] __initdata = {
+ { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
+ { }
+};
+
/**
* xilinx_irq_init() - Interrupt controller initialization for the GIC.
*/
static void __init xilinx_irq_init(void)
{
- gic_init(0, 29, SCU_GIC_DIST_BASE, SCU_GIC_CPU_BASE);
+ of_irq_init(irq_match);
}
/* The minimum devices needed to be mapped before the VM system is up and
diff --git a/arch/arm/mach-zynq/include/mach/zynq_soc.h
b/arch/arm/mach-zynq/include/mach/zynq_soc.h
index d0d3f8f..3d1c6a6 100644
--- a/arch/arm/mach-zynq/include/mach/zynq_soc.h
+++ b/arch/arm/mach-zynq/include/mach/zynq_soc.h
@@ -35,8 +35,6 @@
#define TTC0_BASE IOMEM(TTC0_VIRT)
#define SCU_PERIPH_BASEIOMEM(SCU_PERIPH_VIRT)
-#define SCU_GIC_CPU_BASE (SCU_PERIPH_BASE + 0x100)
-#define SCU_GIC_DIST_BASE (SCU_PERIPH_BASE + 0x1000)
#define PL310_L2CC_BASEIOMEM(PL310_L2CC_VIRT)
/*
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 02/06] input/rmi4: Core files
On 10/23/2012 05:11 PM, Dmitry Torokhov wrote:
On Tuesday, October 23, 2012 04:46:28 PM Christopher Heiny wrote:
On 10/11/2012 01:13 AM, Dmitry Torokhov wrote:
On Thu, Oct 11, 2012 at 04:15:56AM +, Christopher Heiny wrote:
On Thursday, October 11, 2012 02:21:53 AM you wrote:
On Sat, Oct 6, 2012 at 6:09 AM, Christopher Heiny
wrote:
[snip]
+static int process_interrupt_requests(struct rmi_device *rmi_dev)
+{
+ struct rmi_driver_data *data = dev_get_drvdata(_dev->dev);
+ struct device *dev = _dev->dev;
+ struct rmi_function_container *entry;
+ u8 irq_status[data->num_of_irq_regs];
Looking at this...
What does the data->num_of_irq_regs actually contain?
I just fear that it is something constant like always 2 or always 4,
so there is actually, in reality, a 16 or 32 bit register hiding in
there.
In that case what you should do is to represent it as a u16 or u32 here,
just or the bits into a status word, and then walk over that status
word with something like ffs(bitword); ...
Nope, it's not constant. In theory, and RMI4 based sensor can have up
to 128 functions (in practice, it's far fewer), and each function can
have as many as 7 interrupts. So the number of IRQ registers can vary
from RMI4 sensor to RMI4 sensor, and needs to be computed during the
scan of the product descriptor table.
Is it a good idea to have it on stack then? Should it be part of
rmi_device instead?
It's not coming off the stack. We're allocating it via devm_kzalloc()
in rmi_driver_probe().
No, look at the part of the code that was quoted. "u8 irq_status[data-
num_of_irq_regs];" is on stack.
Sorry - I thought you were referring to data->num_of_irq_regs rather
than irq_status. We'll move that.
--
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/
