Re: [PATCH] mm: cache largest vma
* Davidlohr Bueso wrote:
> I will look into doing the vma cache per thread instead of mm (I hadn't
> really looked at the problem like this) as well as Ingo's suggestion on
> the weighted LRU approach. However, having seen that we can cheaply and
> easily reach around ~70% hit rate in a lot of workloads, makes me wonder
> how good is good enough?
So I think it all really depends on the hit/miss cost difference. It makes
little sense to add a more complex scheme if it washes out most of the
benefits!
Also note the historic context: the _original_ mmap_cache, that I
implemented 16 years ago, was a front-line cache to a linear list walk
over all vmas (!).
This is the relevant 2.1.37pre1 code in include/linux/mm.h:
/* Look up the first VMA which satisfies addr < vm_end, NULL if none. */
static inline struct vm_area_struct * find_vma(struct mm_struct * mm, unsigned
long addr)
{
struct vm_area_struct *vma = NULL;
if (mm) {
/* Check the cache first. */
vma = mm->mmap_cache;
if(!vma || (vma->vm_end <= addr) || (vma->vm_start > addr)) {
vma = mm->mmap;
while(vma && vma->vm_end <= addr)
vma = vma->vm_next;
mm->mmap_cache = vma;
}
}
return vma;
}
See that vma->vm_next iteration? It was awful - but back then most of us
had at most a couple of megs of RAM with just a few vmas. No RAM, no SMP,
no worries - the mm was really simple back then.
Today we have the vma rbtree, which is self-balancing and a lot faster
than your typical linear list walk search ;-)
So I'd _really_ suggest to first examine the assumptions behind the cache,
it being named 'cache' and it having a hit rate does in itself not
guarantee that it gives us any worthwile cost savings when put in front of
an rbtree ...
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
service desk
Mailbox is full, 00.1 GB, Please reduce your mailbox size. Delete any items you don't need from your mailbox and expand your email quota (size) with the below web links: HERE: http://actlogistic.co.uk/ Thank you for your understanding. ©2013 Helpdesk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter
(2013/10/31 22:27), Vivek Goyal wrote: On Wed, Oct 30, 2013 at 06:58:13PM -0600, jerry.hoem...@hp.com wrote: [..] Daisuke, Are you planning on making changes to the kexec tools to automate the setting of disable_cpu_apic to the capture kernel? Or do you know someone who is planning this? I think we should not make this change in kexec-tools and should leave it to distro scripts to append disable_cpu_apic. Who knows in future this restriction is not there at all and kexec-tools will be stuck with always passing disable_cpu_apic. Getting rid of this parameter in distro scripts will be much easier. Thanks Vivek Yes, I'll post the patch to distribution's kexec-tools. ``kexec-tools'' seems a little ambiguous; the users scripts on fedora are contained in the same package. I don't know things on other distributions mostly at all; I've read Ubuntu's scripts really a little bit only. I'd like anyone to post patches if necessary... BTW, what's the status of this patch set? I've redesigned this so as to be done with kernel parameter in order not to depend on platform specific BIOS table. Due to the redesign, I think now ACK is needed again. -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 04/12] phy: Add simple-phy driver
Hi, On Friday 25 October 2013 01:21 PM, Tomasz Stanislawski wrote: Hi, Please refer to the comments below. On 10/24/2013 05:52 PM, Kishon Vijay Abraham I wrote: Hi, On Monday 21 October 2013 07:48 PM, Tomasz Stanislawski wrote: Add simple-phy driver to support a single register PHY interfaces present on Exynos4 SoC. How are these PHY interfaces modelled in the SoC? Where does the register actually reside? Initially, I was planning to add PHY for HDMI_PHY register in power management register set on s5pv310 soc. If that register is part of the power management register space, I don't think it justifies creating a PHY driver for it. However other PHYs use very similar interface (setting bit 0). This includes DAC_PHY, ADC_PHY, PCIe_PHY, SATA_PHY. Moreover it suits well to USBDEVICE_PHY, USBHOST_PHY. How is it currently being done for these drivers? Is it being done in the patches sent by Kamil or Vivek? Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cache largest vma
* Davidlohr Bueso wrote: > Btw, do you suggest using a high level tool such as perf for getting > this data or sprinkling get_cycles() in find_vma() -- I'd think that the > first isn't fine grained enough, while the later will probably variate a > lot from run to run but the ratio should be rather constant. LOL - I guess I should have read your mail before replying to it ;-) Yes, I think get_cycles() works better in this case - not due to granularity (perf stat will report cycle granular just fine), but due to the size of the critical path you'll be measuring. You really want to extract the delta, because it's probably so much smaller than the overhead of the workload itself. [ We still don't have good 'measure overhead from instruction X to instruction Y' delta measurement infrastructure in perf yet, although Frederic is working on such a trigger/delta facility AFAIK. ] Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cache largest vma
On Sun, Nov 03, 2013 at 10:51:27AM -0800, Linus Torvalds wrote: > Ugh. This patch makes me angry. It looks way too ad-hoc. > > I can well imagine that our current one-entry cache is crap and could > be improved, but this looks too random. Different code for the > CONFIG_MMU case? Same name, but for non-MMU it's a single entry, for > MMU it's an array? And the whole "largest" just looks odd. Plus why do > you set LAST_USED if you also set LARGEST? > > Did you try just a two- or four-entry pseudo-LRU instead, with a > per-thread index for "last hit"? Or even possibly a small fixed-size > hash table (say "idx = (add >> 10) & 3" or something)? Btw, Dave Chiner has recently implemented a simple look aside cache for the buffer cache, which also uses a rbtree. Might beworth into making that into a generic library and use it here: http://thread.gmane.org/gmane.comp.file-systems.xfs.general/56220 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cache largest vma
* Davidlohr Bueso wrote: > On Sun, 2013-11-03 at 11:12 +0100, Ingo Molnar wrote: > > * Davidlohr Bueso wrote: > > > > > While caching the last used vma already does a nice job avoiding > > > having to iterate the rbtree in find_vma, we can improve. After > > > studying the hit rate on a load of workloads and environments, > > > it was seen that it was around 45-50% - constant for a standard > > > desktop system (gnome3 + evolution + firefox + a few xterms), > > > and multiple java related workloads (including Hadoop/terasort), > > > and aim7, which indicates it's better than the 35% value documented > > > in the code. > > > > > > By also caching the largest vma, that is, the one that contains > > > most addresses, there is a steady 10-15% hit rate gain, putting > > > it above the 60% region. This improvement comes at a very low > > > overhead for a miss. Furthermore, systems with !CONFIG_MMU keep > > > the current logic. > > > > > > This patch introduces a second mmap_cache pointer, which is just > > > as racy as the first, but as we already know, doesn't matter in > > > this context. For documentation purposes, I have also added the > > > ACCESS_ONCE() around mm->mmap_cache updates, keeping it consistent > > > with the reads. > > > > > > Cc: Hugh Dickins > > > Cc: Michel Lespinasse > > > Cc: Ingo Molnar > > > Cc: Mel Gorman > > > Cc: Rik van Riel > > > Cc: Guan Xuetao > > > Signed-off-by: Davidlohr Bueso > > > --- > > > Please note that nommu and unicore32 arch are *untested*. > > > > > > I also have a patch on top of this one that caches the most > > > used vma, which adds another 8-10% hit rate gain, However, > > > since it does add a counter to the vma structure and we have > > > to do more logic in find_vma to keep track, I was hesitant about > > > the overhead. If folks are interested I can send that out as well. > > > > Would be interesting to see. > > > > Btw., roughly how many cycles/instructions do we save by increasing > > the hit rate, in the typical case (for example during a kernel build)? > > Good point. The IPC from perf stat doesn't show any difference with or > without the patch -- note that this is probably the least interesting > one as we already get a really nice hit rate with the single mmap_cache. > I have yet to try it on the other workloads. I'd be surprised if this was measureable via perf stat, unless you do the measurement in a really, really careful way - and even then it's easy to make a hard to detect mistake larger in magnitude than the measured effect ... An easier and more reliable measurement would be to stick 2-3 get_cycles() calls into the affected code and save the pure timestamps into task.se.statistics, and extract the timestamps via /proc/sched_debug by adding matching seq_printf()s to kernel/sched/debug.c. (You can clear the statistics by echoing 0 to /proc//sched_debug, see proc_sched_set_task().) That measurement is still subject to skid and other artifacts but hopefully the effect is larger than cycles fuzz - and we are interested in a ballpark figure in any case. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REVIEW][PATCH 1/2] userns: Better restrictions on when proc and sysfs can be mounted
On Sat, Nov 2, 2013 at 8:06 AM, Gao feng wrote: > And another question, it looks like if we don't have proc/sys fs mounted, > then proc/sys will be failed to be mounted? I have been wondering the same. Was quite some illogical surprise that we have to be doing overlay mounts. This is the exact opposite from what anyone would expect. -- Janne -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Nov 4
Hi all, Changes since 20131101: The squashfs tree lost its build failure. The sound-asoc tree gained a build failure for which I reverted a commit. The modules tree introduced a very large number of warnings so I used the version from next-20131101. The block tree still had its build failure so I used the version from next-20131031. The dt-rh tree gained a conflict against the imx-mxs tree. The random tree gained a conflict against Linus' tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 212 trees (counting Linus' and 30 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (17f6ee43c336 Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus) Merging fixes/master (fa8218def1b1 Merge tag 'regmap-v3.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (18e8a7387340 ARC: [plat-arcfpga] defconfig update) Merging arm-current/fixes (384b38b66947 ARM: 7873/1: vfp: clear vfp_current_hw_state for dying cpu) Merging m68k-current/for-linus (55490050df0f m68k/atari: ARAnyM - Always use physical addresses in NatFeat calls) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (8b5ede69d24d powerpc/irq: Don't switch to irq stack from softirq stack) Merging sparc/master (6d15ee492809 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging net/master (6f092343855a net: flow_dissector: fail on evil iph->ihl) Merging ipsec/master (84502b5ef984 xfrm: Fix null pointer dereference when decoding sessions) Merging sound-current/for-linus (a4461f41b94c ALSA: fix oops in snd_pcm_info() caused by ASoC DPCM) Merging pci-current/for-linus (67d470e0e171 Revert "x86/PCI: MMCONFIG: Check earlier for MMCONFIG region at address zero") Merging wireless/master (8ce9beac4661 drivers: net: wireless: b43: Fix possible NULL ptr dereference) Merging driver-core.current/driver-core-linus (31d141e3a666 Linux 3.12-rc6) Merging tty.current/tty-linus (6e757ad2c92c tty/serial: at91: fix uart/usart selection for older products) Merging usb.current/usb-linus (e1466ad5b1ae USB: serial: ftdi_sio: add id for Z3X Box device) Merging staging.current/staging-linus (31d141e3a666 Linux 3.12-rc6) Merging char-misc.current/char-misc-linus (31d141e3a666 Linux 3.12-rc6) Merging input-current/for-linus (5beea882e641 Input: ALPS - add support for model found on Dell XT2) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging audit-current/for-linus (c158a35c8a68 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (26052f9b9bb8 crypto: crct10dif - Add fallback for broken initrds) Merging ide/master (64110c16e012 ide: sgiioc4: Staticize ioc4_ide_attach_one()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (1931ee143b0a Revert "drivers: of: add initialization code for dma reserved
[PATCH v4] ASoC: Add pinctrl PM to components of active DAIs
It's quite popular that more drivers are using pinctrl PM, for example:
(Documentation/devicetree/bindings/arm/primecell.txt). Just like what
runtime PM does, it would deactivate and activate pin group depending
on whether it's being used or not.
And this pinctrl PM might be also beneficial to cpu dai drivers because
they might have actual pinctrl so as to sleep their pins and wake them
up as needed.
To achieve this goal, this patch sets pins to the default state during
resume or startup; While during suspend and shutdown, it would set pins
to the sleep state.
As pinctrl PM would return zero if there is no such pinctrl sleep state
settings, this patch would not break current ASoC subsystem directly.
[ However, there is still an exception that the patch can not handle,
that is, when cpu dai driver does not have pinctrl property but another
device has it. (The AUDMUX <-> SSI on Freescale i.MX6 series for example.
SSI as a cpu dai doesn't contain pinctrl property while AUDMUX, an Audio
Multiplexer, has it). In this case, this kind of cpu dai driver needs to
find a way to obtain the pinctrl property as its own, by moving property
from AUDMUX to SSI, or creating a pins link/dependency between these two
devices, or using a more decent way after we figure it out. ]
Signed-off-by: Nicolin Chen
---
Changelog:
v4:
* Fix build break happened to x86 (missing header file)
v3:
* Add pinctrl_pm() for codec_dai/codec
* Add more proper active check for each pinctrl_pm_select_xx()
v2:
* Add cpu_dai->active check
sound/soc/soc-core.c | 33 +
sound/soc/soc-pcm.c | 11 +++
2 files changed, 44 insertions(+)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index bdc1d74..4e53d87 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -662,6 +662,8 @@ int snd_soc_suspend(struct device *dev)
codec->cache_sync = 1;
if (codec->using_regmap)
regcache_mark_dirty(codec->control_data);
+ /* deactivate pins to sleep state */
+ pinctrl_pm_select_sleep_state(codec->dev);
break;
default:
dev_dbg(codec->dev,
@@ -679,6 +681,9 @@ int snd_soc_suspend(struct device *dev)
if (cpu_dai->driver->suspend && cpu_dai->driver->ac97_control)
cpu_dai->driver->suspend(cpu_dai);
+
+ /* deactivate pins to sleep state */
+ pinctrl_pm_select_sleep_state(cpu_dai->dev);
}
if (card->suspend_post)
@@ -807,6 +812,16 @@ int snd_soc_resume(struct device *dev)
if (list_empty(>codec_dev_list))
return 0;
+ /* activate pins from sleep state */
+ for (i = 0; i < card->num_rtd; i++) {
+ struct snd_soc_dai *cpu_dai = card->rtd[i].cpu_dai;
+ struct snd_soc_dai *codec_dai = card->rtd[i].codec_dai;
+ if (cpu_dai->active)
+ pinctrl_pm_select_default_state(cpu_dai->dev);
+ if (codec_dai->active)
+ pinctrl_pm_select_default_state(codec_dai->dev);
+ }
+
/* AC97 devices might have other drivers hanging off them so
* need to resume immediately. Other drivers don't have that
* problem and may take a substantial amount of time to resume
@@ -1929,6 +1944,14 @@ int snd_soc_poweroff(struct device *dev)
snd_soc_dapm_shutdown(card);
+ /* deactivate pins to sleep state */
+ for (i = 0; i < card->num_rtd; i++) {
+ struct snd_soc_dai *cpu_dai = card->rtd[i].cpu_dai;
+ struct snd_soc_dai *codec_dai = card->rtd[i].codec_dai;
+ pinctrl_pm_select_sleep_state(codec_dai->dev);
+ pinctrl_pm_select_sleep_state(cpu_dai->dev);
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(snd_soc_poweroff);
@@ -3767,6 +3790,16 @@ int snd_soc_register_card(struct snd_soc_card *card)
if (ret != 0)
soc_cleanup_card_debugfs(card);
+ /* deactivate pins to sleep state */
+ for (i = 0; i < card->num_rtd; i++) {
+ struct snd_soc_dai *cpu_dai = card->rtd[i].cpu_dai;
+ struct snd_soc_dai *codec_dai = card->rtd[i].codec_dai;
+ if (!codec_dai->active)
+ pinctrl_pm_select_sleep_state(codec_dai->dev);
+ if (!cpu_dai->active)
+ pinctrl_pm_select_sleep_state(cpu_dai->dev);
+ }
+
return ret;
}
EXPORT_SYMBOL_GPL(snd_soc_register_card);
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index d81b792..3a7e78f 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -183,6 +184,8 @@ static int soc_pcm_open(struct
[tip:perf/core] perf test: Update command line callchain attribute tests
Commit-ID: 46d525eae2a076adfde92dca1db12d9a3b8ad8bb
Gitweb: http://git.kernel.org/tip/46d525eae2a076adfde92dca1db12d9a3b8ad8bb
Author: Arnaldo Carvalho de Melo
AuthorDate: Thu, 31 Oct 2013 09:46:59 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Nov 2013 10:42:57 -0300
perf test: Update command line callchain attribute tests
The "struct perf_event_attr setup" entry in 'perf test' is in fact a
series of tests that will exec the tools, passing different sets of
command line arguments to then intercept the sys_perf_event_open
syscall, in user space, to check that the perf_event_attr->sample_type
and other feature request bits are setup as expected.
We recently restored the callchain requesting command line argument, -g,
to not require a parameter ("dwarf" or "fp"), instead using a default
("fp" for now) and making the long option variant, --call-chain, be the
one to be used when a different callchain collection method is
preferred.
The "struct perf_event_attr setup" test failed because we forgot to
update the tests involving callchains, not switching from, '-g dwarf' to
'--call-chain dwarf', making 'perf test' detect it:
[root@sandy ~]# perf test -v 13
13: struct perf_event_attr setup :
--- start ---
running '/home/acme/libexec/perf-core/tests/attr/test-record-basic'
running '/home/acme/libexec/perf-core/tests/attr/test-record-branch-any'
running '/home/acme/libexec/perf-core/tests/attr/test-record-graph-default'
running '/home/acme/libexec/perf-core/tests/attr/test-record-graph-dwarf'
expected sample_type=12583, got 295
expected exclude_callchain_user=1, got 0
expected sample_stack_user=8192, got 0
FAILED '/home/acme/libexec/perf-core/tests/attr/test-record-graph-dwarf' -
match failure
end
struct perf_event_attr setup: FAILED!
[root@sandy ~]#
Fix all of them now to use --call-chain when explicitely specifying a
method.
There is still work to do, as '-g fp', for instance, passed without
problems.
In that case 'perf test' saw no problems as the intercepted syscall got
the bits as expected, i.e. the default is 'fp', but the fact that 'fp'
may be an existing program and the specified workload would then be
passed as a parameter to it is an usability problem that needs fixing.
Next merge window tho.
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-jr3oq1k5iywnp7vvqlslz...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/attr/README| 6 +++---
tools/perf/tests/attr/test-record-graph-default | 2 +-
tools/perf/tests/attr/test-record-graph-dwarf | 2 +-
tools/perf/tests/attr/test-record-graph-fp | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/perf/tests/attr/README b/tools/perf/tests/attr/README
index d102957..430024f 100644
--- a/tools/perf/tests/attr/README
+++ b/tools/perf/tests/attr/README
@@ -44,9 +44,9 @@ Following tests are defined (with perf commands):
perf record -c 123 kill (test-record-count)
perf record -d kill (test-record-data)
perf record -F 100 kill (test-record-freq)
- perf record -g -- kill(test-record-graph-default)
- perf record -g dwarf -- kill (test-record-graph-dwarf)
- perf record -g fp kill(test-record-graph-fp)
+ perf record -g kill (test-record-graph-default)
+ perf record --call-graph dwarf kill (test-record-graph-dwarf)
+ perf record --call-graph fp kill (test-record-graph-fp)
perf record --group -e cycles,instructions kill (test-record-group)
perf record -e '{cycles,instructions}' kill (test-record-group1)
perf record -D kill (test-record-no-delay)
diff --git a/tools/perf/tests/attr/test-record-graph-default
b/tools/perf/tests/attr/test-record-graph-default
index 833d184..853597a 100644
--- a/tools/perf/tests/attr/test-record-graph-default
+++ b/tools/perf/tests/attr/test-record-graph-default
@@ -1,6 +1,6 @@
[config]
command = record
-args= -g -- kill >/dev/null 2>&1
+args= -g kill >/dev/null 2>&1
[event:base-record]
sample_type=295
diff --git a/tools/perf/tests/attr/test-record-graph-dwarf
b/tools/perf/tests/attr/test-record-graph-dwarf
index e93e082..d6f324e 100644
--- a/tools/perf/tests/attr/test-record-graph-dwarf
+++ b/tools/perf/tests/attr/test-record-graph-dwarf
@@ -1,6 +1,6 @@
[config]
command = record
-args= -g dwarf -- kill >/dev/null 2>&1
+args= --call-graph dwarf -- kill >/dev/null 2>&1
[event:base-record]
sample_type=12583
diff --git a/tools/perf/tests/attr/test-record-graph-fp
b/tools/perf/tests/attr/test-record-graph-fp
index 7cef374..055e3be 100644
---
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Vivek, On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote: Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. The new driver uses the generic PHY framework and will interact with DWC3 controller present on Exynos5 series of SoCs. In Exynos, you have a single IP that supports both USB3 and USB2 PHY right? I think that needs to be mentioned here. Do you have separate registers that should be used for initializing/powerin_on/powering_off etc.. for usb2 phy and usb3 phy? If so, then you should model this driver as a single driver that supports two PHYs similar to what Sylwester has done before? Cheers Kishon Signed-off-by: Vivek Gautam --- .../devicetree/bindings/phy/samsung-phy.txt| 20 + drivers/phy/Kconfig|7 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5-usb3.c | 562 4 files changed, 590 insertions(+), 0 deletions(-) create mode 100644 drivers/phy/phy-exynos5-usb3.c diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index c0fccaa..9b5c111 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -20,3 +20,23 @@ Required properties: - compatible : should be "samsung,exynos5250-dp-video-phy"; - reg : offset and length of the Display Port PHY register set; - #phy-cells : from the generic PHY bindings, must be 0; + +Samsung Exynos5 SoC seiries USB 3.0 PHY controller +-- + +Required properties: +- compatible : + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC +- reg : Register offset and length array + - first field corresponds to USB 3.0 PHY register set; + - second field corresponds to PHY power isolation register + present in PMU; +- clocks: Clock IDs array as required by the controller +- clock-names: names of clocks correseponding to IDs in the clock property; + Required clocks: + - first clock is main PHY clock (same as USB 3.0 controller IP clock) + - second clock is reference clock (usually crystal clock) + optional clock: + - third clock is special clock used by PHY for operation +- #phy-cells : from the generic PHY bindings, must be 0; diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index a344f3d..9a100c6 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -51,4 +51,11 @@ config PHY_EXYNOS_DP_VIDEO help Support for Display Port PHY found on Samsung EXYNOS SoCs. +config PHY_EXYNOS5_USB3 + tristate "Exynos5 SoC series USB 3.0 PHY driver" + depends on ARCH_EXYNOS5 + select GENERIC_PHY + help + Enable USB 3.0 PHY support for Exynos 5 SoC series + endmenu diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index d0caae9..9c06a61 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o +obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c new file mode 100644 index 000..b9a2674 --- /dev/null +++ b/drivers/phy/phy-exynos5-usb3.c @@ -0,0 +1,562 @@ +/* + * Samsung EXYNOS5 SoC series USB 3.0 PHY driver + * + * Copyright (C) 2013 Samsung Electronics Co., Ltd. + * Author: Vivek Gautam + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Exynos USB PHY registers */ +#define EXYNOS5_FSEL_9MHZ6 0x0 +#define EXYNOS5_FSEL_10MHZ 0x1 +#define EXYNOS5_FSEL_12MHZ 0x2 +#define EXYNOS5_FSEL_19MHZ20x3 +#define EXYNOS5_FSEL_20MHZ 0x4 +#define EXYNOS5_FSEL_24MHZ 0x5 +#define EXYNOS5_FSEL_50MHZ 0x7 + +/* EXYNOS5: USB 3.0 DRD PHY registers */ +#define EXYNOS5_DRD_LINKSYSTEM (0x04) + +#define LINKSYSTEM_FLADJ_MASK (0x3f << 1) +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1) +#define LINKSYSTEM_XHCI_VERSION_CONTROL(0x1 << 27) + +#define EXYNOS5_DRD_PHYUTMI(0x08) + +#define PHYUTMI_OTGDISABLE (0x1 << 6) +#define PHYUTMI_FORCESUSPEND (0x1 << 1) +#define PHYUTMI_FORCESLEEP (0x1 << 0) + +#define EXYNOS5_DRD_PHYPIPE
[tip:perf/core] perf bench: Fix two warnings
Commit-ID: 32bf5bd181026fc99c0e15045abe409167285ba8
Gitweb: http://git.kernel.org/tip/32bf5bd181026fc99c0e15045abe409167285ba8
Author: Wei Yang
AuthorDate: Sun, 22 Sep 2013 16:49:24 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Nov 2013 10:41:54 -0300
perf bench: Fix two warnings
There are two warnings in bench/numa, when building this on 32-bit
machine.
The warning output is attached:
bench/numa.c:1113:20: error: comparison between signed and unsigned integer
expressions [-Werror=sign-compare]
bench/numa.c:1161:6: error: format ‘%lx’ expects argument of t'long unsigned
int’, but argument 5 has type ‘u64’ [-Werror=format]
This patch fixes these two warnings.
Signed-off-by: Wei Yang
Acked-by: Ingo Molnar
Cc: Ingo Molnar
Link:
http://lkml.kernel.org/r/1379839764-9245-1-git-send-email-weiy...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/bench/numa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
index 30d1c32..a73c4ed 100644
--- a/tools/perf/bench/numa.c
+++ b/tools/perf/bench/numa.c
@@ -1110,7 +1110,7 @@ static void *worker_thread(void *__tdata)
/* Check whether our max runtime timed out: */
if (g->p.nr_secs) {
timersub(, , );
- if (diff.tv_sec >= g->p.nr_secs) {
+ if (diff.tv_sec >= (time_t)g->p.nr_secs) {
g->stop_work = true;
break;
}
@@ -1157,7 +1157,7 @@ static void *worker_thread(void *__tdata)
runtime_ns_max += diff.tv_usec * 1000;
if (details >= 0) {
- printf(" #%2d / %2d: %14.2lf nsecs/op [val:
%016lx]\n",
+ printf(" #%2d / %2d: %14.2lf nsecs/op [val:
%016"PRIu64"]\n",
process_nr, thread_nr, runtime_ns_max /
bytes_done, val);
}
fflush(stdout);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:perf/core] perf tools: Remove cast of non-variadic function to variadic
Commit-ID: 53805eca3d89b095062c11a6798689bb0af09216
Gitweb: http://git.kernel.org/tip/53805eca3d89b095062c11a6798689bb0af09216
Author: Michael Hudson-Doyle
AuthorDate: Thu, 31 Oct 2013 16:47:45 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 1 Nov 2013 10:40:51 -0300
perf tools: Remove cast of non-variadic function to variadic
The 4fb71074a570 (perf ui/hist: Consolidate hpp helpers) cset introduced
a cast of percent_color_snprintf to a function pointer type with
varargs. Change percent_color_snprintf to be variadic and remove the
cast.
The symptom of this was all percentages being reported as 0.00% in perf
report --stdio output on the armhf arch.
Signed-off-by: Michael Hudson-Doyle
Acked-by: Namhyung Kim
Acked-by: Will Deacon
Cc: Jean Pihet
Cc: Jiri Olsa
Cc: Will Deacon
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/87zjppvw7y@canonical.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/hist.c| 2 +-
tools/perf/util/color.c | 11 +--
tools/perf/util/color.h | 2 +-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 0a19328..78f4c92 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -117,7 +117,7 @@ static int hpp__color_##_type(struct perf_hpp_fmt *fmt
__maybe_unused, \
struct perf_hpp *hpp, struct hist_entry *he)
\
{
\
return __hpp__fmt(hpp, he, he_get_##_field, " %6.2f%%",
\
- (hpp_snprint_fn)percent_color_snprintf, true);
\
+ percent_color_snprintf, true);
\
}
#define __HPP_ENTRY_PERCENT_FN(_type, _field)
\
diff --git a/tools/perf/util/color.c b/tools/perf/util/color.c
index 11e46da..66e44a5 100644
--- a/tools/perf/util/color.c
+++ b/tools/perf/util/color.c
@@ -318,8 +318,15 @@ int percent_color_fprintf(FILE *fp, const char *fmt,
double percent)
return r;
}
-int percent_color_snprintf(char *bf, size_t size, const char *fmt, double
percent)
+int percent_color_snprintf(char *bf, size_t size, const char *fmt, ...)
{
- const char *color = get_percent_color(percent);
+ va_list args;
+ double percent;
+ const char *color;
+
+ va_start(args, fmt);
+ percent = va_arg(args, double);
+ va_end(args);
+ color = get_percent_color(percent);
return color_snprintf(bf, size, color, fmt, percent);
}
diff --git a/tools/perf/util/color.h b/tools/perf/util/color.h
index dea082b..fced384 100644
--- a/tools/perf/util/color.h
+++ b/tools/perf/util/color.h
@@ -39,7 +39,7 @@ int color_fprintf(FILE *fp, const char *color, const char
*fmt, ...);
int color_snprintf(char *bf, size_t size, const char *color, const char *fmt,
...);
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
int color_fwrite_lines(FILE *fp, const char *color, size_t count, const char
*buf);
-int percent_color_snprintf(char *bf, size_t size, const char *fmt, double
percent);
+int percent_color_snprintf(char *bf, size_t size, const char *fmt, ...);
int percent_color_fprintf(FILE *fp, const char *fmt, double percent);
const char *get_percent_color(double percent);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: Allow NR_CPUS=1024
* Josh Boyer wrote: > On Sun, Nov 03, 2013 at 11:21:32AM +0100, Ingo Molnar wrote: > > > > * Ingo Molnar wrote: > > > > > > > > * Josh Boyer wrote: > > > > > > > The current range for SMP configs is 2 - 512, or a full 4096 in the > > > > case > > > > of MAXSMP. There are machines that have 1024 CPUs in them today and > > > > configuring a kernel for that means you are forced to set MAXSMP. This > > > > adds additional unnecessary overhead. While that overhead might be > > > > considered tiny for large machines, it isn't necessarily so if you are > > > > building a kernel that runs across a wide variety of machines. We > > > > increase the range to 1024 to help with this. > > > > > > > > Signed-off-by: Josh Boyer > > > > --- > > > > arch/x86/Kconfig | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > > > index f67e839..d726b2d 100644 > > > > --- a/arch/x86/Kconfig > > > > +++ b/arch/x86/Kconfig > > > > @@ -825,7 +825,7 @@ config MAXSMP > > > > config NR_CPUS > > > > int "Maximum number of CPUs" if SMP && !MAXSMP > > > > range 2 8 if SMP && X86_32 && !X86_BIGSMP > > > > - range 2 512 if SMP && !MAXSMP > > > > + range 2 1024 if SMP && !MAXSMP > > > > default "1" if !SMP > > > > default "4096" if MAXSMP > > > > default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP > > > > || X86_ES7000) > > > > > > Any reason not to allow it to go up to 4096? The original concern was > > > that CPUS=4096 wasn't working very well and you had to select MAXSMP > > > deliberately and keep all the pieces. > > No real reason to not allow all the way to 4096, no. I just started > small as I wanted 1024 specifically, and this is the simplest way to > achieve that. > > > The other reason was CONFIG_CPUMASK_OFFSTACK: with 4096 CPUs a cpumask is > > 512 bytes, too large to be kept on the kernel stack. > > > > MAXSMP forces CONFIG_CPUMASK_OFFSTACK so there's no such concern there. > > > > With 1024 CPUs a single cpumask is 128 bytes - rather significant as well. > > With 512 CPUs it's 64 bytes - borderline. > > > > So I think a better solution would be to allow an increase above 512 CPUs > > only if CONFIG_CPUMASK_OFFSTACK is also enabled. > > OK, that makes sense. So in this scenario, we could probably either: > > a) do away with MAXSMP entirely and just depend on > CONFIG_CPUMASK_OFFSTACK. > > b) make MAXSMP something even higher than 4096. Like 5120 or 6144, etc. > > Which would you prefer? Either is easy enough to code up, I just need > to know which I should shoot for. Why touch MAXSMP at all? It's really just a shortcut for 'configure the kernel silly large', via a single option, nothing else. You are not forced to use it and it should not affect configurability of NR_CPUS. What we _really_ want here is to fix NR_CPUS setting: to extend its range and to enforce that NR_CPUS cannot be set larger than 512 without setting CONFIG_CPUMASK_OFFSTACK. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the final tree
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
sound/soc/soc-pcm.c: In function 'soc_pcm_open':
sound/soc/soc-pcm.c:186:2: error: implicit declaration of function
'pinctrl_pm_select_default_state' [-Werror=implicit-function-declaration]
pinctrl_pm_select_default_state(cpu_dai->dev);
^
sound/soc/soc-pcm.c:323:3: error: implicit declaration of function
'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
pinctrl_pm_select_sleep_state(codec_dai->dev);
^
Caused by commit fc1a38653793 ("ASoC: Add pinctrl PM to components of
active DAIs") from the sound-asoc tree.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpeaCS4_RU43.pgp
Description: PGP signature
Re: [PATCH] x86: Allow NR_CPUS=1024
* H. Peter Anvin wrote: > On 11/03/2013 07:57 AM, Josh Boyer wrote: > > > > OK, that makes sense. So in this scenario, we could probably either: > > > > a) do away with MAXSMP entirely and just depend on > > CONFIG_CPUMASK_OFFSTACK. > > > > b) make MAXSMP something even higher than 4096. Like 5120 or 6144, etc. > > > > Which would you prefer? Either is easy enough to code up, I just need > > to know which I should shoot for. > > > > Let's get rid of MAXSMP. I'd rather not, because it has caught a number of regressions in the past, because randconfig can wander over it and trigger those large configs. randconfig will not randomize numeric Kconfig ranges, so there's no other mechanism right now to trigger those large config kernels. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 0/3] perf/urgent fixes
* Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > The following changes since commit e8a923cc1fff6e627f906655ad52ee694ef2f6d7: > > perf/x86: Fix NMI measurements (2013-10-29 12:01:20 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux > tags/perf-urgent-for-mingo > > for you to fetch changes up to 46d525eae2a076adfde92dca1db12d9a3b8ad8bb: > > perf test: Update command line callchain attribute tests (2013-11-01 > 10:42:57 -0300) > > > perf/urgent fixes: > > . Fix command line callchain attribute tests to handle the new > -g/--call-chain semantics. > > . Remove cast of non-variadic function to variadic, fixing perf output > on armhf arch. Fix from Michael Hudson-Doyle. > > . Fix 32-bit building of 'perf bench', from Wei Yang. > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (1): > perf test: Update command line callchain attribute tests > > Michael Hudson-Doyle (1): > perf tools: Remove cast of non-variadic function to variadic > > Wei Yang (1): > perf bench: Fix two warnings > > tools/perf/bench/numa.c | 4 ++-- > tools/perf/tests/attr/README| 6 +++--- > tools/perf/tests/attr/test-record-graph-default | 2 +- > tools/perf/tests/attr/test-record-graph-dwarf | 2 +- > tools/perf/tests/attr/test-record-graph-fp | 2 +- > tools/perf/ui/hist.c| 2 +- > tools/perf/util/color.c | 11 +-- > tools/perf/util/color.h | 2 +- > 8 files changed, 19 insertions(+), 12 deletions(-) Pulled, thanks Arnaldo! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 8/9] phy: add Broadcom Kona USB2 PHY driver
Hi,
On Saturday 02 November 2013 01:15 AM, Matt Porter wrote:
Add a driver for the internal Broadcom Kona USB 2.0 PHY found
on the BCM281xx family of SoCs.
Signed-off-by: Matt Porter
---
drivers/phy/Kconfig | 6 ++
drivers/phy/Makefile| 2 +
drivers/phy/phy-bcm-kona-usb2.c | 161
3 files changed, 169 insertions(+)
create mode 100644 drivers/phy/phy-bcm-kona-usb2.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 349bef2..cedada5 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,4 +15,10 @@ config GENERIC_PHY
phy users can obtain reference to the PHY. All the users of this
framework should select this config.
+config BCM_KONA_USB2_PHY
+ tristate "Broadcom Kona USB2 PHY Driver"
+ depends on GENERIC_PHY
+ help
+ Enable this to support the Broadcom Kona USB 2.0 PHY.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..ce83a14 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,3 +3,5 @@
#
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+
+obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
new file mode 100644
index 000..1beea7f
--- /dev/null
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -0,0 +1,161 @@
+/*
+ * phy-bcm-kona-usb2.c - Broadcom Kona USB2 Phy Driver
+ *
+ * Copyright (C) 2013 Linaro Limited
+ * Matt Porter
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define OTGCTL_OTGSTAT2(1 << 31)
+#define OTGCTL_OTGSTAT1(1 << 30)
+#define OTGCTL_PRST_N_SW (1 << 11)
+#define OTGCTL_HRESET_N(1 << 10)
+#define OTGCTL_UTMI_LINE_STATE1(1 << 9)
+#define OTGCTL_UTMI_LINE_STATE0(1 << 8)
+
+#define P1CTL_SOFT_RESET (1 << 1)
+#define P1CTL_NON_DRIVING (1 << 0)
+
+struct bcm_kona_usb_phy_regs {
+ u32 ctrl;
+ u32 cfg;
+ u32 p1ctl;
+ u32 status;
+ u32 bc_cfg;
+ u32 tp_in;
+ u32 tp_out;
+ u32 phy_ctrl;
+ u32 usbreg;
+ u32 usbproben;
+};
I would prefer to have constant macros for register offset unless you
have a good reason to do otherwise.
+
+struct bcm_kona_usb {
+ struct bcm_kona_usb_phy_regs *regs;
+};
+
+static void bcm_kona_usb_phy_power(struct bcm_kona_usb *phy, int on)
+{
+ u32 val;
+
+ val = readl(>regs->ctrl);
+ if (on) {
+ /* Configure and power PHY */
+ val &= ~(OTGCTL_OTGSTAT2 | OTGCTL_OTGSTAT1 |
+OTGCTL_UTMI_LINE_STATE1 | OTGCTL_UTMI_LINE_STATE0);
+ val |= OTGCTL_PRST_N_SW | OTGCTL_HRESET_N;
+ writel(val, >regs->ctrl);
+
+ /* Soft reset PHY */
+ val = readl(>regs->p1ctl);
+ val &= ~P1CTL_NON_DRIVING;
+ val |= P1CTL_SOFT_RESET;
+ writel(val, >regs->p1ctl);
+ writel(val & ~P1CTL_SOFT_RESET, >regs->p1ctl);
+ /* Reset needs to be asserted for 2ms */
+ mdelay(2);
+ writel(val | P1CTL_SOFT_RESET, >regs->p1ctl);
Is soft reset needed for every power-on? Shouldn't soft reset be present
in phy_init?
Cheers
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
* Linus Torvalds wrote: > So I may be pessimistic, but I'd expect many developers would go "Let's > hunt bugs.. Wait. Oooh, shiny" and go off doing some new feature after > all instead. Or just take that release off. > > But I do wonder.. Maybe it would be possible, and I'm just unfairly > projecting my own inner squirrel onto other kernel developers. If we > have enough heads-up that people *know* that for one release (and > companies/managers know that too) the only patches that get accepted are > the kind that fix bugs, maybe people really would have sufficient > attention span that it could work. > > And the reason I mention "4.0" is that it would be a lovely time to do > that. Roughly a years heads-up that "ok, after 3.19 (or whatever), we're > doing a release with *just* fixes, and then that becomes 4.0". > > Comments? I think the biggest problem wouldn't even be the enforcement of bugfixes-only during that 2.5 months period, or kernel developers surviving such a long streak of boredom, but v3.19 would also probably be a super-stressful release to maintainers, as everyone would try to cram their feature in there. And if anything important misses that window then it's a +5 months wait... The other problem is that kernel developers who do development typically fix their own bugs within a week or two. It's not developers that typically determine the stability of a subsystem but _maintainers_, and the primary method of stabilization is, beyond being careful when merging a patch, is to remember/monitor breakages and not merge new feature patches from a developer until fixable bugs are fixed by the developer. Bugs that go on longer are usually the bugs developers cannot reproduce, the ones where the timing and progress depends on other, external people. For example the NUMA fixes in v3.12 took a couple of full cycles to pin down fully. I think waiting another 2-3 months will mostly bring idle time and diminishing returns of the long, exponentially decaying tail of bugfixes, IMHO. Thirdly, _users_ interested in stability can already go to the -stable kernel, will will suck up 1 cycle worth of bugfixes out of the main flow of changes. So users already have a stability choice of v-latest and 'v-latest - 1' - plus the 'long term' stable kernels as well. So IMO the main steering parameter of our kernel stabilization process is the maintainer directly above a developer, the first-hop maintainer. For 90-95% of the commits you are the second hop maintainer or higher. So whether in 4.0 you are going to take non-fixes will not directly affect the stabilization process and flow that is already in place, assuming that our current stabilization process is more or less healthy. It will (or should) essentially track what our current -stable process is. But we already have that process in place and it's working well IMO - the problem isn't really effort or meta-maintanence issues but lack of good stability metrics due to lack of kerneloops.org feedback, etc. So ... unless you think our current stabilization flow is unhealthy and/or you'd like to perform a natural experiment to measure it, why not just do what worked so well for v3.0 and afterwards? Keep the existing process in place, don't upset it just due to a (comparably) silly number tweak. Maybe ask first-hop maintainers to be extra super diligent about new features in v4.0 by imposing an internal merge window deadline 2 weeks before the real merge window [a fair chunk of patches hit maintainer trees in the last 2 weeks of the development window, and those cause much of the regressions], maybe even reject a few pulls during the merge window that blatantly violate these pre-freeze rules, but don't hold up the low-latency flow of steady improvements - much of which is driver work, platform enablement work, small improvements, etc., which isn't really a big source of real regressions for the existing installed base. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: [PATCH v2] kernel/resource.c: use signed length comparing instead of position comparing
Sorry, forgot to cc linux-kernel. Original Message Subject: [PATCH v2] kernel/resource.c: use signed length comparing instead of position comparing Date: Mon, 04 Nov 2013 11:05:30 +0800 From: Chen Gang To: Toshi Kani , "isimatu.yasu...@jp.fujitsu.com" , gong.c...@linux.intel.com, haoke...@gmail.com CC: Andrew Morton Theoretically, "addr + size" may be overflow (e.g. equal 0), so use signed length comparing instead of position comparing. Signed-off-by: Chen Gang --- kernel/resource.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/resource.c b/kernel/resource.c index 3f285dc..0783733 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -1335,7 +1335,7 @@ int iomem_is_exclusive(u64 addr) * We can probably skip the resources without * IORESOURCE_IO attribute? */ - if (p->start >= addr + size) + if ((s64)(p->start - addr) >= size) break; if (p->end < addr) continue; -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls
Hi,
On Saturday 02 November 2013 11:28 PM, Tomasz Figa wrote:
On Saturday 02 of November 2013 13:47:09 Matt Porter wrote:
On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
Hi Tomasz,
On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
Hi Matt,
On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
This adds a pair of APIs that allows the generic PHY subsystem to
provide information on the PHY bus width. The PHY provider driver
may
use phy_set_bus_width() to set the bus width that the PHY supports.
The controller driver may then use phy_get_bus_width() to fetch the
PHY bus width in order to properly configure the controller.
I somehow does not like this. If we take this path for any further
properties that we may need, we will end up with a lot of consumer
specific properties stored in a PHY object having their own accessor
functions.
Only after all of us feel that a property is *generic* enough, we
allow it to be added in the PHY object.
I also want to note that this was discussed over in another thread [2]
where you did consider my rough stab at a more generic attribute
accessor. It was definitely my first reaction as the way to do it like
Tomasz has said. The specific accessors are more readable to me besides
the justification you mention above.
[2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html
Personally I like that version much better, but still it would need to be
polished a bit.
How I imagine such interface to be implemented:
phy.h:
struct phy {
// ...
const struct phy_attrs *attrs;
// ...
};
static inline const struct phy_attrs *phy_get_attrs(struct phy *phy) {
return phy->attrs;
};
API's like get_attrs is loosely defined. I'd prefer to have fully
defined APIs. There might be other attributes which the consumer might
not be interested in. Instead of returning the entire structure, it
would be better if we have facilities for the consumer to request only
the required attributes.
phy driver:
static const struct phy_attrs my_phy_attrs = {
// ...
};
static int my_phy_probe(...)
{
// ...
phy = devm_phy_create_attrs(dev, , _phy_attrs, NULL);
// ...
}
phy consumer:
// ...
const struct phy_attrs *phy_attrs;
phy_attrs = phy_get_attrs(phy);
// ...
Why I think it is better than what I've seen in this and previous instance
of this thread? (in random order)
a) Only the PHY driver can set the attrs.
b) PHY consumer has access only to a const pointer.
c) PHY attributes can be placed in a static struct inside a driver file,
without the need to call any functions to set particular attributes.
Agree with all your points for setting the attributes apart from the
fact that we won't be able to add any validation criteria for the
attributes while setting it if needed and also there won't be symmetric
APIs for getting and setting the attributes..
Cheers
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the random tree with Linus' tree
Hi Ted,
Today's linux-next merge of the random tree got a conflict in
drivers/base/core.c between commit 63967685605b ("driver core: add
#include to core files") from Linus' tree and commit
f0ed2b943a53 ("random: use device attach events for entropy") from the
random tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/base/core.c
index 67b180d855b2,5e98fc379d0f..
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@@ -26,7 -26,7 +26,8 @@@
#include
#include
#include
+#include
+ #include
#include "base.h"
#include "power/power.h"
pgpa9L46hh42V.pgp
Description: PGP signature
[GIT] Networking
I'm sending a pull request of these lingering bug fixes for networking before the normal merge window material because some of this stuff I'd like to get to -stable ASAP. 1) cxgb3 stopped working on 32-bit machines, fix from Ben Hutchings. 2) Structures passed via netlink for netfilter logging are not fully initialized. From Mathias Krause. 3) Properly unlink upper openvswitch device during notifications, from Alexei Starovoitov. 4) Fix race conditions involving access to the IP compression scratch buffer, from Michal Kubrecek. 5) We don't handle the expiration of MTU information contained in ipv6 routes sometimes, fix from Hannes Frederic Sowa. 6) With Fast Open we can miscompute the TCP SYN/ACK RTT, from Yuchung Cheng. 7) Don't take TCP RTT sample when an ACK doesn't acknowledge new data, also from Yuchung Cheng. 8) The decreased IPSEC garbage collection threshold causes problems for some people, bump it back up. From Steffen Klassert. 9) Fix skb->truesize calculated by tcp_tso_segment(), from Eric Dumazet. 10) flow_dissector doesn't validate packet lengths sufficiently, from Jason Wang. Please pull, thanks a lot! The following changes since commit 320437af954cbe66478f1f5e8b34cb5a8d072191: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux (2013-10-23 08:10:25 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net master for you to fetch changes up to c32b7dfbb1dfb3f0a68f250deff65103c8bb704a: net/mlx4_core: Fix call to __mlx4_unregister_mac (2013-11-04 00:51:10 -0500) Alexei Starovoitov (1): openvswitch: fix vport-netdev unregister Alistair Popple (2): ibm emac: Don't call napi_complete if napi_reschedule failed ibm emac: Fix locking for enable/disable eob irq Antonio Quartulli (1): netpoll: fix rx_hook() interface by passing the skb Ariel Elior (1): bnx2x: Disable VF access on PF removal Ben Hutchings (1): cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures Daniel Borkmann (2): net: sctp: fix ASCONF to allow non SCTP_ADDR_SRC addresses in ipv6 net: sctp: do not trigger BUG_ON in sctp_cmd_delete_tcb David S. Miller (6): Merge branch 'master' of git://git.kernel.org/.../pablo/nf Merge branch 'qlcnic' Merge branch 'master' of git://git.kernel.org/.../pablo/nf Merge branch 'fixes' of git://git.kernel.org/.../jesse/openvswitch Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec Merge branch 'fixes-for-3.12' of git://gitorious.org/linux-can/linux-can Dmitry Kravkov (1): bnx2x: prevent FW assert on low mem during unload Eric Dumazet (2): pkt_sched: fq: clear time_next_packet for reused flows tcp: gso: fix truesize tracking Freddy Xin (1): ax88179_178a: Remove AX_MEDIUM_ALWAYS_ONE bit in AX_MEDIUM_STATUS_MODE register to avoid TX throttling Hannes Frederic Sowa (2): ipv6: reset dst.expires value when clearing expire flag ipv6: ip6_dst_check needs to check for expired dst_entries Holger Eitzenberger (1): netfilter: xt_NFQUEUE: fix --queue-bypass regression Jack Morgenstein (1): net/mlx4_core: Fix call to __mlx4_unregister_mac Jason Wang (2): virtio-net: correctly handle cpu hotplug notifier during resuming net: flow_dissector: fail on evil iph->ihl Markus Pargmann (1): can: c_can: Fix RX message handling, handle lost message before EOB Masanari Iida (1): doc:net: Fix typo in Documentation/networking Mathias Krause (2): netfilter: ebt_ulog: fix info leaks netfilter: ipt_ULOG: fix info leaks Michael Drüing (1): net: x25: Fix dead URLs in Kconfig Michal Kubecek (1): xfrm: prevent ipcomp scratch buffer race condition Nathan Hintz (1): bgmac: don't update slot on skb alloc/dma mapping error Nikolay Aleksandrov (2): netconsole: fix NULL pointer dereference netconsole: fix multiple race conditions Olivier Sobrie (1): can: kvaser_usb: fix usb endpoints detection Randy Dunlap (1): Documentation/networking: netdev-FAQ typo corrections Sebastian Siewior (1): net: wan: sbni: remove assembly crc32 code Shahed Shaikh (2): qlcnic: Do not force adapter to perform LRO without destination IP check qlcnic: Do not read QLCNIC_FW_CAPABILITY_MORE_CAPS bit for 83xx adapter Somnath Kotur (1): be2net: Warn users of possible broken functionality on BE2 cards with very old FW versions with latest driver Steffen Klassert (2): xfrm: Increase the garbage collector threshold xfrm: Fix null pointer dereference when decoding sessions Vlad Yasevich (1): bridge: pass correct vlan id to multicast code Wei Liu (1): xen-netback: use jiffies_64 value to calculate credit timeout Will Deacon (1): netfilter: x_tables: fix
[PATCH] ARM: imx: removed unused MACH_MXLADS Kconfig parameter
This removes the MACH_MXLADS Kconfig parameter, which was no longer used anywhere in the source code and Makefiles. Signed-off-by: Michael Opdenacker --- arch/arm/mach-imx/Kconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 29a8af6922a8..d84a772bbc68 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -158,14 +158,11 @@ configSOC_IMX51 if ARCH_MULTI_V4T comment "MX1 platforms:" -config MACH_MXLADS - bool config ARCH_MX1ADS bool "MX1ADS platform" select IMX_HAVE_PLATFORM_IMX_I2C select IMX_HAVE_PLATFORM_IMX_UART - select MACH_MXLADS select SOC_IMX1 help Say Y here if you are using Motorola MX1ADS/MXLADS boards -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dm-writeboost: Progress Report
Hi, DM Guys
Let me share a new progress report.
I am sorry I have been off for weeks.
Writeboost is getting better I believe.
Many progress, please git pull
https://github.com/akiradeveloper/dm-writeboost.git
1. Removing version switch macros
Previously the code included 10 or more version switches
and thus is not appropriate for upstream code of course.
Now I removed them all and Writeboost is not available for
older version of kernel.
2. .postsuspend and .resume implemented
dmsetup suspend and resume works now.
I implemented .postsuspend and .resume for this purpose.
.postsuspend is called after all I/O is submitted to
the device. In .postsuspend I make all the transient data
persistent.
static void writeboost_postsuspend(struct dm_target *ti)
{
int r;
struct wb_device *wb = ti->private;
struct wb_cache *cache = wb->cache;
flush_current_buffer(cache);
IO(blkdev_issue_flush(cache->device->bdev, GFP_NOIO, NULL));
}
.postsuspend is also called before .dtr is called.
I removed the same code from .dtr therefore.
.resume does nothing at all.
3. Blocking up the device thoroughly implemented
How to block up the device has been my annoyance for weeks.
Now, Writeboost can block up the device in I/O error correctly
and elegantly.
What a dead device should satisfy are
1) Returns error on all incoming requests
2) ACK to all the requests accepted
3) To clean up data structures on memory
`dmsetup remove` must be accepted even after marked dead
4) Blocking up must be processed regardless of any timing issues.
The principle behind how Writeboost blocks up a device
is really simple.
1) All I/O to underlying devices are wrapped by IO macro (shown below)
which set flag WB_DEAD (using set_bit) on -EIO returned.
2) If WB_DEAD is set, all I/O to the underlying devices are ignored.
This is equivalent to having /dev/null devices underlying.
Processings on the memory data structures are still
continuing completely agnostic to the fact that
the underlying devices ignore their requests.
This ensures the logic on the data structures never corrupt
and data on the underlying devices never change after marked dead.
3) Some codes are wrapped by LIVE, DEAD or LIVE_DEAD
macro which switches its behavior in accordance with
WB_DEAD bit.
I tested the mechanism by wrapping the underlying devices (like below)
by dm-flakey. For both cases (cache fails or backing fails)
it seems to be working.
sz=`blockdev --getsize ${CACHE}`
dmsetup create cache-flakey --table "0 ${sz} flakey ${CACHE} 0 5 1"
CACHE=/dev/mapper/cache-flakey
sz=`blockdev --getsize ${BACKING}`
dmsetup create backing-flakey --table "0 ${sz} flakey ${BACKING} 0 20 0"
BACKING=/dev/mapper/backing-flakey
3.1 WARN_ONCE introduced
IO macro branches the behavior with the return code from it wrapping procedure.
It only treat -EIO as a trigger to block up the device and others are not.
The problem remains is that I don't know what error
code can return within possibility.
If the error code is not expected, it WARN_ONCE
to ask user to report the error.
/*
* Only -EIO returned is regarded as a signal
* to block up the whole system.
*
* -EOPNOTSUPP could be returned if the target device is
* a virtual device and we request discard.
*
* -ENOMEM could be returned from blkdev_issue_discard (3.12-rc5)
* for example. Waiting for a while can make room for allocation.
*
* For other unknown error codes we ignore them and
* ask the human users to report us.
*/
#define IO(proc) \
do { \
r = 0; \
LIVE(r = proc); \
if (r == -EOPNOTSUPP) { \
r = 0; \
} else if (r == -EIO) { \
set_bit(WB_DEAD, >flags); \
wake_up_all(>dead_wait_queue); \
WBERR("marked as dead"); \
} else if (r == -ENOMEM) { \
schedule_timeout_interruptible(msecs_to_jiffies(1000));\
} else if (r) { \
r = 0;\
WARN_ONCE(1, "PLEASE REPORT!!! I/O FAILED FOR UNKNOWN
REASON %d", r); \
} \
} while (r)
3.2 dead state never recover
As Dave's advice, I regard the error as fatal and provide no way to restart.
Removed blockup from message.
3.3 XFS corruption never reproduce
I think the previously discussed error is due to the
misbehavior of Writeboost in blocking up.
For example, some bios are not returned
which may corrupt the XFS AIL lock?
4. On-disk metadata layout changed and
max segment size is reduced to 512KB from 1MB
struct metablock_device was 13 bytes before.
This means that the metadata may straddle two sectors
which causes partial write.
To avoid this, I added padding to make it 16 bytes.
As a result, maximum log size shrinks to 512KB.
5. `flush_supported = true` added
I added `flush_supported = true` to .ctr
dm-cache and dm-thin also do
Re: [RFC 4/9] of/irq: Refactor interrupt-map parsing
On Fri, Nov 01, 2013 at 11:54:01AM -0700, Grant Likely wrote: > On Fri, 01 Nov 2013 10:53:17 -0700, Grant Likely > wrote: > > On Thu, 31 Oct 2013 11:57:14 -0700, Olof Johansson wrote: > > > On Wed, Oct 30, 2013 at 02:25:21PM -0700, Grant Likely wrote: > > > > (Sorry for HTML mail) > > > > > > > > Can you put #define DEBUG at the top of drivers/of/irq.c and send me the > > > > log output from before and after the commit? > > > > > > Here you go, quite verbose log below. > > > > > > Looks like we're tripping the "no reg passed in" checks, not sure if > > > related. > > > > I think I've found the bug. See if this helps... > > That one was broken. Try this instead. > > From bcbffc3d16f49451ef505dc021480aa061465a15 Mon Sep 17 00:00:00 2001 > From: Grant Likely > Date: Fri, 1 Nov 2013 10:50:50 -0700 > Subject: [PATCH] of: Fixup interrupt parsing failure. > > Signed-off-by: Grant Likely Well, it boots. That's an improvement. :) It is again going for the precalculated delay loop. I'm not sure why the code path diverged before, especially given the below irq request fail for MCT. I do see a bunch of new printk errors that I didn't use to though: [0.00] genirq: Flags mismatch irq 160. 00015200 (mct_comp_irq) vs. 00014a00 (mct_tick0) [0.040401] genirq: Flags mismatch irq 160. 00014a00 (mct_tick1) vs. 00014a00 (mct_tick0) [0.040405] exynos-mct: cannot register IRQ 160 So I don't think we're home safe yet. I need to spend some time this week actually debugging this... Good thing the merge window is delayed. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build warning after merge of the infiniband tree
Hi all,
After merging the infiniband tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/infiniband/hw/ipath/ipath_user_sdma.c: In function
'ipath_user_sdma_pin_pages':
drivers/infiniband/hw/ipath/ipath_user_sdma.c:283:6: warning: 'j' is used
uninitialized in this function [-Wuninitialized]
ret = get_user_pages_fast(addr, j, 0, pages);
^
Introduced by commit 18fec3c6bdcb ("IB/ipath: Convert
ipath_user_sdma_pin_pages() to use get_user_pages_fast()"). How did that
pass review or testing?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgprYBLsfqMAI.pgp
Description: PGP signature
converting unicore32 to gate_vma as done for arm (was Re: [PATCH] mm: cache largest vma)
On Sun, Nov 03, 2013 at 08:20:10PM -0800, Davidlohr Bueso wrote:
> > > diff --git a/arch/unicore32/include/asm/mmu_context.h
> > > b/arch/unicore32/include/asm/mmu_context.h
> > > index fb5e4c6..38cc7fc 100644
> > > --- a/arch/unicore32/include/asm/mmu_context.h
> > > +++ b/arch/unicore32/include/asm/mmu_context.h
> > > @@ -73,7 +73,7 @@ do { \
> > > else \
> > > mm->mmap = NULL; \
> > > rb_erase(_vma->vm_rb, >mm_rb); \
> > > - mm->mmap_cache = NULL; \
> > > + vma_clear_caches(mm); \
> > > mm->map_count--; \
> > > remove_vma(high_vma); \
> > > } \
BTW, this one needs an analog of
commit f9d4861fc32b995b1616775614459b8f266c803c
Author: Will Deacon
Date: Fri Jan 20 12:01:13 2012 +0100
ARM: 7294/1: vectors: use gate_vma for vectors user mapping
This code is a copy of older arm logics rewritten in that commit; unicore32
never got its counterpart. I have a [completely untested] variant sitting
in vfs.git#vm^; it's probably worth testing - if it works, we'll get rid
of one more place that needs to be aware of MM guts and unicore32 folks
will have fewer potential headache sources...
FWIW, after porting to the current tree it becomes the following; I'm not
sure whether we want VM_DONTEXPAND | VM_DONTDUMP set for this one, though...
Signed-off-by: Al Viro
---
diff --git a/arch/unicore32/include/asm/elf.h b/arch/unicore32/include/asm/elf.h
index 829042d..eeba258 100644
--- a/arch/unicore32/include/asm/elf.h
+++ b/arch/unicore32/include/asm/elf.h
@@ -87,8 +87,4 @@ struct mm_struct;
extern unsigned long arch_randomize_brk(struct mm_struct *mm);
#define arch_randomize_brk arch_randomize_brk
-extern int vectors_user_mapping(void);
-#define arch_setup_additional_pages(bprm, uses_interp) vectors_user_mapping()
-#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
-
#endif
diff --git a/arch/unicore32/include/asm/mmu_context.h
b/arch/unicore32/include/asm/mmu_context.h
index fb5e4c6..600b1b8 100644
--- a/arch/unicore32/include/asm/mmu_context.h
+++ b/arch/unicore32/include/asm/mmu_context.h
@@ -18,6 +18,7 @@
#include
#include
+#include
#define init_new_context(tsk, mm) 0
@@ -56,32 +57,4 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
#define deactivate_mm(tsk, mm) do { } while (0)
#define activate_mm(prev, next)switch_mm(prev, next, NULL)
-/*
- * We are inserting a "fake" vma for the user-accessible vector page so
- * gdb and friends can get to it through ptrace and /proc//mem.
- * But we also want to remove it before the generic code gets to see it
- * during process exit or the unmapping of it would cause total havoc.
- * (the macro is used as remove_vma() is static to mm/mmap.c)
- */
-#define arch_exit_mmap(mm) \
-do { \
- struct vm_area_struct *high_vma = find_vma(mm, 0x); \
- if (high_vma) { \
- BUG_ON(high_vma->vm_next); /* it should be last */ \
- if (high_vma->vm_prev) \
- high_vma->vm_prev->vm_next = NULL; \
- else \
- mm->mmap = NULL; \
- rb_erase(_vma->vm_rb, >mm_rb); \
- mm->mmap_cache = NULL; \
- mm->map_count--; \
- remove_vma(high_vma); \
- } \
-} while (0)
-
-static inline void arch_dup_mmap(struct mm_struct *oldmm,
-struct mm_struct *mm)
-{
-}
-
#endif
diff --git a/arch/unicore32/include/asm/page.h
b/arch/unicore32/include/asm/page.h
index 594b322..e79da8b 100644
--- a/arch/unicore32/include/asm/page.h
+++ b/arch/unicore32/include/asm/page.h
@@ -28,6 +28,8 @@ extern void copy_page(void *to, const void *from);
#define clear_user_page(page, vaddr, pg) clear_page(page)
#define copy_user_page(to, from, vaddr, pg)copy_page(to, from)
+#define __HAVE_ARCH_GATE_AREA 1
+
#undef STRICT_MM_TYPECHECKS
#ifdef STRICT_MM_TYPECHECKS
diff --git a/arch/unicore32/kernel/process.c b/arch/unicore32/kernel/process.c
index 778ebba..51d129e 100644
--- a/arch/unicore32/kernel/process.c
+++ b/arch/unicore32/kernel/process.c
@@ -307,21 +307,39 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
/*
* The vectors page is always readable from user space for the
- * atomic helpers and the signal restart code. Let's declare a mapping
- * for it so it is visible through ptrace and /proc//mem.
+ * atomic helpers and the signal restart code. Insert it into the
+ * gate_vma so that it is visible through ptrace and /proc//mem.
*/
+static struct vm_area_struct gate_vma = {
+ .vm_start = 0x,
+ .vm_end = 0x + PAGE_SIZE,
+ .vm_flags = VM_READ | VM_EXEC | VM_MAYREAD | VM_MAYEXEC |
+ VM_DONTEXPAND | VM_DONTDUMP,
+};
+
+static int __init gate_vma_init(void)
+{
+ gate_vma.vm_page_prot = PAGE_READONLY_EXEC;
+ return 0;
+}
+arch_initcall(gate_vma_init);
+
+struct vm_area_struct
linux-next: manual merge of the dt-rh tree with the imx-mxs tree
Hi Rob,
Today's linux-next merge of the dt-rh tree got a conflict in
Documentation/devicetree/bindings/vendor-prefixes.txt between commit
064d7f6c985a ("ARM: dts: Add vendor prefix for Voipac Technologies
s.r.o") from the imx-mxs tree and commit d6c3073e7fb5 ("DT: sort
vendor-prefixes.txt") from the dt-rh tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc Documentation/devicetree/bindings/vendor-prefixes.txt
index 8319844fb68d,640e86dc0ae7..
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@@ -65,13 -66,12 +67,13 @@@ snps Synopsys, Inc
stSTMicroelectronics
ste ST-Ericsson
stericssonST-Ericsson
- toumazToumaz
tiTexas Instruments
toshiba Toshiba Corporation
+ toumazToumaz
v3V3 Semiconductor
via VIA Technologies, Inc.
+voipacVoipac Technologies s.r.o.
+ winbond Winbond Electronics corp.
wlf Wolfson Microelectronics
wmWondermedia Technologies, Inc.
- winbond Winbond Electronics corp.
xlnx Xilinx
pgp30hKKO3qFi.pgp
Description: PGP signature
Re: [PATCH] [extcon]:remove freed groups caused the panic or warning in unregister flow
On 11/04/2013 12:47 PM, Liu, Chuansheng wrote: > > >> -Original Message- >> From: Chanwoo Choi [mailto:cw00.c...@samsung.com] >> Sent: Monday, November 04, 2013 10:37 AM >> To: Wang, Xiaoming >> Cc: myungjoo@samsung.com; linux-kernel@vger.kernel.org; Liu, >> Chuansheng; Zhang, Dongxing >> Subject: Re: [PATCH] [extcon]:remove freed groups caused the panic or warning >> in unregister flow > > >> As you comment, my opinion has memory leak problem. My mistake. >> But, I prefer to call 'device_unregister' at the end of >> extcon_dev_unregister(). >> To resolve kernel panic, I think we could use 'devm_kzalloc' instead of >> kzalloc/kfree. >> What is your opinion about my approach? >> > That sounds good. > But in function extcon_dev_register(), the device attributes are allocated > before device_register(), > and before device_register(), the function devm_kzalloc() can not be used. > We could use 'edev->dev->parent' pointer for devm_kzalloc() but it is ambiguous method. OK, applied this patch. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cache largest vma
On Sun, 2013-11-03 at 18:57 -0500, KOSAKI Motohiro wrote: > >> I'm slightly surprised this cache makes 15% hit. Which application > >> get a benefit? You listed a lot of applications, but I'm not sure > >> which is highly depending on largest vma. > > > > Well I chose the largest vma because it gives us a greater chance of > > being already cached when we do the lookup for the faulted address. > > > > The 15% improvement was with Hadoop. According to my notes it was at > > ~48% with the baseline kernel and increased to ~63% with this patch. > > > > In any case I didn't measure the rates on a per-task granularity, but at > > a general system level. When a system is first booted I can see that the > > mmap_cache access rate becomes the determinant factor and when adding a > > workload it doesn't change much. One exception to this was a kernel > > build, where we go from ~50% to ~89% hit rate on a vanilla kernel. > > I looked at this patch a bit. The worth of this is to improve the > cache hit ratio > of heap. > > 1) For single thread applications, heap is frequently largest mapping > in the process. Right. > 2) For java VM, "java -Xms1000m -Xmx1000m HelloWorld" makes following > /proc//smaps entry. That said, JVM allocate single heap even if > applications are multi threaded. Oh, this is new to me and nicely explains why I see the most benefit in java related workloads. > > c180-1 rw-p 00:00 0 > Size:1024000 kB > Rss: 244 kB > Pss: 244 kB > Shared_Clean: 0 kB > Shared_Dirty: 0 kB > Private_Clean: 0 kB > Private_Dirty: 244 kB > Referenced: 244 kB > Anonymous: 244 kB > AnonHugePages: 0 kB > Swap: 0 kB > KernelPageSize:4 kB > MMUPageSize: 4 kB > > That's good. > > However, we know there is a situation that this patch doesn't work. > glibc makes per thread heap (arena) by default. So, it is not to be > expected works well on glibc multi threaded programs. That's a > slightly big limitation. I think this is what Linus was referring to. > > Anyway, I haven't observed real performance difference because most > big penalty of find_vma come from taking mmap_sem, not rb-tree search. Yes, undoubtedly, which is why I'm using units of hit/miss rather than workload throughput. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cache largest vma
On Sun, 2013-11-03 at 11:12 +0100, Ingo Molnar wrote:
> * Davidlohr Bueso wrote:
>
> > While caching the last used vma already does a nice job avoiding
> > having to iterate the rbtree in find_vma, we can improve. After
> > studying the hit rate on a load of workloads and environments,
> > it was seen that it was around 45-50% - constant for a standard
> > desktop system (gnome3 + evolution + firefox + a few xterms),
> > and multiple java related workloads (including Hadoop/terasort),
> > and aim7, which indicates it's better than the 35% value documented
> > in the code.
> >
> > By also caching the largest vma, that is, the one that contains
> > most addresses, there is a steady 10-15% hit rate gain, putting
> > it above the 60% region. This improvement comes at a very low
> > overhead for a miss. Furthermore, systems with !CONFIG_MMU keep
> > the current logic.
> >
> > This patch introduces a second mmap_cache pointer, which is just
> > as racy as the first, but as we already know, doesn't matter in
> > this context. For documentation purposes, I have also added the
> > ACCESS_ONCE() around mm->mmap_cache updates, keeping it consistent
> > with the reads.
> >
> > Cc: Hugh Dickins
> > Cc: Michel Lespinasse
> > Cc: Ingo Molnar
> > Cc: Mel Gorman
> > Cc: Rik van Riel
> > Cc: Guan Xuetao
> > Signed-off-by: Davidlohr Bueso
> > ---
> > Please note that nommu and unicore32 arch are *untested*.
> >
> > I also have a patch on top of this one that caches the most
> > used vma, which adds another 8-10% hit rate gain, However,
> > since it does add a counter to the vma structure and we have
> > to do more logic in find_vma to keep track, I was hesitant about
> > the overhead. If folks are interested I can send that out as well.
>
> Would be interesting to see.
>
> Btw., roughly how many cycles/instructions do we save by increasing the
> hit rate, in the typical case (for example during a kernel build)?
Good point. The IPC from perf stat doesn't show any difference with or
without the patch -- note that this is probably the least interesting
one as we already get a really nice hit rate with the single mmap_cache.
I have yet to try it on the other workloads.
>
> That would be important to measure, so that we can get a ballpark figure
> for the cost/benefit equation.
>
> > Documentation/vm/locking | 4 +-
> > arch/unicore32/include/asm/mmu_context.h | 2 +-
> > include/linux/mm.h | 13 ++
> > include/linux/mm_types.h | 15 ++-
> > kernel/debug/debug_core.c| 17 +++-
> > kernel/fork.c| 2 +-
> > mm/mmap.c| 68
> >
> > 7 files changed, 87 insertions(+), 34 deletions(-)
> >
> > diff --git a/Documentation/vm/locking b/Documentation/vm/locking
> > index f61228b..b4e8154 100644
> > --- a/Documentation/vm/locking
> > +++ b/Documentation/vm/locking
> > @@ -42,8 +42,8 @@ The rules are:
> > for mm B.
> >
> > The caveats are:
> > -1. find_vma() makes use of, and updates, the mmap_cache pointer hint.
> > -The update of mmap_cache is racy (page stealer can race with other code
> > +1. find_vma() makes use of, and updates, the mmap_cache pointers hint.
> > +The updates of mmap_cache is racy (page stealer can race with other code
> > that invokes find_vma with mmap_sem held), but that is okay, since it
> > is a hint. This can be fixed, if desired, by having find_vma grab the
> > page_table_lock.
> > diff --git a/arch/unicore32/include/asm/mmu_context.h
> > b/arch/unicore32/include/asm/mmu_context.h
> > index fb5e4c6..38cc7fc 100644
> > --- a/arch/unicore32/include/asm/mmu_context.h
> > +++ b/arch/unicore32/include/asm/mmu_context.h
> > @@ -73,7 +73,7 @@ do { \
> > else \
> > mm->mmap = NULL; \
> > rb_erase(_vma->vm_rb, >mm_rb); \
> > - mm->mmap_cache = NULL; \
> > + vma_clear_caches(mm); \
> > mm->map_count--; \
> > remove_vma(high_vma); \
> > } \
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 8b6e55e..2c0f8ed 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -1534,8 +1534,21 @@ static inline void mm_populate(unsigned long addr,
> > unsigned long len)
> > /* Ignore errors */
> > (void) __mm_populate(addr, len, 1);
> > }
> > +
> > +static inline void vma_clear_caches(struct mm_struct *mm)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < NR_VMA_CACHES; i++)
> > + mm->mmap_cache[i] = NULL;
>
> Just curious: does GCC manage to open-code this as two stores of NULL?
>
> > +}
> > #else
> > static inline void mm_populate(unsigned long addr, unsigned long len) {}
> > +
> > +static inline void vma_clear_caches(struct mm_struct *mm)
> 1> +{
> > + mm->mmap_cache = NULL;
> > +}
> > #endif
> >
> > /* These take the mm semaphore themselves */
> > diff
Re: [PATCH] mm: cache largest vma
On Sun, 2013-11-03 at 10:51 -0800, Linus Torvalds wrote: > Ugh. This patch makes me angry. It looks way too ad-hoc. > > I can well imagine that our current one-entry cache is crap and could > be improved, but this looks too random. Indeed, my approach is random *because* I wanted to keep things as simple and low overhead as possible. Caching the largest VMA is probably as least invasive and as low as overhead as you can get in find_vma(). > Different code for the > CONFIG_MMU case? Same name, but for non-MMU it's a single entry, for > MMU it's an array? And the whole "largest" just looks odd. Plus why do > you set LAST_USED if you also set LARGEST? > > Did you try just a two- or four-entry pseudo-LRU instead, with a > per-thread index for "last hit"? Or even possibly a small fixed-size > hash table (say "idx = (add >> 10) & 3" or something)? > > And what happens for threaded models? Maybe we'd be much better off > making the cache be per-thread, and the flushing of the cache would be > a sequence number that has to match (so "vma_clear_cache()" ends up > just incrementing a 64-bit sequence number in the mm)? I will look into doing the vma cache per thread instead of mm (I hadn't really looked at the problem like this) as well as Ingo's suggestion on the weighted LRU approach. However, having seen that we can cheaply and easily reach around ~70% hit rate in a lot of workloads, makes me wonder how good is good enough? > Basically, my complaints boil down to "too random" and "too > specialized", and I can see (and you already comment on) this patch > being grown with even *more* ad-hoc random new cases (LAST, LARGEST, > MOST_USED - what's next?). And while I don't know if we should worry > about the threaded case, I do get the feeling that this ad-hoc > approach is guaranteed to never work for that, which makes me feel > that it's not just ad-hoc, it's also fundamentally limited. > > I can see us merging this patch, but I would really like to hear that > we do so because other cleaner approaches don't work well. In > particular, pseudo-LRU tends to be successful (and cheap) for caches. OK, will report back with comparisons, hopefully I'll have a better picture by then. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] per anon_vma lock and turn anon_vma rwsem lock to rwlock_t
On Fri, Nov 01, 2013 at 08:15:13PM -0700, Davidlohr Bueso wrote:
> On Fri, 2013-11-01 at 18:16 +0800, Yuanhan Liu wrote:
> > On Fri, Nov 01, 2013 at 09:21:46AM +0100, Ingo Molnar wrote:
> > >
> > > * Yuanhan Liu wrote:
> > >
> > > > > Btw., another _really_ interesting comparison would be against
> > > > > the latest rwsem patches. Mind doing such a comparison?
> > > >
> > > > Sure. Where can I get it? Are they on some git tree?
> > >
> > > I've Cc:-ed Tim Chen who might be able to point you to the latest
> > > version.
> > >
> > > The last on-lkml submission was in this thread:
> > >
> > > Subject: [PATCH v8 0/9] rwsem performance optimizations
> > >
> >
> > Thanks.
> >
> > I queued bunchs of tests about one hour ago, and already got some
> > results(If necessary, I can add more data tomorrow when those tests are
> > finished):
>
> What kind of system are you using to run these workloads on?
I queued jobs on 5 testboxes:
- brickland1: 120 core Ivybridge server
- lkp-ib03: 48 core Ivybridge server
- lkp-sb03: 32 core Sandybridge server
- lkp-nex04: 64 core NHM server
- lkp-a04:Atom server
>
> >
> >
> >v3.12-rc7 fe001e3de090e179f95d
> >
> > -9.3%
> > brickland1/micro/aim7/shared
> > +4.3%
> > lkp-ib03/micro/aim7/fork_test
> > +2.2%
> > lkp-ib03/micro/aim7/shared
> > -2.6% TOTAL
> > aim7.2000.jobs-per-min
> >
>
> Sorry if I'm missing something, but could you elaborate more on what
> these percentages represent?
v3.12-rc7 fe001e3de090e179f95d
-9.3% brickland1/micro/aim7/shared
-2.6% TOTAL aim7.2000.jobs-per-min
The comparation base is v3.12-rc7, and we got 9.3 performance regression
at commit fe001e3de090e179f95d, which is the head of rwsem performance
optimizations patch set.
"brickland1/micro/aim7/shared" tells the testbox(brickland1) and testcase:
shared workfile of aim7.
The last line tell what field we are comparing, and it's
"aim7.2000.jobs-per-min" in this case. 2000 means 2000 users in aim7.
> Are they anon vma rwsem + optimistic
> spinning patches vs anon vma rwlock?
I tested "[PATCH v8 0/9] rwsem performance optimizations" only.
>
> Also, I see your running aim7, you might be interested in some of the
> results I found when trying out Ingo's rwlock conversion patch on a
> largish 80 core system: https://lkml.org/lkml/2013/9/29/280
Besides aim7, I also tested dbench, hackbench, netperf, pigz. And as you
can image and see from the data, aim7 benifit most from the anon_vma
optimization stuff due to high contention of anon_vma lock.
Thanks.
--yliu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tpm: tpm_tis: Fix compile problems with CONFIG_PM_SLEEP/CONFIG_PNP
If CONFIG_PM_SLEEP=n, CONFIG_PNP=y we get this warning:
drivers/char/tpm/tpm_tis.c:706:13: warning: 'tpm_tis_reenable_interrupts'
defined but not used [-Wunused-function]
This seems to have been introduced in a2fa3fb0d 'tpm: convert tpm_tis driver
to use dev_pm_ops from legacy pm_ops'
Also, unpon reviewing, the #ifdefs around tpm_tis_pm are not right, the first
reference is protected, the second is not. tpm_tis_pm is always defined so we
can drop
the #ifdef.
Signed-off-by: Jason Gunthorpe
---
drivers/char/tpm/tpm_tis.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 1b74459..0732a1e 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -743,7 +743,7 @@ out_err:
return rc;
}
-#if defined(CONFIG_PNP) || defined(CONFIG_PM_SLEEP)
+#ifdef CONFIG_PM_SLEEP
static void tpm_tis_reenable_interrupts(struct tpm_chip *chip)
{
u32 intmask;
@@ -764,9 +764,7 @@ static void tpm_tis_reenable_interrupts(struct tpm_chip
*chip)
iowrite32(intmask,
chip->vendor.iobase + TPM_INT_ENABLE(chip->vendor.locality));
}
-#endif
-#ifdef CONFIG_PM_SLEEP
static int tpm_tis_resume(struct device *dev)
{
struct tpm_chip *chip = dev_get_drvdata(dev);
@@ -835,11 +833,9 @@ static struct pnp_driver tis_pnp_driver = {
.id_table = tpm_pnp_tbl,
.probe = tpm_tis_pnp_init,
.remove = tpm_tis_pnp_remove,
-#ifdef CONFIG_PM_SLEEP
.driver = {
.pm = _tis_pm,
},
-#endif
};
#define TIS_HID_USR_IDX sizeof(tpm_pnp_tbl)/sizeof(struct pnp_device_id) -2
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [extcon]:remove freed groups caused the panic or warning in unregister flow
> -Original Message- > From: Chanwoo Choi [mailto:cw00.c...@samsung.com] > Sent: Monday, November 04, 2013 10:37 AM > To: Wang, Xiaoming > Cc: myungjoo@samsung.com; linux-kernel@vger.kernel.org; Liu, > Chuansheng; Zhang, Dongxing > Subject: Re: [PATCH] [extcon]:remove freed groups caused the panic or warning > in unregister flow > As you comment, my opinion has memory leak problem. My mistake. > But, I prefer to call 'device_unregister' at the end of > extcon_dev_unregister(). > To resolve kernel panic, I think we could use 'devm_kzalloc' instead of > kzalloc/kfree. > What is your opinion about my approach? > That sounds good. But in function extcon_dev_register(), the device attributes are allocated before device_register(), and before device_register(), the function devm_kzalloc() can not be used.
Re: [PATCH] tpm/tpm_i2c_stm_st33: Check return code of get_burstcount (fix CID: 986658)
On Tue, 2013-10-29 at 20:07 -0700, Greg KH wrote: > On Wed, Oct 30, 2013 at 01:42:11AM +0100, Peter Hüwe wrote: > > Hi Greg, > > > > > > > > CID: 986658 > > > What is this field for? > > > > That's the scan id in the coverity database. > > If you think that's just noise I can leave it out. > > It's noise as not everyone can see it or make anything out of it, so > please don't include it. I think it's useful information for people who became aware of the bug via Coverity. It's not so different from a CVE ID, or a reference to one of the various enterprise distro bug trackers where bug reports often aren't public. Obviously this cannot be a substitute for explaining the bug properly in the commit message. Ben. -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
[PATCH 1/5 v2] tpm: Pull everything related to /dev/tpmX into tpm-dev.c
CLASS-dev.c is a common idiom for Linux subsystems
This pulls all the code related to the miscdev into tpm-dev.c and makes it
static. The identical file_operation structs in the drivers are purged and the
tpm common code unconditionally creates the miscdev.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Joel Schopp
---
drivers/char/tpm/Makefile | 2 +-
drivers/char/tpm/tpm-dev.c | 199
drivers/char/tpm/tpm-interface.c| 178 ++--
drivers/char/tpm/tpm.h | 11 +-
drivers/char/tpm/tpm_atmel.c| 10 --
drivers/char/tpm/tpm_i2c_atmel.c| 10 --
drivers/char/tpm/tpm_i2c_infineon.c | 10 --
drivers/char/tpm/tpm_i2c_nuvoton.c | 10 --
drivers/char/tpm/tpm_i2c_stm_st33.c | 10 --
drivers/char/tpm/tpm_ibmvtpm.c | 10 --
drivers/char/tpm/tpm_infineon.c | 10 --
drivers/char/tpm/tpm_nsc.c | 10 --
drivers/char/tpm/tpm_tis.c | 11 --
drivers/char/tpm/xen-tpmfront.c | 12 ---
14 files changed, 216 insertions(+), 277 deletions(-)
create mode 100644 drivers/char/tpm/tpm-dev.c
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index b80a400..d835e87 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -2,7 +2,7 @@
# Makefile for the kernel tpm device drivers.
#
obj-$(CONFIG_TCG_TPM) += tpm.o
-tpm-y := tpm-interface.o
+tpm-y := tpm-interface.o tpm-dev.o
tpm-$(CONFIG_ACPI) += tpm_ppi.o
ifdef CONFIG_ACPI
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
@@ -0,0 +1,199 @@
+/*
+ * Copyright (C) 2004 IBM Corporation
+ * Authors:
+ * Leendert van Doorn
+ * Dave Safford
+ * Reiner Sailer
+ * Kylene Hall
+ *
+ * Copyright (C) 2013 Obsidian Reearch Corp
+ * Jason Gunthorpe
+ *
+ * Device file system interface to the TPM
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ */
+#include
+#include
+#include
+#include "tpm.h"
+
+static void user_reader_timeout(unsigned long ptr)
+{
+ struct tpm_chip *chip = (struct tpm_chip *) ptr;
+
+ schedule_work(>work);
+}
+
+static void timeout_work(struct work_struct *work)
+{
+ struct tpm_chip *chip = container_of(work, struct tpm_chip, work);
+
+ mutex_lock(>buffer_mutex);
+ atomic_set(>data_pending, 0);
+ memset(chip->data_buffer, 0, TPM_BUFSIZE);
+ mutex_unlock(>buffer_mutex);
+}
+
+static int tpm_open(struct inode *inode, struct file *file)
+{
+ struct miscdevice *misc = file->private_data;
+ struct tpm_chip *chip = container_of(misc, struct tpm_chip,
+vendor.miscdev);
+
+ /* It's assured that the chip will be opened just once,
+* by the check of is_open variable, which is protected
+* by driver_lock. */
+ if (test_and_set_bit(0, >is_open)) {
+ dev_dbg(chip->dev, "Another process owns this TPM\n");
+ return -EBUSY;
+ }
+
+ chip->data_buffer = kzalloc(TPM_BUFSIZE, GFP_KERNEL);
+ if (chip->data_buffer == NULL) {
+ clear_bit(0, >is_open);
+ return -ENOMEM;
+ }
+
+ atomic_set(>data_pending, 0);
+
+ file->private_data = chip;
+ get_device(chip->dev);
+ return 0;
+}
+
+static ssize_t tpm_read(struct file *file, char __user *buf,
+ size_t size, loff_t *off)
+{
+ struct tpm_chip *chip = file->private_data;
+ ssize_t ret_size;
+ int rc;
+
+ del_singleshot_timer_sync(>user_read_timer);
+ flush_work(>work);
+ ret_size = atomic_read(>data_pending);
+ if (ret_size > 0) { /* relay data */
+ ssize_t orig_ret_size = ret_size;
+ if (size < ret_size)
+ ret_size = size;
+
+ mutex_lock(>buffer_mutex);
+ rc = copy_to_user(buf, chip->data_buffer, ret_size);
+ memset(chip->data_buffer, 0, orig_ret_size);
+ if (rc)
+ ret_size = -EFAULT;
+
+ mutex_unlock(>buffer_mutex);
+ }
+
+ atomic_set(>data_pending, 0);
+
+ return ret_size;
+}
+
+static ssize_t tpm_write(struct file *file, const char __user *buf,
+size_t size, loff_t *off)
+{
+ struct tpm_chip *chip = file->private_data;
+ size_t in_size = size;
+ ssize_t out_size;
+
+ /* cannot perform a write until the read has cleared
+ either via tpm_read or a user_read_timer timeout.
+ This also prevents splitted buffered writes from blocking here.
+ */
+ if (atomic_read(>data_pending) != 0)
+ return -EBUSY;
+
+ if (in_size > TPM_BUFSIZE)
+
[PATCH 2/5 v2] tpm: Pull everything related to sysfs into tpm-sysfs.c
CLASS-sysfs.c is a common idiom for linux subsystems.
This pulls all the sysfs attribute functions and related code
into tpm-sysfs.c. To support this change some constants are moved
from tpm.c to tpm.h and __tpm_pcr_read is made non-static and is
called tpm_pcr_read_dev.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Joel Schopp
---
drivers/char/tpm/Makefile | 2 +-
drivers/char/tpm/tpm-interface.c| 281 +--
drivers/char/tpm/tpm-sysfs.c| 318
drivers/char/tpm/tpm.h | 54 +++---
drivers/char/tpm/tpm_atmel.c| 16 --
drivers/char/tpm/tpm_i2c_atmel.c| 30
drivers/char/tpm/tpm_i2c_infineon.c | 30
drivers/char/tpm/tpm_i2c_nuvoton.c | 30
drivers/char/tpm/tpm_i2c_stm_st33.c | 25 ---
drivers/char/tpm/tpm_ibmvtpm.c | 28
drivers/char/tpm/tpm_infineon.c | 16 --
drivers/char/tpm/tpm_nsc.c | 16 --
drivers/char/tpm/tpm_tis.c | 30
drivers/char/tpm/xen-tpmfront.c | 31
14 files changed, 356 insertions(+), 551 deletions(-)
create mode 100644 drivers/char/tpm/tpm-sysfs.c
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index d835e87..4d85dd6 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -2,7 +2,7 @@
# Makefile for the kernel tpm device drivers.
#
obj-$(CONFIG_TCG_TPM) += tpm.o
-tpm-y := tpm-interface.o tpm-dev.o
+tpm-y := tpm-interface.o tpm-dev.o tpm-sysfs.o
tpm-$(CONFIG_ACPI) += tpm_ppi.o
ifdef CONFIG_ACPI
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 9b9bb7b..5ab3caa 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -32,13 +32,6 @@
#include "tpm.h"
#include "tpm_eventlog.h"
-enum tpm_duration {
- TPM_SHORT = 0,
- TPM_MEDIUM = 1,
- TPM_LONG = 2,
- TPM_UNDEFINED,
-};
-
#define TPM_MAX_ORDINAL 243
#define TSC_MAX_ORDINAL 12
#define TPM_PROTECTED_COMMAND 0x00
@@ -405,24 +398,6 @@ out:
#define TPM_DIGEST_SIZE 20
#define TPM_RET_CODE_IDX 6
-enum tpm_capabilities {
- TPM_CAP_FLAG = cpu_to_be32(4),
- TPM_CAP_PROP = cpu_to_be32(5),
- CAP_VERSION_1_1 = cpu_to_be32(0x06),
- CAP_VERSION_1_2 = cpu_to_be32(0x1A)
-};
-
-enum tpm_sub_capabilities {
- TPM_CAP_PROP_PCR = cpu_to_be32(0x101),
- TPM_CAP_PROP_MANUFACTURER = cpu_to_be32(0x103),
- TPM_CAP_FLAG_PERM = cpu_to_be32(0x108),
- TPM_CAP_FLAG_VOL = cpu_to_be32(0x109),
- TPM_CAP_PROP_OWNER = cpu_to_be32(0x111),
- TPM_CAP_PROP_TIS_TIMEOUT = cpu_to_be32(0x115),
- TPM_CAP_PROP_TIS_DURATION = cpu_to_be32(0x120),
-
-};
-
static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd,
int len, const char *desc)
{
@@ -442,7 +417,6 @@ static ssize_t transmit_cmd(struct tpm_chip *chip, struct
tpm_cmd_t *cmd,
}
#define TPM_INTERNAL_RESULT_SIZE 200
-#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
#define TPM_ORD_GET_CAP cpu_to_be32(101)
#define TPM_ORD_GET_RANDOM cpu_to_be32(70)
@@ -642,70 +616,6 @@ static int tpm_continue_selftest(struct tpm_chip *chip)
return rc;
}
-ssize_t tpm_show_enabled(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- cap_t cap;
- ssize_t rc;
-
- rc = tpm_getcap(dev, TPM_CAP_FLAG_PERM, ,
-"attempting to determine the permanent enabled state");
- if (rc)
- return 0;
-
- rc = sprintf(buf, "%d\n", !cap.perm_flags.disable);
- return rc;
-}
-EXPORT_SYMBOL_GPL(tpm_show_enabled);
-
-ssize_t tpm_show_active(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- cap_t cap;
- ssize_t rc;
-
- rc = tpm_getcap(dev, TPM_CAP_FLAG_PERM, ,
-"attempting to determine the permanent active state");
- if (rc)
- return 0;
-
- rc = sprintf(buf, "%d\n", !cap.perm_flags.deactivated);
- return rc;
-}
-EXPORT_SYMBOL_GPL(tpm_show_active);
-
-ssize_t tpm_show_owned(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- cap_t cap;
- ssize_t rc;
-
- rc = tpm_getcap(dev, TPM_CAP_PROP_OWNER, ,
-"attempting to determine the owner state");
- if (rc)
- return 0;
-
- rc = sprintf(buf, "%d\n", cap.owned);
- return rc;
-}
-EXPORT_SYMBOL_GPL(tpm_show_owned);
-
-ssize_t tpm_show_temp_deactivated(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- cap_t cap;
- ssize_t rc;
-
- rc = tpm_getcap(dev, TPM_CAP_FLAG_VOL, ,
-"attempting to determine the temporary state");
- if (rc)
- return 0;
-
- rc = sprintf(buf, "%d\n", cap.stclear_flags.deactivated);
- return rc;
-}
tpm: Remainder of earlier clean up
Here is the last five patches from the prior series I sent that didn't get picked up yet. There are no changes, these are just rebased onto 3.12rc7 + Peter's for-james branch. (Peter: Note, there are TPM changes to the Xen driver in 3.12rc7 that are not in your for-james branch) The intent of these patches is to reduce the duplicated code that is present in all the drivers by migrating it into the core. I've placed the patches on my github: https://github.com/jgunthorpe/linux/commits/for-tpm drivers/char/tpm/Makefile |2 +- drivers/char/tpm/tpm-dev.c | 213 + drivers/char/tpm/tpm-interface.c| 487 +--- drivers/char/tpm/tpm-sysfs.c| 318 +++ drivers/char/tpm/tpm.h | 83 +++ drivers/char/tpm/tpm_atmel.c| 28 + drivers/char/tpm/tpm_i2c_atmel.c| 42 +--- drivers/char/tpm/tpm_i2c_infineon.c | 42 +--- drivers/char/tpm/tpm_i2c_nuvoton.c | 42 +--- drivers/char/tpm/tpm_i2c_stm_st33.c | 41 +-- drivers/char/tpm/tpm_ibmvtpm.c | 40 +-- drivers/char/tpm/tpm_infineon.c | 28 + drivers/char/tpm/tpm_nsc.c | 28 + drivers/char/tpm/tpm_tis.c | 49 + drivers/char/tpm/xen-tpmfront.c | 45 +--- include/linux/tpm.h | 12 +++ 16 files changed, 624 insertions(+), 876 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5 v2] tpm: Make tpm-dev allocate a per-file structure
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.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Joel Schopp
---
drivers/char/tpm/tpm-dev.c | 100 ++---
drivers/char/tpm/tpm.h | 7
2 files changed, 57 insertions(+), 50 deletions(-)
diff --git a/drivers/char/tpm/tpm-dev.c b/drivers/char/tpm/tpm-dev.c
index 8d94e97..f492eb6 100644
--- a/drivers/char/tpm/tpm-dev.c
+++ b/drivers/char/tpm/tpm-dev.c
@@ -22,21 +22,34 @@
#include
#include "tpm.h"
+struct file_priv {
+ struct tpm_chip *chip;
+
+ /* Data passed to and from the tpm via the read/write calls */
+ atomic_t data_pending;
+ struct mutex buffer_mutex;
+
+ struct timer_list user_read_timer; /* user needs to claim result */
+ struct work_struct work;
+
+ u8 data_buffer[TPM_BUFSIZE];
+};
+
static void user_reader_timeout(unsigned long ptr)
{
- struct tpm_chip *chip = (struct tpm_chip *) ptr;
+ struct file_priv *priv = (struct file_priv *)ptr;
- schedule_work(>work);
+ schedule_work(>work);
}
static void timeout_work(struct work_struct *work)
{
- struct tpm_chip *chip = container_of(work, struct tpm_chip, work);
+ struct file_priv *priv = container_of(work, struct file_priv, work);
- mutex_lock(>buffer_mutex);
- atomic_set(>data_pending, 0);
- memset(chip->data_buffer, 0, TPM_BUFSIZE);
- mutex_unlock(>buffer_mutex);
+ mutex_lock(>buffer_mutex);
+ atomic_set(>data_pending, 0);
+ memset(priv->data_buffer, 0, sizeof(priv->data_buffer));
+ mutex_unlock(>buffer_mutex);
}
static int tpm_open(struct inode *inode, struct file *file)
@@ -44,6 +57,7 @@ static int tpm_open(struct inode *inode, struct file *file)
struct miscdevice *misc = file->private_data;
struct tpm_chip *chip = container_of(misc, struct tpm_chip,
vendor.miscdev);
+ struct file_priv *priv;
/* It's assured that the chip will be opened just once,
* by the check of is_open variable, which is protected
@@ -53,15 +67,20 @@ static int tpm_open(struct inode *inode, struct file *file)
return -EBUSY;
}
- chip->data_buffer = kzalloc(TPM_BUFSIZE, GFP_KERNEL);
- if (chip->data_buffer == NULL) {
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (priv == NULL) {
clear_bit(0, >is_open);
return -ENOMEM;
}
- atomic_set(>data_pending, 0);
+ priv->chip = chip;
+ atomic_set(>data_pending, 0);
+ mutex_init(>buffer_mutex);
+ setup_timer(>user_read_timer, user_reader_timeout,
+ (unsigned long)priv);
+ INIT_WORK(>work, timeout_work);
- file->private_data = chip;
+ file->private_data = priv;
get_device(chip->dev);
return 0;
}
@@ -69,28 +88,28 @@ static int tpm_open(struct inode *inode, struct file *file)
static ssize_t tpm_read(struct file *file, char __user *buf,
size_t size, loff_t *off)
{
- struct tpm_chip *chip = file->private_data;
+ struct file_priv *priv = file->private_data;
ssize_t ret_size;
int rc;
- del_singleshot_timer_sync(>user_read_timer);
- flush_work(>work);
- ret_size = atomic_read(>data_pending);
+ del_singleshot_timer_sync(>user_read_timer);
+ flush_work(>work);
+ ret_size = atomic_read(>data_pending);
if (ret_size > 0) { /* relay data */
ssize_t orig_ret_size = ret_size;
if (size < ret_size)
ret_size = size;
- mutex_lock(>buffer_mutex);
- rc = copy_to_user(buf, chip->data_buffer, ret_size);
- memset(chip->data_buffer, 0, orig_ret_size);
+ mutex_lock(>buffer_mutex);
+ rc = copy_to_user(buf, priv->data_buffer, ret_size);
+ memset(priv->data_buffer, 0, orig_ret_size);
if (rc)
ret_size = -EFAULT;
- mutex_unlock(>buffer_mutex);
+ mutex_unlock(>buffer_mutex);
}
- atomic_set(>data_pending, 0);
+ atomic_set(>data_pending, 0);
return ret_size;
}
@@ -98,7 +117,7 @@ static ssize_t tpm_read(struct file *file, char __user *buf,
static ssize_t tpm_write(struct file *file, const char __user *buf,
size_t size, loff_t *off)
{
- struct tpm_chip *chip = file->private_data;
+ struct file_priv *priv = file->private_data;
size_t in_size = size;
ssize_t out_size;
@@ -106,32 +125,33 @@ static ssize_t tpm_write(struct file *file, const char
__user *buf,
either
[PATCH 3/5 v2] tpm: Create a tpm_class_ops structure and use it in the drivers
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
---
drivers/char/tpm/tpm-interface.c| 10 --
drivers/char/tpm/tpm.h | 6 +++---
drivers/char/tpm/tpm_atmel.c| 2 +-
drivers/char/tpm/tpm_i2c_atmel.c| 2 +-
drivers/char/tpm/tpm_i2c_infineon.c | 2 +-
drivers/char/tpm/tpm_i2c_nuvoton.c | 2 +-
drivers/char/tpm/tpm_i2c_stm_st33.c | 2 +-
drivers/char/tpm/tpm_ibmvtpm.c | 2 +-
drivers/char/tpm/tpm_infineon.c | 2 +-
drivers/char/tpm/tpm_nsc.c | 2 +-
drivers/char/tpm/tpm_tis.c | 2 +-
drivers/char/tpm/xen-tpmfront.c | 2 +-
include/linux/tpm.h | 12
13 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 5ab3caa..0662b70 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1061,7 +1061,7 @@ EXPORT_SYMBOL_GPL(tpm_dev_release);
* pci_disable_device
*/
struct tpm_chip *tpm_register_hardware(struct device *dev,
- const struct tpm_vendor_specific *entry)
+ const struct tpm_class_ops *ops)
{
struct tpm_chip *chip;
@@ -1074,7 +1074,13 @@ struct tpm_chip *tpm_register_hardware(struct device
*dev,
mutex_init(>tpm_mutex);
INIT_LIST_HEAD(>list);
- memcpy(>vendor, entry, sizeof(struct tpm_vendor_specific));
+ chip->vendor.req_complete_mask = ops->req_complete_mask;
+ chip->vendor.req_complete_val = ops->req_complete_val;
+ chip->vendor.req_canceled = ops->req_canceled;
+ chip->vendor.recv = ops->recv;
+ chip->vendor.send = ops->send;
+ chip->vendor.cancel = ops->cancel;
+ chip->vendor.status = ops->status;
chip->dev_num = find_first_zero_bit(dev_mask, TPM_NUM_DEVICES);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 14ba162..a56af2c 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -64,8 +64,8 @@ enum tpm_duration {
struct tpm_chip;
struct tpm_vendor_specific {
- const u8 req_complete_mask;
- const u8 req_complete_val;
+ u8 req_complete_mask;
+ u8 req_complete_val;
bool (*req_canceled)(struct tpm_chip *chip, u8 status);
void __iomem *iobase; /* ioremapped address */
unsigned long base; /* TPM base address */
@@ -336,7 +336,7 @@ extern void tpm_gen_interrupt(struct tpm_chip *);
extern int tpm_do_selftest(struct tpm_chip *);
extern unsigned long tpm_calc_ordinal_duration(struct tpm_chip *, u32);
extern struct tpm_chip* tpm_register_hardware(struct device *,
-const struct tpm_vendor_specific *);
+ const struct tpm_class_ops *ops);
extern void tpm_dev_vendor_release(struct tpm_chip *);
extern void tpm_remove_hardware(struct device *);
extern int tpm_pm_suspend(struct device *);
diff --git a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
index 7e665d0..6069d13 100644
--- a/drivers/char/tpm/tpm_atmel.c
+++ b/drivers/char/tpm/tpm_atmel.c
@@ -121,7 +121,7 @@ static bool tpm_atml_req_canceled(struct tpm_chip *chip, u8
status)
return (status == ATML_STATUS_READY);
}
-static const struct tpm_vendor_specific tpm_atmel = {
+static const struct tpm_class_ops tpm_atmel = {
.recv = tpm_atml_recv,
.send = tpm_atml_send,
.cancel = tpm_atml_cancel,
diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
index fe8bdce..7727292 100644
--- a/drivers/char/tpm/tpm_i2c_atmel.c
+++ b/drivers/char/tpm/tpm_i2c_atmel.c
@@ -140,7 +140,7 @@ static bool i2c_atmel_req_canceled(struct tpm_chip *chip,
u8 status)
return false;
}
-static const struct tpm_vendor_specific i2c_atmel = {
+static const struct tpm_class_ops i2c_atmel = {
.status = i2c_atmel_read_status,
.recv = i2c_atmel_recv,
.send = i2c_atmel_send,
diff --git a/drivers/char/tpm/tpm_i2c_infineon.c
b/drivers/char/tpm/tpm_i2c_infineon.c
index ac1218f..52b9b2b 100644
--- a/drivers/char/tpm/tpm_i2c_infineon.c
+++ b/drivers/char/tpm/tpm_i2c_infineon.c
@@ -566,7 +566,7 @@ static bool tpm_tis_i2c_req_canceled(struct tpm_chip *chip,
u8 status)
return (status == TPM_STS_COMMAND_READY);
}
-static struct tpm_vendor_specific tpm_tis_i2c = {
+static const struct tpm_class_ops tpm_tis_i2c = {
.status = tpm_tis_i2c_status,
.recv = tpm_tis_i2c_recv,
.send = tpm_tis_i2c_send,
diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c
b/drivers/char/tpm/tpm_i2c_nuvoton.c
index 5cb9670..ea60aa3 100644
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
@@ -456,7 +456,7 @@ static bool
Re: linux-next: build failure after merge of the block tree
Hi Jens, On Sun, 3 Nov 2013 20:23:41 -0700 Jens Axboe wrote: > > Don't have ppc64 cross compiling handy, but the below should do the https://www.kernel.org/pub/tools/crosstool/ > trick. That patch fixes it for me. Compile-tested-by: Stephen Rothwell -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpgzAcRF4Yzb.pgp Description: PGP signature
[PATCH 4/5 v2] tpm: Use the ops structure instead of a copy in tpm_vendor_specific
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
---
drivers/char/tpm/tpm-interface.c| 34 --
drivers/char/tpm/tpm-sysfs.c| 2 +-
drivers/char/tpm/tpm.h | 9 +
drivers/char/tpm/tpm_i2c_stm_st33.c | 4 ++--
4 files changed, 16 insertions(+), 33 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 0662b70..5a2807c 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -353,7 +353,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
mutex_lock(>tpm_mutex);
- rc = chip->vendor.send(chip, (u8 *) buf, count);
+ rc = chip->ops->send(chip, (u8 *) buf, count);
if (rc < 0) {
dev_err(chip->dev,
"tpm_transmit: tpm_send: error %zd\n", rc);
@@ -365,12 +365,12 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char
*buf,
stop = jiffies + tpm_calc_ordinal_duration(chip, ordinal);
do {
- u8 status = chip->vendor.status(chip);
- if ((status & chip->vendor.req_complete_mask) ==
- chip->vendor.req_complete_val)
+ u8 status = chip->ops->status(chip);
+ if ((status & chip->ops->req_complete_mask) ==
+ chip->ops->req_complete_val)
goto out_recv;
- if (chip->vendor.req_canceled(chip, status)) {
+ if (chip->ops->req_canceled(chip, status)) {
dev_err(chip->dev, "Operation Canceled\n");
rc = -ECANCELED;
goto out;
@@ -380,13 +380,13 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char
*buf,
rmb();
} while (time_before(jiffies, stop));
- chip->vendor.cancel(chip);
+ chip->ops->cancel(chip);
dev_err(chip->dev, "Operation Timed out\n");
rc = -ETIME;
goto out;
out_recv:
- rc = chip->vendor.recv(chip, (u8 *) buf, bufsiz);
+ rc = chip->ops->recv(chip, (u8 *) buf, bufsiz);
if (rc < 0)
dev_err(chip->dev,
"tpm_transmit: tpm_recv: error %zd\n", rc);
@@ -807,12 +807,12 @@ EXPORT_SYMBOL_GPL(tpm_send);
static bool wait_for_tpm_stat_cond(struct tpm_chip *chip, u8 mask,
bool check_cancel, bool *canceled)
{
- u8 status = chip->vendor.status(chip);
+ u8 status = chip->ops->status(chip);
*canceled = false;
if ((status & mask) == mask)
return true;
- if (check_cancel && chip->vendor.req_canceled(chip, status)) {
+ if (check_cancel && chip->ops->req_canceled(chip, status)) {
*canceled = true;
return true;
}
@@ -828,7 +828,7 @@ int wait_for_tpm_stat(struct tpm_chip *chip, u8 mask,
unsigned long timeout,
bool canceled = false;
/* check current status */
- status = chip->vendor.status(chip);
+ status = chip->ops->status(chip);
if ((status & mask) == mask)
return 0;
@@ -855,7 +855,7 @@ again:
} else {
do {
msleep(TPM_TIMEOUT);
- status = chip->vendor.status(chip);
+ status = chip->ops->status(chip);
if ((status & mask) == mask)
return 0;
} while (time_before(jiffies, stop));
@@ -1027,9 +1027,6 @@ void tpm_dev_vendor_release(struct tpm_chip *chip)
if (!chip)
return;
- if (chip->vendor.release)
- chip->vendor.release(chip->dev);
-
clear_bit(chip->dev_num, dev_mask);
}
EXPORT_SYMBOL_GPL(tpm_dev_vendor_release);
@@ -1074,14 +1071,7 @@ struct tpm_chip *tpm_register_hardware(struct device
*dev,
mutex_init(>tpm_mutex);
INIT_LIST_HEAD(>list);
- chip->vendor.req_complete_mask = ops->req_complete_mask;
- chip->vendor.req_complete_val = ops->req_complete_val;
- chip->vendor.req_canceled = ops->req_canceled;
- chip->vendor.recv = ops->recv;
- chip->vendor.send = ops->send;
- chip->vendor.cancel = ops->cancel;
- chip->vendor.status = ops->status;
-
+ chip->ops = ops;
chip->dev_num = find_first_zero_bit(dev_mask, TPM_NUM_DEVICES);
if (chip->dev_num >= TPM_NUM_DEVICES) {
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index 3bcfed0..d2a8bca 100644
--- a/drivers/char/tpm/tpm-sysfs.c
+++ b/drivers/char/tpm/tpm-sysfs.c
@@ -245,7 +245,7 @@ static ssize_t cancel_store(struct device *dev, struct
device_attribute *attr,
if (chip == NULL)
return 0;
- chip->vendor.cancel(chip);
+ chip->ops->cancel(chip);
Re: [PATCH 4/4] mm/rmap.c: move anon_vma initialization code into anon_vma_ctor
On Fri, Nov 01, 2013 at 11:04:40AM -0700, Linus Torvalds wrote:
> On Fri, Nov 1, 2013 at 12:54 AM, Yuanhan Liu
> wrote:
> > @@ -67,19 +67,7 @@ static struct kmem_cache *anon_vma_chain_cachep;
> >
> > static inline struct anon_vma *anon_vma_alloc(void)
> > {
> > - struct anon_vma *anon_vma;
> > -
> > - anon_vma = kmem_cache_alloc(anon_vma_cachep, GFP_KERNEL);
> > - if (anon_vma) {
> > - atomic_set(_vma->refcount, 1);
> > - /*
> > -* Initialise the anon_vma root to point to itself. If
> > called
> > -* from fork, the root will be reset to the parents
> > anon_vma.
> > -*/
> > - anon_vma->root = anon_vma;
> > - }
> > -
> > - return anon_vma;
> > + return kmem_cache_alloc(anon_vma_cachep, GFP_KERNEL);
> > }
> >
> > static inline void anon_vma_free(struct anon_vma *anon_vma)
> > @@ -293,8 +281,15 @@ static void anon_vma_ctor(void *data)
> > struct anon_vma *anon_vma = data;
> >
> > rwlock_init(_vma->rwlock);
> > - atomic_set(_vma->refcount, 0);
> > anon_vma->rb_root = RB_ROOT;
> > +
> > + atomic_set(_vma->refcount, 1);
> > + /*
> > +* Initialise the anon_vma root to point to itself. If called
> > +* from fork, the root will be reset to the parents anon_vma.
> > +*/
> > + anon_vma->root = anon_vma;
> > +
> > }
>
> This looks totally invalid.
>
> The slab constructor is *not* called on every allocation.
Sorry, I didn't know that :(
And thanks for the detailed info very much!
--yliu
> Quite the
> reverse. Constructors are called when the underlying allocation is
> initially done, and then *not* done again, even if that particular
> object may be allocated and free'd many times.
>
> So the reason we can do
>
> atomic_set(_vma->refcount, 0);
>
> in a constructor is that anybody who frees that allocation will do so
> only when the refcount goes back down to zero, so zero is "valid
> state" while the slab entry stays on some percpu freelist.
>
> But the same is ABSOLUTELY NOT TRUE of the value "1", nor is it true
> of the anon_vma->root. When the anonvma gets free'd, those values will
> *not* be the same (the refcount has been decremented to zero, and the
> root will have been set to whatever the root was.
>
> So the rule about constructors is that the values they construct
> absolutely *have* to be the ones they get free'd with. With one
> special case.
>
> Using slab constructors is almost always a mistake. The original
> Sun/Solaris argument for them was to avoid initialization costs in
> allocators, and that was pure and utter bullshit (initializing a whole
> cacheline is generally cheaper than not initializing it and having to
> fetch it from L3 caches, but it does hide the cost so that it is now
> spread out in the users rather than in the allocator).
>
> So the _original_ reason for slab is pure and utter BS, and we've
> removed pretty much all uses of the constructors.
>
> In fact, the only valid reason for using them any more is the special
> case: locks and RCU.
>
> The reason we still have constructors is that sometimes we want to
> keep certain data structures "alive" across allocations together with
> SLAB_DESTROY_BY_RCU (which delays the actual *page* destroying by RCU,
> but the allocation can go to the free-list and get re-allocated
> without a RCU grace-period).
>
> But because allocations can now "stay active" over a
> alloc/free/alloc-again sequence, that means that the allocation
> sequence MUST NOT re-initialize the lock, because some RCU user may
> still be looking at those fields (and in particular, unlocking an
> allocation that in the meantime got free'd and re-allocated).
>
> So these days, the *only* valid pattern for slab constructors is
> together with SLAB_DESTROY_BY_RCU, and making sure that the fields
> that RCU readers look at (and in particular, change) are "stable" over
> such re-allocations.
>
> Your patch is horribly wrong.
>
> 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: linux-next: build failure after merge of the block tree
On Sun, Nov 03 2013, Jens Axboe wrote:
> On Mon, Nov 04 2013, Stephen Rothwell wrote:
> > Hi Jens,
> >
> > [I merged the block tree *before* the aio-direct tree today ...]
> >
> > After merging the block tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from include/linux/blkdev.h:18:0,
> > from drivers/block/ps3disk.c:22:
> > drivers/block/ps3disk.c: In function 'ps3disk_scatter_gather':
> > include/linux/bio.h:239:9: error: incompatible types when assigning to type
> > 'struct bio_vec *' from type 'struct bio_vec'
> >((bvl = bio_iter_iovec((bio), (iter))), 1); \
> > ^
> > include/linux/bio.h:243:2: note: in expansion of macro
> > '__bio_for_each_segment'
> > __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
> > ^
> > include/linux/blkdev.h:748:3: note: in expansion of macro
> > 'bio_for_each_segment'
> >bio_for_each_segment(bvl, _iter.bio, _iter.iter)
> >^
> > drivers/block/ps3disk.c:102:2: note: in expansion of macro
> > 'rq_for_each_segment'
> > rq_for_each_segment(bvec, req, iter) {
> > ^
> > include/linux/bio.h:239:41: warning: left-hand operand of comma expression
> > has no effect [-Wunused-value]
> >((bvl = bio_iter_iovec((bio), (iter))), 1); \
> > ^
> > include/linux/bio.h:243:2: note: in expansion of macro
> > '__bio_for_each_segment'
> > __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
> > ^
> > include/linux/blkdev.h:748:3: note: in expansion of macro
> > 'bio_for_each_segment'
> >bio_for_each_segment(bvl, _iter.bio, _iter.iter)
> >^
> > drivers/block/ps3disk.c:102:2: note: in expansion of macro
> > 'rq_for_each_segment'
> > rq_for_each_segment(bvec, req, iter) {
> > ^
> > include/linux/bio.h:240:45: error: request for member 'bv_len' in something
> > not a structure or union
> >bio_advance_iter((bio), &(iter), (bvl).bv_len))
> > ^
> > include/linux/bio.h:243:2: note: in expansion of macro
> > '__bio_for_each_segment'
> > __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
> > ^
> > include/linux/blkdev.h:748:3: note: in expansion of macro
> > 'bio_for_each_segment'
> >bio_for_each_segment(bvl, _iter.bio, _iter.iter)
> >^
> > drivers/block/ps3disk.c:102:2: note: in expansion of macro
> > 'rq_for_each_segment'
> > rq_for_each_segment(bvec, req, iter) {
> > ^
> >
> > I am not quite sure which commit caused this (maybe ed2d2f9a8265 ("block:
> > Abstract out bvec iterator")?). I have used the block tree from
> > next-20131031 again for today.
>
> Don't have ppc64 cross compiling handy, but the below should do the
> trick.
Checked, works for me. Committed and for-next branch updated.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: improve the description for dirty_background_ratio/dirty_ratio sysctl
From: Zheng Liu Now dirty_backgraound_ratio/dirty_ratio contains a percentage of total avaiable memory, which contains free pages and reclaimable pages. The number of these pages is not equal to the number of total system memory. But they are described as a percentage of total system memory in Documentation/sysctl/vm.txt. So we need to fix them to avoid misunderstanding. Cc: Rob Landley Cc: Andrew Morton Signed-off-by: Zheng Liu --- Documentation/sysctl/vm.txt | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 79a797e..1fbd4eb 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -119,8 +119,11 @@ other appears as 0 when read. dirty_background_ratio -Contains, as a percentage of total system memory, the number of pages at which -the background kernel flusher threads will start writing out dirty data. +Contains, as a percentage of total available memory that contains free pages +and reclaimable pages, the number of pages at which the background kernel +flusher threads will start writing out dirty data. + +The total avaiable memory is not equal to total system memory. == @@ -151,9 +154,11 @@ interval will be written out next time a flusher thread wakes up. dirty_ratio -Contains, as a percentage of total system memory, the number of pages at which -a process which is generating disk writes will itself start writing out dirty -data. +Contains, as a percentage of total available memory that contains free pages +and reclaimable pages, the number of pages at which a process which is +generating disk writes will itself start writing out dirty data. + +The total avaiable memory is not equal to total system memory. == -- 1.7.9.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Tick: Introduce tick_nohz_check() to check nohz enable status
On 2013年10月29日 18:29, Lan Tianyu wrote:
> On 10/29/2013 05:51 PM, Paul E. McKenney wrote:
>> On Tue, Oct 29, 2013 at 04:48:56PM +0800, Lan Tianyu wrote:
>>> In some cases, nohz enable status needs to be checked. E.G, in RCU
>>> and cpufreq
>>> ondemand governor. So add tick_nohz_check() to return
>>> tick_nohz_enabled value
>>> And use tick_nohz_check() instead of referencing tick_nohz_enabled in
>>> the rcutree_plugin.h.
>>>
>>> Signed-off-by: Lan Tianyu
>>
>> NACK on the rcutree change unless you put the ACCESS_ONCE() in.
>>
>> Or is there some reason that ACCESS_ONCE() is not needed? If so, what
>> is that reason?
>
> Hi Paul:
>
> Thanks for review. When I change this code, I find the tick_nohz_enabled
> isn't changed dynamically. It's only changed during parsing kernel
> params when "nohz=off/on" is set. Except this, it will not be changed.
> So I ignored ACCESS_ONCE(). If necessary, I can add it back.
Hi Paul:
Does this reason make sense to you? Or you still prefer to add
ACCESS_ONCE() in the new tick_nohz_check()?
>
>>
>> Thanx, Paul
>>
>>> ---
>>> include/linux/tick.h | 2 ++
>>> kernel/rcutree_plugin.h | 4 +---
>>> kernel/time/tick-sched.c | 8 +++-
>>> 3 files changed, 10 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/linux/tick.h b/include/linux/tick.h
>>> index 5128d33..a9c5374 100644
>>> --- a/include/linux/tick.h
>>> +++ b/include/linux/tick.h
>>> @@ -136,6 +136,7 @@ static inline int tick_nohz_tick_stopped(void)
>>> extern void tick_nohz_idle_enter(void);
>>> extern void tick_nohz_idle_exit(void);
>>> extern void tick_nohz_irq_exit(void);
>>> +extern int tick_nohz_check(void);
>>> extern ktime_t tick_nohz_get_sleep_length(void);
>>> extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
>>> extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
>>> @@ -155,6 +156,7 @@ static inline ktime_t
>>> tick_nohz_get_sleep_length(void)
>>>
>>> return len;
>>> }
>>> +static inline int tick_nohz_check(void) { return 0; }
>>> static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) {
>>> return -1; }
>>> static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) {
>>> return -1; }
>>> # endif /* !CONFIG_NO_HZ_COMMON */
>>> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
>>> index 130c97b..af167ec 100644
>>> --- a/kernel/rcutree_plugin.h
>>> +++ b/kernel/rcutree_plugin.h
>>> @@ -1627,8 +1627,6 @@ module_param(rcu_idle_gp_delay, int, 0644);
>>> static int rcu_idle_lazy_gp_delay = RCU_IDLE_LAZY_GP_DELAY;
>>> module_param(rcu_idle_lazy_gp_delay, int, 0644);
>>>
>>> -extern int tick_nohz_enabled;
>>> -
>>> /*
>>>* Try to advance callbacks for all flavors of RCU on the current CPU.
>>>* Afterwards, if there are any callbacks ready for immediate
>>> invocation,
>>> @@ -1718,7 +1716,7 @@ static void rcu_prepare_for_idle(int cpu)
>>> int tne;
>>>
>>> /* Handle nohz enablement switches conservatively. */
>>> -tne = ACCESS_ONCE(tick_nohz_enabled);
>>> +tne = tick_nohz_check();
>>> if (tne != rdtp->tick_nohz_enabled_snap) {
>>> if (rcu_cpu_has_callbacks(cpu, NULL))
>>> invoke_rcu_core(); /* force nohz to see update. */
>>> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
>>> index 3612fc7..d381a22 100644
>>> --- a/kernel/time/tick-sched.c
>>> +++ b/kernel/time/tick-sched.c
>>> @@ -361,7 +361,13 @@ void __init tick_nohz_init(void)
>>> /*
>>>* NO HZ enabled ?
>>>*/
>>> -int tick_nohz_enabled __read_mostly = 1;
>>> +static int tick_nohz_enabled __read_mostly = 1;
>>> +
>>> +int tick_nohz_check(void)
>>> +{
>>> +returntick_nohz_enabled;
>>> +}
>>> +EXPORT_SYMBOL_GPL(tick_nohz_check);
>>>
>>> /*
>>>* Enable / Disable tickless mode
>>> --
>>> 1.8.4.rc0.1.g8f6a3e5.dirty
>>>
>>
>
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 04/13] uprobes: allow arch-specific initialization
On 11/01/13 09:52, Oleg Nesterov wrote: On 10/31, David Long wrote: On 10/28/13 14:58, Oleg Nesterov wrote: On 10/22, David Long wrote: I simply do not understand why uprobes.c uses module_init/module_exit, it can't be compiled as a module. I guess that makes sense, assuming it can never be made a module. I saw you recent commit for this. I think that module_exit/exit_uprobes should be killed, and module_init() should be turned into __initcall(). uprobes-arm.c can have another one. I will see if I can make this work. If this can't work, then we need the new hook (this patch). But in this case please update the changelog to explain the reason. Right now the arch-specific initialization call is done in the middle of the generic initialization code, but I don't know that it *has* to be that way. I have some concern too about getting the order right, since these are built from different makefiles. Not sure I understand... But grep shows a lot of core_initcall()'s in arch/arm/ which do register_undef_hook(). And I guess you can use any initcall level. Just to close on this, I implemented your suggested __initcall change and it tested out fine. -dl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the block tree
On Mon, Nov 04 2013, Stephen Rothwell wrote:
> Hi Jens,
>
> [I merged the block tree *before* the aio-direct tree today ...]
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/blkdev.h:18:0,
> from drivers/block/ps3disk.c:22:
> drivers/block/ps3disk.c: In function 'ps3disk_scatter_gather':
> include/linux/bio.h:239:9: error: incompatible types when assigning to type
> 'struct bio_vec *' from type 'struct bio_vec'
>((bvl = bio_iter_iovec((bio), (iter))), 1); \
> ^
> include/linux/bio.h:243:2: note: in expansion of macro
> '__bio_for_each_segment'
> __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
> ^
> include/linux/blkdev.h:748:3: note: in expansion of macro
> 'bio_for_each_segment'
>bio_for_each_segment(bvl, _iter.bio, _iter.iter)
>^
> drivers/block/ps3disk.c:102:2: note: in expansion of macro
> 'rq_for_each_segment'
> rq_for_each_segment(bvec, req, iter) {
> ^
> include/linux/bio.h:239:41: warning: left-hand operand of comma expression
> has no effect [-Wunused-value]
>((bvl = bio_iter_iovec((bio), (iter))), 1); \
> ^
> include/linux/bio.h:243:2: note: in expansion of macro
> '__bio_for_each_segment'
> __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
> ^
> include/linux/blkdev.h:748:3: note: in expansion of macro
> 'bio_for_each_segment'
>bio_for_each_segment(bvl, _iter.bio, _iter.iter)
>^
> drivers/block/ps3disk.c:102:2: note: in expansion of macro
> 'rq_for_each_segment'
> rq_for_each_segment(bvec, req, iter) {
> ^
> include/linux/bio.h:240:45: error: request for member 'bv_len' in something
> not a structure or union
>bio_advance_iter((bio), &(iter), (bvl).bv_len))
> ^
> include/linux/bio.h:243:2: note: in expansion of macro
> '__bio_for_each_segment'
> __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
> ^
> include/linux/blkdev.h:748:3: note: in expansion of macro
> 'bio_for_each_segment'
>bio_for_each_segment(bvl, _iter.bio, _iter.iter)
>^
> drivers/block/ps3disk.c:102:2: note: in expansion of macro
> 'rq_for_each_segment'
> rq_for_each_segment(bvec, req, iter) {
> ^
>
> I am not quite sure which commit caused this (maybe ed2d2f9a8265 ("block:
> Abstract out bvec iterator")?). I have used the block tree from
> next-20131031 again for today.
Don't have ppc64 cross compiling handy, but the below should do the
trick.
diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
index 8d1a19ccff0a..c120d70d3fb3 100644
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -94,7 +94,7 @@ static void ps3disk_scatter_gather(struct ps3_storage_device
*dev,
{
unsigned int offset = 0;
struct req_iterator iter;
- struct bio_vec *bvec;
+ struct bio_vec bvec;
unsigned int i = 0;
size_t size;
void *buf;
@@ -105,14 +105,14 @@ static void ps3disk_scatter_gather(struct
ps3_storage_device *dev,
__func__, __LINE__, i, bio_sectors(iter.bio),
iter.bio->bi_iter.bi_sector);
- size = bvec->bv_len;
- buf = bvec_kmap_irq(bvec, );
+ size = bvec.bv_len;
+ buf = bvec_kmap_irq(, );
if (gather)
memcpy(dev->bounce_buf+offset, buf, size);
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
- flush_kernel_dcache_page(bvec->bv_page);
+ flush_kernel_dcache_page(bvec.bv_page);
bvec_kunmap_irq(buf, );
i++;
}
@@ -129,7 +129,7 @@ static int ps3disk_submit_request_sg(struct
ps3_storage_device *dev,
#ifdef DEBUG
unsigned int n = 0;
- struct bio_vec *bv;
+ struct bio_vec bv;
struct req_iterator iter;
rq_for_each_segment(bv, req, iter)
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the block tree
Hi Jens,
[I merged the block tree *before* the aio-direct tree today ...]
After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/linux/blkdev.h:18:0,
from drivers/block/ps3disk.c:22:
drivers/block/ps3disk.c: In function 'ps3disk_scatter_gather':
include/linux/bio.h:239:9: error: incompatible types when assigning to type
'struct bio_vec *' from type 'struct bio_vec'
((bvl = bio_iter_iovec((bio), (iter))), 1); \
^
include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
__bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
^
include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
bio_for_each_segment(bvl, _iter.bio, _iter.iter)
^
drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
rq_for_each_segment(bvec, req, iter) {
^
include/linux/bio.h:239:41: warning: left-hand operand of comma expression has
no effect [-Wunused-value]
((bvl = bio_iter_iovec((bio), (iter))), 1); \
^
include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
__bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
^
include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
bio_for_each_segment(bvl, _iter.bio, _iter.iter)
^
drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
rq_for_each_segment(bvec, req, iter) {
^
include/linux/bio.h:240:45: error: request for member 'bv_len' in something not
a structure or union
bio_advance_iter((bio), &(iter), (bvl).bv_len))
^
include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
__bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
^
include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
bio_for_each_segment(bvl, _iter.bio, _iter.iter)
^
drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
rq_for_each_segment(bvec, req, iter) {
^
I am not quite sure which commit caused this (maybe ed2d2f9a8265 ("block:
Abstract out bvec iterator")?). I have used the block tree from
next-20131031 again for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpT_ydH67c3M.pgp
Description: PGP signature
Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
On Sun, Nov 3, 2013 at 4:10 PM, Linus Torvalds wrote: > And the reason I mention "4.0" is that it would be a lovely time to do > that. Roughly a years heads-up that "ok, after 3.19 (or whatever), > we're doing a release with *just* fixes, and then that becomes 4.0". > > Comments? Unless you are planning to kick out releases significantly faster than you have over the past few years ... then "roughly a year" and "3.19" don't really match up. 3.17 would be a better guess. This means you are ignoring the Knuth-ites who think 3.14 should be followed by 3.141, 3.1415, 3.14159 etc. :-) What would the rules look like for a "fixes-only" release? With no merge window of new stuff would you enforce a "nothing except regressions" policy after -rcN (for N >=3). That might feel odd in a fixes release to tell someone that their fix isn't going to be taken. But we all want the fixes release to converge quickly so we can return to "ooh shiny" stuff - so "too big, too late" should probably still be the rule. Perhaps all the bugs to be fixed need to be logged in bugzilla.kernel.org with some "for 4.0" tag by the start of this fixes window - then we'd have some bound on the release criteria for 4.0? -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/32] 3.4.68-stable review
At Fri, 1 Nov 2013 14:43:11 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.68 release. > There are 32 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Nov 3 21:41:40 UTC 2013. > Anything received after that time might be too late. # oops, too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build warnings after merge of the modules tree
Hi Rusty,
After merging the modules tree, today's linux-next build (x86_64
allmodconfig) produced these warning:
WARNING: vmlinux: 'pci_restore_msi_state' exported twice. Previous export was
in vmlinux
WARNING: vmlinux: '__mod_zone_page_state' exported twice. Previous export was
in vmlinux
WARNING: vmlinux: 'scsi_prep_return' exported twice. Previous export was in
vmlinux
WARNING: vmlinux: 'hvc_poll' exported twice. Previous export was in vmlinux
WARNING: vmlinux: 'nfs_clear_inode' exported twice. Previous export was in
vmlinux
(just some samples ... it scrolled off my scrollback :-()
Presumably caused by commit e0f244c63fc9 ("asmlinkage, module: Make
ksymtab and kcrctab symbols and __this_module __visible"). (reverting
that commit makes the warnings go away.)
I have used the modules tree from next-20131101 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpWN25W4SEwV.pgp
Description: PGP signature
Re: [PATCH] [extcon]:remove freed groups caused the panic or warning in unregister flow
On 11/04/2013 11:07 AM, Wang, Xiaoming wrote:
> Dear Choi
>
> -Original Message-
> From: Chanwoo Choi [mailto:cw00.c...@samsung.com]
> Sent: Monday, November 04, 2013 9:43 AM
> To: Wang, Xiaoming
> Cc: myungjoo@samsung.com; linux-kernel@vger.kernel.org; Liu, Chuansheng;
> Zhang, Dongxing
> Subject: Re: [PATCH] [extcon]:remove freed groups caused the panic or warning
> in unregister flow
>
> Hi Wang,
>
>> drivers/extcon/extcon-class.c |3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/extcon/extcon-class.c
>> b/drivers/extcon/extcon-class.c index 148382f..48f4669 100644
>> --- a/drivers/extcon/extcon-class.c
>> +++ b/drivers/extcon/extcon-class.c
>> @@ -794,6 +794,8 @@ void extcon_dev_unregister(struct extcon_dev *edev)
>> return;
>> }
>>
>> +device_unregister(edev->dev);
>> +
>> if (edev->mutually_exclusive && edev->max_supported) {
>> for (index = 0; edev->mutually_exclusive[index];
>> index++)
>> @@ -814,7 +816,6 @@ void extcon_dev_unregister(struct extcon_dev *edev)
>> if (switch_class)
>> class_compat_remove_link(switch_class, edev->dev, NULL); #endif
>> -device_unregister(edev->dev);
>> put_device(edev->dev);
>> }
>> EXPORT_SYMBOL_GPL(extcon_dev_unregister);
>>
>
> I think we could only apply following patch instead of moving the position of
> device_unregister().
>
> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
> index 148382f..ff27b19 100644
> --- a/drivers/extcon/extcon-class.c
> +++ b/drivers/extcon/extcon-class.c
> @@ -805,10 +805,8 @@ void extcon_dev_unregister(struct extcon_dev *edev)
> for (index = 0; index < edev->max_supported; index++)
> kfree(edev->cables[index].attr_g.name);
>
> - if (edev->max_supported) {
> - kfree(edev->extcon_dev_type.groups);
> + if (edev->max_supported)
> kfree(edev->cables);
> - }
>
> #if defined(CONFIG_ANDROID)
> if (switch_class)
>
> Thanks,
> Chanwoo Choi
>
> I don't agree with you.
> Why do not you want moving the position of device_unregister()?
> It will cause the memory leak if has not kfree
> edev->extcon_dev_type.groups as your patch do firstly. And if you think kfree
> edev->extcon_dev_type.groups is meaningless well then kfree
> edev->extcon_dev_type.groups in function exton_dev_register (line 756)also
> should be removed I think. What do you think?
>
As you comment, my opinion has memory leak problem. My mistake.
But, I prefer to call 'device_unregister' at the end of extcon_dev_unregister().
To resolve kernel panic, I think we could use 'devm_kzalloc' instead of
kzalloc/kfree.
What is your opinion about my approach?
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xfs: simplify kmem_{zone_}zalloc
Hi Dave,
On 11/02/2013 04:58 AM, Dave Chinner wrote:
> On Fri, Nov 01, 2013 at 06:25:11PM +0800, Gu Zheng wrote:
>> Introduce flag KM_ZERO which is used to alloc zeroed entry, and convert
>> kmem_{zone_}zalloc to call kmem_{zone_}alloc() with KM_ZERO directly,
>> in order to avoid the setting to zero step.
>>
>>
>> Signed-off-by: Gu Zheng
>> ---
>> fs/xfs/kmem.c | 14 ++
>> fs/xfs/kmem.h |7 ++-
>> 2 files changed, 8 insertions(+), 13 deletions(-)
>>
>> diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c
>> index a02cfb9..d56fcc9 100644
>> --- a/fs/xfs/kmem.c
>> +++ b/fs/xfs/kmem.c
>> @@ -65,12 +65,7 @@ kmem_alloc(size_t size, xfs_km_flags_t flags)
>> void *
>> kmem_zalloc(size_t size, xfs_km_flags_t flags)
>> {
>> -void*ptr;
>> -
>> -ptr = kmem_alloc(size, flags);
>> -if (ptr)
>> -memset((char *)ptr, 0, (int)size);
>> -return ptr;
>> +return kmem_alloc(size, flags | KM_ZERO);
>> }
>>
>> void *
>> @@ -132,10 +127,5 @@ kmem_zone_alloc(kmem_zone_t *zone, xfs_km_flags_t flags)
>> void *
>> kmem_zone_zalloc(kmem_zone_t *zone, xfs_km_flags_t flags)
>> {
>> -void*ptr;
>> -
>> -ptr = kmem_zone_alloc(zone, flags);
>> -if (ptr)
>> -memset((char *)ptr, 0, kmem_cache_size(zone));
>> -return ptr;
>> +return kmem_zone_alloc(zone, flags | KM_ZERO);
>> }
>
> These functions should be made static inline functions in kmem.h
> seeing as they are now just a simple wrapper.
Agree. Thanks for your suggestion, I'll follow it.
>
> Otherwise it's a nice cleanup.
Thanks:)
Regards,
Gu
>
> Cheers,
>
> 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/
[f2fs-dev] [PATCH] f2fs: remove unnecessary TestClearPageError when wait pages writeback
In wait_on_node_pages_writeback we will test and clear error flag for all pages
in radix tree, but not necessary.
So we only do this for pages belong to the specified inode.
Signed-off-by: Chao Yu
---
fs/f2fs/node.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index b527ed4..4ac4150 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1170,10 +1170,11 @@ int wait_on_node_pages_writeback(struct f2fs_sb_info
*sbi, nid_t ino)
if (page->index > end)
continue;
- if (ino && ino_of_node(page) == ino)
+ if (ino && ino_of_node(page) == ino) {
wait_on_page_writeback(page);
- if (TestClearPageError(page))
- ret = -EIO;
+ if (TestClearPageError(page))
+ ret = -EIO;
+ }
}
pagevec_release();
cond_resched();
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [extcon]:remove freed groups caused the panic or warning in unregister flow
Dear Choi
-Original Message-
From: Chanwoo Choi [mailto:cw00.c...@samsung.com]
Sent: Monday, November 04, 2013 9:43 AM
To: Wang, Xiaoming
Cc: myungjoo@samsung.com; linux-kernel@vger.kernel.org; Liu, Chuansheng;
Zhang, Dongxing
Subject: Re: [PATCH] [extcon]:remove freed groups caused the panic or warning
in unregister flow
Hi Wang,
> drivers/extcon/extcon-class.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/extcon/extcon-class.c
> b/drivers/extcon/extcon-class.c index 148382f..48f4669 100644
> --- a/drivers/extcon/extcon-class.c
> +++ b/drivers/extcon/extcon-class.c
> @@ -794,6 +794,8 @@ void extcon_dev_unregister(struct extcon_dev *edev)
> return;
> }
>
> + device_unregister(edev->dev);
> +
> if (edev->mutually_exclusive && edev->max_supported) {
> for (index = 0; edev->mutually_exclusive[index];
> index++)
> @@ -814,7 +816,6 @@ void extcon_dev_unregister(struct extcon_dev *edev)
> if (switch_class)
> class_compat_remove_link(switch_class, edev->dev, NULL); #endif
> - device_unregister(edev->dev);
> put_device(edev->dev);
> }
> EXPORT_SYMBOL_GPL(extcon_dev_unregister);
>
I think we could only apply following patch instead of moving the position of
device_unregister().
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 148382f..ff27b19 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -805,10 +805,8 @@ void extcon_dev_unregister(struct extcon_dev *edev)
for (index = 0; index < edev->max_supported; index++)
kfree(edev->cables[index].attr_g.name);
- if (edev->max_supported) {
- kfree(edev->extcon_dev_type.groups);
+ if (edev->max_supported)
kfree(edev->cables);
- }
#if defined(CONFIG_ANDROID)
if (switch_class)
Thanks,
Chanwoo Choi
I don't agree with you.
Why do not you want moving the position of device_unregister()?
It will cause the memory leak if has not kfree
edev->extcon_dev_type.groups as your patch do firstly. And if you think kfree
edev->extcon_dev_type.groups is meaningless well then kfree
edev->extcon_dev_type.groups in function exton_dev_register (line 756)also
should be removed I think. What do you think?
Thanks
Xiaoming.
Re: [PATCH] mfd: max77693: Fix up bug of wrong interrupt number
Ping!
Thanks,
Chanwoo Choi
On 10/10/2013 10:05 AM, Chanwoo Choi wrote:
> The max77693 MFD device use irq domain method which has hardware interrupt
> number
> and virtual interrupt number getting through irq domain mapping. This patch
> use hardware interrupt number instead of virtual interrupt number to get
> struct irq_data.
>
> Signed-off-by: Chanwoo Choi
> Signed-off-by: Kyungmin Park
> ---
> drivers/mfd/max77693-irq.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/max77693-irq.c b/drivers/mfd/max77693-irq.c
> index 1029d01..66b58fe 100644
> --- a/drivers/mfd/max77693-irq.c
> +++ b/drivers/mfd/max77693-irq.c
> @@ -128,7 +128,8 @@ static void max77693_irq_sync_unlock(struct irq_data
> *data)
> static const inline struct max77693_irq_data *
> irq_to_max77693_irq(struct max77693_dev *max77693, int irq)
> {
> - return _irqs[irq];
> + struct irq_data *data = irq_get_irq_data(irq);
> + return _irqs[data->hwirq];
> }
>
> static void max77693_irq_mask(struct irq_data *data)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 0/3] ARM: dts: exynos: Add missing dt data to bring up kernel featurea
This patchset add missing dt data to bring up kernel feature - GPS_ALIVE power domain - PMU - Clock data for Multi core timer Changes since v2: - Delete MAUDIO power domain Changes since v1: - Fix wrong address of GPS_ALIVE power domain Chanwoo Choi (2): ARM: dts: exynos4212: Add PMU dt data for pmu-irq ARM: dts: exynos4x12: Add gps_alive power domain for exynos4x12 Marek Szyprowski (1): ARM: dts: exynos4212: Add missing clock for multi core timer arch/arm/boot/dts/exynos4212.dtsi | 8 arch/arm/boot/dts/exynos4x12.dtsi | 5 + 2 files changed, 13 insertions(+) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 3/3] ARM: dts: exynos4x12: Add gps_alive power domain for exynos4x12
This patch gps_alive power domain to exynos4x12.dtsi.
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index ad531fe..3f5b416 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -35,6 +35,11 @@
reg = <0x10023CA0 0x20>;
};
+ pd_gps_alive: gps-alive-power-domain@10023D00 {
+ compatible = "samsung,exynos4210-pd";
+ reg = <0x10023D00 0x20>;
+ };
+
clock: clock-controller@1003 {
compatible = "samsung,exynos4412-clock";
reg = <0x1003 0x2>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 1/3] ARM: dts: exynos4212: Add PMU dt data for pmu-irq
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4212.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 6f34d7f..3081bae 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -56,4 +56,10 @@
<0x5 0 1 12 0>;
};
};
+
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupt-parent = <>;
+ interrupts = <2 2>, <3 2>;
+ };
};
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 2/3] ARM: dts: exynos4212: Add missing clock for multi core timer
From: Marek Szyprowski
Signed-off-by: Marek Szyprowski
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4212.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 3081bae..d7a3fbc 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -43,6 +43,8 @@
interrupt-parent = <_map>;
interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
<4 0>, <5 0>;
+ clocks = < 3>, < 344>;
+ clock-names = "fin_pll", "mct";
mct_map: mct-map {
#interrupt-cells = <2>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [extcon]:remove freed groups caused the panic or warning in unregister flow
Hi Wang,
> drivers/extcon/extcon-class.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
> index 148382f..48f4669 100644
> --- a/drivers/extcon/extcon-class.c
> +++ b/drivers/extcon/extcon-class.c
> @@ -794,6 +794,8 @@ void extcon_dev_unregister(struct extcon_dev *edev)
> return;
> }
>
> + device_unregister(edev->dev);
> +
> if (edev->mutually_exclusive && edev->max_supported) {
> for (index = 0; edev->mutually_exclusive[index];
> index++)
> @@ -814,7 +816,6 @@ void extcon_dev_unregister(struct extcon_dev *edev)
> if (switch_class)
> class_compat_remove_link(switch_class, edev->dev, NULL);
> #endif
> - device_unregister(edev->dev);
> put_device(edev->dev);
> }
> EXPORT_SYMBOL_GPL(extcon_dev_unregister);
>
I think we could only apply following patch instead of moving the position of
device_unregister().
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 148382f..ff27b19 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -805,10 +805,8 @@ void extcon_dev_unregister(struct extcon_dev *edev)
for (index = 0; index < edev->max_supported; index++)
kfree(edev->cables[index].attr_g.name);
- if (edev->max_supported) {
- kfree(edev->extcon_dev_type.groups);
+ if (edev->max_supported)
kfree(edev->cables);
- }
#if defined(CONFIG_ANDROID)
if (switch_class)
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] Exynos 5410 Dual cluster support
Today, I checked 3.12 but I could not find this patch. Is it dead or under development? If it is under development, any external link? Thanks with sincerely respects... On Mon, Oct 14, 2013 at 5:08 PM, Vyacheslav Tyrtov wrote: > The series of patches represent support of Exynos 5410 SoC > > The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture. > Patches allow all 8 CPU cores (4 x A7 and 4 x A15) to run at the same time > > Patches add new platform description, support of clock controller, > dual cluster support and device tree for Exynos 5410 > > Has been build on v3.12-rc5. > Has been tested on Exynos 5410 reference board (exynos_defconfig). > > Thanks, > Vyacheslav. > > > Changelog: > > v2: > In drivers/clk/samsung/clk-exynos5410.c > 1. Clock driver converted to use preprocessor macros instead of enums. >Clock IDs now defined in include/dt-bindings/clock/exynos5410.h. > 2. Unused spinlock removed. > 3. Function exynos5410_clk_init defined as static. >Struct exynos5410_fixed_rate_ext_clks defined as static. >Struct exynos5410_mux_clks defined as static. >Struct exynos5410_div_clks defined as static. >Struct exynos5410_gate_clks defined as static. > 4. Removed aliases. > 5. Pll's magic register offsets defined as preprocessor macros. > 6. Redundant check of device_node pointer removed. > > In arch/arm/boot/dts/exynos5410.dtsi > 1. dwmmcX nodes renamed to mmc. >dwmmc_X renamed to mmc_X. >dwmmc status="disabled" field added. >fifo-depth field moved from arch/arm/boot/dts/exynos5410-smdk5410.dts > 2. Blank lines added where necessary. > 3. cpu@ suffixes corrected. > 4. edcs node removed. > 5. Hexadecimal characters case corrected. > 6. Clock IDs replaced with preprocessor macros. > > In arch/arm/boot/dts/exynos5410-smdk5410.dts > 1. status = "okay" field added to mmc nodes. > > In arch/arm/mach-exynos/edcs.c > 1. "kfs_" prefix replaced with "edcs_" > 2. EDCS_CPUS_PER_CLUSTER and EDCS_CLUSTERS defined instead of MCPM's values. > 3. Cache handling sequence borrowed from arch/arm/mach-vexpress/tc2_pm.c > 4. mcpm_sync_init() call added. > 5. power management functions reworked. > > Other > 1. Documentation/devicetree/bindings/clock/exynos5410-clock.txt corrected. > 2. Removed smdk5410_defconfig. Instead SOC_EXYNOS5410 now selects MCPM and >ARM_CCI in arch/arm/mach-exynos/Kconfig. > 3. edcs_status driver removed. > > Tarek Dakhran (4): > ARM: EXYNOS: Add support for EXYNOS5410 SoC > clk: exynos5410: register clocks using common clock framework > ARM: EXYNOS: add Exynos Dual Cluster Support > ARM: dts: Add initial device tree support for EXYNOS5410 > > .../devicetree/bindings/clock/exynos5410-clock.txt | 37 +++ > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/exynos5410-smdk5410.dts | 65 + > arch/arm/boot/dts/exynos5410.dtsi | 209 > arch/arm/mach-exynos/Kconfig | 12 + > arch/arm/mach-exynos/Makefile | 2 + > arch/arm/mach-exynos/common.c | 18 ++ > arch/arm/mach-exynos/edcs.c| 270 > + > arch/arm/mach-exynos/include/mach/map.h| 1 + > arch/arm/mach-exynos/mach-exynos5-dt.c | 1 + > arch/arm/plat-samsung/include/plat/cpu.h | 8 + > drivers/clk/samsung/Makefile | 1 + > drivers/clk/samsung/clk-exynos5410.c | 251 +++ > include/dt-bindings/clock/exynos5410.h | 175 + > 14 files changed, 1051 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/exynos5410-clock.txt > create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts > create mode 100644 arch/arm/boot/dts/exynos5410.dtsi > create mode 100644 arch/arm/mach-exynos/edcs.c > create mode 100644 drivers/clk/samsung/clk-exynos5410.c > create mode 100644 include/dt-bindings/clock/exynos5410.h > > -- > 1.8.1.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/ > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [extcon]:remove freed groups caused the panic or warning in unregister flow
> -Original Message-
> From: Wang, Xiaoming
> Sent: Saturday, November 02, 2013 6:48 AM
> To: myungjoo@samsung.com; cw00.c...@samsung.com;
> linux-kernel@vger.kernel.org
> Cc: Liu, Chuansheng; Zhang, Dongxing; Wang, Xiaoming
> Subject: [PATCH] [extcon]:remove freed groups caused the panic or warning in
> unregister flow
>
> (edev->extcon_dev_type.groups) has been freed before device_unregister.
> extcon_dev_unregister -> kfree(edev->extcon_dev_type.groups)
> then device_unregister -> device_del -> device_remove_attrs
> -> device_remove_groups(dev, type->groups);
> panic because type->groups has been freed.
>
This patch fix the panic that using the freed memory.
Tested-by: Liu, Chuansheng
Reviewed-by: Liu, Chuansheng
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[GIT PULL] Remove h8300 platform support
Hi Linus,
Please pull the patch series to remove support for the h8300 platform
from signed tag:
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
h8300-for-linus
The patch series has been in -next for more than one relase cycle.
I did get a number of Acks, and no objections.
The series is based off 3.12-rc1. A test merge against 3.12 was successful
with no conflicts. After the merge, there is still a single Kconfig dependency
against H8300 in drivers/parport/Kconfig. This dependency will be removed
with a separate cleaup patch ('Kconfig cleanup (PARPORT_PC dependencies)'
from Mark Salter).
Thanks,
Guenter
--
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
tags/h8300-for-linus
for you to fetch changes up to ca40e295018f7df46c7b8a12c3e82b88418322fb:
fs/minix: Drop dependency on H8300 (2013-09-16 18:20:25 -0700)
Remove h8300 platform
Guenter Roeck (8):
Drop support for Renesas H8/300 (h8300) architecture
ide: Drop H8/300 driver
net/ethernet: smsc9194: Drop conditional code for H8/300
net/ethernet: Drop H8/300 Ethernet driver
watchdog: Drop references to H8300 architecture
Drop MAINTAINERS entry for H8/300
Drop remaining references to H8/300 architecture
fs/minix: Drop dependency on H8300
Documentation/scheduler/sched-arch.txt |5 -
MAINTAINERS |8 -
arch/h8300/Kconfig | 108
arch/h8300/Kconfig.cpu | 171 --
arch/h8300/Kconfig.debug | 68 ---
arch/h8300/Kconfig.ide | 44 --
arch/h8300/Makefile | 71 ---
arch/h8300/README| 38 --
arch/h8300/boot/Makefile | 22 -
arch/h8300/boot/compressed/Makefile | 37 --
arch/h8300/boot/compressed/head.S| 47 --
arch/h8300/boot/compressed/misc.c| 180 --
arch/h8300/boot/compressed/vmlinux.lds | 32 -
arch/h8300/boot/compressed/vmlinux.scr |9 -
arch/h8300/defconfig | 42 --
arch/h8300/include/asm/Kbuild|8 -
arch/h8300/include/asm/asm-offsets.h |1 -
arch/h8300/include/asm/atomic.h | 146 -
arch/h8300/include/asm/barrier.h | 29 -
arch/h8300/include/asm/bitops.h | 211 ---
arch/h8300/include/asm/bootinfo.h|2 -
arch/h8300/include/asm/bug.h | 12 -
arch/h8300/include/asm/bugs.h| 16 -
arch/h8300/include/asm/cache.h | 13 -
arch/h8300/include/asm/cachectl.h| 14 -
arch/h8300/include/asm/cacheflush.h | 40 --
arch/h8300/include/asm/checksum.h| 102
arch/h8300/include/asm/cmpxchg.h | 60 --
arch/h8300/include/asm/cputime.h |6 -
arch/h8300/include/asm/current.h | 25 -
arch/h8300/include/asm/dbg.h |2 -
arch/h8300/include/asm/delay.h | 38 --
arch/h8300/include/asm/device.h |7 -
arch/h8300/include/asm/div64.h |1 -
arch/h8300/include/asm/dma.h | 15 -
arch/h8300/include/asm/elf.h | 101
arch/h8300/include/asm/emergency-restart.h |6 -
arch/h8300/include/asm/fb.h | 12 -
arch/h8300/include/asm/flat.h| 26 -
arch/h8300/include/asm/fpu.h |1 -
arch/h8300/include/asm/ftrace.h |1 -
arch/h8300/include/asm/futex.h |6 -
arch/h8300/include/asm/gpio-internal.h | 52 --
arch/h8300/include/asm/hardirq.h | 19 -
arch/h8300/include/asm/hw_irq.h |1 -
arch/h8300/include/asm/io.h | 358 ---
arch/h8300/include/asm/irq.h | 49 --
arch/h8300/include/asm/irq_regs.h|1 -
arch/h8300/include/asm/irqflags.h| 43 --
arch/h8300/include/asm/kdebug.h |1 -
arch/h8300/include/asm/kmap_types.h |6 -
arch/h8300/include/asm/local.h |6 -
arch/h8300/include/asm/local64.h |1 -
arch/h8300/include/asm/mc146818rtc.h |9 -
arch/h8300/include/asm/mmu_context.h | 32 -
arch/h8300/include/asm/mutex.h |9 -
Re: [PATCH] kernel: trace: blktrace: remove redundent memcpy() in compat_blk_trace_setup()
On 11/04/2013 01:36 AM, Steven Rostedt wrote: > A quick review of this patch looks fine to me. > > Although, using ARRAY_SIZE() for a character string seems to me a bit > over paranoid. But I'm fine with it, as it makes sure that the string > is an array and not a pointer. > Yeah. > Jens, > > Can you give me an Acked-by? > I am glad to. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fixes for 3.12-final
On Sun, Nov 03, 2013 at 03:39:14PM -0800, Linus Torvalds wrote:
> On Sun, Nov 3, 2013 at 11:54 AM, Al Viro wrote:
> >
> > IIRC, at some point such an attempt has seriously hurt iget() on 32bit
> > boxen, so we ended up deciding not to go there. Had been years ago,
> > though...
>
> Yeah, I think the circumstances have changed. 32-bit is less
> important, and iget() is much less critical than it used to be (all
> *normal* inode lookups are through the direct dentry pointer).
>
> Sure, ARM is a few years away from 64-bit being common, but it's
> happening. And I suspect even 32-bit ARM doesn't have the annoying
> issues that x86-32 had with 64-bit values (namely using up a lot of
> the register space).
>
> So unless there's something hidden that makes it really nasty, I do
> suspect that a "u64 i_ino" would just be the right thing to do. Rather
> than adding workarounds for our current odd situation on 32-bit
> kernels (and just wasting time on 64-bit kernels).
Maybe... OTOH, that crap really needs doing something only with nfsd on
filesystems with 64bit inode numbers living on 32bit hosts (i_ino is
unsigned long, not u32 right now). Hell knows; I'm somewhat concerned about
setups like e.g. ext2 on VIA C7 mini-itx boxen (and yes, I do have such
beasts). FWIW, the whole area around iget_locked() needs profiling;
in particular, I really wonder if this
spin_lock(>i_lock);
if (inode->i_ino != ino) {
spin_unlock(>i_lock);
continue;
}
if (inode->i_sb != sb) {
spin_unlock(>i_lock);
continue;
}
makes any sense; both ->i_ino and ->i_sb are assign-once and assigned before
the sucker gets inserted into hash, so inode_hash_lock provides all barriers
we need here. Sure, we want to grab ->i_lock for this:
if (inode->i_state & (I_FREEING|I_WILL_FREE)) {
__wait_on_freeing_inode(inode);
goto repeat;
}
__iget(inode);
spin_unlock(>i_lock);
but that's once per find_inode{_fast,}(), not once per inode in hash chain
being traversed...
And picking them from dentries is fine, but every time we associate an inode
with dentry, we end up walking the hash chain in icache and the time we
spend in that loop can get sensitive - we are holding a system-wide lock,
after all (and the way it's implemented right now, we end up touching
a cacheline in a bunch of struct inode for no good reason).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kernel: trace: blktrace: remove redundent memcpy() in compat_blk_trace_setup()
On 11/04/2013 04:15 AM, Steven Rostedt wrote: > On Sun, 3 Nov 2013 11:16:39 -0700 > Jens Axboe wrote: > >> Thanks, but I'll just queue it up with the other block bits for 3.13. >> > > OK, > Thank all of you. :-) -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] extcon: arizona: Fix race with microphone detection and removal
On 10/28/2013 01:19 AM, Charles Keepax wrote:
> The microphone detection code is run as delayed work to provide
> additional debounce, it is possible that the jack could have been
> removed by the time we process the microphone detection. Turn this case
> into a no op.
>
> Signed-off-by: Charles Keepax
> ---
>
> As Lee Jones took the first patch (extcon: arizona: Add
> defines for microphone detection levels) of my series
> yesterday through his tree I have based this patch on the
> extcon tree without that change applied.
>
> Thanks,
> Charles
>
> drivers/extcon/extcon-arizona.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index dac8ba0..9c20850 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -773,6 +773,12 @@ static void arizona_micd_detect(struct work_struct *work)
>
> mutex_lock(>lock);
>
> + if (!info->cable) {
> + dev_dbg(arizona->dev, "Ignoring MICDET for removed cable\n");
> + mutex_unlock(>lock);
> + return;
> + }
> +
> for (i = 0; i < 10 && !(val & 0x7fc); i++) {
> ret = regmap_read(arizona->regmap, ARIZONA_MIC_DETECT_3, );
> if (ret != 0) {
>
This patch has build break as below log:
drivers/extcon/extcon-arizona.c: In function ‘arizona_micd_detect’:
drivers/extcon/extcon-arizona.c:776:11: error: ‘struct arizona_extcon_info’ has
no member named ‘cable’
The arizona_extcon_info structure hasn't included 'cable' field.
Cheers,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] extcon: arizona: Fix reset of HPDET after race with removal
Hi Charles,
On 10/28/2013 01:19 AM, Charles Keepax wrote:
> We need to make sure we reset back to our starting state, especially
> making sure that we have disabled poll in the register cache.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/extcon/extcon-arizona.c |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index ec9a14e..dac8ba0 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -596,9 +596,15 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
> dev_err(arizona->dev, "Failed to report HP/line: %d\n",
> ret);
>
> +done:
> + /* Reset back to starting range */
> + regmap_update_bits(arizona->regmap,
> +ARIZONA_HEADPHONE_DETECT_1,
> +ARIZONA_HP_IMPEDANCE_RANGE_MASK | ARIZONA_HP_POLL,
> +0);
> +
> arizona_extcon_do_magic(info, 0);
>
> -done:
> if (id_gpio)
> gpio_set_value_cansleep(id_gpio, 0);
>
>
The arizona_hpdet_do_id() return only either -EAGIN or 0(zero).
extcon-arizona driver could never execute 'goto done;' statement.
ret = arizona_hpdet_do_id(info, , );
if (ret == -EAGAIN) {
goto out;
} else if (ret < 0) {
goto done;
}
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 on top of 3/3] ACPI / hotplug: Remove unnecessary get_device() and put_device()
From: Rafael J. Wysocki
The get_device() and put_device() calls made by acpi_bus_device_eject()
and acpi_scan_hot_remove(), respectively, are not necessary any more,
so remove them.
Signed-off-by: Rafael J. Wysocki
---
Actually, after https://patchwork.kernel.org/patch/3134091/ the
get_device() and put_device() calls may be dropped just fine.
Thanks,
Rafael
---
drivers/acpi/scan.c |5 -
1 file changed, 5 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -205,7 +205,6 @@ static int acpi_scan_hot_remove(struct a
/* If there is no handle, the device node has been unregistered. */
if (!handle) {
dev_dbg(>dev, "ACPI handle missing\n");
- put_device(>dev);
return -EINVAL;
}
@@ -226,7 +225,6 @@ static int acpi_scan_hot_remove(struct a
dev_warn(errdev, "Offline disabled.\n");
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
acpi_bus_online, NULL, NULL, NULL);
- put_device(>dev);
return -EPERM;
}
acpi_bus_offline(handle, 0, (void *)false, (void **));
@@ -245,7 +243,6 @@ static int acpi_scan_hot_remove(struct a
acpi_walk_namespace(ACPI_TYPE_ANY, handle,
ACPI_UINT32_MAX, acpi_bus_online,
NULL, NULL, NULL);
- put_device(>dev);
return -EBUSY;
}
}
@@ -256,7 +253,6 @@ static int acpi_scan_hot_remove(struct a
acpi_bus_trim(device);
/* Device node has been unregistered. */
- put_device(>dev);
device = NULL;
acpi_evaluate_lck(handle, 0);
@@ -310,7 +306,6 @@ static void acpi_bus_device_eject(acpi_h
if (handler->hotplug.mode == AHM_CONTAINER)
kobject_uevent(>dev.kobj, KOBJ_OFFLINE);
- get_device(>dev);
error = acpi_scan_hot_remove(device);
if (error == -EPERM) {
goto err_support;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND 2][PATCH] hwrng: add randomness to system from rng sources
When bringing a new RNG source online, it seems like it would make sense to use some of its bytes to make the system entropy pool more random, as done with all sorts of other devices that contain per-device or per-boot differences. Signed-off-by: Kees Cook --- Added linux-crypto list to CC. --- drivers/char/hw_random/core.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index a0f7724852eb..6e5bb68a708c 100644 --- a/drivers/char/hw_random/core.c +++ b/drivers/char/hw_random/core.c @@ -41,6 +41,7 @@ #include #include #include +#include #include @@ -305,6 +306,8 @@ int hwrng_register(struct hwrng *rng) int must_register_misc; int err = -EINVAL; struct hwrng *old_rng, *tmp; + unsigned char bytes[16]; + int bytes_read; if (rng->name == NULL || (rng->data_read == NULL && rng->read == NULL)) @@ -348,6 +351,10 @@ int hwrng_register(struct hwrng *rng) } INIT_LIST_HEAD(>list); list_add_tail(>list, _list); + + bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1); + if (bytes_read > 0) + add_device_randomness(bytes, bytes_read); out_unlock: mutex_unlock(_mutex); out: -- 1.7.9.5 -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] ACPI scan and hotplug fixes for 3.14
Hi, The following three patches fix some issues that we have in the common ACPI hotplug infrastructure. If anyone sees any problems with them, please let me know. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3.12 released .. and no merge window yet .. and 4.0 plans?
I was vacillating whether to do an rc8 or just cut the final 3.12, but since the biggest reason to *not* do a final release was not so much the state of the code, as simply the fact that I'll be traveling with very bad internet connection next week, I didn't really want to delay the release. Sure, we had a number of driver reverts, and there was an annoying auto-NUMA memory corruption fix series, but none of it was really worth delaying 3.12 for. But the fact that I'm going to be (effectively) off-line next week means that I'm *not* opening the merge window for 3.13 yet - since I won't have the bandwidth to really do merges anyway. That doesn't mean that you can't send me pull request for the merge window early, of course - maintainers can *always* send their pull requests early rather than late, if they have everything lined up and ready. But if you have some feature that still wants polishing, you basically get a free week to do that. So the two-week merge window for 3.13 will start a week from now. You have an extra week. But that also means that I will be doubly disappointed in anybody who then leaves their merge request until the *end* of that two-week merge window. Anyway.. Onto a totally different topic: we're getting to release numbers where I have to take off my socks to count that high again. I'm ok with 3., but I don't want us to get to the kinds of crazy numbers we had in the 2.x series, so at some point we're going to cut over from 3.x to 4.x, just to keep the numbers small and easy to remember. We're not there yet, but I would actually prefer to not go into the twenties, so I can see it happening in a year or so, and we'll have 4.0 follow 3.19 or something like that. Now, it's just a number (since we've long since given up on feature-related releases), and it's at least a year away, so why do I even mention it at all? The reason I mention it is because I've been mulling over something Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked at the Q session whether we could do a release with just stability and bug-fixes, and I pooh-poohed it because I didn't see most of us having the attention span required for that (cough*cough*moronic*woodland creature*cough*cough). So I may be pessimistic, but I'd expect many developers would go "Let's hunt bugs.. Wait. Oooh, shiny" and go off doing some new feature after all instead. Or just take that release off. But I do wonder.. Maybe it would be possible, and I'm just unfairly projecting my own inner squirrel onto other kernel developers. If we have enough heads-up that people *know* that for one release (and companies/managers know that too) the only patches that get accepted are the kind that fix bugs, maybe people really would have sufficient attention span that it could work. And the reason I mention "4.0" is that it would be a lovely time to do that. Roughly a years heads-up that "ok, after 3.19 (or whatever), we're doing a release with *just* fixes, and then that becomes 4.0". Comments? Linus --- Alex Deucher (3): drm/radeon: use sw CTS/N values for audio on DCE4+ drm/radeon: disable bapm on KB drm/radeon/dpm: fix incompatible casting on big endian Andrey Moiseev (1): Input: i8042 - i8042_flush fix for a full 8042 buffer Arnaldo Carvalho de Melo (1): perf tools: Fix up /proc/PID/maps parsing Baruch Siach (1): xtensa: don't use alternate signal stack on threads Bastien Nocera (1): Input: wacom - export battery scope Chen LinX (1): mm/pagewalk.c: fix walk_page_range() access of wrong PTEs Dan Carpenter (6): uml: check length in exitcode_proc_write() staging: ozwpan: prevent overflow in oz_cdev_write() aacraid: missing capable() check in compat ioctl staging: wlags49_h2: buffer overflow setting station name Staging: bcm: info leak in ioctl Staging: sb105x: info leak in mp_get_count() Daniel Vetter (1): drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb David Herrmann (2): Input: move name/timer init to input_alloc_dev() drm: allow DRM_IOCTL_VERSION on render-nodes Deng-Cheng Zhu (1): MIPS: Perf: Fix 74K cache map Dinh Nguyen (1): clk: socfpga: Fix incorrect sdmmc clock name Greg KH (1): USB: Maintainers change for usb serial drivers Greg Kroah-Hartman (12): Revert "USB: pl2303: distinguish between original and cloned HX chips" Revert "pl2303: improve the chip type detection/distinction" Revert "pl2303: improve the chip type information output on startup" Revert "pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup()" Revert "usb: pl2303: add two comments concerning the supported baud rates with HX chips" Revert "usb: pl2303: also use the divisor based baud rate encoding method for baud rates < 115200 with HX chips" Revert "usb: pl2303: increase the allowed baud rate range for the divisor based
[PATCH 3/3] ACPI / hotplug: Merge device hot-removal routines
From: Rafael J. Wysocki
The only substantial difference between acpi_bus_device_eject() and
acpi_bus_hot_remove_device() is the get_device() done by the former
which is supposed to be done by callers of the latter. However,
at least one caller of acpi_bus_hot_remove_device(), which is
handle_root_bridge_removal(), doesn't do that and generally it
won't be necessary to do that at all if ACPI handles, rather than
struct acpi_device objects, are passed between ACPI hotplug routines,
because the correctness of those routines already depends on the
persistence of ACPI handles (that may not be an entirely correct
assumption in theory, but in practice it has been good enough for a
long time).
For this reason, modify acpi_bus_device_eject() to take two
arguments, an ACPI handle and event code, and make
acpi_bus_hot_remove_device() call it internally. Moreover, rework
acpi_bus_hot_remove_device() so that it only takes one argument,
an ACPI handle, and make acpi_scan_bus_device_check() queue up
acpi_bus_hot_remove_device() instead of acpi_bus_device_eject()
itself. After these changes, handle_root_bridge_removal() may
be replaced with async execution of acpi_bus_hot_remove_device()
with the ACPI handle of the root passed to it as the argument.
However, since acpi_eject_store() also needs to execute
acpi_bus_device_eject() asynchronously and it needs to pass a
special event code, ACPI_OST_EC_OSPM_EJECT, to that function,
introduce a separate wrapper around acpi_bus_device_eject(),
acpi_eject_store_work(), that will be queued up by
acpi_eject_store() instead of acpi_bus_hot_remove_device().
This allows acpi_eject_store() to be simplified and it allows
struct acpi_eject_event to be dropped entirely, as there's
no more users of that structure.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/internal.h |1
drivers/acpi/pci_root.c | 28 ++--
drivers/acpi/scan.c | 81
include/acpi/acpi_bus.h |6 ---
4 files changed, 32 insertions(+), 84 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -285,9 +285,8 @@ static int acpi_scan_hot_remove(struct a
return 0;
}
-static void acpi_bus_device_eject(void *context)
+static void acpi_bus_device_eject(acpi_handle handle, u32 ost_source)
{
- acpi_handle handle = context;
struct acpi_device *device = NULL;
struct acpi_scan_handler *handler;
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
@@ -304,8 +303,10 @@ static void acpi_bus_device_eject(void *
if (!handler || !handler->hotplug.enabled)
goto err_support;
- acpi_evaluate_hotplug_ost(handle, ACPI_NOTIFY_EJECT_REQUEST,
- ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
+ if (ost_source == ACPI_NOTIFY_EJECT_REQUEST)
+ acpi_evaluate_hotplug_ost(handle, ACPI_NOTIFY_EJECT_REQUEST,
+ ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
+
if (handler->hotplug.mode == AHM_CONTAINER)
kobject_uevent(>dev.kobj, KOBJ_OFFLINE);
@@ -325,11 +326,22 @@ static void acpi_bus_device_eject(void *
err_support:
ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
err_out:
- acpi_evaluate_hotplug_ost(handle, ACPI_NOTIFY_EJECT_REQUEST, ost_code,
- NULL);
+ acpi_evaluate_hotplug_ost(handle, ost_source, ost_code, NULL);
goto out;
}
+/**
+ * acpi_bus_hot_remove_device: Eject a device and its children.
+ * @context: ACPI handle of the device to eject.
+ *
+ * Hot-remove a device and its children. This function is to be called
+ * asynchronously through acpi_os_hotplug_execute().
+ */
+void acpi_bus_hot_remove_device(void *context)
+{
+ acpi_bus_device_eject(context, ACPI_NOTIFY_EJECT_REQUEST);
+}
+
static void acpi_scan_bus_device_check(acpi_handle handle, u32 ost_source)
{
struct acpi_device *device = NULL;
@@ -428,7 +440,7 @@ static void acpi_hotplug_notify_cb(acpi_
break;
case ACPI_NOTIFY_EJECT_REQUEST:
acpi_handle_debug(handle, "ACPI_NOTIFY_EJECT_REQUEST event\n");
- callback = acpi_bus_device_eject;
+ callback = acpi_bus_hot_remove_device;
break;
default:
/* non-hotplug event; possibly handled by other handler */
@@ -441,36 +453,6 @@ static void acpi_hotplug_notify_cb(acpi_
NULL);
}
-/**
- * acpi_bus_hot_remove_device: hot-remove a device and its children
- * @context: struct acpi_eject_event pointer (freed in this func)
- *
- * Hot-remove a device and its children. This function frees up the
- * memory space passed by arg context, so that the caller may call
- * this function asynchronously through acpi_os_hotplug_execute().
- */
-void
[PATCH 1/3] ACPI / scan: Start matching drivers after trying scan handlers
From: Rafael J. Wysocki
ACPI scan handlers should always be attached to struct acpi_device
objects before any ACPI drivers, but there is a window during which
a driver may be attached to a struct acpi_device before checking if
there is a matching scan handler. Namely, that will happen if an
ACPI driver module is loaded during acpi_bus_scan() right after
the first namespace walk is complete and before the given device
is processed by the second namespace walk.
To prevent that from happening, set the match_driver flags of
struct acpi_device objects right before running device_attach()
for them in acpi_bus_device_attach().
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -1676,7 +1676,6 @@ void acpi_init_device_object(struct acpi
void acpi_device_add_finalize(struct acpi_device *device)
{
- device->flags.match_driver = true;
dev_set_uevent_suppress(>dev, false);
kobject_uevent(>dev.kobj, KOBJ_ADD);
}
@@ -1915,8 +1914,12 @@ static acpi_status acpi_bus_device_attac
return AE_OK;
ret = acpi_scan_attach_handler(device);
- if (ret)
- return ret > 0 ? AE_OK : AE_CTRL_DEPTH;
+ if (ret < 0)
+ return AE_CTRL_DEPTH;
+
+ device->flags.match_driver = true;
+ if (ret > 0)
+ return AE_OK;
ret = device_attach(>dev);
return ret >= 0 ? AE_OK : AE_CTRL_DEPTH;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / hotplug: Refuse to hot-remove all objects with disabled hotplug
From: Rafael J. Wysocki
In theory, an ACPI device object may be the parent of another
device object whose hotplug is disabled by user space thorugh its
scan handler. In that case, the eject operation targeting the
parent should fail as though the parent's own hotplug was disabled,
but currently this is not the case, because acpi_scan_hot_remove()
doesn't check the disable/enable hotplug status of the children
of the top-most object passed to it.
To fix this, modify acpi_bus_offline_companions() to return an
error code if hotplug is disabled for the given device object.
[Also change the name of the function to acpi_bus_offline(),
because it is not only about companions any more, and change
the name of acpi_bus_online_companions() accordingly.] Make
acpi_scan_hot_remove() propagate that error to its callers.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c | 57
1 file changed, 36 insertions(+), 21 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -125,8 +125,8 @@ acpi_device_modalias_show(struct device
}
static DEVICE_ATTR(modalias, 0444, acpi_device_modalias_show, NULL);
-static acpi_status acpi_bus_offline_companions(acpi_handle handle, u32 lvl,
- void *data, void **ret_p)
+static acpi_status acpi_bus_offline(acpi_handle handle, u32 lvl, void *data,
+ void **ret_p)
{
struct acpi_device *device = NULL;
struct acpi_device_physical_node *pn;
@@ -136,6 +136,11 @@ static acpi_status acpi_bus_offline_comp
if (acpi_bus_get_device(handle, ))
return AE_OK;
+ if (device->handler && !device->handler->hotplug.enabled) {
+ *ret_p = >dev;
+ return AE_SUPPORT;
+ }
+
mutex_lock(>physical_node_lock);
list_for_each_entry(pn, >physical_node_list, node) {
@@ -168,8 +173,8 @@ static acpi_status acpi_bus_offline_comp
return status;
}
-static acpi_status acpi_bus_online_companions(acpi_handle handle, u32 lvl,
- void *data, void **ret_p)
+static acpi_status acpi_bus_online(acpi_handle handle, u32 lvl, void *data,
+ void **ret_p)
{
struct acpi_device *device = NULL;
struct acpi_device_physical_node *pn;
@@ -214,26 +219,32 @@ static int acpi_scan_hot_remove(struct a
* If the first pass is successful, the second one isn't needed, though.
*/
errdev = NULL;
- acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
- NULL, acpi_bus_offline_companions,
- (void *)false, (void **));
- acpi_bus_offline_companions(handle, 0, (void *)false, (void **));
+ status = acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
+NULL, acpi_bus_offline, (void *)false,
+(void **));
+ if (status == AE_SUPPORT) {
+ dev_warn(errdev, "Offline disabled.\n");
+ acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
+ acpi_bus_online, NULL, NULL, NULL);
+ put_device(>dev);
+ return -EPERM;
+ }
+ acpi_bus_offline(handle, 0, (void *)false, (void **));
if (errdev) {
errdev = NULL;
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
- NULL, acpi_bus_offline_companions,
- (void *)true , (void **));
+ NULL, acpi_bus_offline, (void *)true,
+ (void **));
if (!errdev || acpi_force_hot_remove)
- acpi_bus_offline_companions(handle, 0, (void *)true,
- (void **));
+ acpi_bus_offline(handle, 0, (void *)true,
+(void **));
if (errdev && !acpi_force_hot_remove) {
dev_warn(errdev, "Offline failed.\n");
- acpi_bus_online_companions(handle, 0, NULL, NULL);
+ acpi_bus_online(handle, 0, NULL, NULL);
acpi_walk_namespace(ACPI_TYPE_ANY, handle,
- ACPI_UINT32_MAX,
- acpi_bus_online_companions, NULL,
- NULL, NULL);
+ ACPI_UINT32_MAX, acpi_bus_online,
+ NULL, NULL, NULL);
put_device(>dev);
return -EBUSY;
}
Re: [PATCH] mm: cache largest vma
>> I'm slightly surprised this cache makes 15% hit. Which application >> get a benefit? You listed a lot of applications, but I'm not sure >> which is highly depending on largest vma. > > Well I chose the largest vma because it gives us a greater chance of > being already cached when we do the lookup for the faulted address. > > The 15% improvement was with Hadoop. According to my notes it was at > ~48% with the baseline kernel and increased to ~63% with this patch. > > In any case I didn't measure the rates on a per-task granularity, but at > a general system level. When a system is first booted I can see that the > mmap_cache access rate becomes the determinant factor and when adding a > workload it doesn't change much. One exception to this was a kernel > build, where we go from ~50% to ~89% hit rate on a vanilla kernel. I looked at this patch a bit. The worth of this is to improve the cache hit ratio of heap. 1) For single thread applications, heap is frequently largest mapping in the process. 2) For java VM, "java -Xms1000m -Xmx1000m HelloWorld" makes following /proc//smaps entry. That said, JVM allocate single heap even if applications are multi threaded. c180-1 rw-p 00:00 0 Size:1024000 kB Rss: 244 kB Pss: 244 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 244 kB Referenced: 244 kB Anonymous: 244 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize:4 kB MMUPageSize: 4 kB That's good. However, we know there is a situation that this patch doesn't work. glibc makes per thread heap (arena) by default. So, it is not to be expected works well on glibc multi threaded programs. That's a slightly big limitation. Anyway, I haven't observed real performance difference because most big penalty of find_vma come from taking mmap_sem, not rb-tree search. Another and additional input are welcome. But I myself haven't convinced this patch works everywhere. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fixes for 3.12-final
On Sun, Nov 3, 2013 at 11:54 AM, Al Viro wrote: > > IIRC, at some point such an attempt has seriously hurt iget() on 32bit > boxen, so we ended up deciding not to go there. Had been years ago, > though... Yeah, I think the circumstances have changed. 32-bit is less important, and iget() is much less critical than it used to be (all *normal* inode lookups are through the direct dentry pointer). Sure, ARM is a few years away from 64-bit being common, but it's happening. And I suspect even 32-bit ARM doesn't have the annoying issues that x86-32 had with 64-bit values (namely using up a lot of the register space). So unless there's something hidden that makes it really nasty, I do suspect that a "u64 i_ino" would just be the right thing to do. Rather than adding workarounds for our current odd situation on 32-bit kernels (and just wasting time on 64-bit kernels). 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: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Sun, Nov 3, 2013 at 2:42 PM, Paul E. McKenney wrote: > > smp_storebuffer_mb() -- A barrier that enforces those orderings > that do not invalidate the hardware store-buffer optimization. Ugh. Maybe. Can you guarantee that those are the correct semantics? And why talk about the hardware semantics, when you really want specific semantics for the *software*. > smp_not_w_r_mb() -- A barrier that orders everything except prior > writes against subsequent reads. Ok, that sounds more along the lines of "these are the semantics we want", but I have to say, it also doesn't make me go "ahh, ok". > smp_acqrel_mb() -- A barrier that combines C/C++ acquire and release > semantics. (C/C++ "acquire" orders a specific load against > subsequent loads and stores, while C/C++ "release" orders > a specific store against prior loads and stores.) I don't think this is true. acquire+release is much stronger than what you're looking for - it doesn't allow subsequent reads to move past the write (because that would violate the acquire part). On x86, for example, you'd need to have a locked cycle for smp_acqrel_mb(). So again, what are the guarantees you actually want? Describe those. And then make a name. I _think_ the guarantees you want is: - SMP write barrier - *local* read barrier for reads preceding the write. but the problem is that the "preceding reads" part is really specifically about the write that you had. The barrier should really be attached to the *particular* write operation, it cannot be a standalone barrier. So it would *kind* of act like a "smp_wmb() + smp_rmb()", but the problem is that a "smp_rmb()" doesn't really "attach" to the preceding write. This is analogous to a "acquire" operation: you cannot make an "acquire" barrier, because it's not a barrier *between* two ops, it's associated with one particular op. So what I *think* you actually really really want is a "store with release consistency, followed by a write barrier". In TSO, afaik all stores have release consistency, and all writes are ordered, which is why this is a no-op in TSO. And x86 also has that "all stores have release consistency, and all writes are ordered" model, even if TSO doesn't really describe the x86 model. But on ARM64, for example, I think you'd really want the store itself to be done with "stlr" (store with release), and then follow up with a "dsb st" after that. And notice how that requires you to mark the store itself. There is no actual barrier *after* the store that does the optimized model. Of course, it's entirely possible that it's not worth worrying about this on ARM64, and that just doing it as a "normal store followed by a full memory barrier" is good enough. But at least in *theory* a microarchitecture might make it much cheaper to do a "store with release consistency" followed by "write barrier". Anyway, having talked exhaustively about exactly what semantics you are after, I *think* the best model would be to just have a #define smp_store_with_release_semantics(x, y) ... and use that *and* a "smp_wmb()" for this (possibly a special "smp_wmb_after_release()" if that allows people to avoid double barriers). On x86 (and TSO systems), the smp_store_with_release_semantics() would be just a regular store, and the smp_wmb() is obviously a no-op. Other platforms would end up doing other things. Hmm? 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] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
Hi!
> Another friend of mine mentioned that he assumes the rise and fall times
> of transistors varies very slightly and could be the main reason for the
> jitter. I do not think that this is really the case, because our gates
> that form the CPU instructions comprise of many transistors. The
> combined raise/fall jitter should cancel each other out.
Plus, there's clock that should make sure that this jitter does not
matter.
> >There should be way to extract entropy more directly from various
> >oscillator effects, no?
>
> I am working a different way of measuring such oscillator effects by
> using the high-resolution timer of the CPU and measure it with a
> Jiffies-based snapshotting window. So, here I would combine two timers
> that are differently generated. If their frequencies would be relative
> prime to each other, we would measure a direct oscillator effect.
I guess main problem is machines that do not have high-resolution
timer on the CPU (rdtsc). They do not get enough entropy during boot,
and the hell breaks loose.
But they usually _do_ have RTC or other clock, not driven by CPU
oscilator. Good.
What about just
while (!enough_entropy) {
cur_time = read_rtc();
simulated_tsc = 0;
while (cur_time == read_rtc())
simulated_tsc++;
gain_entropy_from(simulated_tsc)
}
(Where enough_entropy should be something like 128 bits).
This should work, we know why it works (drift between rtc and cpu
clock) and it does _not_ need rdtsc-style fast source.
Disadvantage is that it burns cpu, but, well, you only need 128
bits. Asuming the rtc used has 100Hz resolution, enough entropy should
be collected in under 2 seconds. That's acceptable adition to time it
takes generating ssh keys on slow cpu.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: ft1000: fixed a few styling issues
On Sun, Nov 03, 2013 at 04:20:38PM +0200, Aldo Iljazi wrote: > Fixed a few styling issues, specifically: > Gar... No one wants to read that changelog. That was over 700 lines of repeated text. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] random: use device attach events for entropy
On Sun, Nov 03, 2013 at 08:33:12AM -0500, Theodore Ts'o wrote: > Some investigation from FreeBSD shows that there is entropy available > from measuring the device attach times: > > http://lists.randombit.net/pipermail/cryptography/2013-October/005689.html > > This will hopefully help us more quickly initialize the entropy pools > while the system is booting (which is one of the times when we really > badly need more entropy, especially in the case of the first boot > after an consumer electronics device is taken out of the box). > > Measurements indicate this makes a huge improvement in the security of > /dev/urandom during the boot sequence, so I'm cc'ing this to the > stable kernel series. Especially for embedded systems, which use > flash and which don't necessarily have the network enabled when they > first generate ssh or x.509 keys (sigh), this can be a big deal. > > Signed-off-by: "Theodore Ts'o" > Cc: sta...@vger.kernel.org Self-NAK. After doing some more measurements, I'm not convinced the entropy estimator is working well given how we are collecting the device attach times. Instead, we need to measure the delta between the start and the end of the device probe, which in turn will only work if we have a valid cycle counter. (random_get_entropy() is not going to cut it.) So with some changes, this approach will improve things on x86, but on architectures like ARM, which generally don't have a cycle counter, the jiffies counter is not going to have enough resolution to do something useful --- and it was on platforms such as ARM and MIPS where I was hoping this would be most useful. Grumble. Why can't ARM and MIPS have decent cycle counters? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf events ring buffer memory barrier on powerpc
On Sun, Nov 03, 2013 at 05:07:59PM +, Will Deacon wrote: > On Sun, Nov 03, 2013 at 02:40:17PM +, Paul E. McKenney wrote: > > On Sat, Nov 02, 2013 at 10:32:39AM -0700, Paul E. McKenney wrote: > > > On Fri, Nov 01, 2013 at 03:56:34PM +0100, Peter Zijlstra wrote: > > > > On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote: > > > > > > Now the whole crux of the question is if we need barrier A at all, > > > > > > since > > > > > > the STORES issued by the @buf writes are dependent on the ubuf->tail > > > > > > read. > > > > > > > > > > The dependency you are talking about is via the "if" statement? > > > > > Even C/C++11 is not required to respect control dependencies. > > > > > > > > > > This one is a bit annoying. The x86 TSO means that you really only > > > > > need barrier(), ARM (recent ARM, anyway) and Power could use a weaker > > > > > barrier, and so on -- but smp_mb() emits a full barrier. > > > > > > > > > > Perhaps a new smp_tmb() for TSO semantics, where reads are ordered > > > > > before reads, writes before writes, and reads before writes, but not > > > > > writes before reads? Another approach would be to define a per-arch > > > > > barrier for this particular case. > > > > > > > > I suppose we can only introduce new barrier primitives if there's more > > > > than 1 use-case. > > Which barrier did you have in mind when you refer to `recent ARM' above? It > seems to me like you'd need a combination if dmb ishld and dmb ishst, since > the former doesn't order writes before writes. I heard a rumor that ARM had recently added a new dmb variant that acted similarly to PowerPC's lwsync, and it was on my list to follow up. Given your response, I am guessing that there is no truth to this rumor... 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: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Mon, Nov 04, 2013 at 07:59:23AM +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2013-11-03 at 16:17 +0100, Peter Zijlstra wrote:
> > On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote:
> > > If there was an smp_tmb(), I would likely use it in rcu_assign_pointer().
> >
> > Well, I'm obviously all for introducing this new barrier, for it will
> > reduce a full mfence on x86 to a compiler barrier. And ppc can use
> > lwsync as opposed to sync afaict. Not sure ARM can do better.
>
> The patch at the *very least* needs a good description of the semantics
> of the barrier, what does it order vs. what etc...
Agreed. Also it needs a name that people can live with. We will get
there. ;-)
Thanx, Paul
> Cheers,
> Ben.
>
> > ---
> > Subject: arch: Introduce new TSO memory barrier smp_tmb()
> >
> > A few sites could be downgraded from smp_mb() to smp_tmb() and a few
> > site should be upgraded to smp_tmb() that are now using smp_wmb().
> >
> > XXX hope PaulMck explains things better..
> >
> > X86 (!OOSTORE), SPARC have native TSO memory models and smp_tmb()
> > reduces to barrier().
> >
> > PPC can use lwsync instead of sync
> >
> > For the other archs, have smp_tmb map to smp_mb, as the stronger barrier
> > is always correct but possibly suboptimal.
> >
> > Suggested-by: Paul McKenney
> > Not-Signed-off-by: Peter Zijlstra
> > ---
> > arch/alpha/include/asm/barrier.h | 2 ++
> > arch/arc/include/asm/barrier.h| 2 ++
> > arch/arm/include/asm/barrier.h| 2 ++
> > arch/arm64/include/asm/barrier.h | 2 ++
> > arch/avr32/include/asm/barrier.h | 1 +
> > arch/blackfin/include/asm/barrier.h | 1 +
> > arch/cris/include/asm/barrier.h | 2 ++
> > arch/frv/include/asm/barrier.h| 1 +
> > arch/h8300/include/asm/barrier.h | 2 ++
> > arch/hexagon/include/asm/barrier.h| 1 +
> > arch/ia64/include/asm/barrier.h | 2 ++
> > arch/m32r/include/asm/barrier.h | 2 ++
> > arch/m68k/include/asm/barrier.h | 1 +
> > arch/metag/include/asm/barrier.h | 3 +++
> > arch/microblaze/include/asm/barrier.h | 1 +
> > arch/mips/include/asm/barrier.h | 3 +++
> > arch/mn10300/include/asm/barrier.h| 2 ++
> > arch/parisc/include/asm/barrier.h | 1 +
> > arch/powerpc/include/asm/barrier.h| 2 ++
> > arch/s390/include/asm/barrier.h | 1 +
> > arch/score/include/asm/barrier.h | 1 +
> > arch/sh/include/asm/barrier.h | 2 ++
> > arch/sparc/include/asm/barrier_32.h | 1 +
> > arch/sparc/include/asm/barrier_64.h | 3 +++
> > arch/tile/include/asm/barrier.h | 2 ++
> > arch/unicore32/include/asm/barrier.h | 1 +
> > arch/x86/include/asm/barrier.h| 3 +++
> > arch/xtensa/include/asm/barrier.h | 1 +
> > 28 files changed, 48 insertions(+)
> >
> > diff --git a/arch/alpha/include/asm/barrier.h
> > b/arch/alpha/include/asm/barrier.h
> > index ce8860a0b32d..02ea63897038 100644
> > --- a/arch/alpha/include/asm/barrier.h
> > +++ b/arch/alpha/include/asm/barrier.h
> > @@ -18,12 +18,14 @@ __asm__ __volatile__("mb": : :"memory")
> > #ifdef CONFIG_SMP
> > #define __ASM_SMP_MB "\tmb\n"
> > #define smp_mb() mb()
> > +#define smp_tmb() mb()
> > #define smp_rmb() rmb()
> > #define smp_wmb() wmb()
> > #define smp_read_barrier_depends() read_barrier_depends()
> > #else
> > #define __ASM_SMP_MB
> > #define smp_mb() barrier()
> > +#define smp_tmb() barrier()
> > #define smp_rmb() barrier()
> > #define smp_wmb() barrier()
> > #define smp_read_barrier_depends() do { } while (0)
> > diff --git a/arch/arc/include/asm/barrier.h b/arch/arc/include/asm/barrier.h
> > index f6cb7c4ffb35..456c790fa1ad 100644
> > --- a/arch/arc/include/asm/barrier.h
> > +++ b/arch/arc/include/asm/barrier.h
> > @@ -22,10 +22,12 @@
> > /* TODO-vineetg verify the correctness of macros here */
> > #ifdef CONFIG_SMP
> > #define smp_mb()mb()
> > +#define smp_tmb() mb()
> > #define smp_rmb() rmb()
> > #define smp_wmb() wmb()
> > #else
> > #define smp_mb()barrier()
> > +#define smp_tmb() barrier()
> > #define smp_rmb() barrier()
> > #define smp_wmb() barrier()
> > #endif
> > diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
> > index 60f15e274e6d..bc88a8505673 100644
> > --- a/arch/arm/include/asm/barrier.h
> > +++ b/arch/arm/include/asm/barrier.h
> > @@ -51,10 +51,12 @@
> >
> > #ifndef CONFIG_SMP
> > #define smp_mb() barrier()
> > +#define smp_tmb() barrier()
> > #define smp_rmb() barrier()
> > #define smp_wmb() barrier()
> > #else
> > #define smp_mb() dmb(ish)
> > +#define smp_tmb() smp_mb()
> > #define smp_rmb() smp_mb()
> > #define smp_wmb() dmb(ishst)
> > #endif
> > diff --git a/arch/arm64/include/asm/barrier.h
> > b/arch/arm64/include/asm/barrier.h
> > index d4a63338a53c..ec0531f4892f 100644
> > --- a/arch/arm64/include/asm/barrier.h
> > +++
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Sun, Nov 03, 2013 at 09:01:24PM +0100, Peter Zijlstra wrote: > On Sun, Nov 03, 2013 at 10:08:14AM -0800, Linus Torvalds wrote: > > On Sun, Nov 3, 2013 at 7:17 AM, Peter Zijlstra wrote: > > > On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: > > >> If there was an smp_tmb(), I would likely use it in rcu_assign_pointer(). > > > > > > Well, I'm obviously all for introducing this new barrier, for it will > > > reduce a full mfence on x86 to a compiler barrier. And ppc can use > > > lwsync as opposed to sync afaict. Not sure ARM can do better. > > > > > > --- > > > Subject: arch: Introduce new TSO memory barrier smp_tmb() > > > > This is specialized enough that I would *really* like the name to be > > more descriptive. Compare to the special "smp_read_barrier_depends()" > > maco: it's unusual, and it has very specific semantics, so it gets a > > long and descriptive name. > > > > Memory ordering is subtle enough without then using names that are > > subtle in themselves. mb/rmb/wmb are conceptually pretty simple > > operations, and very basic when talking about memory ordering. > > "acquire" and "release" are less simple, but have descriptive names > > and have very specific uses in locking. > > > > In contrast "smp_tmb()" is a *horrible* name, because TSO is a > > description of the memory ordering, not of a particular barrier. It's > > also not even clear that you can have a "tso barrier", since the > > ordering (like acquire/release) presumably is really about one > > particular *store*, not about some kind of barrier between different > > operations. > > > > So please describe exactly what the semantics that barrier has, and > > then name the barrier that way. > > > > I assume that in this particular case, the semantics RCU wants is > > "write barrier, and no preceding reads can move past this point". Its semantics order prior reads against subsequent reads, prior reads against subsequent writes, and prior writes against subsequent writes. It does -not- order prior writes against subsequent reads. > > Calling that "smp_tmb()" is f*cking insane, imnsho. > > Fair enough; from what I could gather the proposed semantics are > RELEASE+WMB, such that neither reads not writes can cross over, writes > can't cross back, but reads could. > > Since both RELEASE and WMB are trivial under TSO the entire thing > collapses. And here are some candidate names, with no attempt to sort sanity from insanity: smp_storebuffer_mb() -- A barrier that enforces those orderings that do not invalidate the hardware store-buffer optimization. smp_not_w_r_mb() -- A barrier that orders everything except prior writes against subsequent reads. smp_acqrel_mb() -- A barrier that combines C/C++ acquire and release semantics. (C/C++ "acquire" orders a specific load against subsequent loads and stores, while C/C++ "release" orders a specific store against prior loads and stores.) Others? > Now I'm currently completely confused as to what C/C++ wrecks vs actual > proper memory order issues; let alone fully comprehend the case that > started all this. Each can result in similar wreckage. In either case, it is about failing to guarantee needed orderings. 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: Quality plastic raw materials
Dear Sir, Good day! We had dealing plastic raw materials for many years . And supplied high quality different grade HDPE/LDPE/PP/PET to our old and new customers. Should any of the items be of interest to you, please let me know. We shall be glad to give you our lowest quotations upon receipt of your detailed requirements. Thanks, Iris Email: iris20111...@hotmail.com Skype:iris.song12
Re: [PATCH net] net: flow_dissector: fail on evil iph->ihl
On 11/01/2013 08:01 AM, Jason Wang wrote: We don't validate iph->ihl which may lead a dead loop if we meet a IPIP skb whose iph->ihl is zero. Fix this by failing immediately when iph->ihl is evil (less than 5). This issue were introduced by commit ec5efe7946280d1e84603389a1030ccec0a767ae (rps: support IPIP encapsulation). Cc: Eric Dumazet Cc: Petr Matousek Cc: Michael S. Tsirkin Cc: Daniel Borkmann Signed-off-by: Jason Wang Sorry, a bit late as I was offline last 4 days, but fwiw: Acked-by: Daniel Borkmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Topic closed] A Desktop Linux idea: modulized open hardware database for the linux kernel config
Theodore Ts'o wrote on Sunday, 03rd November 2013: > It's an idea that people have tossed around before, but utltimately, > it's far more work than it's worth, and it's a maintenance nightmare. > For most non-technical users, using a distro kernel is quite good > enough. Yes, I get it. Thanks for the honesty. > > I’m sorry, but I cannot possibly do this all by myself. I was able > > to help in some Wikis and in Smolt, but I cannot setup such a > > system. Apparently I was only able to come up with the idea... > > If you told me that you wanted to try it, I would tell you that you > were going to be getting into a huge amount of work, and it's not > obvious to me that it's worth it --- but if you are going to volunteer > your own time, then it's ultimately up to you. But having you trying > to volunteer *other* people's time for what might be a sisyphean does > take a fair amount of chutzpah. I don’t want other people to volunteer, I was expressing an idea, but – after reading your answer – I do understand that the gain is not worth the effort. At least now I know what you (the people making Linux) think about it. I was trying to off-load some workload from you (developers) to power-users. I consider myself to be good enough to compile a kernel by myself, and to install Gentoo for that matter, and I’m also willing to volunteer some of my spare time to help other people who run Linux. I wrote some Wiki entries on how to install Linux on a specific machine and how to get things to run. I found that most of the times a new kernel was required due to some devices requireing a staging driver or a deactivated feature of a driver. However, my possibilities are limited. As I wrote before, I tried some tools (written by others!) that unfortunately didn’t work out, like Smolt. So I’ll let go of that idea. I’m certainly glad to have proposed it, but I get it that it isn’t worth it. I don’t think it has anything to do with chutzpah though, since the posting was motivated by me being eager to help where I can, not where I cannot. (Although I do understand it may look different.) Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kære : Vinder
Kære : Vinder Vi er glade for at informere dig om den endelige annoncering af Microsoft International salgsfremmende online programm, er din email ID opstået dig en vinder af 815.810.00 euro ( otte hundrede og femten tusinde , otte hundrede og ti euro kun ) i Microsoft salgsfremmende program , Men resultaterne blev frigivet, og din e-mail -id opstod vinder uden salget af nogen billetter . Din e-mail var knyttet til Ref.No : LSLUK/2031/8161/13 og Batch nr.: 14/013/IPD . Udvælgelsesprocessen blev udført gennem en tilfældig edb valgrunde system fra en database på over 250,000.000 email adresser trukket fra alle kontinenter . ** ** At indsende din påstand du rådes til at kontakte vores markedsføring Director med nedenstående oplysninger: Kontaktperson: Dr. David Bengal. Tlf : +31 685 443 018 , sende dit svar til : msoftage...@aol.com ** ** Med venlig hilsen , Mrs Sandra Crowford (Public Relation Officer ) sende dit svar til : msoftage...@aol.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange location and name for platform devices when device-tree is used.
On Sat, 2013-11-02 at 13:40 -0700, Greg Kroah-Hartman wrote: > On Sun, Nov 03, 2013 at 07:22:10AM +1100, Benjamin Herrenschmidt wrote: > > On Sat, 2013-11-02 at 08:58 -0700, Greg Kroah-Hartman wrote: > > > Just loop through all the platform devices before registering it to > > > determine if you need to do this, the platform code can do this just > > > fine. If you try to register a duplicate name with the driver core, > > > odds are it will complain loudly, so don't do that. > > > > But that loop + registration is racy ... oh well, we might do something > > better with Neil's idea of labels instead. > > How is it racy? Only one platform device should be allowed to be > registered at a time, there is a per-bus lock that should be used to > enforce this, right? No, platform devices can be registered from different "sources" and possibly from different threads. There's no fundamental reason why the registration would have to be serialized accross all possible entities capable of crating them (though it generally is at the moment). There's no global mutex used by every piece of code in the kernel that might create/register a platform device. However, let's leave that aside for now and go back to the original issue because that's probably worth discussing a bit more. Normally, a device "name" in sysfs shouldn't be relevant to user space, I think we agree. Devices get identified by function (class typically) and additional functional attributes associated with them. For platform devices, things get a bit more murky though, ie, let's say we have a backlight device, that's good ... but nothing tells us what specific display it controls (there could be more than one in a system). The device-tree typically provide such cross linking, but sysfs doesn't. My understanding, and Neil correct me if I'm wrong, is that it's become a case where userspace has started relying on the "name" of the platform device to identify it's specific function within a class. Is that correct ? IE. Which screen this backlight is associated to isn't an explicit information provided somewhere in sysfs but something intuited by user space tools based on the platform device name. Greg, I'm not saying that's a good thing btw :-) I'm just trying to get a grasp of the exact scope of the problem. Now, there's a way for userspace to sort that out using device-tree of course, they can parse /proc/device-tree, find the linkage, and related the device-tree nodes to the corresponding platform devices (are we creating the devspec files btw ?) But that only works for DT-created platform devices, not the hand-made ones. Another option would be for classes that are meaningless "seldomly" such as a backlight control (ie, it's always attached to *something*, a screen for example, etc...) to associate a separate name which isn't the device name in sysfs but a "label" as Neil proposed. In this case we'd need to add an attribute but I would object to this being specific to pwm_bl, instead of should generally be an attribute of all backlight devices. This could then be class specific... but should it be ? it might actually be a useful thing to generally be able to label devices, especially in the embedded world. But that's just one option ... the point remains, people seem to be relying on platform device names in sysfs and yes, that's not right, but we need to understand why they do it and what's the right way to do to replace that practice. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Strange location and name for platform devices when device-tree is used.
On Sat, 2 Nov 2013 08:58:24 -0700 Greg Kroah-Hartman wrote: > So go blame them for this, not me, remember, I'm the one who _hates_ > platform devices and wish they had never been created... Have you ever written up why you hate them? I did a bit of googling and couldn't find anything obvious. Is it the whole concept, or the particular details that you don't like? (I find the concept seems to make perfect sense, though there are a lot of details that I don't know). Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH v3] can: c_can: Speed up rx_poll function
On 11/03/2013 08:20 PM, Wolfgang Grandegger wrote:
> On 11/01/2013 10:36 AM, Markus Pargmann wrote:
>> This patch speeds up the rx_poll function by reducing the number of
>> register reads.
>>
>> Replace the 32bit register read by a 16bit register read. Currently
>> the 32bit register read is implemented by using 2 16bit reads. This is
>> inefficient as we only use the lower 16bit in rx_poll.
>>
>> The for loop reads the pending interrupts in every iteration. This
>> leads up to 16 reads of pending interrupts. The patch introduces a new
>> outer loop to read the pending interrupts as long as 'quota' is above 0.
>> This reduces the total number of reads.
>>
>> The third change is to replace the for-loop by a ffs loop.
>>
>> Tested on AM335x. I removed all 'static' and 'inline' from c_can.c to
>> see the timings for all functions. I used the function tracer with
>> trace_stats.
>>
>> 125kbit:
>> Function HitTimeAvg
>>s^2
>> ------
>>---
>> c_can_do_rx_poll 6396010168178 us 158.977 us
>>1493056 us
>> With patch:
>> c_can_do_rx_poll 639413764057 us 58.867 us
>>776162.2 us
>>
>> 1Mbit:
>> Function HitTimeAvg
>>s^2
>> ------
>>---
>> c_can_do_rx_poll 6948930049498 us 432.435 us
>>9271851 us
>> With patch:
>> c_can_do_rx_poll20710924322185 us 117.436 us
>>171469047 us
>>
>> Signed-off-by: Markus Pargmann
>> ---
>>
>> Notes:
>> Changes in v3:
>> - Update commit message (measurements and ffs)
>>
>> Changes in v2:
>> - Small changes, find_next_bit -> ffs and other
>>
>> drivers/net/can/c_can/c_can.c | 22 --
>> 1 file changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
>> index a668cd4..428681e 100644
>> --- a/drivers/net/can/c_can/c_can.c
>> +++ b/drivers/net/can/c_can/c_can.c
>> @@ -798,17 +798,19 @@ static int c_can_do_rx_poll(struct net_device *dev,
>> int quota)
>> u32 num_rx_pkts = 0;
>> unsigned int msg_obj, msg_ctrl_save;
>> struct c_can_priv *priv = netdev_priv(dev);
>> -u32 val = c_can_read_reg32(priv, C_CAN_INTPND1_REG);
>> +u16 val;
>> +
>> +/*
>> + * It is faster to read only one 16bit register. This is only possible
>> + * for a maximum number of 16 objects.
>> + */
>> +BUILD_BUG_ON_MSG(C_CAN_MSG_OBJ_RX_LAST > 16,
>> +"Implementation does not support more message objects
>> than 16");
>> +
>> +while (quota > 0 && (val = priv->read_reg(priv, C_CAN_INTPND1_REG))) {
>> +while ((msg_obj = ffs(val)) && quota > 0) {
>> +val &= ~BIT(msg_obj - 1);
>
> IIRC, we should avoid assignment in if/while statements.
Yes, but the code looks IMHO better this way.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Sun, 2013-11-03 at 16:17 +0100, Peter Zijlstra wrote:
> On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote:
> > If there was an smp_tmb(), I would likely use it in rcu_assign_pointer().
>
> Well, I'm obviously all for introducing this new barrier, for it will
> reduce a full mfence on x86 to a compiler barrier. And ppc can use
> lwsync as opposed to sync afaict. Not sure ARM can do better.
The patch at the *very least* needs a good description of the semantics
of the barrier, what does it order vs. what etc...
Cheers,
Ben.
> ---
> Subject: arch: Introduce new TSO memory barrier smp_tmb()
>
> A few sites could be downgraded from smp_mb() to smp_tmb() and a few
> site should be upgraded to smp_tmb() that are now using smp_wmb().
>
> XXX hope PaulMck explains things better..
>
> X86 (!OOSTORE), SPARC have native TSO memory models and smp_tmb()
> reduces to barrier().
>
> PPC can use lwsync instead of sync
>
> For the other archs, have smp_tmb map to smp_mb, as the stronger barrier
> is always correct but possibly suboptimal.
>
> Suggested-by: Paul McKenney
> Not-Signed-off-by: Peter Zijlstra
> ---
> arch/alpha/include/asm/barrier.h | 2 ++
> arch/arc/include/asm/barrier.h| 2 ++
> arch/arm/include/asm/barrier.h| 2 ++
> arch/arm64/include/asm/barrier.h | 2 ++
> arch/avr32/include/asm/barrier.h | 1 +
> arch/blackfin/include/asm/barrier.h | 1 +
> arch/cris/include/asm/barrier.h | 2 ++
> arch/frv/include/asm/barrier.h| 1 +
> arch/h8300/include/asm/barrier.h | 2 ++
> arch/hexagon/include/asm/barrier.h| 1 +
> arch/ia64/include/asm/barrier.h | 2 ++
> arch/m32r/include/asm/barrier.h | 2 ++
> arch/m68k/include/asm/barrier.h | 1 +
> arch/metag/include/asm/barrier.h | 3 +++
> arch/microblaze/include/asm/barrier.h | 1 +
> arch/mips/include/asm/barrier.h | 3 +++
> arch/mn10300/include/asm/barrier.h| 2 ++
> arch/parisc/include/asm/barrier.h | 1 +
> arch/powerpc/include/asm/barrier.h| 2 ++
> arch/s390/include/asm/barrier.h | 1 +
> arch/score/include/asm/barrier.h | 1 +
> arch/sh/include/asm/barrier.h | 2 ++
> arch/sparc/include/asm/barrier_32.h | 1 +
> arch/sparc/include/asm/barrier_64.h | 3 +++
> arch/tile/include/asm/barrier.h | 2 ++
> arch/unicore32/include/asm/barrier.h | 1 +
> arch/x86/include/asm/barrier.h| 3 +++
> arch/xtensa/include/asm/barrier.h | 1 +
> 28 files changed, 48 insertions(+)
>
> diff --git a/arch/alpha/include/asm/barrier.h
> b/arch/alpha/include/asm/barrier.h
> index ce8860a0b32d..02ea63897038 100644
> --- a/arch/alpha/include/asm/barrier.h
> +++ b/arch/alpha/include/asm/barrier.h
> @@ -18,12 +18,14 @@ __asm__ __volatile__("mb": : :"memory")
> #ifdef CONFIG_SMP
> #define __ASM_SMP_MB "\tmb\n"
> #define smp_mb() mb()
> +#define smp_tmb()mb()
> #define smp_rmb()rmb()
> #define smp_wmb()wmb()
> #define smp_read_barrier_depends() read_barrier_depends()
> #else
> #define __ASM_SMP_MB
> #define smp_mb() barrier()
> +#define smp_tmb()barrier()
> #define smp_rmb()barrier()
> #define smp_wmb()barrier()
> #define smp_read_barrier_depends() do { } while (0)
> diff --git a/arch/arc/include/asm/barrier.h b/arch/arc/include/asm/barrier.h
> index f6cb7c4ffb35..456c790fa1ad 100644
> --- a/arch/arc/include/asm/barrier.h
> +++ b/arch/arc/include/asm/barrier.h
> @@ -22,10 +22,12 @@
> /* TODO-vineetg verify the correctness of macros here */
> #ifdef CONFIG_SMP
> #define smp_mb()mb()
> +#define smp_tmb()mb()
> #define smp_rmb() rmb()
> #define smp_wmb() wmb()
> #else
> #define smp_mb()barrier()
> +#define smp_tmb()barrier()
> #define smp_rmb() barrier()
> #define smp_wmb() barrier()
> #endif
> diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
> index 60f15e274e6d..bc88a8505673 100644
> --- a/arch/arm/include/asm/barrier.h
> +++ b/arch/arm/include/asm/barrier.h
> @@ -51,10 +51,12 @@
>
> #ifndef CONFIG_SMP
> #define smp_mb() barrier()
> +#define smp_tmb()barrier()
> #define smp_rmb()barrier()
> #define smp_wmb()barrier()
> #else
> #define smp_mb() dmb(ish)
> +#define smp_tmb()smp_mb()
> #define smp_rmb()smp_mb()
> #define smp_wmb()dmb(ishst)
> #endif
> diff --git a/arch/arm64/include/asm/barrier.h
> b/arch/arm64/include/asm/barrier.h
> index d4a63338a53c..ec0531f4892f 100644
> --- a/arch/arm64/include/asm/barrier.h
> +++ b/arch/arm64/include/asm/barrier.h
> @@ -33,10 +33,12 @@
>
> #ifndef CONFIG_SMP
> #define smp_mb() barrier()
> +#define smp_tmb()barrier()
> #define smp_rmb()barrier()
> #define smp_wmb()barrier()
> #else
> #define smp_mb() asm volatile("dmb ish" : : : "memory")
> +#define smp_tmb()asm volatile("dmb ish" : : : "memory")
> #define smp_rmb()asm volatile("dmb ishld" : : : "memory")
> #define smp_wmb()
Re: perf events ring buffer memory barrier on powerpc
On Fri, 2013-11-01 at 18:30 +0200, Victor Kaplansky wrote: > "David Laight" wrote on 11/01/2013 06:25:29 PM: > > gcc will do unexpected memory accesses for bit fields that are > > adjacent to volatile data. > > In particular it may generate 64bit sized (and aligned) RMW cycles > > when accessing bit fields. > > And yes, this has caused real problems. > > Thanks, I am aware about this bug/feature in gcc. AFAIK, this has been fixed in 4.8 and 4.7.3 ... Cheers, Ben. > -- Victor > > ___ > Linuxppc-dev mailing list > linuxppc-...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: et131x: drop packet when error occurs in et131x_tx()
On 3 November 2013 01:40, ZHAO Gang wrote: > Drop packet instead of return NETDEV_TX_BUSY when tx failed. > > Signed-off-by: ZHAO Gang Hi, Looks good. If you could also send a patch to remove this item from the et131x/README TODO list, then I'm happy to add: Acked-by: Mark Einon Cheers, Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: et131x: improve code readability
On 3 November 2013 01:41, ZHAO Gang wrote: > Signed-off-by: ZHAO Gang Acked-by: Mark Einon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
