headers
David Howells | 23 May 2013 16:50
Picon
Favicon

Is spin_is_locked() safe to use with BUG_ON()/WARN_ON()?


We are using spin_is_locked() in a few places to give a warning or an oops if
either a spinlock is not held or if it is held.  I'm not sure all of these are
safe.

Take uas_try_complete() in drivers/usb/storage/uas.c which does:

	WARN_ON(!spin_is_locked(&devinfo->lock));

or fscache_start_operations() which does:

	ASSERT(spin_is_locked(&object->lock));

These will unconditionally fail under sometimes because under certain
conditions spin_is_locked() is hardwired to 0 (ie. not locked) when actually
we're in a place where the spinlock _should_ be locked, and we should get a
non-zero return.

Would it be reasonable to add a spin_is_not_locked() function for use when we
expect it not to be locked and then use spin_is_locked() only when we expect it
to be locked?

Thanks to Milosz Tanski for spotting this one.

David
Permalink | Reply | 2 comments |
headers
Chen Gang | 23 May 2013 09:57

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.


The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
Configure standard kernel features (expert users) > BUG() Support".

But in fact, we always need it, and quite a few of architectures have
already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

And kernel also already has prepared a default effective implementation
for the architectures which is unwilling to implement it by themselves
(e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
score, tile, um, unicore32, xtensa).

So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.

Signed-off-by: Chen Gang <gang.chen <at> asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
(Continue reading)

Permalink | Reply | 32 comments |
headers
Stephen Rothwell | 21 May 2013 05:49
Picon
Picon

[PATCH] Finally eradicate CONFIG_HOTPLUG

Ever since commit 45f035ab9b8f ("CONFIG_HOTPLUG should be always on"),
it has been basically impossible to build a kernel with CONFIG_HOTPLUG
turned off.  Remove all the remaining references to it.

Cc: linux-arch <at> vger.kernel.org
Cc: Russell King <linux <at> arm.linux.org.uk>
Cc: linux-arm-kernel <at> lists.infradead.org
Cc: Doug Thompson <dougthompson <at> xmission.com>
Cc: linux-edac <at> vger.kernel.org
Cc: Bjorn Helgaas <bhelgaas <at> google.com>
Cc: linux-pci <at> vger.kernel.org
Cc: linux-pcmcia <at> lists.infradead.org
Cc: Hans Verkuil <hans.verkuil <at> cisco.com>
Cc: Steven Whitehouse <swhiteho <at> redhat.com>
Cc: cluster-devel <at> redhat.com
Cc: Arnd Bergmann <arnd <at> arndb.de>
Cc: Pavel Machek <pavel <at> ucw.cz>
Cc: "Rafael J. Wysocki" <rjw <at> sisk.pl>
Cc: linux-pm <at> vger.kernel.org
Cc: Andrew Morton <akpm <at> linux-foundation.org>
Cc: linux-mm <at> kvack.org
Signed-off-by: Stephen Rothwell <sfr <at> canb.auug.org.au>
---
 Documentation/ABI/testing/sysfs-bus-pci |  5 +----
 Documentation/SubmitChecklist           |  2 +-
 Documentation/cpu-hotplug.txt           |  2 +-
 Documentation/hwmon/submitting-patches  |  3 +--
 Documentation/kbuild/kconfig.txt        |  2 +-
 Documentation/usb/hotplug.txt           |  6 +++---
 arch/arm/Kconfig                        |  2 +-
(Continue reading)

Permalink | Reply | 5 comments |
headers
H. Peter Anvin | 21 May 2013 00:35
Favicon

Get rid of cpuinit?

We have gotten rid of devinit markup.  A recent patch of Linus' makes me
wonder if we similarly should get rid of cpuinit markup?

Just as with devices, the CPU hotplug machinery has been leveraged to
support a number of pieces of functionality such as suspend, which means
that on anything but the most embedded systems this functionality is
likely needed anyway.

On x86-64, for an "allyesconfig" build, the total amount of space in all
the .cpu* sections combined is 100K.

	-hpa
Permalink | Reply | 2 comments |
headers
Jiang Liu | 17 May 2013 17:45
Picon

[PATCH v7, part3 00/16] accurately calculate memory statisitic information

The original goal of this patchset is to fix the bug reported by
https://bugzilla.kernel.org/show_bug.cgi?id=53501
Now it has also been expanded to reduce common code used by memory
initializion.

This is the third part, previous two patch sets have been merged into
the main stream kernel and could also be accessed at:
http://marc.info/?l=linux-mm&m=136289696323825&w=2
http://marc.info/?l=linux-mm&m=136290291524901&w=2

