Re: perf/tracepoint: another fuzzer generated lockup
(2013/11/15 23:28), Frederic Weisbecker wrote: > On Fri, Nov 15, 2013 at 09:15:21AM -0500, Steven Rostedt wrote: >> On Fri, 15 Nov 2013 13:28:33 +0100 >> Peter Zijlstra wrote: >> >>> On Fri, Nov 15, 2013 at 10:16:18AM +0900, Masami Hiramatsu wrote: Kprobes itself can detect nested call by using per-cpu current-running kprobe pointer. And if it is nested, it just skips calling handlers. Anyway, I don't recommend to probe inside the handlers, but yes, you can trace perf-handler by ftrace B). I actually traced a kprobe-bug by kprobe-tracer last night, that was amazing :) >>> >>> Ah, ok, so that would avoid the worst problems. Good. Should we still >>> mark the entire perf swevent path as __kprobes just to be sure? >> >> I wouldn't unless we can prove that it breaks. It's sometimes nice to >> be able to debug the debugging facilities with the debugging >> facilities ;-) > > Even with the existing __kprobes annotations, I'm sure we can find many ways > to > break the kernel. > > We can reproduce that bug with irq_work recursion with setting a kprobe in > the end of the irq_work() arch low level handler for example. Or simply > somewhere in irq_exit(). > > I think we could do dangerous things with breakpoints as well. Setting > breakpoints > in do_debug() or stuffs like that. > > So keeping up with __kprobes annotations to every potential dangerous site > is not viable IMHO. It's important to maintain basic sanity with tagging sites > that are used by kprobes itself but we can't really prevent from any issue. > > At some point it's up to the user to know what he's doing and avoid recursion. > As long as kprobes can be set only by root. Hmm, it would be better to add some documentation how users can avoid such thing. > OTOH it would be nice to detect these kind of behaviour (thinking about > irq_work for > example) and warn when something wrong is suspected. Agreed. FYI, kprobes has a recursion detection counter and it is reported via debugfs/tracing/kprobe_profile :) Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-kernel@vger.kernel.org
Re: [GIT PULL] A minor amd64_edac fix for 3.13
On Sun, Nov 17, 2013 at 02:22:15AM +0100, Frank Becker wrote: > Still, Google made a mistake by tagging Boris mail as SPAM. As you > already wrote it probably was triggered by the content filter. They > don't tell. To get those filters right is probably impossible. BTW, I > liked your idea to tag propaganda you mentioned in some interview. Btw, this reminds me: I used to have lkml subscribed to gmail and had to go into the spam folder and regularly fish out legit lkml messages. The culmination of this activity was me finding a @google.com employee mail addressed to a discussion on lkml!!! And he was sending from their own range, of course. So yes, while hetzner possibly doesn't take care of spammers or doesn't do so in timely manner (if I'd have to guess, they're on that money saving trip *every* fucking company is on right now) I can't help but wonder at the arrogance of gmail's decision to mark certain messages as spam without saying why so as to senders be able to fix that. And they even manage to shoot their own foot in the process. So Linus, get Linux Foundation to write a nice search interface for mail so that you can move back to community servers. Better yet, write one yourself - I know you're good at writing your own stuff. We'll gladly help out if you need people. :-) :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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 3.4 11/26] md: Fix skipping recovery for read-only arrays.
On Sun, 17 Nov 2013 04:11:19 + Ben Hutchings wrote:
> On Fri, 2013-11-08 at 22:51 -0800, Greg Kroah-Hartman wrote:
> > 3.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Lukasz Dorau
> >
> > commit 61e4947c99c4494336254ec540c50186d186150b upstream.
> >
> > Since:
> > commit 7ceb17e87bde79d285a8b988cfed9eaeebe60b86
> > md: Allow devices to be re-added to a read-only array.
> >
> > spares are activated on a read-only array. In case of raid1 and raid10
> > personalities it causes that not-in-sync devices are marked in-sync
> > without checking if recovery has been finished.
> >
> > If a read-only array is degraded and one of its devices is not in-sync
> > (because the array has been only partially recovered) recovery will be
> > skipped.
> >
> > This patch adds checking if recovery has been finished before marking a
> > device
> > in-sync for raid1 and raid10 personalities. In case of raid5 personality
> > such condition is already present (at raid5.c:6029).
> >
> > Bug was introduced in 3.10 and causes data corruption.
>
> So this fix was not needed for 3.4. Is it harmful if applied to this
> version?
It is not needed, but it is also not harmful.
NeilBrown
>
> Ben.
>
> > Signed-off-by: Pawel Baldysiak
> > Signed-off-by: Lukasz Dorau
> > Signed-off-by: NeilBrown
> > Signed-off-by: Greg Kroah-Hartman
> >
> > ---
> > drivers/md/raid1.c |1 +
> > drivers/md/raid10.c |1 +
> > 2 files changed, 2 insertions(+)
> >
> > --- a/drivers/md/raid1.c
> > +++ b/drivers/md/raid1.c
> > @@ -1357,6 +1357,7 @@ static int raid1_spare_active(struct mdd
> > }
> > }
> > if (rdev
> > + && rdev->recovery_offset == MaxSector
> > && !test_bit(Faulty, >flags)
> > && !test_and_set_bit(In_sync, >flags)) {
> > count++;
> > --- a/drivers/md/raid10.c
> > +++ b/drivers/md/raid10.c
> > @@ -1534,6 +1534,7 @@ static int raid10_spare_active(struct md
> > }
> > sysfs_notify_dirent_safe(tmp->replacement->sysfs_state);
> > } else if (tmp->rdev
> > + && tmp->rdev->recovery_offset == MaxSector
> >&& !test_bit(Faulty, >rdev->flags)
> >&& !test_and_set_bit(In_sync, >rdev->flags)) {
> > count++;
>
signature.asc
Description: PGP signature
linux-kernel@vger.kernel.org
Re: [tip:x86/asm] x86-64, copy_user: Remove zero byte check before copy user buffer.
On 11/16/2013 10:44 PM, Linus Torvalds wrote: > So this doesn't do the 32-bit truncation in the error path of the generic > string copy. Oversight? > >Linus Indeed... although in the kernel it seems to be taken as an invariant that copy lengths over 4G is simply prohibited. There are places all over the kernel which will fail in a massive way if we ever ended up with a copy over 4G in size. As such, I would argue the code with the patch is actually no more broken than with the truncation in place; if anything it is *more* correct than the modified one, since for a (very small) subset of >=4G copies it will actually do the right thing, albeit slowly. The truncations do make me twitch a little inside, I have to admit. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86-64, copy_user: Remove zero byte check before copy user buffer.
Commit-ID: f4cb1cc18f364d761d5614eb62936647f259 Gitweb: http://git.kernel.org/tip/f4cb1cc18f364d761d5614eb62936647f259 Author: Fenghua Yu AuthorDate: Sat, 16 Nov 2013 12:37:01 -0800 Committer: H. Peter Anvin CommitDate: Sat, 16 Nov 2013 18:00:58 -0800 x86-64, copy_user: Remove zero byte check before copy user buffer. Operation of rep movsb instruction handles zero byte copy. As pointed out by Linus, there is no need to check zero size in kernel. Removing this redundant check saves a few cycles in copy user functions. Reported-by: Linus Torvalds Signed-off-by: Fenghua Yu Link: http://lkml.kernel.org/r/1384634221-6006-1-git-send-email-fenghua...@intel.com Signed-off-by: H. Peter Anvin --- arch/x86/lib/copy_user_64.S | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/x86/lib/copy_user_64.S b/arch/x86/lib/copy_user_64.S index a30ca15..ffe4eb9 100644 --- a/arch/x86/lib/copy_user_64.S +++ b/arch/x86/lib/copy_user_64.S @@ -236,8 +236,6 @@ ENDPROC(copy_user_generic_unrolled) ENTRY(copy_user_generic_string) CFI_STARTPROC ASM_STAC - andl %edx,%edx - jz 4f cmpl $8,%edx jb 2f /* less than 8 bytes, go to byte copy loop */ ALIGN_DESTINATION @@ -249,7 +247,7 @@ ENTRY(copy_user_generic_string) 2: movl %edx,%ecx 3: rep movsb -4: xorl %eax,%eax + xorl %eax,%eax ASM_CLAC ret @@ -279,12 +277,10 @@ ENDPROC(copy_user_generic_string) ENTRY(copy_user_enhanced_fast_string) CFI_STARTPROC ASM_STAC - andl %edx,%edx - jz 2f movl %edx,%ecx 1: rep movsb -2: xorl %eax,%eax + xorl %eax,%eax ASM_CLAC ret -- 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] cpufreq: cpufreq-cpu0: Use a sane boot frequency when booting with a mismatched bootloader configuration
On 16 November 2013 19:14, Shawn Guo wrote: > No, it's not a kernel bug. > > OPP is not a definition that belongs to kernel. Instead, it's > characteristics of hardware, and that's why we can naturally put the > definition into device tree. Bear it in mind that device tree is a > hardware description and should be OS agnostic. So it shouldn't be > treated as part of Linux kernel in any case, even though the device > tree source is currently maintained in kernel tree. > > Device tree is designed as a way for firmware/bootloader to describe > hardware to kernel. That said, device tree is more part of bootloader > than kernel. If bootloader runs at a frequency that does not match the > OPP in device tree, the one should be fixed is either bootloader or > device tree but never kernel. I agree for all that.. > However, I agree we should at least have a check in cpufreq-cpu0 driver > and fail out in case that a mismatch is detected. But not here.. We aren't in a non-workable state here.. and so creating panic isn't the right approach. At max we can print an warning but then it doesn't lie in cpufreq-cpu0's domain. It should be done in core if required.. Though for Shawn's information we have another thread in parallel for this issue. You might like to check that too.. https://lkml.org/lkml/2013/11/15/503 -- 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-kernel@vger.kernel.org
linux-kernel@vger.kernel.org
linux-kernel@vger.kernel.org
linux-kernel@vger.kernel.org
linux-kernel@vger.kernel.org
linux-kernel@vger.kernel.org
Re: [PATCH 9/9] KEYS: Fix encrypted key type update method
On Thu, 2013-11-14 at 17:59 +, David Howells wrote: > Mimi Zohar wrote: > > > Is there a keyutils git repo with a version of keyctl that supports the > > control option? > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/log/?h=development Thanks! > > - type size_t is unsigned, no need to verify that it is negative. > > It doesn't hurt either... > > > - missing Documentation/security/keys-trusted-encrypted.txt updates > > Fixed (see diff below), but I suspect trusted_update() also needs scrutiny. > > > - the encrypted_preparse() comment still says 'encrypted_instantiate' > > Fixed. > > David > --- > diff --git a/Documentation/security/keys-trusted-encrypted.txt > b/Documentation/security/keys-trusted-encrypted.txt > index e105ae97a4f5..78794adf445d 100644 > --- a/Documentation/security/keys-trusted-encrypted.txt > +++ b/Documentation/security/keys-trusted-encrypted.txt > @@ -61,7 +61,7 @@ Usage: > keyctl add encrypted name "new [format] key-type:master-key-name keylen" > ring > keyctl add encrypted name "load hex_blob" ring > -keyctl update keyid "update key-type:master-key-name" > +keyctl control keyid encrypted change-master-key > "key-type:master-key-name" > > format:= 'default | ecryptfs' > key-type:= 'trusted' | 'user' The command has remained the same as before: "update key-type:master-key-name". diff --git a/Documentation/security/keys-trusted-encrypted.txt b/Documentation/security/keys-trusted-encrypted.txt index e105ae9..6610be4 100644 --- a/Documentation/security/keys-trusted-encrypted.txt +++ b/Documentation/security/keys-trusted-encrypted.txt @@ -61,12 +61,12 @@ Usage: keyctl add encrypted name "new [format] key-type:master-key-name keylen" ring keyctl add encrypted name "load hex_blob" ring -keyctl update keyid "update key-type:master-key-name" +keyctl control encrypted change-master-key \ + "update key-type:master-key-name" format:= 'default | ecryptfs' key-type:= 'trusted' | 'user' - Examples of trusted and encrypted key usage: Create and save a trusted key named "kmk" of length 32 bytes: @@ -153,6 +153,12 @@ Load an encrypted key "evm" from saved blob: 82dbbc55be2a44616e4959430436dc4f2a7a9659aa60bb4652aeb2120f149ed197c564e0 24717c64 5972dcb82ab2dde83376d82b2e3c09ffc +Encrypt the "evm" key with a new master key kmk-new: + +$ keyctl add trusted kmk-new "new 32" @u +$ keyctl control 831684262 encrypted change-master-key \ + "update trusted:kmk-new" + Other uses for trusted and encrypted keys, such as for disk and file encryption are anticipated. In particular the new format 'ecryptfs' has been defined in in order to use encrypted keys to mount an eCryptfs filesystem. More details thanks, Mimi -- 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: [BUG] perf stat: explicit grouping yields unexpected results
> I'd say that the default behavior should be what Jiri implemented: get > the most out of the situation and inform. But you are right in that > 'forcing' all elements of a group to be valid should be possible as > well - if a special perf stat option or event format is used. When something is multiplexed it can have a very large measurement error. For workloads that fluctuate quite a bit, and the fluctuations do not line up well with the multiplexing interval, the default scaling does not give good results. So you expect to get good data, but you get very bad data. When collecting data for a large number of events it is important to group them correctly, so that events that are directly dependent on each other in equations are properly grouped. When explicit groups were added the user likely considered this problem, so it's not good to silently override the choices. If a user doesn't care they can always not use groups. > Even in that second case it shouldn't say for everything > in the result, but should deny the run immediately and return with an > error, and should tell the user how many events in the group fit and > which ones didn't. Returning this information would be great, but it would really need an extended errno, or just a error string reported out. -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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] sysfs: use a separate locking class for open files depending on mmap
On Sat, Nov 16, 2013 at 10:21:19PM -0500, Dave Jones wrote: > On Sun, Nov 17, 2013 at 11:17:36AM +0900, Tejun Heo wrote: > > > > + if (has_mmap) > > + mutex_init(>mutex); > > + else > > + mutex_init(>mutex); > > ummm... Supposed to look that way. It'll give two separate static lock class keys to of->mutex. Yeah, looks weird. Any better ideas? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] MMC updates for 3.13-rc1
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
tags/mmc-updates-for-3.13-rc1
to receive the MMC merge for 3.13. These patches have been tested in
linux-next, and there's a conflict with the resolution below. Thanks.
diff --cc drivers/mmc/host/mvsdio.c
index deecee0,22ba4d3..000
--- a/drivers/mmc/host/mvsdio.c
+++ b/drivers/mmc/host/mvsdio.c
@@@ -872,10 -845,7 +845,8 @@@ static const struct of_device_id mvsdio
MODULE_DEVICE_TABLE(of, mvsdio_dt_ids);
static struct platform_driver mvsd_driver = {
- .remove = __exit_p(mvsd_remove),
+ .probe = mvsd_probe,
+ .remove = mvsd_remove,
- .suspend= mvsd_suspend,
- .resume = mvsd_resume,
.driver = {
.name = DRIVER_NAME,
.of_match_table = mvsdio_dt_ids,
The following changes since commit 4b97280675f45c1650ee4e388bd711ecbb18c4b4:
Merge tag 'stable/for-linus-3.12-rc2-tag' of
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip (2013-09-25 15:50:53
-0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
tags/mmc-updates-for-3.13-rc1
for you to fetch changes up to e395c4387c746b4cc7aace4c44baecd7e69a3249:
mmc: wbsd: Silence compiler warning (2013-11-08 14:32:03 -0500)
MMC highlights for 3.13:
Core:
- Improve runtime PM support, remove mmc_{suspend,resume}_host().
- Add MMC_CAP_RUNTIME_RESUME, for delaying MMC resume until we're
outside of the resume sequence (in runtime_resume) to decrease
system resume time.
Drivers:
- dw_mmc: Support HS200 mode.
- sdhci-eshdc-imx: Support SD3.0 SDR clock tuning, DDR on IMX6.
- sdhci-pci: Add support for Intel Clovertrail and Merrifield.
Alexey Neyman (1):
mmc: sdhci: Avoid needless loop while handling SDIO interrupts in
sdhci_irq
Axel Lin (3):
mmc: sdhci-bcm-kona: Use sdhci_pltfm_unregister instead of open coded
mmc: sdhci-bcm2835: Use sdhci_pltfm_unregister instead of open coded
mmc: wmt-sdmmc: Simplify wmt_set_sd_power implementation
Balaji T K (3):
mmc: omap_hsmmc: Fix pbias_disable for omap4
mmc: omap_hsmmc: correct max value of clkd
mmc: omap_hsmmc: remove unused no_off
David Cohen (1):
mmc: sdhci-pci: add Intel Merrifield support
Dong Aisheng (16):
mmc: sdhci: add hooks for platform specific tuning
mmc: sdhci: allow platform access of sdhci_send_command
mmc: sdhci-esdhc: move common esdhc_set_clock to platform driver
mmc: sdhci-esdhc-imx: support real clock on and off for imx6q
mmc: sdhci-esdhc-imx: add sd3.0 SDR clock tuning support
mmc: sdhci-esdhc-imx: change pinctrl state according to uhs mode
mmc: sdhci-esdhc-imx: correct pre_div for imx6q
mmc: sdhci-esdhc-imx: set actual_clock in clock setting
mmc: sdhci-esdhc-imx: add std tuning support for mx6sl
mmc: sdhci-esdhc-imx: fix reading cap_1 register value for mx6sl
mmc: sdhci: report error once the maximum tuning loops exhausted or
timeout
mmc: sdhci-esdhc-imx: add DDR mode support for mx6
mmc: sdhci-esdhc-imx: add delay line setting support
mmc: sdhci-esdhc-imx: enable SDR50 tuning for imx6q/dl
mmc: sdhci-esdhc-imx: add preset value quirk for mx6
mmc: sdhci: remove unneeded call when have preset value quirk
Doug Anderson (4):
mmc: dw_mmc: don't queue up a card detect at slot startup
mmc: dw_mmc: Add exynos resume_noirq callback to clear WAKEUP_INT
mmc: dw_mmc: Honor requests to set the clock to 0
mmc: dw_mmc: Set timeout to max upon resume
Eric Ernst (1):
mmc: sdhci-pci: Add SDIO/MMC device ID support for Intel Clovertrail
Grant Grundler (1):
mmc: core: remove dead function mmc_try_claim_host
Jackey Shen (1):
mmc: core: clean up duplicate macros
Jianpeng Ma (1):
mmc: omap_hsmmc: fix timeout for cmd and data soft reset
Kuninori Morimoto (1):
sh: ecovec: fixup compile error on sdhi
Ludovic Desroches (1):
mmc: atmel-mci: abort transfer on timeout error
Rodolfo Giometti (1):
mmc: atmel-mci: fix oops in atmci_tasklet_func
Sachin Kamat (3):
mmc: mvsdio: Convert to devm_ioremap_resource
mmc: dw_mmc-socfpga: Remove redundant of_match_ptr
mmc: dw_mmc-socfpga: Staticize dw_mci_socfpga_probe
Seungwon Jeon (15):
mmc: dw_mmc: add support tuning scheme
mmc: dw_mmc: exynos: add variable delay tuning sequence
mmc: dw_mmc: exynos: adjust the clock rate with speed mode
mmc: dw_mmc: add the capability to support hs200 mode
mmc: dw_mmc: move supports-highspeed of quirks to caps
mmc: dw_mmc: set the supported max/min frequency
mmc: dw_mmc: adjust the fifoth with block size
mmc: dw_mmc: control card read threshold
mmc:
Re: [PATCH] sysfs: use a separate locking class for open files depending on mmap
On Sun, Nov 17, 2013 at 11:17:36AM +0900, Tejun Heo wrote: > +if (has_mmap) > +mutex_init(>mutex); > +else > +mutex_init(>mutex); ummm... Dave -- 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] Fix a trivial typo in comments.
Fix a trivial typo in rq_attach_root. Signed-off-by: Shigeru Yoshida --- kernel/sched/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 5ac63c9..2bc3bc0 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4985,7 +4985,7 @@ static void rq_attach_root(struct rq *rq, struct root_domain *rd) cpumask_clear_cpu(rq->cpu, old_rd->span); /* -* If we dont want to free the old_rt yet then +* If we dont want to free the old_rd yet then * set old_rd to NULL to skip the freeing later * in this function: */ -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: About deadline IO scheduler in kernel
-- Forwarded message -- From: 韩磊 Date: 2013/11/16 Subject: About deadline IO scheduler in kernel To: Linux Kernel Mailing List In deadline scheduler, in a FIFO list when a request insert it and other request remove it in the same time,whether it make conflict??? Whether it need lock?? Thank you! -- 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: Fwd: [PATCH 8/8] arm: dts: keystone: add watchdog entry
On 11/06/2013 03:33 AM, ivan.khoronzhuk wrote:
Add watchdog entry to keystone device tree.
Signed-off-by: Ivan Khoronzhuk
Acked-by: Guenter Roeck
---
arch/arm/boot/dts/keystone.dts |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/keystone.dts b/arch/arm/boot/dts/keystone.dts
index 100bdf5..a6e5f91 100644
--- a/arch/arm/boot/dts/keystone.dts
+++ b/arch/arm/boot/dts/keystone.dts
@@ -179,5 +179,11 @@
interrupts = ;
clocks = <>;
};
+
+ wdt: wdt@022f0080 {
+ compatible = "ti,keystone-wdt";
+ reg = <0x022f0080 0x80>;
+ clocks = <>;
+ };
};
};
--
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: Fwd: [PATCH 7/8] watchdog: davinci: add "clocks" property
On 11/06/2013 03:32 AM, ivan.khoronzhuk wrote:
The Keystone arch is using clocks in DT and source clock for watchdog
has to be specified, so add this to binding.
Signed-off-by: Ivan Khoronzhuk
---
.../devicetree/bindings/watchdog/davinci-wdt.txt |5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
index fddced9..4db4d0e 100644
--- a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
@@ -7,6 +7,10 @@ Required properties:
- reg : Should contain WDT registers location and length
+- clocks: phandle reference to the controller clock.
+ Required only for Keystone arch.
+ See clock-bindings.txt
+
Yet another form of formatting. Also, wonder if it makes sense to merge this
with the patch adding keystone support.
Optional properties:
- timeout-sec:Contains the watchdog timeout in seconds
@@ -21,4 +25,5 @@ wdt: wdt@232 {
compatible = "ti,davinci-wdt";
reg = <0x0232 0x80>;
timeout-sec = <30>;
+ clocks = <>;
};
--
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: Fwd: [PATCH 6/8] watchdog: davinci: reuse driver for keystone arch
On 11/06/2013 03:32 AM, ivan.khoronzhuk wrote:
The keystone arch use the same IP watchdog, so add "ti,keystone-wdt"
compatible and correct identity.
Signed-off-by: Ivan Khoronzhuk
---
.../devicetree/bindings/watchdog/davinci-wdt.txt | 11 +--
drivers/watchdog/Kconfig |4 ++--
drivers/watchdog/davinci_wdt.c |3 ++-
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
index 1668b6e..fddced9 100644
--- a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
@@ -1,13 +1,20 @@
-DaVinci Watchdog Timer (WDT) Controller
+Texas Instruments DaVinci/Keystone Watchdog Timer (WDT) Controller
Required properties:
-- compatible : Should be "ti,davinci-wdt"
+
+- compatible: "ti,davinci-wdt"
+ "ti,keystone-wdt"
+
- reg : Should contain WDT registers location and length
Please use consistent formatting. If you change it, at least change it to be
consistent.
Optional properties:
- timeout-sec:Contains the watchdog timeout in seconds
+Documentation:
+Davinci DM646x - http://www.ti.com/lit/ug/spruer5b/spruer5b.pdf
+Keystone - http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
+
Examples:
wdt: wdt@232 {
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2c954b5..a4fe130 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -270,11 +270,11 @@ config IOP_WATCHDOG
config DAVINCI_WATCHDOG
tristate "DaVinci watchdog"
- depends on ARCH_DAVINCI
+ depends on ARCH_DAVINCI || ARCH_KEYSTONE
select WATCHDOG_CORE
help
Say Y here if to include support for the watchdog timer
- in the DaVinci DM644x/DM646x processors.
+ in the DaVinci DM644x/DM646x or Keystone processors.
To compile this driver as a module, choose M here: the
module will be called davinci_wdt.
diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
index a371b2d..e51fd2e 100644
--- a/drivers/watchdog/davinci_wdt.c
+++ b/drivers/watchdog/davinci_wdt.c
@@ -158,7 +158,7 @@ static unsigned int davinci_wdt_status(struct
watchdog_device *wdd)
static const struct watchdog_info davinci_wdt_info = {
.options = WDIOF_KEEPALIVEPING,
- .identity = "DaVinci Watchdog",
+ .identity = "DaVinci/Keystone Watchdog",
};
static const struct watchdog_ops davinci_wdt_ops = {
@@ -229,6 +229,7 @@ static int davinci_wdt_remove(struct platform_device *pdev)
static const struct of_device_id davinci_wdt_of_match[] = {
{ .compatible = "ti,davinci-wdt", },
+ { .compatible = "ti,keystone-wdt", },
{},
};
MODULE_DEVICE_TABLE(of, davinci_wdt_of_match);
--
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: Fwd: [PATCH 5/8] watchdog: davinci: add "timeout-sec" property
On 11/06/2013 03:32 AM, ivan.khoronzhuk wrote:
Since Davinci WDT has been switched to use WDT core, it became able
to support timeout-sec property, so add it to it's binding description.
Signed-off-by: Ivan Khoronzhuk
---
.../devicetree/bindings/watchdog/davinci-wdt.txt |5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
index 75558cc..1668b6e 100644
--- a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
@@ -4,9 +4,14 @@ Required properties:
- compatible : Should be "ti,davinci-wdt"
- reg : Should contain WDT registers location and length
+Optional properties:
+
empty line not needed here (and inconsistent).
+- timeout-sec: Contains the watchdog timeout in seconds
+
Formatting is different to other bindings.
Examples:
wdt: wdt@232 {
compatible = "ti,davinci-wdt";
reg = <0x0232 0x80>;
+ timeout-sec = <30>;
};
--
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: Fwd: [PATCH 4/8] watchdog: davinci: add GET_STATUS option support
On 11/06/2013 03:32 AM, ivan.khoronzhuk wrote:
When watchdog timer is expired we can know about it thought
thought -> through or with
GET_STATUS ioctl option.
Signed-off-by: Ivan Khoronzhuk
---
drivers/watchdog/davinci_wdt.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
index 6cbf2e1..a371b2d 100644
--- a/drivers/watchdog/davinci_wdt.c
+++ b/drivers/watchdog/davinci_wdt.c
@@ -144,6 +144,18 @@ static unsigned int davinci_wdt_get_timeleft(struct
watchdog_device *wdd)
return wdd->timeout - timer_counter;
}
+static unsigned int davinci_wdt_status(struct watchdog_device *wdd)
+{
+ u32 val;
+ struct davinci_wdt_device *davinci_wdt = watchdog_get_drvdata(wdd);
+
+ val = ioread32(davinci_wdt->base + WDTCR);
+ if (val & WDFLAG)
+ return WDIOF_CARDRESET;
+
"Card previously reset the CPU"
Is this really accurate / correct ?
My understanding is that the status is supposed to return the reason for a
previous reset/reboot,
not the curent condition.
+ return 0;
+}
+
static const struct watchdog_info davinci_wdt_info = {
.options = WDIOF_KEEPALIVEPING,
.identity = "DaVinci Watchdog",
@@ -155,6 +167,7 @@ static const struct watchdog_ops davinci_wdt_ops = {
.stop = davinci_wdt_ping,
.ping = davinci_wdt_ping,
.get_timeleft = davinci_wdt_get_timeleft,
+ .status = davinci_wdt_status,
};
static int davinci_wdt_probe(struct platform_device *pdev)
--
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: Fwd: [PATCH 3/8] watchdog: davinci: add GET_TIMELEFT option support
On 11/06/2013 03:31 AM, ivan.khoronzhuk wrote:
Currently, the davinci watchdog can be read while counting,
so we can add ability to report the remaining time before
the system will reboot.
Signed-off-by: Ivan Khoronzhuk
---
drivers/watchdog/davinci_wdt.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
index 1fc2093..6cbf2e1 100644
--- a/drivers/watchdog/davinci_wdt.c
+++ b/drivers/watchdog/davinci_wdt.c
@@ -117,6 +117,33 @@ static int davinci_wdt_ping(struct watchdog_device *wdd)
return 0;
}
+static unsigned int davinci_wdt_get_timeleft(struct watchdog_device *wdd)
+{
+ u64 timer_counter;
+ unsigned long freq;
+ u32 val;
+ struct davinci_wdt_device *davinci_wdt = watchdog_get_drvdata(wdd);
+
+ /* if timeout is occured then return 0 */
is -> has ?
+ val = ioread32(davinci_wdt->base + WDTCR);
+ if (val & WDFLAG)
+ return 0;
+
+ freq = clk_get_rate(davinci_wdt->clk);
+
+ if (!freq) {
+ dev_err(wdd->dev, "clock freq is not set\n");
+ return 0;
+ }
+
This error check doesn't make sense to me; elsewhere the clock rate is not
validated.
I would suggest to just return 0 here.
+ timer_counter = ioread32(davinci_wdt->base + TIM12);
+ timer_counter |= ((u64)ioread32(davinci_wdt->base + TIM34) << 32);
+
+ do_div(timer_counter, freq);
+
+ return wdd->timeout - timer_counter;
+}
+
static const struct watchdog_info davinci_wdt_info = {
.options = WDIOF_KEEPALIVEPING,
.identity = "DaVinci Watchdog",
@@ -127,6 +154,7 @@ static const struct watchdog_ops davinci_wdt_ops = {
.start = davinci_wdt_start,
.stop = davinci_wdt_ping,
.ping = davinci_wdt_ping,
+ .get_timeleft = davinci_wdt_get_timeleft,
};
static int davinci_wdt_probe(struct platform_device *pdev)
--
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: Fwd: [PATCH 2/8] watchdog: davinci: use davinci_wdt_device structure to hold device data
On 11/06/2013 03:31 AM, ivan.khoronzhuk wrote: Some SoCs, like Keystone 2, can support more than one WDT and each watchdog device has to use it's own base address, clock source, wdd device, so add new davinci_wdt_device structure to hold device data. Signed-off-by: Ivan Khoronzhuk Reviewed-by: Guenter roeck -- 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] sysfs: use a separate locking class for open files depending on mmap
The following two commits implemented mmap support in the regular file
path and merged bin file support into the regular path.
73d9714627ad ("sysfs: copy bin mmap support from fs/sysfs/bin.c to
fs/sysfs/file.c")
3124eb1679b2 ("sysfs: merge regular and bin file handling")
After the merge, the following commands trigger a spurious lockdep
warning. "test-mmap-read" simply mmaps the file and dumps the
content.
$ cat /sys/block/sda/trace/act_mask
$ test-mmap-read /sys/devices/pci\:00/\:00\:03.0/resource0 4096
==
[ INFO: possible circular locking dependency detected ]
3.12.0-work+ #378 Not tainted
---
test-mmap-read/567 is trying to acquire lock:
(>mutex){+.+.+.}, at: [] sysfs_bin_mmap+0x4f/0x120
but task is already holding lock:
(>mmap_sem){++}, at: [] vm_mmap_pgoff+0x49/0xa0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (>mmap_sem){++}:
...
-> #2 (sr_mutex){+.+.+.}:
...
-> #1 (>bd_mutex){+.+.+.}:
...
-> #0 (>mutex){+.+.+.}:
...
other info that might help us debug this:
Chain exists of:
>mutex --> sr_mutex --> >mmap_sem
Possible unsafe locking scenario:
CPU0CPU1
lock(>mmap_sem);
lock(sr_mutex);
lock(>mmap_sem);
lock(>mutex);
*** DEADLOCK ***
1 lock held by test-mmap-read/567:
#0: (>mmap_sem){++}, at: []
vm_mmap_pgoff+0x49/0xa0
stack backtrace:
CPU: 3 PID: 567 Comm: test-mmap-read Not tainted 3.12.0-work+ #378
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
81ed41a0 880009441bc8 81611ad2 81eccb80
880009441c08 8160f215 880009441c60 880009c75208
880009c751e0 880009c75208 880009c74ac0
Call Trace:
[] dump_stack+0x4e/0x7a
[] print_circular_bug+0x2b0/0x2bf
[] __lock_acquire+0x1a3a/0x1e60
[] lock_acquire+0x9a/0x1d0
[] mutex_lock_nested+0x67/0x3f0
[] sysfs_bin_mmap+0x4f/0x120
[] mmap_region+0x3b3/0x5b0
[] do_mmap_pgoff+0x34e/0x3d0
[] vm_mmap_pgoff+0x6a/0xa0
[] SyS_mmap_pgoff+0xbe/0x250
[] SyS_mmap+0x22/0x30
[] system_call_fastpath+0x16/0x1b
This happens because one file nests sr_mutex, which nests mm->mmap_sem
under it, under of->mutex while mmap implementation naturally nests
of->mutex under mm->mmap_sem. The warning is false positive as
of->mutex is per open-file and the two paths belong to two different
files. This warning didn't trigger before regular and bin file
supports were merged because only bin file supported mmap and the
other side of locking happened only on regular files which used
equivalent but separate locking.
It'd be best if we give separate locking classes per file but we can't
easily do that. Let's differentiate on ->mmap() for now. Later we'll
add explicit file operations struct and can add per-ops lockdep key
there.
Signed-off-by: Tejun Heo
Reported-by: Dave Jones
---
fs/sysfs/file.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 79b5da2..b94f936 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -609,7 +609,7 @@ static int sysfs_open_file(struct inode *inode, struct file
*file)
struct sysfs_dirent *attr_sd = file->f_path.dentry->d_fsdata;
struct kobject *kobj = attr_sd->s_parent->s_dir.kobj;
struct sysfs_open_file *of;
- bool has_read, has_write;
+ bool has_read, has_write, has_mmap;
int error = -EACCES;
/* need attr_sd for attr and ops, its parent for kobj */
@@ -621,6 +621,7 @@ static int sysfs_open_file(struct inode *inode, struct file
*file)
has_read = battr->read || battr->mmap;
has_write = battr->write || battr->mmap;
+ has_mmap = battr->mmap;
} else {
const struct sysfs_ops *ops = sysfs_file_ops(attr_sd);
@@ -632,6 +633,7 @@ static int sysfs_open_file(struct inode *inode, struct file
*file)
has_read = ops->show;
has_write = ops->store;
+ has_mmap = false;
}
/* check perms and supported operations */
@@ -649,7 +651,23 @@ static int sysfs_open_file(struct inode *inode, struct
file *file)
if (!of)
goto err_out;
- mutex_init(>mutex);
+ /*
+* The following is done to give a different lockdep key to
+* @of->mutex for files which implement mmap. This is a rather
+* crude way to avoid false positive lockdep warning around
+* mm->mmap_sem - mmap nests @of->mutex under mm->mmap_sem and
+* reading /sys/block/sda/trace/act_mask grabs sr_mutex, under
+* which mm->mmap_sem nests, while holding
Re: xhci_hcd 3.12 regression
Nikolaus Meine tnt.uni-hannover.de> writes:
>
> After upgrading from kernel 3.11 to 3.12 my USB 3.0 card reader
> (Transcend RDF8) stopped working with the same error.
>
> I managed to find the code line which triggered the erroneous behaviour:
>
> It's the definition of the macro xhci_dbg(...) in xhci.h line 1590/1591.
>
> In 3.11 it is
> do { if (XHCI_DEBUG) dev_dbg(...); } while (0)
>
> XHCI_DEBUG is defined as 0 because XHCI_HCD_DEBUGGING is not defined
> so this macro collapses to nothing.
>
> In 3.12 xhci_dbg(...) is defined as
> dev_dbg(...)
> which actually calls dev_printk(...) because DEBUG is defined.
>
> If I define xhci_dbg() in 3.12 as
> do { } while (0)
> my card reader starts working again.
>
> That was the good news.
> The bad news is that I have no idea why calling dev_printk(...)
> does any harm here. Maybe it's a timing problem.
>
> Best Regards
> Nikolaus Meine
>
Hello once again!
I have to correct me previous post:
The card reader does actually work with 3.12 so it's just
the dumping of debug messages which was enabled in 3.12,
no timing problem.
Best Regards
Nikolaus Meine
--
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: [tpmdd-devel] [PATCH 5/5 v2] tpm: Make tpm-dev allocate a per-file structure
On Sun, 2013-11-03 at 20:38 -0700, Jason Gunthorpe wrote: > This consolidates everything that is only used within tpm-dev.c > into tpm-dev.c and out of the publicly visible struct tpm_chip. > > The per-file allocation lays the ground work for someday fixing the > strange forced O_EXCL behaviour of the current code. Reviewed-by: Ashley Lai Acked-by: Ashley Lai Thanks, --Ashley Lai -- 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: xhci_hcd 3.12 regression
M G Berberich oss.m-berberich.de> writes:
>
> Hello,
>
> since 3.12 dmesg (and logfiles) are filled up with:
>
> xhci_hcd :00:14.0: ep 0x81 - asked for 96 bytes, 78 bytes
untransferred
> xhci_hcd :00:14.0: Giveback URB 8807f82ec240, len = 18, expected
= 96, status = -121
> xhci_hcd :00:14.0: Stalled endpoint
> xhci_hcd :00:14.0: Giveback URB 8808181e0240, len = 0, expected
= 13, status = -32
> xhci_hcd :00:14.0: Queueing reset endpoint command
> xhci_hcd :00:14.0: Cleaning up stalled endpoint ring
> xhci_hcd :00:14.0: Finding segment containing stopped TRB.
> xhci_hcd :00:14.0: Finding endpoint context
> xhci_hcd :00:14.0: Finding segment containing last TRB in TD.
> xhci_hcd :00:14.0: Cycle state = 0x0
> xhci_hcd :00:14.0: New dequeue segment = 8808195b4280 (virtual)
> xhci_hcd :00:14.0: New dequeue pointer = 0xfffb2140 (DMA)
> xhci_hcd :00:14.0: Queueing new dequeue state
> xhci_hcd :00:14.0: Set TR Deq Ptr cmd, new deq seg =
8808195b4280 (0xfffb2000 dma), new deq ptr =
> 880816832140 (0xfffb2140 dma), new cycle = 0
> xhci_hcd :00:14.0: // Ding dong!
> xhci_hcd :00:14.0: WARN halted endpoint, queueing URB anyway.
> xhci_hcd :00:14.0: Ignoring reset ep completion code of 1
> xhci_hcd :00:14.0: Successful Set TR Deq Ptr cmd, deq =
fffb2140
>
> blocks, about 25 at a time, every 2 seconds.
> As far as I can tell, this is new with 3.12 (stock) kernel.
>
> System is a i7 4770 on Gigabyte H87-HD3 motherboard, with a IcyBox
> IB-867-B, lshw-output attached.
>
> /proc/version:
> Linux version 3.12.0 (berberic hermione) (gcc version 4.8.2 (Debian
> 4.8.2-1) ) #1 SMP PREEMPT Mon Nov 4 21:20:24 CET 2013
>
> scripts/ver_linux:
> Linux hermione 3.12.0 #1 SMP PREEMPT Mon Nov 4 21:20:24 CET 2013 x86_64
GNU/Linux
>
> Gnu C 4.8
> Gnu make 3.81
> binutils 2.23.90.20131017
> util-linux scripts/ver_linux: 23: scripts/ver_linux:
fdformat: not found
> mount support
> module-init-tools found
> Linux C Library2.17
> Dynamic linker (ldd) 2.17
> Procps 3.3.4
> Kbd1.15.5
> Sh-utils 8.21
> Modules Loaded ppdev lp bnep rfcomm bluetooth vboxpci vboxnetadp
> vboxnetflt vboxdrv kvm_intel kvm cpufreq_powersave
>it87 hwmon_vid coretemp firewire_sbp2 firewire_core
>fuse snd_usb_audio snd_usbmidi_lib snd_seq_midi
> snd_rawmidi pcspkr parport_pc parport
>
> lsusb:
> Bus 002 Device 002: ID 8087:8000 Intel Corp.
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 002: ID 8087:8008 Intel Corp.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 002: ID 05e3:0732 Genesys Logic, Inc.
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 005: ID 08bb:2902 Texas Instruments PCM2902 Audio Codec
> Bus 003 Device 004: ID 0409:005a NEC Corp. HighSpeed Hub
> Bus 003 Device 003: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
> Bus 003 Device 002: ID 03f0:6204 Hewlett-Packard DeskJet 5150c
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> MfG
> bmg
>
Hello!
After upgrading from kernel 3.11 to 3.12 my USB 3.0 card reader
(Transcend RDF8) stopped working with the same error.
I managed to find the code line which triggered the erroneous behaviour:
It's the definition of the macro xhci_dbg(...) in xhci.h line 1590/1591.
In 3.11 it is
do { if (XHCI_DEBUG) dev_dbg(...); } while (0)
XHCI_DEBUG is defined as 0 because XHCI_HCD_DEBUGGING is not defined
so this macro collapses to nothing.
In 3.12 xhci_dbg(...) is defined as
dev_dbg(...)
which actually calls dev_printk(...) because DEBUG is defined.
If I define xhci_dbg() in 3.12 as
do { } while (0)
my card reader starts working again.
That was the good news.
The bad news is that I have no idea why calling dev_printk(...)
does any harm here. Maybe it's a timing problem.
Best Regards
Nikolaus Meine
--
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] A minor amd64_edac fix for 3.13
Linus Torvalds [2013-11-17, 00:52 +0100]: > On Nov 16, 2013 3:34 PM, "Frank Becker" wrote: Hi, > > Blaming the server provider is nonsense. > > BS. :-) Looks like an authentic mail. Who needs crypto-signatures? > If the service provider allows spammers, the service provider is shit. It > really I'd that simple. It isn't black/white and you probably know. E-mail is broken by design. Any attempt to fix it has failed so far. It is abused. I don't defend Hetzner here. Yes, if they made it to be ranked #2 SPAMer on some Web page they have a problem especially considering the fact that they are not #2 in size. I'll tell them that other customers run into a SPAM problem if they don't mitigate that. Still, Google made a mistake by tagging Boris mail as SPAM. As you already wrote it probably was triggered by the content filter. They don't tell. To get those filters right is probably impossible. BTW, I liked your idea to tag propaganda you mentioned in some interview. I'll leave it to this. I've wasted way too much life-time on anti-spam measures already just because I'd like to run my own mail server and can read e-mail without other SPAM^h^h ads around it. The real problem are those fucking parasites aka SPAMers. May they rot in hell. Bye, Frank -- Frank Becker (jabber|mail) signature.asc Description: Digital signature
HI
Hello! My name is Becca Jaclyn from England. I saw your profile today and picked interest to discuss an important business proposal. Please reply to this mail so i can give you more details and also send my photos. Thanks Best regards Becca -- 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: [tpmdd-devel] [PATCH 4/5 v2] tpm: Use the ops structure instead of a copy in tpm_vendor_specific
On Sun, 2013-11-03 at 20:38 -0700, Jason Gunthorpe wrote: > This builds on the last commit to use the ops structure in the core > and reduce the size of tpm_vendor_specific. > > Signed-off-by: Jason Gunthorpe > Reviewed-by: Joel Schopp > --- Reviewed-by: Ashley Lai Acked-by: Ashley Lai Thanks, --Ashley Lai -- 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: [tpmdd-devel] [PATCH 3/5 v2] tpm: Create a tpm_class_ops structure and use it in the drivers
On Sun, 2013-11-03 at 20:38 -0700, Jason Gunthorpe wrote: > This replaces the static initialization of a tpm_vendor_specific > structure in the drivers with the standard Linux idiom of providing > a const structure of function pointers. > > Signed-off-by: Jason Gunthorpe > Reviewed-by: Joel Schopp Reviewed-by: Ashley Lai Acked-by: Ashley Lai Thanks, --Ashley Lai -- 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: [tpmdd-devel] [PATCH 2/5 v2] tpm: Pull everything related to sysfs into tpm-sysfs.c
On Sat, Nov 16, 2013 at 05:53:19PM -0600, Ashley Lai wrote:
> > +/* XXX for now this helper is duplicated in tpm.c */
>
> I think you mean this is duplicated in tpm-interface.c. Is there a
> reason why we cannot add this to tpm.h to avoid this duplication?
Indeed, it was called tpm.c when I wrote it :)
I left it because I think there should be a public API to send a
command that makes sense, and transmit_cmd is not good. But, that can
come later, so lets share them for now.
> > +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd,
> > + int len, const char *desc)
> > +{
>
>
> > +static ssize_t pubek_show(struct device *dev, struct device_attribute
> > *attr,
> > + char *buf)
>
> Most of the functions in this file are moved from tpm-interface.c
> without any modification to the code. Why do we need to change the
> function names in this file? Unless there is a good reason for it
> otherwise I would prefer to keep the same function names.
When I did the sysfs attribute lists in this file I used the modern
sysfs macros:
>> +static DEVICE_ATTR_RO(pubek);
Which are safer to use, but do require the function name to match
the sysfs file name.
So all sysfs functions must be in the form _show.
Jason
--
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-kernel@vger.kernel.org
linux-kernel@vger.kernel.org
Re: [tpmdd-devel] [PATCH 1/5 v2] tpm: Pull everything related to /dev/tpmX into tpm-dev.c
On Sat, Nov 16, 2013 at 04:18:55PM -0600, Ashley Lai wrote:
> Nice clean up!!! The code looks much more clean after removing the
> duplicated code in all drivers. Thanks.
> > +++ b/drivers/char/tpm/tpm-dev.c
> > + * Copyright (C) 2013 Obsidian Reearch Corp
>
> Typo Research?
Yes, thanks :)
> > + * Jason Gunthorpe
> > + *
>
> > +
> > +int tpm_dev_add_device(struct tpm_chip *chip)
> > +{
>
> > + rc = misc_register(>vendor.miscdev);
> > + if (rc) {
> > + chip->vendor.miscdev.name = NULL;
> > + dev_warn(chip->dev,
>
> Any reason why we use dev_warn here instead of dev_err?
Indeed, it was dev_err before I moved it.
Hmm, it has been so long.. I think an earlier draft had
tpm_dev_add_device return void (like in other subsystems), so warn
made more sense. However I eventually changed it to propogate errors,
and didn't catch the flip.
Lets put it back.
Thanks!
Jason
--
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: [tpmdd-devel] [PATCH 2/5 v2] tpm: Pull everything related to sysfs into tpm-sysfs.c
> diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
> new file mode 100644
> index 000..3bcfed0
> --- /dev/null
> +++ b/drivers/char/tpm/tpm-sysfs.c
> @@ -0,0 +1,318 @@
> + * Copyright (C) 2013 Obsidian Reearch Corp
Typo Research?
> + * Jason Gunthorpe
> + *
> +#include "tpm.h"
> +
> +/* XXX for now this helper is duplicated in tpm.c */
I think you mean this is duplicated in tpm-interface.c. Is there a
reason why we cannot add this to tpm.h to avoid this duplication?
> +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd,
> + int len, const char *desc)
> +{
> +static ssize_t pubek_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
Most of the functions in this file are moved from tpm-interface.c
without any modification to the code. Why do we need to change the
function names in this file? Unless there is a good reason for it
otherwise I would prefer to keep the same function names. This is for
easy maintaining (for me at least :)) in case there are issues in the
future and we need to go back we can easily find out where they came
from.
Thanks,
--Ashley Lai
--
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] A minor amd64_edac fix for 3.13
Borislav Petkov [2013-11-16, 19:23 +0100]: > On Sat, Nov 16, 2013 at 10:10:05AM -0800, Linus Torvalds wrote: Hi, > > Ahh. Yes. Googling for "hetzner online spam", and there's a *lot* of > > complaints. See for example > > > > > > http://www.spamrankings.net/rankv2/2013/09/01/monthly/world/volume/cbl/all/regular/ > > Yowza, this is just great! :-( Hetzner provides root servers for money like so many other similar companies. Some folks use that to run their own mail servers for various reasons. Blaming the server provider is nonsense. I've never been in contact with the Hetzner abuse handling. Maybe that could be improved. > > I would suggest everybody who uses hetzner actively drop them, and > > talk publicly about *why* they drop them. Your business may not be all > > that lucrative to them (compared to the spam), but still.. As far as I can see it is Google who filtered the pull request as SPAM by mistake. I'd suggest that everybody who uses Google actively drop them. ;-) But right, I'll open a ticket with Hetzner to ask what they do to shut down SPAMers. Let's see what their FAQ link is. My 2 ct, Frank -- Frank Becker (jabber|mail) signature.asc Description: Digital signature
Re: [PATCH] aio: fix D-cache aliasing issues
On 16-Nov-13, at 5:37 PM, James Bottomley wrote: On Sat, 2013-11-16 at 17:32 -0500, John David Anglin wrote: On 16-Nov-13, at 5:06 PM, James Bottomley wrote: On Sat, 2013-11-16 at 21:07 +0100, Simon Baatz wrote: On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote: On Fri, 2013-11-15 at 23:05 +0100, Helge Deller wrote: When a user page mapping is released via kunmap*() functions, the D-cache needs to be flushed via flush_dcache_page() to avoid D-cache aliasing issues. This patch fixes aio on the parisc platform (and probably others). This should be flush_kernel_dcache_page(). flush_dcache_page() is for full coherency but for unmap, we know the page was coherent going in and may have been modified by the kernel, so only the kernel view needs to be sync'd. Technically, by the kernel API, the flush should be done *before* unmapping. This would have mattered on parisc until we did flush via tmpalias which means we no-longer care if the mapping for the flush exists or not because we always recreate it via the tmpalias pages. On ARM, flush_kernel_dcache_page() actually assumes that the page is mapped. It avoids double flushing of highmem pages by not flushing in those cases where kunmap_atomic() already takes care of flushing. On Parisc, kmap/kunmap is currently a nop. However, if we ever implemented highmem, we would also need to flush before we unmap, which is why the flush needs to go before the kunmap. Not quite. On PA8800/PA8900, we currently do a flush in kunmap. I'm fairly certain from discussion with Helge that he saw this bug on a C8000 with PA8800 processor. In that case, adding a call to flush_kernel_dcache_page() just duplicates the call in kunmap(). Yes, if that's true it won't be the solution. The calls may be needed for the two cases where the page is changed, but I don't know how to avoid double flush on PA8800/PA8900 without changing the primatives. Dave -- John David Anglin dave.ang...@bell.net -- 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] aio: fix D-cache aliasing issues
On 16-Nov-13, at 5:06 PM, James Bottomley wrote: On Sat, 2013-11-16 at 21:07 +0100, Simon Baatz wrote: On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote: On Fri, 2013-11-15 at 23:05 +0100, Helge Deller wrote: When a user page mapping is released via kunmap*() functions, the D-cache needs to be flushed via flush_dcache_page() to avoid D-cache aliasing issues. This patch fixes aio on the parisc platform (and probably others). This should be flush_kernel_dcache_page(). flush_dcache_page() is for full coherency but for unmap, we know the page was coherent going in and may have been modified by the kernel, so only the kernel view needs to be sync'd. Technically, by the kernel API, the flush should be done *before* unmapping. This would have mattered on parisc until we did flush via tmpalias which means we no-longer care if the mapping for the flush exists or not because we always recreate it via the tmpalias pages. On ARM, flush_kernel_dcache_page() actually assumes that the page is mapped. It avoids double flushing of highmem pages by not flushing in those cases where kunmap_atomic() already takes care of flushing. On Parisc, kmap/kunmap is currently a nop. However, if we ever implemented highmem, we would also need to flush before we unmap, which is why the flush needs to go before the kunmap. Not quite. On PA8800/PA8900, we currently do a flush in kunmap. I'm fairly certain from discussion with Helge that he saw this bug on a C8000 with PA8800 processor. In that case, adding a call to flush_kernel_dcache_page() just duplicates the call in kunmap(). Could be wrong though. The problem is the coherence with userspace. That's why flush_dcache_page() is called in several places in this file. I agree with you that this should be done before. I've got to say on all of this, we've implemented the most inane set of primitives. It would be much easier if kmap/kunmap just took care of all of this. kmap should bring userspace into coherence (because why else would we be kmapping) and kunmap should force coherence on the kernel address ... and then no-one would need to worry when to and when not to flush. I'm working on adding a flush to our kmap code to bring userspace into coherence on PA8800/PA8900. It's ugly because it requires looping over vma's as we do in in flush_dcache_page(). Dave -- John David Anglin dave.ang...@bell.net -- 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] aio: fix D-cache aliasing issues
On Sat, 2013-11-16 at 17:32 -0500, John David Anglin wrote: > On 16-Nov-13, at 5:06 PM, James Bottomley wrote: > > > On Sat, 2013-11-16 at 21:07 +0100, Simon Baatz wrote: > >> On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote: > >>> On Fri, 2013-11-15 at 23:05 +0100, Helge Deller wrote: > When a user page mapping is released via kunmap*() functions, the > D-cache needs > to be flushed via flush_dcache_page() to avoid D-cache aliasing > issues. > > This patch fixes aio on the parisc platform (and probably others). > >>> > >>> This should be flush_kernel_dcache_page(). flush_dcache_page() is > >>> for > >>> full coherency but for unmap, we know the page was coherent going > >>> in and > >>> may have been modified by the kernel, so only the kernel view > >>> needs to > >>> be sync'd. Technically, by the kernel API, the flush should be done > >>> *before* unmapping. This would have mattered on parisc until we did > >>> flush via tmpalias which means we no-longer care if the mapping > >>> for the > >>> flush exists or not because we always recreate it via the tmpalias > >>> pages. > >> > >> On ARM, flush_kernel_dcache_page() actually assumes that the page is > >> mapped. It avoids double flushing of highmem pages by not flushing > >> in those cases where kunmap_atomic() already takes care of flushing. > > > > On Parisc, kmap/kunmap is currently a nop. However, if we ever > > implemented highmem, we would also need to flush before we unmap, > > which > > is why the flush needs to go before the kunmap. > > Not quite. On PA8800/PA8900, we currently do a flush in kunmap. > > I'm fairly certain from discussion with Helge that he saw this bug on > a C8000 > with PA8800 processor. In that case, adding a call to > flush_kernel_dcache_page() > just duplicates the call in kunmap(). Yes, if that's true it won't be the solution. > Could be wrong though. > > The problem is the coherence with userspace. That's why > flush_dcache_page() > is called in several places in this file. I agree with you that this > should be done > before. If we need coherence with userspace, we can't do it as we unmap because by then we've used the data in the kernel. We have to do it as we kmap, because that's when we're preparing to use the data. So the solution, if this is the problem, would be flush_dcache_page() just after kmap. James -- 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: [tpmdd-devel] [PATCH 1/5 v2] tpm: Pull everything related to /dev/tpmX into tpm-dev.c
Nice clean up!!! The code looks much more clean after removing the
duplicated code in all drivers. Thanks.
> diff --git a/drivers/char/tpm/tpm-dev.c b/drivers/char/tpm/tpm-dev.c
> new file mode 100644
> index 000..8d94e97
> --- /dev/null
> +++ b/drivers/char/tpm/tpm-dev.c
> + * Copyright (C) 2013 Obsidian Reearch Corp
Typo Research?
> + * Jason Gunthorpe
> + *
> +
> +int tpm_dev_add_device(struct tpm_chip *chip)
> +{
> + rc = misc_register(>vendor.miscdev);
> + if (rc) {
> + chip->vendor.miscdev.name = NULL;
> + dev_warn(chip->dev,
Any reason why we use dev_warn here instead of dev_err?
> + "unable to misc_register %s, minor %d err=%d\n",
> + chip->vendor.miscdev.name,
> + chip->vendor.miscdev.minor, rc);
> + }
> + return rc;
> +}
> +
Reviewed-by: Ashley Lai
Regards,
--Ashley Lai
--
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] aio: fix D-cache aliasing issues
On Sat, 2013-11-16 at 21:07 +0100, Simon Baatz wrote: > On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote: > > On Fri, 2013-11-15 at 23:05 +0100, Helge Deller wrote: > > > When a user page mapping is released via kunmap*() functions, the D-cache > > > needs > > > to be flushed via flush_dcache_page() to avoid D-cache aliasing issues. > > > > > > This patch fixes aio on the parisc platform (and probably others). > > > > This should be flush_kernel_dcache_page(). flush_dcache_page() is for > > full coherency but for unmap, we know the page was coherent going in and > > may have been modified by the kernel, so only the kernel view needs to > > be sync'd. Technically, by the kernel API, the flush should be done > > *before* unmapping. This would have mattered on parisc until we did > > flush via tmpalias which means we no-longer care if the mapping for the > > flush exists or not because we always recreate it via the tmpalias > > pages. > > On ARM, flush_kernel_dcache_page() actually assumes that the page is > mapped. It avoids double flushing of highmem pages by not flushing > in those cases where kunmap_atomic() already takes care of flushing. On Parisc, kmap/kunmap is currently a nop. However, if we ever implemented highmem, we would also need to flush before we unmap, which is why the flush needs to go before the kunmap. I've got to say on all of this, we've implemented the most inane set of primitives. It would be much easier if kmap/kunmap just took care of all of this. kmap should bring userspace into coherence (because why else would we be kmapping) and kunmap should force coherence on the kernel address ... and then no-one would need to worry when to and when not to flush. James -- 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/
[PROBLEM] possible divide by 0 in kernel/sched/cputime.c scale_stime()
Since upgrading from v3.8 to v3.12 I see random crashes in function
scale_stime()
in kernel/sched/cputime.c:
divide error: [#1] SMP
Modules linked in: parport_pc(F) ppdev(F) bnep rfcomm bluetooth
binfmt_misc(F)
zl10353 cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core intel_powerclamp
coretemp
kvm_intel(F) tuner_xc2028 kvm(F) i915 snd_hda_codec_hdmi
snd_hda_codec_realtek
cx8800 cx8802 tuner snd_hda_intel snd_hda_codec cx88_alsa crct10dif_pclmul(F)
crc32_pclmul(F) snd_hwdep(F) snd_pcm(F) snd_page_alloc(F)
ghash_clmulni_intel(F)
aesni_intel(F) snd_seq_midi(F) snd_seq_midi_event(F) snd_rawmidi(F)
snd_seq(F)
joydev(F) cx88xx snd_seq_device(F) snd_timer(F) aes_x86_64(F) lrw(F)
gf128mul(F)
glue_helper(F) video(F) btcx_risc drm_kms_helper ablk_helper(F) tveeprom
cryptd(F)
lp(F) videobuf_dma_sg rc_core drm v4l2_common videobuf_core mei_me parport(F)
snd(F) mei soundcore(F) videodev i2c_algo_bit serio_raw(F) microcode(F)
mac_hid
lpc_ich asus_atk0110 hid_generic usbhid hid usb_storage(F) firewire_ohci
ahci(F)
libahci(F) firewire_core r8169 crc_itu_t(F) mii(F)
CPU: 3 PID: 15367 Comm: htop Tainted: GF3.12.0-031200-generic
#201311031935
Hardware name: System manufacturer System Product Name/P7H55-M PRO, BIOS
170901/04/2011
task: 8800cc09e000 ti: 8800af62 task.ti: 8800af62
RIP: 0010:[] []
cputime_adjust+0xf0/0x110
RSP: 0018:8800af621cc8 EFLAGS: 00010847
RAX: 85fdc1fef4047c00 RBX: RCX: 8800af621df8
RDX: RSI: 8800cc0634d0 RDI:
RBP: 8800af621cd8 R08: fffe R09:
R10: R11: fffe03427acc R12: 8800af621df0
R13: 8800af621df8 R14: R15: 8800cc063300
FS: 7f22a387d740() GS:880117c6() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f22a3892000 CR3: 97023000 CR4: 07e0
Stack:
8800c37f 8800af621df0 8800af621d18 8109aa51
0a7d8c00 42fee100 fffe03427acc 8800bf112a80
8800c37f 8800c307c280 8800af621e50 8121f74b
Call Trace:
[] thread_group_cputime_adjusted+0x41/0x50
[] do_task_stat+0x8eb/0xb60
[] ? vma_compute_subtree_gap+0x50/0x50
[] proc_tgid_stat+0x14/0x20
[] proc_single_show+0x4d/0x90
[] seq_read+0x14e/0x390
[] vfs_read+0x95/0x160
[] SyS_read+0x49/0xa0
[] system_call_fastpath+0x1a/0x1f
Code: 89 fa 49 c1 ea 20 4d 85 d2 74 ca 4c 89 c2 48 d1 ef 49 89 c0 48 d1 ea 48
89 d0 eb 9f 0f 1f 80 00 00 00 00 89 c0 31 d2 49 0f af c0 <48> f7 f7 4c
89 df 48 29 c7 49 89 c3 e9 31 ff ff ff 66 66 66 66
RIP [] cputime_adjust+0xf0/0x110
RSP
---[ end trace dbafd2159a385dd6 ]---
The affected LOC performing the division by 0 was introduced in commit
commit 55eaa7c1f511af5fb6ef808b5328804f4d4e5243
Author: Stanislaw Gruszka
Date: Tue Apr 30 17:14:42 2013 +0200
sched: Avoid cputime scaling overflow
For the problem to occur the function is called eg. with the following
input parameters
stime: 0x3567e00
rtime: 0xbf1abfdb
total: 0x3938700
which leads to 'total' being shifted to 0 during the adaption of the precision
and is then used without further check in
scaled = div_u64((u64) (u32) stime * (u64) (u32) rtime, (u32)total);
The root cause triggering this issue seems to be an overflowed value of
rtime = nsecs_to_cputime(curr->sum_exec_runtime);
On the affected machine the problem can be triggered by loading the
previously idle system by starting a full kernel build. The problem occurs
within a minute after the ondemand frequency scaling governor adjusts the
frequency from the minimum to the maximum.
The x86 init check whether all booted CPUs have their TSC's synchronized, never
failed so far, however, the tsc clocksource is sporadically marked unstable.
Clocksource tsc unstable (delta = -74994678 ns)
The used CPU provides an Intel Invariant TSC as stated by
CPUID.8007H:EDX[8]:
eax ineax ebx ecx edx
000b 756e6547 6c65746e 49656e69
0001 00020652 04100800 0298e3ff bfebfbff
0002 55035a01 00f0b2e3 09ca212c
0003
0004
0005 0040 0040 0003 1120
0006 0005 0002 0001
0007
0008
0009
000a 07300403 0004 0603
000b 002c 0004
8000 8008
8001 0001 28100800
8002 65746e49 2952286c 726f4320 4d542865
8003 35692029 55504320 20202020 20202020
8004 30353620 20402020
[GIT PULL] Please pull NFS client bugfixes
Hi Linus The following changes since commit fab99ebe39fe7d11fbd9b5fb84f07432af9ba36f: NFSv4.2: Remove redundant checks in nfs_setsecurity+nfs4_label_init_security (2013-11-04 16:42:52 -0500) are available in the git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-3.13-2 for you to fetch changes up to 8c2fabc6542d9d0f8b16bd1045c2eda59bdcde13: nfs: fix pnfs Kconfig defaults (2013-11-15 13:41:43 -0500) NFS client bugfixes: - Stable fix for data corruption when retransmitting O_DIRECT writes - Stable fix for a deep recursion/stack overflow bug in rpc_release_client - Stable fix for infinite looping when mounting a NFSv4.x volume - Fix a typo in the nfs mount option parser - Allow pNFS layouts to be compiled into the kernel when NFSv4.1 is Christoph Hellwig (1): nfs: fix pnfs Kconfig defaults Jeff Layton (1): nfs: don't retry detect_trunking with RPC_AUTH_UNIX more than once NeilBrown (1): NFS: correctly report misuse of "migration" mount option. Trond Myklebust (2): SUNRPC: Fix a data corruption issue when retransmitting RPC calls SUNRPC: Avoid deep recursion in rpc_release_client fs/nfs/Kconfig| 6 +++--- fs/nfs/nfs4state.c| 7 ++- fs/nfs/super.c| 2 +- net/sunrpc/clnt.c | 29 + net/sunrpc/xprtsock.c | 28 +--- 5 files changed, 48 insertions(+), 24 deletions(-) -- Trond Myklebust Linux NFS client maintainer NetApp trond.mykleb...@netapp.com www.netapp.com signature.asc Description: This is a digitally signed message part
linux-kernel@vger.kernel.org
[PATCH/RFC] wait_for_completion_timeout() considered harmful.
It would be reasonable to assume that
wait_for_completion_timeout(>auxadc_done, msecs_to_jiffies(5));
would wait at least 5 msecs for the auxadc_done to complete. But it does not.
With a HZ of 200 or less, msecs_to_jiffies(5) has value '1', and so this
will only wait until the next "timer tick", which could happen immediately.
This can lead to incorrect results - and has done so in out-of-tree patches
for drivers/misc/bmp085.c which uses a very similar construct to enable
interrupt
based result collection.
The documentation for several *_timeout* functions claim they will wait for
"timeout jiffies" to have elapsed where this is not the case. They will
actually wait for "timeout" jiffies to have started implying an elapsed time
between (timeout-1) and (timeout).
This patch corrects some of this documentation, and adds a collection of
wait_for_completion*_msecs()
interfaces which wait at least the given number of milliseconds for the
completion (or a signal).
If accepted, we can the see which of the current:
wait_for_completion_timeout-*(..., msecs_to_jiffies(XXX))
could be converted.
Reported-by: "Dr. H. Nikolaus Schaller"
Signed-off-by: NeilBrown
diff --git a/include/linux/completion.h b/include/linux/completion.h
index 5d5aaae3af43..efe92eaf1c45 100644
--- a/include/linux/completion.h
+++ b/include/linux/completion.h
@@ -9,6 +9,7 @@
*/
#include
+#include
/*
* struct completion - structure used to maintain state for a "completion"
@@ -106,4 +107,33 @@ extern bool completion_done(struct completion *x);
extern void complete(struct completion *);
extern void complete_all(struct completion *);
+/* Following wrappers will wait at least 'msecs' milliseconds
+ * unless completion (or signal) happens before then.
+ */
+static inline unsigned long wait_for_completion_msecs(
+ struct completion *x, unsigned long msecs)
+{
+ return wait_for_completion_timeout(x, 1 + msecs_to_jiffies(msecs));
+}
+
+static inline unsigned long wait_for_completion_io_msecs(
+ struct completion *x, unsigned long msecs)
+{
+ return wait_for_completion_io_timeout(x, 1 + msecs_to_jiffies(msecs));
+}
+
+static inline long wait_for_completion_interruptible_msecs(
+ struct completion *x, unsigned long msecs)
+{
+ return wait_for_completion_interruptible_timeout(
+ x, 1 + msecs_to_jiffies(msecs));
+}
+
+static inline long wait_for_completion_killable_msecs(
+ struct completion *x, unsigned long msecs)
+{
+ return wait_for_completion_killable_timeout(
+ x, 1 + msecs_to_jiffies(msecs));
+}
+
#endif
diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c
index a63f4dc27909..b51902373cc0 100644
--- a/kernel/sched/completion.c
+++ b/kernel/sched/completion.c
@@ -126,12 +126,15 @@ EXPORT_SYMBOL(wait_for_completion);
/**
* wait_for_completion_timeout: - waits for completion of a task (w/timeout)
* @x: holds the state of this particular completion
- * @timeout: timeout value in jiffies
+ * @timeout: timeout value in "jiffie starts"
*
* This waits for either a completion of a specific task to be signaled or for
a
* specified timeout to expire. The timeout is in jiffies. It is not
* interruptible.
*
+ * The timeout is in "jiffie starts". It could take between (timeout-1)
+ * and (timeout) jiffies for that many to start.
+ *
* Return: 0 if timed out, and positive (at least 1, or number of jiffies left
* till timeout) if completed.
*/
@@ -159,10 +162,11 @@ EXPORT_SYMBOL(wait_for_completion_io);
/**
* wait_for_completion_io_timeout: - waits for completion of a task (w/timeout)
* @x: holds the state of this particular completion
- * @timeout: timeout value in jiffies
+ * @timeout: timeout value in "jiffie starts"
*
* This waits for either a completion of a specific task to be signaled or for
a
- * specified timeout to expire. The timeout is in jiffies. It is not
+ * specified timeout to expire. The timeout is in "jiffie starts" which implies
+ * a duration between (timeout-1) and (timeout) jiffies. It is not
* interruptible. The caller is accounted as waiting for IO.
*
* Return: 0 if timed out, and positive (at least 1, or number of jiffies left
@@ -196,10 +200,12 @@ EXPORT_SYMBOL(wait_for_completion_interruptible);
/**
* wait_for_completion_interruptible_timeout: - waits for completion
(w/(to,intr))
* @x: holds the state of this particular completion
- * @timeout: timeout value in jiffies
+ * @timeout: timeout value in "jiffie starts"
*
* This waits for either a completion of a specific task to be signaled or for
a
- * specified timeout to expire. It is interruptible. The timeout is in jiffies.
+ * specified timeout to expire. It is interruptible. The timeout is in
+ * "jiffie starts" which implies a duration between (timeout-1) and
+ * (timeout) jiffies.
*
* Return: -ERESTARTSYS if interrupted, 0 if timed out, positive (at least 1,
* or number of jiffies left till
Re: [PATCH 2/2] mm: create a separate slab for page->ptl allocation
On Thu, Nov 7, 2013 at 3:14 PM, Kirill A. Shutemov
wrote:
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> +static inline void pgtable_init(void)
> +{
> + ptlock_cache_init();
> + pgtable_cache_init();
> +}
sparc64defconfig:
include/linux/mm.h:1391:2: error: implicit declaration of function
'pgtable_cache_init' [-Werror=implicit-function-declaration]
arch/sparc/include/asm/pgtable_64.h:978:13: error: conflicting types
for 'pgtable_cache_init' [-Werror]
http://kisskb.ellerman.id.au/kisskb/buildresult/10040274/
Has this been in -next?
Probably it needs .
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] x86/copy_user.S: Remove zero byte check before copy user buffer.
From: Fenghua Yu Operation of rep movsb instruction handles zero byte copy. As pointed out by Linus, there is no need to check zero size in kernel. Removing this redundant check saves a few cycles in copy user functions. Signed-off-by: Fenghua Yu --- arch/x86/lib/copy_user_64.S | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/x86/lib/copy_user_64.S b/arch/x86/lib/copy_user_64.S index a30ca15..ffe4eb9 100644 --- a/arch/x86/lib/copy_user_64.S +++ b/arch/x86/lib/copy_user_64.S @@ -236,8 +236,6 @@ ENDPROC(copy_user_generic_unrolled) ENTRY(copy_user_generic_string) CFI_STARTPROC ASM_STAC - andl %edx,%edx - jz 4f cmpl $8,%edx jb 2f /* less than 8 bytes, go to byte copy loop */ ALIGN_DESTINATION @@ -249,7 +247,7 @@ ENTRY(copy_user_generic_string) 2: movl %edx,%ecx 3: rep movsb -4: xorl %eax,%eax + xorl %eax,%eax ASM_CLAC ret @@ -279,12 +277,10 @@ ENDPROC(copy_user_generic_string) ENTRY(copy_user_enhanced_fast_string) CFI_STARTPROC ASM_STAC - andl %edx,%edx - jz 2f movl %edx,%ecx 1: rep movsb -2: xorl %eax,%eax + xorl %eax,%eax ASM_CLAC ret -- 1.8.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] afs: dir: remove unused label out_skip
The out_skip label is not used, so remove it.
Signed-off-by: Levente Kurusa
---
fs/afs/dir.c |1 -
1 file changed, 1 deletion(-)
diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index 3756d4f..0e10b14 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -669,7 +669,6 @@ static int afs_d_revalidate(struct dentry *dentry, unsigned
int flags)
out_valid:
dentry->d_fsdata = dir_version;
-out_skip:
dput(parent);
key_put(key);
_leave(" = 1 [valid]");
--
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] Fix NX-related Oops in wistron_btns module
The attached patch fixes "kernel tried to execute NX-protected page"
Oops when loading wistron_btns module, occurring since at least 3.4.x;
still applies to Linux 3.12.
--
Jakub Boguszhttp://qboosh.pl/
This patch fixes "kernel tried to execute NX-protected page" oops when
loading winstron-btns module.
Signed-off-by: Jakub Bogusz
--- linux-3.10/drivers/input/misc/wistron_btns.c.orig 2013-11-16
09:05:55.612742472 +0100
+++ linux-3.10/drivers/input/misc/wistron_btns.c2013-11-16
09:24:37.356028732 +0100
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
/* How often we poll keys - msecs */
#define POLL_INTERVAL_DEFAULT 500 /* when idle */
@@ -124,6 +125,7 @@
if (entry_point >= 0xF) {
bios_code_map_base = base;
bios_entry_point = bios_code_map_base + (entry_point & 0x);
+ set_memory_x((unsigned long)bios_code_map_base, 0x1 >>
PAGE_SHIFT);
} else {
iounmap(base);
bios_code_map_base = ioremap(entry_point & ~0x3FFF, 0x4000);
@@ -134,6 +136,7 @@
goto err;
}
bios_entry_point = bios_code_map_base + (entry_point & 0x3FFF);
+ set_memory_x((unsigned long)bios_code_map_base, 0x4000 >>
PAGE_SHIFT);
}
/* The Windows driver maps 0x1 bytes, we keep only one page... */
bios_data_map_base = ioremap(0x400, 0xc00);
Re: Fwd: [PATCH 1/8] watchdog: davinci: change driver to use WDT core
On 11/06/2013 03:31 AM, ivan.khoronzhuk wrote:
To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.
Remove io_lock as the WDT core uses mutex to lock each wdt device.
Remove wdt_state as the WDT core track state with its own variable.
The watchdog_init_timeout() can read timeout value from timeout-sec
property if the passed value is out of bounds. So set initial
heartbeat value more than max value in order to initialize heartbeat
in next way. If heartbeat is not set thought module parameter, try
to read it's value from WDT node timeout-sec property. If node has
no one, use default value.
The heartbeat is hold in wdd->timeout by WDT core, so use it in
order to set timeout period.
Signed-off-by: Ivan Khoronzhuk
---
drivers/watchdog/Kconfig |1 +
drivers/watchdog/davinci_wdt.c | 150 ++--
2 files changed, 38 insertions(+), 113 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index d1d53f3..2c954b5 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -271,6 +271,7 @@ config IOP_WATCHDOG
config DAVINCI_WATCHDOG
tristate "DaVinci watchdog"
depends on ARCH_DAVINCI
+ select WATCHDOG_CORE
help
Say Y here if to include support for the watchdog timer
in the DaVinci DM644x/DM646x processors.
diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
index bead774..a6eef71 100644
--- a/drivers/watchdog/davinci_wdt.c
+++ b/drivers/watchdog/davinci_wdt.c
@@ -3,7 +3,7 @@
*
* Watchdog driver for DaVinci DM644x/DM646x processors
*
- * Copyright (C) 2006 Texas Instruments.
+ * Copyright (C) 2013 Texas Instruments.
2006-2013
*
* 2007 (c) MontaVista Software, Inc. This file is licensed under
* the terms of the GNU General Public License version 2. This program
@@ -15,18 +15,12 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
#include
-#include
-#include
#include
#include
#include
-#include
#include
#define MODULE_NAME "DAVINCI-WDT: "
@@ -61,31 +55,13 @@
#define WDKEY_SEQ0(0xa5c6 << 16)
#define WDKEY_SEQ1(0xda7e << 16)
-static int heartbeat = DEFAULT_HEARTBEAT;
-
-static DEFINE_SPINLOCK(io_lock);
-static unsigned long wdt_status;
-#define WDT_IN_USE0
-#define WDT_OK_TO_CLOSE 1
-#define WDT_REGION_INITED 2
-#define WDT_DEVICE_INITED 3
-
+static int heartbeat = MAX_HEARTBEAT + 1;
Initializing it with 0 (ie not at all) would be just as good. Also see below.
static void __iomem *wdt_base;
struct clk*wdt_clk;
+static struct watchdog_device wdt_wdd;
-static void wdt_service(void)
-{
- spin_lock(_lock);
-
- /* put watchdog in service state */
- iowrite32(WDKEY_SEQ0, wdt_base + WDTCR);
- /* put watchdog in active state */
- iowrite32(WDKEY_SEQ1, wdt_base + WDTCR);
-
- spin_unlock(_lock);
-}
-
-static void wdt_enable(void)
+/* davinci_wdt_start - enable watchdog */
That comment doesn't really provide much value.
+static int davinci_wdt_start(struct watchdog_device *wdd)
{
u32 tgcr;
u32 timer_margin;
@@ -93,8 +69,6 @@ static void wdt_enable(void)
wdt_freq = clk_get_rate(wdt_clk);
- spin_lock(_lock);
-
/* disable, internal clock source */
iowrite32(0, wdt_base + TCR);
/* reset timer, set mode to 64-bit watchdog, and unreset */
@@ -105,9 +79,9 @@ static void wdt_enable(void)
iowrite32(0, wdt_base + TIM12);
iowrite32(0, wdt_base + TIM34);
/* set timeout period */
- timer_margin = (((u64)heartbeat * wdt_freq) & 0x);
+ timer_margin = (((u64)wdd->timeout * wdt_freq) & 0x);
iowrite32(timer_margin, wdt_base + PRD12);
- timer_margin = (((u64)heartbeat * wdt_freq) >> 32);
+ timer_margin = (((u64)wdd->timeout * wdt_freq) >> 32);
iowrite32(timer_margin, wdt_base + PRD34);
/* enable run continuously */
iowrite32(ENAMODE12_PERIODIC, wdt_base + TCR);
@@ -119,84 +93,28 @@ static void wdt_enable(void)
iowrite32(WDKEY_SEQ0 | WDEN, wdt_base + WDTCR);
/* put watchdog in active state */
iowrite32(WDKEY_SEQ1 | WDEN, wdt_base + WDTCR);
-
- spin_unlock(_lock);
-}
-
-static int davinci_wdt_open(struct inode *inode, struct file *file)
-{
- if (test_and_set_bit(WDT_IN_USE, _status))
- return -EBUSY;
-
- wdt_enable();
-
- return nonseekable_open(inode, file);
+ return 0;
}
-static ssize_t
-davinci_wdt_write(struct file *file, const char *data, size_t len,
- loff_t *ppos)
+static int davinci_wdt_ping(struct watchdog_device *wdd)
{
- if (len)
- wdt_service();
-
- return len;
+ /* put watchdog in service state */
+ iowrite32(WDKEY_SEQ0, wdt_base + WDTCR);
+ /* put watchdog in
Re: [PATCH 3/5] cmdline: declare exported symbols immediately
On Sat, Nov 16, 2013 at 2:21 PM, Levente Kurusa wrote: > 2013-11-16 18:32 keltezéssel, Felipe Contreras írta: >> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable >> +EXPORT_SYMBOL(memparse); >> >> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable >> +EXPORT_SYMBOL(get_option); >> >> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable >> +EXPORT_SYMBOL(get_options); >> >> Signed-off-by: Felipe Contreras >> --- >> lib/cmdline.c | 5 ++--- >> 1 file changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/lib/cmdline.c b/lib/cmdline.c >> index 5466333..d4932f7 100644 >> --- a/lib/cmdline.c >> +++ b/lib/cmdline.c >> @@ -67,6 +67,7 @@ int get_option(char **str, int *pint) >> >> return 1; >> } >> +EXPORT_SYMBOL(get_option); >> >> /** >> * get_options - Parse a string into a list of integers >> @@ -112,6 +113,7 @@ char *get_options(const char *str, int nints, int *ints) >> ints[0] = i - 1; >> return (char *)str; >> } >> +EXPORT_SYMBOL(get_options); >> >> /** >> * memparse - parse a string with mem suffixes into a number >> @@ -152,7 +154,4 @@ unsigned long long memparse(const char *ptr, char >> **retptr) >> >> return ret; >> } >> - >> EXPORT_SYMBOL(memparse); >> -EXPORT_SYMBOL(get_option); >> -EXPORT_SYMBOL(get_options); >> > > I don't know about this one, but I have seen lots of files where > EXPORT_SYMBOLs were > listed at the end of the file. To avoid misunderstanding, I still think that > having the > exports after the function is more appropriate. If that was appropriate then checkpatch should be updated to remove that warning, but presumably it's desirable to have them one next to the other. -- Felipe Contreras -- 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] panic: setup panic_timeout early
2013-11-16 19:46 keltezéssel, Felipe Contreras írta: > On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar wrote: >> * Felipe Contreras wrote: > >> Anyway, the fact that you are argumentative even with Linus gives me >> little hope that you will improve your communication patterns with >> _me_, so I'm personally done arguing with you. > > How am I being argumentative? I avoided all arguments. > >>> You don't want to argue? Then don't argue. Apply the patch. [...] >> >> *Plonk*. > > This is exactly the opposite of what is conducive to less argumentation. > > If you are not going to comment on the patch, then don't say anything. > > The patch is good, and the fact that both you and Linus are avoiding > any comments in the patch itself doesn't speak well for your > intentions to avoid argumentation. > > So I ask you again. Do you see something wrong with the patch? > Out-of-joke, the patch is now in an 'appliable' state. You can add my: Reviewed-by: Levente Kurusa -- Regards, Levente Kurusa -- 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 3/5] cmdline: declare exported symbols immediately
2013-11-16 18:32 keltezéssel, Felipe Contreras írta: > WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable > +EXPORT_SYMBOL(memparse); > > WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable > +EXPORT_SYMBOL(get_option); > > WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable > +EXPORT_SYMBOL(get_options); > > Signed-off-by: Felipe Contreras > --- > lib/cmdline.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/lib/cmdline.c b/lib/cmdline.c > index 5466333..d4932f7 100644 > --- a/lib/cmdline.c > +++ b/lib/cmdline.c > @@ -67,6 +67,7 @@ int get_option(char **str, int *pint) > > return 1; > } > +EXPORT_SYMBOL(get_option); > > /** > * get_options - Parse a string into a list of integers > @@ -112,6 +113,7 @@ char *get_options(const char *str, int nints, int *ints) > ints[0] = i - 1; > return (char *)str; > } > +EXPORT_SYMBOL(get_options); > > /** > * memparse - parse a string with mem suffixes into a number > @@ -152,7 +154,4 @@ unsigned long long memparse(const char *ptr, char > **retptr) > > return ret; > } > - > EXPORT_SYMBOL(memparse); > -EXPORT_SYMBOL(get_option); > -EXPORT_SYMBOL(get_options); > I don't know about this one, but I have seen lots of files where EXPORT_SYMBOLs were listed at the end of the file. To avoid misunderstanding, I still think that having the exports after the function is more appropriate. -- Regards, Levente Kurusa -- 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] kstrtox: remove redundant cleanup
2013-11-16 18:32 keltezéssel, Felipe Contreras írta: > We can't reach the cleanup code unless the flag KSTRTOX_OVERFLOW is not > set, so there's not no point in clearing a bit that we know is not set. > > Signed-off-by: Felipe Contreras Acked-by: Levente Kurusa Legit one. To be honest, I don't know who will apply it, because of the stuff discussed earlier. -- Regards, Levente Kurusa -- 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 tip/core/rcu 4/4] documentation: Update circular buffer for load-acquire/store-release
On Sat, Nov 16, 2013 at 05:03:40PM +0100, Peter Zijlstra wrote: > On Fri, Nov 15, 2013 at 04:10:30PM -0800, Paul E. McKenney wrote: > > From: "Paul E. McKenney" > > > > This commit replaces full barriers by targeted use of load-acquire and > > store-release. > > I guess I'd better hurry up merging the patches that introduce these > thingies someplace :-) +1 to that! ;-) Thanx, Paul -- 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] panic: setup panic_timeout early
2013-11-16 19:46 keltezéssel, Felipe Contreras írta: > On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar wrote: >> * Felipe Contreras wrote: > >> Anyway, the fact that you are argumentative even with Linus gives me >> little hope that you will improve your communication patterns with >> _me_, so I'm personally done arguing with you. > > How am I being argumentative? I avoided all arguments. > >>> You don't want to argue? Then don't argue. Apply the patch. [...] >> >> *Plonk*. > > This is exactly the opposite of what is conducive to less argumentation. > > If you are not going to comment on the patch, then don't say anything. > > The patch is good, and the fact that both you and Linus are avoiding > any comments in the patch itself doesn't speak well for your > intentions to avoid argumentation. > > So I ask you again. Do you see something wrong with the patch? > Yes, you. -- Regards, Levente Kurusa -- 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] aio: fix D-cache aliasing issues
On Sat, Nov 16, 2013 at 09:07:18PM +0100, Simon Baatz wrote: > On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote: > > On Fri, 2013-11-15 at 23:05 +0100, Helge Deller wrote: > > > When a user page mapping is released via kunmap*() functions, the D-cache > > > needs > > > to be flushed via flush_dcache_page() to avoid D-cache aliasing issues. > > > > > > This patch fixes aio on the parisc platform (and probably others). > > > > This should be flush_kernel_dcache_page(). flush_dcache_page() is for > > full coherency but for unmap, we know the page was coherent going in and > > may have been modified by the kernel, so only the kernel view needs to > > be sync'd. Technically, by the kernel API, the flush should be done > > *before* unmapping. This would have mattered on parisc until we did > > flush via tmpalias which means we no-longer care if the mapping for the > > flush exists or not because we always recreate it via the tmpalias > > pages. > > On ARM, flush_kernel_dcache_page() actually assumes that the page is > mapped. It avoids double flushing of highmem pages by not flushing > in those cases where kunmap_atomic() already takes care of flushing. Helge -- are you going to resubmit a version of this patch that makes the recommended change? -ben > > > - Simon -- "Thought is the essence of where you are now." -- 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] of: remove /proc/device-tree
On Thu, Mar 21, 2013 at 1:36 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2013-03-21 at 08:16 +, Grant Likely wrote:
>> On Thu, Mar 21, 2013 at 7:43 AM, Benjamin Herrenschmidt
>> wrote:
>> > On Thu, 2013-03-21 at 07:35 +, Grant Likely wrote:
>> >> > Shouldn't we have the symlink just be a config option itself ?
>> >> > Eventually distros might want get rid of it completely ..
>> >>
>> >> Why? It is the cheapest thing in the world and it means the ABI
>> >> doesn't change at all.
>> >
>> > It's also gross and forces sysfs to remain in /sys which isn't a kernel
>> > enforced policy afaik.
>>
>> Documentation/sysfs-rules.txt, Line 30
>
> Whatever... it's still gross :-)
Even Android mounts it there ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] aio: fix D-cache aliasing issues
On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote: > On Fri, 2013-11-15 at 23:05 +0100, Helge Deller wrote: > > When a user page mapping is released via kunmap*() functions, the D-cache > > needs > > to be flushed via flush_dcache_page() to avoid D-cache aliasing issues. > > > > This patch fixes aio on the parisc platform (and probably others). > > This should be flush_kernel_dcache_page(). flush_dcache_page() is for > full coherency but for unmap, we know the page was coherent going in and > may have been modified by the kernel, so only the kernel view needs to > be sync'd. Technically, by the kernel API, the flush should be done > *before* unmapping. This would have mattered on parisc until we did > flush via tmpalias which means we no-longer care if the mapping for the > flush exists or not because we always recreate it via the tmpalias > pages. On ARM, flush_kernel_dcache_page() actually assumes that the page is mapped. It avoids double flushing of highmem pages by not flushing in those cases where kunmap_atomic() already takes care of flushing. - Simon -- 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/40] staging/lustre/llite: Access to released file trigs a restore
On Sat, Nov 16, 2013 at 10:36:18AM +, Dilger, Andreas wrote: > >So, sorry, I have to stop here at this series. I've applied the first 3 > >to the opw-next branch of staging.git so they can live somewhere until > >3.13-rc1 is out. > > > >I know you spent a lot of time making these 120 patches to send me, but > >that too is crazy. You shouldn't wait that long to get feedback and > >send patches to me at all. Please send them in smaller series, with > >less time between patch submissions. > > The reason that there are so many patches in a burst is that we are also > developing new features and fixing bugs in parallel with the kernel, but > they also need to be tested a lot before they are released. It's not any > different from kernel patches testing on -next or -mm for a few months > before they are pushed to the mainline kernel in a batch. It's very different in that you are expecting me to suddenly accept this huge burst of patches all at once, and I can't review them properly. As this patch series shows, there was a problem in the 4rd patch in a 100+ series, which means that I couldn't take them all. So you wasted a bunch of work preparing those other 96 patches. Send them to me in short chunks, that way you don't waste time, and you don't take so long between patch acceptance. > The out-of-tree development can't really stop for a year while the kernel > client code is cleaned up. If the feature patches don't land into the > kernel client for a year (or however long it takes to do all the cleanup), > then it will become outdated and the whole reason for adding the client > into the kernel is lost. But you understand my hesitation at taking any new features when there really has not been any attempt by your team to do much cleanup and fixes of the code at all, right? It feels like I have done more cleanup personally than anyone on your teams, is this not true? So, why would I believe that you all are really going to start doing the major cleanup work on this code that is so obviously needed? Why would I take new features that you are spending your time on instead? > >> There are many users of the external tree so we cannot just abandon > >> it, especially that the upstream client is not shipped in any > >> distribution yet. Thanks for your understanding. > > > >What is keeping people using that tree? Support for older/distro > >kernels? > > > > Support for distro kernels is a big part of it. Most HPC sites use vendor > kernels of various vintages, and we need to keep the code working for those > sites. We also need to continue developing features needed by ever-larger > clusters, fixing bugs, etc. Eventually, when Lustre is in the kernel > proper, > it will also be available in future distro kernels and we can eventually > stop supporting the out-of-tree code. I expect that to be 3+ years away. So, originally you said it would take about a year to get this out of staging. It's been 6 months already with no real progress made with the exception of having interns do cleanup and me doing some basic wrapper function removals. What's the plan for the next 6 months? Based on these 100+ patches, I don't see any major changes that are happening to get this cleaned up properly (or did I miss those patches in this huge patchbomb?) > >Is it the fact that the server code isn't in the kernel? > > Not really. Lustre servers are on separate servers with vendor kernels > (ancient by your standards), and there isn't really any demand for > using newer kernels on those nodes. Most importantly, the out-of-tree > branch is where all of the new feature development is being done. That > also means if feature patches don't land into the kernel it just makes > the kernel version less attractive for users. > > > Should that be added now too so that we can get a proper view of what > > can and can not be changed? Some of your patches are showing that things > > are shared by the two chunks of code, so does that mean if I delete > >things in the client code that don't look to be used by anything, you > > will have problems because the server now breaks? > > Adding the server code to staging would mean another 150kLOC in staging. > We also haven't cleaned that code up even nearly as much as the client > code, so it isn't really even ready to go into staging either. I don't > think you or anyone else would be happy to see that code yet, so I don't > think there is a real advantage to do so. > > Deleting unused code in the kernel client isn't fatal, since we'll > still have the out-of-tree version, but we're trying to keep the code in > sync as much as possible so that it is easier to port patches in both > directions. If code is deleted it means more that needs to be added > back later when the server eventually does get merged, and more effort > to resolve patch conflicts. But look at the function that caused this original question to be asked. You want an api change that I would never
[PATCH 0/3] get/set_dumpable() cleanups and theoretical fix
On 11/15, Kees Cook wrote: > > On Fri, Nov 15, 2013 at 12:36 PM, Oleg Nesterov wrote: > > > > unless I missed something, this is the fix, not cleanup ? > > > > If commit_creds()->set_dumpable(SUID_DUMP_ROOT) races with > > sys_prctl()->set_dumpable(SUID_DUMP_DISABLE), we can get > > SUID_DUMP_USER afaics. > > > > Yes, yes, even if I am right this race is very unlikely. > > Hm, yes, that is a fix then. I struggle to imagine it being > exploitable (i.e. control over both threads, one at least already with > a different cred, etc), but it certainly does look like a bug. Yes, yes, sure, this is only theoretical. OK, I am sending the patches to lkml. I didn't dare to keep your ack, please review v2 (v1 confused bit-mask with bit-number, and in theory we need ACCESS_ONCE). It would be really nice if someone can ack the "it is safe to mix bitops and cmpxchg" assumption mentioned in the changelog. Alex, Josh, this also partly reverts 179899fd5dc780fe "coredump: update coredump-related headers", I think fs/coredump.h buys nothing. Oleg. fs/coredump.c |1 - fs/coredump.h |6 - fs/exec.c | 61 + include/linux/sched.h | 25 ++- 4 files changed, 24 insertions(+), 69 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-kernel@vger.kernel.org
linux-kernel@vger.kernel.org
linux-kernel@vger.kernel.org
[PATCH 1/3] set_dumpable: fix the theoretical race with itself
set_dumpable() updates MMF_DUMPABLE_MASK in a non-trivial way to
ensure that get_dumpable() can't observe the intermediate state,
but this all can't help if multiple threads call set_dumpable()
at the same time.
And in theory commit_creds()->set_dumpable(SUID_DUMP_ROOT) racing
with sys_prctl()->set_dumpable(SUID_DUMP_DISABLE) can result in
SUID_DUMP_USER.
Change this code to update both bits atomically via cmpxchg().
Note: this assumes that it is safe to mix bitops and cmpxchg. IOW,
if, say, an architecture implements cmpxchg() using the locking
(like arch/parisc/lib/bitops.c does), then it should use the same
locks for set_bit/etc.
Signed-off-by: Oleg Nesterov
---
fs/exec.c | 49 +++--
1 files changed, 15 insertions(+), 34 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index bb8afc1..613c9dc 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1621,43 +1621,24 @@ EXPORT_SYMBOL(set_binfmt);
/*
* set_dumpable converts traditional three-value dumpable to two flags and
- * stores them into mm->flags. It modifies lower two bits of mm->flags, but
- * these bits are not changed atomically. So get_dumpable can observe the
- * intermediate state. To avoid doing unexpected behavior, get get_dumpable
- * return either old dumpable or new one by paying attention to the order of
- * modifying the bits.
- *
- * dumpable | mm->flags (binary)
- * old new | initial interim final
- * -+---
- * 01 | 00 01 01
- * 02 | 00 10(*) 11
- * 10 | 01 00 00
- * 12 | 01 11 11
- * 20 | 11 10(*) 00
- * 21 | 11 11 01
- *
- * (*) get_dumpable regards interim value of 10 as 11.
+ * stores them into mm->flags.
*/
void set_dumpable(struct mm_struct *mm, int value)
{
- switch (value) {
- case SUID_DUMP_DISABLE:
- clear_bit(MMF_DUMPABLE, >flags);
- smp_wmb();
- clear_bit(MMF_DUMP_SECURELY, >flags);
- break;
- case SUID_DUMP_USER:
- set_bit(MMF_DUMPABLE, >flags);
- smp_wmb();
- clear_bit(MMF_DUMP_SECURELY, >flags);
- break;
- case SUID_DUMP_ROOT:
- set_bit(MMF_DUMP_SECURELY, >flags);
- smp_wmb();
- set_bit(MMF_DUMPABLE, >flags);
- break;
- }
+ unsigned long old, new;
+
+ do {
+ old = ACCESS_ONCE(mm->flags);
+ new = old & ~MMF_DUMPABLE_MASK;
+
+ switch (value) {
+ case SUID_DUMP_ROOT:
+ new |= (1 << MMF_DUMP_SECURELY);
+ case SUID_DUMP_USER:
+ new |= (1<< MMF_DUMPABLE);
+ }
+
+ } while (cmpxchg(>flags, old, new) != old);
}
int __get_dumpable(unsigned long mm_flags)
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] kill MMF_DUMPABLE and MMF_DUMP_SECURELY
Nobody actually needs MMF_DUMPABLE/MMF_DUMP_SECURELY, there
are only used to enforce the encoding of SUID_DUMP_* enum in
mm->flags & MMF_DUMPABLE_MASK.
Now that set_dumpable() updates both bits atomically we can
kill them and simply store the value "as is" in 2 lower bits.
Signed-off-by: Oleg Nesterov
---
fs/exec.c | 18 +++---
include/linux/sched.h |4 +---
2 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 613c9dc..5303005 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1620,8 +1620,7 @@ void set_binfmt(struct linux_binfmt *new)
EXPORT_SYMBOL(set_binfmt);
/*
- * set_dumpable converts traditional three-value dumpable to two flags and
- * stores them into mm->flags.
+ * set_dumpable stores three-value SUID_DUMP_* into mm->flags.
*/
void set_dumpable(struct mm_struct *mm, int value)
{
@@ -1629,24 +1628,13 @@ void set_dumpable(struct mm_struct *mm, int value)
do {
old = ACCESS_ONCE(mm->flags);
- new = old & ~MMF_DUMPABLE_MASK;
-
- switch (value) {
- case SUID_DUMP_ROOT:
- new |= (1 << MMF_DUMP_SECURELY);
- case SUID_DUMP_USER:
- new |= (1<< MMF_DUMPABLE);
- }
-
+ new = (old & ~MMF_DUMPABLE_MASK) | value;
} while (cmpxchg(>flags, old, new) != old);
}
int __get_dumpable(unsigned long mm_flags)
{
- int ret;
-
- ret = mm_flags & MMF_DUMPABLE_MASK;
- return (ret > SUID_DUMP_USER) ? SUID_DUMP_ROOT : ret;
+ return mm_flags & MMF_DUMPABLE_MASK;
}
/*
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 838a3d9..828c00d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -326,10 +326,8 @@ extern int get_dumpable(struct mm_struct *mm);
#define SUID_DUMP_ROOT 2 /* Dump as root */
/* mm flags */
-/* dumpable bits */
-#define MMF_DUMPABLE 0 /* core dump is permitted */
-#define MMF_DUMP_SECURELY 1 /* core file is readable only by root */
+/* for SUID_DUMP_* above */
#define MMF_DUMPABLE_BITS 2
#define MMF_DUMPABLE_MASK ((1 << MMF_DUMPABLE_BITS) - 1)
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] make __get_dumpable/get_dumpable inline, kill fs/coredump.h
1. Remove fs/coredump.h. It is not clear why do we need it,
it only declares __get_dumpable(), signal.c includes it
for no reason.
2. Now that get_dumpable() and __get_dumpable() are really
trivial make them inline in linux/sched.h.
Signed-off-by: Oleg Nesterov
---
fs/coredump.c |1 -
fs/coredump.h |6 --
fs/exec.c | 18 --
include/linux/sched.h | 21 +
4 files changed, 17 insertions(+), 29 deletions(-)
delete mode 100644 fs/coredump.h
diff --git a/fs/coredump.c b/fs/coredump.c
index 9bdeca1..4bc92c7 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -40,7 +40,6 @@
#include
#include "internal.h"
-#include "coredump.h"
#include
diff --git a/fs/coredump.h b/fs/coredump.h
deleted file mode 100644
index e39ff07..000
--- a/fs/coredump.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef _FS_COREDUMP_H
-#define _FS_COREDUMP_H
-
-extern int __get_dumpable(unsigned long mm_flags);
-
-#endif
diff --git a/fs/exec.c b/fs/exec.c
index 5303005..2196ef5 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -62,7 +62,6 @@
#include
#include "internal.h"
-#include "coredump.h"
#include
@@ -1616,7 +1615,6 @@ void set_binfmt(struct linux_binfmt *new)
if (new)
__module_get(new->module);
}
-
EXPORT_SYMBOL(set_binfmt);
/*
@@ -1632,22 +1630,6 @@ void set_dumpable(struct mm_struct *mm, int value)
} while (cmpxchg(>flags, old, new) != old);
}
-int __get_dumpable(unsigned long mm_flags)
-{
- return mm_flags & MMF_DUMPABLE_MASK;
-}
-
-/*
- * This returns the actual value of the suid_dumpable flag. For things
- * that are using this for checking for privilege transitions, it must
- * test against SUID_DUMP_USER rather than treating it as a boolean
- * value.
- */
-int get_dumpable(struct mm_struct *mm)
-{
- return __get_dumpable(mm->flags);
-}
-
SYSCALL_DEFINE3(execve,
const char __user *, filename,
const char __user *const __user *, argv,
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 828c00d..34c1903 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -317,10 +317,6 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned
long addr,
static inline void arch_pick_mmap_layout(struct mm_struct *mm) {}
#endif
-
-extern void set_dumpable(struct mm_struct *mm, int value);
-extern int get_dumpable(struct mm_struct *mm);
-
#define SUID_DUMP_DISABLE 0 /* No setuid dumping */
#define SUID_DUMP_USER 1 /* Dump as user of process */
#define SUID_DUMP_ROOT 2 /* Dump as root */
@@ -331,6 +327,23 @@ extern int get_dumpable(struct mm_struct *mm);
#define MMF_DUMPABLE_BITS 2
#define MMF_DUMPABLE_MASK ((1 << MMF_DUMPABLE_BITS) - 1)
+extern void set_dumpable(struct mm_struct *mm, int value);
+/*
+ * This returns the actual value of the suid_dumpable flag. For things
+ * that are using this for checking for privilege transitions, it must
+ * test against SUID_DUMP_USER rather than treating it as a boolean
+ * value.
+ */
+static inline int __get_dumpable(unsigned long mm_flags)
+{
+ return mm_flags & MMF_DUMPABLE_MASK;
+}
+
+static inline int get_dumpable(struct mm_struct *mm)
+{
+ return __get_dumpable(mm->flags);
+}
+
/* coredump filter bits */
#define MMF_DUMP_ANON_PRIVATE 2
#define MMF_DUMP_ANON_SHARED 3
--
1.5.5.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] panic: setup panic_timeout early
On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar wrote: > * Felipe Contreras wrote: > Anyway, the fact that you are argumentative even with Linus gives me > little hope that you will improve your communication patterns with > _me_, so I'm personally done arguing with you. How am I being argumentative? I avoided all arguments. >> You don't want to argue? Then don't argue. Apply the patch. [...] > > *Plonk*. This is exactly the opposite of what is conducive to less argumentation. If you are not going to comment on the patch, then don't say anything. The patch is good, and the fact that both you and Linus are avoiding any comments in the patch itself doesn't speak well for your intentions to avoid argumentation. So I ask you again. Do you see something wrong with the patch? -- Felipe Contreras -- 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] A minor amd64_edac fix for 3.13
On Sat, Nov 16, 2013 at 10:10:05AM -0800, Linus Torvalds wrote: > Ahh. Yes. Googling for "hetzner online spam", and there's a *lot* of > complaints. See for example > > > http://www.spamrankings.net/rankv2/2013/09/01/monthly/world/volume/cbl/all/regular/ Yowza, this is just great! :-( > which puts it #2 _worldwide_ in September. I have no idea how accurate > that is, but.. And they were #3 in August. So a steady rise ... > I would suggest everybody who uses hetzner actively drop them, and > talk publicly about *why* they drop them. Your business may not be all > that lucrative to them (compared to the spam), but still.. Yeah, I hear they're not that great otherwise either, regardless of how they handle (or not) spam. @Frank, we need to have a serious talk, you and I :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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] A minor amd64_edac fix for 3.13
On Sat, Nov 16, 2013 at 3:12 AM, Borislav Petkov wrote: > On Sat, Nov 16, 2013 at 02:50:49AM -0800, Linus Torvalds wrote: > >> The most common reason seems to be that your email provide is >> associated with spam, sometimes just because of a shared ISP. > > Sure, it is one: https://www.hetzner.de/ Ahh. Yes. Googling for "hetzner online spam", and there's a *lot* of complaints. See for example http://www.spamrankings.net/rankv2/2013/09/01/monthly/world/volume/cbl/all/regular/ which puts it #2 _worldwide_ in September. I have no idea how accurate that is, but.. I would suggest everybody who uses hetzner actively drop them, and talk publicly about *why* they drop them. Your business may not be all that lucrative to them (compared to the spam), but still.. 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 v5 2/3] of/selftest: Add self tests for manipulation of properties
Hi Grant,
On Nov 15, 2013, at 7:46 PM, Grant Likely wrote:
> Adds a few simple test cases to ensure that addition, update and removal
> of device tree node properties works correctly.
>
> Signed-off-by: Grant Likely
> Cc: Rob Herring
> Cc: Benjamin Herrenschmidt
> Cc: David S. Miller
> Cc: Nathan Fontenot
> Cc: Pantelis Antoniou
> ---
> drivers/of/selftest.c | 62 +++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
> index e21012bde639..cb8d3e722f76 100644
> --- a/drivers/of/selftest.c
> +++ b/drivers/of/selftest.c
> @@ -30,6 +30,67 @@ static struct selftest_results {
> } \
> }
>
> +static void __init of_selftest_dynamic(void)
> +{
> + struct device_node *np;
> + struct property *prop;
> +
> + np = of_find_node_by_path("/testcase-data");
> + if (!np) {
> + pr_err("missing testcase data\n");
> + return;
> + }
> +
> + /* Array of 4 properties for the purpose of testing */
> + prop = kzalloc(sizeof(*prop) * 4, GFP_KERNEL);
> + if (!prop) {
> + selftest(0, "kzalloc() failed\n");
> + return;
> + }
> +
> + /* Add a new property - should pass*/
> + prop->name = "new-property";
> + prop->value = "new-property-data";
> + prop->length = strlen(prop->value);
> + selftest(of_add_property(np, prop) == 0, "Adding a new property
> failed\n");
> +
> + /* Try to add an existing property - should fail */
> + prop++;
> + prop->name = "new-property";
> + prop->value = "new-property-data-should-fail";
> + prop->length = strlen(prop->value);
> + selftest(of_add_property(np, prop) != 0,
> + "Adding an existing property should have failed\n");
> +
> + /* Try to modify an existing property - should pass */
> + prop->value = "modify-property-data-should-pass";
> + prop->length = strlen(prop->value);
> + selftest(of_update_property(np, prop) == 0,
> + "Updating an existing property should have passed\n");
> +
> + /* Try to modify non-existent property - should pass*/
> + prop++;
> + prop->name = "modify-property";
> + prop->value = "modify-missing-property-data-should-pass";
> + prop->length = strlen(prop->value);
> + selftest(of_update_property(np, prop) == 0,
> + "Updating a missing property should have passed\n");
> +
> + /* Remove property - should pass */
> + selftest(of_remove_property(np, prop) == 0,
> + "Removing a property should have passed\n");
> +
> + /* Adding very large property - should pass */
> + prop++;
> + prop->name = "large-property-PAGE_SIZEx8";
> + prop->length = PAGE_SIZE * 8;
> + prop->value = kzalloc(prop->length, GFP_KERNEL);
> + selftest(prop->value != NULL, "Unable to allocate large buffer\n");
> + if (prop->value)
> + selftest(of_add_property(np, prop) == 0,
> + "Adding a large property should have passed\n");
> +}
> +
> static void __init of_selftest_parse_phandle_with_args(void)
> {
> struct device_node *np;
> @@ -312,6 +373,7 @@ static int __init of_selftest(void)
> of_node_put(np);
>
> pr_info("start of selftest - you will see error messages\n");
> + of_selftest_dynamic();
> of_selftest_parse_phandle_with_args();
> of_selftest_property_match_string();
> of_selftest_parse_interrupts();
> --
> 1.8.3.2
>
I like this. I'll add my overlay test cases somewhere around here.
I might need to introduce some new helper functions in order to generate
the overlay completely programmatically.
Regards
-- Pantelis
--
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] panic: setup panic_timeout early
* Felipe Contreras wrote: > On Fri, Nov 15, 2013 at 2:15 PM, Linus Torvalds > wrote: > > On Fri, Nov 15, 2013 at 12:10 PM, Felipe Contreras > > wrote: > >> > >> I haven't seen a single complaint about this commit message, so I > >> don't see what is your point. > > > > My point is that I have sixteen pointless messages in my mbox, > > half of which are due to just your argumentative nature. > > This is clearly not the point you were making, but I won't argue > why. That was exactly the point Linus was making. Anyway, the fact that you are argumentative even with Linus gives me little hope that you will improve your communication patterns with _me_, so I'm personally done arguing with you. > You don't want to argue? Then don't argue. Apply the patch. [...] *Plonk*. 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/
[PATCH 4/5] kstrtox: remove redundant casts
The temporary variable is of the same type as the cast, so it's redundant. Signed-off-by: Felipe Contreras --- lib/kstrtox.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/lib/kstrtox.c b/lib/kstrtox.c index ec8da78..649b74b 100644 --- a/lib/kstrtox.c +++ b/lib/kstrtox.c @@ -176,7 +176,7 @@ int _kstrtoul(const char *s, unsigned int base, unsigned long *res) rv = kstrtoull(s, base, ); if (rv < 0) return rv; - if (tmp != (unsigned long long)(unsigned long)tmp) + if (tmp != (unsigned long)tmp) return -ERANGE; *res = tmp; return 0; @@ -192,7 +192,7 @@ int _kstrtol(const char *s, unsigned int base, long *res) rv = kstrtoll(s, base, ); if (rv < 0) return rv; - if (tmp != (long long)(long)tmp) + if (tmp != (long)tmp) return -ERANGE; *res = tmp; return 0; @@ -223,7 +223,7 @@ int kstrtouint(const char *s, unsigned int base, unsigned int *res) rv = kstrtoull(s, base, ); if (rv < 0) return rv; - if (tmp != (unsigned long long)(unsigned int)tmp) + if (tmp != (unsigned int)tmp) return -ERANGE; *res = tmp; return 0; @@ -254,7 +254,7 @@ int kstrtoint(const char *s, unsigned int base, int *res) rv = kstrtoll(s, base, ); if (rv < 0) return rv; - if (tmp != (long long)(int)tmp) + if (tmp != (int)tmp) return -ERANGE; *res = tmp; return 0; @@ -269,7 +269,7 @@ int kstrtou16(const char *s, unsigned int base, u16 *res) rv = kstrtoull(s, base, ); if (rv < 0) return rv; - if (tmp != (unsigned long long)(u16)tmp) + if (tmp != (u16)tmp) return -ERANGE; *res = tmp; return 0; @@ -284,7 +284,7 @@ int kstrtos16(const char *s, unsigned int base, s16 *res) rv = kstrtoll(s, base, ); if (rv < 0) return rv; - if (tmp != (long long)(s16)tmp) + if (tmp != (s16)tmp) return -ERANGE; *res = tmp; return 0; @@ -299,7 +299,7 @@ int kstrtou8(const char *s, unsigned int base, u8 *res) rv = kstrtoull(s, base, ); if (rv < 0) return rv; - if (tmp != (unsigned long long)(u8)tmp) + if (tmp != (u8)tmp) return -ERANGE; *res = tmp; return 0; @@ -314,7 +314,7 @@ int kstrtos8(const char *s, unsigned int base, s8 *res) rv = kstrtoll(s, base, ); if (rv < 0) return rv; - if (tmp != (long long)(s8)tmp) + if (tmp != (s8)tmp) return -ERANGE; *res = tmp; return 0; -- 1.8.4.2+fc1 -- 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/5] cmdline: fix style issues
WARNING: space prohibited between function name and open parenthesis '('
+int get_option (char **str, int *pint)
WARNING: space prohibited between function name and open parenthesis '('
+ *pint = simple_strtol (cur, str, 0);
ERROR: trailing whitespace
+ $
WARNING: please, no spaces at the start of a line
+ $
WARNING: space prohibited between function name and open parenthesis '('
+ res = get_option ((char **), ints + i);
Signed-off-by: Felipe Contreras
---
lib/cmdline.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/cmdline.c b/lib/cmdline.c
index eb67911..5466333 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -49,13 +49,13 @@ static int get_range(char **str, int *pint)
* 3 - hyphen found to denote a range
*/
-int get_option (char **str, int *pint)
+int get_option(char **str, int *pint)
{
char *cur = *str;
if (!cur || !(*cur))
return 0;
- *pint = simple_strtol (cur, str, 0);
+ *pint = simple_strtol(cur, str, 0);
if (cur == *str)
return 0;
if (**str == ',') {
@@ -84,13 +84,13 @@ int get_option (char **str, int *pint)
* the parse to end (typically a null terminator, if @str is
* completely parseable).
*/
-
+
char *get_options(const char *str, int nints, int *ints)
{
int res, i = 1;
while (i < nints) {
- res = get_option ((char **), ints + i);
+ res = get_option((char **), ints + i);
if (res == 0)
break;
if (res == 3) {
@@ -153,7 +153,6 @@ unsigned long long memparse(const char *ptr, char **retptr)
return ret;
}
-
EXPORT_SYMBOL(memparse);
EXPORT_SYMBOL(get_option);
EXPORT_SYMBOL(get_options);
--
1.8.4.2+fc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] cmdline: declare exported symbols immediately
WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable +EXPORT_SYMBOL(memparse); WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable +EXPORT_SYMBOL(get_option); WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable +EXPORT_SYMBOL(get_options); Signed-off-by: Felipe Contreras --- lib/cmdline.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/lib/cmdline.c b/lib/cmdline.c index 5466333..d4932f7 100644 --- a/lib/cmdline.c +++ b/lib/cmdline.c @@ -67,6 +67,7 @@ int get_option(char **str, int *pint) return 1; } +EXPORT_SYMBOL(get_option); /** * get_options - Parse a string into a list of integers @@ -112,6 +113,7 @@ char *get_options(const char *str, int nints, int *ints) ints[0] = i - 1; return (char *)str; } +EXPORT_SYMBOL(get_options); /** * memparse - parse a string with mem suffixes into a number @@ -152,7 +154,4 @@ unsigned long long memparse(const char *ptr, char **retptr) return ret; } - EXPORT_SYMBOL(memparse); -EXPORT_SYMBOL(get_option); -EXPORT_SYMBOL(get_options); -- 1.8.4.2+fc1 -- 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 5/5] params: improve standard definitions
We are repeating the functionality of kstrtol in param_set_long, and the
same for kstrtoint. We can get rid of the extra code by using the right
functions.
Signed-off-by: Felipe Contreras
---
kernel/params.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/kernel/params.c b/kernel/params.c
index c00d5b5..48e1a81 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -227,17 +227,10 @@ int parse_args(const char *doing,
}
/* Lazy bastard, eh? */
-#define STANDARD_PARAM_DEF(name, type, format, tmptype, strtolfn)
\
+#define STANDARD_PARAM_DEF(name, type, format, strtolfn) \
int param_set_##name(const char *val, const struct kernel_param *kp) \
{ \
- tmptype l; \
- int ret;\
- \
- ret = strtolfn(val, 0, ); \
- if (ret < 0 || ((type)l != l)) \
- return ret < 0 ? ret : -EINVAL; \
- *((type *)kp->arg) = l; \
- return 0; \
+ return strtolfn(val, 0, (type *)kp->arg); \
} \
int param_get_##name(char *buffer, const struct kernel_param *kp) \
{ \
@@ -253,13 +246,13 @@ int parse_args(const char *doing,
EXPORT_SYMBOL(param_ops_##name)
-STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", unsigned long, kstrtoul);
-STANDARD_PARAM_DEF(short, short, "%hi", long, kstrtol);
-STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", unsigned long, kstrtoul);
-STANDARD_PARAM_DEF(int, int, "%i", long, kstrtol);
-STANDARD_PARAM_DEF(uint, unsigned int, "%u", unsigned long, kstrtoul);
-STANDARD_PARAM_DEF(long, long, "%li", long, kstrtol);
-STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", unsigned long, kstrtoul);
+STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", kstrtou8);
+STANDARD_PARAM_DEF(short, short, "%hi", kstrtos16);
+STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", kstrtou16);
+STANDARD_PARAM_DEF(int, int, "%i", kstrtoint);
+STANDARD_PARAM_DEF(uint, unsigned int, "%u", kstrtouint);
+STANDARD_PARAM_DEF(long, long, "%li", kstrtol);
+STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", kstrtoul);
int param_set_charp(const char *val, const struct kernel_param *kp)
{
--
1.8.4.2+fc1
--
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/5] kstrtox: remove redundant cleanup
We can't reach the cleanup code unless the flag KSTRTOX_OVERFLOW is not set, so there's not no point in clearing a bit that we know is not set. Signed-off-by: Felipe Contreras --- lib/kstrtox.c | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/kstrtox.c b/lib/kstrtox.c index f78ae0c..ec8da78 100644 --- a/lib/kstrtox.c +++ b/lib/kstrtox.c @@ -92,7 +92,6 @@ static int _kstrtoull(const char *s, unsigned int base, unsigned long long *res) rv = _parse_integer(s, base, &_res); if (rv & KSTRTOX_OVERFLOW) return -ERANGE; - rv &= ~KSTRTOX_OVERFLOW; if (rv == 0) return -EINVAL; s += rv; -- 1.8.4.2+fc1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] Command line related cleanups
Hi, These became apparent in the review process of a new command line parameter. Felipe Contreras (5): kstrtox: remove redundant cleanup cmdline: fix style issues cmdline: declare exported symbols immediately kstrtox: remove redundant casts params: improve standard definitions kernel/params.c | 25 + lib/cmdline.c | 14 ++ lib/kstrtox.c | 17 - 3 files changed, 23 insertions(+), 33 deletions(-) -- 1.8.4.2+fc1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sound fixes for 3.13-rc1
Linus, please pull sound fixes for v3.13-rc1 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-fix-3.13-rc1 The topmost commit is abfe69dd2e313d0c8226ca4a12329e3d829cfd7c sound fixes for 3.13-rc1 Two peaks in diffstat are for the audio EQ init of IDT codecs and the EMU2004 usb mixer addition, both of which are pretty device-specific, so safe to apply. The rest are a bunch of small fixes, most of them are regression fixes. Anssi Hannula (5): ALSA: hda - hdmi: Use TFx channel positions instead of FxH ALSA: usb: Fix wrong mapping of RLC and RRC channels ALSA: hda - hdmi: Add error-checking to some codec reads ALSA: hda - hdmi: Skip out-of-range latency values in AMD ELD generator ALSA: hda - hdmi: Fix wrong baseline length in ATI/AMD generated ELD Brian Austin (1): ASoC: cs42l52: Correct MIC CTL mask Charles Keepax (1): ASoC: wm8997: Correct typo in ISRC mux routes Dan Carpenter (2): ALSA: snd-aoa: two copy and paste bugs ALSA: isa: not allocating enough space David Henningsson (1): ALSA: hda - Fix Line Out automute on Realtek multifunction jacks Nicolin Chen (1): ASoC: wm8962: Turn on regcache_cache_only before disabling regulator Oskar Schirmer (1): ASoC: fsl: imx-pcm-fiq: omit fiq counter to avoid harm in unbalanced situations Richard Fitzgerald (2): ALSA: compress_core: don't return -EBADFD from poll if paused ASoC: arizona: Fix typo in name of EQ coefficient controls Takashi Iwai (9): ALSA: hda - Control SPDIF out pin on MacBookPro 11,2 ALSA: msnd: Avoid duplicated driver name ALSA: hda - Check keep_eapd_on before inv_eapd ALSA: hda - Don't turn off EAPD for headphone on Lenovo N100 ALSA: hda - Control EAPD for Master volume on Lenovo N100 ALSA: hda - Don't clear the power state at snd_hda_codec_reset() ASoC: blackfin: Fix missing break ALSA: pcsp: Fix the order of input device unregistration ALSA: jack: Unregister input device at disconnection Vasily Khoruzhick (1): ALSA: usb-audio: add front jack channel selector for EMU0204 Vitaliy Kulikov (1): ALSA: hda - load EQ params into IDT codec on HP bNB13 systems Wei Yongjun (1): ALSA: sparc: fix missing unlock on error in snd_cs4231_playback_prepare() --- sound/aoa/fabrics/layout.c| 4 +- sound/core/compress_offload.c | 3 +- sound/core/jack.c | 19 +- sound/drivers/pcsp/pcsp.c | 2 +- sound/isa/msnd/msnd_pinnacle.c| 4 +- sound/isa/wavefront/wavefront_synth.c | 2 +- sound/pci/hda/hda_codec.c | 3 - sound/pci/hda/hda_eld.c | 37 ++- sound/pci/hda/hda_generic.c | 4 +- sound/pci/hda/patch_analog.c | 33 ++- sound/pci/hda/patch_cirrus.c | 56 +++- sound/pci/hda/patch_hdmi.c| 11 +- sound/pci/hda/patch_realtek.c | 4 +- sound/pci/hda/patch_sigmatel.c| 532 +- sound/soc/blackfin/bf5xx-i2s.c| 1 + sound/soc/codecs/cs42l52.h| 2 +- sound/soc/codecs/wm5102.c | 8 +- sound/soc/codecs/wm5110.c | 8 +- sound/soc/codecs/wm8962.c | 2 + sound/soc/codecs/wm8997.c | 10 +- sound/soc/fsl/imx-pcm-fiq.c | 29 +- sound/sparc/cs4231.c | 11 +- sound/usb/mixer_quirks.c | 90 ++ sound/usb/stream.c| 4 +- 24 files changed, 803 insertions(+), 76 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 16/23] ASoC: omap: mcbsp, mcpdm, dmic: raw read and write endian fix
At Sat, 16 Nov 2013 18:09:51 +0200, Jarkko Nikula wrote: > > On 11/16/2013 02:01 AM, Taras Kondratiuk wrote: > > From: Victor Kamensky > > > > All OMAP IP blocks expect LE data, but CPU may operate in BE mode. > > Need to use endian neutral functions to read/write h/w registers. > > I.e instead of __raw_read[lw] and __raw_write[lw] functions code > > need to use read[lw]_relaxed and write[lw]_relaxed functions. > > If the first simply reads/writes register, the second will byteswap > > it if host operates in BE mode. > > > > Changes are trivial sed like replacement of __raw_xxx functions > > with xxx_relaxed variant. > > > > Signed-off-by: Victor Kamensky > > Signed-off-by: Taras Kondratiuk > > --- > > sound/soc/omap/mcbsp.c | 12 ++-- > > sound/soc/omap/omap-dmic.c |4 ++-- > > sound/soc/omap/omap-mcpdm.c |4 ++-- > > 3 files changed, 10 insertions(+), 10 deletions(-) > > > Looks ok to me by looking at the _relaxed definitions in > arch/arm/include/asm/io.h. > > Acked-by: Jarkko Nikula > What's the reason to use _relaxed version in all places? I understand this patch is to fix the endianess, so this can be applied as is, as long as the original code works. But, still in general, I wonder how the concurrency is guaranteed by this driver code... thanks, Takashi -- 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] i2c: Fallback to of_node of parent
I have looked through all bus drivers and in most cases they have a corresponding line that could be removed. Although, this patch would break i2c-powermac, because it relies on the fact that of_node stays NULL. Any idea how to handle that? Greetings, Florian On 16.11.2013 17:11, Florian Meier wrote: > Ok, I will try to find all relevant lines. > Where is the best place to document this? > > Greetings, > Florian > > 2013/11/16 Wolfram Sang : >> >>> + if (!dev->of_node && dev->parent) >>> + dev->of_node = dev->parent->of_node; >>> + >> >> That is not enough. Current drivers could then have the assignment >> removed and even more important, this behaviour should be documented. >> >> Regards, >> >>Wolfram >> -- 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 16/23] ASoC: omap: mcbsp, mcpdm, dmic: raw read and write endian fix
On 11/16/2013 02:01 AM, Taras Kondratiuk wrote: > From: Victor Kamensky > > All OMAP IP blocks expect LE data, but CPU may operate in BE mode. > Need to use endian neutral functions to read/write h/w registers. > I.e instead of __raw_read[lw] and __raw_write[lw] functions code > need to use read[lw]_relaxed and write[lw]_relaxed functions. > If the first simply reads/writes register, the second will byteswap > it if host operates in BE mode. > > Changes are trivial sed like replacement of __raw_xxx functions > with xxx_relaxed variant. > > Signed-off-by: Victor Kamensky > Signed-off-by: Taras Kondratiuk > --- > sound/soc/omap/mcbsp.c | 12 ++-- > sound/soc/omap/omap-dmic.c |4 ++-- > sound/soc/omap/omap-mcpdm.c |4 ++-- > 3 files changed, 10 insertions(+), 10 deletions(-) > Looks ok to me by looking at the _relaxed definitions in arch/arm/include/asm/io.h. Acked-by: Jarkko Nikula -- 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: xen drivers fail to link on ARM with v3.12-9888-gf63c482
On Sat, Nov 16, 2013 at 9:56 AM, Josh Boyer wrote:
> Hi All,
>
> The xen-gntalloc, xen-netfront, xen-blkfront, and xen-netback drivers
> fail to link on ARM today with the following error:
>
> ERROR: "phys_to_mach" [drivers/xen/xen-gntalloc.ko] undefined!
> ERROR: "phys_to_mach" [drivers/net/xen-netfront.ko] undefined!
> ERROR: "phys_to_mach" [drivers/net/xen-netback/xen-netback.ko] undefined!
> ERROR: "phys_to_mach" [drivers/block/xen-blkfront.ko] undefined!
>
> This is with Linus' tree as of this morning.
>
> I'm guessing this is because the mfn_to_pfn and pfn_to_mfn functions
> are inlined and reference phys_to_mach directly, and that isn't
> exported to modules. Thoughts?
The patch below seems to fix this, but I'm not sure it's the desired
approach. I added the export for mach_to_phys just in case.
josh
diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index 23732cd..7772fa8 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -27,7 +27,9 @@ struct xen_p2m_entry {
rwlock_t p2m_lock;
struct rb_root phys_to_mach = RB_ROOT;
+EXPORT_SYMBOL_GPL(phys_to_mach);
static struct rb_root mach_to_phys = RB_ROOT;
+EXPORT_SYMBOL_GPL(mach_to_phys);
static int xen_add_phys_to_mach_entry(struct xen_p2m_entry *new)
{
--
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] i2c: Fallback to of_node of parent
Ok, I will try to find all relevant lines. Where is the best place to document this? Greetings, Florian 2013/11/16 Wolfram Sang : > >> + if (!dev->of_node && dev->parent) >> + dev->of_node = dev->parent->of_node; >> + > > That is not enough. Current drivers could then have the assignment > removed and even more important, this behaviour should be documented. > > Regards, > >Wolfram > -- 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] i2c: Fallback to of_node of parent
> + if (!dev->of_node && dev->parent) > + dev->of_node = dev->parent->of_node; > + That is not enough. Current drivers could then have the assignment removed and even more important, this behaviour should be documented. Regards, Wolfram signature.asc Description: Digital signature
Re: [PATCH tip/core/rcu 4/4] documentation: Update circular buffer for load-acquire/store-release
On Fri, Nov 15, 2013 at 04:10:30PM -0800, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > This commit replaces full barriers by targeted use of load-acquire and > store-release. I guess I'd better hurry up merging the patches that introduce these thingies someplace :-) -- 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] autofs4: allow autofs to work outside the initial PID namespace
On 11/15, Andrew Morton wrote:
>
> Enable autofs4 to work in a "container". oz_pgrp is converted from pid_t
> to struct pid and this is stored at mount time based on the "pgrp=" option
> or if the option is missing then the current pgrp.
I don't understand this code, so I am probably wrong. And this is minor
anyway, but...
> @@ -357,7 +358,17 @@ static int autofs_dev_ioctl_setpipefd(st
> mutex_unlock(>wq_mutex);
> return -EBUSY;
> } else {
> - struct file *pipe = fget(pipefd);
> + struct file *pipe;
> +
> + new_pid = get_task_pid(current, PIDTYPE_PGID);
> +
> + if (ns_of_pid(new_pid) != ns_of_pid(sbi->oz_pgrp)) {
> + AUTOFS_WARN("Not allowed to change PID namespace");
> + err = -EINVAL;
> + goto out;
> + }
> +
> + pipe = fget(pipefd);
> if (!pipe) {
> err = -EBADF;
> goto out;
> @@ -367,12 +378,13 @@ static int autofs_dev_ioctl_setpipefd(st
> fput(pipe);
> goto out;
> }
> - sbi->oz_pgrp = task_pgrp_nr(current);
> + swap(sbi->oz_pgrp, new_pid);
> sbi->pipefd = pipefd;
> sbi->pipe = pipe;
> sbi->catatonic = 0;
> }
> out:
> + put_pid(new_pid);
This looks suspicious, put_pid() can actually kfree the old sbi->oz_pgrp
swapped above. IOW, this assumes we can't race with any user of ->oz_pgrp.
For example,
> @@ -80,7 +83,7 @@ static int autofs4_show_options(struct s
> if (!gid_eq(root_inode->i_gid, GLOBAL_ROOT_GID))
> seq_printf(m, ",gid=%u",
> from_kgid_munged(_user_ns, root_inode->i_gid));
> - seq_printf(m, ",pgrp=%d", sbi->oz_pgrp);
> + seq_printf(m, ",pgrp=%d", pid_vnr(sbi->oz_pgrp));
Can't this race with autofs_dev_ioctl_setpipefd() above?
Oleg.
--
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: vmstat: On demand vmstat workers V3
On Thu, Oct 03, 2013 at 05:40:40PM +, Christoph Lameter wrote:
> V2->V3:
> - Introduce a new tick_get_housekeeping_cpu() function. Not sure
> if that is exactly what we want but it is a start. Thomas?
Not really. Thomas suggested an infrastructure to move CPU-local periodic
jobs handling to be offlined to set of remote housekeeping CPU.
This could be potentially useful for many kind of stats relying on
periodic updates, the scheduler tick being a candidate (I have yet to
check if we can really apply that in practice though).
Now the problem is that vmstats updates use pure local lockless
operations. It may be possible to offline this update to remote CPUs
but then we need to convert vmstats updates to use locks. Which is
potentially costly. Unless we can find some clever lockless update
scheme. Do you think this can be possible?
See below for more detailed review:
[...]
>
> /*
> @@ -1213,12 +1229,15 @@ static const struct file_operations proc
> #ifdef CONFIG_SMP
> static DEFINE_PER_CPU(struct delayed_work, vmstat_work);
> int sysctl_stat_interval __read_mostly = HZ;
> +static struct cpumask *monitored_cpus;
>
> static void vmstat_update(struct work_struct *w)
> {
> - refresh_cpu_vm_stats();
> - schedule_delayed_work(&__get_cpu_var(vmstat_work),
> - round_jiffies_relative(sysctl_stat_interval));
> + if (refresh_cpu_vm_stats())
> + schedule_delayed_work(this_cpu_ptr(_work),
> + round_jiffies_relative(sysctl_stat_interval));
> + else
> + cpumask_set_cpu(smp_processor_id(), monitored_cpus);
That looks racy against other CPUs that may set their own bit and also
against the shepherd that clears processed monitored CPUs.
That seem to matter because a CPU could be simply entirely forgotten
by vmstat and never processed again.
> }
>
> static void start_cpu_timer(int cpu)
> @@ -1226,7 +1245,70 @@ static void start_cpu_timer(int cpu)
> struct delayed_work *work = _cpu(vmstat_work, cpu);
>
> INIT_DEFERRABLE_WORK(work, vmstat_update);
> - schedule_delayed_work_on(cpu, work, __round_jiffies_relative(HZ, cpu));
> + schedule_delayed_work_on(cpu, work,
> + __round_jiffies_relative(sysctl_stat_interval, cpu));
> +}
> +
> +/*
> + * Check if the diffs for a certain cpu indicate that
> + * an update is needed.
> + */
> +static bool need_update(int cpu)
> +{
> + struct zone *zone;
> +
> + for_each_populated_zone(zone) {
> + struct per_cpu_pageset *p = per_cpu_ptr(zone->pageset, cpu);
> +
> + /*
> + * The fast way of checking if there are any vmstat diffs.
> + * This works because the diffs are byte sized items.
> + */
> + if (memchr_inv(p->vm_stat_diff, 0, NR_VM_ZONE_STAT_ITEMS))
> + return true;
> + }
> + return false;
> +}
> +
> +static void vmstat_shepherd(struct work_struct *w)
> +{
> + int cpu;
> + int s = tick_get_housekeeping_cpu();
> + struct delayed_work *d = per_cpu_ptr(_work, s);
> +
> + refresh_cpu_vm_stats();
> +
> + for_each_cpu(cpu, monitored_cpus)
> + if (need_update(cpu)) {
> + cpumask_clear_cpu(cpu, monitored_cpus);
> + start_cpu_timer(cpu);
> + }
> +
> + if (s != smp_processor_id()) {
> + /* Timekeeping was moved. Move the shepherd worker */
> + cpumask_set_cpu(smp_processor_id(), monitored_cpus);
> + cpumask_clear_cpu(s, monitored_cpus);
> + cancel_delayed_work_sync(d);
> + INIT_DEFERRABLE_WORK(d, vmstat_shepherd);
> + }
> +
> + schedule_delayed_work_on(s, d,
> + __round_jiffies_relative(sysctl_stat_interval, s));
Note that on dynticks idle (CONFIG_NO_HZ_IDLE=y), the timekeeper CPU can change
quickly and often.
I can imagine a nasty race there: CPU 0 is the timekeeper. It schedules the
vmstat sherpherd work in 2 seconds. But CPU 0 goes to sleep for a big while
and some other CPU takes the timekeeping duty. The shepherd timer won't be
processed until CPU 0 wakes up although we may have CPUs to monitor.
CONFIG_NO_HZ_FULL may work incidentally because CPU 0 is the only timekeeper
there
but this is a temporary limitation. Expect the timekeeper to be dynamic in the
future
under that config.
> +
> +}
> +
> +static void __init start_shepherd_timer(void)
> +{
> + int cpu = tick_get_housekeeping_cpu();
> + struct delayed_work *d = per_cpu_ptr(_work, cpu);
> +
> + INIT_DEFERRABLE_WORK(d, vmstat_shepherd);
> + monitored_cpus = kmalloc(BITS_TO_LONGS(nr_cpu_ids) * sizeof(long),
> + GFP_KERNEL);
> + cpumask_copy(monitored_cpus, cpu_online_mask);
> + cpumask_clear_cpu(cpu, monitored_cpus);
> + schedule_delayed_work_on(cpu, d,
> + __round_jiffies_relative(sysctl_stat_interval, cpu));
> }
So another issue with the whole design of this patch, outside its
Re: [PATCH tip/core/rcu 4/4] documentation: Update circular buffer for load-acquire/store-release
On Sat, Nov 16, 2013 at 11:58:45AM +, David Howells wrote: > Paul E. McKenney wrote: > > > - /* read index before reading contents at that index */ > > > - smp_mb(); /* finish reading descriptor before incrementing tail > > */ > > I'd rather you didn't remove these comments (assuming they're correct) as > they're pointing out the point of the example. Ah, good point! I have added them back just before the smp_load_acquire() and smp_store_release(), as shown below. Does that work? Thanx, Paul diff --git a/Documentation/circular-buffers.txt b/Documentation/circular-buffers.txt index 15e54ff50018..88951b179262 100644 --- a/Documentation/circular-buffers.txt +++ b/Documentation/circular-buffers.txt @@ -200,6 +200,7 @@ The consumer will look something like this: spin_lock(_lock); + /* Read index before reading contents at that index. */ unsigned long head = smp_load_acquire(buffer->head); unsigned long tail = buffer->tail; @@ -210,6 +211,7 @@ The consumer will look something like this: consume_item(item); + /* Finish reading descriptor before incrementing tail. */ smp_store_release(buffer->tail, (tail + 1) & (buffer->size - 1)); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: Fallback to of_node of parent
Many busses (e.g. tegra, omap, bcm2835)
need to set the of_node of the adapter
device to the one of the parent device, i.e.
adap->dev.of_node = pdev->dev.of_node;
As suggested by Stephen Warren, this could also
be done in the i2c core and it is a common mistake
to forget this line:
I2C: BCM2835: Linking platform nodes to adapter nodes
i2c: Fix device tree binding for i2c-cbus-gpio
Signed-off-by: Florian Meier
Suggested-by: Stephen Warren
---
drivers/i2c/i2c-core.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 430c001..c8e33a5 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1310,6 +1310,9 @@ int i2c_add_adapter(struct i2c_adapter *adapter)
struct device *dev = >dev;
int id;
+ if (!dev->of_node && dev->parent)
+ dev->of_node = dev->parent->of_node;
+
if (dev->of_node) {
id = of_alias_get_id(dev->of_node, "i2c");
if (id >= 0) {
--
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 V2] Cpufreq: Make governor data on nonboot cpus across system suspend/resume
Currently, governor of nonboot cpus will be put to EXIT when system suspend.
Since all these cpus will be unplugged and the governor usage_count decreases
to zero. The governor data and its sysfs interfaces will be freed or released.
This makes user config of these governors loss during suspend and resume.
This doesn't happen on the governor covering boot cpu because it isn't
unplugged during system suspend.
To fix this issue, skipping governor exit during system suspend and check
policy governor data to determine whether the governor is really needed
to be initialized when do init. If not, return EALREADY to indicate the
governor has been initialized and should do nothing. __cpufreq_governor()
convert EALREADY to 0 as return value for INIT event since governor is
still under INIT state and can do START operation.
Signed-off-by: Lan Tianyu
---
Change since v1:
Change coding style.
drivers/cpufreq/cpufreq.c | 10 +++---
drivers/cpufreq/cpufreq_governor.c | 13 -
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..73ad593 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1239,7 +1239,7 @@ static int __cpufreq_remove_dev_finish(struct device *dev,
/* If cpu is last user of policy, free policy */
if (cpus == 1) {
- if (has_target()) {
+ if (has_target() && !frozen) {
ret = __cpufreq_governor(policy,
CPUFREQ_GOV_POLICY_EXIT);
if (ret) {
@@ -1818,9 +1818,13 @@ static int __cpufreq_governor(struct cpufreq_policy
*policy,
mutex_unlock(_governor_lock);
}
- if (((event == CPUFREQ_GOV_POLICY_INIT) && ret) ||
- ((event == CPUFREQ_GOV_POLICY_EXIT) && !ret))
+ if ((event == CPUFREQ_GOV_POLICY_INIT) && ret) {
+ module_put(policy->governor->owner);
+ if (ret == -EALREADY)
+ return 0;
+ } else if ((event == CPUFREQ_GOV_POLICY_EXIT) && !ret) {
module_put(policy->governor->owner);
+ }
return ret;
}
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 0806c31..ddb93af 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -204,9 +204,20 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
switch (event) {
case CPUFREQ_GOV_POLICY_INIT:
+ /*
+* In order to keep governor data across suspend/resume,
+* Governor doesn't exit when suspend and will be
+* reinitialized when resume. Here check policy governor
+* data to determine whether the governor has been exited.
+* If not, return EALREADY.
+*/
if (have_governor_per_policy()) {
- WARN_ON(dbs_data);
+ if (dbs_data)
+ return -EALREADY;
} else if (dbs_data) {
+ if (policy->governor_data == dbs_data)
+ return -EALREADY;
+
dbs_data->usage_count++;
policy->governor_data = dbs_data;
return 0;
--
1.8.2.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] power: Change device_wakeup_enable() to check for null dev_name(dev)
On 11/15/2013 05:25 PM, Greg KH wrote: On Fri, Nov 15, 2013 at 05:16:31PM -0700, Shuah Khan wrote: On 11/15/2013 05:21 PM, Rafael J. Wysocki wrote: On Friday, November 15, 2013 05:03:57 PM Shuah Khan wrote: device_wakeup_enable() uses dev_name(dev) as the wakeup source name. When it gets called with a device with its name not yet set, ws structure with ws->name = NULL gets created. When kernel is booted with wakeup_source_activate enabled, it will panic when the trace point code tries to derefernces ws->name. Change device_wakeup_enable() to check for dev_name(dev) null condition and return -EINVAL to avoid panics when device_wakeup_enable() gets called before device is fully initialized with its name. return -EINVAL; Can you please use WARN_ON(!dev_name(dev)) here? While I agree that it is a bad idea to crash the kernel because dev has no name, that indicates a driver bug that shouldn't be too easy to ignore. Thanks! Right. ok I will re-cut the patch with WARN_ON and send it. fyi I did send fix for the driver (power_supply) as well. http://www.kernelhub.org/?msg=362354=2 Why is a driver calling kobject_set_name() instead of device_set_name()? Yes, it's really the same thing deep down, but drivers should never care about a kobject, just 'struct device'. Well, even then it usually should care about it's type of 'struct device' but that's a different issue... Anyway, not saying your patch is wrong at all, just for the future if people are looking for code cleanups... Use of kobject_set_name() did look odd to me. I will fix that for this driver by re-doing the patch while I am it. About the power_supply patch, stable needs fixing as well, and I will have to backport once he fix goes into the mainline. http://www.kernelhub.org/?msg=362354=2 as is doesn't apply to 3.10 and 3.11 -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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: [Update PATCH 1/1] Cpufreq: Make governor data on nonboot cpus across system suspend/resume
On 11/16/2013 10:41 PM, Rafael J. Wysocki wrote:
On Saturday, November 16, 2013 11:59:59 AM Lan Tianyu wrote:
On 11/16/2013 08:38 AM, Rafael J. Wysocki wrote:
On Friday, November 15, 2013 04:15:34 PM Lan Tianyu wrote:
Currently, governor of nonboot cpus will be put to EXIT when system suspend.
Since all these cpus will be unplugged and the governor usage_count decreases
to zero. The governor data and its sysfs interfaces will be freed or released.
This makes user config of these governors loss during suspend and resume.
First off, do we have a pointer to a bug report related to that?
No, I found this bug when I tried to resolve other similar bug.
https://bugzilla.kernel.org/show_bug.cgi?id=63081. I still have no idea
about bug 63081 and asked reporter to try this patch.
Second, what does need to be done to reproduce this problem?
Defaultly, all cpus use ondemand governor after bootup. Change one
non-boot cpu's governor to conservative,
Well, why would anyone want to do that? Just out of curiosity ...
Just use this way to produce the issue. But on the laptop, I think
fewer people will do the same thing. Just like Viresh said, this also
will affect the systems of governor per policy.
modify conservative config via sysfs interface and then do system suspend.
After resume, the config of conservative is reset. On my machine, all cpus
have owen policy.
So this is acpi-cpufreq, right?
Yes, it's acpi-cpufreq driver.
The patch looks basically OK to me, but ->
This doesn't happen on the governor covering boot cpu because it isn't
unplugged during system suspend.
To fix this issue, skipping governor exit during system suspend and check
policy governor data to determine whether the governor is really needed
to be initialized when do init. If not, return EALREADY to indicate the
governor has been initialized and should do nothing. __cpufreq_governor()
convert EALREADY to 0 as return value for INIT event since governor is
still under INIT state and can do START operation.
Signed-off-by: Lan Tianyu
---
Fix some typos
drivers/cpufreq/cpufreq.c | 5 -
drivers/cpufreq/cpufreq_governor.c | 13 -
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..38f2e4a 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1239,7 +1239,7 @@ static int __cpufreq_remove_dev_finish(struct device *dev,
/* If cpu is last user of policy, free policy */
if (cpus == 1) {
- if (has_target()) {
+ if (has_target() && !frozen) {
ret = __cpufreq_governor(policy,
CPUFREQ_GOV_POLICY_EXIT);
if (ret) {
@@ -1822,6 +1822,9 @@ static int __cpufreq_governor(struct cpufreq_policy
*policy,
((event == CPUFREQ_GOV_POLICY_EXIT) && !ret))
module_put(policy->governor->owner);
+ if ((event == CPUFREQ_GOV_POLICY_INIT) && ret == -EALREADY)
+ ret = 0;
+
-> I'd prefer this check to be combined with the one done to determine whether
or not we need to do the module_put(). Something like
if (event == CPUFREQ_GOV_POLICY_EXIT && ret) {
module_put(policy->governor->owner);
if (ret == -EALREADY)
return 0;
} else if (event == CPUFREQ_GOV_POLICY_EXIT && !ret) {
module_put(policy->governor->owner);
}
Ok. I will update soon.
Thanks!
return ret;
}
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 0806c31..ddb93af 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -204,9 +204,20 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
switch (event) {
case CPUFREQ_GOV_POLICY_INIT:
+ /*
+* In order to keep governor data across suspend/resume,
+* Governor doesn't exit when suspend and will be
+* reinitialized when resume. Here check policy governor
+* data to determine whether the governor has been exited.
+* If not, return EALREADY.
+*/
if (have_governor_per_policy()) {
- WARN_ON(dbs_data);
+ if (dbs_data)
+ return -EALREADY;
} else if (dbs_data) {
+ if (policy->governor_data == dbs_data)
+ return -EALREADY;
+
dbs_data->usage_count++;
policy->governor_data = dbs_data;
return 0;
--
Best Regards
Tianyu Lan
--
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
Re: [PATCH tip/core/rcu 11/14] bonding/bond_main: Apply ACCESS_ONCE() to avoid sparse false positive
On Sat, Nov 16, 2013 at 12:32:16PM +0800, Ding Tianhong wrote:
> 于 2013/11/16 8:40, Paul E. McKenney 写道:
> > From: "Paul E. McKenney"
> >
> > The sparse checking for rcu_assign_pointer() was recently upgraded
> > to reject non-__kernel address spaces. This also rejects __rcu,
> > which is almost always the right thing to do. However, the uses in
> > bond_change_active_slave() and __bond_release_one() are legitimate:
> > They are assigning a pointer to an element from an RCU-protected list
> > (or a NULL pointer), and all elements of this list are already visible
> > to caller.
> >
> > This commit therefore silences these false positives either by laundering
> > the pointers using ACCESS_ONCE() as suggested by Eric Dumazet and Josh
> > Triplett, or by using RCU_INIT_POINTER() for NULL pointer assignments.
>
> I think it is fit for net-next.
Thank you!
If this is queued there, I would be happy to drop it from my tree.
There are no dependencies on anything in my tree.
Thanx, Paul
> > Reported-by: kbuild test robot
> > Signed-off-by: Paul E. McKenney
> > Cc: Stephen Hemminger
> > Cc: "David S. Miller"
> > Cc: bri...@lists.linux-foundation.org
> > Cc: net...@vger.kernel.org
> > ---
> > drivers/net/bonding/bond_main.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/bonding/bond_main.c
> > b/drivers/net/bonding/bond_main.c
> > index 72df399c4ab3..bbd7fd3e46fe 100644
> > --- a/drivers/net/bonding/bond_main.c
> > +++ b/drivers/net/bonding/bond_main.c
> > @@ -890,7 +890,8 @@ void bond_change_active_slave(struct bonding *bond,
> > struct slave *new_active)
> > if (new_active)
> > bond_set_slave_active_flags(new_active);
> > } else {
> > - rcu_assign_pointer(bond->curr_active_slave, new_active);
> > + /* Both --rcu and visible, so ACCESS_ONCE() is OK. */
> > + ACCESS_ONCE(bond->curr_active_slave) = new_active;
> > }
> >
> > if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) {
> > @@ -1801,7 +1802,7 @@ static int __bond_release_one(struct net_device
> > *bond_dev,
> > }
> >
> > if (all) {
> > - rcu_assign_pointer(bond->curr_active_slave, NULL);
> > + RCU_INIT_POINTER(bond->curr_active_slave, NULL);
> > } else if (oldcurrent == slave) {
> > /*
> > * Note that we hold RTNL over this sequence, so there
>
--
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/