This patchset applies to
git://git.cmpxchg.org/linux-mmotm.git v3.9-rc8-mmotm-2013-04-25-16-24

V2->V4:
1) rebase to git://git.cmpxchg.org/linux-mmotm.git
2) fix some build warnings and other minor bugs of previous patches

V4->V5:
1) rebase to v3.9-rc8-mmotm-2013-04-25-16-24
2) address comments from last round of review

V5->V6:
1) Change signature of free_reserved_area() according to Russell King's
   suggestion to fix following build warnings.
2) rebase to v3.9-mmotm-2013-05-09-15-57

V6->V7:
1) use asm-generic/param.h and uapi/asm-generic/param.h for AVR32
2) fix typo in log messages.
(Continue reading)

Permalink | Reply | 17 comments |
headers
Jiang Liu | 11 May 2013 19:34
Picon

[PATCH v6, part3 00/16] accurately calculate memory statisitic information

The original goal of this patchset is to fix the bug reported by
https://bugzilla.kernel.org/show_bug.cgi?id=53501
Now it has also been expanded to reduce common code used by memory
initializion.

This is the third part, previous two patch sets have been merged into
the main stream kernel and could also be accessed at:
http://marc.info/?l=linux-mm&m=136289696323825&w=2
http://marc.info/?l=linux-mm&m=136290291524901&w=2

This patchset applies to
git://git.cmpxchg.org/linux-mmotm.git v3.9-rc8-mmotm-2013-04-25-16-24

V2->V4:
1) rebase to git://git.cmpxchg.org/linux-mmotm.git
2) fix some build warnings and other minor bugs of previous patches

V4->V5:
1) rebase to v3.9-rc8-mmotm-2013-04-25-16-24
2) address comments from last round of review

V5->V6:
1) Change signature of free_reserved_area() according to Russell King's
   suggestion to fix following build warnings.
2) rebase to v3.9-mmotm-2013-05-09-15-57

We have only tested these patchset on x86 platforms, and have done basic
compliation tests using cross-compilers from ftp.kernel.org. That means
some code may not pass compilation on some architectures. So any help
to test this patchset are welcomed!
(Continue reading)

Permalink | Reply | 23 comments |
headers
André Hentschel | 8 May 2013 21:03
Picon
Favicon
Gravatar

[PATCHv4] arm: Preserve the user r/w register TPIDRURW on context switch and fork

From: =?UTF-8?q?Andr=C3=A9=20Hentschel?= <nerv <at> dawncrow.de>

Since commit 6a1c53124aa1 the user writeable TLS register was zeroed to
prevent it from being used as a covert channel between two tasks.

There are more and more applications coming to WinRT, Wine could support them,
but mostly they expect to have the thread environment block (TEB) in TPIDRURW.

This patch preserves that register per thread instead of clearing it.
Unlike the TPIDRURO, which is already switched, the TPIDRURW
can be updated from userspace so needs careful treatment in the case that we
modify TPIDRURW and call fork(). To avoid this we must always read
TPIDRURW in copy_thread.

Signed-off-by: André Hentschel <nerv <at> dawncrow.de>
Signed-off-by: Will Deacon <will.deacon <at> arm.com>
Signed-off-by: Jonathan Austin <jonathan.austin <at> arm.com> 

---
This patch is against a86d52667d8eda5de39393ce737794403bdce1eb

Why so much Signed-off-bys? Some History:
The first patch had performance issues pointed out by Russel King,
so Will Deacon jumped in to help me with that. The second one again
had performance issues and the missing copy_thread part was uncovered.
After some iterations by me, Jonathan Austin proposed a patch and
Russel King sent his idea of the assembler part. All this was finally
merged and refined into this patch.
Thanks to everyone!
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jiang Liu | 8 May 2013 17:16
Picon

[PATCH v5, part3 00/15] accurately calculate memory statisitic information

The original goal of this patchset is to fix the bug reported by
https://bugzilla.kernel.org/show_bug.cgi?id=53501
Now it has also been expanded to reduce common code used by memory
initializion.

This is the third part, previous two patch sets could be accessed at:
http://marc.info/?l=linux-mm&m=136289696323825&w=2
http://marc.info/?l=linux-mm&m=136290291524901&w=2

This patchset applies to
git://git.cmpxchg.org/linux-mmotm.git v3.9-rc8-mmotm-2013-04-25-16-24

V2->V4:
1) rebase to git://git.cmpxchg.org/linux-mmotm.git
2) fix some build warnings and other minor bugs of previous patches

V4->V5:
1) rebase to v3.9-rc8-mmotm-2013-04-25-16-24
2) address comments from last round of review

We have only tested these patchset on x86 platforms, and have done basic
compliation tests using cross-compilers from ftp.kernel.org. That means
some code may not pass compilation on some architectures. So any help
to test this patchset are welcomed!

Patch 1-7:
	Bugfixes and more work for part1 and part2
Patch 8-9:
	Fix typo and minor bugs in mm core
Patch 10-14:
(Continue reading)

Permalink | Reply | 18 comments |
headers
Steve Capper | 8 May 2013 11:52
Favicon

[RFC PATCH v2 00/11] HugeTLB and THP support for ARM64.

This series brings huge pages and transparent huge pages to ARM64.
The functionality is very similar to x86, and a lot of code that can
be used by both ARM64 and x86 is brought into mm to avoid the need
for code duplication.

One notable difference from x86 is that ARM64 supports normal pages
that are 64KB. When 64KB pages are enabled, huge page and
transparent huge pages are 512MB only, otherwise the sizes match
x86.

This series applies to 3.9, and requires one additional patch
ARM64: mm: Correct show_pte behaviour
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/164157.html

I've tested this under the ARMv8 models (Fast and Foundation) and
the x86 code has been tested in a KVM guest. libhugetlbfs was used
for testing under both architectures.

The most significant changes since the first RFC are:

   * PROT_NONE support added for HugeTLB and THP.
   * pmd_modify implementation fixed.
   * Superfluous huge dcache flushing code removed.
   * Simplified (and corrected) MAX_ORDER raise for THP && 64KB
     pages.
   * The MAX_ORDER check in huge_mm.h has been corrected.

I would be particularly interested in any feedback regarding the
first 4 patches in the series (the promotion of some huge page
code from x86 to mm), as this would also allow me to simplify
(Continue reading)

Permalink | Reply | 25 comments |
headers
John P. Goldman | 8 May 2013 10:46
Picon
Favicon

dringender Vorschlag


Entschuldigungen für kommen in Ihre Privatsphäre! Ich bin Rechtsanwalt
Werner Erich Zeller; Ich habe einen meiner einflussreichen und
wohlhabenden Kunden zum Tode; und er hatte eine sehr geheime und private
Investitionen von €15,000,000.00 bei einer privaten Bank in Großbritannien
hier zu Lebzeiten. Diese Investition wurde ohne einen deklarierten
nächsten Angehörigen und begünstigte. Jetzt brauche ich Sie arbeiten mit
mir als mein Partner zu erholen und zu je 50 % Aktienfonds. Alle Dokumente
werden rechtlich beantragt und beschafft, und in 5 Werktage, wird diese
Transaktion auftreten. Aber ich brauche einen ernsten, treuen und
glaubwürdigen Partner.

Bitte senden Sie mir eine vertrauliche Antwort, wenn Sie denken, Sie
vertraut werden können und sind von den Qualitäten! Ich warte auf Ihre
schnelle Antwort.

Werner Erich Zeller (Rechtsanwalt)
Rufen Sie + 44-702-409-0820 (Office)
Permalink | Reply | 0 comments |
headers
André Hentschel | 7 May 2013 22:51
Picon
Favicon
Gravatar

[PATCHv3] arm: Preserve the user r/w register TPIDRURW on context switch and fork

From: =?UTF-8?q?Andr=C3=A9=20Hentschel?= <nerv <at> dawncrow.de>

Since commit 6a1c53124aa1 the user writeable TLS register was zeroed to
prevent it from being used as a covert channel between two tasks.

There are more and more applications coming to WinRT, Wine could support them,
but mostly they expect to have the thread environment block (TEB) in TPIDRURW.

This patch preserves that register per thread instead of clearing it.
Unlike the TPIDRURO, which is already switched, the TPIDRURW
can be updated from userspace so needs careful treatment in the case that we
modify TPIDRURW and call fork(). To avoid this we must always read
TPIDRURW in copy_thread.

Signed-off-by: André Hentschel <nerv <at> dawncrow.de>
Signed-off-by: Will Deacon <will.deacon <at> arm.com>
Signed-off-by: Jonathan Austin <jonathan.austin <at> arm.com> 

---
This patch is against a86d52667d8eda5de39393ce737794403bdce1eb

I could only test it with kernel 3.4.6, beside using Wine for testing i also
used https://github.com/AndreRH/tpidrurw-test

Why so much Signed-off-bys? Some History:
The first patch had performance issues pointed out by Russel King,
so Will Deacon jumped in to help me with that. The second one again
had performance issues and the missing copy_thread part was uncovered.
After some iterations by me, Jonathan Austin proposed a patch and
Russel King sent his idea of the assembler part. All this was finally
(Continue reading)

Permalink | Reply | 2 comments |

Gmane